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

211 

формализованной

формы.

Требования

должны

быть

выражены

в

ясной

форме

и

не

допускать

противоречивых

толкований.

В

соглашениях

о

требованиях

следует

избегать

пунктов,

объяс-

няющих,

как

надо

решать

поставленную

задачу.

Рассматривая

соглашения

о

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

функциональные

группы

обычно

на-

кладывают

жесткие

ограничения

на

эксплуатационные

качества

и

другие

характеристики

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

изделия.

Для

обоснования

этих

ограничений

(принять

или

нет)

обязательно

должен

быть

проведен

достаточно

глубокий

анализ

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

Соглашение

о

требованиях

—

это

договор

между

руково-

дителем

проекта

и

заказчиком,

который

также

включает

суб-

подряды,

заключенные

между

группой

разработки

и

другими

функциональными

группами.

Договорный

характер

соглашения

о

требованиях

подчеркивается

тем,

что

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

индиви-

дуальные

рабочие

планы

к

конкретным

положениям

данного

документа.

И

так как

соглашение

о

требованиях

связывает

во-

едино

усилия

многих

подразделений,

его

необходимо

согласо-

вывать

на

всех

уровнях

(вплоть

до

конкретного

исполнителя).

На

базе

соглашения

о

требованиях

составляется

общий

план

для

всего

проекта.

В

нем

указываются

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

между

функциональными

группами

и

вклад

каждой

из

них

в

проект,

а

также

очерчиваются

границы

обязанностей

каждой

группы.

В

этом

плане

также

дается

основа

описания

всех

задач,

решаемых

группой

разработки.

Обычно

этот

план

составляется

в

виде

сетевого

графика.

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

в фазе анализа осуществимости 

Анализ

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

проводится

одновременно

всеми

функциональными

группами

на

основе

изучения

соглашения

о

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

На

этом

этапе

исследуется

каждое

предложение

соглашения

о

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

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

проекта

поясняет

и

защищает

свой

сетевой

график.

В

процессе

обсуждения

вносят-

ся

изменения

в

эти

документы

и

вновь

представляются

на

ут-

верждение.

Может

быть

предусмотрено

несколько

неформаль-

ных

процедур

пересмотра

плана,

однако

все

они

должны

быть

успешно

закончены

официальным

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

—

фазовым

212 

обзором

II.

В

результате

фиксируется

согласие

или

несогласие

каждой

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

группы

с

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

соглашения

о

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

Полученные

в

ходе

фазового

обзора

II

предложения

отно-

сительно

внесения

изменений

в

соглашение

о

требованиях

дают

возможность

оценить

недостатки

проекта.

Оценку

проводят

по

трем

переменным:

технические

характеристики,

календарные

сроки

и

стоимость

(рис.

8.7).

Рис.

8.7

—

Границы

изменяемости

проекта: 

C

c

—

увеличение

стоимости;

S

c

—

изменение

времени;

F

c

—

изменение

технических

характеристик

То  есть

внутри

проекта

выделяется

некоторый

диапазон

изменения

переменных;

фактически

это

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

заданию

небольшого

запаса

финансовых

ресурсов,

времени

и

свободы

выбора

технических

характеристик

системы.

На

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

переработку

и

утверждение

соглашения

о

требованиях

может

уйти

много

времени,

поэтому

обычно

эта

работа

совмещается

с

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

разработки

в

тех

масшта-

бах,

которые

позволяют

ресурсы.

Параллельно

с

процессом

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

соглашения

о

требованиях

составляются

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

рабочие

планы

и

С

с

S

с

F

с

213 

сводка

трудозатрат,

которые

будут

основой

для

определения

будущих

финансовых

затрат.

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

в фазе конструирования (проектирования) 

Основная

цель

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

заключается

в

выработке

и

анализе

требований

к

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

изделию.

Процесс

де-

композиции

проекта,

начатый

при

составлении

соглашения

о

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

продолжается

путем

разработки

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

и

разбивки

их

на

две

части

—

внутренний

и

внешний

проект.

Внешний

проект

—

это

совокупность

характеристик

программно-

го

изделия,

которые

видит

пользователь.

Внутренний

проект

—

совокупность

характеристик

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

изделия,

скрытых

от

пользователя.

Это

делается,

в

первую

очередь,

для

того,

чтобы

пользователи

могли

критически

рассматривать

те

характери-

стики

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

изделия,

которые

имеют

к

ним

непосред-

ственное

отношение,

не

вдаваясь

в

критику

внутренних

харак-

теристик

изделия.

То есть

внешний

проект

описывает,

что

дела-

ет

программное

изделие,

а

внутренние

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

указыва-

ют,

каким

образом

изделие

сконструировано

для

достижения

внешних

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

Внешние

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

передаются

для

открытого

и

широкого

обсуждения,

в

котором

предпочте-

ния

отдаются

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

пользователей.

Для

того

чтобы

провести

границу

между

внутренним

и

внешним

проектом,

схему

декомпозиции

упорядочивают.

Схе-

ма

декомпозиции

называется

хорошо

упорядоченной,

если

на

ней

отмечен

каждый

случай

вызова

одной

функции

другой,

вплоть

до

некоторого

уровня

абстракции,

удобного

с

точки

зре-

ния

управления

проектом.

Далее,

каждый

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

мо-

дуль

рассматривается

как

черный

ящик,

для

которого

можно

определить

внешнее

поведение,

однако

ничего

нельзя

сказать

относительно

его

внутреннего

устройства.

Свойства

черного

ящика

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

полным

описанием

его

характеристик,

ви-

димых

извне,

включая

описание

условий,

при

которых

к

нему

можно

обратиться,

чтобы

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

его

функционирование.

Те

атрибуты

модулей,

которые

играют

существенную

роль

при

составлении

описания

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

изделия

как

единого

цело-

214 

го,

составляют

внешний

проект.

Все

остальные

параметры

мо-

дулей,

полностью

или

частично

скрытые

внутри

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

изделия,

составляют

внутренний

проект.

С

учетом

четкого

различия

между

внешним

и

внутренним

проектом,

следует

составлять

внешние

и

внутренние

специфи-

кации

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

изделия.

При

этом

необходимо

избегать

общих

мест

в

разных

документах.

Формы

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

обыч-

но

строго

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

(SADT,

PDL,

и

др.).

После

того,

как

внешние

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

приобретают

сравнительно

стабильный

характер,

в

рамках

функции

разра-

ботки

производится

их

рассылка

функциональным

группам

(с

пометкой

«проект»).

Все

замечания

суммирует

специальный

орган

—

технический

комитет,

который

после

анализа

передает

их

в

группу

разработки.

Обязанность

группы

разработки

—

максимально

учесть

все

замечания.

Во

время

создания

внутренних

и

внешних

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

другие

функциональные

группы

готовят

планы

выпуска

доку-

ментации,

планы

испытаний

и

др.

Эти

документы

рассылаются

на

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

в

конце

фазы

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

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

проекта

изучает

и

утверждает

их.

Фаза

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

обычно

заканчивается

утверждением

внешних

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

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

в фазе программирования 

Рабочая

нагрузка

при

выполнении

функции

разработки

достигает

наибольшей

величины

в

фазе

программирования.

Ос-

новная

задача

организации

разработки

заключается

в

координа-

ции

усилий

большого

числа

сотрудников,

занятых

реализацией

этой

функции,

а

также

в

организации

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

между

различными

функциональными

группами.

Метод

—

соблюде-

ние

принятых

на

данном

предприятии

стандартов

программи-

рования.

Кодирование

начинается

на

ранней

стадии

программиро-

вания.

При

этом

используется

так

называемый

«волновой

эф-

фект»

(табл.

8.3),

когда

составление

внешних

и

внутренних

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

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

отладка

и

компоновка

программ

выполняются

одновременно

на

различных

уровнях

структуры

215 

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

изделия.

Например,

в

фазе

программирования

какого-то

модуля

внешние

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

всего

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

изделия

уже

могут

быть

утверждены,

а

внутренние

специфика-

ции

составлены

не

до

конца.

И

наоборот,

хотя

этапы

кодирова-

ния,

отладки

и

компоновки

некоторых

модулей

уже

могут

быть

завершены,

их

разработка

в

рамках

целого

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

про-

дукта

еще

может

быть

не

закончена.

Таблица

8.3

—

Волновой

эффект

в

разработке

модулей

изделия

Модули

A

B

C

D

E

F

G

H

I

J

K

L

M

N

Состав-
ление

внешних

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

заверше-
но

×

×

–

–

×

×

×

–

–

–

×

×

×

×

Состав-
ление

внутрен-
них

спе-

цифика-
ций

за-

вершено

×

×

×

×

–

×

×

×

×

–

–

×

×

×

Кодиро-
вание

законче-
но

×

×

×

–

–

×

×

×

×

–

–

×

–

×

Отладка

законче-
на

×

×

×

–

–

×

×

×

–

–

–

×

–

×

Компо-
новка

законче-
на

×

×

×

–

–

–

×

×

–

–

–

×

–

–

Если

желательно

избрать

более

жесткий

путь

и

если

в

программе

нельзя

выделить

сравнительно

слабо

связанные

ком-

поненты,

то

целесообразно

закончить

не

только

внешний

про-