Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Глава III испр.docx
Скачиваний:
45
Добавлен:
02.04.2015
Размер:
152.27 Кб
Скачать
      1. Прогнозирование

        1. Количественные характеристики

ТЗ включает в том числе ряд количественных показателей, которые, для проекта, разработка которого еще только предстоит, нельзя измерить, а можно только прогнозировать. Основой для прогноза является опыт экспертов и/или метрические данные об аналогичных проектах, которые уже разработаны.

Основными количественными показателями проекта являются:

  1. размер кода (измеряется количестве строк кода LOC – Lines Of Codes);

  2. трудозатраты (измеряется в чел/час, чел/месяц, чел/год…);

  3. стоимость, т.е. размер необходимого финансирования (в руб., $, э…);

  4. длительность работы над проектом (в днях, месяцах, годах..).

Прогнозирование показателей, перечисленных под №№ 2-4 базируется на предполагаемом размере проектируемой ИС. В свою очередь размер ИС оценивается экспертами на основании как опыта собственных разработок, так и метрических данных о уже разработанных ИС. Эти оценки предваряются составлением пооперационного перечня работ (ППР). Эта последовательность прогнозирования основных параметров проекта показана на

Рис. III‑12 Последовательность оценки количественных характеристик проекта

Итак, размер ПО есть та отправная точка, от которой производятся остальные прогнозы базовых количественных характеристик проекта. Основой прогноза размера являются метрические данные. Метрические данные – это разнообразные сведения о ранее разработанных системах, как минимум, об их размерах, стоимости, трудоемкости, времени разработки.

Желательно сохранять сведения о допущенных при разработке ошибках, а именно на каком этапе ошибка допущена, на каком выявлена, причина её возникновения, стоимость её устранения, время, требуемое на устранение и другие сведения.

Как эксперты, так и разработчики используют метрические сведения и чем большим объёмом таковых они располагают, тем выше будет точность их оценки.

При планировании строительства бруклинского моста точность оценки по стоимости и времени разработки была ±1%. При прогнозировании затрат и времени разработки ПО начальное планирование не может быть точнее более чем в четыре раза. Причина этого в том, что мосты человечество строит не одну тысячу лет, а программирует от силы лет 50, и значит, накопленные метрические данные по строительству мостов несопоставимы с данными о программных продуктах.

Тем не менее оценки производить необходимо, так как без предварительных оценок не будет производиться финансирование работ.

Для повышения точности экспертных оценок можно использовать три оценки, то есть эксперт дает оценку с его точки зрения:

  • максимальную

  • минимальную

  • реальную

Например прогнозируемая оценка:

Так как исходный код может быть в разных языках программирования, то для учета сравнительной сложности работ введена единица SLOC, то есть количество строк в базовом Assembler(e) (см. Таблица III -4).

При подсчёте LOC используются правила:

  1. строка кода содержит только один оператор;

  2. учитываются все выполняемые операторы;

  3. определение данных учитывается один раз;

  4. не учитывается отладочный (временный) код.

Таблица III‑4 Соответствие LOC и SLOC для разных языков программирования

Язык

SLOC (Basic Assembler)

Средний показатель SLOC на 1 функциональную точку.

Basic Assembler

1

320

С \C++

1,5\6

320\53

Basic

3

107

FORTRAN

3

105-106

PROLOG

5

64

JAVA

6

53

Pascal\DELPHI

3,5\11

91\29

Языки 4 поколения

16

20

Языки б/д SQL

25

13-16

EXCEL (языки эл. таблиц)

50

6

Зная примерный размер проекта, можно сделать приблизительные оценки его базовых количественных характеристик. В задачу данного пособия не входит подробное рассмотрение моделей для их вычисления. Все они носят эмпирический характер, т.е. получены на базе анализа опыта уже состоявшихся разработок. Для примера рассмотрим оценку трудозатрат:

Трудозатраты = а(размер)в

где a, b – эмпирические константы. Собственно формула не содержит других переменных, кроме «размера кода», что может показаться странным, ведь каждому, имеющему опыт программирования хотя бы в рамках школьного курса информатики, ясно, что создание разных по сложности программ требует разных усилий. Но дело в том, что влияние сложности проекта учтено в значениях констант, т.е. a и b зависят от сложности проекта. Рассмотрим как сложность проекта влияет на вычисляемые значения на примере:

Пример. Для простого проекта размер которого 200 kLOC, а=2.4, b=1.05, и значит:

Трудозатраты =2.4*(200)1.05=2.4*260.66= 626 чел.-мес

Но если проект очень сложный, то для него а=3.6, b=1.2, и значит при том же размере в 200 kLOC имеем:

Трудозатраты = 3.6*(200)1.2= 2077 человеко-месяцев

Т.е. трудозатраты при одном и том же размере проекта возросли в 3,3 раза.