Методы первичного сбора требований. Модели системы. Языки специфики требований. Оценка требований

- глагол "следует (should)" выражает рекомендацию из имеющихся  возможных вариантов;

- глагол "может (may)" указывает образ действий, допустимый  в рамках ГОСТ Р ИСО/МЭК

В данном стандарте существуют ограничения:

1. В настоящем стандарте не детализируются процессы жизненного цикла в терминах методов или процедур, необходимых для удовлетворения требований и достижения результатов процесса.
2. Настоящий стандарт не устанавливает требований к документации в части ее наименований, форматов, определенного содержания и носителей для записи. Настоящий стандарт может потребовать разработки документов подобного класса или типа, например, различных планов. Настоящий стандарт, однако, не предусматривает, чтобы такие документы разрабатывались или комплектовались раздельно или каким-то образом объединялись. Эти решения остаются за пользователем настоящего стандарта.
3. Настоящий стандарт не устанавливает конкретной модели жизненного цикла системы или программных средств, разработки методологии, методов, моделей или технических приемов. Стороны, применяющие настоящий стандарт, отвечают за выбор модели жизненного цикла для программных проектов и отображение процессов, действий и задач, представленных в настоящем стандарте, на эту модель. Стороны также ответственны за выбор и применение методов разработки программных средств и за выполнение действий и задач, подходящих для программного проекта.
4. Настоящий стандарт не должен противоречить политикам, процедурам и нормам применяющей его организации, национальным законам и регулирующим документам. Каждое такое противоречие должно быть разрешено до начала использования настоящего стандарта.

 

Технические процессы состоят  из следующих процессов:

a)определение требований  правообладателей 

b)анализ системных требований (специальный случай процесса  анализа требований);

c)проектирование архитектуры  системы 

d)процесс реализации 

e)процесс комплексирования  системы 

f)процесс квалификационного  тестирования системы 

g)процесс инсталляции  программных средств 

h)процесс поддержки приемки  программных средств 

i)процесс функционирования  программных средств 

j)процесс сопровождения  программных средств 

k)процесс изъятия из  обращения программных средств.

 

Цель стандарта - определить полную совокупность процессов, которые могут выполняться в ходе проекта по созданию программной системы. Но поскольку проекты могут сильно различаться, например, по масштабам, сложности, рискам и т. п., допускается для каждого проекта локально видоизменять использующиеся в нем процессы, исключая или добавляя отдельные работы и задачи. Такая деятельность называется в стандарте адаптацией.

Выбор процессов, работ и задач

Данная работа состоит  из следующих задач:

1. Должны быть определены необходимые для выполнения процессы, работы и задачи. При этом должна быть охвачена разрабатываемая документация и обязанности исполнителей.
2. Дополнительные процессы, работы и задачи, выбранные по 1, но не описанные в стандарте, следует установить в самом договоре. Следует оценить организационные процессы жизненного цикла  с точки зрения их соответствия выбранным процессам, работам и задачам.
3. Имеются задачи, требования к которым содержат слова "должен" или "должны". Эти задачи следует тщательно проанализировать на предмет сохранения или исключения из проекта или данной области деятельности. К обязательно рассматриваемым факторам относятся: риск, стоимость, график работ, выполнимость, объем, критичность и интерфейс с пользователем.

Для дальнейшего анализа  стандарта мне понадобится описание одного из процессов. Вот пример описания (основного) процесса заказа и разработки требований. Я буду комментировать текст, вставляя замечания прямо по ходу описания процесса.

Процесс заказа.

Процесс заказа состоит  из работ и задач, выполняемых  заказчиком. Процесс начинается с  определения потребностей заказчика  в системе,т.е. разработке требований, программном продукте или программной услуге. Далее следуют подготовка и выпуск заявки на подряд, выбор поставщика и управление процессом заказа вплоть до завершения приемки системы, программного продукта или программной услуги. Конкретная организация, имеющая соответствующую потребность, может быть названа собственником. Собственник может заключить договор на выполнение части или всех работ по заказу с посредником, который будет поочередно проводить данные работы в соответствии с процессом заказа. В данном подразделе под заказчиком понимается собственник или посредник.

Заказчик управляет процессом заказа на проектном уровне в соответствии с процессом управления, который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры; адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации  и управляет процессом заказа на организационном уровне в соответствии с процессами усовершенствования . Это типичный для стандарта пример перекрестных ссылок на процессы. Тем самым обеспечивается замкнутость стандарта. Это не очень легко воспринимается при первом чтении, но помогает ничего не забыть в ходе адаптации.

Список работ. Данный процесс  состоит из следующих работ:

1. подготовка;
2. подготовка заявки на подряд;
3. подготовка и корректировка договора;
4. надзор за поставщиком;
5. приемка и закрытие договора.

5.1.1. Подготовка

Данная работа состоит из следующих  задач:

5.1.1.1. Заказчик начинает  процесс заказа, описывая концепцию  или потребность в заказе, разработке  или модернизации системы, программного  продукта или программной услуги.

5.1.1.2. Заказчик должен  определить и проанализировать  требования к системе. Требования  к системе должны охватывать  функциональные, коммерческие, организационные,  потребительские аспекты системы,  а также требования к безопасности, защите и другие критические требования наряду с требованиями к проектированию, тестированию и соответствующим стандартам и процедурам.

5.1.1.3. Если заказчик поручает  поставщику выполнение анализа требований к системе, то заказчик должен согласовать требования, сформулированные в результате анализа.

5.1.1.4. Заказчик может  выполнить определение и анализ  требований к программным средствам  сам или поручить решение этой  задачи поставщику.

5.1.1.5. При решении задач,  определенных в 5.1.1.2 и 5.1.1.4, должен  использоваться процесс разработки (подраздел 5.3).

5.1.1.6. Заказчик должен  рассмотреть варианты реализации  заказа начиная с анализа соответствующих  критериев, включая рискованность  и стоимость проекта и выгоды  от каждого варианта. Анализируются  следующие варианты:

• a) покупка готового программного продукта, удовлетворяющего определенным требованиям;
• b) разработка программного продукта или получение программной услуги собственными силами;
• c) разработка программного продукта или получение программной услуги на договорной основе;
• d) комбинации по перечислениям a), b), c);
• e) модернизация существующего программного продукта или услуги.

(Как видим, стандарт  не включает таких вариантов,  как приобретение прав абонентского  доступа к стандартному программному  обеспечению или доработку удаленного  ПО под требования заказчика  с последующим абонентским доступом. Нет и варианта аренды ПО, как  компонента более сложного объекта  аренды. Вряд ли возможно перечислить  все существующие и будущие  варианты реализации заказа в  стандарте, но задача 5.1.1.6 разработки  такого списка в любом случае имеет смысл)

5.1.1.7. При приобретении  готового программного продукта  заказчик должен получить гарантии  того, что удовлетворены следующие  условия:

• a) программный продукт соответствует установленным требованиям;
• b) имеется в наличии соответствующая документация;
• c) соблюдены права собственности, использования, лицензирования и гарантии;
• d) предусмотрена последующая поддержка программного продукта.

5.1.1.8. Заказчик должен  подготовить, документально оформить  и выполнить план заказа. План  должен содержать:

• a) требования к системе;
• b) планируемую загрузку системы;
• c) тип реализуемого договора;
• d) обязанности организаций, участвующих в договоре;
• e) обеспечение подходов к реализации договора;
• f) анализ возможных рискованных ситуаций, а также методы управления такими ситуациями.

5.1.1.9. Заказчик должен  определить и документально оформить  принятые правила и условия  (критерии) реализации договора.

5.1.2. Подготовка заявки  на подряд

Данная работа состоит  из следующих задач.

5.1.2.1. Заказчик должен  документально оформить требования  к заказу (например, в виде заявки  на подряд), состав которых зависит  от вариантов реализации заказа, выбранных в соответствии с 5.1.1.6. Соответствующая документация по заказу должна содержать:

• a) требования к системе;
• b) описание области применения системы;
• c) указания для участников торгов;
• d) список программных продуктов;
• e) сроки и условия реализации заказа;
• f) правила контроля над субподрядчиками;
• g) технические ограничения (например, по условиям эксплуатации).

(Очевидно, точный состав  документов будет разниться для  разных организаций и предприятий.  Он может включать целый ряд  дополнительных документов, например  бюджетное обоснование для внутреннего  финансового контроля, ссылку на  планы вышестоящих организаций,  различные бизнес-обоснования, например  в связи с инвестиционными  проектами, в рамках которых  предпринимается проект по автоматизации,  и т. д. Приведенный перечень  стоит воспринимать как обязательный и минимальный. ).

5.1.2.2. Заказчик должен  определить, какие из процессов,  работ и задач, описанных в  настоящем стандарте, применимы  к условиям проекта, и соответствующим  образом их адаптировать. В первую  очередь заказчик должен определить  применяемые вспомогательные процессы  и организации, реализующие данные  процессы, включая обязанности этих  организаций (если это не организации  поставщика) так, чтобы потенциальные  поставщики могли в своих предложениях  определить подход к каждому  из выбранных вспомогательных  процессов. Заказчик должен определить  содержание тех задач, которые  предполагается сформулировать  в договоре.

(Вот и задача, относящаяся  к адаптации стандарта. Несмотря  на несколько туманные формулировки, можно предположить, что цель  заказчика - организовать взаимодействие  потенциальных поставщиков с  подразделениями/организациями, выполняющими  вспомогательные процессы. Например, поставщики должны понять существующие  возможности заказчика по управлению  конфигурацией системы и, возможно, предложить услуги по обучению  персонала. А может быть, управление  конфигурацией будет предметом  будущего аутсорсингового контракта).

5.1.2.3. В документации  по заказу должны быть также  определены контрольные пункты  договора, при выполнении которых  анализируется и проверяется  деятельность поставщика. ( Это ссылки на процессы совместного анализа и аудита системы.  ).

5.1.2.4. Требования к заказу  должны быть представлены организации,  выбранной для выполнения работ  в процессе заказа.

5.1.3. Подготовка и корректировка  договора

Данная работа состоит из следующих  задач.

5.1.3.1. Заказчик должен  определить процедуру для выбора  поставщика, включая критерии оценки  поступающих предложений по реализации  заказа и их соответствие установленным  требованиям.

5.1.3.2. Заказчик должен  выбрать поставщика исходя из  оценки предложений, поступивших  от потенциальных поставщиков,  их возможностей и других рассматриваемых  факторов.

5.1.3.3. Заказчик может  до заключения договора привлекать  другие стороны, включая потенциальных  поставщиков, для адаптации настоящего  стандарта к условиям проекта. Однако окончательное решение по адаптации должен принимать заказчик. Заказчик должен включить в текст договора или сослаться в нем на адаптированный настоящий стандарт.