методологииx

Rational Unified Process
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.
В основе RUP лежат следующие принципы:
Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов
(вариантов использования)).
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Жизненный цикл разработки
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная
команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить
промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на
меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество
создаваемого продукта.
Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько
итераций:
Графическое представление процесса разработки по RUP
1. Начало (Inception)
В фазе Начало:
Формируются видение и границы проекта.
Создается экономическое обоснование (business case).
Определяются основные требования, ограничения и ключевая функциональность продукта.
Создается базовая версия модели прецедентов.
Оцениваются риски.
При завершении начальной фазы оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое
предполагает соглашение заинтересованных сторон о продолжении проекта.
2. Уточнение (Elaboration)
В фазе уточнение производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
Документирование требований (включая детальное описание для большинства прецедентов). Спроектированную, реализованную и
оттестированную исполняемую архитектуру. Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
Сниженные основные риски. Успешное выполнение фазы разработки означает достижение вехи архитектуры жизненного цикла (англ.
Lifecycle Architecture Milestone).
3. Построение (Construction)
Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение завершается первым
внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).
4. Внедрение (Transition)
Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя
программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не
соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова.
Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.
Microsoft Solutions Framework (MSF)
— методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт
Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.
Модель проектной группы MSF разрабатывалась в течение нескольких лет и возникла в результате осмысления недостатков
пирамидальной, иерархической структуры традиционных проектных групп.
В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют
между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на
нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к
качеству работы и желание самосовершенствоваться.
Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы.
MSF включает в себя ряд основных принципов. Вот те из них, которые имеют отношение к успешной работе команды:
Распределение ответственности при фиксации отчетности
Наделяйте членов команды полномочиями
Концентрируйтесь на бизнес-приоритетах
Единое видение проекта
Проявляйте гибкость — будьте готовы к переменам
Поощряйте свободное общение
Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts):
Команда соратников
Сфокусированность на нуждах заказчика
Нацеленность на конечный результат
Установка на отсутствие дефектов
Стремление к самосовершенствованию
Заинтересованные команды работают эффективно
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают
модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из её ролевых кластеров, определяемых
моделью, ассоциирован с одной из упомянутых шести целей и работает над её достижением.
В проектную группу входят такие ролевые кластеры:
управление программой
управление продуктом
разработка
тестирование
управление релизом
удовлетворение потребителя
Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры
называются просто ролями. Но в любом случае суть концепции остается той же — построить основу производственных отношений и
связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд
любого проекта.
Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за:
управление программой (program manager) — разработку архитектуры решения, административные службы;
разработку (developer) — разработку приложений и инфраструктуры, технологические консультации;
тестирование (QAE) — планирование, разработку тестов и отчетность по тестам;
управление выпуском (release manager) — инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;
удовлетворение заказчика (user experience) — обучение, эргономику, графический дизайн, техническую поддержку;
управление продуктом (product manager) — бизнес-приоритеты, маркетинг, представительство интересов заказчика.
Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести — один человек может
совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта, его
сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Минимальный коллектив
по MSF может состоять всего из трех человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер.
Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум
одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически
оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.
В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:
Роль команды разработчиков не может быть объединена ни с какой другой ролью.
Избежание сочетания ролей, имеющих предопределенные конфликты интересов.
Как и в любой другой командной деятельности, подходящая комбинация ролей зависит от самих членов команды, их опыта и
профессиональных навыков. На практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно
и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.
MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы,
которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:
ответственность за управление проектом распределенная между лидерами ролевых кластеров внутри команды — каждый член
проектной группы отвечает за общий успех проекта и качество создаваемого продукта.
профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над
ней — в эффективно работающей команде каждый её член имеет необходимые полномочия для выполнения своих обязанностей и
уверен, что получит от коллег все необходимое.
Как следует из вышесказанного, одна из характерных особенностей MSF — отсутствие должности менеджера проекта!
Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы
направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия . Кроме того, когда
ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем
объединяются в ролевые кластеры.
Использование ролевых кластеров не подразумевает и не навязывает никакой специальной структуры организации или обязательных
должностей. Административный состав ролей может широко варьироваться в разных организациях и проектных группах. Чаще всего
роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей
или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение
работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.
Модель проектной группы MSF не обеспечивает успех сама по себе. Есть много других факторов, определяющих успех или неудачу
проекта, но структура проектной группы, безусловно, вносит существенный вклад.
Подходящая структура команды является фундаментом успеха, и реализация модели MSF с использованием лежащих в её основе
принципов поможет сделать проектные группы более эффективными и, как следствие, более успешными.
Модеь процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой
модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при
разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей:
каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена ещё одним инновационным аспектом: она
покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой
подход помогает проектным группам сфокусировать свое внимание на бизнес-отдаче (business value) решения, поскольку эта отдача
становится реальной лишь после завершения внедрения и начала использования продукта.
Модел процессов включает такие основные фазы процесса разработки:
Выработка концепции (Envisioning)
Планирование (Planning)
Разработка (Developing)
Стабилизация (Stabilizing)
Внедрение (Deploying)
В рамках MSF программный код, документация, дизайн, планы и другие рабочие материалы создаются, как правило, итеративными
методами. MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности.
Затем к решению добавляются все новые и новые возможности. Такая стратегия именуется стратегией версионирования. Несмотря на
то, что для малых проектов может быть достаточным выпуск одной версии, рекомендуется не упускать возможности создания для
одного решения ряда версий. С созданием новых версий эволюционирует функциональность решения.
Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. «Живые» документы
(living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках
MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут
быть использованы для планирования и контроля процесса разработки.
Решение не представляет бизнес-ценности, пока оно не внедрено. Именно по этой причине модель процессов MSF содержит весь
жизненный цикл создания решения, включая его внедрение — вплоть до момента, когда решение начинает давать отдачу.]
Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного
обеспечения.
Двенадцать основных приёмов экстремального программирования (по первому изданию книги 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)
Тестирование
В XP особое внимание уделяется двум разновидностям тестирования:
тестирование модулей (unit testing);
приемочное тестирование (acceptance testing).
Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей
разрабатываемой им системы. Тесты модулей позволяют разработчикам убедиться в том, что их код работает корректно. Они также
помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода и как он функционирует. Тесты модулей также
позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring).
Приемочные тесты позволяют убедиться в том, что система действительно обладает заявленными возможностями. Кроме того,
приемочные тесты позволяют проверить корректность функционирования разрабатываемого продукта.
Для XP более приоритетным является подход называемый TDD (Test Driven Development), сначала пишется тест, который не проходит,
затем пишется код, чтобы тест прошел, а уже после делается рефакторинг кода.
Игра в планирование
Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того,
как условия задачи становятся все более четкими. Артефактами игры в планирование является набор бумажных карточек, на которых
записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких
небольших версий продукта. Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным,
является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие
технических решений. Если не выполняется это правило, весь процесс распадается на части.
Заказчик всегда рядом
«Заказчик» в XP — это не тот, кто оплачивает счета, а тот, кто на самом деле использует систему. XP утверждает, что заказчик должен
быть всё время на связи и доступен для вопросов.
Парное программирование
Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один
из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего.
При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы:
рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом,
парное программирование усиливает взаимодействие внутри команды.
Непрерывная интеграция
Если вы будете выполнять интеграцию разрабатываемой системы достаточно часто, вы сможете избежать большей части связанных с
этим проблем. В традиционных методиках интеграция, как правило, выполняется в самом конце работы над продуктом, когда
считается, что все составные части разрабатываемой системы полностью готовы. В XP интеграция кода всей системы выполняется
несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.
Рефакторинг
Рефакторинг (refactoring) — это методика улучшения кода, без изменения его функциональности. XP подразумевает, что однажды
написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. Разработчики XP безжалостно
переделывают написанный ранее код для того, чтобы улучшить его. Этот процесс называется рефакторингом. Отсутствие тестового
покрытия провоцирует отказ от рефакторинга, в связи с боязнью поломать систему, что приводит к постепенной деградации кода.
Частые небольшие релизы
Версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как
можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса.
Чем раньше мы выпустим первую рабочую версию продукта, тем раньше заказчик начнет получать за счет нее дополнительную
прибыль. Следует помнить, что деньги, заработанные сегодня, стоят дороже, чем деньги, заработанные завтра. Чем раньше заказчик
приступит к эксплуатации продукта, тем раньше разработчики получат от него информацию о том, что соответствует требованиям
заказчика, а что — нет. Эта информация может оказаться чрезвычайно полезной при планировании следующего выпуска.
Простота дизайна
XP исходит из того, что в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не
следует проектировать заблаговременно целиком и полностью. Если в самом начале работы вы пытаетесь от начала и до конца
детально спроектировать систему, вы напрасно тратите время. XP предполагает, что проектирование — это настолько важный процесс,
что его необходимо выполнять постоянно в течение всего времени работы над проектом. Проектирование должно выполняться
небольшими этапами, с учетом постоянно изменяющихся требований. В каждый момент времени мы пытаемся использовать
наиболее простой дизайн, который подходит для решения текущей задачи. При этом мы меняем его по мере того как условия задачи
меняются.
Метафора системы
Архитектура — это некоторое представление о компонентах системы и о том, как они взаимосвязаны между собой. Разработчики
используют архитектуру для того, чтобы понять, в каком месте системы добавляется некоторая новая функциональность и с чем будет
взаимодействовать некоторый новый компонент.
Метафора системы (system metaphor) — это аналог того, что в большинстве методик называется архитектурой. Метафора системы дает
команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты и
какую форму они должны принять.
Подобрав хорошую метафору, вы облегчаете команде понимание того, каким образом устроена ваша система. Иногда сделать это не
просто.
Стандарты кодирования
Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:
члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом;
обеспечивается эффективное выполнение остальных практик.
Если в команде не используются единые стандарты кодирования, разработчикам становится сложнее выполнять рефакторинг; при
смене партнеров в парах возникает больше затруднений; в общем и целом, продвижение проекта затрудняется. В рамках XP
необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает
унифицированно, как один человек. Команда должна сформировать набор правил, а затем каждый член команды должен следовать
этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объемным. Задача состоит в
том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды. Стандарт
кодирования поначалу должен быть простым, затем он будет эволюционировать по мере того, как команда обретает опыт. Вы не
должны тратить на предварительную разработку стандарта слишком много времени.
Коллективное владение
Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый
вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных
парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том,
что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.
Давая каждому программисту право изменять код, мы получаем риск появления ошибок, вносимых программистами, которые считают
что знают что делают, но не рассматривают некоторые зависимости. Хорошо определённые UNIT-тесты решают эту проблему: если
нерассмотренные зависимости порождают ошибки, то следующий запуск UNIT-тестов будет неудачным.
Водопадная (каскадная, последовательная) модель
Основная статья: Модель водопада
Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает
последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное
завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в
виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта
документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
Формирование требований;
Проектирование;
Реализация;
Тестирование;
Внедрение;
Эксплуатация и сопровождение.
Преимущества:
Полная и согласованная документация на каждом этапе;
Легко определить сроки и затраты на проект.
Недостатки:
В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей
фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится
«откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто
к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению
современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит
через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а
ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в
реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы[2]. Таким образом,
водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших
систем[3].
Итерационная модель
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative
and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют
итеративной моделью и инкрементальной моделью[4].
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает
«мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с
проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность,
определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю
требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент
— к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в
данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения[3].
По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания
сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко
определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело
все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной
связи и исправлять возможные ошибки в проекте»[4].
Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание
возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть
сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически
объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»[3].
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).
Спиральная модель
Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле
Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом
прототипирования.
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается
качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
риск превышения сроков и стоимости проекта;
необходимость выполнения ещё одной итерации;
степень полноты и точности понимания требований к системе;
целесообразность прекращения проекта.
Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально
проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной
модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID[3].
Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию
жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
Перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
Разрыв в квалификации специалистов разных областей.
В сегодняшней спиральной модели определён следующий общий набор контрольных точек[5]:
Concept of Operations (COO) — концепция (использования) системы;
Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;
Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры
целевой программной системы;
Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;
Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.
Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется
разработка программного обеспечения. Существует несколько подобных методик.
Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов,
называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в
миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ
требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна
для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По
окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе,
иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный
представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент).
Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы
уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как
недисциплинированных.
Принципы
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile
Manifesto[1]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды.
Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Манифест
подписали представители следующих методологий Extreme programming, Scrum, DSDM, Adaptive Software Development, Crystal Clear,
Feature-Driven Development, Pragmatic Programming.[2] Agile Manifesto cодержит 4 основные идеи и 12 принципов. Примечательно что,
Agile Manifesto не содержит практических советов.
Основные идеи:[3]
Личности и их взаимодействия важнее, чем процессы и инструменты;
Работающее программное обеспечение важнее, чем полная документация;
Сотрудничество с заказчиком важнее, чем контрактные обязательства;
Реакция на изменения важнее, чем следование плану.
Принципы, которые разъясняет Agile Manifesto[4]:
удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее ПО — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
постоянное внимание на улучшение технического мастерства и удобный дизайн;
простота — искусство НЕ делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам.
Cleanroom Software Engineering (методология «чистой комнаты») — процесс разработки программного обеспечения,
предназначенный для создания программного обеспечения с сертифицируемым уровнем надёжности. Cleanroom был первоначально
разработан Харланом Миллзом и несколькими его коллегами, в том числе Аланом Хевнером из IBM. Основной принцип cleanroom
состоит в том, что предупреждение дефектов лучше, чем их устранение. Название Cleanroom («чистая комната») взято из электронной
промышленности — так называются помещения с высокой степенью защиты от загрязнений, позволяющие предотвратить появление
дефектов в процессе производства полупроводников. Впервые процесс был применён в середине-конце 80-х годов.
Основные принципы
Разработка программного обеспечения основывается на формальных методах.
Инкрементальная реализации в рамках статистического контроля качества
Статистическое тестирование
Формальная верификация
Итеративный подход (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных
результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит
повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).
Преимущества итеративного подхода:
снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;
организация эффективной обратной связи проектной команды с потребителем (а также заказчиками, стейкхолдерами) и создание
продукта, реально отвечающего его потребностям;
акцент усилий на наиболее важные и критичные направления проекта;
непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;
раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;
более равномерная загрузка участников проекта;
эффективное использование накопленного опыта;
реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в
его успешном завершении.
Пример реализации итеративного подхода — Rational Unified Process.
RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания средств разработки
программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса,
позволяющего программисту максимально быстро создавать компьютерные программы. С конца XX века RAD получила широкое
распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования.
Основные принципы RAD
Инструментарий должен быть нацелен на минимизацию времени разработки.
Создание прототипа для уточнения требований заказчика.
Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.
Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.
Управление проектом должно минимизировать длительность цикла разработки.
Спиральная модель, предложенная Барри Боэмом в 1988 году, стала существенным прорывом в понимании природы разработки ПО.
Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное
прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы
жизненного цикла: анализ и проектирование. Отличительной особенностью этой модели является специальное внимание рискам,
влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:
Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
«Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
«Разрыв» в квалификации специалистов разных областей знаний.
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной
команде.
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и
характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и
последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до
реализации. Каждый виток разбит на 4 сектора:
оценка и разрешение рисков,
определение целей,
разработка и тестирование,
планирование.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый
продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает
объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить
на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую
работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы
работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального
цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый
из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена.
План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из
возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в
последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под
этим ермином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и
реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз:
фаза определения требований и анализа;
фаза проектирования;
фаза реализации;
фаза внедрения.
Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В условиях, когда бизнес цели таких проектов
могут измениться, но требуется разработка стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и
устойчивости, имеет смысл применение Spiral Architecture Driven Development. Данная методология, включающая в себя лучшие идеи
спиральной модели и некоторых других, позволяет существенно снизить архитектурные риски, что является немаловажным фактором
успеха при разработке крупных систем.
Каскадная модель (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки
выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции
и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; забавно,
что сам Ройс использовал итеративную модель разработки.
Содержание модели
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки
этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.
В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:
Определение требований
Проектирование
Конструирование (также «реализация» либо «кодирование»)
Интеграция
Тестирование и отладка (также «верификация»)
Инсталляция
Поддержка
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается
этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью
определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для
программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено,
программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных
компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены,
производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях
разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и
устранение ошибок.
Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и
успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.
Тем не менее, существуют модифицированные каскадные модели (включая модель самого Ройса), имеющие небольшие или даже
значительные вариации описанного процесса.
V-Model (или VEE модель) является моделью разработки информационных систем (ИС), направленной на упрощение понимания
сложностей, связанных с разработкой систем. Она используется для определения единой процедуры разработки программных
продуктов, аппаратного обеспечения и человеко-машинных интерфейсов.
Концепция V-образной модели была разработана Германией и США в конце 1980-х годов независимо друг от друга:
Немецкая V-модель была разработана аэрокосмической компанией IABG в Оттобрунне рядом с Мюнхеном в содействии с
Федеральным департаментом по закупке вооружений в Кобленце, для Министерства обороны Германии. Модель была принята
немецкой федеральной администрацией для гражданских нужд летом 1992.[1]
Американская V-Model (VEE) была разработана национальным советом по системной инженерии (международным — с 1995 года)
для спутниковых систем, включая оборудование, программное обеспечение и взаимодействие с пользователями.[2]
Современной версией V-Model является V-Model XT, которая была утверждена в феврале 2005 года. V-модель используется для
управления процессом разработки программного обеспечения для немецкой федеральной администрации. Сейчас она является
стандартом для немецких правительственных и оборонных проектов, а также для производителей ПО в Германии. V-Model
представляет собой скорее набор стандартов в области проектов, касающихся разработки новых продуктов. Эта модель во многом
схожа с PRINCE2 и описывает методы как для проектного управления, так и для системного развития.
Основные принципы
V-Model процесса разработки ИС.[3]
Основной принцип V-образной модели заключается в том, что детализация проекта возрастает при движении слева направо,
одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали,
между левой и правой сторонами буквы.
Применительно к разработке информационных систем V-Model — вариация каскадной модели, в которой задачи разработки идут
сверху вниз по левой стороне буквы V, а задачи тестирования — вверх по правой стороне буквы V. Внутри V проводятся
горизонтальные линии, показывающие, как результаты каждой из фаз разработки влияют на развитие системы тестирования на
каждой из фаз тестирования. Модель базируется на том, что приемо-сдаточные испытания основываются, прежде всего, на
требованиях, системное тестирование — на требованиях и архитектуре, комплексное тестирование — на требованиях, архитектуре и
интерфейсах, а компонентное тестирование — на требованиях, архитектуре, интерфейсах и алгоритмах.[4]
Цели
V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе проекта ставятся следующие задачи:
Минимизация рисков: V-образная модель делает проект более прозрачным и повышает качество контроля проекта путём
стандартизации промежуточных целей и описания соответствующих им результатов и ответственных лиц. Это позволяет выявлять
отклонения в проекте и риски на ранних стадиях и улучшает качество управления проектов, уменьшая риски.
Повышение и гарантии качества: V-Model — стандартизованная модель разработки, что позволяет добиться от проекта результатов
желаемого качества. Промежуточные результаты могут быть проверены на ранних стадиях. Универсальное документирование
облегчает читаемость, понятность и проверяемость.
Уменьшение общей стоимости проекта: Ресурсы на разработку, производство, управление и поддержку могут быть заранее
просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на
последующие стадии и проекты.
Повышение качества коммуникации между участниками проекта: Универсальное описание всех элементов и условий облегчает
взаимопонимание всех участников проекта. Таким образом, уменьшаются неточности в понимании между пользователем,
покупателем, поставщиком и разработчиком.[5]
Достоинства
Пользователи V-Model участвуют в разработке и поддержке V-модели. Комитет по контролю за изменениями поддерживает проект
и собирается раз в год для обработки всех полученных запросов на внесение изменений в V-Model.[6]
На старте любого проекта V-образная модель может быть адаптирована под этот проект, так как эта модель не зависит от типов
организаций и проектов.[7]
V-model позволяет разбить деятельность на отдельные шаги, каждый из которых будет включать в себя необходимые для него
действия, инструкции к ним, рекомендации и подробное объяснение деятельности.[8]
Ограничения
Следующие моменты не учитываются в V-модели, но могут быть рассмотрены отдельно, либо возможно адаптировать модель под них:
Не регулируется размещение контрактов на обслуживание.
Организация и выполнение управления, обслуживания, ремонта и утилизации системы не учитываются в V-модели. Однако,
планирование и подготовка к этим операциям моделью рассматриваются.
V-образная модель больше касается разработки программного обеспечения в проекте, чем всей организации процесса
Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) - это главным образом методика разработки
программного обеспечения, основанная на концепции быстрой разработки приложений (Rapid Application Development, RAD). В 2007
году DSDM стал основным подходом к управлению проектом и разработки приложений. DSDM - это итеративный и инкрементный
подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.
Цель метода - сдать готовый проект вовремя и уложиться в бюджет, но в то же время регулируя изменения требований к проекту во
время его разработки. DSDM входит в семейство гибкой методологии разработки программного обеспечения, а также разработок не
входящих в сферу инормационных технологий
Самая последняя версия DSDM называется DSDM Atern. Название Atern - это сокращение от Arctic Tern (пер. Полярная крачка).
Полярная крачка - птица, которая может путешествовать на большие расстояния. Она символизирует множество аспектов метода,
наример определение приоритета или кооперирование, которые являются естественным способом ведения рабочего процесса.
Предыдущая версия DSDM (выпущенная в мае 2003 года), которая всё ещё действует и широко используется, - это DSDM 4.2,
являющаяся немного расширенной версией DSDM 4. Расширенная версия содержит руководство по тому, как использовать DSDM
совместно с Экстремальным программированием (Extreme Programming).