Модели жизненного цикла в некоторых реальных методологиях программирования
В монографии по экстремальному программированию [3] Бек жизненный цикл экстремального программирования описывает, не прибегая к схемам. Словесно описывая деятельности разработчиков, он дает картину процесса, не требующую иллюстраций. Тем не менее построить такую схему несложно, и это полезно сделать хотя бы для сопоставления моделей (Бек говорит не о моделях, а об идеальном проекте). Мы приводим модель жизненного цикла проекта в экстремальном программировании в представлении, которое исходит из гантеровских изобразительных средств (см. рис. 11.3).
Из схемы видно, что начальная фаза развития проекта включает в себя некоторое число итераций без выпуска релиза. Это период, когда просто невозможно предоставить систему пользователям. В качестве его задач указывается изучение применяемых инструментов, постановка экспериментов с целью определения и последующего построения стартового варианта архитектурного скелета системы, а также, возможно, освоение методик экстремального программирования командой. Бек выделяет первое внедрение системы в эксплуатацию как особое событие, которое стоит отметить праздничными мероприятиями. В экстремальном программировании подобные мероприятия и другие меры поощрительного воздействия на коллектив занимают существенное место среди менеджерских задач.
Серия итераций — это стационарный период развития проекта, в котором появляется деятельность , связанная с обслуживанием и поддержкой. В отличие от жестких методологий, при экстремальном программировании эти задачи не становятся дополнительной нагрузкой для разработчиков, поскольку методика взаимодействия с заказчиком обеспечивает нужное, актуальное для пользователей развитие работ .
Как только в проекте исчерпывается постоянно пополняемый пул заказываемых для реализации пользовательских историй, исчезает стимул для развития проекта. Эту ситуацию Бек называет смертью проекта. Со смертью проекта использование построенной системы не прекращается. Напротив, отсутствие новых требований к ней свидетельствует о том, что пользовательские нужды обеспечены адекватной поддержкой. Но возможны и другие, менее оптимистичные причины для «смерти». Это либо переход пользователей к применению конкурирующей разработки, которая оказалась более подходящей, либо невозможность в разумные сроки реализовать необходимые возможности системы ( по сути дела, обе причины означают одно и то же). Во всех случаях смерть проекта надо достойно встретить. Соответствующие работы указаны на схеме.
В модели отмечены контрольные точки, связанные с событиями проекта. Смысл их вполне понятен, а конкретизация соответствующих мероприятий привела бы к пересказу подхода в своей интерпретации. По этой же причине мы не станем обсуждать производственные функции и систему деятельностей, которую можно восстановить из описания методологии экстремального программирования .
Отметим, что с точностью до 12 методик, которые объявляются Беком как суть подхода, [3] при изучении этой методологии вполне применимы общие понятия, рассмотренные раньше. Так, деятельность менеджера экстремального проекта в полной мере иллюстрирует следование принципу выяснения отклонений и корректировки траектории (см. лекцию 5).
Методология экстремального программирования является характерным примером использования стратегии сужения задачи проекта за счет итеративного наращивания возможностей. Обратившись к представленной ранее схеме итеративного наращивания (см. рис. 5.4), можно заметить, что в данном подходе конкретизировано движение требований таким образом, чтобы получить ясные и точные критерии их отбора для реализации с помощью апелляции к заказчику. Из этого следуют и границы применимости подхода: когда заказчик плохо представляет, что фактически нужно для поддержки деятельности пользователя, а для аналитического исследования проблем автоматизируемой деятельности возможности нет, экстремальное программирование будет давать сбои. Если воспользоваться метафорой вождения автомобиля, то можно сказать, что этот подход хорошо работает в условиях шоссе, но не на бездорожье.
7 Вопрос. Модели жизненного цикла по. Экстремальное программирование (xp).
— сориентирована на малочисленную группу программистов высокой квалификации, которые приступают к разработке программного продукта с изначально неопределенными или часто меняющимися требованиями.
Ключевые концепции XP:
1. Постановка задачи только по определенным в настоящее время требованиям.
Задача ставится согласно тем требованиям, которые в данный момент выдвинуты или сформулированы настолько однозначно и четко, что или уже детализированы (формализированны), или в кратчайшее время могут быть детализированы на уровне, позволяющем быстро выполнить программную реализацию соответствующему функционалу.
2. Проектирование максимально простой архитектуры продукта.
Программа проектируется настолько просто, насколько это возможно без опережающего учета возможного в будущем функционала.
В архитектуру закладываются только те функции, которые необходимы и точно определены в данный момент.
3. Максимально быстрое получение первой работающей версии программы.
[Такую версию называют «Рыба»]4. Разработка на основе тестов.
5. Коррекция ТЗ и архитектуры программы.
6. Систематические сборки с тестированием и отладкой.
Разработка программного продукта выполняется короткими временными отрезками, и после завершения очередного отрезка выполняется сборка программы с тестированием и отладкой. Такой пошаговый контроль облегчает локализацию и устранение ошибок.
7. Частая подготовка промежуточных версий продукта.
8. Рефакторинг (регулярная переработка кода).
Оптимизация кода программистами с целью внедрения более эффективных алгоритмов. После каждой такой оптимизации программа проходит проверку на тестах, которая гарантирует сохранение работоспособности продукта.
9. Программирование в паре.
Программная реализация каждого выделенного фрагмента выполняется кодерами. Один занимается кодированием, другой анализирует работу первого, оценивая выборные алгоритмы и их реализацию, предлагая более эффективные решения, отслеживая качество кода и т. д.
10. Соблюдение единого стандарта кодирования.
Стандарт кодирования — набор правил и соглашений, используемых при написании исходного кода на некотором языке программирования.
Наличие общего стиля программирования:
— облегчает понимание и поддержание исходного кода, написанного более чем одним программистом;
— упрощает взаимодействие нескольких человек при разработке программного обеспечения.
— стандарт кодирования на языке Си, получивший сокращённое наименование K&R, Кернигана и Ритчи.
— стандарт кодирования на C# от Microsoft.
— стандарт кодирования на Java от Sun Microsystems.
11. Взаимодействие с заказчиком.
Получение ответов на вопросы.
Экстремальное программирование.
— большая гибкость, динамичность.
— высокое качество многократной отладки кода.
— минимальный объем сопроводительной документации.
— трудоемкость подхода (частое тестирование, отладка, рефакторинг).
— плохо поддается планированию (с точки зрения определенного конечного срока сдачи проекта).
C3. Chrysler Comprehensive Compensation System.
(Система, построенная с использованием языка программирования SmallTalk и объектно-ориентированной системой управления базами данных GemStone; проект стартовал в 1993 г., закрыт в 1999/2000 году; создатель — Том Хэдвилд (Tom Hadfield).)
Экстремальное программирование (xp)
Экстремальное программирование(ЭП,XP – eXtreme Programming) – живой подход, предложенный К. Беком.
Возникновение ЭП тесно связано с выполнением проекта C3(букв. Всеобъемлющее компенсирование дляChrysler) – разработка системы учёта выплат работникам фирмыDaimler Chrysler. Суть проекта заключалась в разработке единой системы вместо множества разрозненных приложений. Именно на этом проекте К. Беком отрабатывались практики, лёгшие в основу подхода. В создании ЭП и работе над проектом приняли также участие У. Каннингем и Р. Джефрис. В 1996 г. Бек стал руководить проектом, но в 2000 г. фирма прервала проект. Полученная к этому моменту система использовалась только для 10 тысяч человек из 87 тысяч работников. Поэтому успешный на словах проект на самом деле оказался провальным. Главной причиной этого является не сам подход, а его применение к неподходящему проекту. Для реализации проектаC3(разработки формализуемой системы) необходимо было использовать один из строгих подходов. В 1999 г. вышло первое издание К. Бека «Экстремальное программирование в объяснении: Избирание изменения», а в 2004 г. – второе издание этой книги в соавторстве с Ц. Андрес, переработанное с учётом опыта применения ЭП.
В ЭП гораздо больше спорных моментов, чем в каком-либо другом подходе. Ключевой и основополагающей деятельностью в ЭП считается кодирование, поэтому подход во многом использует идею непланируемой модели – «кодирование – исправление»,– расширяя её принципами эффективной организации работ. Эти принципы доводятся до крайности их реализации в используемых практиках.
При этом практики ЭП оказываются слишком тесно взаимосвязанными, что приводит к излишней жёсткости подхода. Практики считаются фиксированной частью, в то время как ЖЦ системы – адаптивной частью ЭП, что противоречит логике разработки и приводит к проблемам в проектах, использующих этот подход.
Основы подхода
ЭП представляется в виде тройки категорий, с помощью которых описываются стратегии подхода: ценности, принципы и практики. Ценности выражают общую направленность ЭП и конкретизируются в принципах, соответствие которым служит мерой приемлемости и отбора практик для этого подхода.
Жизненный цикл проекта
В ЭП рассматривается модель ЖЦ идеального проекта для ЭП (рис.4.17).
Согласно этой модели выделено 5 фаз ЖЦ: 1. Исследование;2. Планирование;3. Реализация / Итерации;4. Продуцирование / Обслуживание;5. Смерть.
Рис.4.17. Схема модели ЖЦ для подходаXP
На фазе 1выполняется предварительная подготовка к работе, в рамках которой можно выделить следующие операции:
1. Команда выбирает инструменты, осваивает необходимые знания и навыки, анализирует варианты архитектур системы, оценивает будущие задачи.
2. Заказчик готовит истории, сразу же обсуждаемые командой, формируя из них базисный набор историй, который будет реализован в выпуске продукта.
На фазе 2выполняются планирование работы по созданию системы и планирование текущего выпуска продукта. Планирование работы предполагает в частности соглашение о сроках поставки первого выпуска. Планирование выпуска основано на отборе приоритетных историй из базисного набора, которые будут реализованы в очередном выпуске.
Планирование работы и выпуска основано на наблюдении за четырьмя ограничениями, названными в ЭП переменными: стоимость, время, качество и содержание. Заказчиком должно фиксироваться не более трёх переменных, а команда выбирает результирующие значения остальных переменных.
На фазе 3выполняются итерации разработки и функциональное (приёмочное) тестирование системы. Итерации разработки предназначены для реализации историй в рамках плана выпуска и формирования функциональных тестов. В ходе первой итерации формируется общий дизайн, для которого отбираются подходящие истории, для остальных итерации отбор историй выполняется заказчиком. Функциональное тестирование позволяет получить одобренный заказчиком выпуск, включающий истории с учётом плана выпуска.
На фазе 4выполняются развёртывание системы в реальной среде эксплуатации и её обслуживание. Во время развёртывания и обслуживания системы заказчик может сформировать новый набор историй для их включения в следующий выпуск продукта.
На фазе 5завершается эксплуатация системы. Это может произойти по двум причинам: 1. У заказчика нет историй для новых выпусков продукта; 2. Система находиться в плохом состоянии из-за большого числа дефектов.
На протяжении этих фаз ЖЦ выполняются 4 деятельности, связанные с программированием: 1. Кодирование;2. Тестирование;3. Слушание;4. Проектирование. Основой для всех деятельностей является программный код системы.