Программное обеспечение для нахождения длины вектора и его положения на плоскости
Основные требования к программному изделию. Идентификация и оценка функциональности данных. Подсчет нормированного количества функциональных точек. Оценка трудозатрат и сроков разработки программных средств. Определение значения нормирующего фактора.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 17.06.2012 |
| Размер файла | 1,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
ОГЛАВЛЕНИЕ
1. Обследование объектов автоматизации
1.1 Описание предметной области
1.2 Модель предметной области
1.3 Требование пользователя
1.4 Обзор существующих систем автоматизации поставленных задач
1.5 Требование к программному изделию
1.5.1 Функциональные требование:
1.5.2 Эксплуатационное требование
1.5.3 Требование к интерфейсам
1.5.4 Операционные требование
1.5.5 Другие требование
2. Оценка размера сложности
2.1 Определение границ ПС
2.2 Идентификация и оценка функциональности данных (ILF, EIF)
2.3 Идентификация и оценка функциональности транзакции (EI, EO, EQ)
2.4 Определение значения нормирующего фактора.
2.5 Подсчет нормированного количества функциональных точек
2.6 Оценка количества строк исходного кода с использованием бэкфайер-метода
3. Оценка трудозатрат и сроков разработки программных средств
3.1 Управление, используемые в модели COCOMO
3.2 Стоимостные факторы
4. Техническое задание
5. Жизненный цикл
6. Архитектурный проект
7. Детальный проект
7.1 Требования к оформлению программного кода
7.2 Исходный код проекта
8. Метрики сложности программных средств
8.1 Метрика размера программ
8.2 Метрика сложности управление программ
8.3 Метрика уровня комментированности
9. Тестирование программных средств
9.1 Описание процесса тестирование
9.2 Метрики тестирования
10. Оценка надежности
10.1 Модель Коркорэна
1. Обследование объектов автоматизации
1.1 Описание предметной области
Программный продукт, предназначенный для нахождение четвертей на координатной плоскости, в которых проходит заданный вектор и определение его длины. Он представляет собой программный продукт, не требующих каких-либо специальных знаний.
Задача объекта автоматизации - нахождение четвертей на координатной плоскости, где проходит заданный вектор и определение его длины.
Для решение данной задачи объекта автоматизации, необходимо:
1) По первой заданной точки `x1',определить в какой четверти она лежит.
2) По первой заданной точки `y1', определить в какой четверти она лежит.
3) Повторить для вторых точек `x2' и `y2'.
4) Исходя из полученных результатов находим, в какой четверти (или несколько четвертей) проходит весь вектор.
5) Определяем длину =
Пример.
Рассмотрим решение данной задачи на примере из двух заданных точек.
Точка 1 - (1, 1).
Точка 2 - (-3, 2).
Определим для первой точки, в какой четверти она находится. Для этого воспользуемся условием. Если `x'>0 и `y'>0, то это значит что первая четверть.
Повторим для второй точки. Если `x'<0 и `y'>0, то это значит что четвертая четверть.
Исходя из полученных данных, можно определить, что вектор проходит из первой в четвертую четверть.
Определим длину .
1.2 Модель предметной области
Для представления предметной области воспользуемся диаграммой вариантов использования.
Рис. 1. Диаграмма вариантов использования для метода релаксации.
1.3 Требование пользователя
1) Программное изделие должно иметь 2 функции для ввода данных (из файла и клавиатуры).
2) Программное изделие должно иметь функцию для проверки верности данных.
3) Программное изделие должно находить длину вектора по двум заданным точкам с учетом указаний точности.
4) Программное изделие должно иметь функцию для вывода результата на экран и для записи этого результата в файл.
5) Для вывода информации не должны использоваться яркие цвета, иметь удобный интерфейс, использовать стандартные шрифты.
1.4 Обоз существующих систем автоматизации поставленных задач
На данный момент не существует ПО, предназначенного для нахождение длины вектора и его положение на плоскости. Возможно существует ПО, в котором данная задача является частью всей ПО для решение других задач.
1.5 Требование к программному изделию
1.5.1 Функциональные требование:
1) Данное программное изделие должно находить решение при четырех заданных точках.
1.5.2 Эксплуатационное требование
1) Время ответа не должно превышать больше 1 секунды.
2) Программное изделие должно работать без сбоев в течение 2 часов
1.5.3 Требование к интерфейсам
1) Программное изделие должно иметь возможность для ввода исходных данных с клавиатуры или с файла.
2) Программное изделие должно выводить ответ в виде графика.
1.5.4 Операционные требование
1) Программное изделие должно работать под WindowsсерииXP.
1.5.5 Другие требование
1) Программное изделие должно выдавать ошибку или предупреждение, если данные введены не полностью.
2. Оценка размера сложности
2.1 Определение границ ПС
Установление границ данного ПС не вызывает трудностей, т.к. оно является полностью локальным, и обмен данными с другими ПС через локальные или глобальные сети не предусмотрен.
2.2 Идентификация и оценка функциональности данных (ILF, EIF)
В ПС имеется один внутренний логический файл (ILF)для хранения всей нужной информации (координаты точек).
Число типов элементов данных (DET) внутреннего логического файла равно 1:
· `x1', `x2', `y1', `y2' - значение точек на координатной плоскости.
Число типов элементов записей (RET) для этого файла равно 1:
· `x1', `x2', `y1', `y2' - вещественные числа.
Таким образом, уровень сложности внутреннего логического файла - низкий.
Внешних интерфейсных файлов (EIF) данное ПС не имеет.
2.3 Идентификация и оценка функциональности транзакции (EI, EO, EQ)
В ПС имеются два внешних ввода (EI): ввод данных с клавиатуры и ввод данных из файла.
Для ввода данных с клавиатуры число типов элементов данных (DET) равно 4 `x1', `x2', `y1', `y2' и кнопка “Ввод данных”, количество типов используемых файлов (FTR) равно 1.
Уровень данного ввода - низкий.
Для ввода данных из файла получаем аналогичные результаты, за исключением того, что используется кнопка “Ввод результата” и символьная строка, где хранится имя файла.
Таким образом, FTR=1, DET=5, уровень сложности для ввода из файла - низкий.
В ПС имеется один внешний запрос (EQ) - запрос на решаемость исходной системы. Для него нужна проверка в которой определится: если данные корректны, то система имеет на выходе - строка “Данные корректны” или “Данные не корректны”, FTR=DET=1.
Таким образом, уровень внешнего запроса - низкий.
В ПС имеются два внешних вывода (EO): вывод на экран и вывод в файл.
Для вывода данных на экран число типов элементов данных (DET) равно 3: `rez', `dlina' и кнопка “Вывести результат на экран”, количество типов используемых файлов (FTR) равно 3.
Таким образом, уровень вывода на экран - средний.
Для вывода данных в файл DET=3; RET=4: `rez', `dlina'кнопка “Вывести результат в файл” и строка с именем файла.
Уровень вывода в файл - средний.
2.4 Определение значения нормирующего фактора
Рассчитаем ненормированное количество функциональных точек
Таблица 1.
Расчет UFPC
|
Характеристика |
Кол-во |
Ранг |
Итог |
|
|
Внешние вводы (EI) |
2 |
3 |
6 |
|
|
Внешние выводы (EO) |
2 |
5 |
10 |
|
|
Внешние запросы (EQ) |
1 |
3 |
3 |
|
|
Внутренние логические файлы (ILF) |
1 |
7 |
7 |
|
|
Внешние интерфейсы |
0 |
- |
0 |
|
|
Итого (UFPC) |
26 |
Подсчитаем итоговую степень влияния (TDI) общих характеристик системы и нормирующий фактор (VAF).
Для данного ПС важны следующие характеристики:
· Обмен данными имеет вес - 0, т.к. ПС реализовано как единый пакет на автономном компьютере.
· Распределение функции, которая оценивается с весом - 0, поскольку данные между компонентами ПС и системы не передаются.
· Производительность, которая оценивается с весом - 1, поскольку требования были рассмотрены, но для их удовлетворения специальных мер не потребовалось.
· Интенсивно используемая конфигурация, которая оценивается с весом - 0, поскольку явных и неявных ограничений на использование ресурсов не установлено.
· Диалоговый ввод данных, который оценивается с весом - 5, поскольку все транзакции в ПС интерактивные.
· Эффективность для конечного пользователя, степень поддержки с диалоговым функциями эффективности работы по наличию в ПС следующих элементов пользовательского интерфейса - меню, оценивается с весом - 1.
· Оперативное обновление с весом - 0, поскольку обновление отсутствуют.
· Сложность обработки данных, которая оценивается с весом - 0, т.к. не присутствуют ни один из указанных пунктов.
· Повторное использование, которое оценивается с весом - 0, поскольку в ПС нет кода, предназначенного для повторного использования.
· Легкость установки, которая оценивается с весом - 0, поскольку нет особых требований пользователя, и не требует специальной установочной программы.
· Простота использование, имеет вес - 0, поскольку нет особых требований пользователя.
· Распространённость с весом - 0, поскольку ПС не рассчитано на использование больше чем одним пользователем или на установку более чем на одном компьютера.
· Легкость изменение, который оценивается с весом - 0, т.к. пользователь не может вносить изменения.
Нормирующий фактор (VAF) определяется как:
2.5 Подсчет нормированного количества функциональных точек
Нормированное количество функциональных точек для данного ПС вычисляется как:
2.6 Оценка количества строк исходного кода с использованием бэкфайер-метода
Т.к. данная программа будет разрабатываться среде C++ Builder6, что по таблице значений языкового множителя (LM) равносильно С++, то значение LM равно 34.
Таким образом, приблизительное количество строк законченной программы в среде C++ Builder6будет равно:
3. Оценка трудозатрат и сроков разработки программных средств
3.1 Управление, используемые в модели COCOMO
Рассмотрим расчет трудоемкости и сроков реализации программного проекта с использованием модели СОСОМО. В качестве исходных данных возьмем количество строчек кода. Очевидно, что по всем признакам (размеру, сложности, ограничениям) данный проект следует отнести к виду распространенный.
По исходным данным, полученным выше (636 строк кода) с помощью формулы, представленной ниже, без учета влияния стоимостных факторов можно определить ненормированные номинальные трудозатраты:
человеко - месяца,
а также ненормированную деятельность проекта:
месяца.
3.2 Стоимостные факторы
Таблица 2.
Стоимостные факторы и коэффициенты нормирования трудозатрат для телефонного справочника
|
Фактор |
Уровень |
Коэффициент |
|
|
Rely |
Очень низкий |
0,75 |
|
|
CPLX |
Очень низкий |
0,7 |
|
|
Time |
Номинальный |
1 |
|
|
Stor |
Номинальный |
1 |
|
|
Virt |
Очень низкий |
- |
|
|
Turn |
Очень низкий |
0,87 |
|
|
Acap |
Низкий |
1,19 |
|
|
Aexp |
Номинальный |
1 |
|
|
Pcap |
Низкий |
1,17 |
|
|
Vexp |
Номинальный |
1 |
|
|
Lexp |
Номинальный |
1 |
|
|
Modp |
Высокий |
0,91 |
|
|
Tool |
Очень высокий |
0,83 |
|
|
Sced |
Высокий |
1,04 |
|
|
Произведение |
0,49 |
Нормированные трудозатраты на реализацию проекта:
(человеко - месяца)
Нормированная длительность проекта:
(месяца).
Таким образом, для разработки программного средства необходимо 2,9 месяца. Полная реализация ПС равняется 4,6 месяца, без выходных. Затраты на экспертизы составляет 30% или дополнительно 1,3 месяца, без выходных. Итого на реализацию ПС необходимо 6 месяцев, без выходных.
4. Техническое задание
Таблица 3
Техническое задание по госту 34.602-89
|
Наименование раздела |
Содержание раздела |
Требуемые характеристики. |
|
|
Общие сведения. |
Наименование системы. |
Программное средство «Вектор». |
|
|
Шифр темы номер договора. |
Требования отсутствуют. |
||
|
Разработчик. |
Студент группы 08ПО-2 Щербаков Д.В. |
||
|
Перечень документов, на основании которых создается система. |
Пояснительная записка. |
||
|
Срок сдачи проекта. |
17.10.2011 |
||
|
Сведения об источниках и порядке финансирования работ. |
Требования отсутствуют. |
||
|
Порядок оформления и предъявления заказчику результатов работ. |
Требования отсутствуют. |
||
|
Назначение и цели создания системы. |
Назначение системы. |
Система предназначена для нахождение положение вектора на плоскости и его длину. |
|
|
Цели создания системы. |
Создание продукта, позволяющего находить в какой четверти находится вектор и его длину. |
||
|
Характеристика объекта автоматизации. |
Сведения об объекте автоматизации. |
Использование данной системы позволит определять 9 положенийвектора на плоскости и формулу определение его длины. |
|
|
Условия эксплуатации объекта автоматизации и характеристиках окружающей среды. |
Данная система должна функционировать под управлением операционной системы Windows XP. |
||
|
Требования к системе |
Требования к системе в целом |
||
|
Требования к структуре и функционированию системы. |
Разрабатываемая система должна включать в себя возможность сохранять и извлекать данные из файла и выводить весь свой функционал (график, введенные числа, ответ) на монитор |
||
|
Требования к обслуживающему персоналу. |
Для обслуживания ПС необходим обычный пользователь ПК с начальными знаниями операционной системы. |
||
|
Требования показателей назначения. |
Требования отсутствуют. |
||
|
Требования к надежности. |
Обеспечить очень высокий показатель надежности для данного ПС. |
||
|
Требования к эргономике и технической эстетике. |
Интерфейс программы должен быть простым и интуитивным. При выборе цветового решения предпочтения отдать спокойным тонам. |
||
|
Требования к эксплуатации. |
Данное ПС должно работать стабильно,без сбоев, без критических ошибок. Обслуживание данного ПС не обязательно. |
||
|
Требования к защите информации от несанкционированного доступа. |
Требования отсутствуют. |
||
|
Требования по сохранности информации. |
Требования отсутствуют. |
||
|
Требования к функциям (задачам), выполняемым системой. |
|||
|
Перечень задач автоматизации. |
Ввод переменных функции. |
||
|
Требования к каждой функции к форме представления выходной информации. |
Выходная информация будет храниться в файле с расширением *.txt |
||
|
Перечень и критерий отказов для каждой функции. |
Требования отсутствуют. |
||
|
Требования к видам обеспечения |
|||
|
Математическому |
Требования отсутствуют. |
||
|
Информационному |
Требования отсутствуют. |
||
|
Лингвистическому |
Требование отсутствуют. |
||
|
Программному |
Требования отсутствуют. |
||
|
Техническому |
IBM совместимы с ПК |
||
|
Метрологическому |
ISO |
||
|
Состав и содержание работ по созданию системы. |
Раздел должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ. В данном разделе также приводят: 1) перечень документов, по ГОСТ 34.201-89 , предъявляемых по окончании соответствующих стадий и этапов работ; 2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт) |
Разработать проект «Вектор» с использованием стадий: технический проект, рабочая документация, ввод в действие с объединением их в один том «Рабочая документация. |
|
|
Порядок контроля и приемки системы |
Виды, состав, объем и методы испытаний системы и ее основных частей. |
Проведение тестовых испытаний будет проводиться после готовности ПС. |
|
|
Общие требования к приемке работ по стадиям, порядок согласования и утверждения приемочной документации. |
Демонстрация полнофункциональной версии программы и представление текстовой документации. |
||
|
Статус приемочной комиссии. |
Доцент Азарченков А.А. |
||
|
Требование к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. |
Приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМ. |
Требования отсутствуют. |
|
|
Создание условий функционирования объекта автоматизации |
Установка и настройка операционной системы. |
||
|
Сроки и порядок комплектования штатов и обучения персонала. |
Требования отсутствуют. |
||
|
Требования к документированию. |
Документация, подлежащая разработке. |
Руководство пользователя. |
|
|
Источники разработки |
Документы и информационные материалы (технико-экономическое обоснование, отчеты о НИР, информационные материалы на системы-аналоги и др.). |
5. Жизненный цикл
Для организации, планирование, распределение ресурсов (трудозатрат и времени) и управление проектом разработки необходимо определится с типом жизненного цикла (ЖЦ). Мною была выбрана последовательная модель - каскадная модель. Суть этой модели состоит в следующем: каждая стадия должна быть завершена до перехода к следующей, а создаваемые на ней рабочие продукты после их верификации и валидации (V&V) должны быть "заморожены" и переданы на следующую стадию в качестве эталона. Пользователь видит работающий программный продукт в самом конце разработки. Наиболее жесткое ограничение этой модели - необходимость "замораживания" требований, при этом, чтобы минимизировать риск увеличения стоимости, допускаются только небольшие изменения.
С точки зрения качества ПС, в этой модели стоимость исправления дефектов на стадии тестирования наибольшая из всех моделей, поскольку тестирование выполняется в самом конце разработки. Из-за недостатка времени на переделки и тестирование существует значительный риск выпуска ПС с серьезными дефектами.
Однако в силу наибольшей простоты в организации мы остановимся именно на этой модели.
Рис. 2. Каскадная модель
Таблица 4
Основные этапы реализации разрабатываемого ПО
|
Этапы реализации |
Сроки |
Даты |
|
|
1. Анализ требований. |
5 дней |
7.02. - 11.02. |
|
|
2. Проектирование. |
26 дней |
14.02. - 7.04. |
|
|
2.1. Эскизное проектирование базовой версии ПС. |
18 дней |
14.02. - 09.03. |
|
|
2.2. Техническое (детальное) проектирование базовой версии ПС. |
8 дней |
10.03. - 21.03. |
|
|
2.3. Экспертиза |
13 дней |
22.03. - 07.04. |
|
|
3. Реализация |
87 дня |
08.04. - 30.08. |
|
|
3.1. Программирование |
43дня |
08.04. - 30.06. |
|
|
3.2. Отладка |
1 неделя |
01.07. - 11.07. |
|
|
3.3. Разработка документации компонентов базовой версии ПО |
3 недели |
12.07. - 12.08. |
|
|
3.4. Экспертиза |
13 дней |
12.08. - 30.08. |
|
|
4. Тестирование. |
24 дней |
31.08. - 22.09. |
|
|
5. Экспертиза |
13 дней |
23.09. - 11.10. |
|
|
6. Внедрение и поддержка разработчиками процесса эксплуатации версии ПС пользователями. |
4 дня |
12.10. - 17.10. |
Рис 3 Сетевой график MS Project
6. Архитектурный проект
Для разработки данного ПС используется модульное проектирование в силу простоты конечного продукта. Причем, в данном случае будет иметь место одномодульная структура, т.е. весь проект будет представлять собой один модуль, где будут реализованы все нужные функции.
Разрабатываемое ПС имеет функциональный тип связности, т.к. все части модуля реализуют одну функцию (задачу) - нахождение длины вектора и положение ее на координатной плоскости. Т.е. в нашем случае имеется модуль, который содержит элементы, которые, в свою очередь, участвуют в выполнении одной и только одной проблемной задачи. Роль модуля в этом случае можно сравнить с “черным ящиком”.
Поскольку разрабатываемый программный продукт представляет собой одномодульную программу, то такая характеристика, как связность модулей, отсутствует.
Файлы проекта:
· Project1.cpp - в данном файле происходит создание формы и ее запуск, также обработка исключений если форма не создалась.
· Unit1.cpp - главный файл проекта, в котором происходит ввод данный, чтение и запись данный, решение поставленной задачи.
· Unit1.h - в данном файле происходит описание всех компонентов, а так же описание глобальных переменных.
· input.txt - файл, для считывание данных.
Основные функции проекта:
· void new_list() - функция для очищение графика, на котором рисуются вектора.
· intlenV(intx1, intx2, inty1, inty2) - функция для нахождения длины вектора.
· paint () - выводит график с определенным масштабом.
· intchetvert1 (intx1, inty1) иintchetvert1 (intx1, inty1) - функция находит в какой плоскость он находится точка.
· int check_num (AnsiString chain, int len, int flag) - функция, проверяет ввод данных на их корректность.
· int proverka1 (int flag1, int flag2, int flag3, int flag4 и int proverka2 (int x1, int x2, int y1, int y2) -функциивыводитпредупрежденияесливводимыеданныеневерны
· void reset () - функция для сброса значений во всех полях вводимых данных и вывода результата, а так же вызывается функция void new_list().
· void __fastcallTForm1::Button2Click(TObject *Sender)- основная функция из которой вызываются все остальные.
· void __fastcallTForm1::Button1Click(TObject *Sender) - функция для считывание данных из файла.
· void __fastcall TForm1::Button3Click(TObject *Sender) -функциядлязаписивфайл.
· void __fastcallTForm1::Button4Click(TObject *Sender) -функция которая отображает то что будет записано в файл.
7. Детальный проект
7.1 Требования к оформлению программного кода
В программе использованы координаты точек на плоскости- x, y, соответствующее продолжение их означает: 0-начало координат, 1-первая торчка, 2-вторая торчка. Так же в программе существуют два вида флагов - flag, loop. Первый отвечает за то что вводимое поле были только цифры и одновременно их длина была не больше 5, второй отвечает за знак минус для отрицательных чисел и за правильность ввода запитой для чисел от 0 до 1. Соответствующие представки означают: 1-для поля Edit1, 2-для поля Edit2, 3-для поля Edit3 и 4-для поля Edit4. В эти поля вводится некоторая информация она записывается в переменную chain (цепочка), продолжение ` `,2,3,4 -соответствуют своему полю Edit. У каждой цепочки есть длина len, их номера совпадают. Для определение четверти используется переменная t, что означает точка, конец 2 и начало 1 вектора. Указатель *List служит для записи информации в файл. Дополнительный флаг open предназначен для вывода и скрытие информации на экран , которая будет записана в файл.
7.2 Исходный код проекта
Project1.cpp
Unit1.cpp
программный данное нормированный разработка
Unit1.h
8. Метрики сложности программных средств
8.1 Метрика размера программ
В основе метрик измерения размера ПС положена концепция Холстеда заключающаяся в представлении такой программной реализации алгоритма, которая состоит только из операторов и операндов, т.е. соответствует структуре команд ЭВМ.
Возьмем одну из функции в программе:
loop1 = 0;
for (int i = 1; i <= len ; i++)
{ if ( i > 5 ) { flag = 0; break; }
if ( chain[i] == ','&& loop< 1) {loop1++; continue;}
if ( chain[i] == '-'&& i == 1) continue;
if ((chain[i]<48) || (chain[i]>57)) { flag = 0; break; }
else flag = 1;
}
Найдем количество операторов и занесём их в таблицу.
Таблица 5
Число вхождений операторов
|
Оператор |
i |
f1j |
|
|
== |
1 |
3 |
|
|
||, && |
2 |
3 |
|
|
(),{},[] |
3 |
28 |
|
|
= |
4 |
6 |
|
|
++ |
5 |
2 |
|
|
<= |
6 |
1 |
|
|
> |
7 |
2 |
|
|
< |
8 |
1 |
|
|
if, else |
9 |
4 |
|
|
for |
10 |
1 |
|
|
; |
11 |
12 |
|
|
continue |
12 |
2 |
|
|
break |
13 |
2 |
|
|
з1=13 |
N1=67 |
Найдем количество операндов .
Таблица 6
Число вхождение операндов
|
Оператор |
j |
f2j |
|
|
flag1 |
1 |
4 |
|
|
loop1 |
2 |
3 |
|
|
i |
3 |
8 |
|
|
len |
4 |
1 |
|
|
chain |
5 |
4 |
|
|
0 |
6 |
4 |
|
|
1 |
7 |
4 |
|
|
48 |
8 |
1 |
|
|
57 |
9 |
1 |
|
|
5 |
10 |
1 |
|
|
з2=10 |
N2=31 |
Реальная длина приведенного фрагмента программы составляет:
Метрика длины
Найдем теоритический показатель длины, используя уравнение длины, гипотезы М.Х. Хостела:
Метрика объема
Минимальная длина зависит только от числа элементов в словаре з. Например, словарь из восьми различных элементов требует восемь различных знаков, или, что то же самое, восемь возможных значений двоичного числа, состоящего из трех разрядов. В общем случае есть минимальная длина (в битах) всей программы.
Соответствующая метрическая характеристика размера любой реализации какого-либо алгоритма, называемая объемом V, может быть определена как:
Обозначив соответствующие программные параметры наиболее сжатой формы алгоритма звездочками, получим, что минимальный (или потенциальный) объем:
Но в минимальной форме ни операторы, ни операнды не требуют повторений, поэтому:
Кроме того, известно минимально возможное число операторов для любого алгоритма. Каждый алгоритм должен включать один оператор для имени функции или процедуры и один в качестве символа присваивания или группировки, т. е. . Тогда для потенциально объема можно записать следующее уравнение:
В рассматриваемом примере реальный объем составляет:
Чтобы найти потенциальный объем, нам нужно только подсчитать число требуемых входных и выходных параметров. ВданномслучаеэтоForm1->Label14->Caption, Form1->Label15->Caption, Form1->Label16->Caption,Form1->Label17->Visible, такчто.Следовательно, потенциальный объем:
Метрика уровня реализации
С использованием значений реального и потенциального объема ПС можно определить метрику качества программирования . L
Нередко целесообразно определить уровень программы, не прибегая к оценке ее теоретического объема, поскольку список параметров программы часто зависит от реализации и может быть искусственно расширен. Это приводит к увеличению метрической характеристики качества программирования. М. Холстед предлагает аппроксимировать эту оценку выражением, включающим только фактические параметры, т. е. параметры реальной программы:
Метрика интеллектуального содержание
Полученная характеристика уровня программы , позволяет определить метрику интеллектуального содержания I, которая рассматривается как интеллектуальное содержание конкретного алгоритма, инвариантное по отношению к используемым языкам реализации:
= 22,001
Введение характеристики I позволяет определить умственные затраты на создание программы. Процесс создания программы условно можно представить как ряд операций:
1) осмысление предложения известного алгоритма;
2) запись предложения алгоритма в терминах используемого языка программирования, т. е. поиск в словаре языка соответствующей инструкции, ее смысловое наполнение и запись.
8.2 Метрика сложности управление программ
Метрика Мак-Кейба
Впервые графическое представление программ было предложено Мак-Кейбом. Основной метрикой сложности он предлагает считать цикломатическую сложность графа программы, или, как ее еще называют, цикломатическое число Мак-Кейба, характеризующее трудоемкость тестирования программы.
Для вычисления цикломатического числа Маккейба применяется формула
где e- число дуг ориентированного графа G; v- число вершин;p - число компонентов связности графа.
Граф имеет вид:
Показать четыре теста позволяющих проверить работоспособность из условия прохождения по всем участкам
8.3 Метрика уровня комментированности
Наиболее простой метрикой стилистики и понятности программ является оценка уровня комментированности программы. Исходя из практического опыта, принято считать, что уровень комментированности больше 0,1. Проверим это на файле Unit1.cpp:
9. Тестирование программных средств
9.1 Описание процесса тестирование
Тестирование - неотъемлемая составляющая процесса программной инженерии, один из методов улучшения качества разработанного программного обеспечения системы посредством выявления дефектов, не обнаруженных ранними видами проверок. Стандарт ANSI/IEEE Std. 610.12 определяет термин testing в самом его широком смысле как любое действие по анализу ПО (включая методы как динамической, так и статической проверки). Другое определение: «тестирование - процесс выполнения программы (или ее части) с целью обнаружения ошибок. Отладка (de-bugging) - диагностирование точной природы известных ошибок и их исправление».
Тестирование - процесс выполнения программной системы (или элементов ПС) с целью проверки ее соответствия установленным требованиям и обнаружения дефектов.
Тестирование заключается в динамической проверке поведения программы на конечном множестве тестовых данных, специальным образом выбранных из бесконечного входного пространства, на соответствие установленному ожидаемому поведению.
В данной ПС выбран один из трех методов направленного поиска ошибок - предположение об ошибках (errorguessing). Согласно этому методу на основании «исторической» информации об ошибках, обнаруженных в подобных программах, опыта тестировщика, а также каталогов известных ошибок, составляется список предполагаемых ошибок и ошибочных ситуаций. Одним из «классических» примеров применения метода является проверка деления на 0. В традиционной классификации метод относится к категории методов «черного ящика».
Упрощенная структура описания наборов тестов: решение при 4-х заданных значениях
Дата: 24.05.11 Автор: Щербаков Д.В.
Идентификатор теста: 1 Тип: тест-функций
Описание: решение при 4-х заданных значениях
ПС\Версия\Модуль\Объект: ПС «Вектор»
Цель тестирования: найти решение при 4х заданных значениях
Приоритет: высокий.
Предусловие выполнения: наличие .exe файла программы.
Описание тестовых условий:
a. Правильные условия: ввод чисел, длина которых не более 5 символов.
число в диапазоне от -25 до 25
b. Неправильные условия: заполнение менее чем 4 поле
Тестовые данные:
a. Для правильных условий: x1 - 12, x2 - 1.1, x3 - 24, x4 - -6,8
b. Для неправильных условий: x1 - 12, x2 - 1.1, x3 - 24, x4 - __
Ожидаемое поведение (результаты):
a. Для правильных условий: вывод ответа.
b. Для неправильных условий: вывод сообщения об ошибке неверности введенных данных.
Полученные результаты: для верно введенных данных получаем ответ, для неверно - ошибку.
Отклонения: -
Идентификатор проблемы: 0
Идентификатор тестовой процедуры: 1
Упрощенная структура описания наборов тестов: время ответа не должно превышать больше 1 секунды
Дата: 24.05.11 Автор: Щербаков Д.В.
Идентификатор теста: 2 Тип: тест-функций
Описание: время ответа не должно превышать больше 1 секунды
ПС\Версия\Модуль\Объект: ПС «Вектор»
Цель тестирования: выявить время за котороепроисходит обработка введеныхданных.
Приоритет: средний.
Предусловие выполнения: наличие .exe файла программы.
Описание тестовых условий:
a. Правильные условия: -
b. Неправильные условия: -
Тестовые данные:
a. Для правильных условий: любые введенные данные
b. Для неправильных условий: -
Ожидаемое поведение (результаты):
a. Для правильных условий: вывод сообщение\ответа в течение 1й секунды.
b. Для неправильных условий:вывод сообщение\ответа более 1й секунды , зависание.
Полученные результаты: для введённых любых данных , время сообщение\ответа не более 1й секунды
Отклонения: -
Идентификатор проблемы: 0
Идентификатор тестовой процедуры: 2
Упрощенная структура описания наборов тестов: работа без сбоев в течение 2 часов
Дата: 24.05.11 Автор: Щербаков Д.В.
Идентификатор теста: 3 Тип: тест-функций
Описание: работа без сбоев в течение 2 часов
ПС\Версия\Модуль\Объект: ПС «Вектор»
Цель тестирования: выявить все сбои в течение 2х часов работы программы
Приоритет: средний
Предусловие выполнения: наличие .exe файла программы.
Описание тестовых условий:
a. Правильные условия: -
b. Неправильные условия: -
Тестовые данные:
a. Для правильных условий: любые введенные данные
b. Для неправильных условий: -
Ожидаемое поведение (результаты):
a. Для правильных условий:отсутствие сбоев в течение 2х часов
b. Для неправильных условий:сбой программы в течение 2х часов, зависание.
Полученные результаты: для введённых любых данных , при работе с программой в течение 2х часов сбоев не произошло.
Отклонения: -
Идентификатор проблемы: 0
Идентификатор тестовой процедуры: 3
Упрощенная структура описания наборов тестов: возможность для ввода исходных данных с клавиатуры или с файла.
Дата: 24.05.11 Автор: Щербаков Д.В.
Идентификатор теста: 4 Тип: тест-функций
Описание: возможность для ввода исходных данных с клавиатуры или с файла.
ПС\Версия\Модуль\Объект: ПС «Вектор»
Цель тестирования: проверить возможность ввода данных как их файла так и в ручную
Приоритет: средний
Предусловие выполнения: наличие .exe файла программы и input.txtдля чтение данных
Описание тестовых условий:
a. Правильные условия: наличие кнопки «Считать из файла», поля для ввода в ручную
b. Неправильные условия: отсутствие кнопки «Считать из файла» или поля для ввода в ручную
Тестовые данные:
a. Для правильных условий: -
b. Для неправильных условий: -
Ожидаемое поведение (результаты):
a. Для правильных условий:при нажатие кнопки «Считать из файла» данные из файла перенесутся в поля для ручного ввода
b. Для неправильных условий:данные не возможно перенести из файла в поля из программы
Полученные результаты: при нажатии кнопки «Считать из файла», данные успешно перенесены в 4 поля для ручного ввода
Отклонения: обязательное присутствие файлаinput.txt
Идентификатор проблемы: 1
Идентификатор тестовой процедуры: 4
Упрощенная структура описания наборов тестов: вывод ответа в виде графика
Дата: 24.05.11 Автор: Щербаков Д.В.
Идентификатор теста: 5 Тип: тест-функций
Описание: вывод ответа в виде графика
ПС\Версия\Модуль\Объект: ПС «Вектор»
Цель тестирования: проверить возможность ввода в виде графика
Приоритет:низкий
Предусловие выполнения: наличие .exe файла программы
Описание тестовых условий:
a. Правильные условия: -
b. Неправильные условия:-
Тестовые данные:
a. Для правильных условий: ввод корректных данных
b. Для неправильных условий: ввод букв, знаков, пробелов, нескольких запятых и знаков минус
Ожидаемое поведение (результаты):
a. Для правильных условий:вывод ответа в в виде графика
b. Для неправильных условий:ошибка ввода данных
Полученные результаты: при правильных данных, вывод графика на экран
Отклонения: -
Идентификатор проблемы: -
Идентификатор тестовой процедуры: 5
Упрощенная структура описания наборов тестов:работапод Windows серии XP
Дата: 24.05.11Автор: Щербаков Д.В.
Идентификатор теста: 6 Тип: комплексный тест
Описание: работа под Windows серии XP
ПС\Версия\Модуль\Объект: ПС «Вектор»
Цель тестирования: проверить совместимости с WindowsXP
Приоритет: высокий
Предусловие выполнения: наличие .exe файла программы
Описание тестовых условий:
c. Правильные условия: ОС WindowsXP
d. Неправильные условия: иные ОС
Тестовые данные:
c. Для правильных условий: -
d. Для неправильных условий: -
Ожидаемое поведение (результаты):
c. Для правильных условий: запуск приложение , стабильная работы
d. Для неправильных условий: не запуск, зависание приложение
Полученные результаты: при правильных данных, программа запустилась и работала стабильно
Отклонения: -
Идентификатор проблемы: -
Идентификатор тестовой процедуры: 6
Упрощенная структура описания наборов тестов: проверка правильности ввода данных
Дата: 24.05.11 Автор: Щербаков Д.В.
Идентификатор теста:7 Тип: тест-функций
Описание: решение при 4-х заданных значениях
ПС\Версия\Модуль\Объект: ПС «Вектор»
Цель тестирования: выявить ошибки в коде, который отвечает за обработку введенияданных.
Приоритет: высокий.
Предусловие выполнения: наличие .exe файла программы.
Описание тестовых условий:
a. Правильные условия: ввод чисел, длина которых не более 5 символов.
число в диапазоне от -25 до 25
b. Неправильные условия: ввод любых знаков, кроме чисел или не заполнение полей с данными.
Тестовые данные:
a. Для правильных условий: x1 - 12, x2 - 1.1, x3 - 24, x4 - -6,8
b. Для неправильных условий: x1 - 123, x2 - 124321, x3 - jhg, x4 - --87,,
Ожидаемое поведение (результаты):
a. Для правильных условий: вывод ответа.
b. Для неправильных условий: вывод сообщения об ошибке неверности введенных данных.
Полученные результаты: для верно введенных данных получаем ответ, для неверно - ошибку.
Отклонения: число ,1 или ,011 будет отображаться как 0,1 или 0,011 соответственно.
Идентификатор проблемы: 2
Идентификатор тестовой процедуры:7
9.2 Метрики тестирования
Метрики для включения в план измерений процесса тестирования должны выбираться таким образом, чтобы служить объективными индикаторами процесса тестирования и текущего состояния ПC.
Метрики прогнозирования дефектов. По некоторым данным, количество дефектов, оставшихся после автономного и интеграционного тестирования, колеблется в диапазоне от 1 до 14 на KSLOC, а в среднем - 10, то есть, до 1%. Для прогнозирования количества дефектов на уровне отдельных компонентов (до начала тестирования) можно использовать зависимость:
Дпрогн = V1.2
где V-размер в условных единицах функциональности, 1.2 - показатель степени.
Дпрогн = 0,3311,2 = 0,265
Метрики оценивания. Предназначены для оценивания текущего состояния ПС (метрики продукта) в процессе тестирования. Основные категории метрик оценивания:
a) метрики подсчета дефектов.
b) метрики тенденций дефектов.
c) метрики надежности.
Таблица 7
Метрики подсчета дефектов
|
Метрика |
Обозначение |
Формула |
Значение |
|
|
Количество дефектов |
Дфакт |
Сумма всех дефектов |
Дфакт = 2 |
|
|
Плотность дефектов |
Пл_Дфакт |
Пл_Дфакт = Дфакт/Размер |
Пл_Дфакт = 2/331 = 0,006 |
Метрики тенденций дефектов (или профили дефектов) - группа метрик, которые предназначены для определения тенденций дефектов в ПС, а также динамики устранения дефектов. Профили дефектов могут вычисляться по любой классификационной категории: приоритетам устранения, типам, серьезности.
Таблица 8
Метрики профилей дефектов
|
Метрика |
Обозначение |
Формула |
Значение |
|
|
Профиль открытых дефектов |
Пр.Доткр |
Пр.Доткр = Днеустр/Дфакт |
Пр.Доткр = 1 |
|
|
Профиль закрытых дефектов |
Пр.Дзакр |
Пр.Дзакр = Дустр/Дфакт |
Пр.Дзакр = 0/2=0 |
|
|
Профиль серьезности |
ПрСер |
ПрСер = Дсерье/Дфакт |
ПрСер = 1/2 = 0,5 |
|
|
Средний возраст открытых дефектов |
ВОЗРоткр |
ВОЗРоткр = Днейоткр/Доткр |
ВОЗРоткр = 24/1 = 24 |
|
|
Средний возраст закрытых дефектов |
ВОЗРзакр |
ВОЗРзакр = Днейзакр/Дзакр |
ВОЗРзакр = 0 |
Метрики надежности - вычисляются по данным об отказах и требуют помимо подсчета отказов (дефектов) измерения интервалов времени между отказами.
Таблица 9
Метрики надежности
|
Метрика |
Обозначение |
Формула |
Значение |
|
|
Интенсивность отказов |
FR |
FR = Дфакт/Т(мин) |
FR = 2/10 |
|
|
Среднее время между отказами |
MTBF |
MTBF = Tc(мин)/Дфакт |
MTBF = 8/1 |
Таблица 10
Метрики состояния процесса тестирования
|
Метрика |
Обозначение |
Формула |
Значение |
|
|
Динамика выполнения тестов |
Твып |
Твып = Тфакт/Тплан |
Твып = 7/7 = 1 |
|
|
Динамика обнаружения дефектов |
Тдин |
Тдин = Тдеф/Тфакт |
Тдин = 2/7 = 0,28 |
|
|
Общее состояние выполнения тестирования |
Т проц |
Тпроц = Тпр/Тплан |
Тпроц = 100% |
Метрики оценки продолжительности и трудоемкости тестирования.
Продолжительность тестирования может вычисляться в единицах календарного времени тестирования (днях) (включая время на разработку планов, тестов, подготовку данных, выполнение тестов, регистрацию результатов и др.).
Продолжительность = 24 дня
Трудоемкость тестирования Tm (чел.-дней) - может вычисляться как сумма периодов времени, потраченного участниками процесса тестирования на выполнение задач тестирования.
где Ді - время (дней), затраченное одним участником, n - количество участников.
Дi = 24; n = 1.
Tm = 24 человеко-дней.
10. Оценка надежности
Одной из важнейших характеристик качества программного средства является надежность.
Надежность- свойство программного средства сохранять работоспособность в течение определенного периода времени, в определенных условиях эксплуатации с учетом последствий для пользователя каждого отказа.
Работоспособным называется такое состояние программного средства, при котором оно способно выполнять заданные функции с параметрами, установленными требованиями технического задания. С переходом в неработоспособное состояние связано событие отказа.
Причиной отказа программного средства является невозможность его полной проверки в процессе тестирования и испытаний. При эксплуатации программного средства в реальных условиях может возникнуть такая комбинация входных данных, которая вызовет отказ, следовательно, работоспособность программного средства зависит от входных данных, и чем меньше эта зависимость, тем выше уровень надежности.
Для оценки надежности используются три группы показателей: качественные, порядковые и количественные.
10.1 Модель Коркорэна
Применение модели предполагает знание следующих ее показателей:
· модель содержит изменяющуюся вероятность отказов для различных источников ошибок и соответственно разную вероятность их исправления;
· в модели используются такие параметры, как результат только N испытаний, в которых наблюдается Ni ошибок i-го типа;
· выявление в ходе N испытаний ошибки i-го типа появляется с вероятностью ai.
Показатель уровня надежности R вычисляют по следующей формуле:
где N0- число безотказных (или безуспешных) испытаний, выполненных в серии из N испытаний, k - известное число типов ошибок, Yi- вероятность появления ошибок, при Ni> 0, Yi= ai, при Ni= 0, Yi = 0.
Было проведено 7 испытаний программы. 2 из 7 испытаний прошли безуспешно, а в остальных случаях получились следующие данные:
Таблица 11
Результаты тестирование
|
Тип ошибки |
Вероятность появления Yi |
Вероятность появления ошибки. При исп. Ni |
|
|
1. Ошибки вычисления |
0,09 |
0 |
|
|
2. Логические ошибки |
0,26 |
1 |
|
|
3. Ошибки ввода/вывода |
0,22 |
1 |
|
|
4. Ошибки манипулирование данными |
0,18 |
0 |
|
|
5. Ошибки сопряжения |
0,17 |
0 |
|
|
6. Ошибки определение данных |
0,08 |
0 |
|
|
7. Ошибки БД |
0,06 |
0 |
Размещено на Allbest.ru
Подобные документы
Подсчет количества функциональных точек. Расчет трудозатрат на разработку программного средства и ориентировочного времени его разработки, модель жизненного цикла. Разработка технического задания на создание автоматизированной системы, требования к ней.
курсовая работа [2,0 M], добавлен 11.01.2014Разработка программы ведения базы данных для отделения диспансеризации подростков студенческой поликлиники. Требования к программному изделию и программной документации. Стадии и этапы разработки программы. Требования к написанию пояснительной записки.
курсовая работа [18,9 K], добавлен 02.05.2009Требования к программе или программному продукту. Условия эксплуатации и требования к параметрам технических средств. Программное обеспечение, рекомендуемое для функционирования программы. Руководство системного программиста и настройка программы.
отчет по практике [1,1 M], добавлен 22.07.2012Список используемых программных продуктов на предприятии ООО "FasTel". Требования к оборудованию, выбор среды передачи данных. Разработка топологии сети. Основные требования, предъявляемые к серверной комнате. Выбор сетевого шкафа и оборудования.
реферат [3,1 M], добавлен 09.12.2014Разработка программного обеспечения по моделированию рельефа местности на основе топографических карт и прочих объектов на ней. Цифровые модели рельефа. Бикубическая интерполяция высотных данных. Технические требования к программному изделию.
отчет по практике [246,4 K], добавлен 06.04.2013Выбор программных средст, основные требования. Разработка программного обеспечение для автоматизации учета использования и обслуживания транспортных средств. Инфологическая модель базы данных. Разработка SQL запросов, алгоритмов. Структура базы данных.
курсовая работа [1,0 M], добавлен 16.02.2015Анализ методов оценки надежности программных средств на всех этапах жизненного цикла, их классификация и типы, предъявляемые требования. Мультиверсионное программное обеспечение. Современные модели и алгоритмы анализа надежности программных средств.
дипломная работа [280,5 K], добавлен 03.11.2013Проблема безопасности операционных систем. Функции подсистемы безопасности. Идентификация пользователей, программные угрозы (атаки). Типы сетевых атак. Жизненный цикл разработки безопасных программных продуктов. Оценка атак на программное обеспечение.
презентация [1,4 M], добавлен 24.01.2014Сущность понятия "программное обеспечение". Типы прикладных программ. Современные системы программирования для персональных компьютеров. Уровни программного обеспечения: базовый, системный, служебный. Классификация служебных программных средств.
реферат [20,2 K], добавлен 01.04.2010Методика и основные этапы разработки информационной системы туристического агентства, основные требования к ней. Внутренняя структура и элементы данной системы, принцип работы с ней и оценка функциональности. Описание таблиц разрабатываемой базы данных.
контрольная работа [881,5 K], добавлен 08.06.2014
