Декомпозиция проекта

Помимо декомпозиции проекта, необходимо определить работы и процессы,  [c.22]

Декомпозиция представляет собой творческий процесс и может быть выполнена на основании состава фаз проекта, структуры продукта проекта, состава выполняемых работ и т. д. На практике часто удачную декомпозицию проекта можно получить, сочетая разные принципы декомпозиции (например, структура продукта в сочетании с характерными фазами проекта).  [c.212]


Проверить корректность декомпозиции проекта при помощи анализа ответов на следующие вопросы.  [c.212]

В чем состоит суть структуризации (декомпозиции) проекта  [c.63]

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

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


Наконец, при организации разработки программного изделия следует учесть еще один инструмент, хорошо вписывающийся в индивидуальные рабочие планы, — использование стандартов. Каждый, кто занимался программированием, по достоинству оценивает пользу стандартизации в кодировании и документировании программ. В равной мере важны стандарты управления, помогающие проводить планирование, анализ результатов и оценку эффективности осуществляемых проектов. Для того чтобы иметь возможность проверять полноту планирования и проводить декомпозицию проекта на любом этапе, необходимы системные и процедурные руководства, описывающие как методику проведения разработки, так и методики выполнения связанных друг с другом функций поддержки, выпуска документации и испытаний.  [c.89]

Концепция бригады главного программиста хорошо вписывается в методологию, излагаемую в данной книге. Библиотека поддержки разработки является хорошей иллюстрацией методов конфигурационного управления на уровне проекта. Структурное программирование удовлетворяет многим требованиям методологии проектирования, которые упоминаются в этой книге. Нисходящее проектирование, называемое также программированием сверху вниз, является фактически постепенной детализацией описаний функциональной структуры на уровнях более простых функций до тех пор, пока, наконец, не будет достигнут уровень собственно операторов языка программирования [14]. В ходе этого процесса фактически осуществляется декомпозиция проекта, описанная в предыдущей главе. Как заметил Бейкер [39], один из недостатков работы бригад главного программиста заключается в отсутствии подробных описаний функциональной структуры, которые отражали бы все внешние аспекты системы, не затрагивая внутренней структуры проекта. Ясно, что речь здесь идет о внешних спецификациях, рассмотренных в гл. 2. Бригада главного программиста, в составе которой предусмотрена должность руководителя проек-  [c.91]


Рис. 7.6. Функциональная декомпозиция проекта. Рис. 7.6. <a href="/info/64776">Функциональная декомпозиция</a> проекта.
Деятельность группы поддержки достигает первого максимума после передачи плана поддержки на рассмотрение в другие группы (рис. 11.2). Как видно из рис. 11.3, группа поддержки одновременно занята подготовкой рекламного материала, проверкой внешних спецификаций и изучением плана выпуска документов. В этот период важно установить определенную приоритетность работ, чтобы уложиться в запланированные сроки. Лучше всего выполнять их по очереди, однако это может значительно увеличить время проектирования. Хотя календарные планы отдельных проектов в чем-то отличаются друг от друга, группа поддержки всегда стремится выполнять свои работы в следующем порядке , сначала изучить внешние спецификации, затем проверить план выпуска документов, отреагировать на замечания к плану поддержки и, наконец, подготовить рекламный материал. Эта очередность работ наилучшим образом соответствует хорошему стилю планирования и требованиям декомпозиции проекта.  [c.183]

В соответствии с формой, представленной в предыдущем разделе, ниже дается описание информации, которая должна присутствовать в любом соглашении о требованиях. Все последующие упоминания о соглашении о требованиях (СТ) имеют в виду соглашение о требованиях, разработанное в соответствии с данным разделом. Описываемый подход предполагает также декомпозицию проекта в соответствии с табл. 13.2 и дальнейшую детализацию, отражаемую во внешней спецификации изделия согласно разд. 15.1. Материал, следующий вплоть до заголовка Календарный план , пронумерован, озаглавлен и напечатан так же, как в СТ, но с одним исключением обозначения Ок, Ч, Об и 3 указывают уровень детализации.  [c.206]

Документы, целью которых является точная формулировка или определение каких-либо условий, называются спецификациями. Желательно, чтобы спецификации были удобочитаемыми и краткими, но прежде всего они должны быть точными и исчерпывающими. Двусмысленность в спецификациях более нетерпима, чем в планах. В процессе декомпозиции проекта, который для программного изделия начинается с иерархии планов, продолжается в соглашении о требованиях, внешней спецификации, внутренней спецификации и заканчивается спецификацией сопровождения, неопределенность постепенно уступает место полной определенности.  [c.267]

Как отмечалось в гл. 13, выбор заголовков, которые включаются в документ, и их последовательность не произвольны. Представленные в этой главе форматы составлены в соответствии с принципом проектирования сверху вниз, т. е. наиболее важные вопросы помещаются первыми незначительные исключения составляют те случаи, где обеспечение удобства чтения текста важнее сохранения реальной схемы декомпозиции проекта. В представленных форматах используется способ нумерации, позволяющий реализовать вложенную структуру документов, удобную с точки зрения возможности дополнения и исключения отдельных разделов. Например, в гл. 13 в табл. 13.2 приведено оглавление подобной структуры для соглашения о требованиях (СТ), внешней спецификации (ВшС), внутренней спецификации (ВтС) и спецификации сопровождения (СС). Элементы каждого такого документа обозначаются следующим образом 3 — заголовок, Об— общая формулировка, Ч — частичная формулировка, Ок — окончательная формулировка. Преобразование 3->-Об->-Ч->Ок, направленное в одну сторону, осуществляется в процессе принятия проектных решений.  [c.268]

Для всех разделов и подразделов следует приводить схему иерархии, которая является своего рода указателем подразделов. Удобна, например, древовидная или вложенная структура, подобная представленной ниже. Каждый подраздел п должен посвящаться какой-либо одной функциональной возможности. Функции целесообразно организовывать в модули, соответствующие физическим модулям в ВтС, чтобы процесс декомпозиции проекта в ВтС мог быть продолжен в разд. 15.2. Однако в процессе декомпозиции не должны упускаться из виду требования организации ВшС в соответствии с логическими функциями. При этом после составления ВтС нетрудно будет преобразовать логические модули в физические. Пример показан на рис. 15.1.  [c.273]

При составлении СОР вы можете столкнуться с тем, что достижения должны быть определены подробнее. В процессе декомпозиции проекта вы можете обнаружить новые достижения, которые пропустили в процессе планирования сферы действия проекта. Эти дополнения должны быть внесены в документ, определяющий сферу действий проекта. Корректировка сферы действия проекта является результатом процесса определения сферы действия, который и позволяет вам осуществить это.  [c.168]

Процесс определения сферы действия связан с декомпозицией проекта и созданием СОР. Достижения разбиваются на управляемые части работы, которые могут быть разделены в дальнейшем на действия.  [c.171]

Структура декомпозиции проекта (PBS) - в общем случае то же, что и правильно составленная WBS. Термин PBS широко применяется там, где термин WBS ошибочно используется для обозначения списка материалов (ВОМ).  [c.62]

На основе исходной информации о проекте проводится последовательная декомпозиция (разбиение, деление на категории, классификация) по заданным основаниям (признакам, критериям) работ проекта. Для наглядности и простоты использования декомпозиции каждому элементу присваивается уникальный идентификатор, соответствующий уровню с использованием разделителей типа табуляции, знаков препинания и т. д.  [c.370]

Структурная схема комплекса является описанием структуры, необходимой для выполнения декомпозиции. Состав и порядок реализации элементных проектов- определяется формой структурной схемы комплексного инвестиционного проекта, создаваемой для  [c.370]

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

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

Для инновационных продуктов поиск близких или полных аналогов (законченных продуктов с определенным набором свойств) может быть затруднителен. В таком случае необходимо найти информацию о нескольких аналогах, свойства которых охватывают отдельные группы характеристик инновационного продукта, и также сравнить по вышеописанной методике (усреднив также цену) предложения всех выявленных аналогов. Если не выявлены товары - конкуренты, имеющие полностью или частично аналогичные потребительские характеристики, то возможно сравнить продукты по принципу функционального замещения, иными словами ведется поиск товаров с подобной функциональной потребительской применимостью. Ограниченность приведенной методики функциональной декомпозиции заключается в невозможности ее использования в случае, если не найдено даже функциональных аналогов. В этом случае речь может идти или об отсутствии маркетинговой проработки рынка, или о прорывном инновационном результате, для оценки инвестиционной привлекательности которого необходима экспертная оценка проекта как целого с точки зрения соответствия его результатов уровню научно-технического прогресса и сформированное потребности рынка. В этом случае для предварительных оценок можно пользоваться методикой сравнения с идеальным продуктом (табл. 4.2).  [c.26]

При разработке проекта используются методы структурной декомпозиции  [c.20]

Декомпозиция целей — декомпозиция этапов проекта на более мелкие  [c.25]

Структура декомпозиции работ проекта - способ описания целей и задач  [c.182]

Управление проектами базируется на системном подходе к процессу управления, что дает возможность декомпозиции и структуризации управления реализацией проекта любой сложности при его рассмотрении. Системно-ориентированная модель управления реализацией стратегических изменений в деятельности предприятия позволяет представить его как процесс реализации определенных связей между всеми элементами проекта, обеспечивающими достижение поставленных целей.  [c.291]

Стадия детального проектирования ИС связана с декомпозицией крупноблочной структуры системы на компоненты и выбором готовых компонентов (прикладных программ повторного использования, покупных программных и технических средств среды). При выборе и заказе готовых компонентов применяются функциональные профили ИС, полученные на предыдущих стадиях проекта. Применение функциональных профилей в этих случаях заключается в том, чтобы предъявить к используемым компонентам требования их соответствия стандартам применяемого профиля и формировать требования к тестам, проверяющим это соответствие.  [c.81]

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

Выполняется декомпозиция целей проекта в виде упомянутой иерархической структуры работ. Элементы ИСР нижнего уровня рассматривают как пакеты работ. В общем случае можно рекомендовать наиболее характерную последовательность декомпозиции целей проекта  [c.212]

Структура разбиения (декомпозиции) работ (WBS — Work Breakdown Stru ture) — иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня, пакеты детальных работ. СРР является базовым средством для создания системы управления проектом, так как позволяет решать проблемы организации работ, распределения ответственности, оценки стоимости, создания системы отчетности, эффективно поддерживать процедуры сбора информации о выполнении работ и отображать результаты в информационной управленческой системе для обобщения графиков работ, стоимости, ресурсов и дат завершения.  [c.355]

Некоторые формы иерархической декомпозиции, с которыми мы встретимся, представляют собой нисходящее управление (гл. 5), декомпозицию планов (гл. 6), декомпозицию проекта (гл. 7) и структурирование планов выпуска и спецификаций изделий (частично гл. 13 и разд. 15.1—15.3). Вероятно, многие знакомы с такими видами формальной иерархической декомпозиции, как поэтапная обработка [11], уровни абстракции [12], иерархия документации [13], нисходящее программирование [14], модульная декомпозиция [15], композиционное [16] и структурное [17] проектирование. Александер [18] предлагает весьма интересное представление декомпозиции. В небольшой, но очень полезной книге он проводит философское обсуждение процессов анализа и синтеза конструкций, за которым следует математический метод разложения множества ограничений на подмножества, приводящий к минимизации их взаимодействия. Его работы и работы Бёма [19], Хоара [20], Милза [21], а также некоторые пока еще не опубликованные работы представляют собой значитёлньый вклад в проектирование программного обеспечения благодаря введению количественной меры оценки этого процесса и средствам доказательства правильности программ.  [c.31]

Основная цель фазы конструирования заключается в выработке и анализе требований к программному изделию. Процесс декомпозиции проекта, начатый при составлении соглашения о требованиях, продолжается путем разбиения спецификаций а два компонента — внутренний и внешний. Внешний проект — это совокупность характеристик программного изделия, которые видит пользователь. Внутренний проект — это совокупность характеристик программного изделия, скрытых от любого пользователя. На первый взгляд это разделение кажется искусственным, однако это не так, поскольку такая классификация характеристик программного изделия дает много преимуществ. Она хорошо согласуется с рядом практических методов программирования, таких, как нисходящее программирование [14], метод утаивания информации (information hiding) [15], композиционное проектирование [16] и структурное проектирование 17]. С точки зрения руководителя несомненным достоинством такой классификации является то, что пользователи могут критически рассматривать те характеристики программного изделия, которые имеют к ним непосредственное отношение, не вдаваясь в критику внутренних характеристик изделия. Другими словами, можно во внешних спецификациях описать, что делает программное изделие, а во внутренних спецификациях указать, каким образом оно должно быть сконструировано. Внеш-  [c.105]

Структура проекта, создаваемая на основе декомпозиции, позволяет оптимизировать процедуры сбора и обработки информации о ходе выполнения работ по проекту в соответствии с уровнями управления, видами элементных проектов, обобщать информацию по графикам потоков денежных средств и производственных ресурсов. ASE-технологии повышают эффективность проведения структурного анализа при комплексном инвестиционном проектировании.  [c.371]

Решения подобных проблем выходят за рамки экономической целесообразности и требуют умения воздействовать на общественное мнение или учитывать политические издержки осуществления проектов, разрабатываемых муниципальными организациями. Их успешное решение во многом определяется опытом руководства, интуицией и гибким реагированием на изменения общественного мнения. Задача же аналитических методов, подобных АЗВ, состоит в том, чтобы представить сложную проблему, требующую стратегического выбора, в виде совокупности субпроблем (декомпозиция), одни из которых имеют достаточно простое аналитическое решение, другие требуют развития системы взаимодействия муниципальной организации с внешней средой.  [c.289]

Декомпозиция работ [Work Breakdown Stru ture (WBS)] — механизм разбиения рабочего процесса (в общем случае связанного с определенным проектом) на меньшие элементы, которые могут использоваться для назначения ресурсов, бюджета, расписаний и т.д. WBS обеспечивает базис управления проектом.  [c.310]

В справочной системе локализованных версий Proje t 2002 используется термин "структурная декомпозиция работ", что позволило образовать аббревиатуру СДР. Но значительная часть отечественных специалистов по управлению проектами вместо него используют термин "иерархическая разбивка работ" или "иерархическая структура работ". Автор не считает возможным нарушить эту традицию.  [c.105]

Методы управления проектированием программного обеспечения (1981) -- [ c.87 , c.107 ]