Подходы к проектированию информационных систем, страница 2

Процесс обеспечения качества (quality assurance process) – процесс обеспечения соответствующих гарантий того, что ПО и процессы его ЖЦ соответствуют заданным требованиям и утверждённым планам

•  Качество ПО – совокупность свойств, которые характеризуют способность ПО удовлетворять заданным требованиям

Процессы верификации и аттестации

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

Процесс аттестации (validation process) – процесс определения полноты соответствия заданных требований и созданной системы или программного продукта их конкретному функциональному назначению

•  Аттестация – подтверждение и оценка достоверности проведённого тестирования ПО

Процесс совместной оценки

Процесс совместной оценки (joint review process) – предназначен для оценки состояния работ по проекту и ПО, создаваемого при выполнении данных работ (действий), сосредоточен на контроле планирования и управления ресурсами, персоналом, аппаратурой и инструментальными средствами проекта

Процесс инфраструктуры

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

Процесс усовершенствования

Процесс усовершенствования (improvement process) - оценка, измерение, контроль и усовершенствование процессов ЖЦ ПО

Модель ЖЦ ПО

•  Модель ЖЦ ПО – структура, определяющая последовательность выполнения и взаимосвязей процессов, действий и задач на протяжении ЖЦ

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

–  Стадии (phases)

–  Результаты выполнения работ на каждой стадии (deliverables)

–  Ключевые события - точки завершения работ и принятия решений (milestones)

•  Модель ЖЦ ПО определяет временные рамки, фазы процесса, чем начинается и чем заканчивается процесс

•  Стандартной модели ЖЦ ПО нет, существуют различные модели, попадающие под различные квалификационные признаки

Термины модели ЖЦ ПО

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

•  Процесс создания ПО – совокупность упорядоченных по времени, взаимосвязанных и объединённых в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям

Модель «чёрного ящика»

•  Модель, как таковая отсутствует “code and fix”

 

Стадии ЖЦ ПО

•  Анализ осуществимости проектных решений

•  Планирование и формирование требований к ПО

•  Проектирование системы

•  Детальное проектирование

•  Кодирование

•  Интеграция

•  Внедрение

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

ЖЦ ПО согласно ГОСТ 34

•  Формирование требований к АС

•  Разработка концепции АС

•  Техническое задание

•  Эскизный проект

•  Технический проект

•  Рабочая документация

•  Ввод в действие

•  Сопровождение АС

ЖЦ ПО согласно Oracle

•  Стратегия (определение требований)

•  Анализ (формулирование детальных требований)

•  Проектирование (детальные спецификации)

•  Реализация (написание и тестирование приложений)

•  Внедрение

•  Эксплуатация

ЖЦ ПО согласно Rational

•  Начальная стадия (Inception)

•  Разработка (Elaboration)

•  Конструирование (Construction)

•  Ввод в действие (Transition)

Водопадная модель ЖЦ ПО

Принципы «чистого» водопадного подхода

•  Фиксация требований к системе до её сдачи заказчику

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

Преимущества

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

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

Результаты применения водопадной модели

Недостатки водопадной модели

•  Позднее обнаружение проблем

•  Выход из календарного графика, запаздывание с получением результатов

•  Избыточное количество документации

•  Невозможность разбить систему на части (весь продукт разрабатывается один раз)

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

Выход из положения – итерационный подход

Спиральная модель ЖЦ ПО

Особенности спиральной модели

•  Заказчик постоянно участвует в процессе разработки

•  Идентификация и анализ риска на каждой итерации

•  Назначение приоритетов пользовательским требованиям

•  Разработка последовательности прототипов, начиная с требований наивысшего приоритета