что такое границы проекта
Управление содержанием проекта
Содержание проекта – это то, что проект включает в себя, и в чем он состоит. Управление содержанием проекта – достаточно большая область знаний, владея которыми Руководитель проекта определяет, что входит в проект и что остается за его рамками.
Содержание проекта – это наличие в проекте тех работ, которые необходимо выполнить, для того, чтобы получить желаемый результат.
Таким образом, содержанием нужно управлять и контролировать его на протяжении всего жизненного цикла проекта, следить за тем, чтобы в списке необходимых работ не появились лишние, не относящиеся к желаемому результату проекта. Или какие-то побочные, относящиеся уже к другому проекту.
Также стоит различать содержание проекта и содержание продукта: в первом случае, это работы, которые необходимо выполнить для получения желаемого результата (продукта, услуги), во втором случае – это функции и характеристики результата.
В процессе определения содержания появляется детальный документ, в котором отражены цели и задачи проектных работ.
Не стоит так же забывать, что для достижения одного результата могут быть использованы различные альтернативные методы, таким образом, следует рассматривать вопрос шире, со всех сторон, чтобы не упустить более выгодные возможности.
После того, как разработан и утвержден устав проекта, собраны и задокументированы требования, может быть составлено описание содержания проекта. Оно уже содержит больше информации о проекте, и оно более детально.
Качественно составленное описание содержания проекта важно еще и потому, что впоследствии будет являться основой для планов и решений. В то время как при плохо определенных целях могут возникнуть значительные риски.
Чем детальнее и однозначнее звучат пункты содержания проекта, тем проще потом определить, что проект завершен, то есть выполнены все требования и достигнуты все поставленные цели.
Но мы все понимаем, что в процессе жизненного цикла проекта появляется все больше и больше уточняющей информации, что необходимо учитывать при дополнении и детализации содержания проекта, при необходимости согласовывая с заинтересованными лицами.
Содержание проекта включает в себя:
Об описании содержания проекта, критериях приемки результата и границах проекта поговорим ниже.
Описание содержания проекта
В описание проекта входит достаточно высокоуровневое описание того, какие результаты должны быть получены. По большому счету, это следующий уровень детализации того содержания, которые было приведено в уставе проекта. Важно включить сюда то, что требуется сделать или произвести для получения результата. Например, если вы внедряете новую информационную систему, в содержание проекта будет входить:
Критерии приемки результата проекта
По каждому из элементов содержания проекта, приведенному выше, указывается, как заказчик и мы сами поймем, что результат действительно соответствует ожиданиям? Это обычно самая сложная часть описания содержания проекта, т.к. степень неопределенности еще слишком высока, а договариваться нужно уже тут, на берегу,пока работы не начались.
Настоящее искусство – это сформулировать критерии так, чтобы они были действительно удобны в использовании и не вызывали разночтения.
Например, для элемента “Обученные пользователи” (подкатегория “Обученные бухгалтера по работе с дебиторами”) критерием приемки может быть “Бухгалтер может выполнить следующие операции: ввод акта сверки, согласование счета и т.д. самостоятельно не более чем за 1 минуту”.
Границы проекта
Помимо того, что команда проекта будет делать в ходе его реализации, очень важно определить, чего она делать не будет.
На рисунке ниже схематично изображено определение границ проекта.
Определение границ проекта
В ходе описания границ проекта определяются и документируются все моменты, которые могут подразумеваться как часть проекта, но таковой не являются (опять же, в идеально случае вы просто детализируете то, что ранее написали в уставе проекта).
Продолжая приведенный выше пример, в содержание проекта входит обучение пользователей, но не входят командировки проектной команды для обучения бухгалтеров в регионах или организация командировок этих бухгалтеров для обучения в Москве (об этом заказчику придется позаботиться самостоятельно).
Управление содержанием целесообразно еще и потому, что позволяет контролировать объем усилий и средств, направленных на получение результата. Что, если на выполнение проекта потрачено огромное количество ресурсов, усилий, времени – а результат, мягко говоря, того не стоит?
Хорошо написанное содержание проекта – одна из основополагающих успеха проекта и отличный инструмент коммуникации, который руководитель проекта должен уметь использовать во благо этого проекта.
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂
Управление интеграцией проекта. Управление содержанием проекта
Устав проекта
Устав проекта ( Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.
Исходными документами для разработки Устава проекта внедрения ИС являются контракт и результаты предпроектного обследования, определяющие содержание работ по проекту. Результаты предпроектного обследования оформляются в виде отчета, включая описание бизнес-процессов верхнего уровня.
Устав проекта содержит следующую информацию:
1. Название проекта.
2. Бизнес-цели компании или причины возникновения проекта.
Формулировка причины фактически дает ответ на вопрос » Зачем выполняется данный проект?».
Цели проекта определяют, что должно быть выполнено, и описывают конечный результат проекта. В Уставе проекта приводится цель проекта как результат, ожидаемый Заказчиком и полезный для него. Цель формулируется совместно Заказчиком и Исполнителем.
При формулировании цели руководитель проекта должен контролировать ее соответствие контракту, в рамках которого будут выполняться работы по проекту.
Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):
Результаты проекта должны соотноситься со спецификацией контракта, в рамках которого будут выполняться работы по проекту.
Примеры формулировок целей:
Границы проекта определяют в целом то, что включается в проект. Необходимо явно указывать, что не включается в проект (таблица 4.2), чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект.
Указываются территориально удаленные объекты, подлежащие автоматизации.
| Раздел функциональности | Процессы, не подлежащие реализации |
|---|---|
| Организационный менеджмент | Формирование фонда заработной платы по специфичным методикам. Система оповещения по функциям Управления персоналом в целом. Ведение аттестации рабочих мест, вредных условий труда |
| Администрирование персонала | Ведение параллельных данных на английском языке |
| Учет рабочего времени | Фактический учет рабочего времени (будет использоваться негативный учет). Учет рабочего времени по заказам/объектам. Учет работы во вредных условиях |
| Расчет зарплаты | Сдельная система оплаты труда |
5. Содержание проекта (задачи проекта).
Содержание проекта отвечает на вопрос «Какую конкретную работу нужно выполнить для достижения поставленных целей?» или «Какие задачи необходимо решить для достижения поставленных целей?». Содержание может быть получено от Заказчика в качестве составляющей тендерной документации.
Пример описания содержания (задач) проекта
Требования к бизнес-процессам должны включать:
Управление «расползанием» границ проекта: почему, когда и как
Требования меняются и расширяются в ходе любого проекта. Это естественный аспект разработки программного обеспечения. Менеджер проекта должен предвидеть и планировать это, например, путем включения буферов в планы на случай непредвиденных обстоятельств при взятии на себя обязательств. Расползание границ (от англ. «scope creep», также известное как расползание возможностей и расползание требований), однако, относится к неконтролируемому расширению возможностей, которые команда пытается запихнуть в уже переполненный проект. Все это не помещается.
Постоянное изменение и расширение требований затрудняет своевременную реализацию приоритетных функций. Постоянное расширение функциональности приводит к задержкам, проблемам с качеством и нерациональному использованию энергии. Расползание границ — одна из самых распространенных проблем в разработке программного обеспечения.
Определение границ
Первым шагом в борьбе с расползанием границ является документирование четко сформулированных и согласованных границ проекта. Без определения этих границ вы не сможете даже понять, что у вас наблюдается расползание границ. Техники, описанные в моей статье «Определение границ проекта», содержат несколько методов определения. Agile-проекты должны составлять краткое описание границ для каждой итерации, чтобы убедиться, что все понимают, что будет и что не будет реализовано в ходе данной итерации. В качестве альтернативы можно дать каждой итерации краткое название, передающее ее цель.
Шаблон документа «Видение и рамки», который я рекомендую, включает раздел «Ограничения и исключения». Здесь вы можете перечислить все возможности или характеристики продукта, которые заинтересованные лица могут ожидать, но которые заведомо не планируются к добавлению в продукт или в конкретный релиз. Можно также перечислить элементы, которые были исключены из границ проекта, чтобы не забыть о решении по данным рамкам. Подобное перечисление известных ограничений помогает команде быстро принимать решения, если поступает запрос на изменение какой-либо возможности, включенной в список исключений.
Входит ли это в рамки?
Вторым шагом в управлении расползанием границ является вопрос «Входит ли это в сами рамки?» всякий раз, когда кто-то предлагает какую-то дополнительную возможность продукта, например, вариант использования, пользовательскую историю, функциональное требование, функцию или результат обратите внимание, что рамки проекта могут охватывать деятельность и результаты помимо поставляемых программных продуктов. Возможно, ваши заказчики просят предоставить онлайн учебник, чтобы помочь своим пользователям освоить новую систему. Это не меняет сам программный продукт, но, безусловно, расширяет рамки общей работы по проекту, которую необходимо выполнить.
В одной из ситуаций клиент заключил контракт с поставщиком пакетного решения на перенос трех наборов архивных данных в новый пакет. В ходе выполнения проекта заказчик пришел к выводу, что необходимо выполнить еще шесть преобразований данных. Заказчик посчитал, что эта дополнительная работа входит в согласованный объем; поставщик утверждал, что она не входит в рамки проекта, и потребовал дополнительной оплаты.
Это был один из факторов, который привел к аннулированию проекта, судебному иску и консалтинговой задаче, в ходе которого я помог определить причину неудачи проекта. Более четкое определение границ объема работ на начальном этапе, а также соглашение о том, как и кем будут покрываться расходы, связанные с изменением границ проектных работ, могли бы предотвратить этот печальный исход.
Корректировка границ
Есть три возможных ответа на вопрос «Входит ли это в рамки проекта?». Если новая возможность явно входит в рамки проекта, то команде необходимо заняться этим вопросом. Если она явно выходит за рамки, команде не нужно с ней работать, по крайней мере, сейчас. Они могут запланировать новую функциональность на более поздний релиз или итерацию.
Иногда, однако, запрашиваемая функциональность выходит за рамки проекта в том виде, в котором она определена в настоящее время, но это настолько хорошая идея, что рамки должны быть расширены, чтобы вместить ее. Решение о расширении границ проекта — это бизнес-решение. Лица, принимающие ключевые решения, должны учитывать стоимость, риски, график и последствия для рынка. Это требует того, чтобы менеджер проекта, спонсор управления и ключевые клиенты проводили переговоры, чтобы определить, как лучше поступить с изменением границ проекта. Владелец бизнес-требований — спонсор управления — должен решить, станут ли предлагаемые изменения в пользовательских или функциональных требованиях ответственностью менеджера проекта в результате расширения границ (рис. 1).
Работа с расползанием границ
Ниже приведены некоторые возможные стратегии для преодоления неожиданного увеличения требований:
Отложить или исключить некоторые другие, менее приоритетные функциональные возможности, которые были запланированы в текущем релизе.
Нанять дополнительных сотрудников для выполнения дополнительной работы.
Получить дополнительное финансирование, возможно, для оплаты сверхурочных (ладно, это просто шутка), передать часть работы на аутсорсинг или приобрести инструменты, повышающие производительность.
Расширить график выпуска текущего релиза, чтобы учесть дополнительную функциональность (это не шутка).
Идти на компромисс с качеством, делая наспех работу, которую потом придется исправлять (не лучший вариант).
Расширение границ всегда имеет свою цену. Люди, финансирующие проект, должны принять взвешенное решение о том, какая стратегия управления рамками проекта является наиболее подходящей в каждой конкретной ситуации. Цель всегда состоит в том, чтобы обеспечить максимальную потребительскую ценность, согласованную с достижением определенных бизнес-целей и критериев успеха проекта, в рамках существующих ограничений.
Нет смысла притворяться, что команда проекта может реализовать все большее количество функциональных возможностей, не заплатив за это определенную цену. Кроме того, всегда разумно предвидеть определенный расширение границ работ в ходе проекта. Опытный руководитель проекта включит в проектные планы буферы на случай непредвиденных обстоятельств, чтобы команда могла в разумных пределах приспособиться к расширению границ, не нарушая при этом своих обязательств по графику.
Грамотное управление рамками проекта требует соблюдения нескольких условий:
Требования должны быть приоритетными, чтобы лица, принимающие решения, могли выбрать возможности для добавления в следующий релиз или итерацию и могли оценить запросы на изменения с учетом приоритетов требований в текущей базовой структуре. Это цель бэклога в agile-проекте (на самом деле, в любом проекте!).
Размер требований должен быть оценен для того, чтобы команда имела приблизительное представление о том, сколько усилий потребуется для их реализации. Для этого и нужны относительные единицы объема работы.
Команда должна знать свою среднюю производительность (скорость в agile-проекте), чтобы иметь представление о том, сколько требований, измеряемых в единицах размера, она может реализовать и проверить за единицу времени.
Запросы на изменения должны пройти анализ влияния изменений, чтобы команда хорошо понимала, сколько будет стоить реализация каждого из них и каковы будут последствия для проекта.
Необходимо определить лиц, принимающих решения по проекту, и определить процесс принятия ими решений, чтобы они могли эффективно принимать решения об изменении границ работ в случае необходимости.
Коммуникация — еще один важный элемент для управления scope creep. Вам необходимо обучить заинтересованные стороны, чтобы они понимали важность всех запросов на изменения через определенный (и эффективный!) процесс управления изменениями. Процесс управления изменениями — это не барьер, а скорее ворота, механизм, с помощью которого нужные люди могут принимать правильные решения для внедрения нужных изменений в нужное время. Сообщайте о решениях по утвержденным запросам на изменения всем соответствующим заинтересованным сторонам, чтобы они знали, как развивается проект и как это влияет на них.
Не становитесь жертвой расползания границ и не пытайтесь тщетно подавить изменения. Вместо этого четко определите рамки на ранней стадии проекта, а затем следуйте практическому процессу контроля изменений, чтобы справиться с неизбежной эволюцией требований. Дополнительные идеи о том, как справиться с этой вездесущей проблемой проекта, см. в статье «Как предотвратить и управлять расползанием границ проекта».
Изменения случаются: справляйтесь с ними.
Перевод материала подготовлен в рамках курса «Системный аналитик. Basic». Если интересно узнать подробнее о формате обучения и программе курса, регистрируйтесь на день открытых дверей онлайн.
Этап подготовки проекта в теории
В данной статье рассмотрены теоретические основы важнейшего этапа в управлении проектами – именно его подготовки. Это должно быть интересно как новичкам в таком непростом деле, как менеджмент проектов, так и начинающим стартаперам, и возможно, опытным менеджерам.
Что же такое проект?
Проект – одноразовая, неповторяющаяся деятельность или совокупность действий, в результате которых за определенное время достигаются четко поставленные цели.
В определенном смысле все проекты одинаковы. У всех есть потребитель (и) и \ или покровитель (и), которые ждут от реализации проекта достижения в определенное время результатов. Проекты часто реализуются с целью создания чего-то нового или осуществления больших изменений, которые можно рассматривать как завершенный вид деятельности. Проект может возникнуть исходя из новых запросов потребителей или пользователей услуг, либо из возможности получить выгоды для организации, либо на основании новых потребностей организации.
Не существует единственно «правильного» способа управления проектом. Традиционные подходы к управлению проектами сфокусированы на технических аспектах, и влиянию людей на реализацию проекта нередко уделяется меньше внимания. Однако именно люди заказывают и поддерживают проекты, поэтому лидерство, мотивация и управление вовлеченными в проект людьми так же важны, как и использование подходящих методов планирования, контроля и мониторинга.
Часто встречающиеся недостатки в реализации проектов:
На основании своих исследований Элбейк и Томас указали 10 факторов, которые многие определяют как критические для успеха проекта (расположены в соответствии с приоритетами):
Определение границ проекта
Проект начинается с идеи и возникает с целью удовлетворения потребностей человека. Идея состоит в том, чтобы сделать что-то, что кажется необходимым. Преобразование идеи в проект начинается с понимания природы потребности как движущей силы. Поэтому потребности являются основной движущей силой проекта.
Проблемы недостаточно точного определения потребностей:
Для того, чтобы понять масштабы проекта необходимо иметь следующую информацию:
ЗС и их потребности
В зависимости от особенностей проекта многие другие группы или отдельные люди могут быть заинтересованы в нем:
После того, как установлены основные ЗС, эту информацию необходимо использовать для того, чтобы обеспечить проекту максимально возможную поддержку. Обязательно нужно проверить, как реагируют на проект люди до того, как в процессе планирования будут исключены другие варианты его реализации. Если эту возможность использовать в полной мере, то команда проекта узнает о многих потенциальных препятствиях и будет хорошо информирована о приоритетах каждой группы. Один из способов понять реакции разных ЗС является анализ их точек зрения на каждое из ключевых измерений проекта – бюджет, время и качество.
Определение предназначения и целей проекта
Предназначение проекта является широким понятием и может быть соотнесено с миссией и ценностями организации, тогда как цели проекта определяют более точно, чего стремятся достичь, реализуя проект, и каким образом можно определить его успех.
Цели должны соответствовать критериям SMART:
Поставленные цели дают возможность определить шаги, с помощью которых может быть реализовано предназначение проекта и не позволить сбиться с правильного пути; использоваться для того, чтобы убедиться, что проект хорошо вписывается в деятельность организации.
Ясность целей важна для понимания того, что должно быть сделано. Если поставлены четкие цели, то это значит, что имеется определенная система взглядов на конечный результат. На основании поставленных целей происходит структурирование проекта с тем, чтобы его можно было эффективно контролировать и управлять им. Однако иногда возникает необходимость в пересмотре целей, поскольку в процессе осуществления проекта могут возникнуть новые обстоятельства, неизвестные на стадии планирования. Поэтому цели не должны быть «каменными».
Возможности и угрозы
Исследование возможностей и угроз на начальной стадии проекта может быть важным для определения его масштаба. Постоянные обсуждения с ЗС могут выявить многие потенциальные возможности и угрозы, связанные с проектом. Управление рисками (возможными угрозами проекту) будет рассмотрено ниже.
Проверка осуществимости проекта
Затраты и выгоды для оценки проекта
Риски и ситуационное планирование
Существует несколько способов выявления риска. Это в первую очередь обсуждение проекта с ЗС и рассмотрение различных перспектив, в ходе которых отдельные ЗС могут увидеть угрозы их интересам. Очень важно оценивать риск на каждом этапе реализации проекта и планировать возможные способы уменьшения его влияний. Там, где риск можно предвидеть, необходимо разработать ситуационный план, который можно применить, если ситуация риска реализуется.
Оценка риска и анализ влияния: ключевые вопросы
Основание для действий по проекту
Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта
VI Определяем функции системы и границы проекта
Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль
Дуглас Т. Росс
Когда основные потребности пользователей собраны и согласованы со всеми участниками, мы можем приступить к определению ключевых функций разрабатываемой системы, и уже на основании их примерно оценить стоимость и длительность проекта, направленного на создание конечного продукта. В результате этого процесса, как правило выясняется, что не хватает либо времени, либо ресурсов, либо и того и другого для получения качественного результата в предусмотренные сроки. В этом случае, нам очень пригодится умение эффективно определять Границы проекта и управлять ими.
Цель данной группы работ: максимально полно определить набор функций, который должен выполнять целевой продукт, для удовлетворения выявленных потребностей заказчика. Отобрать те из них, которые, могут быть реализованы в рамках текущего проекта.
Границы проекта (project scope) показывают, какая область конечного продукта будет реализована в текущем проекте. Другими словами, определяется черта между тем, что мы будем делать сейчас и тем, что отложим на потом или от чего вообще сможем отказаться. Для этого в арсенале команды должен быть инструмент, позволяющий не просто строить модели создаваемого продукта, а помогающий наглядно очертить рамки автоматизируемых процессов, а также предоставлять возможность легко выносить процессы за границу или включать их обратно. Это очень важно для осознания и более качественного планирования объемов работ. Подобный инструмент полезен не только для «борьбы» с непомерными желаниями заказчика, но и для маневров менеджмента со стороны разработчиков.
Для управления Границами проекта, как на начальных стадиях, так и в течение всего проекта, очень удобно использовать функциональное или процессное моделирование. Модели этого типа позволяют описывать события и последовательности исполнения Бизнес процессов во времени.
Иногда, для определения границ, группа разработчиков пытается использовать не функции, а сущности предметной области. Хочу предостеречь Вас от такого подхода, так как он чреват следующими последствиями:
Рисунок 6.1 — модель процесса определения функций
1. Используем нотацию IDEF0 для определения функций системы и границ проекта
Наиболее удобной методикой функционального моделирования, с точки зрения определения границ проекта, на мой взгляд является “старая добрая” методология проектирования SADT, использующая иерархическую декомпозицию сверху вниз. Применение диаграмм IDEF0 имеет следующие преимущества перед аналогами:
Таким образом, структура сложного процесса представляется в виде абстракции функций высокого уровня, которая раскладывается на более детальные процессы, увеличивая степень точности, слой за слоем.
Этот вид моделирования позволит нам также определить процессы, которые были выпущены из поля зрения на предыдущих этапах.
Если на этапе процессного моделирования будут обнаружены процессы, которые не описаны на стадии сбора информации, мы должны будем снова вернуться к этапу формирования Пользовательских историй и восполнить пробел. А теперь, чтобы все это нагромождение информации лучше улеглось в сознании, давайте рассмотрим конкретный пример.
2. Пример описания функции “Управление требованиями”
Хочу напомнить основные постулаты стандарта IDEFO. Графическую конструкцию стандарта составляют: понятие «Работа» (Activity) для обозначения действия, представленная в виде блока; четыре вида интерфейса: «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), представленный в виде дуг. Левая сторона блока предназначена для входов, верхняя — для управления, правая — для выходов, нижняя — для механизмов. Для более подробного изучения этой темы обратитесь к [2].
На первом шаге моделирования необходимо определить все потоки данных, поступающих в систему из вне (входные сигналы). В нашем случае это:
Рис.6.2 – Функциональная модель системы Управления требованиями верхнего уровня
Проваливаясь во внутрь функции (блока «Работа») мы попадаем на следующий уровень абстракции функциональности системы. Вначале мы видим только потоки данных, выявленные на предыдущем этапе (уровне), см. рис. 6.3.
Рис.6.3 – Начало работы по детализации функции Управление ИТ проектами
Для каждого такого потока необходимо определить процесс, обрабатывающий (преобразующий) или использующий его, добавляя на диаграмме новые блоки «Работ» (функции), связанные с ним.
Таким образом, при каждом последующем шаге (проваливаясь внутрь процесса) необходимо: каждому потоку данных, выявленному на предшествующем уровне, сопоставить функцию (процесс) для его обработки. В результате такого моделирования, мы получим перечень функций, детализирующих вышестоящий абстрактный процесс см. Рис. 6.3.
Рис.6.4 – Определение подпроцессов для функции Управление ИТ проектами
В нашем проекте, согласно изложенным в главе IV целям и выявленным на первом этапе потокам данных, необходимо автоматизировать следующую группу процессов:
Поскольку большинство процессов логически связаны между собой, необходимо установить все потоки данных, обеспечивающие эти связи. Таким образом от функции к функции на диаграмме появляются дуги. Позже, каждая такая дуга (связь), входящая в блок «Работы», должна будет, при моделировании следующего вложенного уровня, “получить” свой процесс обработки.
Пример модели этих функций с уже установленными взаимосвязями отображены на Диаграмме см. Рис. 6.5.
Рис.6.5 – Функциональная модель системы Управления требованиями
Если такие диаграммы используют в документе необходимо сопровождать их подробным описанием. Дальше приведен пример описания:
На рисунке видно, что функциональную архитектуру нашего проекта представлена в виде четырех доменов:
Из диаграммы видно, что блок “А1” имеет обратную связь от блока “А2”, в виде управляющей информации, доводящей о степени реализации требований, сформированных по Пользовательским историям (дуга «Отчет о реализации требований»). Эта связь позволяет отследить ход и полноту реализации Пользовательской истории в конечном продукте по цепочке, через спецификации требований.
Второй блок, как показано на схеме, получает на вход обработанные пожелания заказчика в виде Пользовательских историй, потребностей пользователей и т.п. уже в формализованном виде. На основании этих данных в нем формируются функциональные требования к разрабатываемому продукту и формализуются в виде спецификаций требований. Дальше эти спецификации передаются в четвертый блок “А4”, отвечающий за выставление задания исполнителям на их реализацию. Из диаграммы видно, что задания могут выставляться и на выполнение работ с требованиями (дуга «Задания», входящая в качестве управления в блок “А2”). Обратите внимание на то, что во второй функциональный блок возвращаются данные об исполнении заданий по спецификациям, что позволяет в этом домене определить приращение функциональности, полученное в ходе разработки.
В третий блок направим из блока “А2”, в качестве управляющих инструкций, ключевые показатели спецификаций. На основании их можно определить степень достижения заданной функциональности, используя отчет о выполнении задний, выставленных по этим спецификациям исполнителям. Отчет поступает в виде входящих параметров из блока “А4”.
Несмотря на все мои старания, этот раздел получился тяжелым и утомительным. Но для понимания концепции важно было разобраться, как это все работает. Далее, будем описывать вложенные функции уже не так подробно.
3. Пример описания функции “Сбор потребностей заказчика”
Продолжаем декомпозицию выявленных функций, раскладывая каждый домен на более мелкие, детальные функции. Для этого используем наши Пользовательские истории (речь о них шла в предыдущей части публикации). При их описании будем определять — насколько полно мы «покрываем» ими потребности заказчика.
Заглянем в блок А1 на рисунке 6.4, представляющий домен «Сбор потребностей заказчика». Его детализация показана на рисунке 6.5. Все потоки данных, которые входили в блок А1 на рисунке 6.4, соответственно попали и в детализирующую его диаграмму см. рис. 6.6.
Рис. 6.6 – Схема домена Сбор потребностей заказчика
Функционально домен мы разделили на четыре процесса:
4. Пример описания функции “Управления спецификациями требований”
Следующее уточнение произведем с доменом «Управление спецификациями требований проекта» (А2). На рисунке 6.7 изображена диаграмма этой модели.
Функционально домен делим на четыре процесса:
5. Пример описания функции “Управление заданиями”
На рисунке 6.8 изображена диаграмма, представляющая домен Управления Заданиями проекта (А4). Функционально домен мы разделили на четыре процесса:
При моделировании этого домена, у нас появились процессы, которым мы не можем сопоставить ни одну из Пользовательских историй. Поэтому восполним пробел. Для этого, мы должны вынести проблему на совместное обсуждение команды с заказчиками и сформировать новые Пользовательские истории.
Для процесса 5.2 опишем следующую Пользовательскую историю:
US12. На основании плана итераций проекта отобрать пул задач, которые необходимо реализовать на данном этапе.
Цель: Получить список задач для реализации в текущей итерации проекта.
Процесс 5.3 затрагивает несколько Пользовательских историй:
US13. Подготовить требования, которые необходимо будет реализовать, при наступлении прогнозируемого риска.
Цель: Выработать альтернативные решения для реализации потребности заказчика, при возникновении проблем.
В случае наступления риска, выполняется пользовательская история US8.
6. Пример описания функции “Управление выполнением”
На рисунке 6.9 изображена диаграмма, представляющая домен Управления выполнения проекта. Реализация этого домена немного выходит за рамки нашего проекта, но тесно с ним связана. Поэтому рассмотрим и его.
Рис. 6.9 – Схема домен Управления выполнения проекта
Функционально домен мы разделили на четыре процесса:
7. Подведем итоги процесса определения функций системы и границ проекта
Таким образом, в несколько проходов, слой за слоем уточняется и детализируется функциональная модель разрабатываемого продукта и определяются границы его контуров. В результате этой деятельности мы получаем подробную процессную модель, которую необходимо воплотить в жизнь. Как видно из диаграмм, помимо перечня автоматизируемых функций, также обозначены все информационные потоки, связывающие их.
Теперь если мы хотим вынести какую-либо функцию за рамки проекта или его этапа, мы можем проанализировать зависимости и избежать «провисания» остальных функций в линейке технологического процесса.
В итоге, опираясь на разработанные нами диаграммы, мы можем на первом этапе вынести за рамки проекта функции группы «А3 Управления выполнением», а также функции «А4.2 Формирование заданий на итерацию» и «А4.3 Формирование заданий при наступлении риска». Из диаграммы видно, что в результате система лишится потока данных — «задания исполнителям», обусловленных работами по нивелированию рисков.
Теперь, всякий раз, когда заказчик предлагает Вам включить в продукт новую функциональность, Вы должны сначала зафиксировать изменения на диаграмме Процессов (функций), определить степень изменений и их влияний для системы в целом.
В следующей части мы будем детализировать процессы, включенные в рамки системы ссылка
.