Использование ИСП.

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

при участии всех менеджеров и членов команды, которых затрагивает структура проекта, она анализируется и при необходимости переделывается до тех пор, пока не будет достигнуто полное согласие по поводу ее корректности;

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

для каждого элемента структуры проекта ("сверху вниз" - на всех уровнях до каждой задачи) указываются:

o ответственная и исполняющая организации и функциональные

лидеры проекта; o спецификации продукта

o основной контракт, контракты с субподрядчиками и основные заказы

o оценки и бюджеты ресурсов (сотрудники, фонды, программное и

аппаратное обеспечение) и бюджеты; o номера рабочих заданий/нарядов на работы; o номера счетов издержек (только на уровне задач); o контрольные события и относящиеся к ним операции в сетевых планах: методика анализа и оценки проекта или программы (РЕЯТ)/метод критического пути (СРМ)/управление данными о продукте (PDM) с запланированными датами;

суммируется информация о ресурсах, указанных в структуре проекта: для каждого элемента и проекта в целом сравниваются оценки, бюджеты, ответственности, расходы и фактическое выполнение;

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

оцениваются результаты с целью выявления проблем и выполнения соответствующих корректирующих действий;

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

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

При разработке ИСП необходимо принимать во внимание следующие основные правила:

Каждый элемент ИСП должен обеспечивать достижение ощутимого результата.

Каждый элемент ИСП должен являться агрегатом всех подчиненных элементов, перечисленных непосредственно под ним.

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

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

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

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

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

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

Все пакеты работ должны быть совместимы с организационной структурой и структурой затрат.

Результаты должны быть четко определены так, чтобы исключить дублирование объемов работ внутри элементов ИСП, в целом по организации или отдельными ответственными за выполнение работ.

Результаты должны иметь размер, достаточный для эффективного управления, но не настолько малый, чтобы сделать затраты на контроль чрезмерными.

Традиционные декомпозиции работ обычно имеют три фундаментальных порока.

Они создаются преждевременно при разработке продукта.

Они преждевременно детализируются, планируются и финансируются либо слишком подробно, либо недостаточно подробно.

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

Поэтому в связи со спецификой работ по внедрению КИС применяются эволюционные модели ИСП

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

Элементами ИСП первого уровня являются рабочие процессы (управление проектом, создание рабочей среды, управление требованиями, проектирование, реализация, оценка и внедрение). Эти элементы обычно закрепляются за одной командой и формируют «анатомию» проекта, которая используется в целях планирования и сравнения с другими проектами.

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

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

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

A. Управление проектом

A.a. Управление начальной стадией A.a.a. Разработка бизнес-плана A.a.b. Спецификации версии стадии уточнения A.a.c. Определение основ ИСП стадии уточнения A.a.d. План разработки ПО

A.a.e. Контроль и оценка состояния проекта на начальной стадии

A.b. Управление стадией уточнения

A.b.a. Спецификации версии стадии конструирования ,

A.b.b. Определение основ ИСП стадии конструирования

A.b.c. Контроль и оценка состояния проекта на стадии уточнения

A.c.Управление стадией конструирования A.c.a. Планирование стадии внедрения A.c.b. Определение основ ИСП стадии внедрения

A.c.c. Контроль и оценка состояния проекта на стадии конструирования

d. Управление стадией ввода в действие A.d.a. Планирование следующего поколения

d.b. Контроль и оценка состояния проекта на стадии ввода в действие

Создание рабочей среды

a. Спецификации среды на начальной стадии B.b. Базовая среда на стадии уточнения

b.a. Инсталляция и администрирование среды разработки B.b.b.

B.c.Сопровождение среды на стадии конструирования

B.c.a. Инсталляция и администрирование среды разработки B.c.b. Сопровождение базы данных запросов на изменение

d. Сопровождение среды на стадии ввода в действие B.d.a. Сопровождение и администрирование среды разработки B.d.b. Сопровождение базы данных запросов на изменение

d.c. Формирование и передача среды сопровождения

Управление требованиями

a. Разработка требований на начальной стадии

a.a. Описание концепции

C.a.b. Моделирование вариантов использования C.b. Определение основных требований на стадии уточнения C.b.a. Определение основ концепции

b.b. Моделирование основных вариантов использования C.c.Сопровождение требований на стадии конструирования

d. Сопровождение требований на стадии ввода в действие

Проектирование

a. Создание архитектурных прототипов на начальной стадии D.b. Определение базовой архитектуры на стадии уточнения

b.a. Моделирование проекта архитектуры

D.b.b. Планирование и проведение демонстрации проекта D.b.c. Описание архитектуры ПО D.c. Моделирование проекта на стадии конструирования D.c.a. Сопровождение модели проекта архитектуры

c.b. Моделирование компонентов

d. Сопровождение проекта на стадии ввода в действие

Реализация

a.Создание прототипов компонентов на начальной стадии E.b. Реализация компонентов на стадии уточнения

b.a. Интеграция для демонстрации кодирования критичных компонентов E.c. Реализация компонентов на стадии конструирования

E.c.a. Кодирование компонентов для начальных версий и их автономное тестирование

E.c.b. Кодирование компонентов для альфа-версии и их автономное тестирование

E.c.c. Кодирование компонентов для бета-версии и их автономное тестирование E.d. Сопровождение компонентов

E.e.Сопровождение компонентов на стадии ввода в действие

Оценка

F.a.

F.b.Оценки на стадии уточнения F.b.a. Моделирование тестов

F.b.b. Реализация сценариев тестирования архитектуры F.b.c. Оценка демонстрации и описания версии Оценки на стадии конструирования

F.b.d. Оценка начальной версии и описание версии F.b.e. Оценка альфа-версии и описание версии

b.f. Оценка бета-версии и описание версии

F.c. Оценки на стадии ввода в действие

d.Оценка версии продукта и описание версии

Внедрение

a. Планирование внедрения на начальной стадии

G.b. Планирование внедрения на стадии уточнения

G.c. Внедрение на стадии конструирования

c.a. Определение основ руководства пользователя

G.d. Внедрение на стадии ввода в действие

G.d.a. Передача продукта пользователю

Приведенная структура должна рассматриваться как отправная точка. Ее необходимо подогнать под особенности проекта по многим направлениям.

Масштаб. Более масштабные проекты будут иметь больше уровней и подструктур.

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

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

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

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

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