Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта / Хабр

Все части

Часть 1. Вводная
Часть 2. Цели и Потребности
Часть 3. Функции системы и Границы проекта
Часть 4. Бизнес процессы, автоматизируемые системой
Часть 5. Сущности предметной области и немного о стратегиях
Часть 6. Поведение системы. Совершенстваоние требований
Часть 7. Передача требований в производство. Заключение

Об авторских тренингах на тему: «Обучение проектированию ПО. Функции системы» подробнее можно узнать на моем YouTube канале

Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль

Дуглас Т. Росс

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

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

Границы проекта (project scope) показывают, какая область конечного продукта будет реализована в текущем проекте. Другими словами, определяется черта между тем, что мы будем делать сейчас и тем, что отложим на потом или от чего вообще сможем отказаться. Для этого в арсенале команды должен быть инструмент, позволяющий не просто строить модели создаваемого продукта, а помогающий наглядно очертить рамки автоматизируемых процессов, а также предоставлять возможность легко выносить процессы за границу или включать их обратно. Это очень важно для осознания и более качественного планирования объемов работ. Подобный инструмент полезен не только для «борьбы» с непомерными желаниями заказчика, но и для маневров менеджмента со стороны разработчиков.

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

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

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

На рисунке 6.1 изображен процесс формализации требований к целевой системе, дополненный подпроцессом определения функций, которые она должна выполнять.

Рисунок 6.1 — модель процесса определения функций

1. Используем нотацию IDEF0 для определения функций системы и границ проекта

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

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

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

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

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

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

2. Пример описания функции “Управление требованиями”

Хочу напомнить основные постулаты стандарта IDEFO. Графическую конструкцию стандарта составляют: понятие «Работа» (Activity) для обозначения действия, представленная в виде блока; четыре вида интерфейса: «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), представленный в виде дуг. Левая сторона блока предназначена для входов, верхняя — для управления, правая — для выходов, нижняя — для механизмов. Для более подробного изучения этой темы обратитесь к [2].

На первом шаге моделирования необходимо определить все потоки данных, поступающих в систему из вне (входные сигналы). В нашем случае это:

• Цели проекта;
• Участники и заинтересованные лица проекта;
• Потребности участников к функциональности целевого продукта проекта;
• Методики разработки требований;

Далее определяем все “продукты”, генерируемые системой для внешнего использования (выходные сигналы):

• Артефакты проекта, в том числе Требования, Модели, Планы и т, д. ;
• Целевой продукт проекта.

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

Рис.6.2 – Функциональная модель системы Управления требованиями верхнего уровня

Проваливаясь во внутрь функции (блока «Работа») мы попадаем на следующий уровень абстракции функциональности системы. Вначале мы видим только потоки данных, выявленные на предыдущем этапе (уровне), см. рис. 6.3.

Рис.6.3 – Начало работы по детализации функции Управление ИТ проектами

Для каждого такого потока необходимо определить процесс, обрабатывающий (преобразующий) или использующий его, добавляя на диаграмме новые блоки «Работ» (функции), связанные с ним.

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

Рис.6.4 – Определение подпроцессов для функции Управление ИТ проектами

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

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

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

Поскольку большинство процессов логически связаны между собой, необходимо установить все потоки данных, обеспечивающие эти связи. Таким образом от функции к функции на диаграмме появляются дуги. Позже, каждая такая дуга (связь), входящая в блок «Работы», должна будет, при моделировании следующего вложенного уровня, “получить” свой процесс обработки.

Пример модели этих функций с уже установленными взаимосвязями отображены на Диаграмме см. Рис. 6.5.

Рис.6.5 – Функциональная модель системы Управления требованиями

Если такие диаграммы используют в документе необходимо сопровождать их подробным описанием. Дальше приведен пример описания:

На рисунке видно, что функциональную архитектуру нашего проекта представлена в виде четырех доменов:

1. Сбор потребностей заказчика. Группа процессов по учету и анализу целей разработки продукта, основных сценариев его использования и действующих лиц — пользователей продукта.
2. Управление спецификациями требований. Процессы формирования функциональных требований на основании выявленных потребностей заказчика и будущих пользователей целевого продукта.
3. Управление формированием заданий. Процессы формирования заданий, направленные на удовлетворение выявленных потребностей заказчика, путем реализации функциональных требований. Фиксация результатов, при выполнении заданий исполнителями, путем изменения состояния требований, по которым оно сформировано.
4. Управление выполнением. Процессы, выполняющие мониторинг и фиксацию приращения функционала, позволяющего реализовывать потребности пользователей в целевом продукте.

В первый функциональный блок “А1”, в качестве входящих параметров, направим данные о целях и пожеланиях заказчика, заинтересованных лицах и т.п. Данные поступают из внешнего окружения системы в виде документов –заявок на разработку или в устной форме. Цель процесса — преобразовать их в информацию, пригодную для передачи в блок “А2” — «Управление спецификациями требований». Результат деятельности первого блока, в виде Пользовательских историй и отчетов, также пригоден и для внешнего использования и доступен внешним системам и пользователям в виде печатных форм или экспорта данных в файлы. Поэтому стрелка из блока разделяется и выходит еще и за границу диаграммы, в вышестоящую функцию.

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

Второй блок, как показано на схеме, получает на вход обработанные пожелания заказчика в виде Пользовательских историй, потребностей пользователей и т.п. уже в формализованном виде. На основании этих данных в нем формируются функциональные требования к разрабатываемому продукту и формализуются в виде спецификаций требований. Дальше эти спецификации передаются в четвертый блок “А4”, отвечающий за выставление задания исполнителям на их реализацию. Из диаграммы видно, что задания могут выставляться и на выполнение работ с требованиями (дуга «Задания», входящая в качестве управления в блок “А2”). Обратите внимание на то, что во второй функциональный блок возвращаются данные об исполнении заданий по спецификациям, что позволяет в этом домене определить приращение функциональности, полученное в ходе разработки.

В третий блок направим из блока “А2”, в качестве управляющих инструкций, ключевые показатели спецификаций. На основании их можно определить степень достижения заданной функциональности, используя отчет о выполнении задний, выставленных по этим спецификациям исполнителям. Отчет поступает в виде входящих параметров из блока “А4”.

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

3. Пример описания функции “Сбор потребностей заказчика”

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

Заглянем в блок А1 на рисунке 6.4, представляющий домен «Сбор потребностей заказчика». Его детализация показана на рисунке 6.5. Все потоки данных, которые входили в блок А1 на рисунке 6.4, соответственно попали и в детализирующую его диаграмму см. рис. 6.6.

Рис. 6.6 – Схема домена Сбор потребностей заказчика

Функционально домен мы разделили на четыре процесса:

1. Интервьюирование заказчиков и пользователей целевого продукта. Процесс фиксации Пользовательской истории, в том числе ее цели. Выполняется проверка наличия подобных историй, зафиксированных ранее. Определяются противоречащие друг другу сценарии. Этот блок должен “покрывать” Пользовательские истории US01, US02
2. Изменение Пользовательской истории. Процесс управления изменениями в описании потребностей заказчика продукта, включая инициацию процесса изменения связанных с ней системных требований. Этот блок должен “покрывать” Пользовательские истории US02.
3. Фиксация заинтересованных лиц проекта. Выявляются все лица, так или иначе связанные с проектом. Этот процесс должен “покрывать” Пользовательские истории US04
4. Определение, уровня реализации Пользовательской истории. Осуществляется мониторинг системных требований, связанных с Пользовательской историей, определяются их текущие состояния и уровень реализации в рамках конечного продукта. Этот блок должен “покрывать” Пользовательские истории US11. Блок, в качеств управляющего интерфейса, получает «Отчет о реализации требования», поступающий из блока “А2” — «Управление спецификациями требований», на основании которого рассчитывается уровень выполнения.

4. Пример описания функции “Управления спецификациями требований”

Следующее уточнение произведем с доменом «Управление спецификациями требований проекта» (А2). На рисунке 6.7 изображена диаграмма этой модели.

Функционально домен делим на четыре процесса:

1. Определение бизнес-процессов. Выполняется разработка функциональной архитектуры целевого продукта, в том числе, определяется важность и приоритетность автоматизируемых процессов — управление границами проекта. Этот блок должен “покрывать” Пользовательские истории US05, US06. В качестве управляющего интерфейса блок получает «Задания», поступающие из блока “А4” — «Управление заданиями» и инициирующие выполнение работ.
2. Разработка спецификаций требований. Разрабатываются нотации логической и физической структуры продукта, формируется контент проекта с детальным описанием требований к целевому продукту, на основе которого будет осуществляться взаимодействие всех участников. Этот блок должен “покрывать” Пользовательские истории US07. В качестве управляющего воздействия блок получает описание стандартов, которым должны соответствовать спецификации.
3. Управление изменениями требований. Фиксируются заявки на изменение ранее утвержденных характеристик целевого продукта. В том числе инициируется процесс формирования заданий на реализацию этих изменений. Этот блок должен “покрывать” Пользовательские истории US10.
4. Управление состоянием требований. Осуществляется мониторинг процесса продвижения проекта, в части реализации требований. Эта функция должна “покрывать” Пользовательские истории US11. В качестве управляющего интерфейса блок получает отчеты «Выполнение Заданий» поступающие из блока “А4” — «Управление заданиями», для определения текущего состояния и уровня реализации проекта.

Рис. 6.7 – Схема домена Управления спецификациями требований проекта

5. Пример описания функции “Управление заданиями”

На рисунке 6. 8 изображена диаграмма, представляющая домен Управления Заданиями проекта (А4). Функционально домен мы разделили на четыре процесса:

1. Формирований заданий на основании спецификаций требования. Формируются задания на реализацию требования в том числе: на проектирование, разработку, тестирование, развертывание, пилотное внедрение. Этот блок должен “покрывать” Пользовательские истории US08.
2. Формирование заданий на итерацию. Осуществляется управление выставлением заданий по плану итерации. Эти требования взяты из стандартного процесса управления проектом с использованием итерационного подхода.
3. Формирование заданий при наступлении риска. Осуществляется управление выставлением заданий по плану устранения последствий риска.
4. Учет выполнения заданий. Формируется отчет о выполнении задания. Происходит изменение статуса объектов проекта по результатам выполнения заданий. Этот процесс должен “покрывать” Пользовательские истории US09.

Рис. 6.8 – Схема домена Управления Заданиями проекта

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

Для процесса 5.2 опишем следующую Пользовательскую историю:

US12. На основании плана итераций проекта отобрать пул задач, которые необходимо реализовать на данном этапе.

Цель: Получить список задач для реализации в текущей итерации проекта.

Процесс 5.3 затрагивает несколько Пользовательских историй:

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

Цель: Выработать альтернативные решения для реализации потребности заказчика, при возникновении проблем.

В случае наступления риска, выполняется пользовательская история US8.

6. Пример описания функции “Управление выполнением”

На рисунке 6. 9 изображена диаграмма, представляющая домен Управления выполнения проекта. Реализация этого домена немного выходит за рамки нашего проекта, но тесно с ним связана. Поэтому рассмотрим и его.

Рис. 6.9 – Схема домен Управления выполнения проекта

Функционально домен мы разделили на четыре процесса:

1. Управление продуктом проекта. Фиксируется выпуск продукта. Формируются отчеты о выпуске
2. Управление качеством. Производится анализ исправления замечаний предыдущей проверки. Определяется соответствие Выпуска требованиям. Оформляется отчет о контроле качества. Выявляются новые проблемы.
3. Управление проблемами. Реагирование на отклонения в ходе выполнения процессов. Выполняется приоритезация ошибок, формируются запросы на изменение.
4. Мониторинг и анализ процессов. Выполняется сравнение плановых значений ключевых показателей с реальными. Определяются значения отклонения. Отслеживаются индикаторы — триггеры («признаки рисков», «симптомы риска»), указывающие на то, что события риска произошли или произойдут в ближайшее время. Этот процесс должен “покрывать” Пользовательские истории US11.

7. Подведем итоги процесса определения функций системы и границ проекта

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

Теперь если мы хотим вынести какую-либо функцию за рамки проекта или его этапа, мы можем проанализировать зависимости и избежать «провисания» остальных функций в линейке технологического процесса.

В итоге, опираясь на разработанные нами диаграммы, мы можем на первом этапе вынести за рамки проекта функции группы «А3 Управления выполнением», а также функции «А4.2 Формирование заданий на итерацию» и «А4. 3 Формирование заданий при наступлении риска». Из диаграммы видно, что в результате система лишится потока данных — «задания исполнителям», обусловленных работами по нивелированию рисков.

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

В следующей части мы будем детализировать процессы, включенные в рамки системы ссылка

.

Список литературы

1. Якобсон А., Буч Г., Рамбо Дж. – «Унифицированный процесс разработки ПО» (2004)

2. Дэвид А. Марк и Клемент МакГоуэн – «Методология структурного анализа и проектирования SADT»

3. Коберн — «Современные методы описания функциональных требований» (2002)

4. Леффингуэлл Дин, Уидрих Дон — «Принципы работы с требованиями к ПО» (2002)

5. Карл И. Вигерс – «Разработка требований к программному обеспечению» (2002)

6. Элизабет Халл, Кен Джексон, Джереми Дик — «Разработка и управление требованиями практическое руководство пользователей» (2005)

7. Скотт Амблер – «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (2005)

8. Гринфилд Джек, Кейн Шорт — «Фабрики разработки программ» (2007)

9. Алистэр Коуберн — «Каждому проекту своя методология»

10. Вольфсон Борис- «Гибкие методологии разработки»

11. Лешек А. — «Анализ требований и проектирование систем»

12. Фримен Эрик, Фримен Элизабет — «Паттерны проектирования» (2011)

13. Эванс Эрик — «Предметно-ориентированное Проектирование» (2011)

14. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»

Рамки проекта

11

Проект
— это временное предприятие,
предназначенное для создания уникальных
продуктов или услуг.

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

Мы
говорим: инвестиционный проект или
финансовый проект, а чем они отличаются?

Инвестирование
– это предпринимательское действие,
которое в разные моменты времени t
приводит к денежным выплатам и
поступлениям, причем этот процесс всегда
начинается с выплаты.

Финансирование
– это действие, которое приводит в
разные моменты времени t
к денежным поступлениям и выплатам,
причем этот процесс всегда начинается
с поступления.

Управление
проектами — это приложение знаний,
опыта, методов и средств к работам
проекта для удовлетворения требований,
предъявляемых к проекту, и ожиданий
участников проекта. Работать и жить
по проектам – это бизнес-кредо (в личной
жизни тоже помогает).

Два
подхода к словосочетанию «управление
проектами»:

— с
точки зрения стратегии;

— с
точки зрения тактики

Немного
общих понятий:

• Операционные
  рамки – состав действий, выполняемых
  по проекту;

• Организационные
  рамки – состав участников проекта;

• Временные
  рамки – период реализации проекта и
  его разбивка на отдельные составляющие.

Действия по проекту (операционные рамки)

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

График
реализации разрабатывается в три этапа:

1. Определяется
   логическая последовательность действий
   без учета продолжительности их
   выполнения;

2. Изучаются
   и выбираются (альтернативно) способы
   выполнения отдельных действий и
   необходимые для этого ресурсы;

3. Составление
   собственно графика, имеющего временную
   привязку, а также привязку по ресурсам.

Участники проекта (организационные рамки)

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

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

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

Действия и
бездействие как обязанности участников
проекта.

Временные параметры проекта

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

• Шаг
  расчетного периода – отрезок времени
  в расчетном периоде, для которого
  определяются технические, экономические
  и финансовые показатели.

Начало
расчетного периода:

1. Момент
   завершения расчетов эффективности;

2. Момент
   начала инвестиций;

3. Момент
   осуществления первого из действий по
   проекту;

4. Момент
   начала операционной деятельности.

Окончание
расчетного периода:

1. Нормальное.

   1. Прекращение
      спроса на производимую продукцию;

   2. Износ
      основных зданий, сооружений и
      технологического оборудования;

   3. Исчерпание
      месторождения сырья;

   4. Предусмотренная
      проектом реализация активов, созданных
      в ходе проекта.

2. Катастрофическое
   (это уже риски!).

   1. Стихийное
      бедствие, аварии или отказ оборудования;

   2. Существенные
      изменения экономической политики или
      законодательства;

   3. Негативные
      изменения рыночной конъюнктуры;

   4. Выход
      финансовых показателей за пороговые
      значения;

   5. Возникновение
      недопустимых социальных последствий.

Кстати о рисках:

Что
подразумевать под риском:

— Лишние
траты:

1. времени

2. денег

3. ?

—
Невозможность закончить проект и достичь
его цели

Чтобы
все это получилось необходимо проектами
управлять, а без системы управлять
невозможно, поэтому:

Основные положения системы управления проектами

Для успешного
применения методов управления проектами
надо:

• Ограничить масштаб
  проекта: четко определить продукт,
  ограничить по времени и персоналу;

• Разделять продукт
  на части: модули по техническим
  характеристикам, функциям, подсистемам
  и объектам;

• Разбивать проект:
  выделение команд и групп, разрабатывающих
  отдельные технические характеристики,
  поэтапных подпроектов;

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

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

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

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

Процессы
Управления Проектами

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

• Процессы
  управления проектами
  — касающиеся организации и описания
  работ проекта; в нашем примере:

• Процессы,
  ориентированные на продукт
  — касающиеся спецификации и производства
  продукта; в нашем примере

Процессы
Управления Проектами

Процессы
управления проектами могут быть разбиты
на шесть основных групп:

• процессы
  инициирования
  — принятие решения о начале выполнения
  проекта;

• процессы
  планирования
  — определение целей и критериев успеха
  проекта и разработка рабочих схем их
  достижения;

• процессы
  исполнения
  — координация людей и других ресурсов
  для выполнения плана;

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

• процессы
  управления
  — определение корректирующих воздействий,
  их согласование, утверждение и применение;

• процессы
  завершения —
  формализация выполнения проекта и
  подведение его к упорядоченному финалу.

В соответствии со
стандартом Института управления
проектами (PMI)
управление проектами состоит из следующих
функций:

• планирование,

• контроль,

• анализ,

• принятие решений,

• бюджетирование,

• организация
  осуществления проекта,

• мониторинг,

• оценка,

• отчетность,

• экспертиза,

• проверка и приемка,

• бухгалтерский и
  управленческий учет,

• администрирование.

Структура проекта

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

Обычная
функциональная структура предприятия

Структура,
ориентированная на проекты

Сравнение
возможностей организационных структур
для реализации проектов

О

сновные
процессы планирования

Вспомогательные
процессы планирования

Процессы
исполнения

Процессы анализа

Процессы
управления

Процессы
завершения

Что такое масштаб проекта?

Что такое объем проекта?

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

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

Большие проекты имеют тенденцию изменяться по мере их выполнения. Если в начале проект был эффективно «распределен», то утверждение этих изменений и управление ими будет проще. При документировании масштаба проекта заинтересованные стороны должны быть как можно более конкретными, чтобы избежать расползания масштаба. Расползание масштаба — это ситуация, в которой одна или несколько частей проекта требуют больше работы, времени или усилий из-за плохого планирования или недопонимания.

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

Важность определения масштаба проекта

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

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

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

Как определить объем проекта

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

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

• цель и результаты проекта;
• , когда проект должен быть завершен; и
• сколько заинтересованные лица могут заплатить за это.

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

Посмотрите, как объем проекта вписывается в общее проектное предложение.

Написание описания содержания проекта

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

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

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

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

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

Планирование содержания и управление

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

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

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

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

Пример содержания проекта

Заявления о масштабах

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

• Введение. Это определяет что и почему проекта. Примером может быть: «Этот проект по созданию контента и маркетингу осуществляется компанией RealContent Inc. для распространения статей в своем блоге и на сайтах социальных сетей для повышения узнаваемости бренда и увеличения посещаемости веб-сайта».
• Объем проекта. Это определяет требования проекта. Он устанавливает общие цели для графика проекта и задач и определяет, кто будет вовлечен. В примере с созданием контента можно указать: «Проект будет включать в себя исследование, написание, стратегию контента и поисковую оптимизацию, а также публикацию на веб-сайте компании и в профилях социальных сетей в марте 2021 года. Джон Смит, директор по контенту RealContent, будет контролировать эти задачи. Персонал и авторы контрактов создадут результаты».
• Результаты. Раздел результатов определяет, что будет предоставлено в конце проекта, и указывает дату отправки. В нашем примере «Результаты проекта будут включать хорошо проработанную статью из 2000 слов, которая будет опубликована не позднее 28 февраля 2021 года. тот же срок».
• Критерии приемлемости. Здесь описываются цели проекта и показатели, которые будут использоваться для оценки успеха. Например, «Основная статья наберет 3000 кумулятивных просмотров страниц в течение шести месяцев после публикации и создаст двух новых лидов».
• Исключения. Описывает то, что не будет включено в проект. Например, «Проекту не потребуется создавать мультимедиа для статей».
• Ограничения. Здесь перечислены жесткие ограничения проекта и вещи, которые нельзя изменить. Ограничения проекта могут относиться к графику проекта, бюджету проекта или техническим проблемам. Например, «Проект имеет точную дату подачи 28 февраля 2021 года и твердый бюджет в размере 5000 долларов США».

Объем проекта и объем продукта

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

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

Еда на вынос

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

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

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

Последнее обновление: сентябрь 2021 г.

Продолжить чтение О масштабах проекта

• Топ-15 вопросов для собеседования с менеджером ИТ-проекта

• Проверьте себя по принципам управления проектами Agile

• Удаленное внедрение ERP: 10 основных принципов управления проектами

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

• От общего объема проекта до полного контроля над проектом

Углубленное изучение ИТ-приложений, инфраструктуры и операций

• устав проекта

  Автор: Александр Гиллис

• Планирование проекта: что это такое и 5 шагов для создания плана

  Автор: Бен Луткевич

• Примеры экзаменационных вопросов CCISO по управлению проектами безопасности

  Автор: Кэти Донеган

• Как написать документ с бизнес-требованиями в Agile

  Автор: Дайан Хоффман

SearchCloudComputing

• 
  Сравните AWS Global Accelerator и Amazon CloudFront

  AWS Global Accelerator и Amazon CloudFront решают похожие проблемы. Но пользователи должны знать, когда использовать одно вместо другого. Откройте для себя…

• 
  Лучшие практики для многооблачной стратегии Kubernetes

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

• 
  Руководство для конференции по AWS re:Invent 2022

  Ознакомьтесь с последними новостями, выпусками продуктов и обновлениями технологий, а также анализом и рекомендациями экспертов от AWS re:Invent 2022 …

SearchMobileComputing

• 
  Вопросы и ответы Jamf: как упрощенная регистрация BYOD помогает ИТ-специалистам и пользователям

  Руководители Jamf на JNUC 2022 делятся своим видением будущего с упрощенной регистрацией BYOD и ролью iPhone в …

• 
  Jamf приобретет ZecOps для повышения безопасности iOS

  Jamf заплатит нераскрытую сумму за ZecOps, который регистрирует активность на устройствах iOS для выявления потенциальных атак. Компании ожидают …

• 
  Apple преследует растущий премиальный рынок с iPhone 14

  Apple переключила свое внимание на смартфоны премиум-класса в последней линейке iPhone 14 с такими функциями, как режим блокировки, который ИТ …

SearchDataCenter

• 
  Включите VXLAN в центры обработки данных для повышения скорости сети
  Сети

  VXLAN обеспечивают изоляцию сети и позволяют организациям более эффективно масштабировать сети центров обработки данных. Рассмотрите VXLAN для расширения…

• 
  HPE обновляет серверы ProLiant в комплекте с лицензией GreenLake

  HPE добавила еще один вариант программного обеспечения и услуг с новыми серверами ProLiant с GreenLake, улучшенным программным обеспечением для обеспечения безопасности и …

• 
  Учитывайте этические вопросы технологий при росте центра обработки данных

  Авторы Гарри Льюис и Кен Ледин обсуждают этические вопросы, которые организации должны учитывать при расширении центров обработки данных, . ..

Что такое масштаб проекта? Определение и описание успеха проекта

Дом

Функция

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

Мойра Александр

CIO 15 мая 2020 г. 3:00 PDT

Thinkstock

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

Определение содержания проекта

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

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

• Техническое описание проекта (SoW), которое представляет собой подробную разбивку всей работы, которую должна выполнить команда проекта, и любые важные элементы, которые могут повлиять на результат
• Ограничения, которые могут ограничить или негативно повлиять на результат проекта , включая ресурсы, вопросы закупок, сроки или отсутствие информации
• Исключения из области охвата, которыми может быть все, что не будет частью проекта или его результатов
• Вехи, указывающие точную дату, когда что-то будет поставлено или завершено
• Окончательные результаты, которые будут предоставлены заказчику в конце проекта — например, отчет, функция программного обеспечения, любая информация о процессе или анализ, или любой продукт или услуга, которые нужны заказчику
• Критерии приемлемости точно определить, как будет измеряться успех
• Окончательное утверждение, посредством которого заказчик подписывает описание объема работ, подтверждая, что все параметры были включены, а документ является полным и точным

Основные этапы определения содержания проекта

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

1. Работайте с ключевыми заинтересованными сторонами, чтобы определить и создать заявление о содержании, определяя, что находится в пределах и вне области действия. Сотрудничество с заинтересованными сторонами помогает гарантировать, что важные вещи не останутся незамеченными.
2. Выявление, документирование и передача предположений. Предположения — это те элементы, которые относятся к проекту и считаются верными на протяжении всего проекта. Предположения необходимы для обеспечения оценки стоимости и графика для достижения объема проекта на этапе планирования проекта.
3. Заручитесь поддержкой заявлений о содержании с заинтересованными сторонами, которые больше всего затронуты, чтобы убедиться, что все находятся на одной волне.

Пример содержания проекта

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

• Введение. Этот контент-маркетинговый проект осуществляется для компании XYZ с целью создания статьи для размещения на их сайте для повышения узнаваемости бренда.
• Объем проекта . Этот проект будет включать в себя исследование, контент-стратегию, написание статьи и ее публикацию на веб-сайте XYZ в блоге XYZ. Это также будет включать в себя публикацию статьи в социальных сетях за апрель 2020 года. Все мероприятия будут проводиться Джо Смитом из компании ABC.
• Результаты проекта. Результаты проекта будут включать одну тщательно проработанную письменную статью объемом до 1000 слов, которая будет доставлена ​​по электронной почте на адрес [email protected] не позднее ___ числа.
• Критерии приемлемости проекта. Джейн из компании XYZ рассмотрит и утвердит окончательный вариант статьи перед публикацией.
• Исключения проекта. Этот проект не будет включать платежи внешним поставщикам за исследования или внешние услуги.
• Ограничения проекта. Ограничения могут включать задержки связи, изменения объема или технические трудности.

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

Что такое расползание области действия?

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

Управление содержанием проекта

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

1. Определите, есть ли изменения в требованиях к вашему проекту. Это жизненно важный шаг, поскольку эти изменения напрямую влияют на цели проекта и все связанные с ним действия.
2. Определите, как изменения повлияют на проект. Прежде чем вносить коррективы в объем проекта, необходимо понять, где и как изменения влияют на результат.
3. Получите одобрение изменений, прежде чем приступить к изменению деятельности или направления.
4. Своевременно внедряйте одобренные изменения, чтобы уменьшить задержки и риски.

Дополнительные сведения об управлении содержанием проекта см. в разделе «7 советов по управлению содержанием проекта».

Шаблон содержания проекта.

Во Введении представлен общий обзор проекта.

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

This entry was posted in Семантическое ядро