Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии разработки ПО. Лабораторный практикум
.pdf
Этап расчета метрик:
– рассчитать размерно-ориентированные метрики (SLOC,
метрики Холстеда);
– определить параметры производительности и качества
работы программиста;
– занести результаты расчета в табл. 1.2.
Таблица 1.2
Название параметра Обозначение Значение
Количество логических строк кода SLOC
Количество уникальных операторов h
Количество уникальных операндов h
Общее количество операторов N
Общее количество операндов N
Словарь программы
Длина программы N
Оценочная длина программы
Объем программы V
Сложность программы D
Трудоемкость программы E
Расчетное время реализации T
Расчетное количество ошибок B
Время выполнения этапа кодирования T
Количество ошибок, внесенных на этапе коди-
рования
Производительность работы программиста PP
Эффективность обнаружения ошибок на этапе
анализа
Эффективность обнаружения ошибок на этапе
проектирования
Эффективность обнаружения ошибок на этапе
кодирования
Удельная стоимость кода С
h
°
N
B
DDE
DDE
DDE
уд
1
2
1
2
к
к
1
2
3
1.4. Пример выполнения расчетов
Предположим, что перед разработчиком была поставлена
задача вывода на экран консоли суммы элементов главной диагонали квадратной матрицы, заполненной случайными целыми числами.
11
1.4.1. Анализ
На этапе анализа разработчик выделил следующие функциональные требования к программе:
– программа должна заполнять квадратную матрицу слу-
чайными числами;
– программа должна осуществлять суммирование элемен-
тов главной диагонали матрицы и выводить сумму на экран.
Форматом выходных данных было принято строковое
представление целого числа.
При выборе формата входных данных была выявлена ошибка в функциональных требованиях: не указана необходимость
ввода с клавиатуры размера матрицы, которая была исправлена.
Время выполнения этапа – 6 минут.
1.4.2. Проектирование
На этапе проектирования было решено заполнять ячейки
матрицы случайными целыми числами с использованием методов класса Random. Были описаны алгоритм заполнения матрицы и алгоритм суммирования элементов главной диагонали.
Обнаружилась ошибка в формате выходных данных, допущенная на этапе анализа: использование для суммы того же
типа данных, что и для слагаемых, может привести к переполнению.
Время выполнения этапа – 12 минут.
1.4.3. Кодирование
На этапе кодирования при первичной отладке было выявлено три ошибки в коде и одна ошибка проектирования в алгоритме заполнения матрицы: число шагов цикла превышает
количество ячеек.
Время выполнения этапа – 15 минут.
1.4.4. Тестирование
После компиляции программы было осуществлено ее тестирование, в ходе которого обнаружилась одна ошибка этапа
проектирования: алгоритм предполагал заполнение матрицы
12
положительными числами, тогда как множество целых чисел включает и отрицательные. Кроме того, была обнаружена
ошибка этапа кодирования: в коде были перепутаны индексы
строк и столбцов, и вычислялась сумма неглавной диагонали.
Время выполнения этапа – 15 минут.
Таким образом, сводная таблица выполнения этапов разработки принимает вид табл. 1.3.
Таблица 1.3
Этап Время, ч
Анализ 0,1 1 X X
Проектирование 0,2 1 0 X
Кодирование 0,25 0 1 3
Тестирование 0,25 0 1 1
анализа проектирования кодирования
Выявлено ошибок этапа
1.4.5. Расчет метрик
Листинг программы имеет вид:
1: using System;
2: namespace Lab01
3: {
4: class Program
5: {
6: static void Main (string [] args)
7: {
8: int n;
9: long sum = 0;
10: Random rand = new Random ();
11: Console.Write(«Введитеразмерматрицы:“);
12: Int32. TryParse (Console.ReadLine (),out n);
13: int [,] matrix = new int [n, n];
14: for (int i = 0; i< n; i++)
15: {
16: for (int j=0; j<n; j++)
17: {
18: matrix [i, j] = rand.Next (1000) – 500;
19: if (i == j) sum += matrix [i, j];
13
20: }
21: }
22: Console.WriteLine(«Суммаэлементов:{0}»,sum);
23:
24: }
25: }
26: }
Определим согласно правилам подсчета значение SLOC, занося промежуточные значения в табл. 1.4.
Таблица 1.4
Оператор Количество
if 1
for 2
; 8
{} 3
Таким образом, SLOC = 14.
Для расчета метрик Холстеда выделим уникальные операторы и операнды и приведем их общее количество (табл. 1.5).
Таблица 1.5
Операторы Операнды
№ оператор
1 int 5 13 , 6 1 n 6
2 ; 13 14 out 1 2 sum 3
3 long 1 15 [] 5 3 0 3
4 = 6 16 for 2 4 rand 2
5 Random 2 17 < 2 5 Console 3
6 new 2 18 ++ 2 6 «Введите размер
7 () 8 19 {} 2 7 matrix 3
8 . 5 20 Next 1 8 i 6
9 Write 1 21 - 1 9 j 6
10 Int32 1 22 == 1 10 1000 1
11 TryParse 1 23 += 1 11 500 1
12 ReadLine 1 24 WriteLine 1 12 «Сумма элементов:
кол-
№ оператор
во
кол-
№ операнд
во
кол-
во
1
матрицы: »
1
{0}»
14
Таким образом, h1 = 24, N1 = 71, h2 = 12, N2 = 36.
22
24 log 24 12 log 12 1� 53,06.N∧=⋅ +⋅ =
2
24 36
36.
2 12
D =⋅=
1
1
� 100 % 50 %.
2
DDE =⋅=
2
0
� 100 % 0 %.
2
DDE =⋅=
3
3
� 100 % 75 %.
4
DDE =⋅=
Рассчитаем метрики.
h = 24 + 12 = 36.
N = 71 + 36 = 107.
107 log 36 �553,19.V =⋅=
E = 553,19 × 36 = 19 914,84.
T = 19 914,84 / 64 800 = 0,31 ч.
B = 553,19 / 3000 = 0,18.
T
B
= 15 / 60 = 0,25 ч.
К
= 4.
К
PP = 14 / 0,25 = 56 строк/ч.
Для расчета удельной стоимости кода определим величину
финансовых затрат исходя из стоимости одного часа работы
программиста (условно, 1000 руб.):
С
= Tк ⋅ 1000 = 250 руб.
к
15
Тогда удельная стоимость равна:
С
= Ск / SLOC = 250 / 14 = 17,86 руб./строка.
уд
1.5. Вопросы для самоконтроля
1. Может ли в программе на языке C# количество логиче-
ских строк превышать количество физических?
2. Будут ли равны по количеству логических строк две
одинаковые по функционалу программы, написанные на разных языках программирования?
3. Будут ли равны по количеству физических строк две
одинаковые по функционалу программы, написанные на разных языках программирования?
4. Как изменятся словарь и длина программы (по Холстеду), если весь исходный код написать дважды подряд?
16
Лабораторная работа № 2
«ОПРЕДЕЛЕНИЕ ТРУДОЗАТРАТ
НА РАЗРАБОТКУ»
2.1. Цель работы
Получение практических навыков в оценке трудоемкости
разработки программ.
2.2. Теоретический минимум
Для оценки трудоемкости проекта на начальной стадии его
разработки размерно-ориентированные метрики не подходят,
поскольку никакой код еще не написан. На этом этапе можно
использовать методику подсчета функциональных указате-
лей (function points, FP) – численной оценки объема будущей
программы, исходя из ее функциональности, различимой на
этапе анализа требований. Подсчет регулируется стандартным
набором правил, процессов и руководств, определяемых международной группой пользователей функциональных баллов
(IFPUG), и включает в себя следующие этапы:
– определение границ приложения и выделение функцио-
нальных элементов;
– подсчет элементов данных и определение рангов функ-
циональных элементов;
– расчет количества функциональных указателей.
2.2.1. Определение границ приложения
и выделение функциональных элементов
Для корректного применения методики важно правильно
определить границу программы – воображаемую линию, отделяющую программу от внешней среды. Для определения этой границы необходимо выделить внешние по отношению к программе
сущности – пользователей или другие программы и проанализировать, какая часть информации находится под контролем программы, а какая – вне ее контроля. Группы данных, хранящиеся
внутри программы или вне ее, называют файлами, а процессы
перемещения данных через границу – транзакциями.
17
Различают три вида транзакций: внешний ввод, внешний
вывод и внешний запрос, и два вида файлов: внутренний логический файл и внешний интерфейсный файл (рис. 2.1).
Рис. 2.1. Границы и функциональные элементы программы
Внешний ввод (external input, EI) – элементарный процесс переноса данных или управляющей информации из
внешней среды в программу, влияющий на поведение программы или меняющий содержимое внутренних логических
файлов.
Внешний вывод (external output, EO) – элементарный процесс переноса данных или управляющей информации из программы во внешнюю среду, логика работы которого содержит
математические расчеты, создает производные данные, влияет на поведение программы или меняет содержимое внутренних логических файлов.
Внешний запрос (external inquiry, EQ) – элементарный
процесс переноса данных или управляющей информации из
программы во внешнюю среду, логика работы которого не содержит математических расчетов, не создает производных
данных, не влияет на поведение системы и не меняет содержимого внутренних логических файлов.
Внутренний логический файл (internal logical file, ILF) –
распознаваемая пользователем группа логически связанных
данных, которая располагается внутри программы и обслуживается через ее транзакции.
Внешний интерфейсный файл (external interface file, EIF) –
распознаваемая пользователем группа логически связанных
18
данных, которая располагается внутри другой программы и обслуживается ей.
Транзакции и файлы вместе образуют пять функциональ-
ных элементов.
2.2.2. Подсчет элементов данных
и определение рангов функциональных
элементов
Введем необходимые определения.
Элемент данных (data element type, DET) – распознаваемое пользователем уникальное динамическое поле данных.
Запись (record element type, RET) – распознаваемая пользователем подгруппа элементов данных в рамках внутреннего
логического или внешнего интерфейсного файла.
Ссылка на файл (file type referenced, FTR) – внутренний логический или внешний интерфейсный файл, читаемый или записываемый транзакцией.
Каждому функциональному элементу в зависимости от количества элементов данных, числа ссылок на файлы и числа
записей присваивается ранг сложности – низкий, средний,
или высокий в соответствии с табл. 2.1.
Таблица 2.1
Ранг сложности функциональных элементов
Функциональный элемент Элементов данных
EI 1–4 5–15 > 15
EO, EQ 1–4 5–19 > 19
ILF, EIF 1–19 20–50 > 50
Ссылок на файлы Записей Ранг
0–1 0–1 1 Низкий Низкий Средний
2 2–3 2–5 Низкий Средний Высокий
> 2 > 3 > 5 Средний Высокий Высокий
2.2.3. Расчет количества функциональных
указателей
Количество функциональных указателей определяется по
формуле
19
(
)
14
1
,
0,65 0,01
i
i
FP S F
=
=⋅ +⋅
∑
где S – сумма транзакций и файлов с учетом весовых коэффи-
циентов;
– коэффициенты регулировки сложности.
F
i
Для вычисления суммы S транзакции и файлы разного ранга суммируются со своими весовыми коэффициентами, определяемыми по табл. 2.2.
Таблица 2.2
Весовые коэффициенты функциональных элементов
Функциональный элемент
EI 3 4 6
EO 4 5 7
EQ 3 4 6
ILF 7 10 15
EIF 5 7 10
Низкий Средний Высокий
Ранг
Коэффициент регулировки сложности – это эмпирическая
оценка степени влияния на характеристики проектируемой
программы каждого из 14 системных параметров, приведенных
в прил. 1. Каждому коэффициенту присваивается значение в
баллах по шкале от 0 (не имеет значения) до 5 (имеет ключевое
значение).
Рассчитав количество функциональных указателей, можно
дать оценку размера будущей программы (SLOC′), выбрав язык
программирования и используя коэффициент пересчета из FP
в SLOC по табл. 2.3.
Таблица 2.3
Пересчет FP-оценок в SLOC-оценки
Язык программирования SLOC / FP
Assembler 119
C 97
C++ 50
C# 54
Excel 209
20
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]