Управление ИТ-проектами и жизненным циклом ПО

Введение

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

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

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

Моделирование при разработке ПО

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

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

К основным моделям жизненных циклов ПО относятся:

1. Каскадная (водопадная) модель.
2. V-образная модель.
3. Инкрементная модель.
4. Спиральная модель.
5. Гибкая модель.
6. Модель-скрам.

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

Виды моделей жизненных циклов ПО

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

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

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

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

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

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