Процесс планирования проекта в рамках жизненного цикла системы
Цель процесса планирования проекта
Цель процесса планирования проекта состоит в составлении и доведении до заинтересованных сторон эффективного и выполнимого плана проекта
В результате успешного выполнения процесса планирования проекта:
обеспечивается доступ к проектным планам;
определяются роли, ответственность и полномочия участников;
формируется официальный запрос на ресурсы и услуги, необходимые для достижения целей проекта;
определяются показатели для характеристик проекта;
штат проекта ориентируется в соответствии с планами проекта.
При реализации процесса планирования проекта организация должна осуществлять следующие действия в соответствии с принятой политикой и процедурами:
определять проектные цели и ограничения;
определять границы проекта в соответствии с соглашением;
устанавливать декомпозицию работ, основанную на развивающейся системной архитектуре;
определять и поддерживать графики работ в рамках проекта, основываясь на целях проекта и оценках выполнимости работ;
определять критерии достижения результатов проекта для схем принятия решений на стадиях жизненного цикла, сроков поставок и основных зависимостей от внешних входов или выходов;
определять расходы на проект и планировать бюджет;
устанавливать структуру полномочий и ответственности за выполнение работ в рамках проекта;
определять инфраструктуру и службы, необходимые для реализации проекта;
планировать приобретение материалов, покупных изделий и услуг обеспечивающих систем для выполнения проекта;
формировать и доводить план до заинтересованных сторон для технического управления проектом, включая соответствующие ревизии;
определять проектные показатели, которые должны быть сформированы, и связанные с ними данные, которые должны быть собраны, подвергнуты валидации и анализу;
составлять планы по обеспечению качества проекта.
Схема взаимосвязи результатов выполнения работ по планированию проекта в рамках жизненного цикла системы
Планирование проекта разработки ис в соответствии с положениями гост группы 34 «Информационные технологии»
Планирование проекта разработки ИС выполняется в рамках следующих стадий и работ:
стадия «Разработка концепции АС», в ходе которой выполняются следующие работы: изучение объекта; проведение необходимых научно-исследовательских работ; разработка вариантов концепции АС, удовлетворяющих требованиям пользователя; оформление отчета о выполненной работе;
стадия «Техническое задание», в ходе которой выполняется работа «Разработка и утверждение технического задания на АС».
Основные результаты планирования проекта разработки ИС по ГОСТ группы 34
Основными результатами данных стадий являются документы «Отчет о выполнении работы на стадии «Разработка концепции АС» и «Техническое задание на АС»
Основная особенность применения ГОСТ группы 34 для планирования проекта разработки ИС
В ГОСТах группы 34 не раскрыты практические рекомендации по способам выполнения работ данных стадий. Поэтому основное содержание этих работ менеджеру проекта следует определять, исходя из структуры и состава документов «Отчет о выполнении работы на стадии «Разработка концепции АС» и «Техническое задание на АС»
В основной части документа «Отчет о выполнении работы на стадии «Разработка концепции АС» приводят:
описание результатов изучения объекта автоматизации (а);
описание и оценку преимуществ и недостатков разработанных альтернативных вариантов концепции создания АС (б);
сопоставительный анализ требований пользователя к АС и вариантов концепции АС на предмет удовлетворения требованиям пользователя (в);
обоснование выбора оптимального варианта концепции и описание предлагаемой АС (г);
ожидаемые результаты и эффективность реализации выбранного варианта концепции АС (д);
ориентировочный план реализации выбранного варианта концепции АС (е);
необходимые затраты ресурсов на разработку, ввод в действие и обеспечение функционирования (ж);
требования, гарантирующие качество АС (и);
условия приемки системы (к).
Схема соответствия результатов планирования проекта в рамках жизненного цикла системы содержанию документа «Отчет о выполнении работы на стадии «Разработка концепции АС»
Документ «ТЗ на АС» содержит следующие разделы:
общие сведения (а);
назначение и цели создания (развития) системы (б);
характеристика объектов автоматизации (в);
требования к системе (г);
состав и содержание работ по созданию системы (д);
порядок контроля и приемки системы (е);
требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие (ж);
требования к документированию (и);
источники разработки (к).
Схема соответствия результатов планирования проекта в рамках жизненного цикла системы содержанию документа «ТЗ на АС»
Выводы по результатам анализа сопоставления:
с точки зрения управления проектом разработки ИС оба рассмотренных документа, вопреки утверждению ГОСТ 34.602-89, содержат информацию о плане управления данным проектом;
содержание документа «Отчет о выполнении работы на стадии «Разработка концепции АС» ориентировано на уровни менеджера проекта и офиса управления проектом, поскольку описывает общесистемные решения в области управления проектом разработки ИС;
содержание документа «ТЗ на АС» ориентировано на уровни менеджера проекта, офиса управления проектом и исполнителей проекта и является отображением плана управления проектом разработки ИС на уровень исполнителей всех проектных работ по разработке ИС;
документ «Отчет о выполнении работы на стадии «Разработка концепции АС» можно охарактеризовать как документ, содержащий стратегический и, частично, оперативный планы управления проектом разработки ИС;
документ «ТЗ на АС» можно охарактеризовать как документ, содержащий оперативный и текущие планы управления проектом разработки ИС;
документ «ТЗ на АС» является ЕДИНСТВЕННЫМ проектным документом в рамках методологии разработки ИС по ГОСТам группы 34 «Информационные технологии», который устанавливает соответствие между планом управления проектом и его исполнением конкретными сотрудниками поставщика ИТ-услуг.
Литература:
Руководство к своду знаний по управлению проектами (руководство PMBOK). Четвертое издание [Текст]. – Project Management Institute, Inc., 14 Campus Boulevard Newtown Square, Pennsylvania 19073-3299 USA, 2008. – 242 p.
ГОСТ ИСО/МЭК 15288 – 2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем» [Текст]. – М.: Федеральное агентство по техническому регулированию и метрологии, 2006. – 57 с.
ГОСТ ИСО/МЭК 12207 – 2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств» [Текст]. – М.: Стандартинформ, 2011. – 106 с.
ГОСТ 34.601-90. Информационные технологии. Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы.
РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов.
()
Принципы планирования и управления требованиями к информационной системе
процесс сбора требований в стандарте PMBOK;
основные определения и описания требований к информационным и программным системам;
основы управления требованиями к информационным и программным системам;
основные проблемы работы с требованиями к информационным и программным системам;
процессы работы с требованиями в стандартах ISO/IEC 15288:2002 и ISO/IEC 12207:2008;
процессы работы с требованиями в методологии SSADM.
Процесс сбора требований в стандарте PMBOK
Определение понятия «процесс сбора требований»
Сбор требований – процесс определения и документирования требований заинтересованных сторон проекта для достижения целей проекта
Определение понятия «требование» согласно PMBOK
Требования включают в себя количественно определенные и задокументированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон проекта
Входами процесса сбора требований являются:
Устав проекта, который используется для предоставления требований к проекту высокого уровня и описания продукта высокого уровня, позволяющих разработать подробные требования к продукту;
реестр заинтересованных сторон проекта, который используется для определения заинтересованных сторон проекта, которые могут предоставить подробную информацию о требованиях к проекту и продукту.
Основными методами и инструментами сбора требований являются:
интервью;
фокус-группы;
семинары с участием модератора; групповые творческие методы (мозговой штурм, метод номинальных групп, метод Дельфи, составление интеллект-карт, диаграммы сходства);
методы группового принятия решений (единогласие, большинство голосов, относительное большинство голосов, диктатура);
анкеты и опросы;
наблюдения;
прототипы.
Выходами процесса сбора требования являются:
документы по требованиям;
план управления требованиями;
матрица отслеживания требований.
Элементы документов по требованиям могут включать в себя среди прочего:
бизнес-потребность или возможность, которую необходимо использовать, с описанием ограничений нынешней ситуации и того, почему необходима реализация проекта;
цели бизнеса и проекта для возможности контроля;
функциональные требования, соответствующим образом описывающие бизнес-процессы, информацию и взаимодействие с продуктом, которые могут быть задокументированы в текстовой форме в списке требований, в моделях или в обоих вариантах;
нефункциональные требования, такие как уровень обслуживания, производительность, безопасность, надежность, соответствие нормам, наличие технической поддержки, длительное использование / чистка и т.д.;
требования к качеству;
критерии приемки;
бизнес-правила, описывающие руководящие принципы организации;
влияние на другие отделы организации, такие как центр обработки вызовов, отдел продаж, технологические группы;
влияние на другие органы внутри и за пределами исполняющей организации;
требования к технической поддержке и обучению;
допущения и ограничения в отношении требований.
Элементы плана управления требованиями могут включать в себя среди прочего:
порядок планирования, отслеживания и составления отчетов о действиях в отношении требований;
действия по управлению конфигурацией, такие как порядок инициирования изменений требований к продукту, услуге или результату, порядок анализа влияния, его выявления, отслеживания и составления отчетов о нем, а также уровни полномочий, необходимые для одобрения данных изменений;
процесс расстановки приоритетов требований;
используемые показатели продукта и обоснование их использования;
структуру отслеживания, т.е. какие параметры требований будут отражены в матрице отслеживания, и требования к каким другим документам проекта будут отслеживаться.
Общее представление матрицы отслеживания требований
Матрица отслеживания требований представляет собой таблицу, которая связывает требования с их происхождением и отслеживает их на протяжении жизненного цикла проекта.