Как создается программное обеспечение? Чем в своей деятельности руководствуются специалисты? В этой сфере важны методологии разработки программного обеспечения. Некоторые из них мы рассмотрим в этой статье, подробно останавливаясь на задачах, этапах, важных принципах и отличиях данных методологий.
Что это?
Начнем статью с определения. Методология разработки программного обеспечения - это совокупность принципов, система идей, понятий, способов, методов и средств, которые в конечном счете будут определять стиль разработки ПО. Иными словами, методология здесь - реализация какого-либо определенного стандарта.
Что важно отметить, стандарты здесь советуют, а не предписывают, как должно быть. Поэтому перед создателем ПО сохраняется свобода выбора, адаптации теории.
Конкретные продукты реализуются через методологию разработки программного обеспечения. Она будет определять, каким образом специалист станет выполнять свою работу. Сегодня подобных методологий множество - основные мы рассмотрим по ходу материала. Что же влияет на выбор из них одной-единственной? Выделяется размер команды, сложность и специфика определенного проекта, зрелость и стабильность процессов в компании-работодателе, личные предпочтения создателя ПО.
Таким образом, методологии - это ядро теории управления разработкой какого-либо программного обеспечения. Ранее в их отношении применялась классификация, разделяющая все методологии на два типа: итерационные и водопадные (исходя из применяемых моделей жизненного цикла). Сегодня используется современная общая классификация, разделяющаяся также на две группы: прогнозируемые и адаптивные. Познакомимся с ними подробнее.
Прогнозируемые методологии
Что относится к данным методологиям разработки программного обеспечения? Это те разновидности, которые ориентированы на детальное планирование будущего. Задачи и ресурсы известны на всем протяжении срока проекта. Отсюда рабочая команда будет с трудом реагировать на неожиданные изменения.
План составляется по составу необходимых работ, требованиям к ним. Отсюда изменение требований прямо приводит к изменению всего плана, дизайна проекта. Для прогнозируемых методологий типично создание специального комитета, управляющего изменениями, чтобы в проекте учитывались только важнейшие требования.
Адаптивные методологии
В чем особенность данных методологий разработки компьютерного программного обеспечения? Они уже нацелены на преодоление ожидаемого несовершенства, неполноты требований, на постоянное изменение последних. Соответственно, с изменением требований будет заменяться и команда разработчиков проекта.
Точный план по адаптивной методологии разрабатывается только на ближайшее время. Планы, относящиеся к более удаленным от реальности событиям, существуют в форме деклараций о целях работы, ее результатах и ожидаемых затратах.
Гибкие методологии
Гибкие методологии разработки программного обеспечения - англ. 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 выступает одной из разновидностей инкрементной модели. Компоненты или функции программы здесь параллельно разрабатываются несколькими командами профессионалов. В результате получается несколько мини-проектов. Время на создание каждого из них жестко ограничено. Все модули складываются в общий рабочий прототип. Система хороша тем, что помогает быстро представить заказчику для обозрения рабочий продукт, в который затем можно внести ряд изменений.
Процесс разработки программного обеспечения здесь включает в себя несколько этапов:
- Бизнес-моделирование. Это определение информационных потоков между спектром подразделений.
- Моделирование сведений. Данные, собранные на первом этапе, используются для определения сущностей, необходимых для циркуляции информации.
- Моделирование процесса. Во время этой фазы информационные потоки связывают определенные объекты для достижения цели разработки.
- Сборка приложения. Тут используются средства автосборки для преобразования моделей проектирования в код.
- Тестирование. Проверка новых компонентов и интерфейсов.
Использовать такой метод разработки программного обеспечения следует только в том случае, когда в команде есть высококвалифицированные и "узкие" специалисты. Бюджет проекта определенно большой: нужно оплатить работу профессионалов, стоимость готового инструментария автоматизированной сборки.
Модель выбирают при уверенном знании целевого бизнеса в тех случаях, когда нужно представить готовый продукт в короткие сроки - за 2-3 месяца.
Iterative Model
Следующий пример организации разработки программного обеспечения - это итерационная (или итеративная модель). Особенностью проекта является то, что для начала его реализации не нужна полная спецификация требований. Создание начинается с конструирования базы, которая должна стать основой для определения дальнейших требований.
Версия в данном случае может быть и вовсе неидеальной. Главное требование - чтобы она работала. Разработчик понимает и видит конечную цель работы. Он должен стремиться к тому, чтобы каждый шаг его деятельности был результативен, а каждая созданная версия - работоспособна.
Чем-то создание ПО здесь напоминает сотворение картины: сначала делается набросок, затем он заполняется цветами, добавляются детали, насыщенность, переходы оттенков, последние штрихи - и процесс завершен.
Чем-то напоминает инкрементную модель? Давайте рассмотрим разницу. По инкрементной методологии продукт составляется из частей, а функционал ПО складывается, что называется, по кусочкам. Но при этом каждая часть - уже целостный элемент. А "кусочки" в итерационной модели не обладают самостоятельностью.
Еще один яркий пример разработки программного обеспечения по данной методологии: аппаратура, распознающая голос. Все началось с подготовки научной базы. Затем была собрана необходимая документация. С каждой новой разработкой качество аппаратуры повышалось. Но идеального уровня она не достигла до сих пор. Следовательно, проект еще не завершен.
Применение итеративной модели оправдано в следующих случаях:
- Требования к конечной версии разработки понятны и четко определены.
- Проект очень масштабный.
- Основная задача заранее определена. Но ее детали допустимо совершенствовать, изменять в процессе работы.
Spiral Model
Спиральная модель во многом напоминает предыдущую. Однако акцент делается еще на одну задачу разработки программного обеспечения - оценку рисков. Более всего данная методология применима для решения критических бизнес-заданий, когда неуспешность проекта может серьезно повредить деятельности компании.
Спиральную модель широко применяют при выпуске новых линеек программного обеспечения, при необходимости проведения научных исследований проекта, практической апробации. Каждый из "витков спирали" проходит в четыре фазы:
- Планирование.
- Анализирование рисков.
- Конструирование.
- Оценка итогов. Если она положительная, то разработчик переходит к новому "витку" проекта.
Спиральную модель не стоит использовать для маленьких бюджетных проектов. Напротив, она более подходит для масштабных и дорогих. Отличный пример применения методологии - для разработки системы банковского документооборота. Здесь большое внимание уделяется не столько самому программированию, сколько анализу каждого уже произведенного "витка".
LD
Так называемая бережливая разработка ПО. Является одним из ответвлений гибкой методологии, которую мы разобрали выше. Главное достоинство LD: сохранение высокого морального и функционального состояния специалистов. В частности, это следующее:
- Поощрение каждого из работников за особо успешную деятельность.
- Текущие задачи проекта изменяются только в случае крайней необходимости или же по желанию заказчика.
- Строгое выполнение плана. Сверхработы здесь считаются признаком потери как времени, так и ресурсов.
- Внедрение в работу общей концепции деятельности: "Широко мыслить, быстро ошибаться, мало работать, стремительно обучаться".
XP
Весьма любопытный пример - методология так называемого экстремального программирования. Что тут скрывается? Это ведение разработки ПО в условиях постоянно изменяющихся требований к продукту. Направление методологии имеет следующие отличительные черты:
- "Игра в планирование". В начале работ представлен лишь приблизительный план. С каждым витком разработки его четкость увеличивается.
- Высокая частота релизов. Это значит, что новая версия будет иметь лишь небольшие отличия от предыдущей, но на ее выпуск затрачивается самый минимум времени.
- Контакт с клиентом. Для следующих данной методологии важно быстро удовлетворять все требования заказчика - оперативно реагировать на все его замечания и пожелания.
- Рефакторинг. Качество кода улучшается без уменьшения его функциональности.
- Стандартное выполнение кода. На лицо или следование общим правилам, или отсутствие разногласий в процессе разработки.
- Коллективная ответственность. Да, каждый из членов команды занят определенным участком работ. Но за общий результат ответственен уже весь коллектив.
FDD
И последняя методология в нашей статье. Она обеспечивает масштабируемость и повторяемость. Но при этом поощряется творческий подход, применение в работе инноваций. Основные принципы методологии следующие:
- Разработка каждого крупного проекта - это системная деятельность.
- Все процессы должны быть простыми и хорошо проработанными.
- Логичность и ценность каждого из процессов должна быть ясна и понятна любому из членов команды.
- Предпочтение - коротким циклам разработки ПО. Это позволяет снизить количество ошибок, вместе с тем увеличивая функциональность.
Ценность методологии и в том, что она четко регламентирует продолжительность процессов. При этом на организационные вопросы в каждом цикле не должно затрачиваться более 25 % времени. Остальные 75 % - сугубо на разработку, сборку, тестирование функционала.
На этом закончим знакомство с основными разработками программного обеспечения. Как вы убедились, особенности каждой из них позволяют выбрать подходящую методологию для успешной реализации самых разнотипных проектов.
