Файл: Технология раработки програмного обеспечения УП.pdf

206 

Фаза

Обзор

основных

событий

Рассматриваемые

вопросы

III.

Конструиро

-

вание

IV.

Программи-

рование

V.

Оценка

VI.

Использова-

ние

верждены

Спецификации

утверждены

Испытания

начаты

Распространение

начато

Изделие

снято

1,

2,

4,

5,

6

1,

2,

8

2,

8,

9,

10

10

Ключевые

решения,

которые

должны

основываться

на

ре-

зультатах

фазового

обзора,

будут

ответами

на

следующие

во-

просы:

Фаза

I.

Следует

ли

вкладывать

ресурсы

в

продолжение

анализа

осуществимости

проекта?

Фаза

II.

Обоснована

ли

реализуемость

проекта

и

следует

ли

расходовать

средства

на

проектирование?

Фаза

III.

Удовлетворяет

ли

проект

потребностям

пользо-

вателя

в

текущий

момент

времени

и

следует

ли

выделять

сред-

ства

для

завершения

работ?

Фаза

IV.

Закончена

ли

разработка

изделия

и

можно

ли

ему

дать

объективную

независимую

оценку?

Фаза

V.

Достаточно

ли

высоко

качество

программного

изделия

для

его

поставки

пользователю?

Фаза

VI.

Можно

ли

прекратить

обслуживание

программ-

ного

изделия?

Администраторы

планирования

выступают

в

роли

орга-

низаторов

фазового

обзора.

Однако

эту

роль

могут

выполнять

и

представители

различных

конкурирующих

групп.

Независимо

от

того,

кто

проводит

обзор,

группа

планиро-

вания

обладает

решающим

голосом

в

фазовых

обзорах

I,

II,

V

и

VI.

Перечень

вопросов,

подлежащих

рассмотрению

в

каждом

обзоре,

строго

стандартизирован:

•

Строго

ли

выполняются

планы?

Окончание табл. 8.2 

207 

•

Строго

ли

соблюдаются

все

предварительные

техниче-

ские

условия?

•

Идет

ли

разработка

проекта

в

соответствии

с

намечен-

ным

графиком?

•

Не

превышают

ли

расходы,

связанные

с

проектирова-

нием,

определенные

статьи

бюджета?

•

Обеспечены

ли

все

необходимые

взаимодействия?

•

Существуют

ли

какие-либо

оправдания

замеченным

нарушениям?

•

Каков

элемент

случайности,

присутствующий

в

пла-

нах?

•

В

чем

состоят

основные

трудности?

•

Каковы

возможные

пути

преодоления

основных

труд-

ностей?

•

С

каким

риском

связано

продолжение

работ?

•

С

каким

риском

связано

прекращение

работ?

•

Удовлетворяет

ли

программное

изделие

в

его

нынеш-

нем

виде

текущим

требованиям?

Когда

эти

вопросы

изучены,

определяются,

согласовыва-

ются

и

предпринимаются

необходимые

действия.

Набор

этих

действий

также

стандартизован:

•

Продолжение

работ

по

плану.

•

Пересмотр

планов

и

спецификаций

с

последующим

продолжением

работ

согласно

новым

установкам.

•

Ввод

в

действие

планов

в

случае

непредвиденных

об

-

стоятельств

для

обеспечения

возможности

возврата

к

исходным

спецификациям,

графикам

работ

и

сметам

затрат.

•

Прекращение

работ.

Проведение

фазовых

обзоров

упрощается

за

счет

исполь-

зования

стандартного

обслуживания

механизма

обсуждения.

Некоторые

вопросы,

поднимаемые

в

фазовых

обзорах,

относят-

ся

к

сфере

текущей

интерпретации

предварительных

соглаше-

ний.

Всякое

несоответствие

должно

устраняться

по

ходу

его

обнаружения.

Следует

помнить,

что

соглашение

о

требованиях

всегда

должно

правильно

отражать

реальную

ситуацию,

а

спе-

цификации

должны

быть

в

любой

момент

времени

закончен-

208 

ным

документом,

который

правильно

описывает,

что

представ-

ляет

собой

программное

изделие.

Управление

программным

изделием

основано

на

осуще-

ствлении

контроля

и

сведении

балансов:

группа

планирования

постоянно

следит

за

расхождением

между

реальным

положени-

ем

дел,

связанных

с

проектированием

программного

изделия,

планами

и

спецификациями.

Механизм

рассмотрения

и

утвер-

ждения

должен

обеспечивать

возможность

выявления

расхож-

дений

и

последующее

их

устранение.

Технические

советы,

объ-

единенные

комиссии

и

фазовые

обзоры

как

раз

и

являются

та-

ким

механизмом.

8.3 

Организация

разработки

программного

изделия

Под

управлением

проектом

мы

будем

понимать

управле-

ние

достижением

требований,

предъявляемых

к

программному

изделию

на

основании

использования

матричной

структуры

связи

функций

и

проектов.

В

этой

матрице

каждой

функции

соответствует

группа

руководителей,

несущих

ответственность

за

ее

выполнение

наилучшим

образом,

каждому

программному

изделию

соответствует,

в

свою

очередь,

группа

руководителей,

внимание

которых

сосредоточено

только

на

данном

программ-

ном

изделии

(рис.

8.6).

Администратор

проекта

(руководитель)

занят

одним-

единственным

проектом,

каждая

функция

которого

охватывает

несколько

индивидуальных

разработок.

Администратор

изделия

регулирует

степень

участия

каж-

дой

функциональной

группы

в

разработке

программного

изде-

лия,

успешность

которой

определяется,

прежде

всего,

степенью

соблюдения

ранее

установленных

технических

требований

и

целей,

допустимых

границ

затрат.

Обычно

он

начинает

выпол-

нять

свою

роль,

начиная

с

фазы

анализа

осуществимости

и

до

окончания

фазы

оценки.

Администратор

—

это,

обычно,

со-

трудник

подразделения

разработки,

хорошо

понимающий

рабо-

ты,

выполняемые

другими

людьми

и

подразделениями

(часто

бывает,

что

он

несет

ответственность

за

все,

не

имея

полномо-

чий).

209 

Рис.

8.6

—

Схема

матричного

управления

проектом

В

матричной

структуре

каждый

разработчик

имеет

двух

начальников.

Однако

именно

матричная

структура

наиболее

эффективна

для

управления

такими

непредсказуемыми

процес-

сами,

как

разработка

программ.

8.3.1 Организация разработки программного изделия 

в фазе исследований 

Затраты

труда

при

реализации

функций

разработки

от-

дельного

программного

изделия,

согласно

кривой

Релея,

имеют

максимальное

значение

в

фазах

проектирования

и

программи-

рования.

Осуществление

функций

разработки

начинается

в

фазе

исследований

с

того

момента,

когда

будет

признана

необходи-

мость

создания

конкретного

программного

изделия.

В

этом

слу-

чае

план

—

это

план

завоевания

рынков

сбыта,

план

выпуска

серии

программных

изделий

и

бюджет.

Основной

параметр

этих

планов

—

срок,

к

которому

возникает

необходимость

в

данном

программном

изделии.

Первая

задача,

выполняемая

в

Индивиду-

альный 

проект 1 

Индивиду-

альный 

проект 2 

Индивиду-

альный 

проект 3 

Разработ-

чики 

Индивиду-

альный 

проект 1 

Индивиду-

альный 

проект 2 

Индивиду-

альный 

проект 3 

Обслужи-

вание 

Индивиду-

альный 

проект 1 

Индивиду-

альный 

проект 2 

Индивиду-

альный 

проект 3 

Выпуск до-

кументации 

Индивиду-

альный 

проект 1 

Индивиду-

альный 

проект 2 

Индивиду-

альный 

проект 3 

Испытания 

Индивиду-

альный 

проект 1 

Индивиду-

альный 

проект 2 

Индивиду-

альный 

проект 3 

Сопровож-

дение 

Общее ру-

ководство 

А

дм

инис

-

тр

ат

ор

 1 

А

дм

инис

-

тр

ат

ор

 2 

А

дм

инис

-

тр

ат

ор

 3 

210 

рамках

разработки,

состоит

в

том,

чтобы

определить,

когда

сле-

дует

начать

разработку

изделия,

чтобы

обеспечить

его

готов-

ность

к

моменту,

когда

в

нем

возникнет

необходимость.

Функ-

ция

разработки

предусматривает

согласование

момента

начала

проектирования

с

возможностью

выполнения

других

функций,

чтобы

гарантировать

их

совместное

обеспечение

в

процессе

проектирования.

В

рамках

функции

разработки

фиксируются

предлагаемые

сроки

начала

и

завершения

всех

видов

работ,

среди

которых

выделяют

основные

этапы

проектирования,

и

запрашиваются

ресурсы,

необходимые

для

анализа

осуществи-

мости

проекта,

—

кадры,

машинное

время,

командировки,

фон-

ды

для

проведения

консультаций.

Это

достигается

путем

со-

ставления

сметы

затрат,

в

которой

обязательно

указывается,

кто

несет

ответственность

за

выполнение

проекта

в

каждой

функ-

циональной

группе,

здесь

же

предлагается

кандидатура

руково-

дителя

проекта

в

целом.

Руководитель

проекта

(администратор)

дает

указание

выполнить

анализ

результатов

работ,

выполнен-

ных

в

фазе

I

(фазовый

обзор),

и

ходатайствует

о

соответствую-

щем

финансировании.

Обычно

администратор

ограничивается

выделением

средств

на

работы,

связанные

с

составлением

со-

глашения

о

требованиях.

Такая

мера

ограничит

трату

ресурсов,

в

которых

нет

необходимости

во

время

фазы

анализа

осущест-

вимости.

Для

правильного

принятия

решения

на

основе

результа-

тов

фазы

I

оценивается

не

только

стоимость,

но

и

календарные

сроки

проектирования.

Поэтому

один

из

участников

проекта,

ответственный

за

подготовку

соглашения

о

требованиях,

пред-

ставляет

формально

законченный

план

—

график

работ.

Этот

первоначальный

вариант

плана

должен

обязательно

фиксиро-

вать

точный

срок

представления

соглашения

о

требованиях

и

предполагаемый

срок

окончания

разработки

программного

из-

делия.

Если

на

основании

фазового

обзора

I

руководство

разре-

шает

начать

анализ

осуществимости,

выделяя

для

этого

соот-

ветствующие

ресурсы,

то

предпринимается

попытка

составить

соглашение

о

требованиях.

Формальное

составление

соглаше-

ния

о

требованиях

облегчается,

если

придерживаться

строго