Корпоративные информационные системы. Лекция 8. Раздел 4. Разработка ПО КИС. Часть 4.1

1.

Корпоративные
информационные системы
Лекция 8
Раздел 4. Разработка ПО КИС
Часть 4.1. Этапы разработки ПО.
Преподаватель: Недашковский В. М.

2.

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

3.

Классический жизненный цикл разработки ПО

4.

Классический жизненный цикл разработки ПО
Системный анализ.
На этом этапе дается:
• формализованное описание предметной области и
выявление требований к системе;
• начинается решение задачи планирования проекта ПО,
определяются:
- объем проектных работ,
- риск проектных работ,
- необходимые трудозатраты,
- формируются задачи,
- формируется план-график работ.

5.

Классический жизненный цикл разработки ПО
Анализ требований
На этом этапе в, основном, уточняются и
детализируются функции ПО. Все определения
документируются
в
спецификации
анализа.
Завершается решение задачи планирования проекта.

6.

Классический жизненный цикл разработки ПО
Проектирование
Проектирование включает создание проектных
представлений:
• архитектуры ПО;
• модульной структуры ПО;
• алгоритмической структуры ПО;
• структуры данных;
• входного и выходного интерфейса (входных и выходных
форм данных).

7.

Классический жизненный цикл разработки ПО
Исходные данные для проектирования
содержатся в спецификации анализа, т. е. в
требованиях к ПО. Таким образом, в ходе выполнения
проектирования выполняется трансляция требований
к ПО во множество проектных представлений.
При решении задач проектирования основное
внимание уделяется качеству будущего программного
продукта.

8.

Классический жизненный цикл разработки ПО
Кодирование
Состоит в переводе результатов проектирования
в текст на языке программирования.
Тестирование
Это выполнение программы для выявления
дефектов в функциях, логике и форме реализации
программного продукта.

9.

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

10.

Классический жизненный цикл разработки ПО
Достоинства и недостатки классического жизненного цикла
Достоинства:
• дает план и временной график по всем этапам проекта;
• упорядочивает ход разработки.
Недостатки:
• реальные проекты часто требуют отклонения от стандартной
последовательности шагов;
• цикл основан на точной формулировке всех исходных требований к
ПО (реально в начале проекта требования заказчика определены лишь
частично);
• результаты проекта доступны заказчику только в конце работы.

11.

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

12.

Макетирование
Макетирование основывается на многократном
повторении итераций, в которых участвуют заказчик и
разработчик.

13.

Макетирование
Макетирование (прототипирование ) начинается со
сбора и уточнения требований к создаваемому ПО.
Разработчик и заказчик вместе определяют все цели ПО,
устанавливают, какие требования известны, а какие
предстоит доопределить.
Затем
выполняется
быстрое
проектирование,
приводящее к построению макета (прототипа).
Макет оценивается заказчиком и используется для
уточнения требований к ПО.
Итерации повторяются до тех пор, пока макет не выявит
все требования заказчика и не даст возможности
разработчику понять, что должно быть сделано.

14.

Макетирование
Достоинства макетирования:
• обеспечивает определение полных требований к ПО.
Недостатки макетирования:
• заказчик может принять макет за продукт;
• разработчик может принять макет за продукт.

15.

Стратегии разработки ПО
Существует три стратегии разработки ПО:
1. Однократный проход (водопадная стратегия) – линейная
последовательность этапов разработки.
2. Инкрементная стратегия. В начале процесса определяются
все пользовательские и системные требования, но реализация
выполняется в виде последовательности версий. Первая версия
реализует часть запланированных возможностей. Следующая
версия реализует дополнительные возможности и т. д., пока не
будет получена полная система.
3.Эволюционная стратегия. Система строится в виде
последовательности версий, но в начале процесса определены
не все требования. Требования уточняются в результате
разработки версий.

16.

Инкрементная модель
Инкрементная модель является классическим
примером инкрементной стратегии разработки ПО.

17.

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

18.

Быстрая разработка приложений
Модель быстрой разработки приложений RAD (Rapid
Application Development) – второй пример применения
инкрементной стратегии разработки ПО.
Первый инкремент приводит к получению базового
продукта, реализующего базовые требования (при этом многие
вспомогательные требования остаются нереализованными).
План следующего инкремента предусматривает
модификацию базового продукта, обеспечивающую
дополнительные характеристики и функциональность
В отличие от макетирования, инкрементная модель
обеспечивает в конце инкрементной итерации работающий
продукт.

19.

Быстрая разработка приложений

20.

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

21.

Эволюционная стратегия разработки ПО
Спиральная модель (убрать пунктирную систему координат?)

22.

Эволюционная стратегия разработки ПО
Обозначения на спиральной модели:
1 - начальный сбор требований и планирование проекта;
2 - та же работа, но на основе рекомендаций заказчика;
3 - анализ риска на основе начальных требований;
4 - анализ риска на основе реакции заказчика;
5 - переход к комплексной системе;
б - начальный макет системы;
7 - следующий уровень макета;
8 - сконструированная система;
9 - оценивание заказчиком.

23.

Эволюционная стратегия разработки ПО
Спиральная модель определяет четыре действия,
представленные четырьмя квадрантами спирали:
1. Планирование – определение цели, выявление вариантов
и ограничений.
2. Анализ риска – анализ вариантов и распознавание/выбор
риска. Выявляется наиболее опасный для успеха риск и его
пытаются уменьшить.
3. Конструирование – разработка продукта следующего
уровня.
4. Оценивание – оценка заказчиком текущих результатов
разработки.

24.

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

25.

Эволюционная стратегия разработки ПО
В каждом цикле по спирали результаты анализа риска
формируются в виде «продолжать, не продолжать». Если
риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали
продолжается, с каждым шагом продвигая разработчиков к
более общей модели системы.
В
каждом
цикле
по
спирали
требуется
конструирование, которое может быть реализовано
классическим жизненным циклом или макетированием.

26.

Эволюционная стратегия разработки ПО
Достоинства спиральной модели:
• наиболее реально (в виде эволюции) отображает разработку
программного обеспечения;
• позволяет явно учитывать риск на каждом витке эволюции
разработки;
• использует моделирование для уменьшения риска и
совершенствования программного изделия.
Недостатки спиральной модели:
• повышенные требования к заказчику.
• трудности контроля и управления временем разработки.

27.

Эволюционная стратегия разработки ПО
Компонентно-ориентированная модель
Эта модель является развитием спиральной модели. В ней
конкретизируется содержание квадранта конструирования, а
именно, учитывается тот факт, что в современных условиях новая
разработка должна основываться на повторном использовании
программных компонентов из библиотеки компонентов.
В новом программном проекте, исходя из требований
заказчика, выявляются кандидаты в компоненты и проверяется
наличие этих кандидатов в библиотеке.
Если они найдены, то компоненты извлекаются из
библиотеки и используются повторно. Иначе создаются новые
компоненты, они применяются в проекте и включаются в
библиотеку.

28.

Эволюционная стратегия разработки ПО
К достоинствам компонентно-ориентированной
модели относится:
• уменьшение времени разработки ПО;
• снижение стоимости программной разработки;
• повышение производительности разработки.

29.

Спасибо за внимание