Лекция 4. Строгие и гибкие методологии разработки.

 

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

На практике применяется совмещение тех или иных элементов той или иной методологии – в зависимости от задач, предметной области, масштаба проекта, используемой технологии программирования и культуры разработки ПО, умений команды разработчиков все эти технологии применять.

 

Основное назначение методологий разработки ПО – способы преодоления «кризиса разработки ПО», способы обеспечения успешного построения качественных систем в срок и согласно остальным ограничениями проекта.

Известна шутка про взаимоотношения проектировщиков и заказчиков «быстро, дёшево, качественно – выберите любые два». Она показывает необходимость дополнительных усилий по обеспечению ВСЕХ характеристик качества, «треугольника качества». Поскольку требования качества у заказчика и исполнителя существенно отличаются: исполнителя интересует технические качества разрабатываемого продукта, и его востребованность; заказчика же прежде всего интересуют сложные, нефункциональные NFR требования и сложные же, интегральные и составные качества (например известное «соотношение цена/качество»).

Для управления этим внешним качеством для заказчика нужно выполнение процессов управления требованиями, управления ожиданиями (user needs ), оценка и обеспечение качества продукта (Q&A, Quality Assurance, а не только QC – Quality Control).

 

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

То есть, обеспечить выполнение всех «трёх из трёх» требований треугольника качества – в какой-то предсказуемой, контролируемой мере.

 

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

Из тех проектов, которые закончились успешно, было подсчитано: не более 30% занимает собственно программирование. Остальное занимает тестирование, отладка; работа с заказчиком по уточнению требований, проектирование архитектуры, документирование.

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

 

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

 

Системная инженерия – отрасль науки, изучающей решение инженерных задач как создание, разработку и совершенствование целостных систем. Системная инженерия единообразно изучает системы, возникающие при решении различных задач, потому что ЖЦ таких систем имеют сходные элементы. Одной из отраслей системной инженерии является программная инженерия (стандарты ISO 12207, ISO 24774, стандарты оформления документации ГОСТ ЕСПД и т.п.).

Разрабатывается «целевая система» – программная система, которая решает задачу.

«Обеспечивающей» по отношению к целевой является система, управляющая процессом разработки.

 

Сам процесс разработки в наиболее общем виде имеет следующие этапы ЖЦ разработки:

 

· Выясняются требования к системе, функциональные и нефункциональные
(что надо сделать? SR )

· Составляется техническое задание
(как надо сделать? FR + NFR, SBS )

· Оцениваются, проектируются технические решения и выбирается лучшая архитектура
(какова структура ядра системы?, SBS )

· Проектирование проводится до нужной степени детализации, вплоть до отдельных компонент.

o Определяются интерфейсы компонент

o Кодируются компоненты (программирование)

o Тестируются отдельные компоненты (модульное тестирование)

· Собираются компоненты в систему

o Проводится интеграционное тестирование

· Полученное решение оценивается на предмет полноты реализованных требований

o В ходе процесса управления релизами (выпусками) принимается решение об выпуске очередной версии

o Проводится функциональное и приёмочное тестирование

· Проводится поддержка пользователей, в ходе которой происходит доработка и исправление ошибок

o Выпускаются новые версии

o Проводится нагрузочное тестирование

· Если принято решение о «конце жизни продукта» , End Of Life – списание, отказ от дальнейшей поддержки. Как правило, при этом старая система заменяется новой и процесс повторяется заново.

 

Дальнейшим развитием технологии RAD, Rapid Application Development стал подход ALM, Application Lifecycle Management. Подход ориентирован на создание полноценного интегрированного инструментария, выполняющего все этапы ЖЦ разработки из «единой информационной среды».

 

Разработка также может осуществляться в ходе управления проектом. Но откуда берутся отдельные работы этого проекта?

Методика (научное понятие), или методология (программистское) – это указания, как применять теории о процессе разработки на практике.

Существует множество таких теорий: водопадная (waterfall), каскадная, спиральная (итеративная) модель.

 

Так, исторически наиболее древней является водопадная модель. В этой модели проект разработки состоит из последовательности работ ЖЦ, к следующей работе переходят только тогда, когда закончены все работы текущего этапа. Так, если выясняются требования к системе – необходимо тщательным образом их задокументировать, разработать и утвердить у заказчика достаточно подробное, понятное и непротиворечивое ТЗ, приступать к процессу разработки и надеяться, что требования заказчика за это время не изменятся. Иными словами, если нет окончательной, кристальной ясности к тому, что и как нужно построить – к работам не приступают. Это имеет смысл для разработки аппаратного обеспечения, программированию систем реального времени, промышленной автоматики – ведь затраты на исправление «ошибок проектирования» на нижних уровнях проекта будут гораздо, гораздо больше.
Такие методологии разработки называют строгими методологиями.

 

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

Далее рассмотрим строгую методику разработки согласно Rational Unified Process (просто Unified Process в новых открытых версиях методики, RUP в коммерческих).

 

Согласно этой методике [6], ЖЦ процесса разработки состоит из четырёх крупных фаз:

· Начало (Inception)

· Уточнение (Elaboration)

· Построение (Construction)

· Внедрение (Transition)

Фазы выполняются последовательно, наподобие конвейера. Процесс является

· Управляемым требованиями и риском

· Архитектуро-центричным

· Итеративным и инкрементным

 

Управляемость требованиями и риском означает, что необходимо осуществлять планирование релизов, реализуя требования согласно проставленным приоритетам. С учётом риска нарушения требования, с учётом полезности для релиза в целом.

 

Архитектуро-центричность означает, что ведётся разработка на основании артефактов (документов), описывающих проектные решения (архитектуру). Архитектура представлена в виде моделей, диаграмм UML. Новые модели разрабатываются из старых моделей. Когда архитектурного описания достаточно для перехода к следующей фазе, осуществляется переход.

 

Итеративность – разработка производится методом последовательного приближения, итерациями. Каждая следующая более полно удовлетворяет требованиям.

Инкрементность – следующая итерация добавляет новую функциональность и не «ломает» старую.

Для каждой фазы и процедуры определяются входные и выходные документы (артефакты), определяются их типовые формы.

Для планирования релизов используется метод сценариев использования:

– составляется диаграмма использования (взаимодействия), показывающая как именно пользователь (actor) будет работать с системой

– сценарий моделируется: выделяются сущности: классы, методы, компоненты, ответственность.

– выделяется требуемая функциональность (часть сценария использования)

– составляется матрица прослеживаемости требований:
 по строкам матрицы – требования, по колонкам – требуемая функциональность.

На пересечении получается часть архитектуры системы (подсистема), которая отвечает, каким образом выполняется данное требование; в ответ на какие требования необходима эта функциональность.

 Эта матрица позволяет определить противоречия и неоднозначности в требованиях и функциональности.

 

Таким образом, RUP описывает процесс разработки, основанный на UML диаграммах. В ходе этого процесса происходит следующее:

· Собираются требования к программной системе в ходе процесса управления требованиями

· Из требований выбираются нужные, важные, критичные, функциональные и нефункциональные и расставляются приоритеты

· Составляется документ «технические требования»: что нужно сделать?

· Из него составляется документ «техническое задание»: как решить задачу?

· Составляется набор диаграмм, описывающий техническое решение (как сделано) с нужной степенью детализации.

· На новом этапе процессов методологии RUP диаграммы старого этапа перерабатываются в новые диаграммы, пока их набор не будет достаточен для процессов разработки.

Процесс RUP (UP, Unified Process) описывает методологию разработки, то есть, процесс разработки на основе этапов жизненного цикла (ЖЦ) программной системы. В ходе этого процесса выполняются подпроцессы управления требованиями, уточнения, проектирования, построения (реализации) системы, документирования, развёртывания (установки и обучения пользователей).

Стандарт XMI предназначен для обмена между различными программами моделирования диаграммами заданных типов.

 

Таким образом, в ходе работы по RUP составляется модель проекта системы, модель архитектуры

 

Методологии разработки объясняют, как на практике должна применяться какая-то методика, теория процесса разработки.

 

Строгие методологии подразумевают последовательную работу над этапами ЖЦ разработки.

Гибкие методологии ставят целью оптимизацию проекта разработки за счёт:

· Упрощения процесса разработки архитектуры

· Более плотной работы с заказчиком в ходе процесса управления требованиями.

· Итеративной, инкрементальной работы над ЖЦ разработки

· Более гибкого процесса планирования выпусков (релизов).

 

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

Новые версии выпускаются согласно процессу планирования релизов.

 

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

 

Гибкие методологии разработки (XP, SCRUM, Crystal) делают акцент на важности процесса планирования релизов. Подразумевается более плотная работа с заказчиком для оценки важности требований, реализуемой функциональности. Применяются такие методы оценки, как игра в планирование (planning poker) в XP, спринты в SCRUM.

Требования и функциональность сортируются по приоритетам, и временным затратам на реализацию.

Такую оценку проводит исполнитель-разработчик, и заказчик, потом приходят к консенсусу относительно оценок. Отобранные требования включаются в очередной релиз, который выпускается после очередной итерации.

XP (Экстремальное программирование) предлагает методики, которые могут сократить время проектирования, улучшить взаимозаменяемость программистов, обеспечить понимаемость требований и системы всеми участниками команды (программирование в паре, pair programming). В ходе программирования в паре программист-новичок прикрепляется к более опытному, они совместно реализуют (программируют) очередное требование, но работу выполняет один; другой наблюдает, и задаёт вопросы и предлагает лучшие варианты. Затем программисты в паре меняются – следующее требование реализует другой, второй наблюдает.

 

Существенное отличие SCRUM от XP состоит в том, что в SCRUM планирование разработки осуществляется на основании спринтов (sprint) – итераций, в начале которых отбираются требования для реализации, фиксируются и изменяться в текущей итерации не будут. Затем, после демонстрации прототипа заказчику заказчик утверждает релиз, подтверждает что реализованы все нужные требования в этой версии. Или он может инициировать переделку, или отложить реализацию требования на следующую итерацию.

FDD, или Feature-Driven Development, разработка по функциям – подход, при котором функциональность и приоритеты в её реализации является основой процесса разработки.

 

Разработка через тестирование (TDD) – подход, когда сначала пишутся тесты, потом код, который проходит тесты, которые переделываются, когда в результате доработок код изменяется. Таким образом, тесты выступают в качестве документации, примеров по использованию остальной части программы. Это открывает возможность к

 

Рефакторингу – переработке старого, непонятного, громоздкого кода, который сложно поддерживать. Рефакторинг сохраняет поведение кода, улучшая его структуру и «понятность». Качеству «понятности» полностью соответствует «чистый код».

 

 Задача рефакторинга – ликвидация «технических долгов», улучшение понятности, сопровождаемости системы.

 

Модульное, или юнит-тестирование – тесты компонент, которые пишутся в соответствии с подходом TDD.

Затем проводится интеграционное тестирование системы в целом, собранной из протестированных компонент.

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

 

Для автоматизации процесса компиляции, настройки, сборки, установки у конечного пользователя применяется процесс непрерывной интеграции, CI Continuous Integration. В ходе процесса инструментарий автоматически запускает процессы извлечения кода из системы контроля версий, конфигурирования, процессы сборки, настройки, запуска тестов в автоматическом режиме, подготовку инсталлятора, генерацию отчётов программисту.

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