Характеристики жизненного цикла проекта

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

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

В большинстве случаев описания жизненных циклов различных проектов обладают рядом схожих характеристик:

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

• В начале проекта вероятность его успешного завершения минимальна, а риск и неопределенность максимальны. По мере выполнения проекта шансы успешного завершения постепенно возрастают.

• Возможность повлиять на результаты проекта и его стоимость у участников проекта максимальна в начале проекта и постепенно уменьшается в ходе его выполнения.

Современные процессы разработки программного обеспечения.

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

Выбор методологии

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

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

• масштаб проекта;

• критичность проекта — проекты, в которых ошибки могут приводить к тяжелым последствиям, вплоть до гибели людей, должны проводиться гораздо более формально, чем те проекты, в которых ошибки приводят только к временным неудобствам;

• распределение участников — чем компактнее расположены участники, чем легче им общаться между собой, тем менее формализованным может быть проект;

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

• требования заказчика — существенно различаются в зависимости от отрасли и статуса организации-заказчика. Как правило, эти требования выше для государственных предприятий;

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

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