А.В. Карпишук
Технологии разработки ПО
Лабораторный практикум
1
Оглавление
Введение ......................................................................................................................................... 3
1. Лабораторная работа № 1. «Расчет показателей масштабности» ......................................... 4
2. Лабораторная работа № 2. «Определение трудозатрат на разработку»............................. 16
3. Лабораторная работа № 3. «Разработка графических спецификаций» .............................. 26
4. Лабораторная работа № 4. «Определение связности класса» ............................................. 36
5. Лабораторная работа № 5. «Структурное тестирование» ................................................... 40
6. Лабораторная работа № 6. «Функциональное тестирование» ............................................ 48
7. Лабораторная работа № 7. «Разработка интерфейса пользователя» .................................. 61
Библиографический список ........................................................................................................ 69
Приложение А. Оценка системных параметров ...................................................................... 70
Приложение Б. Требования к оформлению отчетов ................................................................ 78
2
Введение
Целью освоения дисциплины «Технологии разработки ПО» является получения студентами знаний, умений и навыков, формирование профессиональных компетенций в области анализа, проектирования, реализации, тестирования, отладки, внедрения и сопровождения программного обеспечения вычислительной техники.
Цикл лабораторных работ по дисциплине направлен на закрепление знаний, полученных в лекционном курсе, и приобретение навыков решения типовых задач, стоящих перед разработчиками сложных программных средств. Данное учебное пособие содержит
описание методик решения таких задач, примеры выполнения и вопросы для самоконтроля.
3
1. Лабораторная работа № 1. «Расчет показателей
масштабности»
1.1. Цель работы
Освоение методики определения масштабов программных средств и получение
практических навыков в оценке производительности и качества работы программиста.
1.2. Теоретический минимум
В оценке сроков и стоимости разработки программного проекта выделяют два основных этапа: оценивание размера программы и, опираясь на полученные данные, оценивание трудозатрат и стоимости. При этом трудоемкость разработки в рамках одного класса
решаемых задач практически линейно зависит от масштаба проекта. Организации, сферой
деятельности которых является разработка программ, имеют собственные наработки и
стандарты в методике определения трудоемкости, опирающиеся на опыт выполнения
предыдущих проектов и позволяющие оптимально распределить ресурсы. Важными параметрами в учете ресурсов являются производительность и качество работы отдельных программистов или групп разработчиков, для оценки которых необходим расчет численных
показателей (метрик) программного кода.
В данной лабораторной работе выполняются задачи расчета размерно-ориентированных метрик программы и определения индивидуальных показателей производительности и качества работы программиста.
1.2.1. Метрика SLOC
К размерно-ориентированным метрикам относится метрика строки кода (source
lines of code, SLOC) – совокупное количество строк кода в модулях программы. Различают
физические (physical) и логические (logical) строки кода. Физической строке соответствует
одна строка листинга программы, логической строке соответствует, как правило, один оператор языка программирования. Поскольку один и тот же программный код, даже в рамках
4
одного языка, может быть описан разным количеством физических строк, для оценки трудоемкости используют логические строки кода.
При подсчете показателя SLOC в программах на языках C/C++, С# считаются:
1. Операторы ветвления: if, else if, else, ?, try, catch, switch.
2. Операторы цикла: for, while, do..while. Инициализация, условие и инкремент в заголовке цикла for, фигурные скобки {}, ограничивающие тело цикла, а также закрывающий
оператор цикла разделитель точка с запятой не считаются.
3. Операторы перехода: return, break, goto, exit, continue, throw. Метки, используемые
совместно с оператором goto, не считаются.
4. Прочие операторы, оканчивающиеся точкой с запятой.
5. Разделитель блоков: {}. Пара фигурных скобок считаются как один разделитель.
Фигурные скобки, оканчивающиеся разделителем точка с запятой, не считаются. Фигурные скобки, используемые в операторах ветвления и цикла, также не считаются.
6. Директивы препроцессора.
Для того чтобы оценить масштаб проекта, модули которого написаны на разных языках программирования, необходимо выбрать универсальную единицу измерения и привести к ней объемы этих модулей. Такой единицей может выступать число машинных команд
в объектном коде после трансляции. Коэффициенты перевода зависят от компилятора,
среды разработки и стиля программирования, и должны определяться для каждого разработчика или группы разработчиков на основании опыта предыдущих проектов.
1.2.2. Метрики Холстеда
Еще одной группой размерно-ориентированных метрик являются метрики Холстеда (Halstead complexity measures), в основе методики расчета которых лежат четыре измеряемые характеристики программы:
ƞ1 - число уникальных операторов программы, включая символы-разделители, имена
процедур и знаки операций (словарь операторов);
5
ƞ 2 - число уникальных операндов программы (словарь операндов);
N1 - общее число операторов в программе;
N2 - общее число операндов в программе.
При определении этих характеристик руководствуются следующими правилами:
1. Все переменные и константы считаются операндами.
2. Глобальные переменные и константы, используемые в разных модулях программы, считаются множественными вхождениями одного операнда.
3. Локальные переменные с одинаковыми именами в разных функциях (методах)
считаются уникальными операндами.
4. Циклические конструкции, например, do {…} while (), while () {…}, for () {…},
управляющие конструкции, например, if () {…}, if () {…} else {…}, и т. д., считаются операторами.
5. В управляющей конструкции switch () {case:…}, ключевое слово switch и все вхождения case считаются операторами.
6. Зарезервированные ключевые слова, такие как return, default, continue, break, sizeof
и т. д., считаются операторами.
7. Вызовы функций и методов считаются операторами.
8. Знаки арифметических, логических и поразрядных операций, скобки, запятые и
разделители считаются операторами.
9. Оператор перехода goto считается оператором, а связанная с ним метка - операндом.
10. В обращениях к элементам массива, имя массива и индекс считаются операндами, а квадратные скобки – оператором.
11. В обращениях к полям (свойствам, данным-членам) структур или объектов, имя
экземпляра структуры (объекта) и имя поля считаются операндами, а разделяющий их
6
оператор доступа – оператором. Поля, имеющие одинаковые имена, но принадлежащие разным типам структур или разным классам, считаются уникальными операндами.
12. Комментарии, типы данных, объявления идентификаторов, функций и методов,
а также директивы препроцессора в расчетах не учитываются.
На основании подсчетов операторов и операндов, вычисляют следующие метрики:
Словарь программы (program vocabulary, ƞ) – суммарное количество уникальных
операторов и операндов в программе:
ƞ = ƞ1 + ƞ2
Длина программы (program length, N) – суммарное количество операторов и операндов в программе:
N = N1 + N2
Оценочная длина программы (estimated program length, N̂) – ожидаемая сумма операторов и операндов в программе:
N = ƞ1 ∙ log2 ƞ1 + ƞ2 ∙ log2 ƞ2
Для стилистически корректного кода, расхождение величин длины и оценочной
длины программы не превышает, как правило, 10%.
Объем программы (program volume, V) – размер реализации алгоритма вне зависимости от конкретного языка программирования:
V = N ∙ log ƞ
Сложность программы (program difficulty, D) – мера сложности написания (и понимания) программного кода:
D=
ƞ N
∙
2 ƞ
Трудоемкость написания программы (program effort, E) – суммарное количество
усилий, затрачиваемое на написание программы:
E=V·D
7
Прогноз времени реализации (time required to program, T) – оценка времени (в часах), необходимого для написания программы:
T = E / 64800
Прогноз числа ошибок (тumber of delivered bugs, B) – оценка потенциального количества ошибок, допущенных при реализации кода:
B = V / 3000
1.2.3. Параметры производительности и качества работы программиста
После завершения всех этапов разработки программы, у руководителя проекта набирается достаточно информации для оценки эффективности отдельных разработчиков. В
данной работе будем использовать следующие измеряемые параметры:
Производительность работы программиста (programmer productivity, PP) – отношение количества строк в коде (SLOC) ко времени, затраченному на его разработку (TК):
PP = SLOC / TК
Эффективность обнаружения ошибок (defect detection efficiency, DDE) — отношение количества ошибок, внесенных и обнаруженных в течение одного этапа разработки, к
общему числу ошибок, внесенных на данном этапе:
DDE =
Число ошибок, внесенных и обнаруженных на этапе
∙ 100%
Общее число ошибок, внесенных на этапе
Удельная стоимость кода (СУД) – отношение финансовых затрат на разработку кода
(CК) к количеству строк в нем:
СУД = СК / SLOC
1.3. Порядок выполнения работы
Работа выполняется в пять этапов: анализ, проектирование, кодирование, тестирование и расчет метрик. Для каждого этапа, кроме последнего, необходимо фиксировать время
выполнения этапа и количество обнаруженных ошибок, заполняя таблицу 1.1.
8
Таблица 1.1
Выявлено ошибок этапа
Этап
Время, ч
анализа
проектирования
кодирования
X
X
Анализ
Проектирование
X
Кодирование
Тестирование
Этап анализа:
– получить у преподавателя свой вариант задания;
– осмыслить суть задачи, при необходимости задать преподавателю уточняющие
вопросы;
– выявить функциональные требования к программе;
– определить формат входных и выходных данных.
Этап проектирования:
– разработать алгоритм решения задачи;
– определить типы и структуры хранения данных;
– определить перечень подключаемых библиотек.
Этап кодирования:
– создать проект в среде разработки программ;
– осуществить кодирование модулей;
– скомпилировать исполняемый файл.
Этап тестирования:
– разработать тестовые наборы данных и условия запуска, позволяющие проверить
работы программы на соответствие функциональным требованиям;
9
– осуществить прогон программы по всем тестовым наборам, фиксируя результаты
тестирования;
– в случае обнаружения критической ошибки, препятствующей выполнению тестов
(зависание программы, необработанное исключение), устранить причину ошибки и продолжить тестирование.
Этап расчета метрик:
– рассчитать размерно-ориентированные метрики (SLOC, метрики Холстеда);
– определить параметры производительности и качества работы программиста;
– занести результаты расчета в таблицу 1.2.
Таблица 1.2.
Название параметра
Обозначение
Количество логических строк кода
SLOC
Количество уникальных операторов
ƞ1
Количество уникальных операндов
ƞ2
Общее количество операторов
N1
Общее количество операндов
N2
Словарь программы
ƞ
Длина программы
N
Оценочная длина программы
N
Объем программы
V
Сложность программы
D
Трудоемкость программы
E
Расчетное время реализации
T
Расчетное количество ошибок
B
Время выполнения этапа кодирования
TК
Значение
10
Количество ошибок, внесенных на этапе кодирования
BК
Производительность работы программиста
PP
Эффективность обнаружения ошибок на этапе анализа
DDE1
Эффективность обнаружения ошибок на этапе проектирова-
DDE2
ния
Эффективность обнаружения ошибок на этапе кодирования
Удельная стоимость кода
DDE3
Суд
1.4. Пример выполнения расчетов
Предположим, что перед разработчиком была поставлена задача вывода на экран
консоли суммы элементов главной диагонали квадратной матрицы, заполненной случайными целыми числами.
1.4.1. Анализ
На этапе анализа разработчик выделил следующие функциональные требования к
программе:
– программа должна заполнять квадратную матрицу случайными числами;
– программа должна осуществлять суммирование элементов главной диагонали
матрицы и выводить сумму на экран.
Форматом выходных данных было принято строковое представление целого числа.
При выборе формата входных данных была выявлена ошибка в функциональных
требованиях: не указана необходимость ввода с клавиатуры размера матрицы, которая была
исправлена.
Время выполнения этапа – 6 минут.
1.4.2. Проектирование
11
На этапе проектирования было решено заполнять ячейки матрицы случайными целыми числами с использованием методов класса Random. Были описаны алгоритм заполнения матрицы и алгоритм суммирования элементов главной диагонали.
Обнаружилась ошибка в формате выходных данных, допущенная на этапе анализа:
использование для суммы того же типа данных, что и для слагаемых, может привести к
переполнению.
Время выполнения этапа – 12 минут.
1.4.3. Кодирование
На этапе кодирования, при первичной отладке было выявлено три ошибки в коде и
одна ошибка проектирования в алгоритме заполнения матрицы: число шагов цикла превышает количество ячеек.
Время выполнения этапа – 15 минут.
1.4.4. Тестирование
После компиляции программы было осуществлено ее тестирование, в ходе которого
обнаружилась одна ошибка этапа проектирования: алгоритм предполагал заполнение матрицы положительными числами, тогда как множество целых чисел включает и отрицательные. Кроме того, была обнаружена ошибка этапа кодирования: в коде были перепутаны
индексы строк и столбцов, и вычислялась сумма неглавной диагонали.
Время выполнения этапа – 15 минут.
Таким образом, сводная таблица выполнения этапов разработки принимает вид:
Таблица 1.3
Выявлено ошибок этапа
Этап
Время, ч
анализа
проектирования
кодирования
Анализ
0,1
1
X
X
Проектирование
0,2
1
0
X
Кодирование
0,25
0
1
3
12
Тестирование
0,25
0
1
1
1.4.5. Расчет метрик
Листинг программы имеет вид:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
using System;
namespace Lab01
{
class Program
{
static void Main(string[] args)
{
int n;
long sum = 0;
Random rand = new Random();
Console.Write("Введите размер матрицы: ");
Int32.TryParse(Console.ReadLine(),out n);
int[,] matrix = new int[n, n];
for (int i = 0; i< n; i++)
{
for (int j=0; j<n; j++)
{
matrix[i, j] = rand.Next(1000) - 500;
if (i == j) sum += matrix[i, j];
}
}
Console.WriteLine("Сумма элементов: {0}",sum);
}
}
}
Определим согласно правилам подсчета значение SLOC, занося промежуточные
значения в таблицу:
Таблица 1.4
Оператор
Количество
if
1
for
2
;
8
{}
3
Таким образом, SLOC = 14.
13
Для расчета метрик Холстеда выделим уникальные операторы и операнды и приведем их общее количество.
Таблица 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
"Введите размер матрицы: "
1
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
"Сумма элементов: {0}"
1
Таким образом, ƞ1 = 24, N1 = 71, ƞ2 = 12, N2 = 36.
Рассчитаем метрики.
ƞ = 24 + 12 = 36
N = 71 + 36 = 107
N = 24 ∙ log 24 + 12 ∙ log 12 = 153,06
V = 107 ∙ log 36 = 553,19
D=
24 36
∙
= 36
2 12
E = 553,19 · 36 = 19914,84
T = 19914,84 / 64800 = 0,31 ч
14
B = 553,19 / 3000 = 0,18
TК = 15 / 60 = 0,25 ч
BК = 4
PP = 14 / 0,25 = 56 строк/ч
DDE =
1
∙ 100% = 50%
2
DDE =
0
∙ 100% = 0%
2
DDE =
3
∙ 100% = 75%
4
Для расчета удельной стоимости кода определим величину финансовых затрат исходя из стоимости одного часа работы программиста (условно, 1000 руб.):
СК = TК · 1000 = 250 руб.
Тогда удельная стоимость равна:
Суд = СК / SLOC = 250 / 14 = 17,86 руб. / строку
1.5. Вопросы для самоконтроля
1. Может ли в программе на языке C# количество логических строк превышать количество физических?
2. Будут ли равны по количеству логических строк две одинаковые по функционалу
программы, написанные на разных языках программирования?
3. Будут ли равны по количеству физических строк две одинаковые по функционалу программы, написанные на разных языках программирования?
4. Как изменятся словарь и длина программы (по Холстеду), если весь исходный
код написать дважды подряд?
15
2. Лабораторная работа № 2. «Определение трудозатрат на
разработку»
2.1. Цель работы
Получение практических навыков в оценке трудоемкости разработки программ.
2.2. Теоретический минимум
Для оценки трудоемкости проекта на начальной стадии его разработки размерноориентированные метрики не подходят, поскольку никакой код еще не написан. На этом
этапе можно использовать методику подсчета функциональных указателей (function points,
FP) – численной оценки объема будущей программы, исходя из ее функциональности, различимой на этапе анализа требований. Подсчет регулируется стандартным набором правил, процессов и руководств, определяемых международной группой пользователей функциональных баллов (IFPUG), и включает в себя следующие этапы:
– определение границ приложения и выделение функциональных элементов;
– подсчет элементов данных и определение рангов функциональных элементов;
– расчет количества функциональных указателей.
2.2.1. Определение границ приложения и выделение функциональных элементов
Для корректного применения методики важно правильно определить границу программы – воображаемую линию, отделяющую программу от внешней среды. Для определения этой границы необходимо выделить внешние по отношению к программе сущности
– пользователей или другие программы и проанализировать, какая часть информации находится под контролем программы, а какая – вне ее контроля. Группы данных, хранящиеся
внутри программы или вне её называют файлами, а процессы перемещения данных через
границу - транзакциями.
Различают три вида транзакций: внешний ввод, внешний вывод и внешний запрос, и
два вида файлов: внутренний логический файл и внешний интерфейсный файл (рис 2.1).
16
Рисунок 2.1 Границы и функциональные элементы программы
Внешний ввод (external input, EI) – элементарный процесс переноса данных или
управляющей информации из внешней среды в программу, влияющий на поведение программы или меняющий содержимое внутренних логических файлов.
Внешний вывод (external output, EO) – элементарный процесс переноса данных или
управляющей информации из программы во внешнюю среду, логика работы которого содержит математические расчеты, создает производные данные, влияет на поведение программы или меняет содержимое внутренних логических файлов.
Внешний запрос (external inquiry, EQ) – элементарный процесс переноса данных или
управляющей информации из программы во внешнюю среду, логика работы которого не
содержит математических расчетов, не создает производных данных, не влияет на поведение системы и не меняет содержимого внутренних логических файлов.
Внутренний логический файл (internal logical file, ILF) – распознаваемая пользователем группа логически связанных данных, которая располагается внутри программы и обслуживается через ее транзакции.
Внешний интерфейсный файл (external interface file, EIF) – распознаваемая пользователем группа логически связанных данных, которая располагается внутри другой программы и обслуживается ей.
Транзакции и файлы вместе образуют пять функциональных элементов.
2.2.2. Подсчет элементов данных и определение рангов функциональных элементов
17
Введем необходимые определения.
Элемент данных (data element type, DET) – распознаваемое пользователем уникальное динамическое поле данных.
Запись (record element type, RET) – распознаваемая пользователем подгруппа элементов данных в рамках внутреннего логического или внешнего интерфейсного файла.
Ссылка на файл (file type referenced, FTR) – внутренний логический или внешний
интерфейсный файл, читаемый или записываемый транзакцией.
Каждому функциональному элементу в зависимости от количества элементов данных, числа ссылок на файлы и числа записей присваивается ранг сложности – низкий, средний, или высокий в соответствии с таблицей 2.1.
Таблица 2.1.
Ранг сложности функциональных элементов
Функциональный элемент
Элементов данных
EI
1-4
5-15
>15
1-4
5-19
>19
1-19
20-50
>50
EO, EQ
ILF, EIF
Ссылок на файлы
Записей
Ранг
0-1
0-1
1
Низкий
Низкий
Средний
2
2-3
2-5
Низкий
Средний
Высокий
>2
>3
>5
Средний
Высокий
Высокий
2.2.3. Расчет количества функциональных указателей
Количество функциональных указателей определяется по формуле:
𝐹𝑃 = 𝑆 ∙ (0,65 + 0,01 ∙ ∑
𝐹 ),
где S – сумма транзакций и файлов с учетом весовых коэффициентов, Fi – коэффициенты регулировки сложности.
18
Для вычисления суммы 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 системных параметров, приведенных в приложении А. Каждому коэффициенту присваивается значение в баллах по
шкале от 0 (не имеет значения) до 5 (имеет ключевое значение).
Рассчитав количество функциональных указателей, можно дать оценку размера будущей программы (SLOCˊ), выбрав язык программирования и используя коэффициент пересчета из FP в SLOC по таблице 2.3.
Таблица 2.3
Пересчет FP-оценок в SLOC-оценки
Язык программирования
SLOC/FP
Assembler
119
C
97
C++
50
C#
54
Excel
209
19
HTML
34
Java
53
JavaScript
47
Perl
24
SQL
21
Visual Basic
42
VB.NET
52
Оценку срока (Tˊ) и стоимости (Cˊ) разработки кода можно получить по формулам:
Tˊ = SLOCˊ / PP,
Cˊ = SLOCˊ · Суд,
где PP – производительность работы программиста, Суд – удельная стоимость.
2.3. Порядок выполнения работы
1. Получить у преподавателя свой вариант задания.
2. Определить границы приложения и выделить функциональные элементы.
3. Подсчитать элементы данных и определить ранги функциональных элементов.
4. Рассчитать количество функциональных указателей.
5. Оценить размер программы, сроки и стоимость ее разработки, взяв значения производительности и удельной стоимости из результатов выполнения лабораторной работы
№1.
6. Заполнить таблицу 2.4. результатами расчетов и оформить отчет о выполнении
работы.
Таблица 2.4
Название параметра
Число функциональных указателей
Оценка размера программы
Обозначение
Значение
FP
SLOCˊ
20
Оценка сроков разработки
Tˊ
Оценка стоимости разработки
Cˊ
2.4. Пример выполнения расчетов
Произведем оценку программы «Студенческий офис», функциональными требованиями к которой являются:
– ввод, хранение и вывод данных о студентах (ФИО, пол, дата рождения, группа,
размер стипендии);
– ввод преподавателями ведомостей с оценками;
– хранение и вывод оценок студентов по дисциплинам, вывод среднего балла индивидуально и по группе;
– взаимодействие с бухгалтерской программой для передачи сведений об успеваемости и получения размера стипендии.
2.4.1. Определение границ приложения и выделение функциональных элементов
Исходя из требований к программе, можно выделить следующие внешние по отношению к программе сущности:
– пользователь «сотрудник студенческого офиса»;
– пользователь «преподаватель»;
– внешняя программа «бухгалтерия».
Граница приложения будет проходить по графическому интерфейсу взаимодействия с пользователями и программному интерфейсу взаимодействия с внешней программой (рис. 2.2).
21
Рисунок 2.2 Функциональные элементы программы «студенческий офис»
Различимы следующие файлы:
– внутренние логические файлы «студенты», «группы», «оценки»;
– внешний интерфейсный файл «стипендии».
Различимы следующие транзакции:
– внешние вводы «данные студента» и «ведомости»;
– внешний вывод «успеваемость»;
– внешние запросы «карточка студента», «карточка группы», «запрос стипендии».
2.4.2. Подсчет элементов данных и определение рангов функциональных элементов
Различимыми элементами данных во внутреннем логическом файле «студенты» являются: «идентификатор студента», «фамилия», «имя», «отчество», «пол», «дата рождения», «размер стипендии». Эти данные можно логически разделить на две группы: «персональные данные» и «финансовая информация». Таким образом, файл «студенты» имеет 7
элементов данных и 2 записи. Согласно таблице 2.1, такой файл имеет низкий ранг.
Различимыми элементами данных во внутреннем логическом файле «группы» являются: «идентификатор группы», «название группы», «идентификатор студента». Все элементы являются частью одной записи. Таким образом, файл «группы» имеет низкий ранг.
В файле «оценки» различимы элементы данных: «идентификатор записи», «идентификатор студента», «дисциплина», «дата», «балл», образующие одну запись. Ранг файла –
низкий.
22
Во внешнем интерфейсном файле «стипендии» различимы элементы данных: «минимальный балл», «величина стипендии», образующие одну запись. Ранг файла – низкий.
Внешний ввод «данные студента» оперирует элементами данных: «идентификатор
студента», «фамилия», «имя», «отчество», «пол», «дата рождения», «идентификатор
группы», «название группы» и ссылается на два внутренних логических файла: «студенты»
и «группы». Имеем восемь элементов данных и две ссылки на файлы. Ранг внешнего ввода
«данные студента» по таблице 2.1 - средний.
Внешний ввод «ведомости» оперирует четырьмя элементами данных: «идентификатор студента», «дисциплина», «дата», «балл» и изменяет один внутренний логический файл
«оценки». Ранг – низкий.
Внешний вывод «успеваемость» затрагивает три внутренних логических файла:
«студенты», «группы» и «оценки» и оперирует семью элементами данных: «идентификатор
студента», «фамилия», «имя», «идентификатор группы», «название группы», «балл по дисциплине», «средний балл». Ранг – средний.
Внешний запрос «карточка студента» выводит все данные, связанные со студентом,
его успеваемостью и стипендией из трех внутренних логических файлов. Ранг – средний.
Ранг внешних запросов «карточка группы» и «запрос стипендии» - низкий.
2.4.3. Расчет количества функциональных указателей
По таблице 2.2 определяем весовые коэффициенты функциональных элементов и
сводим результаты в таблицу 2.5.
Таблица 2.5.
Весовой
Функциональный элемент
Тип элемента
Ранг
коэффициент
«Студенты»
ILF
низкий
7
«Группы»
ILF
низкий
7
«Оценки»
ILF
низкий
7
23
«Стипендии»
EIF
низкий
5
«Данные студента»
EI
средний
4
«Ведомости»
EI
низкий
3
«Успеваемость»
EO
средний
5
«Карточка студента»
EQ
средний
4
«Карточка группы»
EQ
низкий
3
«Запрос стипендии»
EQ
низкий
3
Сумма транзакций и файлов с учетом весовых коэффициентов:
S = 7 · 3 + 5 · 2 + 4 · 2 + 3 · 3 = 48
Из таблицы в приложении А выбираем те системные параметры, влияние которых
оценивается выше нуля баллов:
Таблица 2.6.
Системный параметр
оценка
Обоснование
Передача данных
1
Требуется обмен данными с бухгалтерией
Эффективность работы конеч-
1
Подразумевается наличие меню и бумажной
ного пользователя
версии пользовательской документации.
Определим итоговое количество функциональных указателей:
𝐹𝑃 = 𝑆 × 0,65 + 0,01 ×
𝐹
= 32,16
Оценочный размер программы на языке C#, с учетом коэффициента из таблицы 2.3:
SLOCˊ = 32,16 · 54 = 1737 строк
Для оценки срока и стоимости разработки, воспользуемся значениями производительности и удельной стоимости, полученными в примере к лабораторной работе №1:
Tˊ = SLOCˊ / PP = 1737 / 56 = 31 час,
Cˊ = SLOCˊ · Суд = 1737 · 17,86 = 31023 руб.
24
2.5. Вопросы для самоконтроля
1. В чем различие функциональных элементов «внешний вывод» и «внешний запрос»?
2. Где по отношению к границе программы находится внутренний логический
файл?
3. Где по отношению к границе программы находится внешний интерфейсный
файл?
4. Как связаны количество функциональных указателей и количество строк кода?
5. Чем определяется ранг сложности функционального элемента?
25
3. Лабораторная работа № 3. «Разработка графических
спецификаций»
3.1. Цель работы
Получение практических навыков в оформлении спецификаций этапа анализа требований.
3.2. Теоретический минимум
Анализ требований к разрабатываемому программному обеспечению завершается
разработкой спецификаций - формализованного описания функций и ограничений программы, отвечающего требованиям полноты и точности.
Под полнотой подразумевается описание всех существенных для данной стадии
проектирования функций и ограничений.
Под точностью подразумевается описание спецификаций в форме, исключающей
неоднозначную трактовку.
Обеспечить соблюдение перечисленных требований позволяет только строго формализованная модель программного обеспечения. В зависимости от подхода к разработке
могут быть использованы различные модели и нотации.
В данной работе рассмотрены следующие виды диаграмм: вариантов использования, переходов состояний, потоков данных.
3.2.1. Диаграмма вариантов использования
Диаграмма вариантов использования (диаграмма прецедентов, Use Case diagram)
предназначена для определения функциональных требований и позволяет наглядно описать
предоставляемые программой сервисы. Основные элементы диаграммы приведены на рис.
3.1.
26
Рисунок 3.1 Элементы диаграммы вариантов использования
а) Действующее лицо (actor) – внешняя по отношению к программе сущность, взаимодействующая с программой, или использующая ее сервисы;
б) Вариант использования (прецедент, Use Case) – очевидная для действующего
лица процедура, решающая конкретную задачу;
в) Связь (ассоциация, association) – взаимодействие действующего лица с вариантом использования;
г) Расширение (extend) – добавление альтернативного функционала в основной вариант использования;
д) Включение (include) – задействование функционала как неотъемлемой части основного варианта использования;
е) Наследование (generalization) – копирование потомком всех атрибутов и поведения предка.
3.2.2. Диаграмма переходов состояний
Диаграмма переходов состояний (UML state machine) – графическая модель, описывающая возможные состояния программы и переходы из одного состояния в другое.
Для построения диаграмм используются условные обозначения, показанные на рисунке 3.2.
27
Рисунок 3.2 Элементы диаграммы переходов состояний
а) Начальное псевдосостояние (initial pseudostate) – точка старта (может быть
только одна);
б) Конечное состояние (final state) – точка завершения (может быть несколько или
ни одной);
в) Простое состояние (simple state) – состояние, не имеющее регионов и вложенных состояний (может иметь внутренние действия);
г) Составное состояние (composite state) – состояние, имеющее один или более регионов со вложенными состояниями;
д) Переход (transition) – направленная связь между двумя состояниями, может содержать необязательные элементы:
триггеры – перечень событий, приводящих к переходу;
охранное выражение – логическое условие, разрешающее переход;
действия – операции, совершаемые при переходе;
е) Выбор (choice) – псевдосостояние, реализующее условный переход.
3.2.3. Диаграмма потоков данных
Диаграмма потоков данных (data flow diagram) – графическая модель системы, описывающая хранение, обработку и передачу данных.
Для построения диаграмм используются условные обозначения, показанные на рисунке 3.3.
28
Рисунок 3.3 Элементы диаграммы потоков данных
а) Внешняя сущность (external entity) – объект, не входящий в систему, но являющийся источником и/или получателем её данных;
б) Процесс (process) – функция обработки данных;
в) Хранилище (data storage) – внутреннее хранилище данных в системе;
г) Поток (data flow) – направленное движение данных.
Чтобы сделать диаграмму более читаемой, ее разбивают на несколько уровней. Самым верхним в иерархии уровней является контекстный (нулевой), на котором отражены:
программа (одним процессом), внешние сущности, и потоки данных между ними. На следующем (первом) уровне программа декомпозируется на несколько процессов, появляются
внутренние потоки и хранилища данных. На втором уровне процессы могут разбиваться на
подпроцессы и так далее, до тех пор, пока не будет достигнут требуемый уровень детализации. Процедуры контекстного уровня имеют номера 1, 2, 3 и т. д. Процедуры первого
уровня имеют номера, производные от процедур нулевого, например: 1.1, 1.2, 2.1, 2.2, 2.3.
Процедуры второго уровня – производные от первого, например: 1.1.1, 2.3.5, и так далее.
3.3. Порядок выполнения работы
1. Получить у преподавателя свой вариант задания.
2. Определить внешние сущности, состояния программы, выполняемые ею функции
и данные, которые она обрабатывает.
3. Построить диаграмму вариантов использования.
4. Построить диаграмму переходов состояний.
5. Построить потоков данных.
6. Оформить отчет о выполненной работе.
29
3.4. Пример выполнения работы
Построение диаграмм рассмотрим на примере программы-клиента корпоративной
почты, требования к которой описаны заказчиком следующим образом:
«Сотрудники организации должны иметь возможность отправлять друг другу
письма, прикреплять документы и вставлять фотографии. Руководители подразделений
могут делать массовые рассылки в пределах подразделения».
3.4.1. Построение диаграммы вариантов использования
Действующими лицами являются: «сотрудник» и «руководитель». «Руководитель»
имеет доступ ко всем сервисам «сотрудника», а также к дополнительному сервису «массовая рассылка», поэтому он является наследником действующего лица «сотрудник».
Вариантами использования являются: «проверка почты», «чтение письма», «отправка письма», «массовая рассылка». Поскольку почтовая программа должна различать
пользователей, добавляется вариант «авторизация».
Вложение документа и вставка фотографии – это дополнительный функционал отправки, поэтому оформляются как вспомогательные варианты использования со связью
«расширение».
Чтение писем включает проверку почты, а массовая рассылка – отправку писем, поэтому между этими вариантами устанавливается связь «включение».
Результат построения диаграммы приведен на рис. 3.4.
30
Рисунок 3.4 Диаграмма вариантов использования для почтовой программы
3.4.2. Построение диаграммы переходов состояний
Различимые пользователем состояния, в которых может находиться программа
начиная с момента её запуска: «авторизация», «проверка почты», «ожидание», «чтение
письма», «редактирование письма», «выбор файла», «отправка письма».
Авторизация может завершиться успешно (при корректном пароле), либо с ошибкой.
в случае ошибки процесс авторизации повторяется.
Проверка почты включает в себя вложенные состояния (отправку на сервер запроса
о наличии новых писем, их загрузку), поэтому отображается составным состоянием.
Результат построения приведен на рисунке 3.5.
31
Рисунок 3.5 Диаграмма переходов состояний для почтовой программы
3.4.3. Построение диаграммы потоков данных
Анализируя функциональные возможности и поведение программы по диаграммам
вариантов использования и переходов состояний, выделим:
1. Внешние сущности: «пользователь», «почтовый сервер».
2. Виды данных: «логины», «письма», «адреса», «файлы».
3. Хранилища: «входящие письма», «исходящие письма», «адресная книга»,
«файлы».
Декомпозируем виды данных на отдельные элементы:
1. Логин: «имя пользователя», «пароль».
2. Письмо: «id письма», «тема письма», «текст письма», «адрес отправителя», «адреса получателей», «вложения».
3. Арес: «подразделение», «адресат», «e-mail».
4. Файл: «имя файла», «содержимое файла».
Построим диаграмму потоков данных на контекстном уровне.
32
Рисунок 3.6 Потоки данных почтовой программы (контекстный уровень)
На первом уровне диаграммы выделим основные процедуры.
Рисунок 3.7 Потоки данных почтовой программы (первый уровень)
На втором уровне диаграммы опишем содержание процедуры «Отправка письма».
33
Рисунок 3.8 Потоки данных в процедуре «Отправка письма» (второй уровень)
3.5. Вопросы для самоконтроля
1. Может ли программа быть действующим лицом на диаграмме вариантов использования?
2. В чем принципиальное различие между связями «расширение» и «включение»
диаграммы вариантов использования?
3. Как будет выглядеть диаграмма переходов состояний уличного светофора?
4. На диаграмме потоков данных для процедуры 1.2 показаны три вложенные процедуры. Какие номера они будут иметь?
5. Показывает ли диаграмма потоков данных очередность выполнения процедур?
34
35
4. Лабораторная работа № 4. «Определение связности класса»
4.1. Цель работы
Получение практических навыков в оценке связности класса по данным.
4.2. Теоретический минимум
Связность класса (class cohesion) – это взаимозависимость компонентов класса. Под
компонентами класса подразумеваются поля и методы, определенные в классе, а также унаследованные от классов-предков.
Метод класса связан с полем класса, если он обращается к этому полю напрямую,
или через вызовы других методов.
Два метода класса прямо связанны между собой, если оба метода связаны с одним и
тем же полем класса.
Два метода класса косвенно связанны между собой, если они не связаны прямо, но
между ними можно построить маршрут из прямо связанных методов.
Обычно конструкторам доступны все поля класса, то есть, они создают косвенные
соединения между никак не связанными методами, поэтому ни конструкторы, ни деструкторы в расчетах связности не учитываются. Непубличные методы также не учитываются.
На диаграмме отношений компонентов класса (рис. 4.1) публичные методы обозначены прямоугольниками, поля – эллипсами, связи «метод – поле» – сплошными линиями, а
«конструктор/деструктор – поле» – пунктиром.
Рисунок 4.1 Диаграмма отношений компонентов класса
Методы m1 и m2 прямо связаны через поле a.
36
Методы m2 и m3 прямо связаны через поле b.
Методы m1 и m3 косвенно связаны через метод m2.
Построив связи между методами, определяют три характеристики связности:
NP – максимально возможное количество связей между N методами:
NP = N · (N – 1) / 2
NDC – количество прямых связей между методами.
NIC – количество прямых и косвенных связей между методами.
Далее рассчитываются метрики связности:
Сильная связность класса (tight class cohesion, TCC):
TCC = NDC / NP
Слабая связность класса (loose class cohesion, LCC):
LCC = NIC / NP
4.3. Порядок выполнения работы
1. Получить у преподавателя свой вариант задания.
2. Реализовать класс, решающий поставленные задачи.
3. Построить диаграмму отношений компонентов класса.
4. Определить количество прямых и косвенных связей между методами.
5. Рассчитать метрики связности.
6. Оформить отчет о выполненной работе.
4.4. Пример выполнения расчетов
На листинге представлен код класса Rectangle:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
class Rectangle
{
private int x1, x2, y1, y2, color;
public Rectangle (int _x1, int _x2, int _y1, int _y2, int _color)
{
x1 = _x1; y1 = _y1; x2 = _x2; y2 = _y2; color = _color;
}
public int Width()
{
return x2 - x1;
}
public int Height()
{
return y2 - y1;
37
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
}
public int Square()
{
return Width() * Height();
}
public int GetColor()
{
return color;
}
}
Класс имеет пять полей и пять открытых методов (не учитывая конструктор).
Построим диаграмму отношений компонентов класса Rectangle (рис. 4.2).
Рисунок 4.2 Диаграмма отношений компонентов класса Rectangle
Метод Width связан с полями x1 и x2 через обращение к ним.
Метод Height связан с полями y1 и y2 через обращение к ним.
Метод Square связан с полями x1 и x2 через вызов метода Width, а с полями y1 и y2 –
через вызов метода Height.
Метод GetColor связан с полем color через обращение к нему.
Определим характеристики связности.
Количество открытых методов (за исключением конструктора):
N=4
Максимально возможное количество связей:
NP = 4 · (4 – 1) / 2 = 6
Прямые связи между методами (Width – Square через поля x1, x2 и Square – Height
через поля y1, y2):
NDC = 2
38
Косвенные связи между методами (Width – Height через метод Square):
NIC = 1
Рассчитаем метрики связности.
TCC = NDC / NP = 2 / 6 = 0,33
LCC = NIC / NP = 1 / 6 = 0,17
4.5. Вопросы для самоконтроля
1. Может ли связность класса-потомка быть выше связности класса-предка?
2. В каких диапазонах находятся значения метрик TCC и LCC?
3. Почему конструкторы класса не учитываются в расчете характеристики NP?
4. Приведите пример класса с сильной связностью равной 0,5.
5. Приведите пример класса со слабой связностью равной 0.
39
5. Лабораторная работа № 5. «Структурное тестирование»
5.1. Цель работы
Освоение методики тестирования базового пути.
5.2. Теоретический минимум
Тестирование – процесс выполнения программы с целью обнаружения ошибок.
Тест – совокупность исходных данных, условия запуска программы и ожидаемый
результат.
Исчерпывающим называется тестирование, обеспечивающее проверку безошибочной работы программы для всех вариантов входных данных и всех ветвей вычислений. Проведение исчерпывающего тестирования в реальных условиях, как правило, невозможно изза огромного количества комбинаций входных данных, поэтому перед проектировщиком
тестов стоит задача выбора ограниченного набора тестов с максимальной вероятностью
приводящих к обнаружению ошибки.
Успешным называется тест, обнаруживший ранее не раскрытую ошибку.
Рассматривают два основных подхода к тестированию:
Функциональное тестирование (тестирование с управлением по вводу/выводу) –
программа рассматривается как «черный ящик», тестовые наборы строятся только на основании функциональных требований, без учета знаний о внутренней структуре.
Структурное тестирование (тестирование, управляемое логикой программы или
тестирование «белого ящика») – подразумевает анализ внутренних элементов программы
и логики их взаимодействия.
В данной лабораторной работе рассматривается одна из методик структурного тестирования, разработанная Томасом Дж. МакКейбом (Thomas J. McCabe) – Тестирование
базового пути.
Алгоритм применения методики заключается в следующем:
1. Для заданной программы строится потоковый граф.
40
2. По потоковому графу определяется цикломатическая сложность программы и выделяется базовое множество линейно независимых маршрутов.
3. Разрабатываются тесты (наборы входных данных и ожидаемых результатов), обеспечивающие однократную проверку каждого маршрута базового множества. Количество таких тестов равно цикломатической сложности программы.
4. Осуществляется прогон программы по разработанным тестам, при этом реально полученные результаты сопоставляются с ожидаемыми.
Потоковый граф (control-flow graph) – множество всех возможных путей выполнения программы, представленное в виде направленного графа.
Цикломатическая сложность (сyclomatic complexity) – количество линейно независимых маршрутов в потоковом графе.
Линейно независимый маршрут (linearly independent path) – путь, включающий по
крайней мере одно ребро, не находящееся ни в одном из других путей.
При построении потокового графа следует придерживаться следующих правил:
1. Потоковый граф должен иметь строго один входной узел и строго один выходной
узел. Граф, не имеющий входного узла, описывает недостижимый код. Граф, не имеющий
выходного узла, описывает бесконечный цикл.
2. Последовательный участок программного кода, не содержащий операторов ветвления и цикла, а также меток перехода из других участков кода, представляется простым
узлом потокового графа, имеющим строго одну исходящую дугу.
3. Оператор ветвления или цикла преобразуется в предикатный узел, имеющий
строго две исходящие дуги.
4. Составные условия и множественные ветвления преобразуются в цепочку предикатных узлов.
Пример корректного потокового графа приведен на рисунке 5.1.
41
Рисунок 5.1 Потоковый граф программы
Узел 1 является входным, узел 7 – выходным. Узлы 2,3,5 – предикатные.
Цикломатическая сложность V(G) графа G, имеющего e дуг и n узлов может быть
определена по формуле:
V(G) = e – n + 2
Второй способ определения цикломатической сложности – по числу p предикатных
узлов графа G:
V(G) = p + 1
Третий способ: цикломатическая сложность равна количеству R регионов графа. На
рисунке 5.2 показаны четыре региона графа – R1, R2, R3, R4.
Рисунок 5.2 Регионы потокового графа
Цикломатическая сложность потокового графа равна:
V(G) = e – n + 2 = 9 – 7 + 2 = 4
42
V(G) = p + 1 = 3 + 1 = 4
V(G) = R = 4
Следовательно, потоковый граф имеет 4 базовых маршрута:
Таблица 5.1.
№ маршрута
Маршрут (последовательность узлов)
1
1–2–4–7
2
1–2–3–6–7
3
1–2–3–5–7
4
1–2–3–5–2–4–7
Номера маршрутов, соответствующие им входные данные, условия запуска и ожидаемые результаты заносят в первые три столбца таблицы тестирования:
Таблица 5.2.
Входные данные и
№
Ожидаемый результат
Полученный результат
Вывод
условия запуска
После прогона программы по всем маршрутам, в четвертый столбец заносят полученные результаты, а в пятом – вывод («тест пройден» / «тест не пройден»).
5.3. Порядок выполнения работы
1. Получить у преподавателя свой вариант задания.
2. Реализовать метод класса, решающий поставленную задачу.
3. Построить потоковый граф метода, определить его цикломатическую сложность.
4. Выделить базовые маршруты, разработать тестовые варианты.
5. Осуществить тестирование программы и заполнить таблицу 5.2.
6. Оформить отчет о выполненной работе.
5.4. Пример выполнения работы
43
Метод класса, который необходимо протестировать, должен складывать, вычитать,
умножать или делить два целых числа, введенных с клавиатуры, и выводить результат на
экран консоли.
На листинге представлен код метода.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
void Calculator()
{
Console.Write("Введите х: ");
int x = Convert.ToInt32(Console.ReadLine());
Console.Write("Выберите операцию [+, -, *, /]: ");
char operation = Convert.ToChar(Console.ReadLine());
Console.Write("Введите y: ");
int y = Convert.ToInt32(Console.ReadLine());
string s = x.ToString() + operation + y.ToString()+"=";
string result = "";
if (operation == '/' && y == 0)
{
result = "ошибка деления на ноль";
}
else
{
switch (operation)
{
case '+': result = (x + y).ToString(); break;
case '-': result = (x - y).ToString(); break;
case '*': result = (x - y).ToString(); break;
case '/': result = (x / y).ToString(); break;
default: result = "ошибочная операция"; break;
}
}
Console.WriteLine(s + result);
Console.ReadKey();
}
Код преобразуется в потоковый граф, приведенный на рисунке 5.3.
Рисунок 5.3 Потоковый граф метода Calculator
44
Линейные участки кода преобразуются в узлы: 1 (строки 1..10), 7 (строки 12..14), 5
(строка 19), 8 (строка 20), 10 (строка 21), 12 (строка 22), 13 (строка 23), 14 (строки 24..28).
Условный оператор if в строке 11 является составным (проверяется два независимых
условия), поэтому он преобразуется в два предикатных узла – 2 и 4.
Оператор множественного выбора switch преобразуется цепочку из четырех предикатных узлов: 3, 6, 9, 11.
Цикломатическая сложность метода:
V(Calculator) = e – n + 2 = 19 – 14 + 2 = 7
V(Calculator) = p + 1 = 6 + 1 = 7
V(Calculator) = R = 7
Выделим базовые маршруты:
Таблица 5.3.
№ маршрута
Маршрут (последовательность узлов)
1
1 – 2 – 4 – 7 – 14
2
1 – 2 – 3 – 5 – 14
3
1 – 2 – 4 – 3 – 5 – 14
4
1 – 2 – 3 – 6 – 8 – 14
5
1 – 2 – 3 – 6 – 9 – 10 – 14
6
1 – 2 – 3 – 6 – 9 – 11 – 12 – 14
7
1 – 2 – 3 – 6 – 9 – 11 – 13 – 14
Подберем значения входных данных под каждый из маршрутов и определим ожидаемый результат:
Таблица 5.4.
Входные данные
№ теста
Ожидаемый результат
x
operation
y
1
5
/
0
ошибка деления на ноль
2
24
/
12
2
45
3
0
+
3
3
4
1
-
10
-9
5
4
*
-6
-24
6
15
/
2
7,5
7
250
%
8
ошибочная операция
Внесем данные в левую часть таблицы тестирования и выполним тесты, заполняя
правую часть. В итоге таблица тестирования примет вид:
Таблица 5.5.
Входные данные
Ожидаемый
Полученный
результат
результат
ошибка деления
ошибка деления
на ноль
на ноль
№
Вывод
x
1
5
operation
/
y
0
+
2
24
/
12
2
2
+
3
0
+
3
3
3
+
4
1
-
10
-9
-9
+
5
4
*
-6
-24
10
-
6
15
/
2
7,5
7
-
ошибочная
ошибочная
операция
операция
7
250
%
8
+
Тесты 5 и 6 не пройдены. Находим в таблице 5.3 узлы, отличающие маршруты 5 и 6
от остальных маршрутов множества. Это узлы 10 и 12, соответствующие строкам кода 21 и
22. Анализируя эти строки, находим причины ошибок:
– в строке 21 выполняется операция вычитания, вместо умножения;
– в строке 22 выполняется целочисленное деление.
5.5. Вопросы для самоконтроля
1. Какой из трех способов определения цикломатической сложности позволяет рассчитать без построения потокового графа, имея только код программы?
46
2. Какие узлы в строке 3 таблицы 6.3 можно заменить на другие, не разрушив базовый набор?
3. Какие из значений входных данных в таблице 6.4 можно изменить, сохранив при
этом маршруты?
4. Почему оператор switch отображается в несколько узлов потокового графа?
5. Как таблица результатов тестирования помогает локализовать источник ошибки?
47
6. Лабораторная работа № 6. «Функциональное тестирование»
6.1. Цель работы
Получение практических навыков в тестировании программ по принципу «черного
ящика».
6.2. Теоретический минимум
Функциональное тестирование (тестирование «черного ящика») позволяет получить
наборы входных данных, обеспечивающие исчерпывающую проверку программы на соответствие функциональным требованиям. Программа рассматривается здесь как «черный
ящик», внутренняя реализация которого скрыта, доступны для исследования лишь информационные входы и выходы.
Рисунок 6.1 Представление программы в виде «черного ящика»
Проведение исчерпывающего тестирования предполагает выполнение программы
на всех возможных комбинациях входных данных и их последовательностей. Очевидно,
что почти для всех реальных программ проведение исчерпывающего тестирования невозможно. В большинстве случаев подбирают разумное количество тестов, позволяющих с
большой вероятностью выявить:
– при каких наборах входных данных проявляются аномалии в работе программы;
– какие наборы выходных данных демонстрируют дефекты в работе программы.
Рассмотрим три общепринятые методики получения тестовых данных: эквивалентное разбиение, анализ граничных значений и граф причинно-следственных связей.
6.2.1. Методика эквивалентного разбиения
48
Методика предполагает разбиение области входных данных на конечное число
групп – классов эквивалентности.
Класс эквивалентности (equivalence class)– это такие комбинации наборов входных
данных, обрабатывая которые программа ведет себя одинаково.
Достаточно протестировать программу на одном наборе входных данных, чтобы судить о ее поведении на всем классе эквивалентности. Таким образом, разработав по одному
тесту для каждого класса, можно получить набор тестов, обеспечивающих «разумное» тестирование.
Классы эквивалентности формируются согласно спецификациям по следующим
правилам:
1. Если входной параметр x может принимать значения на отрезке n…m, то формируют три класса:
– допустимый:
𝑥 ∈ {𝑛. . . 𝑚};
– недопустимый:
x < n;
– недопустимый:
x > m.
2. Если входной параметр x может принимать значение из множества {n, m, p}, то
формируют два класса:
– допустимый:
𝑥 ∈ {𝑛, 𝑚, 𝑝};
– недопустимый:
𝑥 ∉ {𝑛, 𝑚, 𝑝};
3. Если есть основания считать, что различные элементы одного класса могут обрабатываться программой по-разному, то такой класс разбивается на меньшие классы эквивалентности.
Определив классы эквивалентности для всех входных параметров, получают перечень допустимых и недопустимых классов и заносят их в таблицу 6.1.
Таблица 6.1.
№
Входной параметр
Допустимые классы
Недопустимые классы
49
Тестовые наборы формируют таким образом, чтобы максимально компактно сгруппировать допустимые классы, при этом только одно значение в наборе может принадлежать недопустимому классу.
6.2.2. Методика граничных значений
Граничными называют значения на границах классов эквивалентности или около
них. Большую часть ошибок можно обнаружить, анализируя именно граничные значения.
Правила применения методики:
1. Если входной параметр x может принимать значения на отрезке n…m, то тесты
должны быть построены:
– для значений n и m;
– для значений чуть меньших n и чуть больших m.
2. Если входной параметр x может принимать значение из множества {n, m, p}, то
тесты должны быть построены:
– для проверки минимального значения (n);
– для проверки максимального значения (p);
– для значений чуть меньших n и чуть больших p.
3. Если входными параметрами являются упорядоченные множества (массивы, линейные списки, последовательные файлы), то тесты строятся для первого и последнего элементов этого множества, а также, для элементов с индексами на 1 меньше первого и на 1
больше последнего.
Определив граничные значения для всех входных параметров, получают перечень
допустимых и недопустимых значений и заносят их в таблицу 6.2.
Таблица 6.2.
№
Допустимые граничные
Недопустимые граничные
значения
значения
Входной параметр
50
Тестовые наборы формируют с тем же условием, что и при эквивалентном разбиении: максимально группируя допустимые значения, и выбирая не больше одного недопустимого значения на тест.
6.2.3. Методика причин-следствий
Граф причинно-следственных связей – использующее алгебру логики описание взаимосвязи причин и следствий в виде графа, где каждый узел может находиться только в
одном из двух состояний: 1 (истина, true) или 0 (ложь, false).
Причиной называют узел графа, соответствующий входному условию или классу эквивалентности.
Следствием называют узел графа, соответствующий действию или выходному условию.
Методика формирования тестовых вариантов включает в себя следующие шаги:
1. Для каждого модуля перечисляют причины и следствия, каждой причине и следствию назначают уникальный идентификатор. Причины обозначают символами ci, следствия – символами ei.
2. Используя базовые символы, приведенные на рис. 6.2, путем соединения причин
и вытекающих из них следствий, строится граф причинно-следственных связей.
51
Рисунок 6.2 Символы графа причинно-следственных связей
а) тождество – если причина c истинна, то и следствие e истинно, и наоборот, если
ложна причина, то ложно и следствие;
б) функция «не» – если причина c истинна, то и следствие e ложно, и наоборот, если
ложна причина, то следствие истинно;
в) функция «или» – следствие e истинно, если истинна одна хотя бы одна из причин
c1 или c2, в противном случае следствие ложно;
г) функция «и» – следствие e истинно, если истинны обе причины c1 и c2, в противном
случае следствие ложно;
д) ограничение «исключает» – истинность одной из причин c1 или c2 исключает истинность другой;
е) ограничение «включает» – как минимум одна из причин c1, c2 или c3 должна быть
истинной;
ж) ограничение «только одно» – одна и только одна причина c1, или c2 истинна;
з) ограничение «требует» – если причина c1 истинна, то и причина c2 должна быть
истинной;
52
и) ограничение «скрывает» – если следствие e1 истинно, то следствие e2 должно
стать ложным.
3. Граф причинно-следственных связей преобразуют в таблицу решений (табл. 6.3),
строки в которой соответствуют причинам и следствиям графа, а столбцы – решениям (уникальным комбинациям состояний причин), приводящим каждое из следствий в истинное
состояние.
Таблица 6.3.
Решения
Причины
1
2
3
4
5
…
c1
c2
…
Следствия
e1
e2
…
4. Для каждого столбца таблицы решений формируют тестовый вариант таким образом, чтобы значения входных параметров соответствовали состояниям соответствующих
причин. Граф причинно-следственных связей преобразуют в таблицу решений (табл. 6.3),
строки в которой соответствуют причинам и следствиям графа, а столбцы – решениям (уникальным комбинациям состояний причин), приводящим одно из следствий в истинное состояние.
6.3. Порядок выполнения работы
1. Получить у преподавателя свой вариант задания.
2. Написать программу, решающую поставленную задачу, не проверяя корректность
ее работы.
53
3. Выделить входные и выходные параметры.
4. Входные параметры разбить на классы эквивалентности, заполнить таблицу 6.1.
5. Определить граничные значения входных параметров, заполнить таблицу 6.2.
6. Построить граф причинно-следственных связей, заполнить таблицу 6.3.
7. По данным из таблиц 6.1, 6.2 и 6.3 сформировать тестовые варианты, заполняя
первые три столбца таблицы 6.4.
Таблица 6.4.
Входные данные и
№
Ожидаемый результат
Полученный результат
Вывод
условия запуска
9. Осуществить прогон программы по всем тестам, заполняя правую часть таблицы
6.4
10. Оформить отчет о выполненной работе.
6.4. Пример выполнения работы
Протестируем форму расчета стоимости года обучения в коммерческом вузе. Правила расчета звучат в техническом задании следующим образом:
«К обучению на платной основе допускаются лица, достигшие 18-летнего возраста. Срок обучения составляет 5 лет. Стоимость обучения на первом курсе – 40000
рублей в год, на последующих курсах – 20000 рублей в год. Пенсионерам (мужчинам старше
60 лет и женщинам старше 55 лет) – скидка 50%».
Внешний вид формы приведен на рис. 6.3.
54
Рисунок 6.3 Форма расчета стоимости года обучения
Поля для ввода данных представляют собой простые текстовые поля (TextBox), результат расчета выводится во всплывающем диалоговом окне при нажатии на кнопку «рассчитать».
Введем обозначения для входных и выходных параметров:
Таблица 6.5.
№
Обозначение
Тип параметра
Тип данных
Описание
1
age
входной
целое число
возраст
2
sex
входной
строка
пол
3
year
входной
целое число
год обучения (курс)
4
cost
выходной
целое число
стоимость обучения
Тестовые варианты будем формировать по трем описанным выше методикам.
6.4.1. Эквивалентное разбиение
Анализ требований показывает, что диапазон значений параметра age имеет особые
точки: 18, 55 и 60. Разобьем числовую ось по этим точкам на диапазоны и обозначим знаком
«+» значения и диапазоны, а знаком «-» – недопустимые.
Рисунок 6.4 Диапазоны эквивалентности параметра age
Формируются четыре класса эквивалентности:
– недопустимый:
age < 18;
– допустимый:
18 ≤ age < 55;
– допустимый:
55 ≤ age < 60;
– допустимый:
age ≥ 60.
Параметр sex может принимать значения: «М», «Ж», «Мужской», «Женский». Следовательно, классы эквивалентности формируются по правилу для множества:
– допустимый:
𝑠𝑒𝑥 ∈ {М, Ж, Мужской, Женский};
55
– недопустимый:
𝑠𝑒𝑥 ∉ {М, Ж, Мужской, Женский}.
Параметр year может принимать значения от 1 до 5 включительно, разбивая числовую ось на три диапазона:
Рисунок 6.5 Диапазоны эквивалентности параметра year
Формируются три класса эквивалентности:
– недопустимый:
year < 1;
– допустимый:
1 ≤ year ≤ 5;
– недопустимый:
year > 5.
Для формирования таблицы тестов выберем конкретные значения из каждого класса.
Таблица 6.6.
Входные данные
№ теста
Ожидаемый результат
age
sex
year
1
5
«М»
2
некорректный возраст
2
25
«П»
3
некорректный пол
3
57
«Женский»
0
некорректный курс
4
75
«Мужской»
10
некорректный курс
5
19
«Ж»
1
cost = 4000
6
58
«М»
2
cost = 2000
7
65
«Женский»
5
cost = 1000
6.4.2. Граничные значения
Согласно правилам применения методики, для параметра age тесты должны быть
построены для граничных значений допустимых классов (18, 55, 60), для значений чуть
меньше минимальных границ (17, 54), а также для значений чуть больше максимальных
границ (56, 61). Расположим все значения на числовой оси и расставим знаки допустимости:
56
Рисунок 6.6 Граничные значения параметра age
Для параметра sex множество значений не является ни числовым, ни упорядоченным, поэтому при построении тестов будем брать любое допустимое значение.
Для параметра year тесты должны быть построены для граничных значений (1, 5), и
для значения чуть меньше нижней и чуть больше верхней границы (0, 6). Отобразим значения на числовой оси:
Рисунок 6.7 Граничные значения параметра year
Сформируем таблицу тестов.
Таблица 6.7.
Входные данные
№ теста
Ожидаемый результат
age
sex
year
1
17
«М»
1
некорректный возраст
2
18
«Мужской»
0
некорректный курс
3
54
«Женский»
6
некорректный курс
4
18
«М»
1
cost = 4000
5
54
«Ж»
1
cost = 4000
6
55
«М»
5
cost = 2000
7
56
«Женский»
5
cost = 1000
8
60
«Мужской»
1
cost = 2000
9
61
«М»
5
cost = 1000
57
6.4.3. Причинно-следственные связи
Перечислим причины (входные условия) c и следствия (выходные значения) e для
формы расчета стоимости обучения:
Таблица 6.8.
Причины
с1
с2
с3
с4
с5
с6
с7
18 ≤ age < 55
55 ≤ age < 60
age ≥ 60
sex = «М»
sex = «Ж»
year = 1
1 < year ≤ 5
Следствия
e1
e2
e3
cost = 40000
cost = 20000
cost = 10000
Построим граф причинно-следственных связей:
Рисунок 6.8 Граф причинно-следственных связей расчета стоимости обучения
В ходе построения графа потребовалось добавить несколько промежуточных причин, имеющих свой логический смысл:
58
Таблица 6.9.
Промежуточные причины
с8
55 лет и старше
с9
мужчина-пенсионер
с10
женщина-пенсионер
с11
первый год, без скидки
с12
пенсионер
с13
со второго по пятый годы, со скидкой
Заполним таблицы решений (табл. 6.10) и тестовых вариантов (табл. 6.11).
Таблица 6.10.
Решения
Причины
c1
c2
c3
c4
c5
c6
c7
1
2
3
4
5
6
7
8
1
1
0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0
0
1
1
0
1
1
-
-
0
0
1
0
0
1
-
-
1
1
0
1
1
0
0
1
0
0
0
1
1
1
1
0
1
1
1
0
0
0
1
0
0
0
0
0
0
0
0
1
1
1
1
0
0
0
0
0
0
0
0
1
1
1
Следствия
e1
e2
e3
59
Таблица 6.11.
Входные данные
№ теста
Ожидаемый результат
age
sex
year
1
18
«М»
2
cost = 40000
2
25
«Ж»
1
cost = 20000
3
55
«Ж»
3
cost = 20000
4
60
«Ж»
4
cost = 20000
5
61
«М»
5
cost = 20000
6
57
«Ж»
1
cost = 10000
7
70
«Ж»
1
cost = 10000
8
75
«М»
1
cost = 10000
6.5. Вопросы для самоконтроля
1. Что такое класс эквивалентности?
2. Каковы правила формирования классов эквивалентности?
3. Почему значения вблизи границ классов эквивалентности имеют важное значение
для тестирования?
4. Какое минимальное количество тестов должно быть сформировано по методике
эквивалентного разбиения для тестирования модуля, принимающего два входных параметра, каждый из которых имеет по одному допустимому и по одному недопустимому классам эквивалентности?
5. В каких состояниях могут находиться узлы графа причинно-следственных связей?
60
7. Лабораторная работа № 7. «Разработка интерфейса
пользователя»
7.1. Цель работы
Получение практических навыков в проектировании и реализации элементов пользовательского интерфейса.
7.2. Теоретический минимум
Интерфейс пользователя – это совокупность средств, способов и правил взаимодействия программы с пользователем. Основным элементом такого взаимодействия является
диалог – регламентированный обмен информацией в реальном времени, направленный на
совместное решение задачи.
Каждый сеанс взаимодействия состоит из процедур ввода и вывода информации и
управляющих команд. Вводом считается передача информации от человека к программе,
выводом – от программы к человеку.
Наиболее распространенными видами пользовательского интерфейса являются:
– текстовый – ввод и вывод осуществляются в символьной форме;
– графический – для взаимодействия используются визуальные формы представления;
– голосовой – для взаимодействия используются технологии распознавания и
синтеза речи.
7.2.1. Этапы разработки пользовательского интерфейса
Разработка пользовательского интерфейса может быть осуществлена на основе спецификаций, разработанных на этапе анализа требований и уточненных на этапе проектирования. При этом процесс разработки интерфейса разбивается на три этапа: построение графов диалогового взаимодействия, выбор форм представления данных и синтез элементов
пользовательского интерфейса. Каждый этап завершается оформлением соответствующих
спецификаций.
61
7.2.2. Построение графов диалогового взаимодействия
Граф диалогового взаимодействия – это разновидность диаграммы переходов состояний, описывающая последовательность взаимодействия пользователя и программы при
реализации диалога. Как правило, отдельные графы взаимодействия строятся для каждого
варианта использования, определенного на этапе анализа требований.
В качестве узлов графа (состояний) выступают элементарные сеансы диалогового
обмена. В качестве дуг – переходы, инициируемые командами подтверждения, отмены
ввода, навигацией по элементам интерфейса, вводом некорректных данных, исключениями
и иными событиями, требующими изменения диалогового контекста.
7.2.3. Выбор форм представления данных
На данном этапе каждое состояние графа трансформируется в отдельную таблицу
представления данных (табл. 7.1).
Таблица 7.1.
Элемент данных / команда
Тип данных
Элемент интерфейса
В первом столбце таблицы указывают входной или выходной параметр или команду
управления, во втором – тип данных для представления этого параметра или команды, в
третьем – конкретный элемент реализации, зависящий от выбранного типа пользовательского интерфейса.
7.2.4. Синтез элементов пользовательского интерфейса
На этапе синтеза все формы представления данных получают программную реализацию. Для графического оконного интерфейса каждая таблица, как правило, преобразуется
в отдельное окно или форму, а отдельный элемент – в кнопку, поле ввода или вывода, список и т. п. Для текстового или голосового интерфейса таблица разворачивается в элементарный сеанс взаимодействия, а элементом интерфейса служат текстовые или речевые конструкции.
62
7.3. Порядок выполнения работы
1. Получить у преподавателя свой вариант задания.
2. Проанализировать требования и построить диаграмму вариантов использования.
3. Для каждого основного варианта использования построить граф диалогового взаимодействия.
4. Отдельные состояния графов преобразовать в таблицы форм представления данных.
5. Реализовать элементы пользовательского интерфейса.
6. Оформить отчет о выполненной работе.
7.4. Пример выполнения работы
Разработаем графический интерфейс для почтовой программы из примера к лабораторной работе №3, основными вариантами использования которой являются (см. рис. 3.4):
проверка почты, чтение письма и отправка письма. Дополнительно предусмотрены процедуры авторизации, выбора подразделения для массовой рассылки, вложение документов
и фотографий.
7.4.1. Построение графов диалогового взаимодействия
При реализации варианта использования проверка почты, взаимодействие пользователя с программой предполагает следующие процедуры авторизации пользователя и визуализации списка входящих писем.
Вариант чтение письма, в дополнение к перечисленным, содержит процедуру просмотра письма.
Вариант отправка письма содержит процедуры авторизации, редактирования
письма, выбора адресата, выбор файла.
Построим соответствующие графы взаимодействия (рис. 7.1).
63
Рисунок 7.1 Графы диалогового взаимодействия интерфейса почтовой программы
7.4.2. Выбор форм представления данных
Видом интерфейса программы определим графический, на основе диалоговых форм.
Каждое состояние каждого графа взаимодействия будет отображаться в диалоговое окно.
Состояния с одинаковым именем из разных графов связываются с одним и тем же окном.
Основным окном программы будет окно просмотра почты.
Сформируем таблицы представления данных и выберем элементы реализации с учетом использования среды разработки Microsoft Visual Studio и технологии Windows Forms.
Таблица 7.2.
Диалоговое окно «Авторизация»
Элемент данных / команда
Тип данных
Элемент интерфейса
Приглашение ко вводу логина
Текст
Label
Приглашение ко вводу пароля
Текст
Label
Поле ввода логина
Текст
TextBox
Поле ввода пароля
Текст
TextBox
Подтверждение ввода
Кнопка
Button
Отмена ввода
Кнопка
Button
64
Таблица 7.3.
Диалоговое окно «Просмотр почты»
Элемент данных / команда
Тип данных
Элемент интерфейса
Текст
Label
Входящие письма
Список
ListBox
Завершение просмотра
Кнопка
Button
Переход к просмотру письма
Кнопка
Button
Заголовок списка писем
Таблица 7.4.
Диалоговое окно «Просмотр письма»
Элемент данных / команда
Тип данных
Элемент интерфейса
Заголовок отправителя
Текст
Label
Заголовок темы
Текст
Label
Отправитель
Текст
TextBox
Тема письма
Текст
TextBox
Текст письма
Гипертекст
RichTextBox
Переход к ответу
Кнопка
Button
Завершение чтения
Кнопка
Button
Таблица 7.5.
Диалоговое окно «Написание письма»
Элемент данных / команда
Тип данных
Элемент интерфейса
Заголовок адресата
Текст
Label
Заголовок темы
Текст
Label
Заголовок вложений
Текст
Label
Адресат
Текст
TextBox
Тема письма
Текст
TextBox
65
Вложения
Текст
TextBox
Гипертекст
RichTextBox
Отмена отправки
Кнопка
Button
Отправка
Кнопка
Button
Текст письма
Диалоговые окна выбора файла и выбора адресата являются шаблонными, их интерфейс не проектируется.
7.4.3. Синтез элементов пользовательского интерфейса
На основе таблиц представления данных, используя среду визуального проектирования интерфейса реализуем диалоговые окна (рис. 7.2 – 7.5).
Рисунок 7.2 Диалоговое окно «Авторизация»
Рисунок 7.3 Диалоговое окно «Просмотр почты»
66
Рисунок 7.4 Диалоговое окно «Просмотр письма»
Рисунок 7.5 Диалоговое окно «Написание письма»
7.5. Вопросы для самоконтроля
1. Какие виды интерфейсов пользователя вы знаете?
2. Какой вид интерфейса разработан в примере к лабораторной работе?
3. Назовите этапы проектирования интерфейсов.
4. Дайте определение термину «диалог».
67
5. На какой стадии разработки программного обеспечения можно начинать проектирование интерфейса пользователя?
6. Что такое граф диалогового взаимодействия?
7. Что является узлами графа диалогового взаимодействия?
68
Библиографический список
1. Иванова, Г.С. Технология программирования: учебник для вузов / Г.С. Иванова. –
М.: Изд-во МГТУ им. Н.Э.Баумана, 2006. – 335 с.: ил.
2. Камаев, В.А. Технологии программирования: учебник / В.А. Камаев, В.В. Костерин. – 2-е изд., перераб. и доп. – М.: Высш. шк., 2006. – 454 с.: ил.
69
Приложение А. Оценка системных параметров
А.1. Передача данных
Критерии оценки
балл
Приложение полностью функционирует на автономном ПК
0
Приложение имеет удаленный доступ к данным или удаленную печать
1
Приложение имеет удаленный доступ к данным и удаленную печать
2
Приложение реализует сбор данных "онлайн" или является клиентской частью системы обработки
3
данных
Приложение реализует клиент-серверную систему обработки данных, но использует только один
4
протокол связи
Приложение реализует клиент-серверную систему обработки данных и использует несколько про-
5
токолов связи
А.2. Распределенная обработка данных
Критерии оценки
Приложение не поддерживает перенос данных или функций их обработки между компонентами
балл
0
системы
Приложение подготавливает данные для их обработки другим компонентом системы, таким как
1
СУБД, или электронные таблицы
Данные подготавливаются и передаются на обработку в другой компонент системы (не для конеч-
2
ного пользователя)
Передача данных для обработки осуществляется в режиме "онлайн" в одном направлении
3
Передача данных для обработки осуществляется в режиме "онлайн" в обоих направлениях
4
Функции обработки динамически распределяются между наиболее подходящими компонентами
5
системы
70
А.3. Производительность
Критерии оценки
балл
Пользователем не определены особые требования к производительности приложения
0
Требования к производительности определены, но особые меры для их выполнения не требуются
1
Время отклика или пропускная способность системы критичны в часы пиковых нагрузок. Время
2
обработки данных ограничивается рабочим днем
Время отклика или пропускная способность системы критичны в течение всего рабочего времени.
3
Время обработки данных определяется требованиями сопряженных систем
Заявлены строгие требования к производительности, требующие выполнения дополнительного
4
анализа на этапе проектирования
Требуются специальные инструменты анализа производительности, используемые на этапах проек-
5
тирования, разработки и/или реализации
А.4. Аппаратные ограничения
Критерии оценки
балл
Никакие явные или неявные аппаратные ограничения не определены
0
Аппаратные ограничения заявлены, но никаких особых усилий для их соблюдения не требуют
1
Обозначены некоторые временные ограничения или требования безопасности
2
Для отдельных частей приложения аппаратной платформой определены специфические требования
3
Аппаратная платформа накладывает особые ограничения на функционирование приложения
4
Дополнительно, особые ограничения на функционирование приложения оказывают распределен-
5
ные компоненты системы
А.5. Скорость транзакций
Критерии оценки
Пики транзакционной активности не ожидаются
Ожидаются ежемесячные, ежеквартальные, сезонные или ежегодные пики транзакционной актив-
балл
0
1
ности
71
Ожидаются недельные пики транзакционной активности
2
Ожидаются ежедневные пики транзакционной активности
3
Пользователем определены требования к высокой скорости транзакций, требующие анализа произ-
4
водительности на этапе проектирования
Пользователем определены требования к высокой скорости транзакций, требующие специальных
инструментов анализа производительности, используемых на этапах проектирования, разработки
5
и/или реализации
А.6. Оперативный ввод данных
Критерии оценки
балл
Вся обработка данных осуществляется в пакетном режиме
0
От 1% до 7% данных требуют оперативного ввода
1
От 8% до 15% данных требуют оперативного ввода
2
От 16% до 23% данных требуют оперативного ввода
3
От 24% до 30% данных требуют оперативного ввода
4
Более 30% данных требуют оперативного ввода
5
А.7. Эффективность работы конечного пользователя
Определяет количество дополнительных функций, повышающих эффективность работы конечного пользователя, включая:
– средства навигации ("горячие клавиши", динамические меню и т.п.);
– справочную систему;
– пакетную обработку;
– активное использование анимации, подсветки, цветового выделения и других
средств индикации;
– бумажную копию пользовательской документации;
– минимизацию числа окон (экранов), в цепи решения конкретных задач;
– двуязычный интерфейс (считается как 4 пункта);
– мультиязычный интерфейс (считается как 6 пунктов).
72
Критерии оценки
балл
Приложение не реализует ни одну из перечисленных функций
0
Приложение реализует 1-3 из перечисленных функций
1
Приложение реализует 4-5 из перечисленных функций
2
Приложение реализует 6 и более из перечисленных функций, но особые требования к эффективно-
3
сти работы конечного пользователя не определены
Приложение реализует 6 и более из перечисленных функций, определены особые требования к эф-
4
фективности работы конечного пользователя
Приложение реализует 6 и более из перечисленных функций, определены особые требования к эффективности работы конечного пользователя, требующие разработки специальных инструментов и
5
процедур
А.8. Удаленное обновление
Критерии оценки
Нет поддержки удаленного обновления
Удаленно обновляются от 1 до 3 управляющих файлов. Объем обновления небольшой, процесс
балл
0
1
восстановления легок
Удаленно обновляются 4 и более управляющих файлов. Объем обновления небольшой, процесс
2
восстановления легок
Основные внутренние логические файлы обновляются удаленно
Основные внутренние логические файлы обновляются удаленно. Реализована защита от потери
3
4
данных
Основные внутренние логические файлы обновляются удаленно. Реализована защита от потери
данных. Объем обновляемых данных высок. Реализованы процедуры автоматического обновления
5
и восстановления с минимальным вмешательством оператора
А.9. Сложность обработки
Описывает степень, в которой приложение содержит следующие элементы:
– процедуры аудита и/или контроля безопасности;
– сложную логическую обработку;
73
– сложную математическую обработку;
– большой объем обработки прерванных транзакций, вызванных сбоями сети, неполными или некорректными данными;
– большое количество обработчиков данных от устройств ввода-вывода.
Критерии оценки
балл
Приложение не содержит ни одного из перечисленных элементов
0
Приложение содержит любой из перечисленных элементов
1
Приложение содержит любые два из перечисленных элементов
2
Приложение содержит любые три из перечисленных элементов
3
Приложение содержит любые четыре из перечисленных элементов
4
Приложение содержит все пять перечисленных элементов
5
А.10. Повторная используемость
Критерии оценки
балл
Приложение не содержит повторно используемого кода
0
Приложение использует повторно используемый код
1
Менее 10% приложения учитывает потребности более чем одного пользователя
2
Не менее 10% приложения учитывает потребности более чем одного пользователя
3
Приложение специально разработано и документировано для облегчения повторного использова-
4
ния путем корректировки на уровне исходного кода
Приложение специально разработано и документировано для облегчения повторного использова-
5
ния путем корректировки на уровне пользовательских настроек
А.11. Легкость инсталляции
Критерии оценки
балл
Никаких специальных настроек для установки не требуется
0
При установке требуется определенная настройка приложения
1
74
Требования к установке и конвертированию определены пользователем, но их влияние на проект
2
незначительно
Требования к установке и конвертированию определены пользователем, их влияние на проект зна-
3
чительно
В дополнение к (2) требуются автоматические инструменты установки и конвертирования
4
В дополнение к (3) требуются автоматические инструменты установки и конвертирования
5
А.12. Легкость эксплуатации
Описывает степень минимизации ручных действий при работе с приложением:
– эффективные инструменты резервирования и восстановления, работа которых
инициируется пользователем;
– эффективные инструменты резервирования и восстановления, не требующие вмешательства пользователя (считается как два элемента);
– приложение минимизирует ручные манипуляции;
– приложение минимизирует использование бумаги.
Критерии оценки
Не предусмотрено никаких автоматизированных процедур, кроме стандартного резервного копиро-
балл
0
вания, инициируемого пользователем
1 элемент из описания параметра
1
2 элемента из описания параметра
2
3 элемента из описания параметра
3
4 элемента из описания параметра
4
Приложение предназначено для автоматической работы. не требует вмешательства оператора,
кроме процессов запуска и закрытия. Особенностью приложения является автоматическое восста-
5
новление после сбоев
А.13. Разнообразие условий размещения
75
Критерии оценки
Не требуется учет более чем одних условий размещения
Были учтены несколько объектов размещения. Приложение функционирует в одной и той же про-
балл
0
1
граммно-аппаратной среде
Были учтены несколько объектов размещения. Приложение функционирует в схожих программно-
2
аппаратных средах
Были учтены несколько объектов размещения. Приложение функционирует в различных програм-
3
мно-аппаратных средах
Приложение протестировано, документировано и поддерживается в условиях (1) или (2)
4
Приложение протестировано, документировано и поддерживается в условиях (3)
5
А.14. Простота изменений
Описывает степень, в которой приложение разработано для легкой модификации логики обработки или структур данных. Для приложения могут применяться следующие характеристики:
– предоставляется гибкий механизм запросов и отчетов, который может обрабатывать простые запросы (например, только к одному внутреннему логическому файлу);
– предусмотрен гибкий механизм запросов и отчетов средней сложности (например,
применяемых к нескольким внутренним логическим файлам);
– предоставляется гибкий механизм запросов и отчетов, который может обрабатывать сложные запросы (например, логические комбинации на одном или нескольких внутренних логических файлах);
– настройка пользователями логики работы происходит интерактивно, но изменения
вступают в силу на следующий рабочий день;
– настройка пользователями логики работы происходит интерактивно, изменения
вступают в силу немедленно.
Критерии оценки
Приложение не поддерживает ни одного из перечисленных пунктов
балл
0
76
Приложение поддерживает один из перечисленных пунктов
1
Приложение поддерживает два из перечисленных пунктов
2
Приложение поддерживает три из перечисленных пунктов
3
Приложение поддерживает четыре из перечисленных пунктов
4
Приложение поддерживает пять перечисленных пунктов
5
77
Приложение Б. Требования к оформлению отчетов
Задачами оформления отчета о лабораторной работе является пошаговое описание
ее выполнения, представление полученных результатов и выводов, позволяющие оценить
уровень знаний и навыков студента по теме работы.
Обязательными элементами отчета являются:
– титульный лист;
– цель работы;
– индивидуальное задание;
– описание методики, алгоритма решения задачи, применяемых математических
формул;
– описание хода и приведение результатов выполнения работы, включающих алгоритмы, диаграммы, расчеты, листинги программного кода, скриншоты (в зависимости от
задания);
– вывод.
Отчет оформляется на компьютере. Текст набирается шрифтом «Times New Roman»,
кегль – 12. Поля: левое – 30 мм, правое – 10, нижнее – 20, верхнее – 15 мм.
78
