Разработка и стандартизация программных средств

Реферат

Разработка и стандартизация программных средств 1

Рисунок 4 — Установка драйвера

В поле «Источник данных» (см. Рисунок 4) вносим псевдоним базы данных, через которое мы впоследствии будем подключать компоненты BDE (« е»).

После того как псевдоним базы данных создан, откроем новый проект в BorlandDelphi 7, установив на форме компоненты DataSource и Table. В окне свойств DataSource, поля DataSetвыберем Table1, DatabaseName выберем псевдоним базы данных «kassa», а в Name — имя таблицы «касса». Присвоив свойству Active значение True, мы активируем подключение к базе данных. Эти же свойства устанавливаем и в компоненте Table. Для отображения данных таблицы необходимо перенести на форму DBGrid, и, если настройка свойств прошла успешно, данные таблицы «kassa» появятся в полях DBGrid (см. Рисунок 5).

В данном проекте используются компоненты:

  • Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, DB, DBTables, Grids, DBGrids, ExtCtrls, DBCtrls, StdCtrls;

Разработка и стандартизация программных средств 2

Рисунок 5- Установленные компоненты DataSource ,Table, DBGrid, MainMenu

Разработка и стандартизация программных средств 3

Рисунок 6-Кнопки DBNavigator: добавление записи, удаление, редактирование, обновление и сохранение записей

2. Модели оценки характеристик качества и надежности ПО

Размерно-ориентированные метрики. Функционально- ориентированные метрики. Пример применения метрик. Достоинства и недостатки размерно – ориентированных и функционально-ориентированных метрик.

Размерно-ориентированные метрики

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC – оценках (LinesOfCode).

LOC — оценка – это количество строк в программном продукте.

Исходные данные для расчета этих метрик сводятся в таблицу (табл.2).

Исходные данные для расчета LOC- метрик

Таблица 2.

Проект Затраты, чел.-мес. Стоимость тыс. $ КLOC, тыс. LOC Ошибки Количество человек
А01 1 50 0,073 18 11 1

Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте А01 показывает: 73 строки программы были разработаны за 1 чел.-мес. И стоили $50 000. Кроме того, по проекту было разработано 20 страниц документации, а в течение первого года эксплуатации было зарегистрировано 11 ошибок. Разрабатывали проект один человек.

На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества проекта:

  • Производительность = Длина / Затраты =0,073/1=0,073 (тыс.LOC/чел.-мес.);
  • Качество = Ошибки / Длина=11/0,073=150,68 (Единиц/тыс. LOC);
  • Удельная стоимость = Стоимость /Длина=50/0,073=684,93 (тыс.$/LOC);
  • Документированность = Страниц_Документа / Длина=20/0,073=232?56 (Страниц/тыс.LOC)

Достоинства размерно-ориентированных метрик:

  • широко распространены;
  • просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

  • зависимы от языка программирования;
  • требуют исходных данных, которые трудно получить на начальной стадии проекта;
  • не приспособлены к непроцедурным языкам программирования.

Функционально-ориентированные метрики

Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC – оценки при этом рассматривается не размер, а функциональность или полезность продукта.

Используется 5 информационных характеристик.

Количество внешний вводов

Количество внешних выводов

Количество внешних запросов

Количество внутренних логических файлов

Количество внешних интерфейсных файлов

транзакция

Внешний ввод

Внешний вывод —

Внешний запрос –

Внутренний логический файл –

Внешний интерфейсный файл –

Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга. Для транзакций ранжирование основано на количестве ссылок и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов-элементов записей и типов элементов данных, входящих в файл.

Тип элемента-записи – подгруппа элементов данных, распознаваемая пользователем в пределах файла.

Тип элемента данных – уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. Примеры элементов данных для различных характеристик приведены в табл.4, 5 и содержат правила учета элементов из графического интерфейса пользователя (ГИП).

Примеры элементов данных

Таблица 3.

Информационная характеристика Элементы данных
Внешние вводы Поля ввода данных, сообщения об ошибках, вычисляемые значения, кнопки
Внешние выводы Поля данных в отчетах, вычисляемые значения, сообщения об ошибках, заголовки столбцов, которые читаются из внутреннего файла
Внешние запросы

Вводимые элементы: поле, используемое для списка, щелчок мыши.

Выводимые элементы: отображаемые на экране поля.

Правила учета элементов данных из ГИП

Таблица 4.

Элемент данных Правило учета
Группа радиокнопок Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных
Группа флажков (переключатели) Так как в группе пользователь может выбрать несколько флажков, каждый флажок считают элементом данных
Командные кнопки Командная кнопка может определять действия добавления, изменения, запроса. Кнопка ОК может вызвать транзакции. Кнопка Next может быть входным элементом запроса или вызвать другую транзакцию.
Списки Список может быть внешним запросом, но результат запроса может быть элементом данных внешнего вида.

Например, ГИП для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый_Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (Добавить, Изменить, Удалить).

В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка).

Обычно этому экрану ГИП соответствует несколько транзакций. Типичный экран включает несколько внешний запросов, сопровождающих внешний ввод.

Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл.5-9 (числовая оценка указана в круглых скобках).

Использовать их очень просто. Например, внешнему вводу, который ссылается на два файла и имеет 7 элементов данных по табл.6 назначается средний ранг и оценка сложности 4.

Ранг и оценка сложности внешних вводов

Таблица 5.

Ссылки на файлы Элементы данных
1-4 5-15 >15
0-1 Низкий (3) Низкий (3) Средний (4)
2 Низкий (3) Средний (4) Высокий (6)
>2 Средний (4) Высокий (6) Высокий (6)

Ранг и оценка сложности внешних выводов

Таблица 6.

Ссылки на файлы Элементы данных
1-4 5-19 >19
0-1 Низкий (4) Низкий (4) Средний (5)
2-3 Низкий (4) Средний (5) Высокий (7)
>3 Средний (5) Высокий (7) Высокий (7)

Ранг и оценка сложности внешних запросов

Таблица 7.

Ссылки на файлы Элементы данных
1-4 5-19 >19
0-1 Низкий (3) Низкий (3) Средний (4)
2-3 Низкий (3) Средний (4) Высокий (6)
>3 Средний (4) Высокий (6) Высокий (6)

Ранг и оценка сложности внутренних логических файлов

Таблица 8.

Ссылки на файлы Элементы данных
1-19 20-50 >50
0-1 Низкий (7) Низкий (7) Средний (10)
2-5 Низкий (7) Средний (10) Высокий (15)
>5 Средний (10) Высокий (15) Высокий (15)

Ранг и оценка сложности внешних интерфейсных файлов

Таблица 9

Ссылки на файлы Элементы данных
1-19 20-50 >50
0-1 Низкий (5) Низкий (5) Средний (7)
2-5 Низкий (5) Средний (7) Высокий (10)
>5 Средний (7) Высокий (10) Высокий (10)

После сбора всей необходимой информации приступают к расчетам метрики – количества функциональных указателей FP (FunctionPoints).

Исходные данные для расчета сводятся в табл. 10. В таблицу заносится количественное значение характеристики каждого вида (по всем уровням сложности).

Места подстановки значений отмечены прямоугольником (этот символ играет роль метки — заполнителя).

Количественные значения характеристик умножаются на числовые оценки сложности. Полученные в каждой строке значения суммируются, давая полное значение для данной характеристики. Эти полные значения суммируются по вертикали, формируя общее количество.

Исходные данные для расчета FP – метрик

Таблица 10.

Имя характеристики Ранг, сложность, количество
Низкий Средний Высокий Итого
Внешние вводы 3*3=9 3*4=12 3*6=18 =29
Внешние выводы 6*4=24 6*5=30 6*7=42 =96
Внешние запросы 0*3=0 0*4=0 0*6=0 =0
Внутренние логические файлы 1*7=7 1*10=10 1*15=15 =32
Внешние интерфейсные файлы 1*5=5 1*7=7 1*10=10 =22
Общее количество =179

Количество функциональных указателей вычисляется по формуле:

FP=Общее количество*(0,65+0,01*4)=208*(0,65+0,01*4)=143,52, (1)

Где F i – коэффициент регулировки сложности (I=1..14).

Каждый коэффициент может принимать следующие значения: 0- нет влияния, 1- случайное, 2- небольшое, 3- среднее, 4 – важное, 5 – основное. Значения выбираются эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (табл.11).

После вычисления FP на его основе формируются метрики производительности, качества и другие оценки.

Производительность = ФункцУказатель / Затраты =143,52/1=143,52 (FP/чел.-мес.);

  • Качество = Ошибки / ФункцУказатель=11/143,52=0,08 (Единиц/FP);
  • Удельная Стоимость = Стоимость / ФункцУказатель=50/143,52=0,39 (Тыс.$/FP);

Документированность=СтраницДокумента/ФункцУказатель=20/143,52=0,14 (Страниц/FP)

Определение системных параметров приложения

Таблица 11.

Системный параметр Описание
1 Передачи данных Сколько средств данных требуется для передачи или обмена информацией с приложением или системой?
2 Распределенная обработка данных Как обрабатываются распределенные данные и функции обработки?
3 Производительность Нуждается ли пользователь в фиксации времени ответа или производительности?
4 Распространенность используемой конфигурации Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение?
5 Скорость транзакций Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)?
6 Оперативный ввод данных Какой процент информации нужно вводить в режиме онлайн?
7 Эффективность работы конечного пользователя Приложение проектировалось для обеспечения эффективной работы конечного пользователя?
8 Оперативное обновление Как много внутренних файлов обновляется в онлайновой транзакции?
9 Сложность обработки Выполняет ли приложение интенсивную логическую или математическую обработку?
10 Повторная используемость Приложение разрабатывалось для удовлетворения требований одного или многих пользователей?
11 Легкость инсталляции Насколько трудны преобразования и инсталляция приложения?
12 Легкость эксплуатации Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления?
13 Разнообразные условия размещения Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций?
14 Простота изменений Была ли спроектирована, разработана и поддержана в приложении простота изменения?

метрики свойств

количество алгоритмов

Исходные данные для расчета указателя свойств

Таблица 12.

Характеристика Количество Сложность Итого
1 Вводы 3 *4 =12
2 Выводы 6 *5 =30
3 Запросы 0 *4 =0
4 Логические файлы 1 *7 =7
5 Интерфейсные файлы 1 *7 =7
6 Количество алгоритмов 5 *3 =15
Общее количество =71

После заполнения таблицы по формуле (1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей.

Достоинства функционально-ориентированных метрик:

  • не зависят от языка программирования;
  • Легко вычисляются на любой стадии проекта.

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

FP – оценки легко пересчитать в LOC– оценки. Как показано в табл.13, результаты пересчета зависят от языка программирования, используемого для реализации ПО.

Пересчет FP – оценок в LOC – оценки

Таблица 13.

Язык программирования Количество операторов на 1 FP
Ассемблер 320
С 128
Паскаль 90
С++ 64
Java 53
Visual Basic 32
Visual С++ 34
Delphi Pascal 29
HTML 3 15
LISP 64
Prolog 64

Заключение

В данном курсовом проекте было разработано программное средство «Учет движения денежных средств по кассе». при помощи двух программных продуктов: MicrosoftAccess и BorlandDelphi 7. А так же были рассмотрены надежность и качество разработанного программного средства, раскрыты функции и задачи.

1. Диго С.М. Базы данных: проектирование и использование. Учебное пособие для вузов. – Москва.: Финансы и статистика, 2005.

2. Кузин А.В., Демин В.М.Разработка баз данных в системе MicrosoftAccess: Учебник – Учебник – м.: Форум: Инфра-М, 2005г.

3. Тиори Т., Фрай Дж. : Проектирование структур баз данных. М, 1985.

4. Гофман В., Хомоненко А.: Delphi 6 в подлиннике. СПб,2001.

5. Пестрнков В. М., Маслобоев А. Н.: Delphi на примерах.,2005.

6. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем., Под редакцией Тельнова Ю.Ф.. – Москва.: Финансы и статистика, 2003.

7. Дунаев С. В. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования – М.: Диалог – МИФИ, 1999. – 416 с.

8. Сигнор Р., Стегман М. О. Использование ODBC для доступа к базам данных – М.: БИНОМ, 1995. – 384 с.

9. Фленов М.Е. Библия Delphi. – СПб.: БХВ-Петербург, 2004. – 880 с.