Тема 3 Модели ЖЦ ПО

Модели жизненного цикла
программного обеспечения
Содержание
Немного терминологии
Понятие модели жизненного цикла
программного обеспечения
Стадии модели ЖЦ ПО
Виды моделей ЖЦ ПО
Методологии разработки ПО
Литература
Модель ЖЦ ПО
Под моделью ЖЦ ПО понимается
структура, определяющая
последовательность выполнения и
взаимосвязи процессов, действий и
задач на протяжении ЖЦ.
Модель ЖЦ зависит от специфики,
масштаба и сложности проекта и
специфики условий, в которых
система создается и функционирует.
Технология проектирования ПО
Технология проектирования ПО
определяется как совокупность
технологических операций
проектирования в их
последовательности и взаимосвязи,
приводящая к разработке проекта
ПО.
Технология проектирования ПО
Требования к технологии проектирования
ПО:
соответствие стандарту ISO/IEC 12207 ;
гарантированное достижение целей
разработки в рамках установленного
бюджета, с заданным качеством и в
установленное время;
возможность декомпозиции проекта на
составные части, разрабатываемые
группами исполнителей ограниченной
численности (3-7 человек), с последующей
интеграцией составных частей;
Технология проектирования ПО
Требования к технологии проектирования
ПО:
минимальное время получения
работоспособного ПО;
независимость получаемых проектных
решений от средств реализации (СУБД,
операционных систем, языков и систем
программирования);
поддержка комплексом согласованных
CASE-средств, обеспечивающих
автоматизацию процессов, выполняемых
на всех стадиях ЖЦ.
Технология проектирования ПО
Стандарты технологии
проектирования:
Стандарт проектирования;
Стандарт оформления проектной
документации;
Стандарт интерфейса конечного
пользователя.
Memoд проектирования ПО
Memoд проектирования ПО
представляет собой организованную
совокупность процессов создания
ряда моделей, которые описывают
различные аспекты разрабатываемой
системы с использованием четко
определенной нотации
Memoд проектирования ПО
Метод определяется как совокупность
следующих составляющих:
концепций и теоретических основ;
нотаций, используемых для
построения моделей статической
структуры и динамики поведения
проектируемой системы;
процедуры, определяющей
практическое применение метода.
Модель ЖЦ ПО
Крайний случай – модель «черного
ящика» (отсутствие какой-либо модели,
“code and fix”)
Спецификации
системы
Разработка
ПО
Программный
продукт
Модель ЖЦ ПО
Стадии в модели «черного ящика»
Начало проекта
Безудержный энтузиазм
Разочарование
Хаос
Поиски виновных
Наказание невиновных
Награждение непричастных
Определение требований к системе
Модель ЖЦ ПО
Состав стадий полного ЖЦ ПО1 :
Анализ осуществимости проектных решений
Планирование и формирование требований к ПО
Проектирование системы
Детальное проектирование
Кодирование
Интеграция
Внедрение
и сопровождение
1Эксплуатация
Боэм Б.У. Инженерное
проектирование программного
обеспечения. М.: Радио и связь, 1985
Модель ЖЦ ПО
Другие подходы:
Гост 34
• Формирование
требований к АС
• Разработка концепции
АС
• Техническое задание
• Эскизный проект
• Технический проект
• Рабочая документация
• Ввод в действие
• Сопровождение АС
Oracle
• Стратегия (определение
требований)
• Анализ
(формулирование
детальных требований)
• Проектирование
(детальные
спецификации)
• Реализация (написание
и тестирование
приложений)
• Внедрение
• Эксплуатация
Rational
• Начальная стадия
(Inception)
• Разработка
(Elaboration)
• Конструирование
(Construction)
• Ввод в действие
(Transition)
Состав модели ЖЦ ПО
В состав модели ЖЦ ПО входят следующие
стадии:
1. Формирование требований к ПО.
2.
Проектирование.
3.
Реализация.
4.
Тестирование.
5.
Ввод в действие.
6.
Эксплуатация и сопровождение.
7.
Снятие с эксплуатации.
Формирование требований к ПО
Стадия формирования требований к ПО
включает следующие этапы:
планирование работ;
проведение обследования деятельности
автоматизируемого объекта (организации);
построение моделей деятельности
организации:
• модели "AS-IS" ("как есть");
• модели "ТО-ВЕ" ("как должно быть").
Стадия проектирования
Стадия проектирования включает
следующие этапы:
разработка системного проекта;
разработка технического проекта.
Стадия реализации
Стадия реализации включает
разработку и изготовление продукта
с требуемыми характеристиками, в
требуемом объеме и в требуемые
сроки.
Стадия тестирования
Стадия тестирования включает
проверку соответствия
разработанной программы
заявленным требованиям:
 тестирование
 сертификация
Стадия ввода в действие
Стадия ввода в действие включает
следующие этапы:
подготовка производства и персонала
к использованию программы;
адаптация программы к особенностям
ее использования.
Стадия эксплуатации и
сопровождения
Стадия эксплуатации и сопровождения
определяет следующие действия:
Эксплуатация программы в производстве
Помощь пользователям, выявление и
разрешение проблем, связанных с
использованием программы
Эксплуатация
Разработка
Сопровождение
Стадия снятия с эксплуатации
Стадия снятия с эксплуатации определяет
следующие действия:
прекращение использования ПС;
архивация или утилизация системы и ее
компонентов
Классификация моделей ЖЦ ПО
Модели ЖЦ ПО
Каскадная
Итерационная
Каскадная модель (waterfall model)
Формирование
требований к ПО
Конференция
NATO
Проектирование
1968г.
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение
Каскадная модель
Особенности каскадной модели:
Фиксированный набор стадий
Каждая стадия -> законченный результат
Стадия начинается, когда закончилась предыдущая.
Недостатки: негибкость
фаза д.б. закончена, прежде чем приступить к
следующей
Набор фаз фиксирован
Тяжело реагировать на изменения требований
Использование: там, где требования хорошо
понятны и стабильны.
Модель с промежуточным контролем
Формирование
требований к ПО
Уинстон Ройс
1970г.
Проектирование
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение
V-образная модель
Итерационный подход
Требования всегда меняются в ходе
разработки.
Важна возможность выполнения итераций,
результатом которых является прототип
продукта с частичной функциональностью.
Это достигается в итерационных моделях.
Итерационный подход
Итерация – последовательность работ
в рамках утвержденного плана,
приводящая к созданию
работоспособного варианта ПО
(релиза)
Итерации – реализация одного или нескольких
функциональных требований
(вариантов использования)
Итерационный подход
Под прототипом понимается
действующий программный
компонент, реализующий отдельные
функции и внешние интерфейсы
разрабатываемого ПО
Инкрементная модель ЖЦ
Эволюционная модель
Эволюционная модель
Особенности эволюционной модели:
Стадии повторяются неоднократно.
Сначала
для
плохо
сформулированных
требований
выполняется весь цикл работ по созданию работающего
прототипа. Потом уточняются требования и все повторяется...
На
выходе
–
продукт,
отвечающий
пользователей.
Недостатки:
Система часто плохо структурирована
Проект «не прозрачен»
Требуются средства для быстрой разработки
Подходит для малых и средних проектов
потребностям
Модель пошаговой разработки
Модель пошаговой разработки (Миллс):
Шаги. Каждый шаг – работающий прототип.
Наиболее важные для заказчика компоненты – в начале.
Требования фиксированы во время шага.
Для шага можно применять каскадную или эволюционную модель.
План требований
Шаг разработки
Детализация
требований
Архитектура
системы
Шаг аттестации
Система не готова
Аттестация
системы
Шаг сборки
СИСТЕМА
Спиральная модель
Определение целей,
альтернатив и
ограничений
Барри Боэм
1988г
Идентификация и разрешение
рисков, оценка альтернатив
Анализ риска
Прототипирование
начало
Анализ
требований
Планирование
следующей
итерации
П
ро
ду
к
т
Проектирование
Кодирование и
тестирование
Разработка продукта на
очередной итерации
Спиральная модель
Особенности спиральной модели:
Вместо действий с обратной связью – спираль.
Каждый виток спирали соответствует 1 итерации.
Нет заранее фиксированных фаз. В зависимости от потребностей.
Каждый виток разбит на 4 сектора:
Определение целей
Оценка и разрешение рисков
Разработка и тестирование
Планирование
Главное отличие: акцент на анализ и преодоление
рисков.
На каждом витке могут применяться разные модели процесса
разработки ПО.
Итеративная модель
Филлип Кратчен
1995г
Итеративная модель
Вопросы
Что такое методология?
Версии зала...
Введение в методологию
Методология – принципы и способы
организации теоретической и практической
деятельности.
Совокупность
методов,
применяемых в какой-либо науке.
Для проектирования ПО
сформулируем так:
Методология есть методы,
принципы и способы
организации деятельности
проектной группы для создания
программного средства.
Методологии разработки ПО
RAD (Rapid Application Development)
Быстрая разработка
Rational Unified Process (RUP).
Microsoft Solution Framework (MSF)
Extreme
Programming
(XP).
Экстремальное
программирование
(самая новая среди рассматриваемых
методологий)
Быстрая разработка RAD
(Rapid Application
Development).
Модель RAD (Rapid
Application Development).
Метод быстрой разработки
приложений. Подходов к разработке
прикладного ПО в рамках спиральной
модели ЖЦ.
Метод основан на последовательной
итерации эволюционной системы или
прототипов, которые анализируются
совместно с заказчиком.
Составляющие RAD
небольшие группы разработчиков (от 3 до
7 человек), выполняющих работы по
проектированию отдельных подсистем ПО;
короткий, но тщательно проработанный
производственный график (чаще 60 дней,
до 3 месяцев);
повторяющегося цикла, при котором
разработчики по мере того, как
приложение начинает обретать форму,
запрашивают и реализуют в продукте
требования, полученные в результате
взаимодействия с заказчиком.
Модель RAD
Планирование требований
Пользовательское описание
Конструирование
Перевод на новую систему эксплуатации
Модель RAD
Планирование требований – структурный
анализ и обсуждение с заказчиком
реализуемых коммерческих задач;
Пользовательское описание – сбор
пользовательской информации и
построение моделей процессов
предметной области с использованием
автоматизированных инструментальных
средств при активном участии заказчика;
Модель RAD
Конструирование – выполняется
детализованное проектирование,
включающее разработку
(кодирование и тестирование)
системы, а также поставка
программного продукта заказчику;
Перевод на новую систему
эксплуатации – проведение
совместно с заказчиком приемочных
испытаний, установка системы и
обучение пользователей.
RUP (Rational Unified
Process)
Rational Unified Process
Фирма Rational Software, разработавшая язык
UML, предложила свою модель жизненного цикла,
которая называется Rational Objectory Process.
Основные свойства данной технологии:
процесс итеративный, т.е. происходит
последовательное уточнение результатов,
действия процесса направлены на создание
моделей, а не других элементов проекта,
например, текстовых документов,
действия жизненного цикла определяются в
первую очередь блоками использования (use
case).
Основные принципы RUP
Снижение риска (итерационный подход к
созданию ПО)
Выполнению требований заказчиков
(планирование и управление проектом на основе
требований)
Построение системы на базе компонентной
архитектуры ПО
Визуальное моделирование
Обеспечение высокого качество (упреждающее
тестирование)
Управление изменениями
Rational Unified Process
Жизненный цикл разбит на циклы,
результатом каждого из которых
является собственная версия
программной системы. Каждый цикл
состоит из четырех фаз:
Начало ( Inception )
Исследование\Совершенствование
( Elaboration )
Построение ( Construction )
Внедрение\Переход ( Transition )
Rational Unified Process
Построение
MSF (Microsoft Solutions
Framework)
Методология MSF
MSF – методология разработки
программного
обеспечения
от
компании Microsoft, опирающаяся на
практический опыт компании и
описывающая управление людьми и
управление процессами в ходе
разработки решения.
Методология MSF
Предлагает максимально облегченный и гибкий подход к
процессу разработки.
Другой пример подобных методологий - Extreme
Programming (XP).
Agile направление в MSF ориентируется на небольшие
команды (5-6 человек).
Предполагает, что информация о разрабатываемом
продукте не просто выясняется в процессе разработки, а
может и будет изменяться по ходу.
Таким образом, первая рабочая версия системы должна
быть создана как можно раньше, а сам продукт фактически
проявляется из прототипов путем повторения итераций в
цикле разработки.
Microsoft Solutions Внедрение
Framework
(MSF) завершено
Deployment
Complete
Готовность
решения
утверждена
Release
Readiness
Approved
Vision/Scop
e Approved
MSF
Scope
Complete
Разработка
завершена
Концепция
проекта
утверждена
Project
Plans
Approved
Планы
проекта
утверждены
Фаза выработки концепции
Широко описывает
цели проекта и ограничения
(Envisioning)
Deployment
Complete
Core Team Organized
Vision/Scope Baseline
Create
Vision/Scop
e
Approved
•
Ключевые точки
–
–
–
Общее описание и рамки проекта (Vision/Scope);
Описание структуры проекта (Project Structure);
Начальная оценка рисков (risk assessment).
Фаза планирования (Planning)
Определяет, что разрабатывает и как разрабатывает
Vision/Scop
e
Approved
Technology Validation Complete
Functional Specification Baselined
Master Project Plan Baselined
Master Project Schedule Baselined
Development/ Test Environment Set Up
Project
Plans
Approved
•
Ключевые точки
–
–
–
Функциональная спецификация;
План управления рисками;
Сводный план и календарный план график.
Фаза разработки (Developing)
Создается решение
Project
Plans
Approved
Scope
Complete
Proof-of-Concept Complete
Internal Release 1
Internal Release 2
Internal Release n
•
Ключевые точки
–
–
–
–
Исходный код;
Исполняемые файлы;
Установочные скрипты;
Настройки конфигурации;
–
–
–
Окончательна функц. спецификация;
Материалы поддержки решения;
Спецификации и сценарии тестов.
Фаза стабилизации (Stabilizing)
Интегрированное нагрузочное тестирование
Release Readiness
Approved
Pilot Complete
Pre-production Testing Complete
Release Candidates
User Acceptance Testing Complete
Zero Bug Release
Bug Convergence
Scope
Complete
•
Ключевые точки
–
–
–
Окончательный продукт;
Документация выпуска;
Материалы поддержки;
–
–
–
–
Результаты тестирования;
Исходный и исполняемый код;
Проектная документация;
Анализ пройденной фазы.
Фаза внедрения (Deploying)
Внедрение решения
Deployment Stabilized
Deployment
Complete
Site Deployment Complete
Core Technology Deployed
Release
Readiness
Approved
•
Ключевые точки
–
–
–
Информационные системы;
Все проектные документы;
Массивы данных;
–
–
–
Процедуры и процессы;
Скрипты и код;
Отчет о завершении проекта.
Основные особенности подхода Microsoft
начальная разработка концепции (vision statement), выбор
возможностей и определение их приоритетов на основе запросов
пользователей
пошаговое наращивание функциональных возможностей продукта
много небольших команд разработчиков (3-8 человек, параллельно
работающих над продуктом
частая синхронизация изменений
полная сборка очередного релиза к концу дня с помощью средств
управления конфигурацией (“daily build”)
немедленная фиксация дефектов в каждом релизе и их устранение
всестороннее внутреннее и внешнее тестирование (бетатестирование)
3 или 4 контрольные точки стабилизации продукта в течение
цикла разработки
Результат – создание “good enough” продукт для массового
рынка с последующим совершенствованием и поставкой
Экстремальное
программирование
Терминология
Экстрема́ льное программи́ рование
(XP)— одна из гибких методологий
разработки программного обеспечения.
Авторы методологии — Кент Бек, Уорд
Каннингем, Мартин Фаулер.
Гибкая методология разработки — это
концептуальный каркас, в рамках которого
выполняется разработка программного
обеспечения.
Основные приёмы XP
Двенадцать основных приёмов
экстремального программирования могут
быть объединены в четыре группы:
Короткий цикл обратной связи
Непрерывный, а не пакетный процесс
Понимание, разделяемое всеми
Социальная защищенность программиста
Основные приёмы XP
Короткий цикл обратной связи (Fine
scale feedback):
Разработка через тестирование (Test driven
development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite
customer)
Парное программирование (Pair
programming)
Основные приёмы XP
Непрерывный, а не пакетный процесс:
Непрерывная интеграция (Continuous
Integration)
Рефакторинг (Design Improvement, Refactor)
Частые небольшие релизы (Small Releases)
Основные приёмы XP
Понимание, разделяемое всеми:
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective
code ownership) или выбранными шаблонами
проектирования (Collective patterns
ownership)
Стандарт кодирования (Coding standard or
Coding conventions)
Основные приёмы XP
Социальная защищенность
программиста (Programmer welfare):
40-часовая рабочая неделя (Sustainable
pace, Forty hour week)
Этапы ЖЦ в соответствии с
ГОСТ 19.102-77
Стадии
разработки
Техническое
задание
Этапы работ
Содержание работ
Обоснование
необходимости
разработки программы
Постановка задачи.
Сбор исходных материалов.
Выбор и обоснование критериев эффективности и качества разрабатываемой
программы.
Обоснование необходимости проведения научно-исследовательских работ.
Научно-исследовательские
работы
Определение структуры входных и выходных данных.
Предварительный выбор методов решения задач
Обоснование целесообразности применения ранее разработанных программ.
Определение требований к техническим средствам.
Обоснование принципиальной возможности решения поставленной задачи.
Разработка
и
утверждение
технического задания
Определение требований к программе.
Разработка технико-экономического обоснования разработки программы.
Определение стадий, этапов и сроков разработки программы и документации на
нее.
Выбор языков программирования.
Определение необходимости проведения научно-исследовательских работ на
последующих стадиях.
Согласование и утверждение технического задания.
Разработка эскизного проекта
Предварительная разработка структуры входных и выходных данных.
Уточнение методов решения задачи.
Разработка общего описания алгоритма решения задачи.
Разработка технико-экономического обоснования.
Утверждение эскизного проекта
Разработка
пояснительной
Согласование и утверждение эскизного проекта
Эскизный проект
записки.
Этапы ЖЦ в соответствии с
ГОСТ 19.102-77
Стадии
разработки
Технический
проект
Этапы работ
Содержание работ
Разработка
проекта
технического
Уточнение структуры входных и выходных данных.
Разработка алгоритма решения задачи.
Определение формы представления входных и выходных данных.
Определение семантики и синтаксиса языка.
Разработка структуры программы.
Окончательное определение конфигурации технических средств.
Утверждение
проекта
технического
Разработка программы
Программирование и отладка программы
Разработка
документации
Разработка программных документов в соответствии с требованиями ГОСТ
19.101-77.
программной
Рабочий проект
Внедрение
Разработка плана мероприятий по разработке и внедрению программ.
Разработка пояснительной записки.
Согласование и утверждение технического проекта.
Испытания программы
Разработка, согласование и утверждение программы и методики испытаний.
Проведение предварительных государственных, межведомственных, приемосдаточных и других видов испытаний.
Корректировка программы и программной документации по результатам
испытаний.
Подготовка
программы
Подготовка и передача программы и программной документации для
сопровождения и (или) изготовления
Оформление и утверждение акта о передаче программы на сопровождение и
(или) изготовление.
Передача программы в фонд алгоритмов и программ.
и
передача
ГОСТ 19.102-77
Стадии Постановка
Этапы работ
Содержание
задачи.
работ
разраСбор исходных материалов.
ботки
Выбор
и обоснование критериев
Постановка задачи.
Обоснование
ТехниСбор исходных материалов.
эффективности
и качества
разрабатываемой
необходимости разработки
Выбор
и обоснование критериев
Определение
требований
к
программе.
ческое
программы.
эффективности и качества
программы
программы.
Определение структуры входныхразрабатываемой
и выходных
данных.
задание
Разработка технико-экономического
обоснования
Обоснование необходимости
Обоснование необходимости
проведения
Предварительный
выбор методов
решения
задач
проведения
научноразработки
программы.
исследовательских
научно-исследовательских
работ. работ.ранее
Обоснование целесообразности
применения
Определение структуры входных и
Научно-исследовательские
Определение
стадий,
этапов и программ.
сроков
разработанных
выходных разработки
данных.
Предварительный выбор методов
программы
и документации
нее.
работы
Определение
требований на
к техническим
средствам.
решения задач
Обоснование целесообразности
Обоснование
принципиальной
возможности
решения
ранее разработанных
Выбор языков программирования.применения
программ.
поставленной задачи.
Определение требований к программе.
Разработка
и утверждение
Определение
необходимости
проведения
научноРазработка технико-экономического
обоснования разработки программы.
техническогоработ
задания
исследовательских
на последующих
стадиях.
Согласование и утверждение технического задания.
ГОСТ 19.102-77
Стадии
Этапы работ Содержание работ
разработк
и
Предварительная разработка структуры
Предварительная
разработка
Эскизный Разработка
входных и выходных данных.
Уточнение
методов решения задачи.
структуры входных
и выходных
проект
эскизного
Разработка общего описания алгоритма
данных.
решения задачи. Разработка техникопроекта
экономического обоснования.
Уточнение методов
решения
задачи.
Разработка
пояснительной
записки.
Утверждение Согласование и утверждение эскизного
Разработка общего описания
эскизного
проекта
алгоритма пояснительной
решения задачи.
Разработка
записки.
проекта
Разработка технико-экономического
Согласование
и утверждение эскизного
обоснования.
проекта
ГОСТ 19.102-77
Стадии
разработки
Этапы работ
Содержание
работ
Уточнение структуры входных и выходных
Технический
данных. Разработка
алгоритма решения задачи.
проект Разработка
технического
Определение
формы представления
проекта
входных и выходных данных.
Разработка плана мероприятий
по разработке и внедрению
Утверждение
Определение
семантики и синтаксиса
программ.
Разработка пояснительной
технического
языка. плана
Разработка
мероприятий по
разработке и
записки.
Согласование и утверждение
проекта
Разработка
структуры программы.
внедрению
программ.
технического проекта.
Окончательное определение конфигурации
Разработка пояснительной записки.
технических средств.
Согласование и утверждение технического проекта.
Уточнение структуры входных и выходных
данных.
Разработка алгоритма решения задачи.
Определение формы представления входных и
выходных данных.
Определение семантики и синтаксиса языка.
Разработка структуры программы.
Окончательное определение конфигурации
технических средств.
ГОСТ 19.102-77
Стадии
разработки
Этапы работ
Содержание работ
Рабочий
проект
Разработка
программы
Программирование
и отладка
программы
Разработка, согласование и утверждение
Разработка программных
Разработка
программы и методики
испытаний.
документов
в соответствии с
программной
требованиями
ГОСТ 19.101-77.
Разработкапредварительных
программных
документов
в
Проведение
документации
соответствии с требованиями
ГОСТ
государственных,
межведомственных,
19.101-77.
приемо-сдаточных
и других видов
Испытания
испытаний.
программы
Разработка, согласование и утверждение программы и
методики испытаний.
Проведение предварительных государственных,
межведомственных, приемо-сдаточных и других видов
испытаний.
Корректировка программы и программной
документации по результатам испытаний.
Корректировка программы и программной
документации по результатам испытаний.
ГОСТ 19.102-77
Стадии
разработки
Внедрение
Этапы
работ
Содержание
Подготовка
и передача
программы и
работ
программной документации
для
Подготовка
и передача программы и
сопровождения
и
(или)
изготовления
Подготовка программной документации для
сопровождения и (или)
Оформление
акта о
и передача и утверждение
изготовления
передаче
программы
на
программы
сопровождение и (или) изготовление.
Передача программы в фонд алгоритмов
и программ.
Литература к лекции
1) Вендров
А.М.
Пректирование
программного
обеспечения
экономических информационных систем
– М: Финансы и статистика, 2005
2) Гусятников
В.Н.,
Безруков
А.И.
Стандартизация
и
разработка
программных систем. - М: Финансы и
статистика, 2010.
3) И. Соммервиль. Инженерия
программного обеспечения, 6 изд. –
И.д. "Вильямс", 2002.