Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (2007) (1095890), страница 31
Текст из файла (страница 31)
Набор этихдействий также стандартизован: Продолжение работ по плану. Пересмотр планов и спецификаций с последующимпродолжением работ согласно новым установкам. Ввод в действие планов в случае непредвиденных обстоятельств для обеспечения возможности возврата кисходным спецификациям, графикам работ и сметамзатрат. Прекращение работ.Проведение фазовых обзоров упрощается за счет использования стандартного обслуживания механизма обсуждения.Некоторые вопросы, поднимаемые в фазовых обзорах, относятся к сфере текущей интерпретации предварительных соглашений.
Всякое несоответствие должно устраняться по ходу его обнаружения. Следует помнить, что соглашение о требованияхвсегда должно правильно отражать реальную ситуацию, а спецификации должны быть в любой момент времени законченным документом, который правильно описывает, что представляет собой программное изделие.Управление программным изделием основано на осуществлении контроля и сведении балансов: группа планированияпостоянно следит за расхождением между реальным положением дел, связанных с проектированием программного изделия,планами и спецификациями.
Механизм рассмотрения и утверждения должен обеспечивать возможность выявления расхо-207ждений и последующее их устранение. Технические советы,объединенные комиссии и фазовые обзоры как раз и являютсятаким механизмом.8.3 Организация разработки программногоизделияПод управлением проектом мы будем понимать управление достижением требований, предъявляемых к программномуизделию на основании использования матричной структурысвязи функций и проектов. В этой матрице каждой функции соответствует группа руководителей, несущих ответственность заее выполнение наилучшим образом, каждому программному изделию соответствует, в свою очередь, группа руководителей,внимание которых сосредоточено только на данном программном изделии (рис. 8.6).Администратор проекта (руководитель) занят однимединственным проектом, каждая функция которого охватываетнесколько индивидуальных разработок.Администратор изделия регулирует степень участия каждой функциональной группы в разработке программного изделия, успешность которой определяется, прежде всего, степеньюсоблюдения ранее установленных технических требований ицелей, допустимых границ затрат.
Обычно он начинает выполнять свою роль, начиная с фазы анализа осуществимости и доокончания фазы оценки. Администратор — это, обычно, сотрудник подразделения разработки, хорошо понимающий работы, выполняемые другими людьми и подразделениями (частобывает, что он несет ответственность за все, не имея полномочий).208ВыпускдокументацииИспытанияСопровождениеИндивидуальныйпроект 1Индивидуальныйпроект 1Индивидуальныйпроект 1Индивидуальныйпроект 1Индивидуальныйпроект 1Индивидуальныйпроект 2Индивидуальныйпроект 2Индивидуальныйпроект 2Индивидуальныйпроект 2Индивидуальныйпроект 2Индивидуальныйпроект 3Индивидуальныйпроект 3Индивидуальныйпроект 3Индивидуальныйпроект 3Индивидуальныйпроект 3Администратор 2ОбслуживаниеАдминистратор 3РазработчикиАдминистратор 1ОбщееруководствоРис.
8.6 — Схема матричного управления проектомВ матричной структуре каждый разработчик имеет двухначальников. Однако именно матричная структура наиболее эффективна для управления такими непредсказуемыми процессами, как разработка программ.8.3.1 Организация разработки программного изделияв фазе исследованийЗатраты труда при реализации функций разработкиотдельного программного изделия, согласно кривой Релея, имеют максимальное значение в фазах проектирования и программирования. Осуществление функций разработки начинается вфазе исследований с того момента, когда будет признана необходимость создания конкретного программного изделия. В этомслучае план — это план завоевания рынков сбыта, план выпуска серии программных изделий и бюджет.
Основной параметрэтих планов — срок, к которому возникает необходимость вданном программном изделии. Первая задача, выполняемая в209рамках разработки, состоит в том, чтобы определить, когда следует начать разработку изделия, чтобы обеспечить его готовность к моменту, когда в нем возникнет необходимость. Функция разработки предусматривает согласование момента началапроектирования с возможностью выполнения других функций,чтобы гарантировать их совместное обеспечение в процессепроектирования. В рамках функции разработки фиксируютсяпредлагаемые сроки начала и завершения всех видов работ, среди которых выделяют основные этапы проектирования, и запрашиваются ресурсы, необходимые для анализа осуществимостипроекта, — кадры, машинное время, командировки, фонды дляпроведения консультаций. Это достигается путем составлениясметы затрат, в которой обязательно указывается, кто несет ответственность за выполнение проекта в каждой функциональной группе, здесь же предлагается кандидатура руководителяпроекта в целом.
Руководитель проекта (администратор) даетуказание выполнить анализ результатов работ, выполненных вфазе I (фазовый обзор), и ходатайствует о соответствующем финансировании. Обычно администратор ограничивается выделением средств на работы, связанные с составлением соглашенияо требованиях. Такая мера ограничит трату ресурсов, в которыхнет необходимости во время фазы анализа осуществимости.Для правильного принятия решения на основе результатов фазы I оценивается не только стоимость, но и календарныесроки проектирования. Поэтому один из участников проекта,ответственный за подготовку соглашения о требованиях, представляет формально законченный план — график работ. Этотпервоначальный вариант плана должен обязательно фиксировать точный срок представления соглашения о требованиях ипредполагаемый срок окончания разработки программного изделия.Если на основании фазового обзора I руководство разрешает начать анализ осуществимости, выделяя для этого соответствующие ресурсы, то предпринимается попытка составитьсоглашение о требованиях.
Формальное составление соглашения о требованиях облегчается, если придерживаться строгоформализованной формы. Требования должны быть выраженыв ясной форме и не допускать противоречивых толкований. Всоглашениях о требованиях следует избегать пунктов, объясня-210ющих, как надо решать поставленную задачу. Рассматривая соглашения о требованиях, функциональные группы обычно накладывают жесткие ограничения на эксплуатационные качества идругие характеристики программного изделия. Для обоснованияэтих ограничений (принять или нет) обязательно должен бытьпроведен достаточно глубокий анализ осуществимости.Соглашение о требованиях — это договор между руководителем проекта и заказчиком, который также включает субподряды, заключенные между группой разработки и другимифункциональными группами. Договорный характер соглашенияо требованиях подчеркивается тем, что привязываются индивидуальные рабочие планы к конкретным положениям данногодокумента.
И так как соглашение о требованиях связывает воедино усилия многих подразделений, его необходимо согласовывать на всех уровнях (вплоть до конкретного исполнителя).На базе соглашения о требованиях составляется общийплан для всего проекта. В нем указываются взаимодействиямежду функциональными группами и вклад каждой из них впроект, а также очерчиваются границы обязанностей каждойгруппы. В этом плане также дается основа описания всех задач,решаемых группой разработки.
Обычно этот план составляетсяв виде сетевого графика.8.3.2 Организация разработки программного изделияв фазе анализа осуществимостиАнализ осуществимости проводится одновременно всемифункциональными группами на основе изучения соглашения отребованиях. На этом этапе исследуется каждое предложениесоглашения о требованиях. Руководитель проекта поясняет изащищает свой сетевой график.
В процессе обсуждения вносятся изменения в эти документы и вновь представляются наутверждение. Может быть предусмотрено несколько неформальных процедур пересмотра плана, однако все они должныбыть успешно закончены официальным рассмотрением — фазовым обзором II. В результате фиксируется согласие или несогласие каждой функциональной группы с предложениями соглашения о требованиях.211Полученные в ходе фазового обзора II предложения относительно внесения изменений в соглашение о требованиях даютвозможность оценить недостатки проекта. Оценку проводят потрем переменным: технические характеристики, календарныесроки и стоимость (рис. 8.7).СсSсFсРис. 8.7 — Границы изменяемости проекта:Cc — увеличение стоимости; Sc — изменение времени;Fc — изменение технических характеристикТо есть внутри проекта выделяется некоторый диапазонизменения переменных; фактически это соответствует заданиюнебольшого запаса финансовых ресурсов, времени и свободывыбора технических характеристик системы.На рассмотрение, переработку и утверждение соглашенияо требованиях может уйти много времени, поэтому обычно этаработа совмещается с продолжением разработки в тех масштабах, которые позволяют ресурсы.Параллельно с процессом рассмотрения соглашения отребованиях составляются индивидуальные рабочие планы исводка трудозатрат, которые будут основой для определениябудущих финансовых затрат.2128.3.3 Организация разработки программного изделияв фазе конструирования (проектирования)Основная цель проектирования заключается в выработкеи анализе требований к программному изделию.
Процесс декомпозиции проекта, начатый при составлении соглашения отребованиях, продолжается путем разработки спецификаций иразбивки их на две части — внутренний и внешний проект.Внешний проект — это совокупность характеристик программного изделия, которые видит пользователь. Внутренний проект —совокупность характеристик программного изделия, скрытых отпользователя.
Это делается, в первую очередь, для того, чтобыпользователи могли критически рассматривать те характеристики программного изделия, которые имеют к ним непосредственное отношение, не вдаваясь в критику внутренних характеристик изделия. То есть внешний проект описывает, что делаетпрограммное изделие, а внутренние спецификации указывают,каким образом изделие сконструировано для достижения внешних спецификаций. Внешние спецификации передаются дляоткрытого и широкого обсуждения, в котором предпочтенияотдаются предложениям пользователей.Для того чтобы провести границу между внутренним ивнешним проектом, схему декомпозиции упорядочивают. Схема декомпозиции называется хорошо упорядоченной, если наней отмечен каждый случай вызова одной функции другой,вплоть до некоторого уровня абстракции, удобного с точки зрения управления проектом.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
