Элементы программной инженерии
4. Процесс создания программного обеспечения
Сразу оговоримся, что по данному разделу написано немало литературы. Существуют многостраничные книги, ГОСТ-ы, стандарты... На сегодняшний день мы можем смело утверждать, что при некотором общем теоретическом (философском) и практическом понимании того, что происходит в отрасли, и что нужно делать для лучшей организации при создании программного обеспечения, терминология в данной области абсолютно не устоялась. Мы в данном курсе ориентируемся на вариант И. Соммервилля. При этом рекомендуем ознакомиться и с другими книгами и материалами. Каждая новая книга предложит вам новую терминологию. Не пугайтесь этого. Пройдет время, и терминология устоится. Общий смысл изложения во многих книгах по программной инженерии совпадает.
4.1. Понятие процесса
Процесс создания программного обеспечения - совокупность мероприятий, целью которых является создание или модернизация программного обеспечения [2.1, 2.2, 2.3].
Выделяют 4 основных мероприятия (стадии) процесса:
Спецификация: формулирование спецификаций определяет основные требования к ПО (что должна делать система).
Разработка: создание ПО в соответствии со спецификациями.
Аттестация: проверка ПО на соответствие потребностям заказчика.
Модернизация: развитие ПО в соответствии с изменившимися потребностями заказчика.
Все стадии основаны на специальных технологиях. Например, рассмотренные кратко в предыдущей лекции модульное, структурное, объектно-ориентированное, компонентное программирование относятся к стадии Разработки.
Каждая организация может организовать процесс создания программного обеспечения так, как ей это представляется разумным. Этот процесс может иметь разную степень формализации. Так, создание продукта может идти по принципу "вечером обсудили и договорились", но этот принцип работает только для команд из 2-3 человек в достаточно простых проектах. Возможна другая крайность - каждое действие жестко определено и прописано в описании процесса. В этом случае возникает необходимость длительного предварительного обучения сотрудников работе в рамках этого, безусловно, сложного описания. Подобный подход, конечно, порождает и другие накладные расходы. Например, то, что вполне могло бы быть решено в частной беседе, теперь приходится долго и нудно "проводить" через соответствующий формализм. Пожалуй, такая степень формализации может пойти на пользу для очень больших, тем более распределенных, коллективов, решающих задачи большой сложности. Для небольшого или среднего проекта описанная степень формализации принесет больше вреда, чем пользы (хорошая аналогия - забивание гвоздей микроскопом).
Несмотря на естественные отличия в описаниях процессов, как правило, в нем присутствуют рассмотренные стадии. Они могут иначе называться, детализироваться, но от них никуда не уйти.
Существуют известные, хорошо проработанные процессы: Microsoft Solutions Framework (MSF), Rational Unified Process (RUP) и другие.
Эти процессы (ко второму в большей степени применим термин методология) имеют свои разновидности и могут применяться как для малых и средних компаний и проектов, так и для больших.
4.2. Модели процесса
Итак, некий "каркас" процесса обычно выглядит так:
- Спецификация.
- Разработка.
- Аттестация.
- Модернизация.
Сам этот "каркас" можно приводить в жизнь по-разному. Существуют общие модели процесса, которые определяют, как организовать работу по "каркасу" на практике. Фактически, модель процесса - некое абстрактное представление процесса на верхнем уровне. Так, модель не рассматривает детально содержимое каждого из этапов. Модель рассматривает состав этапов и способы их претворения в жизнь.
Рассмотрим некоторые устоявшиеся модели процесса разработки программного обеспечения.
4.2.1. Каскадная модель (Waterfall model)
Суть каскадной модели состоит в следующем:
- Требования к системе определяются на начальном этапе и далее не меняются.
- Процесс создания ПО разбивается на следующие стандартные этапы: определение требований, проектирование, кодирование и тестирование модулей, интеграция и тестирование продукта, эксплуатация и сопровождение.
- Каждый этап может начаться лишь тогда, когда закончился предыдущий.
Достоинства каскадной модели в простоте и хорошей структурированности. Основные недостатки связаны с прямолинейностью и отсутствием гибкости. Дело в том, что неизменность требований является мифом. Требования менялись, меняются и будут меняться всегда в ходе разработки. Каскадная модель не учитывает этот факт. В итоге, если ничего не предпринимать, конечный продукт будет отличаться от потребностей пользователей. Более того, скорее всего и документация в конце не будет отражать реальной ситуации (например, ТЗ, составленное в начале не будет совпадать с тем, что получится в конце). Поэтому каскадная модель в чистом виде перспективна лишь для очень больших проектов, где хорошая структурированность выходит на первые роли, а также в тех случаях, когда требования хорошо осознаны и зафиксированы в самом начале.
4.2.2. Эволюционная модель (Evolutionary development)
Суть эволюционной модели состоит в том, что многие стадии повторяются неоднократно. Так, после анализа требований производится разработка некоторого прототипа, удовлетворяющего этим требованиям. После этого прототип может быть показан пользователям. Далее - уточнение требований и вновь проектирование, реализация, отладка и тестирование. В результате нескольких повторений этого процесса на выходе получается продукт, удовлетворяющий пожеланиям пользователей. Заметим, что вместе с продуктом развивается и документация к нему.
Недостатки эволюционного подхода в плохой структурированности системы, отсутствия внятного подробного проекта на начальных этапах, необходимости в средствах быстрой разработки. Соответственно, подход хорошо подходит для малых и средних проектов.
4.2.3. Итерационный подход
Часто подходы, перечисленные ранее, используются в совокупности. В том смысле, что на некоторых стадиях при их детализации можно пользоваться как каскадной, так и эволюционной моделью. Полезность этого обусловлена реальными условиями, в которых, в частности, требования почти всегда меняются в ходе разработки. Соответственно, необходимо иметь возможность адекватно реагировать, а именно, выполнять новую итерацию, заново проходя все или почти все этапы с целью создания того, что будет удовлетворять пожеланиям пользователя.
Рассмотрим две популярные гибридные модели, использующих различные особенности перечисленных выше моделей, и основанные на итерациях.
Модель пошаговой разработки
Модель пошаговой разработки (Миллс) состоит в выполнении стандартных шагов. В итоге каждого шага - работающий прототип. Требования фиксированы во время шага. Для шага можно применять каскадную или эволюционную модель.
Особенность состоит в том, что наиболее важные для заказчика компоненты разрабатываются в самом начале, в результате чего он может оценить, насколько конечный продукт будет соответствовать его потребностям, и при необходимости внести коррективы.
Одно из ответвлений - Экстремальное программирование.
Спиральная модель разработки
Спиральная модель (Боэм) оказалась чрезвычайно популярной. Суть ее состоит в том, что вместо действий с обратной связью происходит выполнение различных этапов по спирали. Каждый виток спирали соответствует 1 итерации. Заранее фиксированных фаз нет, их состав зависит от потребностей.
Каждый виток разбит на 4 сектора: определение целей, оценка и разрешение рисков, планирование, разработка и тестирование.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт.
Главное отличие от других моделей состоит в акценте на анализ и преодоление рисков (об этом мы еще будем говорить более подробно в 3 разделе нашего курса).
5. Что дальше?
Тема следующей лекции - Визуальное моделирование при анализе и проектировании.