3.2.6 Модель быстрого прототипирования

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

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

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

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

Получив одобрение пользователя, быстрый прототип преобразуют де­тальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью дей­ствующей системой.

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

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

3.2.7 Agileметодологии

3.2.7.1 Описание методологии

Эти адаптивные модели также носят название моделей "скоростного" жизненного цикла (Bullock 2003). В 2001 году группой, состоявшей из 17 представителей пользователей этой адаптивной модели жизненного цикла был выпущен "Манифест скоростной разработки программного обеспечения", и эта инициатива получила широкое развитие в отрасли информационных технологий.

Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.

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

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

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

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

Если рассмотреть пары связей:

люди и взаимодействие - процессы и инструменты

работающий продукт - обширная документация

сотрудничество с заказчиком - детали контракта

готовность к изменениям - следование плану,

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

Существует более 15 agile методологий. Самые распространенные:

• XP

• Scrum

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

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

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

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

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

• Серия максимально коротких итераций, состоящих из шагов:

  • выбор реализуемых требований (в экстремальном программировании — пользовательских историй);

  • реализация только отобранных требований;

  • передача результата для практического использования;

  • короткий период оценки достигнутого (в зависимости от объема работ периода его можно назвать этапом или контрольным мероприятием).

• Фаза заключительной оценки разработки проекта.

Реальные быстрые методологии конкретизируют эту схему, дополняют ее теми или иными методиками.

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

Стремление к сертификации сдвигает границу между гибкими и жесткими методологиями в сторону последних, и есть опасения, что в результате быстрые подходы станут формализованными до такой степени, что их нельзя уже будет называть гибкими. Эта проблема отмечалась во многих докладах на конференции сторонников обсуждаемого подхода Extreme Programming and Agile Methods — XP/Agile Universe 2003.

Тем не менее в 2003 появилась компания, выполняющая проекты по методологии экстремального программирования, которая получила сертификат по одному из общепризнанных стандартов ISO 9001:2000, свидетельствующий об определенных гарантиях качества организации проектной деятельности и получаемых результатов. Это произошло по прошествии примерно года с момента подачи заявки на сертификацию. Все, что для этого потребовалось сделать, свелось к приведению соответствия между процессами экстремального программирования и поддерживаемыми стандартом. В остальном процедура сертификации не нарушила процессы производства программ в компании. Не потребовалось никакой настройки процесса, доведения его до требований стандарта. Не претерпела изменений база данных, в которой сохранялись пользовательские истории со сведениями о работе с ними. Документация, предназначенная для пользователей, построенная на базе априорного тестирования, признана соответствующей требованиям качества и т.д.

3.2.7.2 Экстремальное программирование - Extreme Рrogramming (XP)

Экстремальное программирование (Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. (авторы Кент Бек, Уорд Каннингем, Мартин Фаулер и другие, 1996-1999)

Двенадцать основных практики экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

• Короткий цикл обратной связи (Fine scale feedback)

  • Разработка через тестирование (Test driven development)

  • Игра в планирование (Planning game)

  • Заказчик всегда рядом (Whole team, Onsite customer)

  • Парное программирование (Pair programming)

• Непрерывный, а не пакетный процесс

  • Непрерывная интеграция (Continuous Integration)

  • Рефакторинг (Design Improvement, Refactor)

  • Частые небольшие релизы (Small Releases)

• Понимание, разделяемое всеми

  • Простота (Simple design)

  • Метафора системы (System metaphor)

  • Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)

  • Стандарт кодирования (Coding standard or Coding conventions)

• Социальная защищенность программиста (Programmer welfare):

  • 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

Ниже дано описание практик, которые активно используются и в других моделях для повышения качества продукта.

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

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

Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы.

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

Давая каждому программисту право изменять код, мы получаем риск появления ошибок, вносимых программистами, которые считают что знают что делают, но не рассматривают некоторые зависимости. Хорошо определённые UNIT-тесты решают эту проблему: если не рассмотренные зависимости порождают ошибки, то следующий запуск UNIT-тестов будет неудачным.

Заказчик всегда рядом. «Заказчик» в XP — это не тот, кто оплачивает счета, а тот, кто на самом деле использует систему. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

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

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

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

Цель рефакторинга - сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным. Рефакторинг следует отличать от оптимизации производительности. Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет ее работу.

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

Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи:

1. Необходимо добавить новую функцию, которая не достаточно укладывается в принятое архитектурное решение

2. Необходимо исправить ошибку, причины возникновения которой сразу не ясны

3. Когда сложно объяснить коллеге логику работы программы

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

1. Дублирование кода

2. Длинный метод

3. Большой класс

4. Длинный список параметров

5. "Завистливые" функции - это метод, который чрезмерно обращается к данным другого объекта

6. Избыточные временные переменные

7. Классы данных

8. Не сгруппированные данные

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

Требования к проекту:

• Исходные коды и все, что необходимо для сборки и тестирования проекта, хранится в репозитории системы управления версиями;

• Операции копирования из репозитория, сборки и тестирования всего проекта автоматизированы и легко вызываются из внешней программы

На выделенном сервере организуется служба, запускающая локальную сборку

• по внешнему запросу,

• по расписанию,

• по факту обновления репозитория, и др.

В случае сборки по расписанию (daily build —ежедневная сборка) дополнительно вводится система нумерации сборок. Обычно каждая сборка нумеруется натуральным числом, которое увеличивается с каждой новой сборкой.

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