Классификация действий по реализации проекта
Есть много классификаций действий по реализации проекта, но наиболее используемые из них: рабочие пакеты; задачи; внедрения; вехи.
Рабочий пакет – большой, логически определенный раздел работы, обычно продолжительностью, по крайней мере, 12 месяцев; может включать разноплановые параллельные действия. Он независим от других действий, но может зависеть от других действий, или влиять на них; обычно выполняется одной командой специалистов.
Задача – обычно значительно меньшая по объему работа. Это часть рабочего пакета, обычно 3–6 человек/месяцев; может зависеть от другого параллельного действия; обычно выполняется одним человеком.
Внедрения – выход проекта, который может быть реально оценен.
Примеры: отчет (например, список требований к системе); программа (например, альфа версия изделия).
Внедрения – индикаторы хода выполнения работы.
Вехи – момент, на который может быть оценено состояние выполнения проекта. Обычно главный поворотный момент в разработке проекте.
Примеры: составление списка требований к системе; внедрение альфы версии программы.
Рабочие пакеты обозначаются WP1, WP2...; задачи обозначаются T1.1, T1.2, и т. д.; первое число – номер рабочего пакета; второе – порядковый номер.
Внедрения обозначаются D1.1, D1.2, и т. д.; вехи обозначаются M1, M2 и т. д.
Для каждого рабочего пакета и задачи, это обычно составляются документы: краткое описание; самая ранняя дата начала; самая ранняя дата конца; общее число человек/месяцев; рабочие пакеты или задачи, оказывающие влияние на данные; зависимые рабочие пакеты или задачи; кто ответственный.
Критические пути
Влияния и зависимости рабочих пакетов и задач определяют критический путь – последовательность зависимостей в проекте.
Критический путь – последовательность действий, осуществляющая самый долгий процесс разработки проекта. Любая задержка в осуществлении действий критического пути вызовет задержку в реализации всего проекта.
Задержки в действиях не на критическом пути не обязательно ведут к задержкам всего проекта.
Контрольные вопросы.
Классические схемы разработки корпоративных систем
В процессе разработки любых проектов всегда участвуют такие компоненты, как целеопределение, системотехника, технологии, ресурсы и окружающая инфраструктура. Успешность реализации проектов всегда зависит от того, на сколько управляемы все эти компоненты. Создание и реализация проектов всегда предусматривает организацию работ в несколько фаз, так как в противном случае резко снижается управляемость работ. Ранее, при разработке проектов использовалась так называемая водопадная модель организации работ (рис. 3).
При такой модели работ все фазы выполнялись последовательно, а критериями качества, на основе которых строилась организация управления проектом, были полнота и законченность проектной документации на каждой стадии и планируемость сроков и стоимости работ. Управление качеством по этим критериям было возможно потому, что следующая фаза работ не могла начаться до завершения предыдущей. Применение водопадной модели является наиболее оптимальным, когда осуществляются проекты, не требующие больших затрат времени и ресурсов.
При разработке и внедрении "больших" систем, например, систем управления предприятиями, такая схема приводила к тому, что сроки выполнения работ всегда сдвигались из-за того, что не учитывалась динамика изменений требований к разрабатываемой системе, а к моменту окончания разработки продукт, формально отвечающий всем требованиям по качеству, оказывался бесполезным или по крайней мере устаревшим. Одной из главных причин, по которой нарушались планы создания систем, была "величина" системы. В современных условиях требования к разработке систем резко ужесточились. Сроки создания и внедрения таких систем должны быть резко сокращены, а сама система управления должна давать приращение нового качества в каждой функции управления, то есть старый принцип работы таких систем , "что на входе, то и на выходе", уже не удовлетворяет потребителя.
Рис. 3. Водопадная модель