Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения, страница 31

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

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

рис. 8.5). Сознательные решения, принимаемые в конце каждой фазы с целью заблаговременного определения судьбы изделия в будущем, называются фазовым планированием. Эта процедура выполняется следующим образом.Сначала определяются фазы и основные события в концекаждой из них. Затем проводится формальный обзор на основе,по крайней мере, одного документа для каждого события.Таблица 8.2 — Документы обзоровФазаI.

ИсследованияII. Анализ осуществимостиIII. КонструированиеIV. ПрограммированиеОбзор основныхсобытийРесурсы распределеныТребования утвержденыСпецификацииутвержденыИспытания начатыРассматриваемые вопросы1. Распределение бюджета2. Извещение о календарныхсроках3. Соглашение о требованиях4. Спецификации5. Издание документации6. План испытаний7. План поддержки8. Отчеты9. План выпуска10. Конфигуратор1, 21, 2, 3, 9, 101, 2, 4, 5, 61, 2, 8205ФазаV.

ОценкаVI. ИспользованиеОбзор основныхсобытийРаспространениеначатоИзделие снятоРассматриваемые вопросы2, 8, 9, 1010Ключевые решения, которые должны основываться на результатах фазового обзора, будут ответами на следующие вопросы:Фаза I. Следует ли вкладывать ресурсы в продолжениеанализа осуществимости проекта?Фаза II. Обоснована ли реализуемость проекта и следуетли расходовать средства на проектирование?Фаза III.

Удовлетворяет ли проект потребностям пользователя в текущий момент времени и следует ли выделять средства для завершения работ?Фаза IV. Закончена ли разработка изделия и можно лиему дать объективную независимую оценку?Фаза V. Достаточно ли высоко качество программного изделия для его поставки пользователю?Фаза VI.

Можно ли прекратить обслуживание программного изделия?Администраторы планирования выступают в роли организаторов фазового обзора. Однако эту роль могут выполнять ипредставители различных конкурирующих групп.Независимо от того, кто проводит обзор, группа планирования обладает решающим голосом в фазовых обзорах I, II, V иVI.Перечень вопросов, подлежащих рассмотрению в каждомобзоре, строго стандартизирован: Строго ли выполняются планы? Строго ли соблюдаются все предварительные технические условия? Идет ли разработка проекта в соответствии с намеченным графиком? Не превышают ли расходы, связанные с проектированием, определенные статьи бюджета?206 Обеспечены ли все необходимые взаимодействия? Существуют ли какие-либо оправдания замеченнымнарушениям? Каков элемент случайности, присутствующий в пла-нах? В чем состоят основные трудности? Каковы возможные пути преодоления основных труд-ностей? С каким риском связано продолжение работ? С каким риском связано прекращение работ? Удовлетворяет ли программное изделие в его нынеш-нем виде текущим требованиям?Когда эти вопросы изучены, определяются, согласовываются и предпринимаются необходимые действия.

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

Механизм рассмотрения и утверждения должен обеспечивать возможность выявления расхо-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 Организация разработки программного изделияв фазе анализа осуществимостиАнализ осуществимости проводится одновременно всемифункциональными группами на основе изучения соглашения отребованиях. На этом этапе исследуется каждое предложениесоглашения о требованиях. Руководитель проекта поясняет изащищает свой сетевой график. В процессе обсуждения вносятся изменения в эти документы и вновь представляются наутверждение.