Tarkvara kvaliteed ja standardid

Tarkvara kvaliteed ja
standardid
Качество и стандарты программного
обеспечения
L.Joonas
2012
Основные темы курса

Понятие качества

Жизненный цикл продукта

Тестирование

Метрики качества

Управление качеством
Понятие качества
Что качественнее – настенные часы или
песочные часы?
Что качественнее ?
Что качественнее ?

Windows Vista или Ubuntu 9.0
ISO 9000:2000 формулирует
понятие качества следующим
образом:

полнота свойств и характеристик
продукта, процесса или услуги,
которые обеспечивают способность
удовлетворять заявленным или
подразумеваемым потребностям
Определение IEEE:

Качество программного обеспечения - это
степень, в которой оно обладает
требуемой комбинацией свойств
Качество



Отвечает специфическим требованиям
(Crosby)
Пригодно к использованию (Juran)
Удовлетворяет клиента
Аспекты качества









Функциональность
Надежность
Соответствие
Прочность, устойчивость
Пригодность к использованию
Удобство
Эстетичность
Этичность
Внешнее восприятие
Аспекты качества программного
продукта








функциональность
годность к употреблению
исполнение
требования к установке
удобство сопровождения
документация/информация
обслуживание
общее удовлетворение
Различные потребители и
среда потребления
Обычные
пользователи
Непользователи,
имеющие отношение к
предмету





Ежедневное использование
для обычных работ
Редкое использование –
специальные копии
Продавец – консультант
Ремонтник –
обслуживание и ремонт



Сотрудники в комнате
Руководство –
цена/прибыль
50 лет программирования :
основные принципы
качества
50 лет программирования:
основные принципы качества

Технологические достижения

Социальные и экономические факторы
50 лет программирования:
основные принципы качества (2)

1950-1959: возникновение
Первыми «компьютерами» были женщины, которых не
брали в армию США.
Компьютеры стали применяться в первую очередь для
оборонных задач.
Простые алгоритмы разрабатывались тщательно
50 лет программирования:
основные принципы качества (3)

1960-1969: выход в свет
Более эффективные компьютеры стали доступны всем.
Высокое качество программ из-за несовершенных способов
компиляции.
Цена небрежности была высока.
50 лет программирования:
основные принципы качества (4)

1970-1979: хаос
Персональные компьютеры и простота компиляции.
Более эффективные способы решения задач.
Программисты стали выдавать ошибки за особенности программ
(«унаследованный код»).
О тестировании попросту забыли.
50 лет программирования:
основные принципы качества (5)




1980-1989: возрождение
CASE-инструментарий (computer aided software engineering)
Языки 4 поколения (4GL)
Формальные методы (сокрытие информации, структурное
программирование и поэтапное улучшение)
50 лет программирования:
основные принципы качества (6)





1990-1999: совершенствование
Capability Maturity Model
(Управление разработкой программного
обеспечения гарантирует получение более качественного продукта)
«Шесть сигма» (Six Sigma) — это дисциплинарный, определяемый данными
подход и методология ликвидации дефектов в любом процессе
CBSE (component-based software engineering — «компонентная разработка
программного обеспечения»)
COTS (commercial off-the-shelf — готовые коммерчески доступные компоненты).
50 лет программирования:
основные принципы качества (5)


С 2000 по 2012 год: инженерия?
уровень ошибок последние двадцать лет практически не
меняется, несмотря на объектно-ориентированную
технологию, автоматические отладчики, более
качественные средства тестирования и более строгий
контроль типов в таких языках, как Java и Ada

«объем экономических потерь из-за
ошибочного программного
обеспечения в США достигает
миллиардов долларов в год и
составляет, по некоторым оценкам,
около 1% национального валового
внутреннего продукта» (Research
Triangle Institute, «The Economic
Impacts of Inadequate Infrastructure for
Software Testing,» NIST Planning
Report 02-3, May 2002).
Метрики качества
программного обеспечения
Когда вы можете измерить то, о чем вы
говорите, и выразить это в числах, вы
знаете кое-что об этом; но если вы не
можете измерить это и выразить в
числах, ваше знание скудно и
неудовлетворительно.
Лорд Кельвин
Введение


универсальные метрики, которые применимы
практически ко всем видам программного
обеспечения
часть наиболее важных метрик в успешных
проектах разрабатывается индивидуально на
основе особенностей проекта и характеристик
предметной области
Понятие качества

Определение ISO: Качество - это полнота свойств и
характеристик продукта, процесса или услуги, которые
обеспечивают способность удовлетворять заявленным или
подразумеваемым потребностям [61].

Определение IEEE: Качество программного обеспечения это степень, в которой оно обладает требуемой
комбинацией свойств [58].
Составляющие качества
информационной системы:

Качество инфраструктуры (infrastructure quality):
качество аппаратного и поддерживающего
программного обеспечения (например, качество
операционных систем, компьютерных сетей и т.п.).

Качество программного обеспечения (software quality):
качество программного обеспечения информационной
системы.

Качество данных (data quality): качество данных,
использующихся информационной системой на входе.
Составляющие качества
информационной системы:

Качество информации (information quality): качество
информации, продуцируемое информационной системой.

Качество административного управления (administrative
quality) – качество менеджмента, включая качество
бюджетирования, планирования и календарного контроля.

Качество сервиса (service quality) – качество обучения,
системной поддержки и т.п.

Анализ всех составляющих качества
должен проводится с учетом сфер
ответственности заинтересованных
сторон, как внутренних участников
исполняемого процесса (in-process
stakeholder), так и пользователей
процесса (end-of-process stakeholders).
Многомерность качества
Жизненный цикл
программного
обеспечения
Введение

В основе любой отрасли промышленного производства, к которым относится и
создание программного обеспечения (ПО) или программных средств (ПС),
лежит технологический процесс.

Большинство характеристик программного продукта - качество, стоимость,
сроки создания, актуальность - непосредственно определяются технологией
разработки и точностью ее соблюдения.

Фирма, занимающаяся производством программного обеспечения, может
преуспевать только в том случае, если выпускаемая ею продукция всегда
отличается высоким качеством и разработана в соответствии с потребностями
пользователей.

Компания, которая способна выпускать такую продукцию своевременно и
регулярно, при максимально полном и эффективном использовании всех
имеющихся человеческих и материальных ресурсов будет стабильно
процветать.
Список элементов качества, на которые
распространяются требования стандартов
ISO 900










Ответственность руководства.
Система качества.
Анализ контракта.
Управление проектированием.
Управление документацией.
Закупки продукции.
Продукция, предоставляемая потребителям.
Идентификация продукции и ее
прослеживаемость.
Управление процессами.
Контроль и проведение испытаний.
Список элементов качества, на которые
распространяются требования стандартов ISO
900 (2)










Контрольное измерительное и испытательное оборудование.
Статус контроля и испытаний.
Управление продукцией, не соответствующей стандарту качества.
Корректирующие и предупреждающие действия.
Погрузочно-разгрузочные работы, хранение, упаковка и поставка.
Регистрация данных о качестве.
Внутренние проверки качества.
Подготовка кадров.
Техническое обслуживание.
Статистические методы.
Группа проекта

Руководитель проекта - координирует все действия, организует внешнее
и внутреннее взаимодействия группы проекта, обеспечивает соблюдение
сроков разработки и качество разрабатываемого ПО и его соответствие
требованиям заказчика, несет полную ответственность за результат
работ по проекту;

Системный аналитик - анализирует требования к системе, разрабатывает
концепцию и логику работы системы, составляет технические задания
или подобные документы, несет ответственность за соответствие
предлагаемых решений требованиям заказчика;
Группа проекта (2)

Разработчики - реализуют принятые технические задания, отвечают за качество и
сроки разрабатываемого кода, за его соответствие техническим заданиям;

Дизайнер - участвует в разработке концепции системы, разрабатывает ее
пользовательский интерфейс и принимает участие в его реализации, несет
ответственность за соблюдение фирменного стиля и требований к реализации
пользовательского интерфейса;

Тестер - разрабатывает программу тестирования, осуществляет ее и несет
ответственность за полноту тестирования готовых модулей и системы в целом;

Технический писатель - разрабатывает документацию на проект, несет
ответственность за полноту и правильность описания.
Жизненный цикл
Жизненный цикл – это «карта-путеводитель» для всех участников проекта.

Модель ЖЦ разработки ПО является единственным видом процесса, в
котором представлен порядок его осуществления.

Под жизненным циклом ПО понимается совокупность процессов,
связанных с последовательным изменением состояния ПО от
формирования исходных требований к нему до окончания его
эксплуатации.

Жизненный цикл состоит из стадий - логически завершенных частей ЖЦ.
Стадии характеризуются определенными состоянием ПО, видом
предусмотренных работ и их результатом.
Структурная схема терминов
Жизненный
цикл ПО
Структура ЖЦ
Основные
процессы ЖЦ
Вспомогательные процессы
Организационные процессы
Модель ЖЦ
Этапы ЖЦ
Каскадная
модель
Спиральная
модель
Жизненный цикл (2)


ISO/IEC 12207 (ISO - International Organization of
Standardization - Международная организация по
стандартизации, IEC - International Electrotechnical
Commission - Международная комиссия по
электротехнике).
Определяет структуру ЖЦ, содержащую процессы,
действия и задачи, которые должны быть выполнены во
время создания систем.
Структура ЖЦ по стандарту ISO/IEC 12207
базируется на трех группах процессов:

основные процессы ЖЦ (приобретение, поставка,
разработка, эксплуатация, сопровождение);

вспомогательные процессы (документирование, управление
конфигурацией, обеспечение качества, аттестация, аудит,
решение проблем);

организационные процессы (управление проектами,
создание инфраструктуры проекта, улучшение самого ЖЦ,
обучение).
Пять основных стадий ЖЦ:





анализ и формализация требований
заказчика;
проектирование;
реализация;
тестирование;
внедрение и эксплуатация.
Типы ЖЦ
два основных типа:
 Последовательный тип
 Эволюционный тип
Последовательный тип
Данный тип ЖЦ предполагает, что каждая следующая стадия
может быть начата только после завершения работ на предыдущей
стадии. Он применим тогда, когда:



требования к продукту четко определены и не меняются со
временем;
имеется достаточно большой опыт реализации подобного рода
систем;
время реализации проекта составляет от нескольких месяцев до
года.
В реальности в последнее время этот тип жизненного цикла
практически никогда не применяется.
Эволюционный тип

Функциональные возможности системы в данном случае
наращиваются постепенно. В процессе разработки основные
стадии ЖЦ (проектирование, реализация, тестирование)
проходятся несколько раз применительно к очередной
добавляемой порции возможностей системы.

Данный тип ЖЦ не требует заранее наличия всех требований к
системе и позволяет заказчику активно участвовать в ее
разработке.

Минусы:
сложность в управлении и контроле выполнения проекта;
сложность оценки затрат на разработку;
риск бесконечного улучшения системы.



Выбор типа жизненного
цикла





Выбор конкретного типа жизненного цикла зависит от ряда
субъективных и объективных причин, сопутствующих проекту:
наличия четких и подробных требований к ПО;
ресурсов, имеющихся в наличии для проведения работ по проекту;
наличия и доступности заказчика в процессе разработки;
новизны используемых при разработке технологий и (или)
инструментальных средств.
Обычно решение о выборе конкретного типа жизненного цикла
принимается руководителем проекта. Как правило, в реальности
применяется смешанный тип жизненного цикла, а в последнее время
все чаще Унифицированный Процесс Разработки
Модели ЖЦ

Модель ЖЦ - структура, определяющая
последовательность выполнения и взаимосвязи процессов,
действий и задач, выполняемых на протяжении ЖЦ.

Каскадная
V – образная
Модель быстрого прототипирования
RAD – модель
Инкрементная
Спиральная
Адаптированные модели






Модели ЖЦ (2)
Наибольшее распространение получили две
основные модели ЖЦ:

каскадная модель (70-85 гг.);

спиральная модель (86-90 гг.).
Каскадный способ

Каскадный способ - разбиение всей разработки на этапы,
причем переход с одного этапа на следующий происходит
только после того, как будет полностью завершена работа
на текущем.

Попытки оптимизации данной модели привели
возникновению других циклов разработки ПО.
к
Положительные стороны применения
каскадного подхода:

на каждом этапе формируется законченный набор проектной
документации, отвечающий критериям полноты и согласованности;

выполняемые в логичной последовательности этапы работ позволяют
планировать сроки завершения всех работ и соответствующие затраты.

каскадный подход хорошо зарекомендовал себя при построении
систем, для которых в самом начале разработки можно достаточно
точно и полно сформулировать все требования. В эту категорию
попадают сложные расчетные системы, системы реального времени и
другие подобные задачи.
Каскадная модель –
фаз





Исследование
концепции
Процесс системного
распределения
Процесс определения
требований
Процесс разработки
проекта
Процесс реализации
описание

Процесс установки

Процесс эксплуатации и
поддержки
Процесс сопровождения
Процесс вывода из
эксплуатации
Интегральные задачи



Каскадная модель – преимущества




Хорошо известна
потребителям
Упорядоченно
справляется со
сложностями
Удобна в применении
Стабильность
требований




Дефекты можно
обнаружить на ранних
этапах
Доступна для понимания
Хорошо определены
стадии модели
Легко проследить ход
выполнения проекта
Каскадная модель – недостатки




В основе последовательная
линейная структура
Требования должны быть
известны вначале
Процесс обучения
происходит в конце ЖЦ
Замораживание
результативных данных
по завершению каждой
фазы



Интеграция полученных
результатов происходит
на завершающей стадии
работы модели
Клиент не может
ознакомиться с системой
заранее
Программный продукт
разрабатывается за один
раз
Каскадная модель – область
применения



В ситуациях, в которых требования и
их реализация четко определены
При переносе уже существующего
продукта на новую платформу
При выполнении больших проектов, в
которых задействовано несколько
больших команд разработчиков
Схема каскадного
подхода
Каскадный способ (2)

Однако реально в процессе создания
систем постоянно возникает
потребность в возврате к предыдущим
этапам, уточнении или пересмотре
ранее принятых решений.
Реальный процесс создания систем
принимает вид, показанный на
следующем слайде
Реальный процесс создания систем
на базе каскадной модели
V - образная модель



В модели особое значение придается действиям,
направленным на верификацию и аттестацию продукта
После кодирования следуют фазы тестирования
Эта модель была разработана как разновидность
каскадной модели
V –образная модель жизненного
цикла разработки ПО
V - образная модель – описание
фаз





Планирование проекта и
требований
Анализ требований к
продукту
Архитектура или
проектирование на
высшем уровне
Детализированная
разработка проекта
Разработка
программного кода





Модульное тестирование
Интеграция и
тестирование
Системное и приемочное
тестирование
Производство,
эксплуатация и
сопровождение
Приемочные испытания
V – образная модель –
преимущества



Особое значение
придается
планированию
Определяет продукты,
которые должны быть
получены в результате
процесса разработки
Предусмотрены
аттестация и
верификация и внешних
полученных данных




Определение требований
– перед разработкой
проекта системы
Проектирование ПО –
перед разработкой
компонентов
Можно отслеживать ход
процесса разработки
Проста в использовании
V - образная модель – недостатки



Плохо справляется с

параллельными
событиями
Не учтены итерации

между фазами
Поздно происходит
тестирование требований
Не предусмотрено
внесение требования
динамических изменений
Не содержит действий,
направленных на анализ
рисков
V - образная модель – область
применения



В ситуациях, в которых
информация о требованиях
доступна заранее
В случае, когда доступными
являются информация о методе
реализации решения и
технология
В системах, в которых требуется
высокая надежность
Модель быстрого
прототипирования
Модель быстрого
прототипирования– преимущества



Взаимодействие

заказчика с системой
начинается на раннем
этапе разработки

В процессе разработки
можно внести новые
требования
Можно выявить проблему
до привлечения
дополнительных ресурсов
Позволяет выполнять
гибкое проектирование и
разработку
Позволяет максимально
уменьшить количество
неточностей в требованиях
Небольшой объем
доработок
Модель быстрого прототипирования–
недостатки



Репутация
«разработанного на
скорую руку» метода
Может быть уделено
недостаточно внимания
качеству ПО или
долгосрочной надежности
Решение трудных проблем
может отодвигаться на
будущее



При досрочном
завершении проекта у
пользователя останется
только частичная
система
Прототипирование
вызывает зависимость
Нет информации о
точном числе итераций
Модель быстрого
прототипирования– область
применения




Требования не известны 
заранее
Требования непостоянны 
Есть потребность в
разработке

пользовательских
интерфейсов

Выполняется не
имеющая аналогов
разработка
Осуществляются
временные демонстрации
При средней и высокой
степенях риска
Применяется с каскадной
моделью
Вместе с элементами
анализа и проектирования
Модель быстрой разработки
приложений RAD (Rapid Application
Development)




Пользователь задействован на всех фазах ЖЦ
Короткое время перехода от определения
требований до создания полной системы
Разработка продукта ограничивается 60 днями,
называемыми временным блоком
Использование мощных инструментальных
средств разработки, высокий уровень фактора
использования
Модель RAD – описание фаз
Модель RAD – преимущества

Время цикла разработки
проекта сокращается

Требуется меньшее
количество специалистов

Уменьшаются затраты

Создается обратная связь

Повторно используются
компоненты уже
существующих программ

Возможно произвести
быстрый изначальный
просмотр продукта
Модель RAD – недостатки


Необходимо достаточное
количество
высококвалифицированных разработчиков
Неудачна при отсутствии
компонент для повторного
использования



Требуются быстрые
действия из-за жестких
временных ограничений
Необходим эффективный
ускоренный процесс
разработки;
При использовании
"вслепую" затраты не
ограничены
Модель RAD – область применения

В моделируемых и
масштабируемых
системах

При выполнении проектов в
сокращенные сроки

Пригодные к повторному
использованию части можно
легко получить

Требования хорошо
известны

При невысокой степени
технических рисков

В системах небольшого
размера

В информационных
системах

Затраты и соблюдение
графика не являются самым
важным вопросом
Инкрементная модель

Это процесс частичной реализации всей
системы и медленного наращивания
функциональных возможностей.

На ранних этапах выполняется
конструирование системы в целом

Модель эффективна при использовании как
в случае чрезвычайно больших, так и в
небольших проектов.
Инкрементная модель (2)
Аттестация
Выполнимость
системы
Аттестация
План и требования к ПО
Разработка проекта продукта
Инкремент 1
Верификация
Инкремент 3
Инкремент 2
Инкрементная модель (3)
Инкремент
Верификация
Детализирован
Модульное
тестирование
ная разработка
проекта
Кодирование
Верификация
прогр.
продукта
Интеграция
Системное
тестирование
Внедрение
Повторная
аттестация
Эксплуатация и
сопровождение
Инкрементная модель – описание
фаз

Планирование

Анализ

Разработка

Кодирование

Тестирование

Поставка
Инкрементная модель –
преимущества

Не требуется заранее
тратить средства,
необходимые для
разработки всего проекта
Существует возможность
поддерживать постоянный
прогресс в ходе выполнения
проекта

При выполнении каждого
инкремента получается
функциональный продукт
Снижаются затраты на
первоначальную поставку
программного продукта

Заказчик может
высказаться по поводу
каждой разработанной
версии системы
Снижается риск неудачи и
изменения требований
Риск распределяется на
несколько меньших по
размеру инкрементов
Инкрементная модель – недостатки

Не предусмотрены
итерации в рамках
каждого инкремента

Определение полной
функциональной системы
должно осуществляться в
начале ЖЦ

Может возникнуть
оттягивание решений
трудных проблем на
будущее

Для инкрементов трудно
выполнить анализ и
проверку
Инкрементная модель – область
применения

Требования можно
сформулировать заранее

Существует потребность
быстро поставить на
рынок продукт

На выполнение проектов
предусмотрен большой
период времени
разработки

При равномерном
распределении свойств
различной степени
важности

При выполнении проекта
с применением новой
технологии
Спиральная модель ЖЦ

В спиральной модели ЖЦ делается упор на начальные этапы ЖЦ:
анализ и проектирование.

Воплощает в себе преимущества каскадной модели

Включены анализ рисков, управление ими, процессы поддержки и
менеджмента

Разработка продукта с использованием метода прототипирования
или быстрой разработки приложения

Каждый цикл представляет собой набор операций, которому
соответствует такое же количество стадий, как и в модели
каскадного процесса.
Спиральная модель ЖЦ
(2)
Спиральная модель ЖЦ
(3)

Каждый виток спирали соответствует созданию нового
фрагмента или версии системы, на нем уточняются
цели и характеристики проекта, определяется его
качество и планируются работы следующего витка
спирали. Один виток спирали при этом представляет
собой законченный проектный цикл по типу каскадной
схемы. Такой подход назывался также
"Продолжающимся проектированием". Позднее в
проектный цикл дополнительно стали включать стадии
разработки и опробования прототипа системы. Это
называлось: "быстрое прототипирование", rapid
prototyping approach или "fast-track".
Спиральная модель – описание
стадий

Определение целей, альтернативных
вариантов и ограничений

Оценка альтернативных вариантов,
идентификация и разрешение рисков

Разработка продукта следующего уровня

Планирование следующей фазы
Спиральная модель –
преимущества

Модель разрешает
пользователям "увидеть"
систему на ранних этапах

Обеспечивается определение
непреодолимых рисков

Пользователи принимают
участие при планировании,
анализе рисков, разработке

Предусмотрена возможность
гибкого проектирования

Обеспечивается разбиение
большого объема работы по
разработке продукта на
небольшие части

Обратная связь от
пользователей к разработчикам
выполняется с высокой
частотой и на ранних этапах
модели

Не нужно распределять заранее
финансовые ресурсы
Спиральная модель – недостатки

При низкой степени
риска или небольших
размерах, модель может
оказаться дорогостоящей

Нужда в высоко
профессиональных
знаниях для оценки
рисков

Модель имеет
усложненную структуру

Спираль может
продолжаться до
бесконечности
Спиральная модель – область
применения

Для средней или высокой
степени риска

В случае больших
проектов

Когда пользователи не
уверены в своих
потребностях


Когда ожидаются
существенные изменения
При выполнении бизнеспроектов и проектов в
области аэрокосмической
промышленности,
обороны и инжиниринга

Когда речь идет о
применении новой
технологии
Адаптированные модели

Быстрое отслеживание.

Параллельный инжиниринг.

Спиральная модель "Win-Win".

Эволюционный/инкрементный
принцип.

Принцип V-образной инкрементной
модели.
Быстрое отслеживание

Ускоренное прохождение или пропуск фаз
жизненного цикла или процессов
разработки;

Необходимость в применении возникает в
случае критической нехватки времени;

ЖЦ обычно является менее формальным.
Параллельный инжениринг

Создание продуктов более высокого качества
за меньший период времени;

Все аспекты ЖЦ проекта учитываются в
процессе от проектирования до производства
как можно раньше;

Состоит из нескольких действий, которые
осуществляются одновременно;

Необходимо оценивать возможные
технические риски при использовании
метода.
Спиральная модель "Win-Win"

К начальной фазе каждого цикла
добавляются так называемые действия
Теории W;

Теория W— это принцип менеджмента,
при реализации которого особое значение
придается ключевым организаторам
совместного дела, выполняющим
разработку системы (пользователь,
заказчик, разработчик, наладчик,
создатель интерфейсов и т.д.), которые
станут "победителями", если проект
окажется успешным.
Спиральная модель "Win-Win" –
описание фаз




Определение
участников следующего
уровня;
Определение условий,
необходимых для
одержания участниками
победы;
Согласование
"победных" условий;
Формулирование целей,
ограничений и
альтернативных
вариантов следующего
уровня;




Оценка альтернативных
вариантов на уровне
продукта и процесса,
разрешение рисков;
Определение
следующего уровня
продукта и процесса,
включая сегментацию;
Обоснование
определений продукта и
процесса;
Обзор и комментарии.
Спиральная модель "Win-Win" преимущества





Более быстрая разработка ПО;
Уменьшение стоимости программ;
Более высокий уровень удовлетворения со
стороны участников проекта;
Более высокое качество ПО;
Исследование большого количества
вариантов построения архитектуры на
ранних этапах разработки.
Эволюционный/инкрементный
принцип

Разработка программного продукта при
использовании принципа часто затруднена;

Каждая инкрементная конструкция
реализует небольшую часть возможностей
разрабатываемой системы
Выбор приемлемой модели ЖЦ
разработки ПО
1.
2.
3.
4.
Проанализировать отличительные категории
проекта.
Ответить на вопросы каждой категории, обведя
кружочком слова "да" или "нет".
Расположить по степени важности категории или
вопросы, относящиеся к каждой категории,
относительно проекта.
Воспользоваться упорядоченными категориями для
разрешения противоречий, возникающих при
сравнении моделей.
Отличительные категории

Требования

Команда разработчиков

Коллектив пользователей

Тип проекта и риски
Отличительные категории - требования
Требования
Каскад- V-образная
ная
ПротоСпитипиро- ральная
вание
Являются ли
требования легко
определимыми
и/или хорошо
известными?
Да
Да
Нет
Нет
Да
Нет
Могут ли требования
заранее
Да
определяться
в цикле?
Да
Нет
Нет
Да
Да
Часто ли будут
изменяться
требования в цикле?
Нет
Нет
Да
Да
Нет
Нет
Нужно ли
демонстрировать
требования с целью
определения?
Нет
Нет
Да
Да
Да
Нет
RAD
Инкрементная
Отличительные категории – требования
(продолжение)
Требования
Каскад
ная
V-образ
ная
Прототипирование
Спиральная
RAD
Инкрементная
Требуются ли для
демонстрации
возможностей
проверка концепции?
Нет
Нет
Да
Да
Нет
Нет
Будут ли требования
отражать сложность
системы?
Нет
Нет
Да
Да
Нет
Да
Обладает ли
требование
функциональными
свойствами на
раннем этапе?
Нет
Нет
Да
Да
Да
Да
Отличительные категории – команда
разработчиков
Команда
разработчиков
Каскад- V-образная
ная
Прототипирование
Спиральная
RAD
Инкрементная
Являются ли
проблемы
предметной облас-ти Нет
проекта новыми для
большинства
разработчиков?
Нет
Дат
Да
Нет
Нет
Является ли
технология
предметной области
проекта новой
для большинства
разработчиков?
Да
Нет
Да
Нет
Да
Нет
Да
Да
Нет
Да
Да
Изменяются ли роли
Нет
участников проекта
во время ЖЦ?
Отличительные категории – команда
разработчиков (продолжение)
Команда
разработчиков
Каскад- V-образ- Прототипироная
ная
вание
Спиральная
RAD
Инкрементная
Являются ли
инструменты,
используемые
проектом, новыми
для большинства
разработчиков?
Да
Да
Нет
Да
Нет
Нет
Могут ли
разработчики проекта пройти
обучение?
Нет
Да
Нет
Нет
Да
Да
Является ли
структура более
значимой для
разработчиков, чем
гибкость?
Да
Да
Нет
Нет
Нет
Да
Отличительные категории – команда
разработчиков (конец)
Команда
разработчиков
Каскад- V-образ- Прототипироная
ная
вание
Спиральная
RAD
Инкрементная
Будет ли менеджер
проекта строго
отслеживать
прогресс команды?
Да
Да
Нет
Да
Нет
Да
Важна ли легкость
распределения ресур- Да
сов?
Да
Нет
Нет
Да
Да
Приемлет ли
команда
равноправные
обзоры
и инспекции,
менеджмент/обзоры
заказчика, а также стадии?
Да
Да
Да
Да
Нет
Да
Отличительные категории – коллектив
пользователей
Коллектив
пользователей
Каскад- V-образ- Прототипироная
ная
вание
Спиральная
RAD
Инкрементная
Будет ли
присутствие
пользователей
ограничено в
жизненном цикле?
Да
Да
Нет
Да
Нет
Да
Будут ли
пользователи
знакомы с определением системы?
Нет
Нет
Да
Да
Нет
Да
Буду ли
пользователи
ознакомлены с проб- Нет
лемами предметной
области?
Нет
Да
Нет
Да
Да
Отличительные категории – коллектив
пользователей (продолжение)
Коллектив
пользователей
Каскад- V-образ- Прототипироная
ная
вание
Спиральная
RAD
Инкрементная
Будут ли
пользователи
вовлечены во все
фазы жизненного
цикла?
Нет
Нет
Да
Нет
Да
Нет
Будет ли заказчик
отслеживать ход
выполнения
проекта?
Нет
Нет
Да
Да
Нет
Нет
Отличительные категории
Отличительные категории – тип проекта и
риски
Тип проекта и
риски
Каскад- V-образ- Прототипироная
ная
вание
Спиральная
RAD
Инкрементная
Будет ли проект
идентифицировать
новое направление
продукта для
организации?
Нет
Нет
Да
Да
Нет
Да
Будет ли проект
иметь тип системной Нет
ин-теграции?
Да
Да
Да
Да
Да
Будет ли проект являться расширением
существующей
системы?
Нет
Да
Нет
Нет
Да
Да
Должна ли быть
высокая степень
надеж-ности?
Нет
Да
Нет
Да
Нет
Да
Отличительные категории – тип проекта и
риски (продолжение)
Тип проекта и
риски
Каскадная
V-образ- Прототипироная
вание
Спиральная
RAD
Инкрементная
Будет ли
финансирование
проекта стабильным на всем
протяжении ЖЦ?
Да
Да
Да
Нет
Да
Нет
Ожидается ли длительная
эксплуатация
продукта в
организации?
Да
Да
Нет
Да
Нет
Да
Будет ли система
изменяться с
применением
непредвиденных
методов, на этапе
со-провождения?
Нет
Нет
Да
Да
Нет
Да
Является ли график
ограниченным?
Нет
Нет
Да
Да
Да
Да
Отличительные категории – тип проекта и
риски (конец)
Тип проекта и
риски
Каскадная
V-образ- Прототипироная
вание
Спиральная
RAD
Инкрементная
Будет ли проект
иден-тифицировать
новое направление
продукта для
организации?
Нет
Нет
Да
Да
Нет
Да
Являются ли "прозрачными"
интерфейс-ные
модули?
Да
Да
Нет
Нет
Нет
Да
Доступны ли повторно используемые
ком-поненты?
Нет
Нет
Да
Да
Да
Нет
Являются ли достаточными ресурсы
(время, деньги, инструменты, персонал)?
Нет
Нет
Да
Да
Нет
Нет
Подгонка модели жизненного цикла разработки
ПО
1.
2.
3.
Ознакомьтесь с различными моделями.
Просмотрите и проанализируйте возможные виды работ:
разработка, модернизация, сопровождение и т.д.
Выберите самый подходящий жизненный цикл, используя
матрицы критериев:
 высокая степень риска,
 пользовательский интерфейс,
 высокая надежность,
 время доставки на рынок/выпуска продукта,
 приоритеты пользователя,
 уточнение требований,
 ожидаемый срок эксплуатации системы,
 технология,
 размер и сложность,
 возможный параллелизм,
 интерфейсы для существующих и новых систем.
Подгонка модели жизненного цикла разработки
ПО
1.
2.
3.
4.
5.
6.
Проанализируйте, насколько выбранный жизненный
цикл соответствует стандартам организации, заказчиков
или типа проекта — ISO, IEEE и т.д.
Сформулируйте набор фаз и действий, образующих
каждую фазу.
Определите внутренние и внешние производимые
продукты.
Определите шаблоны и внутреннее содержимое
поставляемых продуктов.
Определите действия по обзору, инспектированию,
верификации и аттестации, а также стадии проекта.
Выполните оценку эффективности схемы жизненного
цикла и проведите ее модернизацию там, где это
необходимо.