Лекция 2. Стандарты жизненного цикла ПО. Управление требованиями.

 

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

Наиболее распространёнными стандартами описания ЖЦ ПО являются:

· Российский ГОСТ 34.601-90

· Международный ISO/IEC 12207:1995 (российский аналог – ГОСТ Р ИСО/МЭК 12207-99)

 

Стандарт ГОСТ 34.601-90

 

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

 

1. Формирование требований к АС

1.1. Обследование объекта и обоснование необходимости создания АС

1.2. Формирование требований пользователя к АС

1.3. Оформление отчета о выполнении работ и заявки на разработку АС

2. Разработка концепции АС

2.1. Изучение объекта

2.2. Проведение необходимых научно-исследовательских работ

2.3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей

2.4. Оформление отчета о проделанной работе

3. Техническое задание

3.1. Разработка и утверждение технического задания на создание АС

4. Эскизный проект

4.1. Разработка предварительных проектных решений по системе и ее частям

4.2. Разработка документации на АС и ее части

5. Технический проект

5.1. Разработка проектных решений по системе и ее частям

5.2. Разработка документации на АС и ее части

5.3. Разработка и оформление документации на поставку комплектующих изделий

5.4. Разработка заданий на проектирование в смежных частях проекта

6. Рабочая документация

6.1. Разработка рабочей документации на АС и ее части

6.2. Разработка и адаптация программ

7. Ввод в действие

7.1. Подготовка объекта автоматизации

7.2. Подготовка персонала

7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

7.4. Строительно-монтажные работы

7.5. Пусконаладочные работы

7.6. Проведение предварительных испытаний

7.7. Проведение опытной эксплуатации

7.8. Проведение приемочных испытаний

8. Сопровождение АС.

8.1. Выполнение работ в соответствии с гарантийными обязательствами

8.2. Послегарантийное обслуживание

 

Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

 

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

Это проявляется в том, что:

· не отражены гибкие, итеративные методологии разработки, их ценности и подходы

· возможности более гибкого задания модели ЖЦ ПО – ограничены

· в основном стандарт ориентирован на разработку АС в общем виде:

o программно-аппаратных комплексов

o объектов автоматизации

o строительно-монтажных, пусконаладочных работ

· оформляется документация по ГОСТ ЕСПД

o более «тяжеловесный» стандарт документации, чем современные

o не вполне учитываются требования CALS технологий и ЕИМ/ЕИП

o не вполне поддерживаются CASE-средства и  разработки на основании моделей, моделеориентированной архитектуры, порождающего проектирования и синтеза из формальных моделей спецификаций

o ожидается более «тяжеловесный» процесс согласования и утверждения, управления документацией и изменениями согласно ГОСТ – чем современные процессы управления конфигурацией, согласование на основании систем СЭД, BPM.

 

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

 

Ценность этого стандарта ГОСТ 34.601-90 применительно к разработке ПО (а не программно-аппаратных комплексов АС) состоит в основном, в стандартизации документооборота (результатов) и этапов работ (процессов) проекта разработки АС, включая согласование и доработки.

 

Особенностью стандарта является то, что в требованиях к оформлению и содержанию задана структура требуемых разделов в ТЗ, техническом задании. Расписаны процессы согласования и утверждения тех. задания. Не полностью описан процесс составления успешного, корректного тех. задания – этот процесс творческий и отдаётся на откуп аналитику, главному инженеру, руководителю проекта: описаны требования к результату процесса разработки ТЗ, не описан достаточно подробно сам процесс разработки ТЗ, вопрос оценки самого качества ТЗ также не однозначен.

В реальности при разработке ПО тех. задание зачастую инкрементально, итеративно пересматривается, уточняется, проверяется на тех. реализуемость, ошибки и противоречивые требования многократно.

Современные методологии и CASE-средства позволяют этот процесс более подробно формализовать, и автоматизировать его выполнение. Более чётко определить качество результатов этого процесса.

 

Это достигается за счёт регулярного, итерационного выполнения процесса управления требованиями.

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

 

У «технического задания», как документа есть как преимущества, так и недостатки:

· преимущества

o если есть чёткая, формальная модель решения, или математическая модель АС (например, согласно теории автоматического управления, ТАУ)

o если есть чётко описанные внешние системы, интерфейсы, стандарты и способы сопряжения с «внешним миром»

o если чётко понятно, что именно нужно делать исполнителю и как именно принимать результат заказчику

o если процесс согласования и утверждения не вызывает сложностей

· недостатки

o если «пока ещё» не указан чётко и конкретно набор отраслевых стандартов, НСИ (нормативно-справочной информации), норм и показателей, которым нужно соответствовать

o если способ решения в виде задач и подзадач «пока ещё» не ясен и его самого по себе нужно открыть в ходе выполнения

o если заказчик «пока ещё» не вполне понимает, чего он хочет (но может это оценить экспертным путём, когда увидит прототип)

o если исполнитель «пока ещё» не вполне понимает, как он будет решать задачу (но понимает, каков должен быть результат)

o если процесс согласования «пока ещё» не ясен

o если оценить качество задания «пока ещё» проблематично

Это «пока ещё» означает только одно: что конечный результат должен быть достигнут и техническое задание должно быть согласовано до окончания работ, обеспечив приёмку результатов – но его может не быть в начале работ.

То есть, что техническое задание должно быть разработано инженерными, стабильно повторяемыми методами (а не творческо-эвристическими, в ходе искусства) – в ходе процесса управления требованиями.

При этом требования в свою очередь подразделяются на элементарные и составные. То есть: составные требования, в свою очередь, нужно разрабатывать рекурсивно, итерационно в ходе процесса управления требованиями.

Подробнее процесс управления требованиями рассмотрен в следующей лекции.