ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 10758
Скачиваний: 8
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
Состав-
ление
внешних
специ-
фикаций
заверше-
но
×
×
–
–
×
×
×
–
–
–
×
×
×
×
Состав-
ление
внутрен-
них
спе-
цифика-
ций
за-
вершено
×
×
×
×
–
×
×
×
×
–
–
×
×
×
Кодиро-
вание
законче-
но
×
×
×
–
–
×
×
×
×
–
–
×
–
×
Отладка
законче-
на
×
×
×
–
–
×
×
×
–
–
–
×
–
×
Компо-
новка
законче-
на
×
×
×
–
–
–
×
×
–
–
–
×
–
–
Если
желательно
избрать
более
жесткий
путь
и
если
в
программе
нельзя
выделить
сравнительно
слабо
связанные
ком-
поненты,
то
целесообразно
закончить
не
только
внешний
про-