Б. Конструктивно-технологическая часть проекта 1. Технология программирования
С ростом масштабов задач, менеджеры не справляются с управлением выделенными ресурсами. Увеличение ресурсов может усугублять проблему, не решая поставленных задач. Человеческие ресурсы в разработке программного обеспечения играют первостепенную роль, а проблема роста сложности управления хорошо описывается высказыванием, что «девять женщин не родят за месяц ребёнка». Эту действительность раскрыл[39] в 1975 году Фредерик Брукс в своей книге «Мифический человеко-месяц». В своей более поздней работе Брукс выделил две составляющие сложности разработки ПО: трудности, присущие специфике создания ПО, и акцидентальные – в данном контексте такие, которые связаны с ограничениями уровня развития науки и техники. Вторые более или менее успешно преодолеваются на пути научно-технического прогресса, зато первые будут сопровождать разработку ПО всегда.
Управление процессом становится действием, напрямую зависимым от восприятия состояния и поведения объекта. В том, что касается создания ПО, это является весьма сложной задачей, поскольку процесс разработки – сугубо интеллектуальная, во многом творческая деятельность, для которой конвейерные либо другие им подобные методы неприменимы. Поэтому и были предприняты активные попытки представить модель процесса создания ПО, которая в максимальной степени смогла бы учесть присущие ему особенности и сделать его управляемым.
Модели на основе инженерного подхода 1.1.1. Каскадная модель.
В 1970 У.У. Ройс опубликовал статью[40] в которой концептуально описал то, что сейчас называется «Каскадной моделью». В своей работе Ройс представляет процесс разработки как поток, проходящий свои фазы последовательно. При такой модели разработчик переходит от стадии к стадии последовательно, полностью завершая текущую ступень.
Данная методика зачастую критикуется[41] за недостаточную гибкость. При такой работе формализация встаёт на первое место перед сроками, а так же ведёт к увеличению стоимости разработки. Впрочем, формализация позволяет снизить риски в разработке.
1.1.2. V-образная модель.
В 1980 году немецкая аэрокосмическая компания IABG и Американский национальный совет по системной инженерии независимо друг от друга разработали концепцию V-образной модели[32]. Современная версия «V-Model XT» была утверждена в 2005 году и является стандартом немецкий оборонных, правительственных проектов, и прочих национальных производителей программного обеспечения.
V-Model по своему принципу есть ни что иное, как вариация каскадной модели, в которой разработка спускается по левому ребру сверху вниз, а тестирование поднимается вверх по правому. Внутри задачи зависимы горизонтально, что показывает, как задачи разработки влияют на систему тестирования.
Данная модель так же имеет свои недостатки. Например, тестирование происходит поздно, что, при внесении изменений, влияет на сроки разработки, а следовательно на стоимость. Модель не анализирует риски и не гибка для динамического изменения требований. В защиту метода нужно упомянуть высокий уровень планирования разработки, верификация для всех этапов разработки, а так же входных и выходных данных.
Модели, учитывающие специфику разработки ПО
Поскольку первые модели были заимствованы из традиционной инженерной области, они не учитывали в полной мере специфику производства ПО. Однако последующие модели были уже гораздо больше ориентированы на особенности этого вида деятельности, имеющего много принципиальных отличий от конструирования предметов материального мира.
Инкрементная модель.
Инкрементная модель строится на инкрементной стратегии конструирования. Сначала определяются системные и пользовательские требования, оставшуюся часть реализуют в виде последовательности версий. Первая версия реализует зачастую базовый функционал, а следующая уже содержит дополнительные возможности. Природа инкрементного подхода итеративна и на каждой итерации обладает готовым продуктом. Спиральная модель.
Спиральную модель в 1986 году предложил Барри Боэм. Модель стала революционной в области разработки программного обеспечения. Модель сочетает в себе проектирование, прототиприрование и анализ. Большая часть рисков образуется из организационных и процессных взаимодействий. На каждом ветке находится фрагмент или версия продукта, здесь определяются цели проекта, его качество, характеристики и планируется следующий виток. Это позволяет развивать и конкретизировать детали проекта, реализуя обоснованный вариант. Виток разбивается 4 секторами:
Оценка и разрешение рисков
Определение целей
Разработка и тестирование
Планирование
Каждый виток может гибко подстраиваться и использовать различные модели разработки. В итоге модель в своём глобальном представлении является сочетанием прототипирования и водопадной модели. Итеративность процессов позволяет начинать новый виток, когда ещё не завершён предыдущий, перенося какие-то этапы с одно витка на другой. Для определения сроков перехода между витками используется вводятся временные ограничения на каждый этап. Переход осуществляется по плану вне зависимости от степени готовности работ.
Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В условиях, когда бизнес цели таких проектов могут измениться, но требуется разработка стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости, имеет смысл применение Spiral Architecture Driven Development. Данная методология, включающая в себя лучшие идеи спиральной модели и некоторых других, позволяет существенно снизить архитектурные риски, что является немаловажным фактором успеха при разработке крупных систем.
Современные модели
К середине 1990-х годов индустрия ПО стала достаточно развитой, сложные проекты успешно реализовывались с помощью приобретающей популярность объектно-ориентированной методологии, а команды разработчиков стали применять подходы, основанные на использовании наиболее значимых преимуществ предыдущих моделей.
Объектно-ориентированная модель. Объектно-ориентированная модель разработки была создана на основе объектно-ориентированной парадигмы программирования. Изначально эта методология представляла из себя копирование принципов объектно-ориентированного программирования, но позже распространилась на весь жизненный цикл, и включила в себя действия и нотацию языка. Объектно-ориентированная разработка не опирается ни на какой язык программирования и может даже применяться не к объектно-ориентированному программированию. Данная модель, благодаря своим формальным конструкциям, позволяет понять многие различные аспекты и упростить дальнейшую реализацию, тестирование и развитие версий. Очень популярна OMT (Object Modeling Technique) методология, поддерживающие первые две стадии жизненного цикла. Эта методология получила большое распространение благодаря своей системе графических обозначений. Итеративная модель.
В 1995 году Филипп Кратчен объединил[32] преимущества спиральной инкрементной и объектно-ориентированных методологий, предложив итеративную модель. Эта модель включает в себя 4 фазы жизненного цикла разработки ПО:
• Начало
• Исследование
• Построение
• Внедрение
На каждой фазе процесс итеративно изменяется: сначала разрабатываются прототипы, уточняются требования, решаются наиболее трудные аспекты; завершающие итерации расширяют функциональность и приводят к созданию продукта. Так же модель включает в себя две группы процессов:
• Рабочие – управление требованиями, анализ, проектирование, реализация, тестирование, развертывание;
• Вспомогательные – управление конфигурацией и изменениями, проектом и процессом.
Число и назначение процессов определяются непосредственно задачей и могут иметь свои циклы, соответствующие основным фазам. Управление рисками здесь схоже со спиральной моделью – приоритеты и трудозатраты определяются в начале каждой итерации. Эта модель хорошо подходит для большинства программных разработок, а особенно для версионных продуктов.
Модели быстрой разработки.
Экстремальное программирование
Экстремальное программирование – методология, представленная Кентом Беком, Уордом Каннингемом, Мартинов Фаулером и их коллегами в 1996 году. Эта методология является одной из наиболее гибких в разработке ПО и состоит из 12 приёмов в 4 группах
Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование (Test driven development) – включает в себя модульное тестирование (unit testing) и функциональное тестирование. Так же приоритетным является подход TDD (Test Driven Develoopment) – сначала пишется тест, а потом для его прохождения разрабатывается логика.
Игра в планирование (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)
SCRUM (Agile)
Scrum – это быстрый, адаптивный эмпирический метод разработки. Это логическое противостояние водопадной модели, а методология строится на повторяющихся циклах, что позволяет методу самоорганизовываться, быть гибким и предсказуемым. Метод по своей работе основан на встречах: ежедневных и циклических 30-ти дневных. Каждый день решаются вопросы: что было сделано? Что будет делаться? Что мешает?
Scrum основан на принципах индивидуализма и взаимодействия строгих методов, и процессов. Главным в методе ставится работающее ПО, а не сложная документация, а взаимодействие с заказчиком выходит на первый план перед контрактными договорённостями. Главным представлением Srum является то, что задача важнее плана.
Построение SCRUM-команды - это 5-9 человек среди которых Scrum Master – менеджер и локальный лидер. На встречах могут присутствовать люди, но они будут лишены права голоса. Говорить могут только члены команды. Команда строится не только из программистов, но так же и тестировщики, дизайнеры и другие заинтересованные люди.
В конце каждого 30-ти дневного Sprint`а разработчик демонстрирует заказчику рабочий прототип, требования к которому были сформулированы в начале Sprint`а в бэклоге – таблице соотношения задачи – времени.
Успех данного подхода во многом определяется личными качествами Scrum Master`а.
Адаптированные и комбинированные модели.
Модели разработки, определяющие жизненный цикл, эволюционируя, не заменяя старые, а организовываясь под собственную сферу использования. Не все методики могут применяться в любом случае, иногда они могут быть даже тормозящим или тупиковым процессом. Иногда для идеального решения задачи может подойти один и только один метод. Руководство разработки должны рассматривать все варианты задолго до начала проектирования продукта. Иногда модели приходится адаптировать модели под свои задачи, применять комбинации или даже создавать свой путь.
Быстрая разработка сменила консервативные процессы в историческом плане, но на практике старые методы адаптировались, изменились, и переняв эффективные приёмы, нашли применение в современных процессах
1.6 Выводы
После анализа большинства популярных методов разработки, и учитывая возможности разработки, наиболее очевидным является метод экстремального программирования. Данный подход позволяет быстро оценить результат разработки и вносить сложные изменения. Принцип разработки через тестирование является сильной стороной данного метода для разработки одним человеком. Сложности возникают в принципах коллективной работы, которые приходится нарушать, консолидируя всю работу в одном разработчике.
|
