При выборе пункта Просмотр архива осуществляется просмотр архива заявок и ответов.

При выборе пункта Выход происходит завершение работы с программой и выход из нее в ОС.



Рис. 2.1 Схема диалога

Дерево функций задачи «Работа с заявками» соответствует сценарию диалога задачи и показывает структуру диалога пользователя с программой: все возможные варианты выбора пунктов меню с их обозначениями, которые будут использоваться при описании технологического процесса задачи. Дерево разговоров представлено на рисунке ниже.



Рис. 2.2 Дерево-функций

2.3 Выбор концептуальной модели

Для выбора концептуальной модели данных рассмотрим три их разновидности:

1. Семантическая модель;

2. Фреймы;

3. Модель «сущность-связь».

Семантическая модель основывается на построении семантической сети. Под семантической сетью понимают ориентированный граф, состоящий из помеченных вершин и дуг и задающий объекты и отношения предметной области. Семантические сети обладают рядом достоинств, а именно:

1. Описание объектов предметной области происходит естественным языком;

2. Все записи, поступающие в БД накапливаются в относительно однородной структуре.

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

Фреймы выражаются структурами данных с привязанными процедурами обработки этих данных. Фреймы могут быть следующих видов: событийные, характеристики, логические предикаты. Использование фреймовой модели так же нецелесообразно, поскольку данная модель не отражает типы связей в реляционной модели данных.

Модель «сущность-связь» описывается в терминах сущность, связь, значение. Сущность - понятие которое может быть идентифицировано. Связь - соединение сущностей. Для представления связей и сущностей введен специальный метод: ER-диаграма. Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность - это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя или более сущностями типа «многие - ко - многим» или подобные им. Характеристическая сущность (или характеристика) представляет собой сущность, единственная цель которой, в рамках рассматриваемой предметной области, состоит в описании или уточнении некоторой другой сущности. ER-диаграма - графическое представление взаимосвязей сущностей. Каждое множество сущностей представляется прямоугольником, а множество связей - ромбом. Связи могут быть трех типов: «один к одному», «один ко многим», «многие ко многим». данные типы связи присущи реляционной модели, как и сущности, которым в реляционной модели соответствуют таблицы.

Вывод: в связи с тем, что модель «сущность-связь» наиболее близка по принципам организации к реляционной модели и реализация последней на основе первой наиболее удобна, то в качестве концептуальной модели выбрана модель «сущность-связь».

2.4 Процесс моделирования

2.4.1 Выделение сущностей

Сущность «клиент» является стержневой сущностью разрабатываемой модели. С клиентом заключается договор, на основании которого ведется вся остальная деятельность, лицевой счет, проводки, учет проводок. В качестве ключа для данной сущности вводится атрибут №Клиента.

Все сущности, их атрибуты и ключи представлены в табл. 2.1.

Таблица 2.1

Название сущности	Атрибут	Ключ
Кассир	№Договора, дата договора, сумма договора, срок действия.	№Договора
Клиент	№Клиента, наименование заказчика, адрес, телефон.	№Клиента
Лицевой счет	№Лицевого счета.	№Лицевого счета
Проводка	№Проводки.	№Проводки.
Договор	№Договора, дата заказлючения, номер счета.	№Договора
Счет	№Счета, сумма счета.	№Счета

2.4.2 Выделение сущностей между связями

Выделение связей между сущностями осуществляется на основании анализа предметной области. Все выделенные связи представлены на рис. 2.1



Рис. 2.3. Связи между сущностями

2.4.3 Построение логической модели

Выполнив анализ сущностей и связей меду ними построим логическую модель, в виде отношений (таблица 2.2)

Таблица 2.2

Название сущности	Атрибут	Ключ
Кассир	№Договора, дата договора, сумма договора, срок действия.	№Договора
Клиент	№Клиента, наименование заказчика, адрес, телефон.	№Клиента
Лицевой счет	№Лицевого счета.	№Лицевого счета
Проводка	№Проводки.	№Проводки.
Договор	№Договора, дата заключения, номер счета.	№Договора
Счет	№Счета, сумма счета.	№Счета

Для построения логической модели данных использовалось case - средство ER-Win, которое позволяет проектировать реляционные модели данных как на физическом уровне (ER-диаграмы), так и на физическом (проектирование таблиц БД).

Для построения логической модели данных использовалось case - средство ER-Win, которое позволяет проектировать реляционные модели данных как на физическом уровне (ER-диаграмы), так и на физическом (проектирование таблиц БД).

Логическая модель данных представлена в виде ER-диаграмы на рис. 2.4.

Рис. 2.4 ER-диаграмма модели данных АРМ «Кассир-опперационист»

2.5 Формализация расчетов

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

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

В результате выполненной работы предполагается достигнуть следующих эффектов:

1. уменьшение времени необходимого для учета операций;

2. автоматизация контроля;

3. возможность длительного хранения информации, для возможности более полного расчета эффективности деятельности ОПЕРУ;

4. постоянная известность о сроках оплаты.

5. Предкалькуляция

2.6 Программное обеспечения решения задачи

Алгоритмизация в самом общем виде может быть определена как процесс направленного действия проектировщика (группы проектировщиков), необходимый для выработки алгоритмов, достаточных для реализации создаваемого объекта (системы), удовлетворяющего заданным требованиям. Завершающим этапом алгоритмизации является выпуск набора алгоритмов, отображающий решения, принятые проектировщиком, в форме, необходимой для производства объекта (системы).

2.6.1 Общие положения

Метод - это последовательный процесс создания моделей, которые описывают вполне определёнными средствами различные стороны разрабатываемой программной системы. Методы важны по нескольким причинам. Во-первых, они упорядочивают процесс создания сложных программных систем. Во-вторых, они позволяют менеджерам в процессе разработки оценить степень продвижения и риск.

Обычно методы проектирования делятся на три основные группы;

1. Метод проектирования сверху вниз;

2. Метод потоков данных;

3. Объектно-ориентированное проектирование.

Для структурного проектирования характерна алгоритмическая декомпозиция. Следует отметить, что большинство программ написано в соответствии с этим методом. Тем не менее структурный подход не позволяет выделить абстракции и обеспечить ограничение доступа к данным; он также не предоставляет достаточных средств для организации параллелизма. Структурный метод не может обеспечить создание предельно сложных систем, и он, как правило, неэффективен в объектных и объектно-ориентированных языках программирования. Поэтому данный метод не использовался для проектирования АРМ «Кассир-операционнист».

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

Объектно-ориентированное проектирование (object-oriented design, OOD) - это подход в основе которого лежит представление о том, что программную систему нужно проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определённого класса, причём классы образуют иерархию. Объектно-ориентированный подход отражает топологию новейших языков высокого уровня, таких как Object Pascal, C++, Smalltalk и др. Модели, для проектирования которой используется вышеназванный подход проектирования присущи четыре главных элемента:

1. Абстрагирование;

2. Инкапсуляция;

3. Модульность;

4. Иерархия.

Абстрагирование позволяет выделить существенные характеристики проектируемого объекта, отличающие его от других объектов;

Инкапсуляция - процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение. Она позволяет изолировать контрактные обязательства абстракции от их реализации.

Модульность - свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.

Иерархия - упорядочивание абстракций, расположение их по уровням.

Абстракция и инкапсуляция дополняют друг друга. Абстрагирование направлено на наблюдение поведения объекта извне, а инкапсуляция определяет четкие границы между различными абстракциями, т.е. наблюдение за поведением объекта изнутри.

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

Таким образом, для проектирования АРМ используется объектно-ориентированный подход.

2.6.2 Анализ алгоритмов работы с базой данных

Система управления разработанной БД использует реляционный подход для построения базы данных. Подобные системы основаны на реляционной модели данных, которые используются для моделирования взаимосвязей между объектами реального мира и для хранения данных об этих объектах. Применение реляционной модели данных обусловлено использованием реляционной алгебры и соответствующих алгоритмов и операций для выполнения действий над данными. Использование алгоритмов реляционной алгебры позволяет обеспечить высокую производительность работы с базой данных.

Основные операции реляционной алгебры были впервые предложены Коддом. Он доказал, что запросы, формулируемые с помощью языка исчисления могут быть сформулированы в языках реляционной алгебры и наоборот, тоесть запросы представленные с помощью языка реляционной алгебры могут быть использованы для выполнения запросов к разработанной БД. Ниже приведен ряд запросов к БД:

SELECT nomer_dogovora, zakaz.nomer_ zakaz, dogovor.nomer_ zakaz,

naimen_post

FROM zakaz, dogovor

WHERE zakaz.nomer_ zakaz =dogovor.nomer_ zakaz

SELECT select nomer_lc, lc.nomer_dogovora,

dogovor.nomer_dogovora, naimen_post, lk.nomer_lk,

dogovor.nomer_lk

FROM from zajavka, dogovor, lk

WHERE (zajavka.nomer_dogovora=dogovor.nomer_dogovora)

AND (nomer_lk=dogovor.nomer)

Рассмотрим четыре операции над отношениями:

1. Селекция;

2. Проекция;

3. Теоретико-множественное объединение;

4. Соединение.

Селекция (selected_on - подвергнутые селекции по) уменьшает количество строк в таблице, и ее можно представить как результат разрезания таблицы по горизонтали и удаления ненужных кортежей. Формально селекция записывается так:

R selected_on [<предикат>] {синтаксис языка запросов (SQL)}

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

Операция селекции соответствует программам, которые выбирают записи из файлов и печатают эти записи. Однако условия отбора могут относится только к отдельно взятым записям. Например, невозможно выбрать запись, исходя из того, что значение какого-либо ее поля равно или больше, чем значение этого поля в предидущей записи. В действительности почти невозможно смоделировать поведение автомата с конечным числом состояний, который изменяет свое состояние для каждой записи, изменяя тем самым критерии отбора для следующей записи.

Проекция (projected_to - спроецированное на) уменьшает количество столбцов в таблице; данную операцию можно представить себе как разрезание по вертикали название операции имеет своим источником понятие проекции множества точек N-мерного пространства в пространство с меньшим количеством измерений. Например, в результате проекции множества точек плоскости (Х, У) на ось Х получается множество точек, расположенных на этой оси. К сожалению, значения проекций некоторых «точек» могут совпадать; это произойдет в том случае, когда проекция удалит столбец, входящий в ключ, так что оставшиеся части двух «укороченных» кортежей могут быть идентичными. Тогда придется удалить дубликаты и тем самым уменьшить количество строк, т.е. размер БД. Если хотя бы один из возможных ключей при выполнении проекции останется незатронутым, то дубликатов не будет.

Формально проекция записывается следующим образом:

R projected_to <имя-атрибута>{, <имя-атрибута>}

Где список <имен-атрибутов> означает имена сохраняемых столбцов.

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

Теоретико-множественное объединение (union) имеет два операнда; она берет строки двух таблиц и размещает их друг за другом, формируя одну длинную таблицу. Это возможно лишь в том случае, когда обе таблицы имеют один и тот же тип, т.е. имеют совпадающие названия (имена) и типы столбцов. Такие таблицы называют «совместимыми по объединению». Все дубликаты строк должны быть удалены из отношения-результата. Данная операция аналогична объединению множеств в алгебре, но она является дополнительной по отношению к ограничению, так как имеется возможность восстановить отношение путем объединения двух дополняющих друг друга результатов операции селекции.

Операция теоретико-множественного отношения соответствует известной операции «слияния» файлов. Если известно, что файлы не пересекаются, и если порядок записей не играет роли, то достаточно скопировать один файл в конце другого. Однако, как правило, файлы поддерживаются в порядке первичных ключей, и тогда используются простые алгоритмы слияния., считывающие поочередно записи из каждого файла в зависимости от того, в каком из файлов запись имеет ключ с меньшим значением полей, так что в новый файл записи также будут помещаться в порядке первичных ключей.

Соединение (joined_to - соединение с) имеет два операнда; она определена для любых двух таблиц. Если эти две таблицы не имеют столбцов с совпадающими именами, то соединение ведет себя, как декартово произведение, соединяя каждую строку первой таблицы поочередно с каждой строкой второй таблицы. Если имена всех столбцов этих двух таблиц совпадают, то соединение ведет себя как теоретико-множественное пересечение, и создает таблицу, состоящую из тех строк, которые встречаются в каждой из рассматриваемых двух таблиц (такая таблица может быть и пустой, аналогично пустому множеству). Если у двух таблиц-операндов совпадают лишь некоторые имена столбцов, то в результате соединения получается таблица, содержащая все имена столбцов первой таблицы, а также все те имена столбцов второй таблицы, которые не встретились в первой. Строки результата выбираются из первой таблицы, а дополнительные значения конкатенируются (присоединяются) из тех строк второй таблицы, у которых значения в общих столбцах совпадают. До некоторой степени соединения является дополнением проекции, если осуществить проекцию «исходного» отношения так, чтобы получился набор отношений, каждое из которых сохраняет первичный ключ исходного, то соединение этого отношения восстановит исходное при дополнительном условии, что каждый столбец исходного отношения встречается хотя бы в одной из проекций.

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

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

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

2.6.3 Алгоритмы запросов к БД

Для начала работы с программой необходимо соединиться с базой данных, для чего щелкнуть по команде меню соединится с БД. Если на компьютере пользователя установлен InterBase Local Server и создана база данных, то появится запрос на подтверждение права доступа к БД.

В случае если соединение прошло успешно, то пользователь допускается к работе с АСИС.

2.7 Работа с режимами

Работа с договорами

Работа с договорами включает в себя:

- Работа с клиентами;

- Работа с договорами;

- Работа с валютой;

- Работа с заключенными договорами;

- Работа с ассортиментом договоров;

- Работа с платежами.

Договор заключается клиентом с банком на определенную операцию. С одним поставщиком может быть заключено несколько договоров. В качестве атрибутов договора являются следующие поля: номер договора, код, дата договора, сумма, срок действия договора. Все атрибуты, кроме срока действия договора являются обязательными для заполнения. На основании договора производится дальнейшая деятельность по работе с клиентами. Она заключается в:

- Работа с заявками;

- Работа со счетами;

- Работа с заказами.

Для автоматизации использования АРМ реализована возможность печати бланков документов договора, заявки, заказа.

Добавление нового договора осуществляется путем выбора соответствующей закладки и вводе текста в поля-атрибуты таблицы. Добавление при условии, что для добавляемого договора известен клиент.

Редактирование происходит при нажатии клавиши Enter на выбранной записи. Происходит автоматическое изменение всех полей других таблиц связанных с номером редактируемого договора. Это изменение необходимо для поддержания ссылочной целостности в БД.

Для удаления определенного договора необходимо два раза щелкнуть правой кнопкой мыши на удаляемом договоре. Автоматически удалятся все записи связанные с удаляемым договором.

Работа с клиентами.

Работа с клиентами состоит в добавлении нового клиента, его атрибутов, удалении клиентаа, редактировании атрибутов клиента: код клиента (для каждого заказчика код уникален), лицевой счет, адрес и телефон клиента. Все атрибуты, кроме телефона являются обязательными для заполнения, в случае их незаполнения возникает ошибка.

Добавление клиента производится следующим образом: пользователь выбирает соответствующую таблицу и заполняет атрибуты клиента.

Для редактирования таблицы «клиенты» нужно выбрать запись для редактирования, нажать клавишу Enter и изменить необходимую информацию. Измененные атрибуты заказчика автоматически изменяются в других таблицах.

Удаление записи «клиент» происходит путем двойного щелчка мышью на удаляемой записи. При этом требуется запрос на подтверждение удаления записи.

Работа с платежами.

Таблица «платежи» представляет собой справочник платежей, которые производятся, через ОПЕРА. Атрибуты этой таблицы содержат уникальный код для каждого платежа.

Добавление новой записи в таблицу осуществляется путем ввода информации о платеже в строки таблицы платежи. Редактирование - нажатием клавиши Enter на редактируемой строке и изменении информации.

Удаление - двойным щелчком мыши на удаляемой строке.

Работа с заключенными договорами.

Работа с данной таблицей для пользователя ограничена, поскольку данными для ее заполнения служат ранее заполненные таблицы (договор, клиент).

Пользователь имеет возможность добавлять, редактировать и удалять записи.

Добавить запись можно в случае когда таблица активна, т.е. пользователь осуществляет работу с ней. Таблица автоматически переводится в режим добавления записей при нажатии пользователем клавиши на пустой строке, либо нажатием клавиши Insert. Для редактирования необходимо выбрать запись для редактирования и, нажав клавишу Enter произвести редактирование необходимого поля записи. Удаление происходит путем двойного щелчка мышью на выбранной для удаления записи.

Работа со счетами

Для работа со счетами предлагается закладка «счет», которая содержит таблицу счета и поле для определения оптимального счета. Таблица «счета» включает атрибуты: номер счета, номер заявки, номер договора, сумма счета. Все атрибуты обязательны для заполнения. Ассортимент счета соответствует ассортименту заявки. На закладку выводится информация (либо предоставляется для ввода) только по одному из заключенных договоров, номер которого выбран в таблице ассортимент договоров.

Работа с заказами

Для работы с заказами предлагается две закладки:

- Заказ;

- Все заказы.

В закладку «заказ» включены таблица «заказ» с атрибутами: номер

заказа, номер договора, номер счета, получено, оплачено, и поле для. Пользователю предоставляется возможность добавления, редактирования и удаления записей. Все операции с записями осуществляются для определенного договора, указанного в закладке ассортимент договора. Все атрибуты таблицы обязательны к заполнению. Заполнение полей таблицы оплачено и получено можно осуществлять с выпадающего списка с двумя строками (да, нет).

Печать.

Закладка «печать» используется для печати бланков. Для выбора документа, который необходимо напечатать следует выбрать соответствующий флажок.

2.8 Испытание программного продукта

Надежность программного обеспечения (ПО) есть вероятность его работы без отказов в течении определенного периода времени, рассчитанная с учетом стоимости для пользователя каждого отказа. Надежность программного обеспечения как определяющий элемент его качества закладывается на этапе разработки и проектирования, реализуется на этапе реализации ПО. Выбор критериев, которыми должна определятся надежность ПО, отыскание оптимальной по отношению к этим критериям его структуры, выбор режима работы ПО - вот далеко не полный перечень тех проблем, которые должны быть решены на этапе создания и реализации ПО до его эксплуатации. Поэтому для обеспечения надежности ПО зачастую используют такие термины, как доказательство, тестирование, отладка, контроль и испытание, которые часто используются как синонимы, поэтому приведём эти определения:

1. Тестирование (testing) - процесс выполнения программы или части программы, с намерением или целью найти ошибки;

2. Доказательство (proof) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы.

3. Контроль (verification) - попытка найти ошибки в тестовой, или моделируемой среде;

4. Испытание (validation) - попытка найти ошибки, выполняя программу в заданной реальной среде;

5. Аттестация (certification) - авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторыми заранее определённым стандартом;

6. Отладка (debugging) не является разновидностью тестирования. Хотя «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование - деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки.

Справочные документы

Испытания программного продукта производятся с использованием следующей справочной литературы:

1. ГОСТ Р28195-89 Оценка качества программных средств.

2. ISO/IEC 9126: 1991 Information Technology Software Product Quality Characteristics.

3. Стандарты разработки ПО ESA PSS-05-0-1991.

Краткий обзор верификации

Верификация обозначает:

1. действие по проверке, инспекции, тестированию, контролю процессов, определённых требованиями ANSI -78

2. процесс определения: удовлетворяет ли продукт данной фазе ЖЦ ПО требованиям, сформулированным на протяжение предыдущих фаз;

3. формальное доказательство корректности программы.

4. верификация необходима для обеспечения качественных характеристик продукта.

Ряд определений, приведённый ниже, охватывает вторую сторону тестирования: типы ошибок, которые предполагается обнаружить, и стандарты, с которыми сопоставляются тестируемые программы.

1. Тестирование модуля или автономное тестирование - контроль отдельного программного модуля, обычно в изолированной среде (т.е. изолированно от всех остальных модулей). Тестирование модуля иногда также включает математическое доказательство.

2. Тестирование сопряжений - контроль сопряжений между частями системы (модулями, компонентами подсистемами).

3. Комплексное тестирование - контроль и / или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

4. Тестирование приемлемости - проверка соответствия программы требованиям пользователя.

Сквозной контроль

Эффективный прием оценки детальных внешних спецификаций - подготовить тесты и затем воспользоваться детальными внешними спецификациями для имитации поведения системы. Этот процесс часто называют сквозным контролем или прослеживанием.

Для проверки отдельных внешних функций должны быть выполнены следующие действия. Не автор спецификаций должен сначала построить «тесты на бумаге» для этой функции, т.е. список конкретных входных данных (допустимых и недопустимых). Вместе с автором спецификаций затем имитируют ввод этих данных в cистему, используя спецификации как описание поведения системы. Если оказывается, что спецификации описывают выходные данные или преобразование для какого-то набора входных данных недостаточно полно и правильно, это означает, что обнаружена ошибка.

Важно отметить, что цель всякого такого сеанса сквозного контроля - обнаружить ошибки, но не исправлять их сразу.

Используя данный прием тестирования, были протестированы запросы осуществляемые к базе данных (БД) созданной системы. Для этого на вход подавались различные запросы к БД (См. приложение B).

В результате проведения теста было зафиксировано, что корректные запросы обрабатываются БД согласно предполагаемому результату, время обработки запроса отвечает указанному в ТЗ (не более 3 секунд при минимальной конфигурации, процессор). При попытке осуществить некорректный запрос к БД не всегда выдаются сообщения об ошибках, либо не указано какие действия необходимо предпринять для правильной работы системы.

Трассировка требований к ПО и требований пользователя

Для осуществления проверки требований к ПО и требований пользователя на полноту (поиск всех пропущенных требований), т.е. удовлетворения всех требований пользователя в программном продукте, и отсутствия неоднозначности применяется матрица трассировки.

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

Тестирование внешних функций

Цель теста внешней функции - найти расхождения между программой и её внешними спецификациями. Необходимым условием успешного тестирования функций является наличие чётких и точных внешних спецификаций. Если внешние спецификации неполны или неоднозначны, результаты тестирования не могут не быть такими же.

Внешние спецификации обычно разбиваются на отдельные внешние функции (например, по типу входных сообщений или команд пользователя), и после тщательного изучения каждой функции строятся тесты. Тесты должны строиться для всех входных условий и вариантов, а также на границах всех областей допустимых значений на входе и области изменения на выходе. Тесты должны также проверять поведение программы у функциональных границ и в случаях и в случаях ввода недопустимых или непредусмотренных данных. Рассмотрим методологию проектирования тестов, основанную на функциональных диаграммах (cause-effect graphing).

Тестирование функций - процесс контроля, поскольку оно обычно выполняется в моделируемой среде (в противоположность обстановке реальной). Другими словами, тестирование функций обычно выполняется для компонент системы прежде, чем она будет собрана воедино. Например, могут быть недоступны определённые устройства ввода-вывода, вследствие чего потребуется написать специальные программы для имитации их работы, могут отсутствовать или быть неполными отдельные компоненты программного обеспечения, что также потребует имитации или применения вспомогательных программ.

Метод функциональных диаграм, предлагает способ перевода спецификаций, написанных на естественном языке, на язык формальный. Это способствует проектированию высокорезультативных тестов, не страдающих избыточностью, и обнаруживающих случаи неполноты и неоднозначности во входных спецификациях. Метод предполагает анализ семантического содержания внешних спецификаций и перевод их на язык логических отношений между входными данными (ситуациями) и выходными данными и преобразованиями (эффектами), представленных в виде логической диаграммы («и- или» - графа), называемой функциональной диаграммой.

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

Последовательность применения метода:

1. Первый шаг: разбить внешние спецификации на отдельные функции, комбинаторные свойства которых и должны тестироваться;

2. Второй шаг: проанализировать спецификации в поисках всех явных и неявных ситуаций (условия на входе) и эффектов (действия на выходе). Лучше всего делать это, подчёркивая каждую ситуацию и каждый эффект, по мере того как они встречаются при чтении спецификаций. Все ситуации и эффекты нумеруются произвольным образом.

3. Третий шаг: нарисовать функциональную диаграмму. Ситуации изображаются в виде вершин на левом краю листа бумаги, а эффекты - на правом.

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

Тестирование модуля

Целью тестирования модуля является нахождение несоответствия между логикой и сопряжениями модуля, с одной стороны, и его внешними спецификациями (описанием функций, входных и выходных дынных, внешних эффектов), с другой стороны. Процесс проектирования тестов для модуля состоит из следующих четырех шагов:

1. Руководствуясь внешними спецификациями модуля, были подготовлены тесты для каждой ситуации и каждой возможности, для каждой границы областей допустимых значений всех входных данных, областей изменения данных, для всех недопустимых условий.

2. Был проверен текст программы, чтобы убедиться, что все условные переходы были выполнены в каждом направлении. (Текст программы определялся с использованием созданного логического анализатора).

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

4. Был проверен текст программы на её чувствительность к отдельным особым значениям входных данных и были добавлены соответствующие тесты.

Следует отметить, что компиляцию модуля также можно рассматривать как часть процесса тестирования, поскольку компилятор обнаруживает большинство синтаксических ошибок, а также некоторые семантические и логические ошибки.

В результате реализации данного типа тестирования было зафиксировано, что все условные переходы выполняются в каждом направлении, не происходит «зацикливания» в модуле при граничных значениях индексов циклов, также как и не обнаружено сбоев в работе модуля при невыполнении тела какого-либо из циклов, система реагирует на граничные значения водимых данных корректно.

Комплексное тестирование

Комплексное тестирование - процесс поисков несоответствия системы ее исходным целям. Это наиболее творческий из всех видов тестирования. Оно состоит из следующих шагов:

1. Тестирование стрессов. Распространенный недостаток больших систем в том, что они функционируют как будто бы нормально при слабой или умеренной нагрузке, но выходят из строя при большой нагрузке и в стрессовых ситуациях реальной среды. Тестирование стрессов представляет попытки подвергнуть систему крайнему «давлению».

2. Для проведения тестов осуществлялось большое количество запросов к БД (20 запросов). В результате теста не было зафиксировано никаких отклонений в работе программы, но было отмечено определенное замедление работы БД с запросами.

3. Тестирование объёма. В то время как при тестировании стрессов делается попытка подвергнуть систему серьёзным нагрузкам в короткий интервал времени, тестирование объема представляет собой попытку предъявить системе большие объёмы данных в течение более длительного времени.

4. Для проведения тестов создавалась БД как можно больших размеров, создавались очереди документов, выводимых на печать, использовались граничные значения числовых форматов. В результате теста также не было зафиксировано отклонений в работе программы, обработка запросов БД осуществлялась с незначительным замедлением.

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

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

1. Тестирование защиты. Так как внимание к вопросам сохранения секретности в сегодняшнем автоматизированном обществе возрастает, к большинству систем предъявляются определенные требования по обеспечению защиты от несанкционированного доступа. Цель тестирования защиты - нарушить секретность в системе.

2. В результате проведения теста было зафиксировано, что пользователь не имеющий доступа к системе проникнуть в нее не может.

3. Тестирование производительности. Требования к производительности и эффективности (время ответа для различных нагрузок и различных конфигураций) - важная часть проектов систем. Для проведения данного теста были использованы персональные компьютеры различной конфигурации (на базе AMD Athlon 64 X2 5000+, на базе Intel Core i7 720 QM, на базе Intel Core i5 670 QM, на базе AMD Phenom II X4 925 BOX, на базе Intel Core i7 975 Extreme OEM). В результате проведения теста была зафиксирована корректная работы системы, но необходимо отметить, что работа на ПК на базе Intel не рекомендуется, хотя и возможна.

Выводы по тестированию ПО

На основание проведения вышеперечисленных тестов (см. приложение B,) можно заключить, что:

1. Созданная система выполняет все функции, указаные в техническом задание на дипломное проектирование.

2. При аварийном отключении сохраняет максимально возможное количество данных.

3. Система способна работать на ПК различной конфигурации, в том числе и минимальной.

4. Система отвечает поставленным требованиям по защите от несанкционированного доступа.

5. Система корректно осуществляет свою работу при работе с большими объемами данных и при большом количестве запросов (20 запросов).

3. Обоснование экономической эффективности проекта

3.1 Расчет стоимости программного продукта

Трудоемкость разработки программной продукции зависит от ряда факторов, основными из которых являются следующие: степень новизны разрабатываемого программного продукта, сложность алгоритма его функционирования, объем используемой информации, вид ее представления и способ обработки, а также уровень используемого алгоритмического языка программирования. Чем выше уровень языка, тем трудоемкость меньше.

Трудоемкость разработки программной продукции ? может быть определена как сумма величин трудоемкости выполнения отдельных стадий разработки программного продукта из формулы (3.1)

,	(3.1)

где - трудоемкость разработки технического задания на создание программного продукта;

- трудоемкость разработки эскизного проекта программного продукта;

- трудоемкость разработки технического проекта программного продукта;

- трудоемкость разработки рабочего проекта программного продукта;

- трудоемкость внедрения разработанного программного продукта.

Трудоемкость разработки технического задания рассчитывается по формуле (3.2)

,	(3.2)

где - затраты времени разработчика постановки задачи на разработку технического задания, [чел./дни];

- затраты времени разработчика программного обеспечения на разработку технического задания, [чел./дни].

Их значения рассчитываются по формулам (3.3) и (3.4)

,	(3.3)
,	(3.4)

где - норма времени на разработку технического задания на программный продукт;

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

(совместная разработка с разработчиком ПО);

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

(совместная разработка с разработчиком постановки задач).

Тогда

Трудоемкость разработки эскизного проекта рассчитывается по формуле (3.5)

,	(3.5)

где - затраты времени разработчика постановки задачи на разработку эскизного проекта, [чел./дни];

- затраты времени разработчика программного обеспечения на разработку эскизного проекта, [чел./дни].

Их значения рассчитываются по формулам (3.6) и (3.7)

,	(3.6)
,	(3.7)

где - норма времени эскизного проекта на программный продукт. В нашем случае

- коэффициент, учитывающий удельный вес трудоемкости работ, выполняемых разработчиком постановки задачи на стадии эскизного проекта. Принимается (совместная работа с разработчиком ПО).

- коэффициент, учитывающий удельный вес трудоемкости работ, выполняемых разработчиком программного обеспечения на стадии эскизного проекта. Принимается (совместная работа с разработчиком постановки задач).

Тогда

Трудоемкость разработки технического проекта зависит от функционального назначения программного продукта, количества разновидностей форм входной и выходной информации и определяется по формуле (3.8)

,	(3.8)

где - норма времени, затрачиваемого на разработку технического проекта разработчиком постановки задач;

- норма времени, затрачиваемого на разработку технического проекта разработчиком ПО;

- коэффициент учета режима обработки информации. Принимаем =1,45 (группа новизны - Б, режим обработки информации - реальный масштаб времени);

- коэффициент учета вида используемой информации, определяется по формуле (3.9).

Принимается количество разновидностей форм входной информации - 1, количество разновидностей форм выходной информации - 2:

,	(3.9)

где - коэффициент учета вида используемой информации для переменной информации;

- коэффициент учета вида используемой информации для нормативно-справочной информации;

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

Принимается (группа новизны - Б):

- количество наборов данных переменной информации;

- количество наборов данных нормативно-справочной информации;

- количество баз данных.

В данном случае:

Находится значение :

Тогда

Трудоемкость разработки рабочего проекта зависит от функционального назначения программного продукта, количества разновидностей форм входной и выходной информации, сложности алгоритма функционирования, сложности контроля информации, степени использования готовых программных модулей, уровня алгоритмического языка программирования и определяется по формуле (3.10)

,	(3.10)

где - коэффициент учета сложности контроля информации. Принимается

- коэффициент учета режима обработки информации. Принимаем значение (группа новизны - Б, режим обработки информации - реальный масштаб времени)

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

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

- коэффициент учета вида используемой информации и сложности алгоритма программного продукта;

- норма времени, затраченного на разработку рабочего проекта на языке программирования разработчиком постановки задач.

Выбирается (количество разновидностей форм входной информации - 1, количество разновидностей форм выходной информации - 2)

- норма времени, затраченного на разработку рабочего проекта на языке программирования разработчиком ПО. Выбирается (количество разновидностей форм входной информации - 1, количество разновидностей форм выходной информации - 2)

Значение коэффициент учета вида используемой информации и сложности алгоритма программного продукта определяется по формуле (3.11)

,	(3.11)

где - коэффициент учета сложности алгоритма программного продукта и вида используемой информации для переменной информации;

- коэффициент учета сложности алгоритма программного продукта и вида используемой информации для нормативно-справочной информации;

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

Принимается (сложность алгоритма программного продукта - 3, группа новизны - Б):

Находится значение :

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Тогда

Трудоемкость выполнения стадии «Внедрения» рассчитывается по формуле (3.12)

,	(3.12)

где - норма времени, затрачиваемого разработчиком постановки задач на выполнение процедур внедрения программного продукта;

- норма времени, затрачиваемого разработчиком программного обеспечения на выполнение процедур внедрения программного продукта;

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

Коэффициенты и были найдены выше:

Тогда

Общая трудоемкость разработки программного продукта:

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

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

Расчет производится по формуле (3.13)

,	(3.13)

где - трудоемкость i-ой работы, [чел./дни];

Q - трудоемкость дополнительных работ, выполняемых исполнителем, [чел./дни];

- количество исполнителей, выполняющих i-ую работу.

Так как дополнительные работы на всех этапах отсутствуют, то продолжительность каждого этапа составляет:

Общее время выполнения проекта:

3.2 Определение цены программной продукции

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

Затраты, образующие себестоимость продукции (работ, услуг), группируются в соответствии с их экономическим содержанием по следующим элементам:

- нематериальные активы и затраты на оборудование (за вычетом стоимости возвратных отходов);

- затраты на оплату труда;

- отчисления на социальные нужды;

- амортизация основных средств;

- прочие затраты.

3.2.1 Расчет нематериальных активов и затрат на оборудование

В данной статье учитываются суммарные затраты на приобретение оборудования и нематериальных активов, требуемых для разработки данного программного продукта. Так как пакет Turbo Delphi с библиотеки уже установлен в организации, то стоимость его не учитывается. Результаты сведены в таблицу 3.1. Цены указаны по состоянию на январь 2011 года.

Таблица 3.1 - Затраты на оборудование и ПО

Наименование	Количество, шт.	Цена за ед., руб.	Сумма, руб.
Turbo Delphi	2	9500,00	18000,00
Windows XP Home Edition RUS SP2	2	3408,00	6816,00
Итого			24816,00

Затраты на ПО: руб.

Затраты, связанные с использованием вычислительной техники определяют по формуле (3.14)

,	(3.14)

где - время использования ЭВМ для разработки данного программного продукта. Берем значение (количество разновидностей форм входной информации - 1, количество разновидностей форм выходной информации - 2)

- поправочный коэффициент учета времени использования ЭВМ.

Берется значение (сложность алгоритма ПП - 3; группа новизны - Б).

- цена одного часа работы ЭВМ,

- коэффициент учета степени использования системы управления базами данных;

- коэффициент учета быстродействия ЭВМ. Выбирается (более операций в секунду)

[руб.]

3.2.2 Расчет основной заработной платы

В данную статью включаются основная заработная плата всех исполнителей, непосредственно занятых разработкой данного программного продукта с учетом их должностных окладов и времени участия. Расчет проводится по формуле (3.15)



,	(3.15)

где - месячный оклад i-го исполнителя, [руб.];

- трудоемкость работ, выполняемых i-м исполнителем, [чел./дни] - определяются из календарного плана-графика;

- среднее количество рабочих дней в месяце. Принимается d=21 день.

Расчет затрат на оплату труда каждого исполнителя:

Суммарная заработная плата равна:

3.2.3 Расчет дополнительной заработной платы

В данной статье учитываются выплаты непосредственным исполнителям за время, не проработанное на производстве, в том числе: оплата очередных отпусков, компенсация за недоиспользованный отпуск, оплата льготных часов подросткам и другие. Дополнительная заработная плата рассчитывается по формуле (3.16)

,	(3.16)

где - коэффициент отчислений на дополнительную заработную плату.

Принимается .

Тогда дополнительная заработная плата с учетом коэффициента отчислений составит:

3.2.4 Отчисления на социальные нужды

В статье учитываются отчисления в бюджет социального страхования по установленному законодательством тарифу от суммы основной и дополнительной заработной платы. Расчет производится по формуле (3.17)

,	(3.17)

где - коэффициент отчислений на социальное страхование.

Принимается

Тогда

3.2.5 Расчет амортизационных отчислений

Расчет ведется по формуле (3.18)

,	(3.18)

где А - годовые амортизационные отчисления;

Т - время работы оборудования;

- действительный годовой фонд рабочего времени на ПЭВМ.

Цена ПЭВМ требуемая для разработки ПО представлены в таблице 3.2:

Наименование	Цена
ЦП: AMD Phenom II X4 925BOX (ядро Deneb 2,8ГГц, Socket AM3, L2-кеш 2 мб, L3-кеш 6 мб.	5200
Системная плата: Gigabyte GA-MA770T-UD3P (Socket AM3, AMD770, 4хDDR3 1066\1333\1666 максимум до 16 Гб, PCIex16, 2xPCIe, 4xPCIe, IDE, 6xSATA, 8xUSB2,0, IEEE 1394a, S\PDIF-out, COM, LAN, 2xPS\2, аудио)	3200
Память: 2048 Мб 1333МГц, DDR3 Kingston PC 10666 (KVR1333D3N9-2G)	2450
Видеокарта: XFX Radeon HD 5750 1Гб GDDR5 (PCIex16,2xDVI, HDMI, DisplayPort)	6450
Жесткий диск: Seagate Barracuda ST3320418AS 320Гб (SATA-2, 7200 об\мин, 16Мб)	2400
Оптический привод: NEC AD-7243S-08LF (SATA, CD-ROM\R\RW, DVD-ROM\RAM, DVD-R\RW, DL)	950
Корпус: ASUS TA-881 (ATX, 450 Вт, 1х12 см, 24+4 pin, 2xUSB, звук	2200
Монитор: BenQ SE2241 (TFT, 21,5 дюйм, 1920х1080, 5 мс, 250 кд\м3,1000:1, VGA, DVI, HDMI. SCART, композитный, компонентный	10500
Мышь: A4TechXL-750BK (360dpi, лазерная, проводная) Клавиатура: A4TechKX-6MU-R-slim (проводная, 104 осноных+13 дополнительных клавиш)	1700
Итого:

Данные для расчета амортизационных отчислений представлены в таблице 3.3.

Таблица 3.3 - Данные для расчета амортизационных отчислений

Цена ПЭВМ (на январь 2010 года), руб.	32890
Процент на амортизационные отчисления, %	12
Годовой фонд рабочего времени на ПЭВМ (пятидневная неделя, 7,5 часовой рабочий день), час	1950

А=0,12·32890·2=7894 руб.

Т=245,91·7,5=1844,3 [час.] (из расчета 7,5 часового рабочего дня)

Всего амортизационные отчисления при разработке программного продукта составяет:

руб.

3.2.6 Накладные расходы

В данную статью входят другие затраты, входящие в состав себестоимости продукции (работ, услуг), но не относящиеся к ранее перечисленным элементам затрат.

,	(3.19)

где - коэффициент накладных расходов.

Принимается

Тогда

3.2.7 Итоговые результаты

Результаты расчетов затрат на разработку программного продукта приведены в таблице 3.4.

Таблица 3.4 - Результаты расчетов

Наименование статьи	Сметная стоимость, руб.
Затраты на нематериальные активы и оборудование	24816
Затраты на оплату труда	162190
Дополнительная заработная плата	32438
Отчисления в ФСС	74677
Амортизация оборудования	7466
Накладные расходы	48657

Подобные документы

• Проектирование автоматизированного рабочего места кассира-операциониста для ООО "Расчетно-кассовый центр"

  Технологический процесс сбора, передачи, обработки и выдачи информации. Назначение программного продукта. Анализ экономических показателей внедрения автоматизированного рабочего места кассира-операциониста. Организация рабочего места оператора ЭВМ.
  
  дипломная работа [2,6 M], добавлен 08.12.2014
  

• Разработка программного обеспечения для автоматизации документооборота в фонде жилого дома

  Понятие и специфика автоматизированных систем. Описание методики разработки программы для автоматизации. Ее тестирование и отладка. Внедрение АС в работу предприятия. Расчет экономического эффекта от разработки и реализации программного продукта.
  
  дипломная работа [1,4 M], добавлен 23.06.2015
  

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

  Расчет издержек предприятия на разработку программного продукта и экономической эффективности от его внедрения. Топология физических связей и структуризация сети. Характеристика программного обеспечения. Средства автоматизации, описание алгоритма задачи.
  
  дипломная работа [867,6 K], добавлен 05.11.2015
  

• Электронный документооборот

  Описание предприятия и его деятельности, особенности его организационной структуры. Характеристика комплекса задач и обоснование необходимости автоматизации. Разработка проекта автоматизации, выбор и обоснование метода его экономической эффективности.
  
  дипломная работа [2,6 M], добавлен 16.06.2011
  

• Создание автоматизированной информационной системы

  Краткая характеристика предприятия и его организационная структура, описание технического и программного обеспечения. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Расчет трудоемкости внедрения.
  
  отчет по практике [167,4 K], добавлен 11.12.2013
  

• Разработка интернет-сайта систем видеонаблюдения

  Формализация и стандартизация данных. Описание программных блоков. Защита от несанкционированного доступа, некорректной регистрации и авторизации. Тестирование и отладка программного продукта. Расчет годового экономического эффекта от его внедрения.
  
  курсовая работа [588,7 K], добавлен 17.07.2014
  

• Информационная система компании ЗАО "НаноБрахиТек"

  Характеристика предприятия и его деятельности, организационная структура управления, выбор комплекса задач автоматизации и характеристика существующих бизнес-процессов, обоснование проектных решений. Программное обеспечение задачи, разработка модулей.
  
  дипломная работа [2,6 M], добавлен 29.11.2013
  

• База данных "Клиниг" для ООО "Мастер блеск"

  Технико-экономическое описание предметной области и разработка программного проекта по автоматизации рабочего места менеджера по клининговым услугам. Разработка этапов внедрения программного продукта и расчет экономической эффективности его внедрения.
  
  дипломная работа [2,1 M], добавлен 12.04.2014
  

• Назначение и цели автоматизации системы защиты информации

  Автоматизация рабочего места оператора, принимающего звонки от населения. Описание информационной инфраструктуры. Характеристика комплекса задач, подлежащих автоматизации для более комфортной работы оператора. Структурный состав программного продукта.
  
  отчет по практике [36,7 K], добавлен 04.04.2015
  

• Платежная интернет-система для виртуального предприятия

  Экономическая сущность задачи автоматизации приема электронных платежей. Характеристика комплекса задач, задачи и обоснование необходимости автоматизации. Информационная модель и ее общее описание. Программное и технологическое обеспечение задачи.
  
  курсовая работа [2,0 M], добавлен 09.10.2011
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам