Практическая работа №3. Тема: определение требований к программному обеспечению и исходных данных для его проектирования. Модели процесса разработки.

Трудности конструирования реальных приложений обусловлены их сложностью, и крити­ческую роль в преодолении этой сложности играет сам процесс конструирования. В настоящее время можно выделить три стратегии конструирования модели процесса [8].

• Линейная стратегия. Требования определены в начале разработки, и выпуск про­граммного обеспечения производится один раз в конце разработки.

• Итерационная стратегия. Требования также определены в начале разработки, но выпуск версий программного обеспечения производится многократно по ходу раз­работки.

• Эволюционная стратегия. Выпуск версий программного обеспечения производит­ся многократно по ходу разработки, но требования не определены в начале разра­ботки, они определяются по ходу разработки.

Свойства указанных стратегий можно свести в табл. 3.

Далее рассматриваются некоторые известные модели, представляющие каждую из упомя­нутых стратегий.

3.1. Водопадные и конвейерные модели

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

• Анализ требований состоит в сборе требований к продукту. Результатом анализа, как правило, является некоторый текст или модель использования.

• Проектирование описывает внутреннюю структуру продукта. Обычно такое описа­ние дается в форме диаграмм и текстов.

• Реализация - это программирование. Результатом реализации является программ­ный код всех уровней, будь то код, генерируемый высокоуровневой системой про­граммирования, компилятором языка четвертого поколения или какой-либо дру­гой.

• Тестирование - это процесс сборки всего продукта из отдельных частей и провер­ки того, что требования удовлетворены.

Замечание. Модель водопада (конвейера) является исторически первой осознанно использованной мо­делью процесса разработки программного обеспечения. Многие очень крупные проекты бы­ли успешно проведены с использованием этой модели.

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

3.2. Спиральные и инкрементные модели

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

Замечание. Модель конвейера, также как и спиральная модель, может использовать вехи. Характерным для модели конвейера (водопада) является безвозвратный (не итеративный) характер про­цесса, в то время как в спиральных и инкрементных моделях мы вновь и вновь повторяем последовательность фаз. Таким образом, рассматриваемые модели относятся к итерацион­ной стратегии.

Иногда представляется возможным понемногу продвигать проект вперед при практически непрерывном процессе. Такая модель процесса особенно полезна на поздних стадиях про­екта, когда продукт находится на сопровождении или когда разрабатываемый продукт очень схож с созданным ранее. Например, процесс, используемый в некоторых отделени­ях корпорации Microsoft, предусматривает обновление программного кода и документа­ции ежедневно к конкретному времени для интеграции и ночного тестирования.

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

Для организации инкрементальной разработки обычно выбирается характерный временной интервал, на­пример неделя. Затем в течение этого интервала происходит обновление исходного проек­та (документации, набора тестов, программного кода и т. д.).

Наиболее известной инкрементной моделью является Унифицированный процесс (Ra­tional Unified Process).

0. Гибкие модели процесса разработки

Самой яркой моделью гибкой разработки сейчас, видимо является экстремальное программирование, предложенное Кентом Беком.

Кент Бек (Kent Beck) - пионер экстремального программирования. Практикующий разработчик, менеджер и автор нескольких книг по экстремаль­ному программированию, применению образцов проектирования и гибким процессам разработки.

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

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

Вообще говоря, экстремальное программирование использует многие известные ранее ме­тодики, но применяет из максимально интенсивным, экстремальным образом.¹⁷ Ключе­выми методиками экстремального программирования принято считать следующие.

• Динамическое планирование (planning game) - быстро сформировать приблизитель­ный план работы и постоянно обновлять его по мере того, как условия задачи ста­новятся все более четкими. Если со временем план перестает быть актуальным, он должен быть обновлен.

• Частые выпуски (small releases) - самая первая упрощенная версия быстро сдается заказчику, после чего через относительно короткие промежутки времени (неделя-две недели) происходит выпуск новых версий.

• Архитектурная метафора (system metaphor) -простая и понятная заказчику кон­цепция системы.

• Простое проектирование (simple design) - в каждый момент времени система должна быть спроектирована так просто, как это возможно, так как заказчик может изменить функциональность.

• Опережающее тестирование (testing) - для любой программы должны существо­вать автоматические тесты. Любая функция системы, для которой нет тестов, счи­тается несуществующей. Не должно существовать кода без тестов.

• Рефакторинг (refactoring) - постоянное улучшение качества кода с сохранением функциональности.

• Парное программирование (pair programming) - весь код пишется двумя програм­мистами, работающими на одном компьютере.

• Коллективное владение кодом (collective ownership) - любой разработчик может улучшать любой код системы в любое время.

• Непрерывная интеграция (continuous integration) - как только код написан и про­тестирован, он интегрируется в общую систему. После интеграции код обновляется у всех разработчиков, т.е. в любой момент времени все разработчики работают с актуальной версией кода.

• 40-часовая рабочая неделя (no overtime) - внеурочная работа способствует ухуд­шению психологического климата в команде. Невозможность планирования рабо­чего времени отрицательно сказывается на результатах работы.

• Доступный заказчик (on-site customer) - в команде все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы.

• Стандарты кодирования (coding standards) - весь код должен быть написан в еди­ном стиле.

В экстремальном программировании применяются и многие другие методики, но по край­ней мере перечисленные должны применяться совместно и интенсивно, иначе эффект не будет достигнут.