Учебное пособие: Технология раработки програмного обеспечения УП
26
программы,
хранящиеся
в
библиотеке?
Следует
ли
исходить
из
строк
или
операторов
начального
текста?
В
зависимости
от
от-
ветов
на
эти
вопросы
количество
строк
кода
может
меняться
в
2–4
раза.
Эффективность
действия
отдельного
программиста
в
зна-
чительной
мере
зависит
от
типа
задачи.
Организация
работы
программиста
также
влияет
на
результаты
труда.
Например,
в
условиях
дефицита
времени
очень
мало
внимания
уделяется
документации.
Однако
т.к.
≈
70 %
общих
затрат
идет
на
сопро-
вождение,
экономия
времени
на
разработку
документации
мо-
жет
оказаться
пагубной.
Один
из
методов
решения
поставленных
проблем
может
состоять
в
учреждении
должности
библиотекаря,
осуществ-
ляющего
функции
интерфейса
между
программистом
и
ЭВМ.
Программы
кодируются
и
передаются
библиотекарю
для
вклю-
чения
их
в
оперативную
системную
библиотеку.
Отладка
мо-
дулей
осуществляется
программистом,
однако
изменение
офи-
циальной
копии
программы
в
библиотеке
осуществляется
толь-
ко
библиотекарем.
Использование
библиотеки
еще
более
рас-
ширяется
при
наличии
оперативной
системы
управления
дан-
ными.
Введение
должности
библиотекаря
имеет
еще
один
по-
ложительный
эффект:
все
изменения
в
программных
модулях
системной
библиотеки
производит
один
человек,
поэтому
этим
процессом
легко
управлять.
Подобный
подход
позволяет
пре-
дотвратить
неоправданные
изменения
и
побуждает
программи-
ста
тщательно
обдумывать
каждое
из
них.
При
этом
руководи-
тель
получает
возможность
осуществлять
систематический
кон
-
троль
за
ходом
проектирования
и
облегчается
проверка
состоя-
ния
работ.
При
крупномасштабных
проектах
для
написания
доку-
ментации
привлекаются
технические
исполнители,
что
позво-
ляет
освободить
программистов
для
более
квалифицированных
работ.
В
крупных
организациях
(фирма
IBM)
создается
бригада
главного
программиста.
При
создании
бригады
исходят
из
того,
что
программисты
имеют
различные
уровни
квалификации.
Ор-
27
ганизация
бригады
главного
программиста
является
одним
из
путей
уменьшения
количества
коммуникаций
(рис.
3.3).
Рис.
3.3
—
Снижение
количества
взаимосвязей
при
использовании
бригады
главного
программиста
3.1.2 Методика оценки затрат
Одним
из
важнейших
аспектов
процесса
разработки
про-
граммного
обеспечения
является
оценка
необходимых
ресурсов
или
требуемых
затрат.
3.1.2.1 Методика инженерно-технической оценки затрат
Базовая
методика
оценки
затрат
заключается
в
следую-
щем:
Шаг
1.
Формируются
общие
требования
к
системе
исходя
из
существующего
технического
задания.
Потенциальных
раз-
работчиков
информируют
о
том,
что
ожидают
от
системы.
Этот
документ
именуют
«списком
пожеланий».
Для
более
точного
определения
требуемых
ресурсов
проводится
анализ
требова-
ний.
Шаг
2.
Собирается
аналогичная
информация,
например
данные
о
подобных
системах.
Шаг
3.
Отбираются
основные
релевантные
данные.
Шаг
4.
Проводится
предварительная
оценка.
Шаг
5.
Проводится
окончательная
оценка
системы.
Основной
этап
этой
работы
—
шаг
4.
При
его
выполне-
нии
проводятся
следующие
действия.
Шаг
4а.
Сравнение
проектируемой
системы
с
подобными
уже
разработанными
системами.
28
Шаг
4б.
Разбиение
системы
на
части
и
сравнение
каждой
из
этих
частей
с
подобными
ей
частями
других
систем.
Шаг
4в.
Планирование
работ
и
оценка
затрат
на
каждый
месяц.
Шаг
4г.
Разработка
соглашений,
которые
могут
быть
ис-
пользованы
при
работе.
Отметим,
что
реализация
шага
4а
при
отсутствии
доста-
точного
опыта
может
занять
довольно
продолжительный
пери-
од
времени.
Шаг
4б
требует
тщательного
определения
понятия
«часть
системы».
Не
отличается
строгим
регламентом
и
шаг
4г,
так
как
нет
адекватного
набора
стандартных
соглашений.
По-
этому
в
реальной
практике
используются
различные
модифика-
ции
рекомендуемого
метода,
базирующиеся
либо
на
более
фор-
мализованных
понятиях,
либо
на
субъективных
оценках.
Метод
экспертных
оценок.
Оценка
производится
исходя
из
личного
опыта
квалифицированного
проектировщика
(экс-
перта).
Для
многих
приложений
проектировщики
могут
прогно-
зировать
сложность
системы
и
оценку
ресурсных
затрат,
даже
если
алгоритмы
еще
в
явном
виде
не
определены.
Подобная
оценка
основывается
на
опыте
работы
проектировщика
над
схожей
системой.
Однако
при
этом
очень
велико
влияние
субъ-
ективных
факторов,
так
что
метод
в
целом
не
лучше,
чем
ис-
кусство
отдельного
проектировщика.
Тем
не
менее
при
отсутст-
вии
строгой
теории
и
недостатке
эмпирических
знаний
этот
ме-
тод
принимается
за
основу
стратегии
оценки
затрат.
Метод
алгоритмического
анализа.
При
данном
методе
оценки
затрат
используется
некоторый
алгоритм.
Оценка
явля-
ется
объективной
и
повторяемой.
Сейчас
теория
подобных
ал-
горитмов
развивается
довольно
бурно,
однако
пока
на
практике
применяется
лишь
небольшое
число
подобных
алгоритмов.
Кроме
того,
алгоритм
приводит
к
правильным
результатам
лишь
в
том
случае,
если
используемые
для
расчетов
данные
(специфика-
ции)
достаточно
точны,
что
редко
бывает
на
практике.
Пошаговый
анализ.
Задаются
спецификации
на
основе
пошагового
анализа
по
нисходящему
либо
восходящему
прин-
ципу,
так
что
каждая
определенная
таким
образом
задача
оце-
нивается
отдельно.
Такой
полуалгоритмический
процесс
может
29
быть
скомбинирован
с
такими
методами,
как
метод
экспертных
оценок.
Закон
Паркинсона.
Во
многих
случаях
для
выполнения
некоторой
работы
(задачи)
затрачивается
то
время,
которое
от-
ведено
для
нее,
независимо
от
того,
является
ли
выполнение
этой
работы
необходимым.
Каждый
исполнитель
вносит
какой-
то
вклад
в
работу
над
системой
и
расходует
определенное
вре-
мя.
Подобный
подход
опирается
на
использование
других
ме-
тодов,
т.е.
если
оценка
уже
произведена
(например,
с
помощью
экспертов),
все
привлекаемые
исполнители
будут
выполнять
свою
работу
безотносительно к ее
важности
и
необходимости.
При
подобном
подходе
структура
системы
зачастую
определя-
ется
составом
коллектива
разработчиков
(если
над
системой
работает
3
человека,
то
она,
скорее
всего,
будет
состоять
из
трех
сегментов).
Затраты
на
завершение
разработки.
В
некоторых
случа-
ях
стоимость
системы,
оговариваемая
при
заключении
догово-
ра,
намеренно
занижается
разработчиком
системы
в
надежде,
что
в
последующем
ее
можно
будет
существенно
увеличить
за
счет
изменения
спецификаций.
После
заключения
договора
на
разработку
какой-то
части
системы
изменение
спецификаций
происходит
по
соглашению
между
разработчиком
и
заказчиком
без
участия
других
лиц.
В
этом
случае
разработчик
находится
в
более
выгодном
положении,
чем
заказчик,
поскольку
на
разра-
ботку
системы
уже
затрачены
значительные
средства
и
для
за-
казчика
нецелесообразно
начинать
ее
заново
с
привлечением
других
специалистов.
Заказчику
следует
проявлять
осмотри-
тельность
в
отношении
предложений,
резко
отличающихся
от
других.
Более
того,
он
должен
тщательно
проводить
анализ
системных
требований,
чтобы
избежать
необходимости
измене-
ния
спецификаций.
Психологический
аспект.
В
некоторых
случаях
оценки
стоимости
системы
различными
разработчиками
довольно
близки.
Проведенный
ими
алгоритмический
анализ
проблемы
остается
впечатляющим
до
тех
пор,
пока
не
проведен
более
тщательный
анализ.
В
подобных
случаях
разработчики
просто
осведомлены
о
наличии
средств
у
заказчика.
30
В
общем
случае
точную
оценку
затрат
можно
дать
лишь
на
основе
опыта.
3.1.2.2 Оценка на основе распределения Рэлея
В
настоящее
время
некоторые
результаты
теории
надеж-
ности
аппаратных
средств
ЭВМ
начинают
использовать
для
оценки
сроков
и
затрат
при
разработке
программного
обеспече-
ния.
Было
установлено,
что
зависимость
суммарных
затрат
от
времени
при
разработке
больших
систем
(свыше
50
человеко-
лет)
хорошо
отображается
следующим
уравнением:
( )
(
)
2
,
1
at
E t
K
e−
=
−
где
E(t)
—
суммарные
затраты
к
моменту
времени
t;
К
—
общая
стоимость
системы;
а
—
характеристика
максимальных
затрат
на
единичном
отрезке
времени.
Такая
зависимость,
выраженная
в
дифференциальной
форме,
отображается
кривой
Рэлея
( )
2
,
2
at
E t
K a t e−
′
= ⋅ ⋅ ⋅ ⋅
где
E’(t)
—
плотность
затрат
или
ежегодные
затраты
(рис.
3.4).
Рис.
3.4
—
Отображение
ежегодных
затрат
кривой
Рэлея
0
0,1
0,2
0,3
0,4
0,5
1
4
7 10 13 16 19 22 25 28 31 34 37 40
Время
Еж
е
го
д
н
ы
е
за
тр
а
ты