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

1.

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

2.

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

3.

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

4.

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

5.

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

6.

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

7.

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

8.

Концептуальной основой объектно-ориентированного подхода
является объектная модель.
Основными принципами ее построения:
• инкапсуляция (encapsulation);
• наследование (inheritance);
• полиморфизм (polymorphism);
• абстрагирование (abstraction);
• модульность (modularity);
• иерархия (hierarchy).

9.

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

10.

Наследование — метод определения объектов, при котором
производные объекты (потомки) наследуют свойства (атрибуты и
действия) от своих родителей. Наследование свойств в объектноориентированном подходе понимается как наследование атрибутов
и методов, т. е. возможность использования в производном объекте
атрибутов и методов базового объекта.
Основными
понятиями
объектно-ориентированного
подхода являются объект и класс.
Объект — предмет или явление, имеющее четко
определенное
поведение
и
обладающие
состоянием,
поведением и индивидуальностью.
Структура и поведение схожих объектов определяют общий для
них класс.
Класс – это множество объектов, связанных общностью
структуры и поведения

11.

Полиморфизм — свойство объектов, при котором действие
с одинаковыми именами вызывает различное поведение для
различных объектов.
Полиморфизм предполагает
именования разных действий.
возможность
одинакового
Эта особенность имеет два аспекта:
• возможность одинакового именования статических
методов;
• возможность одинакового именования динамических
методов.

12.

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

13.

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

14.

Выделим 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) — метод, предполагающий бережное
отношение ко всем участникам процесса.

15.

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

16.

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

17.

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

18.

19.

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

20.

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

21.

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

22.

Модель Build&Fix

23.

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

24.

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

25.

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

26.

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

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

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

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

29.

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

30.

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

31.

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

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

33.

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

34. Эволюционная модель

35. Эволюционная модель

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

36.

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

37.

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

38.

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

39.

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

40. Модель RAD

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

41. Модель RAD

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

42.

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

43. Модель пошаговой разработки

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

44.

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

45.

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

46.

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

47.

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

48.

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

49.

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

50.

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

51.

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

52.

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

53.

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

54.

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

55.

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

56.

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

57.

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

58.

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

59.

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

60.

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

61.

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

62.

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

63.

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

64.

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