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

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

ЖЦ ПО и его стандарты Жизненный цикл ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Стандарты ЖЦ ПО: Международный стандарт ISO/IEC 12207. Oracle Unified Method (OUM). ГОСТ 34. Rational Unified Process (RUP).

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

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

Oracle Unified Method (OUM) ЖЦ формируется из определенных фаз проекта и процессов, каждый из которых выполняется в течение нескольких фаз. Фазы проекта: Начальная фаза (Inception) – определяются и согласуются цели проекта между всеми заинтересованными сторонами; Разработка требований (Elaboration) – детализация требований, определенных на начальной фазе, создание прототипов, разработка архитектуры системы; Конструирование (Construction) – разработка первого выпуска прикладной системы на основе стандартных и разработанных компонентов, тестирование системы, подготовка системы для испытания, развертывания и приемки; Переход к эксплуатации системы (Transition) - установка новой прикладной системы, подготовка к началу эксплуатации; Эксплуатация системы (Production) - поддержка и слежение за приложением, планирование будущих функциональных расширений.

Процессы OUM Управление проектом (Project Management). Бизнес-требования (Business Requirements). Анализ требований (Requirements Analysis). Отображение и настройка (Mapping and Configuration) – проверка прототипа системы на соответствие бизнес требованиям. Анализ (Analysis ). Проектирование (Design). Разработка (Implementation). Тестирование (Testing). Управление производительностью (Performance Management). Техническая архитектура (Technical Architecture). Конвертация и перенос данных (Data Acquisition and Conversion). Документация (Documentation). Управление изменениями (Organizational Change Management). Обучение (Training). Переход к эксплуатации (Transition). Эксплуатация и поддержка (Operations and Support).

Фазы и процессы OUM

Стандарты ГОСТ34 Стандарты предусматривают стадии и этапы выполнения работ по созданию автоматизированной системы (АС), но не предусматривают сквозных процессов в явном виде. Cтандарты: ГОСТ 34.601-90 (Стадии создания АС) ГОСТ 34.602-89 (ТЗ на создание АС) Методические указания РД 50-34.698-90 (Требования к содержанию документов).

ГОСТ 34 Стандарт ГОСТ 34 имеет несколько стадий разработки автоматизированной системы: ФТ - Формирование требований к АС. РК - Разработка концепции АС. ТЗ - Техническое создание АС. ЭП - Эскизный проект. ТП - Технический проект. РД - Рабочая документация. ВД - Ввод в действие. СП - Сопровождение АС. Каждая стадия состоит из нескольких этапов.

Требования, концепции и ТЗ 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. Послегарантийное обслуживание.

Унифицированный процесс Процесс разработки программного обеспечения (Software Engineering Process, SEP) определяет кто ведет разработку, какие работы выполняются и что является их результатом, в какой последовательности идет разработка. Унифицированный процесс (UP) - это SEP от авторов UML. Для него нет стандарта. Унифицированный процесс Rational Unified Process (RUP) - это коммерческий вариант UP, созданный компанией Rational Software. В 2003 году компания Rational вошла в состав компании IBM. В RUP определены временные стадии (фазы) разработки проекта и выполняемые работы.

Rational Unified Process. Временные стадии работы над проектом Начало – определение общей идеи проекта. Уточнение – планирование необходимых работ и ресурсов. Конструирование – построение продукта с помощью разработки серии последовательных версий. Переход – поставка продукта пользователю (производство, распространение, обучение).

Rational Unified Process. Работы, выполняемые при разработке проекта. Деловое моделирование – определение необходимых возможностей системы и потребностей пользователей. Требования – описание общих требований к системе. Анализ и проектирование – описание проекта системы. Выполнение (реализация) – разработка программных модулей. Испытание (тестирование) – проверка функционирования системы. Развертывание (внедрение) – поставка системы конечному пользователю.

Rational Unified Process

Модели жизненного цикла ПО Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. Основные модели ЖЦ: каскадная модель (70-85 г.г.); спиральная модель (86-90 г.г.).

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

Планируемая разработка

Реальная разработка

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

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

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

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