что такое граница проектирования

Управление «расползанием» границ проекта: почему, когда и как

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

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

Определение границ

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

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

Входит ли это в рамки?

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

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

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

Корректировка границ

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

Иногда, однако, запрашиваемая функциональность выходит за рамки проекта в том виде, в котором она определена в настоящее время, но это настолько хорошая идея, что рамки должны быть расширены, чтобы вместить ее. Решение о расширении границ проекта — это бизнес-решение. Лица, принимающие ключевые решения, должны учитывать стоимость, риски, график и последствия для рынка. Это требует того, чтобы менеджер проекта, спонсор управления и ключевые клиенты проводили переговоры, чтобы определить, как лучше поступить с изменением границ проекта. Владелец бизнес-требований — спонсор управления — должен решить, станут ли предлагаемые изменения в пользовательских или функциональных требованиях ответственностью менеджера проекта в результате расширения границ (рис. 1).

Работа с расползанием границ

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

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

Нанять дополнительных сотрудников для выполнения дополнительной работы.

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

Расширить график выпуска текущего релиза, чтобы учесть дополнительную функциональность (это не шутка).

Идти на компромисс с качеством, делая наспех работу, которую потом придется исправлять (не лучший вариант).

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

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

Грамотное управление рамками проекта требует соблюдения нескольких условий:

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

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

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

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

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

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

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

Изменения случаются: справляйтесь с ними.

Перевод материала подготовлен в рамках курса «Системный аналитик. Basic». Если интересно узнать подробнее о формате обучения и программе курса, регистрируйтесь на день открытых дверей онлайн.

Источник

Какой документ регламентирует границы проектирования разделов?

Подчёркиваю: меня не интересует т.н. «правда жизни» («возьмись да сделай, чо тут рассусоливать?»). Меня интересует этот законодательный нюанс.

Thượng Tá Quân Đội Nhân Dân Việt Nam

Изучайте внимательно ГОСТ 21.401-88 ТЕХНОЛОГИЯ ПРОИЗВОДСТВА. ОСНОВНЫЕ ТРЕБОВАНИЯ К РАБОЧИМ ЧЕРТЕЖАМ

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

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

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

ShaggyDoc, приветствую.
Спасибо за ответ. Но.
ГОСТ 21.401 говорит:
«4.4. На чертежах расположения указывают и обозначают:
— трубопроводы и их элементы, опоры трубопроводов и опорные конструкции под них; »
Т.е. речь идёт о _расположении_ опор и их конструктиве. Здесь не сказано, что технолог их разрабатывает. Я не прав?

Thượng Tá Quân Đội Nhân Dân Việt Nam

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

Разумеется в оформительских ГОСТ не говорится кто их разрабатывает = это тот, кто разрабатывает соответствующий основной комплект.

Сараи, эстакады, этажерки и прочий металлолом

Thượng Tá Quân Đội Nhân Dân Việt Nam

Например 5.900-7 Опорные конструкции (4 выпуска), А17В001 (периодически обновляющиеся). Опорные конструкции по этим сериям выбирает и «закладывает» технолог.

Сараи, эстакады, этажерки и прочий металлолом

Thượng Tá Quân Đội Nhân Dân Việt Nam

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

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

Именно это и разрабатывают технологи, а не КМ-щики. За это они и получают свои деньги. В других «специальных» ГОСТ также имеются ссылки на общий ГОСТ 21.114-95 ПРАВИЛА ВЫПОЛНЕНИЯ ЭСКИЗНЫХ ЧЕРТЕЖЕЙ ОБЩИХ ВИДОВ НЕТИПОВЫХ ИЗДЕЛИЙ.

Причем сами же ГОСТ предусмотрено, что

т.е. вообще без разработки деталировочных рабочих чертежей.

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

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

Сараи, эстакады, этажерки и прочий металлолом

ShaggyDoc, давно понял, что спорить с Вами бесполезно, правда в большинстве согласен в Вашими мыслями. Не знаю зачем ввязался.

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

Источник

Практика формирования требований в ИТ проектах от А до Я. Часть 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 Формирование заданий при наступлении риска». Из диаграммы видно, что в результате система лишится потока данных — «задания исполнителям», обусловленных работами по нивелированию рисков.

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

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

Источник