Фазовый обзор

Совокупность всех точек, в которых две функциональные группы взаимодействуют друг с другом, называется организационной границей. Конечно, функция может иметь один канал взаимодействия со всеми остальными функциями, однако более вероятно, что она будет иметь несколько границ соприкосновения, потому что характер взаимодействия с разными функциональными группами различен. Каждая такая граница должна быть вполне определенной, недвусмысленной и простой. Границы функций определяются всем множеством зафиксированных и незафиксированных планов, стратегий и процедур, которые определяют функциональные обязанности. Однако чем больше сведений фиксируется в письменном виде, тем лучше, так как это уменьшает двусмысленность. Основное свойство организационной границы состоит в разграничении ответственности (кто что делает, каким образом, для чего, с кем и для кого). Неполное определение, двусмысленность и сложность приводят к невозможности описания, а следовательно, и понимания природы взаимодействий. Существенным вкладом в управление взаимодействием являются контрольные комиссии (гл. 18). Путем проведения официальных обзоров результатов работ, выполненных в каждой фазе жизненного цикла (фазовых обзоров), как это предлагается делать в гл. 6, и на основе функционирования объединенных технических ревизионных комиссий  [c.52]


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

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

Независимо от того, кто проводит обзор, группа планирования обладает решающим голосом в фазовых обзорах I, II, V и VI.  [c.81]

Проведение фазовых обзоров существенно упрощается за счет использования стандартного механизма обсуждения. Так, фазовый обзор I может происходить на обычном или специальном заседании бюджетной комиссии. Фазовые обзоры II, V и VI могут проводиться объединенной комиссией (разд. 18.2). Фазовые обзоры II и VI происходят на регулярных заседаниях, проводимых по расписанию, и им предшествует необходимая подготовительная работа. Фазовый обзор V полезно проводить на специальном заседании, когда будет готов отчет об испытаниях класса В (разд. 10.8). Фазовый обзор III лучше всего поручить контрольной комиссии (как это описано в разд. 18.3) с последующим доведением выводов до сведения объединенной комиссии, принимающей окончательное  [c.83]


Таблица 6.3 Участие группы планирования в различных фазовых обзорах Таблица 6.3 Участие <a href="/info/64628">группы планирования</a> в различных фазовых обзорах
Фаза Фазовый обзор Форма участия при обсуждении документов  [c.83]

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

Некоторые из вопросов, поднимаемых в фазовых обзорах, относятся к сфере текущей интерпретации предварительных соглашений. Всякое несоответствие должно устраняться по ходу его обнаружения, будь то результат проверки или обновления более ранних документов. Следует помнить, что соглашение о требованиях всегда должно правильно отражать реальную ситуацию, а внешняя спецификация должна быть в любой момент времени законченным документом, который правильно описывает, что представляет собой программное изделие. Правильное конфигурационное управление требует также, чтобы каждая существующая в данный момент времени версия программного изделия имела свою собственную внешнюю спецификацию или четко изложенное описание в рамках внешней спецификации. Управление созданием программного изделия — своего рода игра, основанная на осуществлении контроля и сведении балансов группа планирования постоянно следит за расхождением между реальным положением дел, связанных с проектированием программного изделия, планами и спецификациями. Механизм рассмотрения и утверждения должен обеспечивать возможность выявления расхождений и последующего их устранения. Технические советы, объединенные комиссии и фазовые обзоры как раз и являются таким механизмом.  [c.85]


Роль группы планирования в фазовых обзорах в упрощенном виде отражена в табл. 6.3. На рис. 6.6 в терминах сетевого планирования (разд. 14.6) представлена деятельность группы планирования в период от начала фазы анализа осуществимости до окончания фазы оценки.  [c.85]

Затраты человеческого труда при реализации функции разработки отдельно взятого программного изделия обычно распределяются во времени так, как показано на рис. 7.3. Осуществление функции разработки начинается в фазе исследований с того момента времени, когда будет признана необходимость создания конкретного программного изделия. План —будь это план завоевания рынков сбыта, план выпуска серии программных изделий или план распределения бюджета — указывает срок, к которому возникнет необходимость в данном программном изделии. Первая задача, выполняемая в рамках функции разработки, состоит в том, чтобы определить, когда следует начать разработку изделия и соответственно инициировать начало проекта, чтобы обеспечить готовность программного изделия к тому времени, когда в нем возникнет необходимость. Функция разработки предусматривает согласование момента начала проектирования с возможностью выполнения других функций, чтобы гарантировать их своевременное обеспечение в процессе проектирования. В рамках функции разработки фиксируются предлагаемые сроки начала и завершения всех видов работ, среди которых выделяются основные этапы проектирования, и запрашиваются ресурсы, необходимые для анализа осуществимости проекта, — кадры, машинное время, командировки, фонды для проведения консультаций. Это достигается путем составления плана затрат, например имеющего вид плана бюджетных ассигнований, в котором указывается, кто несет ответственность за выполнение проекта в каждой функциональной группе здесь же предлагается кандидатура руководителя проекта в целом. Руководитель проекта или администратор изделия просит выполнить анализ результатов работы, достигнутых в фазе I (фазовый обзор I), ходатайствуя о соответствующем финансировании.  [c.99]

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

Для того чтобы принять твердое решение на основании результатов фазового обзора I, следует оценить не только стоимость, но и календарные сроки проектирования. Поэтому один из участ-  [c.99]

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

В зависимости от желания руководителя проекта может быть запланировано несколько неформальных процедур пересмотра плана, однако все они обязательно должны завершиться заключительным официальным его рассмотрением, называемым фазовым обзором II. Объединенная комиссия, состав которой обсуждается в разд. 18.2, является официальным органом, который удобен для проведения этой работы. В результате ее фиксируется согласие или несогласие каждой из функциональных групп с предложенным соглашением о требованиях. При благоприятном исходе руководителю проекта не придется добиваться утверждения соглашения о требованиях вопреки возражениям какой-либо функциональной группы. Если же такая ситуация возникает, он должен стараться заручиться согласием функциональных групп, отвергших соглашение о требованиях, продолжать работу над проектом, несмотря на высказанные возражения.  [c.103]

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

Участие группы разработки в фазовых обзорах.  [c.117]

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

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

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

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

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

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

Группа обслуживания, подобно другим группам, имеет право проверять и утверждать ряд важных документов, а также участвовать в некоторых фазовых обзорах.  [c.133]

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

В фазовом обзоре II группа обслуживания ведет переговоры о приобретении аппаратуры и других материалов для проведения испытаний класса С и распространения программного изделия. Она также рассматривает и планирует растущий объем услуг в конфигурационном управлении, защите прав собственности, ведении документации и управлении сопровождением. Итак, в фазовом обзоре II группа обслуживания участвует в обсуждении и утверждении документов.  [c.134]

Группа обслуживания не участвует в фазовом обзоре III, однако между фазами II и IV она рассматривает и утверждает план испытаний, а также спецификации испытаний, чтобы убедиться в соответствии этих документов требованиям испытаний класса С. Она также изучает и утверждает обязательства по обеспечению испытаний аппаратурой и другими средствами в соответствии с планом испытаний.  [c.134]

Группа обслуживания проверяет все извещения о календарных сроках и утверждает изменения планов, касающиеся обслуживания. В соответствии с типичным сетевым графиком, приведенным на рис. 8.1, в рамках функции обслуживания всегда держатся под контролем такие события, как Проектное оборудование установлено (О10) и Дата распространения изделия (О20). Группа обслуживания также рассматривает и утверждает во время обзора сетевого графика сроки других, менее значительных событий, таких, как Информационный листок выпуска готов к печати (ОН) и Информационный листок выпуска отпечатан (О12). В заключение в табл. 8.1 отражена роль группы обслуживания в фазовых обзорах.  [c.134]

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

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

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

Еще до начала фазового обзора I в группу выпуска документации поступает запрос о проведении предварительных оценок не-1 обходимых ресурсов, на основе которых производится распреде- ление бюджета. Как уже говорилось в разд. 9.3, для этих целей можно использовать стандартные расценки, а утверждение средств отложить до фазового обзора II, когда можно будет уточнить конкретные статьи расходов. Поэтому группа выпуска документации анализирует лишь окончательное распределение бюджета.  [c.148]

В ходе фазового обзора II эта группа пересматривает свои ис-  [c.148]

Таблица 9.2 Участие группы выпуска документации в фазовых обзорах Таблица 9.2 Участие <a href="/info/64624">группы выпуска документации</a> в фазовых обзорах
До фазового обзора III эта группа участвует в работе над внешней спецификацией изделия. Ко времени фазового обзора III она должна изучить внешнюю спецификацию, которая была представлена на утверждение группой разработки, и убедиться, что в ней правильно отражены интересы группы выпуска документации.  [c.149]

В фазовом обзоре IV все внимание участников проекта сосредоточено на передаче программ в распоряжение группы испытаний. Группа выпуска документации участвует в этом обзоре лишь в том случае, когда для составления материалов нужны дополнительные источники или если план выпуска документации нуждается в корректировке. В фазовом обзоре V группа выпуска документации участвует только в том случае, когда необходимы ее рекомендации относительно выпуска изделия с недоработками. При этом всестороннему обсуждению подвергаются все аргументы за и против соблюдения календарных сроков и оценивается ущерб, наносимый качеству программного изделия. В фазовом обзоре VI основное внимание сосредоточено на проблеме ослабления поддержки программного изделия или ее полной отмены. К этому времени изменения в документации настолько незначительны, что становятся частью деятельности группы сопровождения, и поэтому группа выпуска документации в фазовом обзоре VI не участвует,  [c.149]

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

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

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

Смотреть страницы где упоминается термин Фазовый обзор

: [c.53]    [c.85]    [c.101]    [c.134]   
Методы управления проектированием программного обеспечения (1981) -- [ c.81 ]