Понятие жизненного цикла (ЖЦ) является одним из ключевых понятий методологии проектирования информационных систем.
Жизненный цикл информационной системы – это непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации [4].
Основным стандартом, определяющим структуру жизненного цикла, является ГОСТ Р ИСО/МЭК 12207-2010
https://www.gostrf.com/normadata/1/4293804/4293804988.pdf.
СЛАЙД 4 Согласно стандарту структура жизненного цикла основывается на трех группах процессов:
- основные (заказ, разработка, поставка, эксплуатация, сопровождение);
- вспомогательные (обеспечивают выполнение основных процессов):
-документирование – работы по разработке, выпуску, редактированию, распространению и сопровождению документов, в которых нуждаются все заинтересованные лица;
-управление конфигурацией (конфигурационное управление) включает работы: определение и установление состояния программных объектов в системе; управление изменениями и выпуском объектов; обеспечение полноты, совместимости и правильности объектов; управление хранением, обращением и поставкой объектов;
-обеспечение качества – работы по обеспечению соответствия создаваемой системы и реализуемых процессов жизненного цикла установленным требованиям и утвержденным планам;
-верификация – работы соответствующего субъекта (заказчика, поставщика или независимой стороны) по проверке соответствия создаваемых промежуточных результатов установленным требованиям по мере реализации проекта. Различают верификацию договора, процесса, требований, проекта, системы, сборки системы и документации;
-аттестация – работы соответствующего субъекта по проверке полного соответствия требований и конечного продукта функциональному назначению системы;
-совместный анализ – работы по оценке состояния или результатов какой-либо работы (системы);
-аудит – работы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и условиям договора;
-разрешение проблем – работы по анализу и устранению проблем, обнаруженных при реализации проекта;
-организационные:
-управление проектами – работы по планированию и управлению процессами, включая контроль, проверку и оценку выполненных работ с формированием отчетности;
-создание инфраструктуры проекта – работы по установлению и обеспечению инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения системы;
-усовершенствование – работы по оценке, контролю и улучшению процессов жизненного цикла;
-обучение – работы по планированию и проведению обучения персонала, включая разработку учебных материалов. При этом под персоналом понимаются не только конечные пользователи, которые будут эксплуатировать систему, но и разработчики системы. Например, разработчики должны быть обучены технологиям и средствам программирования, принятым в организации, и даже обучены правильно внедрять и обучать конечных пользователей работе с системой. Как бы это ни парадоксально звучало, но обучать правильной методике и приемам обучения тоже необходимо.
СЛАЙД 5 ГОСТ 34.601-90 https://docs.cntd.ru/document/gost-34-601-90
СЛАЙД 6 Стадии и этапы создания АС в общем случае приведены в таблице
| Стадии | Этапы работ |
| 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. Послегарантийное обслуживание |
Стадии и этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта.
Допускается исключать стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.
В процессе разработки и эксплуатации системы участвует определенный круг лиц (представители заказчика и разработчика), заинтересованных в успешной реализации проекта.
В этом процессе между ними распределяются роли, за каждой из которых закрепляется определенный набор функций (обязанностей). При этом один и тот же человек может выступать в разных ролях (качествах). Так, например, один и тот же человек может быть проектировщиком и программистом, в то же время в проекте может принимать участие несколько экспертов, проектировщиков или программистов.
СЛАЙД 13 Организации, которые участвуют в работах по созданию информационной системы:
- Организация-заказчик (пользователь), для которой создается АС и которая обеспечивает финансирование, приемку работ и эксплуатацию АС, а также выполнение отдельных работ по созданию АС;
- Организация-разработчик, которая осуществляет работы по созданию АС, представляя заказчику совокупность научно-технических услуг на разных стадиях и этапах создания, а также разрабатывая и поставляя различные программные и технические средства АС;
- Организация-поставщик, которая изготавливает и поставляет программные и технические средства по заказу разработчика или заказчика;
- Организация-генпроектировщик объекта автоматизации;
- Организации-проектировщики различных частей проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС;
- Организации строительные, монтажные, наладочные и другие.
У проекта должен быть один руководитель и, как правило, один системный аналитик. За остальные роли в крупных проектах отвечает обычно по несколько человек. Роли эксперта-технолога и пользователя выполняют представители заказчика, остальные роли – представители разработчика. Эксперты-технологи могут быть приглашены из сторонней организации. По мере необходимости в проекте могут принимать участие координатор работ (ответственный) со стороны заказчика, аудиторы и т. д.
СЛАЙД 15 Классификация моделей жизненного цикла:
К настоящему времени наибольшее распространение получили следующие модели (стратегии) жизненного цикла:
- каскадная;
- инкрементная;
- спиральная.
Рассмотрим каскадную и спиральные модели и сравним их.
СЛАЙД 16 Каскадная стратегия (однократный проход, водопадная или классическая модель) подразумевает линейную последовательность выполнения стадий создания информационной системы. Другими словами, переход с одной стадии на следующую происходит только после того, как будет полностью завершена работа на текущей.
Данная модель применяется при разработке информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования.
Достоинства модели:
- на каждой стадии формируется законченный набор документации, программного и аппаратного обеспечения, отвечающий критериям полноты и согласованности;
- выполняемые в четкой последовательности стадии позволяют уверенно планировать сроки выполнения работ и соответствующие ресурсы (денежные, материальные и людские).
Недостатки модели:
- реальный процесс разработки информационной системы редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем;
- основана на точной формулировке исходных требований к информационной системе. Реально в начале проекта требования заказчика определены лишь частично;
- основной недостаток – результаты разработки доступны заказчику только в конце проекта. В случае неточного изложения требований или их изменения в течение длительного периода создания ИС заказчик получает систему, не удовлетворяющую его потребностям.
СЛАЙД 19,20 Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.
Данная модель жизненного цикла характерна при разработке новаторских (нетиповых) систем. В начале работы над проектом у заказчика и разработчика нет четкого видения итогового продукта (требования не могут быть четко определены) или стопроцентной уверенности в успешной реализации проекта (риски очень велики). В связи с этим принимается решение разработки системы по частям с возможностью изменения требований или отказа от ее дальнейшего развития. Как видно на слайде 19 развитие проекта может быть завершено не только после стадии внедрения, но и после стадии анализа риска.
СЛАЙД 21 Достоинства модели:
- позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;
- допускает изменение требований при разработке информационной системы, что характерно для большинства разработок, в том числе и типовых;
- обеспечивает большую гибкость в управлении проектом;
- позволяет получить более надежную и устойчивую систему. По мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации;
- позволяет совершенствовать процесс разработки – анализ, проводимый в каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации;
- уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.
СЛАЙД 22 Недостатки модели:
- увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;
- затруднены операции временного и ресурсного планирования всего проекта в целом. Для решения этой проблемы необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа выполнена. План составляется на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков.
Знание различных моделей жизненного цикла и умение их применять на практике необходимы любому руководителю проекта. Правильный выбор модели позволяет грамотно планировать объемы финансирования, сроки и ресурсы, необходимые для выполнения работ, сократить риски как разработчика, так и заказчика. Это способствует повышению авторитета (имиджа) разработчиков в глазах заказчика и в свою очередь оказывает влияние на перспективу дальнейшего сотрудничества с ним и другими заказчиками. Считать, что спиральная модель лучше остальных, неверно. Ведь на каждый проект заключается отдельный договор с определенной стоимостью. Заключать договор на большую сумму с неопределенным итоговым результатом заказчик никогда не будет (если только он не альтруист). В этом случае он предложит вложить вначале небольшую сумму в проект и уже по результатам первой версии (итерации) будет решать вопрос о заключении дополнительного договора на развитие системы.
Каждая из моделей имеет свои достоинства и недостатки, а также сферы применения в зависимости от специфики разрабатываемой системы, возможностей заказчика и разработчика и т. п. В табл. приводится сравнительная характеристика рассмотренных выше моделей, которая должна помочь в выборе стратегии для конкретного проекта. СЛАЙД 24
| Характеристика проекта | Модель (стратегия) | |
| Каскадная | Спиральная | |
| Новизна разработки и обеспеченность ресурсами | Типовой. Хорошо проработаны технология и методы решения задачи | Нетиповой (новаторский). Нетрадиционный для разработчика |
| Ресурсов заказчика и разработчика хватает для реализации проекта в сжатые сроки | ||
| Масштаб проекта | Малые и средние проекты | Любые проекты |
| Сроки выполнения проекта | До года | До нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года |
| Заключение отдельных договоров на отдельные версии | Заключается один договор. Версия и есть итоговый результат проекта | На отдельную версию или несколько последовательных версий обычно заключается отдельный договор |
| Определение основных требований в начале проекта | Да | Нет |
| Изменение требований по мере развития проекта | Нет | Да |
| Разработка итерациями (версиями) | Нет | Да |
| Распространение промежуточного ПО | Нет | Да |
не стоит рассматривать значения «Да» и «Нет» как жесткие требования. Например, незначительное изменение требований по мере развития проекта при использовании каскадной модели (например, добавление некоторых непредусмотренных сервисных функций) встречается не так уж редко и в случае их реализации способствует улучшению взаимоотношений между сторонами. Аналогично распространение промежуточного программного обеспечения при спиральной модели необязательно, а иногда даже вредно отражается на процессах внедрения и опытной эксплуатации системы.
При разработке системы под итоговым продуктом и промежуточным программным обеспечением согласно следует понимать:
- ревизию (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД, необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием;
- модификацию – любые оперативные изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения и обусловливающие изменение эксплуатационных характеристик без изменения функций (предусмотренных ТЗ), а также изменения, связанные с устранением ошибок, усовершенствованием;
- версию – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду;
- развитие (очередь) – плановые изменения информационной системы, связанные с введением новых функций и улучшением эксплуатационных характеристик, переходом на новую информационную среду, внедрением новых комплексов технических средств, новых информационных технологий и пр.
В соответствии с приведенной классификацией итоговым продуктом для любой из моделей жизненного цикла является обязательная к передаче версия или очередь системы. Разработка очередями характерна при инкрементной стратегии. В качестве промежуточного программного обеспечения следует рассматривать ревизии и модификации. Как было отмечено выше, частая передача ревизий и модификаций конечным пользователям (особенно занятым другими производственными делами) нежелательна. Согласно [12] смена версий информационных систем на железнодорожном транспорте должна выполняться не чаще одного - двух раз в год, а модификаций – не чаще раза в месяц.
Вопросы для самопроверки:
1. Дайте определение понятию «жизненный цикл информационной системы».
2. Назовите группы процессов жизненного цикла.
3. Перечислите стадии жизненного цикла системы согласно ГОСТ 34.601-90 и дайте краткую характеристику каждой из них.
4. Перечислите роли участников проекта.
5..Приведите классификацию моделей жизненного цикла и перечислите их особенности.
6. Для чего необходим выбор модели жизненного цикла?