С. Архипенков

Модели (или, как еще любят говорить, методологии) процессов разработки ПО принято классифицировать по "весу" - количеству формализованных процессов (большинство процессов или только основные) и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше "вес" модели.

Наиболее распространенные современные модели процесса разработки ПО представлены на Рисунке 3.

Рисунок 3 Различные модели процесса разработки ПО и их распределение по "весу"

ГОСТы

ГОСТ 19 "Единая система программной документации" и ГОСТ 34 "Стандарты на разработку и сопровождение автоматизированных систем" ориентированы на последовательный подход к разработке ПО. Разработка в соответствии с этими стандартами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ, и завершается выпуском достаточно большого числа весьма формализованных и обширных документов. Таким образом, строгое следование этим гостам не только приводит к водопадному подходу, но и требует очень высокой степени формализованности разработки. На основе этих стандартов разрабатываются программные системы по госзаказам в России.

SW-CMM

В середине 80-х годов минувшего столетия Министерство обороны США крепко задумалось о том, как выбирать разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software в качестве эталонной модели организации разработки программного обеспечения.

Данная модель определяет пять уровней зрелости процесса разработки ПО.

1. Начальный - процесс разработки носит хаотический характер. Определены лишь немногие из процессов, и успех проектов зависит от конкретных исполнителей.
2. Повторяемый - установлены основные процессы управления проектами: отслеживание затрат, сроков и функциональности. Упорядочены некоторые процессы, необходимые для того, чтобы повторить предыдущие достижения на аналогичных проектах.
3. Определенный - процессы разработки ПО и управления проектами описаны и внедрены в единую систему процессов компании. Во всех проектах используется стандартный для организации процесс разработки и поддержки программного обеспечения, адаптированный под конкретный проект.
4. Управляемый - собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных.
5. Оптимизируемый - постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий.

Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.

RUP

Унифицированный процесс (Rational Unified Process, RUP) был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности. Именно эта черта RUP вызывает основную критику - поскольку он может быть чем угодно, его нельзя считать ничем определенным. В результате такого общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.

MSF

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

PSP/TSP

Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process [ , ]. Personal Software Process определяет требования к компетенциям разработчика. Согласно этой модели каждый программист должен уметь:

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

Team Software Process делает ставку на самоуправляемые команды численностью 3-20 разработчиков. Команды должны:

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

Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.

Agile

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

Выбор модели процесса

Тяжелые и легкие модели производственного процесса имеют свои достоинства и свои недостатки (Таблица 1).

Таблица 1. Плюсы и минусы тяжелых и легких моделей процессов разработки ПО

Вес модели	Плюсы	Минусы
Тяжелые	Процессы рассчитаны на среднюю квалификацию исполнителей. Большая специализация исполнителей. Ниже требования к стабильности команды. Отсутствуют ограничения по объему и сложности выполняемых проектов.	Требуют существенной управленческой надстройки. Более длительные стадии анализа и проектирования. Более формализованные оммуникации.
Легкие	Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурациями. Упрощенные стадии анализа и проектирования, основной упор на разработку функциональности, совмещение ролей. Неформальные коммуникации.	Эффективность сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды. Объем и сложность выполняемых проектов ограничены.

Те, кто пытается следовать описанным в книгах моделям, не анализируя их применимость в конкретной ситуации, показания и противопоказания, уподобляются последователям культа "Карго" - религии самолетопоклонников. В Меланезии верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос, аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения ("муштру") и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи "USA". Все это для того чтобы снова с неба спустились самолеты и этих предметов стало больше.

Алистер Коуберн, один из авторов "Манифеста гибкой разработки ПО" проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и "гибких" до тяжелых (СММ-5) за последние 20 лет [ , ]. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись в проектах. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что:

• У каждого проекта должна быть своя модель процесса разработки.
• У каждой модели - свое время.

Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с "Законом 4-х П" (Рисунок 4). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта "отдохни.ру". И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.

Рисунок 4. "Закон 4-х П". Процесс в проекте должен определяться в зависимости от проекта, продукта и персонала

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

Что надо делать для успеха программного проекта

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

Чтобы программный проект стал успешным, необходимо:

1. Четко ставить цели.
2. Определять способ достижения целей.
3. Контролировать и управлять реализацией.
4. Анализировать угрозы и противодействовать им.
5. Создавать команду.

1. Ставим цели

   1.1. Концепция определяет ясные недвусмысленные цели.
   1.2. Все члены команды считают концепцию реалистичной.
   1.3. У проекта имеется обоснование экономической эффективности.
   1.4. Разработан прототип пользовательского интерфейса.
   1.5. Разработана спецификация целевых функций программного продукта.
   1.6. С конечными пользователями продукта налажена двухсторонняя связь

2. Определяем способ достижения целей

   2.1. Имеется детальный письменный план разработки продукта.
   2.2. В список задач проекта включены "второстепенные" задачи (управление конфигурациями, конвертация данных, интеграция с другими системами).
   2.3. После каждой фазы проекта обновляется расписание и бюджет.
   2.4. Архитектура и проектные решения документированы.
   2.5. Имеется план обеспечения качества, определяющий тестирование и рецензирование.
   2.6. Определен план многоэтапной поставки продукта.
   2.7. В плане учтены обучение, выходные, отпуска, больничные.
   2.8. План проекта и расписание одобрен всеми участниками команды.

3. Контролируем и управляем реализацией

   3.1. У проекта есть куратор. Это такой топ-менеджер исполняющей компании, который лично заинтересован в успехе данного проекта.
   3.2. У проекта есть менеджер, причем только один!
   3.3. В плане проекта определены "бинарные" контрольные точки.
   3.4. Все заинтересованные стороны могут получить необходимую информацию о ходе проекта.
   3.5. Между руководством и разработчиками установлены доверительные отношения.
   3.6. Установлена процедура управления изменениями в проекте.
   3.7. Определены лица, ответственные за решение о принятии изменений в проекте.
   3.8. План, расписание и статусная информация по проекту доступна каждому участнику.
   3.9. Код системы проходит автоматическое рецензирование.
   3.10. Применяется система управления дефектами.

4. Анализируем угрозы

   4.1. Имеется список рисков проекта. Осуществляется его регулярный анализ и обновление.
   4.2. Руководитель проекта отслеживает возникновение новых рисков.
   4.3. Для каждого подрядчика определено лицо, ответственное за работу с ним.

5. Работаем над созданием команды

   5.1. Опыт команды достаточен для выполнения проекта.
   5.2. У команды достаточная компетенция в прикладной области.
   5.3. В проекте имеется технический лидер.
   5.4. Численность персонала достаточна.
   5.5. У команды имеется достаточная сплоченность.
   5.6. Все участники привержены проекту.

Оценка и интерпретация теста

Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:

• 0 - даже не слышали об этом;
• 1 - слышали, но пока не применяем;
• 2 - применяется частично;
• 3 - применяется в полной мере.

Поправочные коэффициенты:

• для малых проектов (до 5 человек) - 1.5;
• для средних (от 5 до 20 человек) - 1.25.

Результат:

• <40 - завершение проекта сомнительно.
• 40-59 - средний результат. В ходе проекта следует ожидать серьезные проблемы.
• 60-79 - хороший результат. Проект, скорее всего, будет успешным.
• 80-89 - отличный результат. Вероятность успеха высока.
• >90 - великолепный результат. 100% шансов на успех.

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

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

Что это?

Начнем статью с определения. Методология разработки программного обеспечения - это совокупность принципов, система идей, и средств, которые в конечном счете будут определять стиль разработки ПО. Иными словами, методология здесь - реализация какого-либо определенного стандарта.

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

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

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

Прогнозируемые методологии

Что относится к данным методологиям разработки программного обеспечения? Это те разновидности, которые ориентированы на детальное планирование будущего. Задачи и ресурсы известны на всем протяжении срока проекта. Отсюда рабочая команда будет с трудом реагировать на неожиданные изменения.

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

Адаптивные методологии

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

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

Гибкие методологии

Гибкие методологии разработки программного обеспечения - англ. Agile software development. Отсюда второе название: agile-методы.

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

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

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

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

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

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

Agile Manifesto

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

Agile Manifesto был разработан и принят 1-13 февраля 2001 года в лыжном комплексе в горах Юты. Содержит в себя 4 главные идеи и 12 принципов командной работе без единого практического совета.

Представим основные идеи этой современной методологии разработки программного обеспечения:

• Взаимодействие и люди главнее инструментов и процессов.
• Работающий продукт выше исчерпывающей документации.
• Сотрудничество с клиентом главнее согласования отдельных условий контрактов.
• Готовность команды к изменениям важнее следования первоначальным планам.

Также в рамках Agile Manifesto были обозначены следующие принципы деятельности разработчиков:

• Удовлетворение запросов клиента за счет бесперебойной ранней поставки ценного ПО.
• Приветствие изменений требований даже по завершении реализации проекта. Ведь именно это может повысить его конкурентоспособность.
• Частые поставки рабочего ПО - каждую неделю-месяц.
• В проекте заняты мотивированные личности, обеспеченные комфортными условиями работы, доверием и поддержкой.
• Ежедневное тесное взаимодействие между заказчиком и командой разработчиков.
• Лучшим измерителем прогресса будет работающее программное обеспечение.
• Пользователи, спонсоры и разработчики должны поддерживать выбранный темп неопределенный срок.
• Постоянное внимание улучшению дизайна продукта, техническим требованиям.
• Простота выступает искусством не заниматься лишней работой.
• Постоянная адаптация команды к изменяющимся условиям деятельности. Разработчики должны постоянно находить средства повышения эффективности своей работы, следовать им в дальнейшем.

Waterfall Model

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

Благодаря такой жесткости, по данной методологии довольно легко управлять проектом. Стоимость и сроки разработки заранее определены, отчего работы проходят быстро. Но важно помнить и такой аспект: каскадная модель дает отличный итог только в проектах с заранее четко заданными требованиями, методиками их реализации. Здесь у специалистов нет шанса "сдать назад", ведь тестирование начинается только после полного завершения этапа.

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

Специалисты советуют использовать методологию "водопад" в следующих случаях:

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

V-Model

Стадии разработки программного обеспечения тут также последовательны. Эту особенность V-Model "унаследовала" от "водопада". Особенно хороша для тех систем, где требуется бесперебойное функционирование. Хороший пример: создание прикладного ПО для клиник, используемого для непрерывного наблюдения за пациентами. Или же программное обеспечение, управляющее механизмами подушек безопасности в транспортных средствах. Или приложение для мобильного оператора, призванное экономить расходы пользователя на роуминг в поездках за границу.

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

Когда необходимо использовать данную методологию для разработок:

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

Incremental Model

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

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

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

Опишем случаи, когда использование Incremental Model будет обоснованным:

• Четко определенные и понятные требования к конечному продукту.
• Допускается доработка некоторых деталей с течением времени.
• Есть несколько рисковых целей.
• Необходим ранний вывод ПО на рынок.

RAD Model

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

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

1. Бизнес-моделирование. Это определение информационных потоков между спектром подразделений.
2. Моделирование сведений. Данные, собранные на первом этапе, используются для определения сущностей, необходимых для циркуляции информации.
3. Во время этой фазы информационные потоки связывают определенные объекты для достижения цели разработки.
4. Сборка приложения. Тут используются средства автосборки для преобразования моделей проектирования в код.
5. новых компонентов и интерфейсов.

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

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

Iterative Model

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

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

Чем-то создание ПО здесь напоминает сотворение картины: сначала делается набросок, затем он заполняется цветами, добавляются детали, насыщенность, переходы оттенков, последние штрихи - и процесс завершен.

Чем-то напоминает инкрементную модель? Давайте рассмотрим разницу. По инкрементной методологии продукт составляется из частей, а функционал ПО складывается, что называется, по кусочкам. Но при этом каждая часть - уже целостный элемент. А "кусочки" в итерационной модели не обладают самостоятельностью.

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

Применение итеративной модели оправдано в следующих случаях:

• Требования к конечной версии разработки понятны и четко определены.
• Проект очень масштабный.
• Основная задача заранее определена. Но ее детали допустимо совершенствовать, изменять в процессе работы.

Spiral Model

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

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

• Планирование.
• Анализирование рисков.
• Конструирование.
• Оценка итогов. Если она положительная, то разработчик переходит к новому "витку" проекта.

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

LD

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

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

XP

Весьма любопытный пример - методология так называемого экстремального программирования. Что тут скрывается? Это ведение разработки ПО в условиях постоянно изменяющихся требований к продукту. Направление методологии имеет следующие отличительные черты:

• "Игра в планирование". В начале работ представлен лишь приблизительный план. С каждым витком разработки его четкость увеличивается.
• Высокая частота релизов. Это значит, что новая версия будет иметь лишь небольшие отличия от предыдущей, но на ее выпуск затрачивается самый минимум времени.
• Контакт с клиентом. Для следующих данной методологии важно быстро удовлетворять все требования заказчика - оперативно реагировать на все его замечания и пожелания.
• Рефакторинг. Качество кода улучшается без уменьшения его функциональности.
• Стандартное выполнение кода. На лицо или следование общим правилам, или отсутствие разногласий в процессе разработки.
• Коллективная ответственность. Да, каждый из членов команды занят определенным участком работ. Но за общий результат ответственен уже весь коллектив.

FDD

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

• Разработка каждого крупного проекта - это системная деятельность.
• Все процессы должны быть простыми и хорошо проработанными.
• Логичность и ценность каждого из процессов должна быть ясна и понятна любому из членов команды.
• Предпочтение - коротким циклам разработки ПО. Это позволяет снизить количество ошибок, вместе с тем увеличивая функциональность.

Ценность методологии и в том, что она четко регламентирует продолжительность процессов. При этом на организационные вопросы в каждом цикле не должно затрачиваться более 25 % времени. Остальные 75 % - сугубо на разработку, сборку, тестирование функционала.

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

программное обеспечение управление

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

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

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

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

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

Рисунок 1- Модифицированная каскадная модель разработки программного обеспечения

Модифицированная каскадная модель предусматривала возможность возвращения к предыдущим этапам.

Спустя непродолжительное время после своего появления на свет каскадная модель была доработана Уинстом Ройсом с учетом взаимозависимости этапов и необходимости возврата на предыдущие ступени, что может быть вызвано, например, неполнотой требований или ошибками в формировании задания . В таком «обратимом» виде каскадная модель просуществовала долгое время и явилась основой для многих проектов (рисунок 1).

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

Для того, чтобы устранить недостатки каскадной модели была предложена V-образная, или шарнирная модель разработки программного обеспечения (рисунок 2).

Рисунок 2- V-образная модель разработки программного обеспечения

V-образная модель позволяет гораздо лучше контролировать результат на предмет его соответствия ожиданиям, поскольку сфокусирована на тестировании .

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

Однако в целом V-образная модель является всего лишь модификацией каскадной и обладает многими ее недостатками. В частности, и та и другая слабо приспособлены к возможным изменениям требований заказчика. Если процесс разработки занимает продолжительное время (иногда до нескольких лет), то полученный в результате продукт может оказаться фактически ненужным заказчику, поскольку его потребности существенно изменились.

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

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

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

Предложенная Барри Боэмом в 1988 году спиральная модель стала существенным прорывом в понимании природы разработки программного обеспечения, хотя объединяет каскадный подход и итерационный процесс проектирования на основе создания прототипов (рисунок 3).

Рис. 3.

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

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

Впервые предложенная Филиппом Крачтеном в 1995 году, итеративная модель объединяет главные преимущества спиральной, инкрементной, каскадной моделей, а также методов разработки на основе создания прототипов и объектно-ориентированного подхода (рисунок 4). Она завоевала большую популярность и в том или ином виде используется во многих современных проектах .

Рисунок 4- Итеративная модель разработки программного обеспечения

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

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

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

Самым известным и авторитетным стандартом качества следует считать Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 году, хотя работы над ним начались гораздо раньше - основные его положения были опубликованы еще в 1986 голу. Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания программного обеспечения. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (таблица 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA) .

Таблица 1-Модель СММ

Название уровня	Ключевые области процесса
1 - Начальный	Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено
2 - Повторяющийся	Управление программными конфигурациями. Обеспечение качества программных продуктов. Управление контрактами подрядчиков. Контроль за ходом проектов. Планирование программных проектов. Управление требованиями
3 - Определенный	Экспертные оценки. Координация взаимодействий проектных групп. Инженерия программного продукта. Комплексный менеджмент ПО. Программа обучения персонала. Определение организационного процесса. Область действия организационного процесса
4 - Управляемый	Менеджмент качества ПО. Управление процессом на основе количественных методов
5 - Оптимизируемый	Управление изменением процесса. Управление технологическими изменениями. Предотвращение дефектов

Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов, а он получил новое имя - SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

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

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

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI - Capability Maturity Model Integrated (CMMI) - интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления - классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA).

В таблице 2 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

Таблица 2- Соответствие уровней зрелости стандартов CMM, CMMI

SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO.

В современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.

Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания программного обеспечения. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI .

Модель зрелости процесса разработки программного обеспечения (CMM), разработанная Институтом программной инженерии в университете Carnegie Mellon, предлагает пять уровней зрелости (таблица 3). Она помогает организациям повысить зрелость своих процессов разработки программного обеспечения, и организации могут быть оценены и аккредитованы в соответствии с этими уровнями.

Таблица 3-Уровни зрелости разработки программного обеспечения

Уровень 1 - начальный уровень	Процесс разработки ПО спонтанен, и регламентированы лишь немногие процессы. Успех разработки может зависеть от отдельных сотрудников.
Уровень 2 - уровень повторяемости	Созданы основные процессы управления проектами для отслеживания затрат, календарного плана и функциональных возможностей.
Уровень 3 - уровень регламентируемости	Процесс разработки ПО документирован, стандартизирован и интегрирован со стандартным процессом разработки ПО организации как для операций управления, так и для операций разработки. Во всех проектах используется стандартизированный процесс.
Уровень 4 - уровень управляемости	Проводится сбор подробных показателей процесса разработки ПО и качества продукта, что позволяет понять процесс и продукты и управлять ими.
Уровень 5 - уровень оптимизируемости	Непрерывная оптимизация процесса обеспечивается количественной обратной связью от процесса и от пилотных инновационных идей и технологий.

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

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

Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/30 июля 2012. Пока процесс обсуждения … Википедия

- (англ. Software project management) особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по… … Википедия

- (ПО) период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл процесс построения и развития ПО. Содержание 1 Стандарты… … Википедия

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

Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия

Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия

Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия

Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

Книги

• , Кон Майк. В книге "Пользовательские истории: гибкая разработка программного обеспечения" Майка Кона, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки…
• Пользовательские истории. Гибкая разработка программного обеспечения , Майк Кон. В книге`Пользовательские истории: гибкая разработка программного обеспечения` Майка Кона, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки…

Программирование ,

Разработка мобильных приложений

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

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний - , мелкий - .

Когда использовать каскадную методологию?

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

2. «V-Model»

Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта , находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.

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

Когда использовать V-модель?

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

3. «Incremental Model» (инкрементная модель)

В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.

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

Когда использовать инкрементную модель?

• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

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

Модель быстрой разработки приложений включает следующие фазы:

• Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
• Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
• Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
• Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
• Тестирование: тестируются новые компоненты и интерфейсы.

Когда используется RAD-модель?

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

5. «Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

В основе такого типа - непродолжительные ежедневные встречи - «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

• отчёт о проделанной работе с момента последнего Scrum’a;
• список задач, которые сотрудник должен выполнить до следующего собрания;
• затруднения, возникшие в ходе работы.

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

Когда использовать Agile?

• Когда потребности пользователей постоянно меняются в динамическом бизнесе.
• Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
• В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.

6. «Iterative Model» (итеративная или итерационная модель)

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

На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй - появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.

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

Когда оптимально использовать итеративную модель?

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

7. «Spiral Model» (спиральная модель)

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

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование. На проекте по разработке СЭД для ОДУ Сибири СО ЕЭС два совещания об изменении кодификации разделов электронного архива занимают в 10 раз больше времени, чем объединение двух папок программистом. Государственные проекты, в которых мы участвовали, начинались с подготовки экспертным сообществом дорогостоящей концепции, которая отнюдь не всегда бесполезна, поскольку окупается в масштабах страны.

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

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

О технологиях разработки:
.
.
.
.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите , пожалуйста.