Лекция_6-7 Методы проектирования и жизненный цикл программ

1.

Методы проектирования и
жизненный цикл программ
«Нельзя автоматизировать беспорядок,
ибо в результате этого получится автоматизированный хаос».

2.

Жизненный цикл информационной системы – период
времени, который начинается с момента принятия решения о
необходимости
создания
информационной
системы
и
заканчивается в момент ее полного изъятия из эксплуатации.
Методология проектирования информационных систем
описывает процесс создания и сопровождения систем в виде
жизненного цикла (ЖЦ) ИС, представляя его как некоторую
последовательность стадий (этапов) и выполняемых на них
процессов.
Для каждого этапа определяются:
- состав и последовательность выполняемых работ,
- получаемые результаты,
- методы и средства, необходимые для выполнения работ,
- роли и ответственность участников и т.д.
Такое формальное описание ЖЦ ИС позволяет спланировать и
организовать процесс коллективной разработки и обеспечить
управление этим процессом.

3.

Выделим 11 видов подходов:
- Waterfall — традиционный подход.
- RUP (Rational Unified Process) — рациональный.
- Agile — общая методология гибкой разработки.
- Crystal Clear — подход с уравниванием разработчиков
в коллективе.
- Spiral — спиральный метод.
- DSDM (Dynamic Systems Development Model) — динамическая
модель.
- JAD (Joint Application Development) — ориентированный
на пользователя подход.
- RAD (Rapid Application Development) — модель быстрой
разработки.
- Scrum — концепция работы в условиях сорванных сроков
и идеологического кризиса.
- XP (Extreme Programming) — экстремальная разработка
в динамической среде.
-тLD (Lean Development) — метод, предполагающий бережное
отношение ко всем участникам процесса.

4.

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

5.

Agile — метод гибкой разработки программного обеспечения,
предполагающий большое количество итераций.
Документ Agile Manifesto описывает до 4 идей и 12 принципов
гибкого подхода, коротко его можно описать всего двумя
пунктами:
- Неформальные отношения важнее задокументированных.
То есть устные договоренности между сотрудниками, между
заказчиком и исполнителем важнее всего, что отражено
в планах, договорах и техническом задании. Иначе говоря,
клиент всегда прав.
- Работающий продукт — главная оценка прогресса. Важны
не инструменты, решения, производительность и изящество,
а тот факт, что все запланированные возможности реализованы.

6.

Модель Waterfall относится к классическому пониманию
разработки ПО. Весь процесс является жестким и линейным,
имеет четкие цели для каждого этапа, новая фаза начинается
по завершению предыдущей, нет возврата назад.
На практике Waterfall часто не оправдывает ожиданий,
поскольку игнорирует динамические изменения. Так, после
тестирования очень сложно откатить процесс и заложить
функции, не учтенные на стадии разработки.
Waterfall неэффективен ещё и потому, что предполагает
временные простои сотрудников в рамках одного проекта.
Тестирование проводится только в конце разработки, хотя
проблемы, найденные на этом этапе — это дорогостоящие
исправления.

7.

8.

Методология – принципы и способы организации
теоретической
и
практической
деятельности.
Совокупность методов, применяемых в какой-либо
науке.
Для проектирования ПО сформулируем
так:
Методология есть методы, принципы и
способы
организации
деятельности
проектной
группы
для
создания
программного средства.

9.

Классификация методологий
Классические методологии проектирования
- Каскадная (водопадная) модель
- Итеративная модель
- Спиральная модель
Гибкие методологии проектирования
- Методология XP
- Манифест Agile / Методология SCRUM

10.

Идеальная модель ЖЦ

11.

Каскадная (водопадная) модель - идеальный
вариант

12.

Каскадная (водопадная) модель - в реальном применении

13.

Основные этапы разработки по каскадной модели
За десятилетия существования модели «водопад»
разбиение работ на стадии и названия этих стадий менялись.
Кроме того, наиболее разумные методики и стандарты
избегали
жесткого
и
однозначного
приписывания
определенных работ к конкретным этапам. Можно выделить
ряд устойчивых этапов разработки, практически не зависящих
от предметной области:
- анализ требований заказчика;
- проектирование;
- разработка;
- тестирование и опытная эксплуатация;
- сдача готового продукта.

14.

Достоинства каскадной (водопадной) модели
- Последовательное
выполнение
этапов
проектирования в строгом фиксированном порядке
- Позволяет оценивать качество продукта на каждом
этапе
Недостатки каскадной (водопадной) модели
- Жесткость модели
- «Запаздывание» и «Бесполезность»

15. Модель с промежуточным контролем

Формирование
требований к ПО
Проектирование
Реализация
Тестирование
Ввод в действие
Эксплуатация и
сопровождение

16. V-образная модель

17.

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

18.

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

19.

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

20. Инкрементная модель ЖЦ

21.

Итеративная
модель
предполагает
разбиение
жизненного цикла проекта на последовательность итераций,
каждая из которых напоминает “мини-проект”, включая все
фазы жизненного цикла в применении к созданию меньших
фрагментов функциональности, по сравнению с проектом, в
целом. Цель каждой итерации – получение работающей
версии
программной
системы,
включающей
функциональность,
определенную
интегрированным
содержанием всех предыдущих и текущей итерации.
С точки зрения структуры жизненного цикла такую
модель называют итеративной (iterative). С точки зрения
развития продукта – инкрементальной (incremental).
Эволюционную модель называют просто итеративной
(говоря о процессе) и/или инкрементальной (говоря о
наращивании функциональности продукта).

22.

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

23.

Когда использовать итеративную модель:
– для крупных проектов;
– когда известны, по крайней мере, ключевые
требования;
– когда требования к проекту могут меняться в
процессе разработки.
Итеративная модель
является ключевым
элементом так называемых «гибких» (Agile) подходов к
разработке программного обеспечения.

24.

Одним из примеров реализации итерационной модели
ЖЦ является получивший широкое распространение в 90 –е
годы ХХ века способ так называемой «быстрой разработки
приложений», или RAD (Rapid Application Development).
Подход
RAD
предусматривает
наличие
трех
составляющих:
- небольших групп разработчиков(от 3 до 7 человек),
выполняющих работы по проектированию отдельных
подсистем ПО. Это обусловлено требованием максимальной
управляемости коллектива.
короткого,
но
тщательно
проработанного
производственного графика (до трех месяцев).
- повторяющегося цикла, при котором разработчики по
мере того, как приложение начинает обретать форму,
запрашивают и реализуют в продукте требования,
полученные в результате взаимодействия с заказчиком.

25.

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

26.

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

27. Модель RAD

Планирование требований
Пользовательское описание
Конструирование
Перевод на новую систему эксплуатации

28. Модель RAD

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

29.

Спиральная модель

30.

Главная
особенность
спиральной
концентрация на возможных рисках.
модели
–
Основные типы рисков, которые могут возникнуть в
процессе разработки ПО:
- Нереалистичный бюджет и сроки;
Дефицит специалистов;
- Частые изменения требований;
- Чрезмерная оптимизация;
- Низкая производительность системы;
Несоответствие уровня квалификации специалистов
разных отделов.

31.

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

32.

Основная проблема спирального цикла – определение
момента перехода на следующую стадию. Для ее решения
необходимо ввести временные ограничения на каждую из
стадий жизненного цикла.
Когда использовать спиральную модель:
– когда важен анализ рисков и затрат;
– крупные долгосрочные проекты с отсутствием четких
требований или вероятностью их динамического изменения;
– при разработке новой линейки продуктов.

33.

Крайним случаем модели ЖЦ можно считать так называемую
модель «черного ящика» (black box), или «code and fix»
(кодирование и исправление), что фактически означает отсутствие
какой-либо модели. В этом случае выделить какие-либо
рациональные стадии в процессе разработки ПО не представляется
возможным, поскольку отсутствует планирование и организации
работ.
Модель «черного ящика»
Программистский фольклор, но
тем не менее, выделяет в такой
модели следующие стадии:
-
начало проекта
безумный энтузиазм
разочарование
хаос
поиски виновных
наказание невинных
награждение непричастных
определение требований к
системе.

34.

Жизненный цикл программ
Одним из базовых понятий методологии проектирования
информационных систем является понятие жизненного цикла ее
программного обеспечения (ЖЦ ПО).
ЖЦ ПО - это непрерывный процесс, который начинается с
момента принятия решения о необходимости его создания и
заканчивается в момент его полного изъятия из эксплуатации.
Жизненный цикл начинается с идеи или потребности,
которую
необходимо
удовлетворить
с
использованием
программных средств.
Архитектура строится как набор процессов и взаимных
связей между ними. Например, основные процессы жизненного
цикла обращаются к вспомогательным процессам, в то время,
как организационные процессы действуют на всем протяжении
жизненного цикла и связаны с основными процессами.

35.

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

36.

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

37.

Стандарты жизненного цикла ПО
Проектирование и производство заказных технических
систем и программных продуктов регламентируют четыре
крупных комплексов международных стандартов:
1. Стандарт ГОСТ Р ИСО/МЭК 12207-2010 –
Информационная технология. Системная и программная
инженерия. Процессы жизненного цикла программных
средств;
2. CMMI – Система и модель оценки зрелости,
управление проектами программных средств;
3. ГОСТ Р ИСО/МЭК 9000:2000 – Стандарты
менеджмента (административного управления) качеством
систем;
4. Стандарт ISO 19759:2005 – SWEBOK, Совокупность
знаний о разработке программных средств. Руководство.

38.

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

39.

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ
следует включать следующие группы процессов:
1. Договорные процессы:
- приобретение (внутренние решения или решения внешнего
поставщика);
- поставка (внутренние решения или решения внешнего
поставщика).
-
2. Процессы предприятия:
управление окружающей средой предприятия;
инвестиционное управление;
управление ЖЦ ИС;
управление ресурсами;
управление качеством.

40.

3. Проектные процессы:
планирование проекта;
оценка проекта;
контроль проекта;
управление рисками;
управление конфигурацией;
управление информационнымипотоками;
принятие решений.
-
4. Технические процессы:
определение требований;
анализ требований;
разработка архитектуры;
внедрение;
интеграция;
верификация;
переход;
аттестация;
эксплуатация;
сопровождение;
утилизация.
5. Специальные процессы:
- определение и установка
взаимосвязей исходя из задач и
целей.

41.

Оценка
качества
(стандарт
осуществляется на всех этапах
программных средств (ПС) при:
ГОСТ
28195-89)
жизненного цикла
- планировании показателей качества ПС;
- контроле качества на отдельных этапах разработки
(техническое задание, технический проект, рабочий
проект);
- контроле качества в процессе производства ПС;
-проверке эффективности модификации ПС в процессе
сопровождения.

42.

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

43.

Модель ЖЦ любого конкретного ПО определяет характер
процесса его создания который представляет собой совокупность
упорядоченных во времени, взаимосвязанных и объединенных в
стадии работ, выполнение которых необходимо и достаточно для
создания ПО, соответствующего заданным требованиям.
Под стадией понимается часть процесса создания ПО,
ограниченная
определенными
временными
рамками
и
заканчивающаяся выпуском конкретного продукта (моделей,
программных
компонентов,
документации),
определяемого
заданными для данной стадии требованиями.
Стадии процесса создания ПО выделяются по соображениям
рационального
планирования
и
организации
работ,
заканчивающихся заданными результатами. Конкретный состав
стадий ЖЦ ПО определяется используемой технологией создания
ПО и соответствующими технологическими стандартами.

44.

Стадии цикла разработки ПО
1. Анализ требований
Цель этой стадии – определение детальных требований к системе. В
зависимости от выбранной модели разработки, могут отличаться подходы к
определению момента перехода с одной стадии на другую. К примеру, в
каскадной или V-модели стадия анализа требований закрепляется в
документе – спецификации требований к программному обеспечению
(Software Requirement Specification, SRS), оформление которого должно
быть закончено до перехода на следующую стадию.

45.

Стадии цикла разработки ПО
2. Проектирование
На стадии проектирования
(называемой также стадией
дизайна
и
архитектуры)
программисты
и
системные
архитекторы,
руководствуясь
требованиями, разрабатывают
высокоуровневый
дизайн
системы.
Разнообразные технические
вопросы,
возникающие
в
процессе
проектирования,
обсуждаются
со
всеми
заинтересованными сторонами,
включая
заказчика.
В
соответствии с уточненными
требованиями
выбираются
наиболее
подходящие
проектные решения.
На этом этапе для упрощения
визуализации процесса проектирования
используются нотации.
Основные используемые нотации:
– Блок-схемы;
– ER-диаграммы;
– UML-диаграммы;
– Макеты

46.

Стадии цикла разработки ПО
3. Разработка и программирование
Этот цикл повторяется до тех пор, пока все
требования не будут реализованы.
Программирование предполагает четыре
основных стадии:
1) Разработка алгоритмов – фактически,
создание логики работы программы;
2) Написание исходного кода;
3) Компиляция – преобразование в
машинный код;
4) Тестирование и отладка (юниттестирование).
Модульное
тестирование это, грубо говоря,
тестирование
битов вашего кода
в изоляции с
тестовым кодом.
Модульное тестирование, или юнит-тестирование — процесс
в программировании, позволяющий проверить на корректность отдельные
модули исходного кода программы, наборы из одного или более программных
модулей вместе с соответствующими управляющими данными, процедурами
использования и обработки.

47.

Стадии цикла разработки ПО
4. Документация
Существует
четыре
уровня
документации:
–
Архитектурная
(проектная)
–
например, дизайн-спецификация.
– Техническая – вся сопровождающая
разработку документация.
–
Пользовательская
–
включает
справочные и поясняющие материалы,
необходимые конечному пользователю для
работы с системой.
– Маркетинговая – включает рекламные
материалы,
сопровождающие
выпуск
продукта. Ее цель – в красочной форме
представить
функциональность
и
конкурентные преимущества продукта.

48.

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

49.

Стадии цикла разработки ПО
6. Внедрение и сопровождение