Если применение предлагаемых методов и средств начать с иерархической декомпозиции планов и проектов создания программных изделий, то легко удается реализовать и все остальные концепции. Основой хорошего структурирования разработок является генеральный план — соглашение о требованиях, в котором четко устанавливаются еще до начала проектирования стратегия и тактика создания изделия. В приложении приводится пример такого документа. [c.19]
Хорошее изделие может быть создано только на основании хорошего проекта, а для этого требуется хорошая документация, которая понятна разработчикам и удобна для использования в процессе проектирования. В том случае, когда проектные решения должны быть поняты большим числом людей, которые должны общаться между собой в ходе проектирования универсального программного обеспечения, качество проекта полностью определяется качеством положенной в его основу документации. Поэтому, чтобы успешно производить программные изделия, необходимо иметь полную документацию, охватывающую все аспекты их разработки. Вслед за принятием на вооружение соглашения о требованиях нужно позаботиться о том, чтобы спецификации изделия отражали потребности всех связанных с его созданием функциональных групп разработки, испытаний, выпуска документации и др. Обеспечить такое соответствие нетрудно, внедрив в практику проектирования программных изделий после соглашения о требованиях внешние спецификации, описываемые здесь достаточно подробно. [c.19]
Фаза программирования начинается уже в фазе конструирования, как только станут доступными основные спецификации на отдельные компоненты изделия, но не ранее утверждения соглашения о требованиях. Это перекрытие фаз программирования и конструирования приводит к экономии общего времени разработки, а также к обеспечению проверки правильности проектных решений [c.26]
Рассмотрение соглашения о требованиях Разработка [c.49]
Остановимся, наконец, а проблеме обучения. Принимая на работу людей любого уровня квалификации, следует обеспечить им возможность продвижения по службе в результате дополнительного профессионального обучения. По каждой выполняемой функции должен быть подготовлен семинар хотя бы на полдня, рассчитанный на слушателей с самым различным начальным уровнем знаний. Каждый такой семинар должен охватывать тематику, определяемую конкретной функцией так, как это изложено в части II данной книги, и обращать особое внимание на взаимодействие функций. Работу семинаров следует организовывать таким образом, чтобы на них рассматривались наиболее значительные или уникальные средства проектирования, подобные соглашению о требованиях. Необходимо внушить персоналу, что в семинаре должен участвовать каждый, независимо от исполняемых им функций и занимаемого положения. Для стимулирования заинтересованности в таких семинарах можно сделать участие в некоторых [c.59]
Окончательный план разработки изделия может быть выработан только в результате довольно серьезного изучения и обсуждения проблемы. Первая задача, которая обычно решается после распределения бюджета, состоит в формировании такого плана. Документ, в котором фиксируется план создания изделия, представляет собой технические условия, или соглашение о требованиях. В этом документе устанавливаются договорные отношения между разработчиком и пользователем, а также теми, кто должен заниматься продажей изделия. Помимо разработчика, который обычно готовит этот документ, в его составлении принимают участие многие функциональные подразделения, в том числе группы испытаний, выпуска документации, персонал, занятый внедрением, распространением, сопровождением, сбытом, обучением и поддержкой. Рассмотрение, утверждение и корректировка соглашения о требованиях являются, вероятно, наиболее важными моментами во всем процессе разработки именно благодаря соглашению о требованиях все заинтересованные стороны знают, какие ожидания можно связывать с создаваемым изделием что оно собой представляет, каковы его возможности и для чего оно нужно. Иными [c.72]
С началом фазы анализа осуществимости плановики и администраторы планирования в группе планирования обязаны помогать тем, кто выполняет этот анализ, отвечая на все возникающие вопросы, связанные с предыдущими планами или другими функциями. Результатом анализа является отчет, направляемый непосредственно в группу планирования и дающий четкие рекомендации. Если результаты анализа осуществимости проекта показывают, что изделие может быть создано, указанный отчет приобретает вид плана разработки (лучше всего, если это будет соглашение о требованиях), что гарантирует тщательность прогнозирования развития проекта и позволяет избежать дублирования усилий после одобрения плана. [c.76]
Всякий раз, когда это возможно, анализ осуществимости проекта должен выполняться той группой, которая в случае положительных результатов анализа будет нести ответственность за разработку изделия. В то время как другие типы отчетов могут быть написаны любой группой, соглашения о требованиях должны составляться предполагаемыми разработчиками, возможно, под руководством группы планирования. Это приводит к самому строгому из всех возможных подходов к выработке соглашения о требованиях, так как разработчик является в этом случае ответственным за выполнение своих собственных планов. [c.76]
Группа планирования всегда считается ответственной за обеспечение соответствия соглашения о требованиях тактическим и стратегическим планам и даже целевым программам организации. Это тем более справедливо, когда планы формируются группой, [c.76]
В некоторый момент времени после того, как ресурсы распределены (в начале фазы анализа осуществимости), но до утверждения соглашения о требованиях (конец фазы анализа осуществимости), новое программное изделие рассматривается с учетом будущих условий его использования. Для этого существуют два средства конфигуратор и план выпуска. В конфигураторе (табл. 6.1) перечисляются программные изделия, которые должны функционировать совместно с проектируемым изделием, а именно те, которые, во-первых, необходимы для его ввода в действие или его эксплуатации, во-вторых, сами зависят от него в период их установки или эксплуатации, в-третьих, могут работать параллельно с им и т. п. Конфигуратор — это план создания интерфейсов высокого уровня, определяющий связи и способствующий обеспечению взаимодействия функциональных групп, совместно разрабатывающих некоторое изделие. [c.77]
Как только группа планирования получает черновой вариант соглашения о требованиях, она может провести его стоимостный анализ, который, правда, выполняется только в том случае, если [c.77]
Последняя задача, выполняемая группой планирования в фазе анализа осуществимости, состоит в рассмотрении и утверждении соглашения о требованиях к программному изделию. Это самый важный момент в планировании, так как он устанавливает направление разработки и инициирует цепь событий, которые не контролируются группой планирования до тех пор, пока соблюдаются установленные соглашения о требованиях. Кроме всех прочих функций, группа планирования занимается также согласованием планов нижних уровней с планами выпуска совокупности и серии изделий, потому что никакая другая функциональная группа, кроме группы планирования, не заинтересована в таком согласовании. [c.79]
По окончании фазы исследований группа планирования первым делом рассматривает и утверждает планы организации поддержки для каждого изделия или совокупности изделий. В течение всей фазы конструирования группа выпуска документации и группа испытаний готовятся к рассмотрению плана изданий документов и плана испытаний. Группа планирования (обычно под руководством администратора планирования) анализирует эти планы главным образом на их соответствие предписываемым формам и совместимость с соглашением о требованиях, конфигуратором и планом выпуска программного изделия. В течение фазы программирования группа поддержки готовит свой план, а группа планирования рассматривает его в том же порядке, в каком до этого рассматривались план изданий и план испытаний. [c.79]
Следующий период в жизненном цикле программного изделия, имеющий отношение к группе планирования, связан с принятием решения о целесообразности широкого распространения изделия. Рекомендация дается группой испытаний, а если решение о выпуске принято без ее согласия, то группу испытаний просят дать заключение о степени готовности изделия. При этом группа планирования анализирует отчет группы испытаний и вновь выясняет у нее степень соблюдения соглашения о требованиях. Для принятия решения о распространении изделия всегда требуется согласие [c.79]
Р10 — П20 — анализ соглашения о требованиях, И01 — И10 — анализ плана испытаний, Б01 — Б10 — анализ плана выпуска документации, Д01 — Д10 — анализ плана поддержки, Д11 — Д12 — анализ рекламных материалов, И32 — ПЗО — анализ отчета об испытаниях класса В. [c.84]
Некоторые из вопросов, поднимаемых в фазовых обзорах, относятся к сфере текущей интерпретации предварительных соглашений. Всякое несоответствие должно устраняться по ходу его обнаружения, будь то результат проверки или обновления более ранних документов. Следует помнить, что соглашение о требованиях всегда должно правильно отражать реальную ситуацию, а внешняя спецификация должна быть в любой момент времени законченным документом, который правильно описывает, что представляет собой программное изделие. Правильное конфигурационное управление требует также, чтобы каждая существующая в данный момент времени версия программного изделия имела свою собственную внешнюю спецификацию или четко изложенное описание в рамках внешней спецификации. Управление созданием программного изделия — своего рода игра, основанная на осуществлении контроля и сведении балансов группа планирования постоянно следит за расхождением между реальным положением дел, связанных с проектированием программного изделия, планами и спецификациями. Механизм рассмотрения и утверждения должен обеспечивать возможность выявления расхождений и последующего их устранения. Технические советы, объединенные комиссии и фазовые обзоры как раз и являются таким механизмом. [c.85]
Руководитель проекта формирует многие из документов, описанных в этой книге, такие, как соглашения о требованиях, сводки трудозатрат, внешние спецификации, сетевые графики и уведомления о календарных сроках. Он анализирует и утверждает те из документов, которые создаются без его участия, например распределение бюджета, внутренние спецификации, описание конфигурации системы, планы выпуска документации, планы испытаний и поддержки. Он также проводит анализ отчетов о ходе проектирования, делает представления на сотрудников и часто осуществляет непосредственное управление проектом. [c.98]
Для проведения этой работы благоразумный руководитель запрашивает лишь самые необходимые ресурсы, чтобы завершить анализ осуществимости проекта программного изделия. Это удобно выполнить, выделив в распределении бюджета отдельную статью расходов на подготовку соглашения о требованиях. Такая мера предотвращает трату ресурсов, в которых нет необходимости во время фазы анализа осуществимости, и позволяет руководителю сохранить фонды на решение последующих задач проекта до начала фазового обзора II. К тому времени станут яснее объемы предстоящих работ, и поэтому можно будет принять правильное решение о целесообразности продолжения проекта. [c.99]
Если на основании фазового обзора I руководство разрешает начать анализ осуществимости проекта, выделяя для этого соответствующие ресурсы, то в рамках функции разработки предпринимается попытка составить соглашение о требованиях. Для выполнения этой задачи необходимо иметь достаточно полные резуль- [c.100]
Формальное составление соглашения о требованиях облегчается, если придерживаться формы, описанной в гл. 13 однако аналитическое исследование правильности утверждений, содержащихся в этом документе, требует большого опыта и размышлений. Требования должны быть выражены в ясной форме и не допускать противоречивого толкования. Следует иметь объективные критерии, позволяющие судить, действительно ли эта цель была достигнута. В соглашении о требованиях следует избегать пунктов, объясняющих, как надо решать поставленные задачи, чтобы оставить открытыми пути выбора технических решений на последующих этапах разработки. Рассматривая соглашение о требованиях, другие функциональные группы наложат более жесткие ограничения на эксплуатационные качества и другие характеристики программного изделия, и те, кто осуществляет функцию разработки, должны быть готовы принять эти ограничения или отвергнуть их, приведя веские причины. Для обоснования этих причин необходимо иметь результаты достаточно глубокого анализа. [c.101]
Соглашение о требованиях, как это следует из названия, представляет собой договор между руководителем проекта и заказчиком, который также включает субподряды, заключаемые между группой разработки и другими функциональными группами. Поэтому к его содержанию следует относиться со всей тщательностью и осторожностью, каких заслуживает заключение любого контракта, стараясь избегать как излишних обязательств, так и неопределенности формулировок. Договорный характер соглашения о требованиях следует подчеркивать, привязывая индивидуальные рабочие планы к конкретным положениям этого документа. И поскольку соглашение о требованиях связывает воедино усилия нескольких подразделений, его автору рекомендуется неформальным образом согласовать их деятельность с положениями этого документа, прежде чем передать его на рассмотрение кому бы то ни было, включая собственных сотрудников. Эта мера предотвратит столкновение противоречивых интересов участников проекта во время официального анализа результатов работы в той или иной фазе и тем самым ускорит процесс утверждения документа. [c.101]
Анализ осуществимости проекта проводится одновременно всеми функциональными группами на основе изучения соглашения о требованиях. На этом этапе тщательно исследуется каждое предложение, записанное в соглашении о требованиях. Руководитель проекта поясняет и защищает свой сетевой график. В процессе обсуждения соглашения о требованиях и сетевого графика он неоднократно вносит изменения в эти документы и вновь представляет их на утверждение. Время, затраченное на выработку соглашения о требованиях и приобретения уверенности в реальности плана его выполнения, с лихвой окупится на последующих этапах проектирования. [c.103]
В зависимости от желания руководителя проекта может быть запланировано несколько неформальных процедур пересмотра плана, однако все они обязательно должны завершиться заключительным официальным его рассмотрением, называемым фазовым обзором II. Объединенная комиссия, состав которой обсуждается в разд. 18.2, является официальным органом, который удобен для проведения этой работы. В результате ее фиксируется согласие или несогласие каждой из функциональных групп с предложенным соглашением о требованиях. При благоприятном исходе руководителю проекта не придется добиваться утверждения соглашения о требованиях вопреки возражениям какой-либо функциональной группы. Если же такая ситуация возникает, он должен стараться заручиться согласием функциональных групп, отвергших соглашение о требованиях, продолжать работу над проектом, несмотря на высказанные возражения. [c.103]
На рассмотрение, переработку и утверждение соглашения о требованиях может уйти немало времени. Хороший руководитель проекта совмещает эту деятельность с продолжением разработки в тех масштабах, которые позволяют ему имеющиеся ресурсы. Это совмещение следует поощрять, например, путем выделения средств на разработку спецификаций программного изделия в надежде на то, что соглашение о требованиях будет утверждено в первоначальном виде или претерпит лишь незначительные изменения, допустимые планом. [c.105]
Параллельно с процессом рассмотрения или даже, может быть, подготовки соглашения о требованиях в рамках функции разработки составляются индивидуальные рабочие планы (разд. 14.3) и сводка трудозатрат (разд. 14.4) для будущих участников разработки проекта. Эту работу надо проделать до того времени, когда в проект будут вложены значительные средства, и лучше всего ее проделать в то сравнительно свободное время, пока соглашение о требованиях находится на рассмотрении. [c.105]
Р10 — подготовка соглашения о требованиях Р10 — PJ1 — подготовка части внутреннего проекта для начала программирования Р10 — П20 — реакция на пересмотр соглашения о требованиях Р10 — Р20 — составление внешней спецификации И01 — И10 — рассмотрение плана испытаний Р20 — РЗО — реакция на пересмотр внешней спецификации Б01 — Б10 — рассмотрение плана выпуска документации Д01— Д10 — рассмотрение плана поддержки И11 — И13 — рассмотрение спецификации испытаний Р11 — Р31 — составление внутренней спецификации СЮ — Р40 — внесение последних обязательных изменений Р21 — Р40 — кодирование, отладка, компоновка Р40 — Р41 — подготовка и проведение демонстрации изделия в действии И20 — Р42 — прогон приемочных тестов Б02 — БП — рассмотрение чернового варианта справочных материалов Р40 — ИЗО — подготовка спецификации выпуска ДП — Д12 — рассмотрение рекламных материалов ИЗО — И31 — реакция на перечни дефектов БП — Б12 — рассмотрение первого варианта справочных материалов Б12 — Б20 — окончательное утверждение справочных материалов И32 — ПЗО — рассмотрение отчета об испытаниях класса В Р31 — П20 — рассмотрение спецификации сопровождения. [c.111]
Испытания класса В представляют собой независимую проверку программного изделия на соответствие спецификациям, в -частности соглашению о требованиях и внешним спецификациям. Программное изделие считается готовым к проведению испытаний класса В после успешного завершения приемочных испытаний. Группа разработки составляет отчет об испытаниях класса А, подытоживающий результаты этих испытаний, в том числе приемочных, и свидетельствующий о готовности программного изделия к испытаниям класса В. [c.114]
Группа разработки участвует в пяти из шести предусмотренных фазовых обзоров. В фазовом обзоре I эта группа дает первоначальную оценку стоимости проекта и составляет предварительный график проектирования. Она. рассматривает все представленные данные, утверждает календарные сроки, в особенности срок готовности соглашения о требованиях, а также распределение ресурсов. На этом этапе целесообразно планировать только те расходы, которые необходимы для доведения проекта до этапа утверждения соглашения о требованиях, что позволит избежать перерасхода средств, если этот документ еще не будет утвержден или если придется в значительной степени пересмотреть характеристика программного изделия. [c.117]
В фазовом обзоре II в центре внимания находится соглашение о требованиях. Группа разработки рассматривает технические требования, распределение бюджета, новый календарный план, а также некоторые элементы предварительного варианта конфигуратора и графика выпуска изделия. Она утверждает соглашение о требованиях, выделение дополнительных средств из распределе- [c.117]
В фазе исследований группа обслуживания занимается исключительно планированием своей работы на будущее. Дело в том, что пока не будет доказана осуществимость проекта, т. е. пока не будет утверждено соглашение о требованиях, группа обслужи- [c.121]
Р10 — П20 — анализ соглашения о требованиях И01 — И10 — анализ плана испытаний Р10 — ОЮ-закупка оборудования, необходимого для осуществления разработки И01 — И10 —закупка оборудования для проведения испытаний И11 — И13 — анализ плана поддержки ИЗО — ОН—подготовка информационного листка выпуска ОН — О12 —издание Информационного листка выпуска ОН — О20 — проведение испытаний класса С ПЗО — 020 -ч тиражирование, упаковка и распространение изделия. [c.123]
В конце фазы исследований руководитель проекта передает на рассмотрение составленное им соглашение о требованиях. Администратор планирования проверяет его на совместимость с существующими планами и передает руководителю проекта результаты своего анализа. Группа обслуживания также изучает соглашение о требованиях с точки зрения потребностей в обеспечении научно-исследовательских работ техническими и другими средствами. Средства, приобретение которых занимает большой период времени, заказываются заранее, однако фактическая закупка осуществляется только после утверждения соглашения о требованиях. [c.124]
Цели присутствуют в планах самых различных уровней в целевых планах, в бюджете, в планах выпуска изделий, документации и т. д. Каждый из этих планов рассматривается более подроб- о в том или ином разделе книги. Основной план для программно-то изделия — соглашение о требованиях — насыщен конкретными целями, которые могут и должны включаться в индивидуальные рабочие планы, служащие тем механизмом, посредством которого в системе целевого управления достигается договоренность между исполнителями и их руководителями. [c.56]
Достижение целей отчасти гарантируется включением общих целей создания изделия в индивидуальные рабочие планы и организацией текущего контроля за их достижением. Существуют такие средства, помогающие достичь цели путем управления по методу исключения. Как будет показано ниже, соглашение о требованиях, план поддержки, распределение бюджета и другие средства уста--навливают те границы, в пределах которых не требуется использование обратной связи однако при нарушении таких границ необходимы немедленные управляющие воздействия. Существуют три основных критерия оценки эффективности той или иной деятельности конкретные свойства, затрачиваемое время и стоимость. Каждый из этих критериев имеет определенные границы действия, по достижении которых обязательно представляется отчет руководству о результатах. Фазовые обзоры, рассматриваемые в гл. 6, предусматривают периодический анализ процесса создания программного изделия даже в том случае, когда заданная граница еще не достигнута. [c.56]
План выпуска изделия имеет то же назначение, что и конфигуратор, но он охватывает только такие элементы, которые должны быть готовы к определенному моменту времени. В табл. 6.1 приведен план выпуска операционной системы с виртуальной памятью (VSOS) к моменту утверждения соглашения о требованиях к программному изделию ASK. Поскольку выпуск системы ASK планировался в расчете именно на такие условия работы, плановики и разработчики этой системы использовали данный план выпуска как официальный документ. Группа поддержки из фирмы AB omputers также использовала его для подготовки рынков сбыта к предстоящему выпуску изделия. [c.77]
ПШ —распределение бюджета утверждено П20 — соглашение о требованиях утверждено ПЗО —изделие готово к распространению Р10 — соглашение о требованиях составлено Р11 — составление внутренних спецификаций начато Р20 — внешние спецификации составлены Р21-. кодирование начато РЗО — внешние спецификации утверждены Р31 — составление внутренних спецификаций завершено Р40 — начаты испытания класса А Р41—демонстрация изделия проведена Р42 — приемочные испытания проведены О10— требуемые по проекту средства установлены ОН — информационный листок выпуска готов к печати О12 — информационный листок выпуска издан О20 — изделие передано на распространение Б01 — план выпуска документации составлен Б02 — подготовка справочных материалов начата Б10 — план выпуска документации утвержден Б11 — техническое редактирование начато Б12 —утверждение справочных материалов начато Б20 — справочные материалы готовы к печати Б21 — справочные материалы изданы И01 — план испытаний составлен И10 — план испытаний утвержден И11—спецификации испытаний составлены- И12 — разработка контрольных примеров начата И13 — спецификации испытаний утверждены ИД) — состав приемочных испытаний определен ИЗО - начаты испытания класса В И31 - последний цикл испытаний начат И32 — отчет об испытаниях класса В издан Д01 — план поддержки составлен Д1С — план поддержки утвержден Д11 — рекламные интервалы подготовлены Д12 —рекламные материалы сданы в печать Д13 —план обучения издан Д20 — рекламные материалы распространены Д21 —учебные пособия подготов-лены ДЗО —обучение закончено С10 —внесение изменений запрещено С20 — спецификация сопровождения готова. [c.102]
Полученные в ходе фазового обзора II многочисленные предложения относительно внесения тех или иных изменений в соглашение о требованиях дают возможность взвесить достоинства и недостатки проекта.. Оценку удобно производить по трем переменным техническим характеристикам, календарным срокам и стоимости. Поэтому качество проекта полезна представить в трехмерном пространстве, где каждая из трех переменных откладывается вдоль ортогональных осей координат (рис. 7.5). Поскольку время и стоимость связаны простыми линейными зависимостями, их нетрудно отложить на соответствующих осях. Чтобы завершить картину, представим себе, что совокупность технических характеристик изделия можно измерить некоторой величиной, которая откладывается вдоль некоторой линейной шкалы. Теперь соглашение о требованиях можно представить в виде прямоугольного параллелепипеда с размерами, указывающими время, стоимость и совокупную оценку технических параметров, которые были заданы в соглашении о требованиях. Ко времени передачи последнего на утверждение внутри этого пространства характеристик проекта целесообразно выделить некоторый диапазон изменения переменных фактически это соответствует созданию небольшого запаса финансовых ресурсов, времени и свободы выбора параметров прог-раммнвго изделия. В результате появится возможность осуществлять модификации внутри пространства характеристики проекта [c.104]
Основная цель фазы конструирования заключается в выработке и анализе требований к программному изделию. Процесс декомпозиции проекта, начатый при составлении соглашения о требованиях, продолжается путем разбиения спецификаций а два компонента — внутренний и внешний. Внешний проект — это совокупность характеристик программного изделия, которые видит пользователь. Внутренний проект — это совокупность характеристик программного изделия, скрытых от любого пользователя. На первый взгляд это разделение кажется искусственным, однако это не так, поскольку такая классификация характеристик программного изделия дает много преимуществ. Она хорошо согласуется с рядом практических методов программирования, таких, как нисходящее программирование [14], метод утаивания информации (information hiding) [15], композиционное проектирование [16] и структурное проектирование 17]. С точки зрения руководителя несомненным достоинством такой классификации является то, что пользователи могут критически рассматривать те характеристики программного изделия, которые имеют к ним непосредственное отношение, не вдаваясь в критику внутренних характеристик изделия. Другими словами, можно во внешних спецификациях описать, что делает программное изделие, а во внутренних спецификациях указать, каким образом оно должно быть сконструировано. Внеш- [c.105]
Смотреть страницы где упоминается термин Соглашение о требованиях
: [c.18] [c.34] [c.73] [c.82] [c.89] [c.92] [c.96] [c.100] [c.101] [c.108] [c.109] [c.122]Смотреть главы в:
Методы управления проектированием программного обеспечения -> Соглашение о требованиях