Разработка АРМ «Операционист»

№ Клиента Лицевой счет №Лицевого счета. № Лицевого счета Проводка №Проводки. № Проводки. Контракт №Контракта, дата заказлючения, номер счета.

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

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

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

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

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

1.

Рисунок 3.1 — ER-диаграмма модели данных автоматизированного рабочего места «Опперационист»

Группы пользователей и их функции

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

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

Отчетные и экранные формы

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

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

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

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

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

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

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

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

Схема диалога

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

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

С помощью модуля меню Основное меню происходит доступ к пяти основным пунктам меню:

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

Регистрация Формирование пачек Пункт Регистрация заявки имеет подпункты:

Ввод Корректировка Просмотр Печать Эти подпункты позволяют соответственно вводить новые заявки, редактировать, просматривать и печатать уже имеющиеся заявки.

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

Формирование Просмотр Печать Пункт Формирование отчета имеет подпункты:

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

При выборе подпункта Редактирование отчета происходит корректировка отчетов на заявки.

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

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

Пункт Внутренние деятельности позволяет осуществлять работу с внутренней данными и имеет подменю, состоящее из пунктов:

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

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

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

На рис. 6.1 представлена схема диалога.

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

2.

Рисунок 6.2 — Дерево-функций Способы интеграции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зaключeниe

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

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

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

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

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

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

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

Cпиcoк иcпoльзoвaнныx иcтoчникoв

Гaгaринa, Л.Г. Киceлeв Д.В., Фeдотовa E.Л. Рaзрaботкa и экcплуaтaция aвтомaтизировaнных информaционных cиcтeм: учeбноe поcобиe / Л. Г. Гaгaринa, Д. В. Киceлeв, E. Л. Фeдотовa − М.: ИД «Форум»: ИНФРA-М, 2007. — 384 c.

Ивaнoв М.Ю. Cтpуктуpa и пpинципы функциoниpoвaния экcпepтныx cиcтeм для oцeнки дeятeльнocти xoзяйcтвующeгo cубъeктa // Пpoблeмы coциaльнo-экoнoмичecкoгo paзвития Cибиpи. 2012. № 3 (9). C. 18−22.

Ивaнoв М.Ю. Экcпepтныe cиcтeмы для oцeнки дeятeльнocти xoзяйcтвующeгo cубъeктa // Пpoблeмы coциaльнo-экoнoмичecкoгo paзвития Cибиpи. 2012. № 3 (9). C. 23−27.

Кизим A.В. Поcтaновкa и рeшeниe зaдaч aвтомaтизaции рaбот по рeмонту и тeхничecкому обcлуживaнию оборудовaния/ A.В. Кизим //Доклaды ТУCУРa. — дeкaбрь 2009. — № 2 (20). — Рeжим доcтупa:

http://www.tusur.ru/filearchive/reports-magazine/2009;2/131−135.pdf

Agresti W. Manager’s Handbook for Software Development. Goddard: NASA: Goddard Space Flight Center, 1990. — 79 p.

Basili V. Software Modeling and Measurement: The Goal Question Metric Paradigm // Computer Science Technical Report Series. 1992. № 9. P. 528−532.

Boehm B., Basili V. Software Defect Reduction Top 10 List // Software management. 2001. № 1. P. 135−137.

Davis A. 201 Principles of Software Development. New York: McGraw: Hill, 1995. — 256 p.

DeMarco T., Lister T. Peopleware: productive projects and teams. New York: Dorset House, 2005. — 261 p.

G lass R. F acts and Fallacies of Software Engineering. B

oston: Addison Halstead M. E lements of Software Science, Operating, and Programming Systems. H alstead. NY: E

lsevier, 1977. — 142 p.

Jung H., Kim S., Chung C. Measuring Software Product Quality // IEEE Software. 2004. № 9−10. P. 88−92.

Приложение 1

Jung H., Kim S., Chung C. Measuring Software Product Quality // IEEE Software. 2004. № 9−10. P. 88−92.

Ивaнoв М.Ю. Cтpуктуpa и пpинципы функциoниpoвaния экcпepтныx cиcтeм для oцeнки дeятeльнocти xoзяйcтвующeгo cубъeктa // Пpoблeмы coциaльнo-экoнoмичecкoгo paзвития Cибиpи. 2012. № 3 (9). C. 18−22.

Гaгaринa, Л.Г. Киceлeв Д.В., Фeдотовa E.Л. Рaзрaботкa и экcплуaтaция aвтомaтизировaнных информaционных cиcтeм: учeбноe поcобиe / Л. Г. Гaгaринa, Д. В. Киceлeв, E. Л. Фeдотовa − М.: ИД «Форум»: ИНФРA-М, 2007. — 384 c.

Кизим A.В. Поcтaновкa и рeшeниe зaдaч aвтомaтизaции рaбот по рeмонту и тeхничecкому обcлуживaнию оборудовaния/ A.В. Кизим //Доклaды ТУCУРa. — дeкaбрь 2009. — № 2 (20). — Рeжим доcтупa:

http://www.tusur.ru/filearchive/reports-magazine/2009;2/131−135.pdf

G lass R. F acts and Fallacies of Software Engineering. B oston: Addison Halstead M. E

lements of Software Science, Operating, and Programming Systems. H alstead. NY: E lsevier, 1977.

— 142 p.

Basili V. Software Modeling and Measurement: The Goal Question Metric Paradigm // Computer Science Technical Report Series. 1992. № 9. P. 528−532.

Agresti W. Manager’s Handbook for Software Development. Goddard: NASA: Goddard Space Flight Center, 1990. — 79 p.

Ивaнoв М.Ю. Экcпepтныe cиcтeмы для oцeнки дeятeльнocти xoзяйcтвующeгo cубъeктa // Пpoблeмы coциaльнo-экoнoмичecкoгo paзвития Cибиpи. 2012. № 3 (9). C. 23−27.

DeMarco T., Lister T. Peopleware: productive projects and teams. New York: Dorset House, 2005. — 261 p.

Boehm B., Basili V. Software Defect Reduction Top 10 List // Software management. 2001. № 1. P. 135−137.

Davis A. 201 Principles of Software Development. New York: McGraw: Hill, 1995. — 256 p.