Развивающиеся проекты

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

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

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

Иерархический характер модификации версий структуры содержания проекта и структуры продукции проекта можно продемонстрировать на конкретном примере. 'Вслед за созданием первой версии программы появляется подверсия с номером 1.1 или подверсия еще более низкого уровня — 1.1.1. В зависимости от потребностей могут создаваться подверсии 1.2, 1.3 и т.д. или же подверсии более низкого уровня — 1.1.2, 1.1.3... 1.1.10, 1.2.1, 1.2.2... 1.2.5 и т.д. После того как потенциал решений первой версии будет исчерпан, начинается развитие новой, второй версии программного продукта с последующим развитием ее подверсии (2.1, 2.2 и т.д.). Таким образом, по ходу развивающегося проекта складывается сложная иерархическая система последовательного (а иногда и параллельного) управления структурой продукции. Цифровой код той или иной версии определяется самым нижним уровнем структуры продукции, который не подвергался изменениям. Иными словами, версии 1.3.4 и 1.3.7 созданы на базе версии 1.3, т.е. на основе модификации третьего уровня; в данном случае второй уровень является нижним уровнем структуры продукции, который не подвергается изменениям при разработке этих версий. Этот нижний, не подвергаемый изменениям уровень является базовым для создания всех производных от него версий. Такая иерархическая модель наглядно демонстрирует особенности развивающегося проекта (конечно, реальная нумерация и кодификация различных версий продукции определяется не только логикой внесения изменений в конфигурацию продукции, но и содержанием проекта и его продукции).

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