Стадия обеспечения. Жизненный цикл программных систем

Жизненный цикл программного обеспечения

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ним документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

· вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Модели жизненного цикла ПО

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

1. Каскадная модель (до 70-х годов XX в) определяет последовательный переход на следующий этап после завершения предыдущего.

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

Достоинство : хорошие показатели по срокам разработки и надежности при решении отдельных задач.

Недостаток : неприменимость к большим и сложным проектам из-за изменчивости требований к системе в течение длительного проектирования.

2. Итерационная модель (70-80-е годы XX в.) соответствует технологии проектирования «снизу - вверх». Допускает итерационные возвраты на предыдущие этапы после выполнения очередного этапа;

Модель предусматривает обобщение полученных проектных решений отдельных задач в общесистемные решения. При этом возникает потребность в пересмотре ранее сформулированных требований.

Достоинство: возможность оперативно вносить коррективы в проект.

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

3. Спиральная модель (80-90-е годы XX в.) соответствует технологии проектирования «сверху - вниз». Предполагает использование программного прототипа, допускающего программное расширение. Проект системы циклически повторяет путь от детализации требований к детализации программного кода.

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

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

Достоинства:

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

2. сокращение сроков проектирования;

3. упрощение создания проектной документации.

Недостаток: высокие требования к качеству общесистемного репозитория (общей базы проектных данных).

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

· Анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области.

· Проектирование. Пользователи под руководством разработчиков принимают участие в техническом проектировании.

· Конструирование. Разработчики проектируют рабочую версию ПО с использованием языков 4-го поколения;

· Внедрение. Разработчики обучают пользователей работе в среде новой ПО.

Понятие жизненного цикла программного обеспечения

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

В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ разделены на три группы (рис. 2.1).

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

1. Формирование требований к ПО.

2. Проектирование.

3. Реализация.

4.Тестирование.

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

6. Эксплуатация и сопровождение.

7. Снятие с эксплуатации.

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

a) каскадная и

b) спиральная (эволюционная).

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

Преимущества применения каскадной модели заключаются в следующем:

На каждой стадии формируется законченный набор проектной документации;

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

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

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

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

Каскадную (эволюционную) модель можно представить в виде диаграммы, которая приведена на рисунке 2.5.

Одним из результатов применения спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений , или RAD (Rapid Application Development). Жизненный цикл ПО в соответствии с этим способом включает в себя четыре стадии:

1) анализ и планирование требований;

2) проектирование;

3) реализация;

4) внедрение.

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

1) Стратегия;

2) Анализ;

3) Проектирование;

4) Реализация;

5) Тестирование;

6) Внедрение;

7) Эксплуатация и техническая поддержка.

Стратегия

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

Итогом этапа определения стратегии становится документ, в котором четко сформулировано следующее:

Что именно причитается заказчику, если он согласится финансировать проект;

Когда он сможет получить готовый продукт (график выполнения работ);

Во сколько это ему обойдется (график финансирования этапов работ для крупных проектов).

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

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

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

a) функции - информация о событиях и процессах, которые происходят в бизнесе;

b) сущности - информация о предметах, которые имеют значение для организации и о которых что-либо известно.

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

Проектирование

На этапе проектирования формируется модель данных. Проектировщики обрабатывают данные анализа. Конечным продуктом этапа проектирования являются схема базы данных (если таковая существует в проекте) или схема хранилища данных (ER-модель) и набор спецификаций модулей системы (модель функций).

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

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

Задачами проектирования являются:

Рассмотрение результатов анализа и проверка их полноты;

Семинары с заказчиком;

Определение критических участков проекта и оценка его ограничений;

Определение архитектуры системы;

Принятие решения об использовании продуктов сторонних разработчиков, а также о способах интеграции и механизмах обмена информацией с этими продуктами;

Проектирование хранилища данных: модель базы данных;

Проектирование процессов и кода: окончательный выбор средств разработки, определение интерфейсов программ, отображение функций системы на ее модули и определение спецификаций модулей;

Определение требований к процессу тестирования;

Определение требований к безопасности системы.

Реализация

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

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

Чаще всего на этапе разработки меняются интерфейсы пользователя. Это обусловлено периодической демонстрацией модулей заказчику. Он также может существенно изменять запросы к данным.

Этап разработки сопряжен с этапом тестирования, и оба процесса идут параллельно. Синхронизирует действия тестеров и разработчиков система bug tracking.

Ошибки должны быть классифицированы согласно приоритетам. Для каждого класса ошибок должна быть определена четкая структура действий: «что делать», «как срочно», «кто ответственен за результат». Каждая проблема должна отслеживаться проектировщиком/разработчиком/тестировщиком, отвечающим за ее устранение. То же самое касается ситуаций, когда нарушаются запланированные сроки разработки и передачи модулей на тестирование.

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

Тестирование

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

Чем сложнее проект, тем больше будет потребность в автоматизации системы хранения ошибок - bug tracking, которая обеспечивает следующие функции:

Хранение сообщения об ошибке (к какому компоненту системы относится ошибка, кто ее нашел, как ее воспроизвести, кто отвечает за ее исправление, когда она должна быть исправлена);

Система уведомления о появлении новых ошибок, об изменении статуса известных в системе ошибок (уведомления по электронной почте);

Отчеты об актуальных ошибках по компонентам системы;

Информация об ошибке и ее история;

Правила доступа к ошибкам тех или иных категорий;

Интерфейс ограниченного доступа к системе bug tracking для конечного пользователя.

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

Собственно тесты систем принято подразделять на несколько категорий:

a) автономные тесты модулей; они используются уже на этапе разработки компонентов системы и позволяют отслеживать ошибки отдельных компонентов;

b) тесты связей компонентов системы; эти тесты также используются и на этапе разработки, они позволяют отслеживать правильность взаимодействия и обмена информацией компонентов системы;

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

d) приемосдаточный тест ; основное его назначение - сдать систему заказчику;

e) тесты производительности и нагрузки ; эта группа тестов входит в системный, именно она является основной для оценки надежности системы.

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

Отдельного компонента информационной системы;

Группы компонентов системы;

Основных модулей системы;

Операционной системы;

Жесткий сбой (отказ питания, жестких дисков).

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

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

Внедрение

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

Ввод в эксплуатацию проходит как минимум три стадии:

2) накопление информации;

3) выход на проектную мощность (то есть собственно переход к этапу эксплуатации).

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

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

Выход системы на проектную мощность в хорошем варианте - это доводка мелких ошибок и редкие серьезные ошибки.

Эксплуатация и техническая поддержка

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

Стандарты жизненного цикла ПО

• ГОСТ 34.601-90
• ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)

Методологии разработки ПО

• Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
• Экстремальное программирование (англ. Extreme Programming, XP ). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.

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

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

1. Формирование требований к АС
   1. Обследование объекта и обоснование необходимости создания АС
   2. Формирование требований пользователя к АС
   3. Оформление отчета о выполнении работ и заявки на разработку АС
2. Разработка концепции АС
   1. Изучение объекта
   2. Проведение необходимых научно-исследовательских работ
   3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
   4. Оформление отчета о проделанной работе
3. Техническое задание
   1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект
   1. Разработка предварительных проектных решений по системе и ее частям
5. Технический проект
   1. Разработка проектных решений по системе и ее частям
   2. Разработка документации на АС и ее части
   3. Разработка и оформление документации на поставку комплектующих изделий
   4. Разработка заданий на проектирование в смежных частях проекта
6. Рабочая документация
   1. Разработка рабочей документации на АС и ее части
   2. Разработка и адаптация программ
7. Ввод в действие
   1. Подготовка объекта автоматизации
   2. Подготовка персонала
   3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
   4. Строительно-монтажные работы
   5. Пусконаладочные работы
   6. Проведение предварительных испытаний
   7. Проведение опытной эксплуатации
   8. Проведение приемочных испытаний
8. Сопровождение АС.
   1. Выполнение работ в соответствии с гарантийными обязательствами
   2. Послегарантийное обслуживание

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

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

Стандарт ISO/IEC 12207/ и его применение

Стандарт ISO/IEC 12207:1995 «Information Technology - Software Life Cycle Processes» является основным нормативным документом, регламентирующим состав процессов жизненного цикла ПО. Он определяет структуру жизненного цикла, содержащую процессы , действия и задачи , которые должны быть выполнены во время создания ПО.

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

Процессы жизненного цикла ПО

• Основные:
  • Приобретение (действия и задачи заказчика, приобретающего ПО)
  • Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
  • Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
  • Эксплуатация (действия и задачи оператора - организации, эксплуатирующей систему)
  • Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение - внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
• Вспомогательные
  • Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
  • Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
  • Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)
  • Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
  • Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
  • Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
  • Аудит (определение соответствия требованиям, планам и условиям договора)
  • Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
• Организационные
  • Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
  • Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
  • Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
  • Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:

1. Инициирование приобретения
2. Подготовка заявочных предложений
3. Подготовка и корректировка договора
4. Надзор за деятельностью поставщика
5. Приемка и завершение работ

Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:

1. Формирование требований к системе
2. Формирование списка программных продуктов
3. Установление условий и соглашений
4. Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

1. Стадии;
2. Результаты выполнения работ на каждой стадии;
3. Ключевые события - точки завершения работ и принятия решений.

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

Модели жизненного цикла ПО

Каскадная модель

Каскадная модель жизненного цикла («модель водопада» , англ. waterfall model ) была предложена в 1970 г. Уинстоном Ройсом . Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
5. Внедрение;
6. Эксплуатация и сопровождение.

Спиральная модель

Спиральная модель (англ. spiral model ) была разработана в середине 1980-х годов Барри Боэмом . Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

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

Один из примеров реализации спиральной модели - RAD (англ. Rapid Application Development , метод быстрой разработки приложений).

В общем случае программная система помимо собственно программ содержит еще и аппаратное обеспечение, а также обычно рассматривается в окружении других программно-аппаратных систем.

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

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

Этапы жизненного цикла ПО

Жизненный цикл программного обеспечения - период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы: -1- возникновение и исследование идеи; -2- анализ требований и проектирование; -3- программирование; -4- тестирование и отладка; -5- ввод программы в действие; -6- эксплуатация и сопровождение; -7- завершение эксплуатации.

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

Примеры описания жизненного цикла

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

В отечественных нормативных документах (например, ГОСТ ЕСПД) принято следующее разграничение на этапы, которое приводится с указанием аналогий из списка, данного в начале раздела:

разработка технического задания (этапы 1 и 2);

технический проект (третий этап до 3.2.1 включительно);

рабочий проект (3.2.2, 4.2.1 и, частично, 4.2, 4.3);

экспериментальное внедрение (4.2 и 4.3);

сдача в промышленную эксплуатацию (этап 5);

промышленная эксплуатация (этап 6).

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

Рис. 1.1 Пример жизненного цикла программных систем

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

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

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

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

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

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

Кодирование и тестирование программного обеспечения (4.1.1 и 4.1.2). Создание, тестирование отдельных модулей, документирование и приемка программных компонентов, которые составляют программную систему.

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

Интеграция системы (4.3). Тестирование работоспособности и функциональной законченности частей общей системы в целом.

Приемка и поставка системы (5). Производится приемка системы заказчиком, и поставка ему системы.

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

Завершение проекта (7). Формирование посториорной модели проектных действий с анализом достоинств, недостатков и т.д., и использование их в качестве основания для улучшения процесса разработки.

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

этап планирования, который определяет и координирует действия по разработке программной системы (этап 1);

этап разработки, на котором создается программная система:

постановку задачи (этап 2),

проектирование (3),

кодирование (4.1.1),

получение исполняемого кода (4.1.1, 4.3);

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

Рис. 1.2 Вариант упрощенного жизненного цикла программной системы.

Отсутствие интегрированного этапа в обобщенном жизненном цикле не означает, что проверка производится только там, где это явно указано в названии этапа (например 4.2.1 и 4.2). Каждый этап может считаться завершенным только тогда, когда результаты, полученные на данном этапе, были признаны удовлетворительными, а для этого необходимо производить проверку результатов на каждом этапе. В обобщенном жизненном цикле некоторые проверки были вынесены отдельными пунктами для демонстрации повышенных объемов, сложности и важности этих проверок.

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

На рис. 1.3. показана последовательность этапов разработки программного обеспечения для отдельных компонентов единой программной системы с различными жизненными циклами.

Рис. 1.3 Последовательность этапов разработки компонент программного обеспечения

Для компонента W из множества системных требований к единому продукту формируется подмножество требований, относящихся к данному компоненту, используются эти требования при формировании проекта программного компонента, реализовывают этот проект в исходном коде и тогда интегрирует компонент с аппаратурой. Компонент X показывает использование ранее разработанного программного обеспечения. Компонент Y показывает использование простой отдельной функции, которая может быть закодирована прямо на основе требований к программному обеспечению. Компонент Z показывает использование прототипной стратегии. Обычно, целями прототипирования является лучшее понимание требований к программному обеспечению и уменьшение технических рисков и рисков разработки при создании конечного продукта. Исходные требования используются как базис для получения прототипа. Этот прототип преобразуется в окружение, типичное для конкретного использования системы при разработке. Результатом преобразований является уточненные данные, которые используются для создания конечного программного продукта.

Практически все этапы жизненного цикла объединяются с верификацией.

Источник нашей мудрости - наш опыт, источник нашего опыта - наша глупость.

Саша Гитри, французский актер, режиссер

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

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

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

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

1.1. Общее описание жизненного цикла

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

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

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

На данный момент можно выделить следующие часто упоминаемые и используемые модели жизненного цикла:

• каскадная модель;
• процессная или поэтапная модель с промежуточным контролем;
• итерационная модель.

1.2. Каскадная модель

Каскадная модель (или, как ее еще называют, водопадная) (рис. 1.1) рассматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Эта модель происходит от структуры диаграммы Ганта для поэтапного процесса. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Модель подчеркивает, что результаты, полученные в ходе выполнения одного этапа, используются для выполнения следующего этапа.

Рис. 1.1.

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

Одним интересным вариантом развития поэтапной модели является V-образный жизненный цикл (рис. 1.3). В этой модели акцент делается на работы, связанные с верификацией документов разработки. Нисходящая ветвь модели описывает собственно разработку программной документации: требования к ПО, функции программных элементов, архитектуру - связи программных функций, программный код. Восходящая ветвь - этапы верификации.

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

Рис. 1.3.