Tarkvara kvaliteed ja standardid Качество и стандарты программного обеспечения L.Joonas 2012. - презентация

1 Tarkvara kvaliteed ja standardid Качество и стандарты программного обеспечения L.Joonas 2012

2 Основные темы курса Понятие качества Жизненный цикл продукта Тестирование Метрики качества Управление качеством

3 Понятие качества Что качественнее – настенные часы или песочные часы?

4 Что качественнее ?

5 Windows Vista или Ubuntu 9.0

6 ISO 9000:2000 формулирует понятие качества следующим образом: полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям

7 Определение IEEE: Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств

8 Качество Отвечает специфическим требованиям (Crosby) Пригодно к использованию (Juran) Удовлетворяет клиента

9 Аспекты качества Функциональность Надежность Соответствие Прочность, устойчивость Пригодность к использованию Удобство Эстетичность Этичность Внешнее восприятие

10 Аспекты качества программного продукта функциональность годность к употреблению исполнение требования к установке удобство сопровождения документация/информация обслуживание общее удовлетворение

11 Различные потребители и среда потребления Обычные пользователи Ежедневное использование для обычных работ Редкое использование – специальные копии Продавец – консультант Ремонтник – обслуживание и ремонт Непользователи, имеющие отношение к предмету Сотрудники в комнате Руководство – цена/прибыль

12 50 лет программирования : основные принципы качества

13 Технологические достижения Социальные и экономические факторы

14 50 лет программирования: основные принципы качества (2) : возникновение Первыми «компьютерами» были женщины, которых не брали в армию США. Компьютеры стали применяться в первую очередь для оборонных задач. Простые алгоритмы разрабатывались тщательно

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

16 50 лет программирования: основные принципы качества (4) : хаос Персональные компьютеры и простота компиляции. Более эффективные способы решения задач. Программисты стали выдавать ошибки за особенности программ («унаследованный код»). О тестировании попросту забыли.

17 50 лет программирования: основные принципы качества (5) : возрождение CASE-инструментарий (computer aided software engineering) Языки 4 поколения (4GL) Формальные методы (сокрытие информации, структурное программирование и поэтапное улучшение )

18 50 лет программирования: основные принципы качества (6) : совершенствование Capability Maturity Model (Управление разработкой программного обеспечения гарантирует получение более качественного продукта) «Шесть сигма» (Six Sigma) это дисциплинарный, определяемый данными подход и методология ликвидации дефектов в любом процессе CBSE (component-based software engineering «компонентная разработка программного обеспечения») COTS (commercial off-the-shelf готовые коммерчески доступные компоненты).

19 50 лет программирования: основные принципы качества (5) С 2000 по 2012 год: инженерия? уровень ошибок последние двадцать лет практически не меняется, несмотря на объектно-ориентированную технологию, автоматические отладчики, более качественные средства тестирования и более строгий контроль типов в таких языках, как Java и Ada

20 «объем экономических потерь из-за ошибочного программного обеспечения в США достигает миллиардов долларов в год и составляет, по некоторым оценкам, около 1% национального валового внутреннего продукта» (Research Triangle Institute, «The Economic Impacts of Inadequate Infrastructure for Software Testing,» NIST Planning Report 02-3, May 2002).

21 Метрики качества программного обеспечения

22 Когда вы можете измерить то, о чем вы говорите, и выразить это в числах, вы знаете кое-что об этом; но если вы не можете измерить это и выразить в числах, ваше знание скудно и неудовлетворительно. Лорд Кельвин

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

24 Понятие качества Определение ISO: Качество - это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям [61]. Определение IEEE: Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств [58].

25 Составляющие качества информационной системы: Качество инфраструктуры (infrastructure quality): качество аппаратного и поддерживающего программного обеспечения (например, качество операционных систем, компьютерных сетей и т.п.). Качество программного обеспечения (software quality): качество программного обеспечения информационной системы. Качество данных (data quality): качество данных, использующихся информационной системой на входе.

26 Составляющие качества информационной системы: Качество информации (information quality): качество информации, продуцируемое информационной системой. Качество административного управления (administrative quality) – качество менеджмента, включая качество бюджетирования, планирования и календарного контроля. Качество сервиса (service quality) – качество обучения, системной поддержки и т.п.

27 Анализ всех составляющих качества должен проводится с учетом сфер ответственности заинтересованных сторон, как внутренних участников исполняемого процесса (in-process stakeholder), так и пользователей процесса (end-of-process stakeholders).

28 Многомерность качества

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

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

31 Список элементов качества, на которые распространяются требования стандартов ISO 900 Ответственность руководства. Система качества. Анализ контракта. Управление проектированием. Управление документацией. Закупки продукции. Продукция, предоставляемая потребителям. Идентификация продукции и ее прослеживаемость. Управление процессами. Контроль и проведение испытаний.

32 Список элементов качества, на которые распространяются требования стандартов ISO 900 (2) Контрольное измерительное и испытательное оборудование. Статус контроля и испытаний. Управление продукцией, не соответствующей стандарту качества. Корректирующие и предупреждающие действия. Погрузочно-разгрузочные работы, хранение, упаковка и поставка. Регистрация данных о качестве. Внутренние проверки качества. Подготовка кадров. Техническое обслуживание. Статистические методы.

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

34 Группа проекта (2) Разработчики - реализуют принятые технические задания, отвечают за качество и сроки разрабатываемого кода, за его соответствие техническим заданиям; Дизайнер - участвует в разработке концепции системы, разрабатывает ее пользовательский интерфейс и принимает участие в его реализации, несет ответственность за соблюдение фирменного стиля и требований к реализации пользовательского интерфейса; Тестер - разрабатывает программу тестирования, осуществляет ее и несет ответственность за полноту тестирования готовых модулей и системы в целом; Технический писатель - разрабатывает документацию на проект, несет ответственность за полноту и правильность описания.

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

36 Структурная схема терминов Организацион- ные процессы Вспомогатель- ные процессы Основные процессы ЖЦ Спиральная модель Каскадная модель Этапы ЖЦ Модель ЖЦСтруктура ЖЦ Жизненный цикл ПО

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

38 Структура ЖЦ по стандарту ISO/IEC базируется на трех группах процессов: основные процессы ЖЦ (приобретение, поставка, разработка, эксплуатация, сопровождение); вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, аттестация, аудит, решение проблем); организационные процессы (управление проектами, создание инфраструктуры проекта, улучшение самого ЖЦ, обучение).

39 Пять основных стадий ЖЦ: анализ и формализация требований заказчика; проектирование; реализация; тестирование; внедрение и эксплуатация.

40 Типы ЖЦ два основных типа: Последовательный тип Эволюционный тип

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

42 Эволюционный тип Функциональные возможности системы в данном случае наращиваются постепенно. В процессе разработки основные стадии ЖЦ (проектирование, реализация, тестирование) проходятся несколько раз применительно к очередной добавляемой порции возможностей системы. Данный тип ЖЦ не требует заранее наличия всех требований к системе и позволяет заказчику активно участвовать в ее разработке. Минусы: сложность в управлении и контроле выполнения проекта; сложность оценки затрат на разработку; риск бесконечного улучшения системы.

43 Выбор типа жизненного цикла Выбор конкретного типа жизненного цикла зависит от ряда субъективных и объективных причин, сопутствующих проекту: наличия четких и подробных требований к ПО; ресурсов, имеющихся в наличии для проведения работ по проекту; наличия и доступности заказчика в процессе разработки; новизны используемых при разработке технологий и (или) инструментальных средств. Обычно решение о выборе конкретного типа жизненного цикла принимается руководителем проекта. Как правило, в реальности применяется смешанный тип жизненного цикла, а в последнее время все чаще Унифицированный Процесс Разработки

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

45 Модели ЖЦ (2) Наибольшее распространение получили две основные модели ЖЦ: каскадная модель (70-85 гг.); спиральная модель (86-90 гг.).

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

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

48 Каскадная модель – описание фаз Исследование концепции Исследование концепции Процесс системного распределения Процесс системного распределения Процесс определения требований Процесс определения требований Процесс разработки проекта Процесс разработки проекта Процесс реализации Процесс реализации Процесс установки Процесс установки Процесс эксплуатации и поддержки Процесс эксплуатации и поддержки Процесс сопровождения Процесс сопровождения Процесс вывода из эксплуатации Процесс вывода из эксплуатации Интегральные задачи Интегральные задачи

49 Каскадная модель – преимущества Хорошо известна потребителям Упорядоченно справляется со сложностями Удобна в применении Стабильность требований Дефекты можно обнаружить на ранних этапах Дефекты можно обнаружить на ранних этапах Доступна для понимания Доступна для понимания Хорошо определены стадии модели Хорошо определены стадии модели Легко проследить ход выполнения проекта Легко проследить ход выполнения проекта

50 Каскадная модель – недостатки В основе - последовательная линейная структура Требования должны быть известны вначале Процесс обучения происходит в конце ЖЦ Замораживание результативных данных по завершению каждой фазы Интеграция полученных результатов происходит на завершающей стадии работы модели Интеграция полученных результатов происходит на завершающей стадии работы модели Клиент не может ознакомиться с системой заранее Клиент не может ознакомиться с системой заранее Программный продукт разрабатывается за один раз Программный продукт разрабатывается за один раз

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

52 Схема каскадного подхода

53 Каскадный способ (2) Однако реально в процессе создания систем постоянно возникает потребность в возврате к предыдущим этапам, уточнении или пересмотре ранее принятых решений. Реальный процесс создания систем принимает вид, показанный на следующем слайде

54 Реальный процесс создания систем на базе каскадной модели

55 V - образная модель В модели особое значение придается действиям, направленным на верификацию и аттестацию продукта После кодирования следуют фазы тестирования Эта модель была разработана как разновидность каскадной модели

56 V –образная модель жизненного цикла разработки ПО

57 V - образная модель – описание фаз Планирование проекта и требований Анализ требований к продукту Архитектура или проектирование на высшем уровне Детализированная разработка проекта Разработка программного кода Модульное тестирование Модульное тестирование Интеграция и тестирование Интеграция и тестирование Системное и приемочное тестирование Системное и приемочное тестирование Производство, эксплуатация и сопровождение Производство, эксплуатация и сопровождение Приемочные испытания Приемочные испытания

58 V – образная модель – преимущества Особое значение придается планированию Определяет продукты, которые должны быть получены в результате процесса разработки Предусмотрены аттестация и верификация и внешних полученных данных Определение требований – перед разработкой проекта системы Определение требований – перед разработкой проекта системы Проектирование ПО – перед разработкой компонентов Проектирование ПО – перед разработкой компонентов Можно отслеживать ход процесса разработки Можно отслеживать ход процесса разработки Проста в использовании Проста в использовании

59 V - образная модель – недостатки Плохо справляется с параллельными событиями Не учтены итерации между фазами Поздно происходит тестирование требований Не предусмотрено внесение требования динамических изменений Не предусмотрено внесение требования динамических изменений Не содержит действий, направленных на анализ рисков Не содержит действий, направленных на анализ рисков

60 V - образная модель – область применения В ситуациях, в которых информация о требованиях доступна заранее В случае, когда доступными являются информация о методе реализации решения и технология В системах, в которых требуется высокая надежность

61 Модель быстрого прототипирования

62 Модель быстрого прототипирования– преимущества Взаимодействие заказчика с системой начинается на раннем этапе разработки В процессе разработки можно внести новые требования Можно выявить проблему до привлечения дополнительных ресурсов Позволяет выполнять гибкое проектирование и разработку Позволяет выполнять гибкое проектирование и разработку Позволяет максимально уменьшить количество неточностей в требованиях Позволяет максимально уменьшить количество неточностей в требованиях Небольшой объем доработок Небольшой объем доработок

63 Модель быстрого прототипирования– недостатки Репутация «разработанного на скорую руку» метода Может быть уделено недостаточно внимания качеству ПО или долгосрочной надежности Решение трудных проблем может отодвигаться на будущее При досрочном завершении проекта у пользователя останется только частичная система При досрочном завершении проекта у пользователя останется только частичная система Прототипирование вызывает зависимость Прототипирование вызывает зависимость Нет информации о точном числе итераций Нет информации о точном числе итераций

64 Модель быстрого прототипирования– область применения Требования не известны заранее Требования непостоянны Есть потребность в разработке пользовательских интерфейсов Выполняется не имеющая аналогов разработка Осуществляются временные демонстрации Осуществляются временные демонстрации При средней и высокой степенях риска При средней и высокой степенях риска Применяется с каскадной моделью Применяется с каскадной моделью Вместе с элементами анализа и проектирования Вместе с элементами анализа и проектирования

65 Модель быстрой разработки приложений RAD (Rapid Application Development) Пользователь задействован на всех фазах ЖЦ Короткое время перехода от определения требований до создания полной системы Разработка продукта ограничивается 60 днями, называемыми временным блоком Использование мощных инструментальных средств разработки, высокий уровень фактора использования

66 Модель RAD – описание фаз

67 Модель RAD – преимущества Время цикла разработки проекта сокращается Требуется меньшее количество специалистов Уменьшаются затраты Создается обратная связь Создается обратная связь Повторно используются компоненты уже существующих программ Повторно используются компоненты уже существующих программ Возможно произвести быстрый изначальный просмотр продукта Возможно произвести быстрый изначальный просмотр продукта

68 Модель RAD – недостатки Необходимо достаточное количество высококвалифицирован- ных разработчиков Неудачна при отсутствии компонент для повторного использования Требуются быстрые действия из-за жестких временных ограничений Требуются быстрые действия из-за жестких временных ограничений Необходим эффективный ускоренный процесс разработки; Необходим эффективный ускоренный процесс разработки; При использовании "вслепую" затраты не ограничены При использовании "вслепую" затраты не ограничены

69 Модель RAD – область применения В моделируемых и масштабируемых системах Требования хорошо известны При невысокой степени технических рисков В информационных системах При выполнении проектов в сокращенные сроки При выполнении проектов в сокращенные сроки Пригодные к повторному использованию части можно легко получить Пригодные к повторному использованию части можно легко получить В системах небольшого размера В системах небольшого размера Затраты и соблюдение графика не являются самым важным вопросом Затраты и соблюдение графика не являются самым важным вопросом

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

71 Инкрементная модель (2) Выполнимость системы План и требо- вания к ПО Разработка про- екта продукта Аттестация Инкремент 3 Верифи- кация Инкремент 1Инкремент 2

72 Инкрементная модель (3) Инкремент Детализирован ная разработка проекта Кодирова- ние Интегра- ция Внедре- ние Эксплуатация и сопровождение Верификация Модульное тестирование Верификация прогр. продукта Системное тестирование Повторная аттестация

73 Инкрементная модель – описание фаз Планирование Анализ Разработка Кодирование Тестирование Поставка

74 Инкрементная модель – преимущества Не требуется заранее тратить средства, необходимые для разработки всего проекта При выполнении каждого инкремента получается функциональный продукт Заказчик может высказаться по поводу каждой разработанной версии системы Существует возможность поддерживать постоянный прогресс в ходе выполнения проекта Снижаются затраты на первоначальную поставку программного продукта Снижается риск неудачи и изменения требований Риск распределяется на несколько меньших по размеру инкрементов

75 Инкрементная модель – недостатки Не предусмотрены итерации в рамках каждого инкремента Определение полной функциональной системы должно осуществляться в начале ЖЦ Может возникнуть оттягивание решений трудных проблем на будущее Может возникнуть оттягивание решений трудных проблем на будущее Для инкрементов трудно выполнить анализ и проверку Для инкрементов трудно выполнить анализ и проверку

76 Инкрементная модель – область применения Требования можно сформулировать заранее Существует потребность быстро поставить на рынок продукт На выполнение проектов предусмотрен большой период времени разработки При равномерном распределении свойств различной степени важности При равномерном распределении свойств различной степени важности При выполнении проекта с применением новой технологии При выполнении проекта с применением новой технологии

77 Спиральная модель ЖЦ В спиральной модели ЖЦ делается упор на начальные этапы ЖЦ: анализ и проектирование. Воплощает в себе преимущества каскадной модели Включены анализ рисков, управление ими, процессы поддержки и менеджмента Разработка продукта с использованием метода прототипирования или быстрой разработки приложения Каждый цикл представляет собой набор операций, которому соответствует такое же количество стадий, как и в модели каскадного процесса.

78 Спиральная модель ЖЦ (2)

79

80 Спиральная модель ЖЦ (3) Каждый виток спирали соответствует созданию нового фрагмента или версии системы, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также "Продолжающимся проектированием". Позднее в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы. Это называлось: "быстрое прототипирование", rapid prototyping approach или "fast-track".

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

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

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

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

85 Адаптированные модели Быстрое отслеживание. Параллельный инжиниринг. Спиральная модель "Win-Win". Эволюционный/инкрементный принцип. Принцип V-образной инкрементной модели.

86 Быстрое отслеживание Ускоренное прохождение или пропуск фаз жизненного цикла или процессов разработки; Необходимость в применении возникает в случае критической нехватки времени; ЖЦ обычно является менее формальным.

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

88 Спиральная модель "Win-Win" К начальной фазе каждого цикла добавляются так называемые действия Теории W; Теория W это принцип менеджмента, при реализации которого особое значение придается ключевым организаторам совместного дела, выполняющим разработку системы (пользователь, заказчик, разработчик, наладчик, создатель интерфейсов и т.д.), которые станут "победителями", если проект окажется успешным.

89 Спиральная модель "Win-Win" – описание фаз Определение участников следующего уровня; Определение условий, необходимых для одержания участниками победы; Согласование "победных" условий; Формулирование целей, ограничений и альтернативных вариантов следующего уровня ; Оценка альтернативных вариантов на уровне продукта и процесса, разрешение рисков; Определение следующего уровня продукта и процесса, включая сегментацию; Обоснование определений продукта и процесса; Обзор и комментарии.

90 Спиральная модель "Win-Win" - преимущества Более быстрая разработка ПО; Уменьшение стоимости программ; Более высокий уровень удовлетворения со стороны участников проекта; Более высокое качество ПО; Исследование большого количества вариантов построения архитектуры на ранних этапах разработки.

91 Эволюционный/инкрементный принцип Разработка программного продукта при использовании принципа часто затруднена; Каждая инкрементная конструкция реализует небольшую часть возможностей разрабатываемой системы

92 Выбор приемлемой модели ЖЦ разработки ПО 1. Проанализировать отличительные категории проекта. 2. Ответить на вопросы каждой категории, обведя кружочком слова "да" или "нет". 3. Расположить по степени важности категории или вопросы, относящиеся к каждой категории, относительно проекта. 4. Воспользоваться упорядоченными категориями для разрешения противоречий, возникающих при сравнении моделей.

93 Отличительные категории Требования Команда разработчиков Коллектив пользователей Тип проекта и риски

94 Отличительные категории - требования Требования Каскад- ная V-образ- ная Прото- типиро- вание Спи- ральная RAD Инк- ремен- тная Являются ли требования легко определимыми и/или хорошо известными? Да Нет ДаНет Могут ли требования заранее определяться в цикле? Да Нет Да Часто ли будут изменяться требования в цикле? Нет Да Нет Нужно ли демонстрировать требования с целью определения? Нет Да Нет

95 Отличительные категории – требования (продолжение) Требования Каскад ная V-образ ная Прото- типиро- вание Спира- льная RAD Инкре- мент- ная Требуются ли для демонстрации возможностей проверка кон- цепции? Нет Да Нет Будут ли требования отражать сложность системы? Нет Да НетДа Обладает ли требование функциональными свойствами на раннем этапе? Нет Да

96 Отличительные категории – команда разработчиков Команда разработчиков Каскад- ная V-образ- ная Прото- типиро- вание Спира- льная RAD Инкре- мент- ная Являются ли проблемы предметной облас-ти проекта новыми для большинства разработчиков? Нет ДатДаНет Является ли технология предметной области проекта новой для большинства разработчиков? Да НетДаНетДа Изменяются ли роли участников проекта во время ЖЦ? Нет Да НетДа

97 Отличительные категории – команда разработчиков (продолжение) Команда разработчиков Каскад- ная V-образ- ная Прото- типиро- вание Спира- льная RAD Инкре- мент- ная Являются ли инструменты, используемые проектом, новыми для большинства разработчиков? Да НетДаНет Могут ли разработчи- ки проекта пройти обучение? НетДаНет Да Является ли структура более значимой для разработчиков, чем гибкость? Да Нет Да

98 Отличительные категории – команда разработчиков (конец) Команда разработчиков Каскад- ная V-образ- ная Прото- типиро- вание Спира- льная RAD Инкре- мент- ная Будет ли менеджер проекта строго отслеживать прогресс команды? Да НетДаНетДа Важна ли легкость распределения ресур- сов? Да Нет Да Приемлет ли команда равноправные обзоры и инспекции, менедж- мент/обзоры заказчи- ка, а также стадии? Да Нет Да

99 Отличительные категории – коллектив пользователей Коллектив пользователей Каскад- ная V-образ- ная Прото- типиро- вание Спира- льная RAD Инкре- мент- ная Будет ли присутствие пользователей ограничено в жизненном цикле? Да НетДаНетДа Будут ли пользователи знакомы с опреде- лением системы? Нет Да НетДа Буду ли пользователи ознакомлены с проб- лемами предметной области? Нет ДаНетДа

100 Отличительные категории – коллектив пользователей (продолжение) Коллектив пользователей Каскад- ная V-образ- ная Прото- типиро- вание Спира- льная RAD Инкре- мент- ная Будут ли пользователи вовлечены во все фазы жизненного цикла? Нет ДаНетДаНет Будет ли заказчик отслеживать ход выполнения проекта? Нет Да Нет Отличительные категории

101 Отличительные категории – тип проекта и риски Тип проекта и риски Каскад- ная V-образ- ная Прото- типиро- вание Спира- льная RAD Инкре- мент- ная Будет ли проект идентифицировать новое направление продукта для организации? Нет Да НетДа Будет ли проект иметь тип системной ин-теграции? НетДа Будет ли проект яв- ляться расширением существующей системы? НетДаНет Да Должна ли быть высокая степень надеж-ности? НетДаНетДаНетДа

102 Отличительные категории – тип проекта и риски (продолжение) Тип проекта и риски Каскад- ная V-образ- ная Прото- типиро- вание Спира- льная RAD Инкре- мент- ная Будет ли финансирование проекта ста- бильным на всем протяжении ЖЦ? Да НетДаНет Ожидается ли дли- тельная эксплуатация продукта в организации? Да НетДаНетДа Будет ли система изменяться с применением непредвиденных методов, на этапе со-провождения? Нет Да НетДа Является ли график ограниченным? Нет Да

103 Отличительные категории – тип проекта и риски (конец) Тип проекта и риски Каскад- ная V-образ- ная Прото- типиро- вание Спира- льная RAD Инкре- мент- ная Будет ли проект иден-тифицировать новое направление продукта для организации? Нет Да НетДа Являются ли "проз- рачными" интерфейс-ные модули? Да Нет Да Доступны ли повтор- но используемые ком-поненты? Нет Да Нет Являются ли доста- точными ресурсы (время, деньги, инст- рументы, персонал)? Нет Да Нет

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

105 Подгонка модели жизненного цикла разработки ПО 1. Проанализируйте, насколько выбранный жизненный цикл соответствует стандартам организации, заказчиков или типа проекта ISO, IEEE и т.д. 2. Сформулируйте набор фаз и действий, образующих каждую фазу. 3. Определите внутренние и внешние производимые продукты. 4. Определите шаблоны и внутреннее содержимое поставляемых продуктов. 5. Определите действия по обзору, инспектированию, верификации и аттестации, а также стадии проекта. 6. Выполните оценку эффективности схемы жизненного цикла и проведите ее модернизацию там, где это необходимо.