Понятие жизненного цикла (ЖЦ). Основные, вспомогательные и организационные процессы

Понятие жизненного цикла (ЖЦ). Основные, вспомогательные и организационные  процессы.

 

Жизненный цикл – это период времени с момента принятия решения о необходимости создания ПО до полного изъятия из эксплуатации.

Основной документ, регламентирующий состав процессов ЖЦ, – стандарт ISO 12207, описывает структуру процессов ЖЦ, но не конкретизирует, как реализовать или выполнить действия и задачи, включенные в эти процессы. Согласно стандарту все процессы разделены на 3 группы:

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

 

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

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

 

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

Стратегии конструирования ПО

 

1. однократный проход
• водопадная стратегия

 

2. итеративный подход

весь ЖЦ проекта - последовательность итераций выпуска версий. После каждой итерации - пересмотр функциональности, сетевых графиков работ, планов, спецификаций, требований и других проектных артефактов. Это позволяет планировать возможности для последующих версий, делать учёт опыта предыдущих циклов, обеспечивая гибкость и устойчивость к переменам требований; обеспечивается ведение «живой» документации, изменяющейся по мере эволюции проекта.

 

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

Стандартные модели ЖЦ. Каскадная схема разработки ПО. Спиральная модель ЖЦ ПО.

 

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

 

Каскадная модель. Первая по времени появления, самая распространенная:

Свойства взаимодействия этапов:

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

Выявление и устранение ошибок – только на стадии тестирования (может растянуться во времени, или вообще никогда не завершиться).

 

Спиральная модель. Пример применения эволюционной стратегии конструирования.

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

Методологии и технологии проектирования ПО. Требования к технологии.

Метод – совокупность приемов или операций для получения искомого результата.

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

 

Технология  проектирования - совокупность трех составляющих:

• пошаговая процедура, определяющая последовательность технологических операций проектирования:

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

 

Технология проектирования, разработки и сопровождения ИС должна:

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

 

Реальное применение любой технологии невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта:

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

Основные этапы разработки. Информационные потоки процесса синтеза ПС

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

В процессе анализа ищется ответ на вопрос «Что должна делать будущая система?»

В процессе синтеза формируется ответ на вопрос «Каким образом система будет реализовывать предъявленные к ней требования?». 3 этапа:

1. проектирование
1. Разработка данных – это результат преобразования информационной модели анализа в структуры данных, которые потребуются для реализации ПС.
2. Разработка архитектуры выделяет основные структурные компоненты и фиксирует связи между ними.
3. Разработка процедур описывает последовательность действий в структурных компонентах, то есть определяет их содержание.
2. кодирование
3. тестирование

Стратегическое  планирование. Бизнес-стратегии.

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

 

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

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

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

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

 

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

 

Проекты по разработке ИС должны быть заранее спланированы. Необходимо получить ответ на вопрос «Какие технологии ИС и приложения принесут наибольшие деловые выгоды?». Решение должно базироваться на бизнес-стратегии и тщательном планировании.

 

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

 

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

Анализ. Модели анализа: информационная, функциональная, поведенческая

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

Анализ:

- анализ требований (исследование требований к системе через ее функции)

- объектный анализ (исследование объектов предметной области).

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

Требования определяют услуги, ожидаемые от системы, и ограничения, которым система должна подчиняться.

 

Анализ требований дает возможность:

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