Управление жизненным циклом программы

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

2. Понятие жизненного цикла

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

3.

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

4.

создание и производство;
распространение и продажа;
эксплуатация;
сопровождение и мониторинг;
снятие с эксплуатации (утилизация).
Масштабы программных средств
По особенностям и свойствам жизненного цикла
программ их целесообразно делить на ряд классов и
категорий, из которых наиболее различающимися
являются два крупных класса – малые и большие.
Первый класс составляют относительно небольшие
программы, создаваемые одиночками или небольшими
коллективами (3–5) специалистов, которые:
• создаются преимущественно для получения конкретных
результатов автоматизации научных исследований или
для анализа относительно простых процессов самими
разработчиками

5.

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

6.

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

7.

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

8.

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

9.

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

10. Классификация процессов жизненного цикла по ИСО/МЭК 12207

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

11.

Основные процессы:
• приобретение;
• поставка;
• разработка;
• эксплуатация;
• сопровождение.
Вспомогательные процессы:
• документирование;
• управление конфигурацией;
• обеспечение качества;
• верификация;
• аттестация;
• совместная оценка;
• аудит;
• разрешение проблем.

12.

Организационные процессы:
• управление;
• усовершенствование;
• создание инфраструктуры;
• обучение.
Стадии разработки программных средств по
ЕСПД
Стадии – наиболее укрупненные составляющие
процесса разработки, для завершения которых
характерно получение ПО в определённой стадии
готовности. Эти стадии предусмотрены ГОСТ 19.102-77
ЕСПД.

13.

Согласно этому стандарту выделяют следующие
стадии создания ПС.

14.

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

15.

2. Эскизное проектирование
На данной стадии выполняется:
детализация состава и структуры входной и выходной
информации;
детализация метода решения задач.
На этапе эскизного проектирования нужно создать
предварительную версию программного средства
(возможно
в
виде
модели)
и
выяснить
принципиальные вопросы, устраняя возможные
разногласия между разработчиком и заказчиком. При
этом выполняется:
определение предварительной технологии решения
задачи;
прогнозирование эффективности решения задачи на
конкретном объекте;
ведется
освоение
инструментальных
средств
(апробирование, обучение персонала).
3.Техническое проектирование (технический проект)
На данном этапе:

16.

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

17.

4. Рабочее проектирование (рабочий проект)
Результат рабочего проектирования – получение ПС в
состоянии операционной готовности, в котором
устранены синтаксические и семантические ошибки,
как в программном коде так и в программной
документации.
Основные работы этой стадии:
программная реализация (написание программного
кода, привязка его к специфике конкретного объекта,
адаптация и настройка программных модулей);
отладка (автономная – в лабораторных условиях и
комплексная – на объекте);
разработка эксплуатационной документации;
организация внедрения ПС.
5. Внедрение
На этапе внедрения осуществляют:
подготовку персонала к эксплуатации;

18.

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