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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008

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

3Модели жизненного цикла пс.

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

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

К настоящему времени наибольшее распространение получи­ли следующие основные модели ЖЦ:

•  каскадная модель (70-80-е годы 20 века);

•  спиральная модель (80-90-е годы 20 века).

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

Рис. 2.19. Каскадная схема разработки программного средства

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

•  на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласован­ности;

•  выполняемые в логичной последовательности этапы работ по­зволяют планировать сроки завершения всех работ и соответ­ствующие затраты.

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

Рис. 2.20. Схема реального процесса разработки ПС по каскадной схеме

Основным недостатком каскадного подхода является существен­ное запаздывание с получением результатов. Согласование резуль­татов с пользователями производится только в точках, планируе­мых после завершения каждого этапа работ, требования к ИС «за­морожены» в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания толь­ко после того, как работа над системой будет полностью заверше­на. В случае неточного изложения требований или их изменения в течение длительного периода создания ПС пользователи получа­ют систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 2.21), делающая упор на начальные папы ЖЦ: анализ и проектирование. На этих этапах реализуе­мость технических решений проверяется путем создания прото­типов. Каждый виток спирали соответствует созданию фрагмен­та или версии ПС, на нем уточняются цели и характеристики про­екта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

Рис. 2.21. Схема спиральной модели жизненного цикла

Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итера­тивном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача — как можно быстрее показать пользователям системы работоспособ­ный продукт, тем самым, активизируя процесс уточнения и до­полнения требований.

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