Файл: Жизненный цикл программного проекта.pdf

2.2. Организационные процессы жизненного цикла программного продукта

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

Организационные процессы жизненного цикла программного обеспечения включают:

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

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

3. Процесс усовершенствования. Направлен на усовершенствование всех остальных процессов жизненного цикла программного обеспечения. Усовершенствование может повысить производительность разработчиков и добиться большей выгоды от выполнения заказа на производство программы.

4. Процесс обучения. Постоянное обучение сотрудников и повышение их квалификации – это залог производства качественных продуктов и программ. Процесс обучения направлен на организацию мероприятий для повышения уровня и получения новых навыков сотрудниками компании-разработчика^[19].

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

Этапы создания программных продуктов приведены на рис. 2.

Рисунок 2 – Этапы создания программных продуктов

Приведём все основные этапы создания программного продукта. Всего их пять. Они так или иначе характерны для любой методологии разработки программного обеспечения: будь то классическая водопадная, либо современные гибкие методологии (Agile software development) – во всех из них разработчики проходят через следующие этапы создания программного обеспечения:

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

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

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

3. Разработка. Когда требования сформулированы и архитектура готова – команда начинает разработку программного продукта. На этапе разработки также выполняется документирование системы.

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

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

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

2.3. Модели жизненного цикла программных продуктов

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

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

1. Каскадная (водопадная) модель.

Схематически данная модель изображена на рис. 3.

Рисунок 3 – Каскадная (водопадная) модель
жизненного цикла программного продукта^[21]

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

Характерные черты каскадной модели:

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

2) циклическое повторение пройденных этапов (как в классической модели).

2. V-образная модель разработки.

Схема данной модели изображена на рис. 4.

Рисунок 4 – V-образная модель разработки
жизненного цикла программного продукта^[22]

По рис. 4 можно проследить, что в V-образной модели имеется возможность вернуться на некоторые этапы разработки и уточнить нужные требования.

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

3. Модель прототипирования.

Схема данной модели изображена на рис. 5.

Рисунок 5 – Модель прототипирования
жизненного цикла программного продукта^[23]

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

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

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

4. Модель быстрой разработки (RAD-модель).

Схема данной модели изображена на рис. 6.

Рисунок 6 – RAD-модель жизненного цикла программного продукта^[24]

RAD-модель (rapid application development — быстрая разработка приложений) ориентирована в первую очередь на быстроту и удобство программирования. Команда делает акцент именно на разработке, а большая часть работы по составлению требований и описанию пользователей возлагается на заказчика.

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

5. Итерационная модель.

Схема данной модели изображена на рис. 7.

Рисунок 7 – Итерационная модель жизненного цикла программного продукта^[25]

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

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

6. Спиральная модель.

Схема данной модели изображена на рис. 8.

Рисунок 8 – Спиральная модель жизненного цикла программного продукта^[26]

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

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

Гибкие методологии (Agile) олицетворяют современные подходы к разработке программного обеспечения. Они используются обычно в небольших командах разработчиков. Среди них такие модели жизненного цикла программного продукта, как Scrum, DSDM, XP, FDD и другие.

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