UML-диаграмма приложения “Заказы” представлена на рисунке 14

Рис.14 UML-диаграмма приложения “Заказы”.

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

Глава 3. Экспериментальная проверка программного комплекса.

3.1 Исходные данные и постановка задачи для проведения тестирования

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

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

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

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

защита программного комплекса от несанкционированного доступа;

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

добавление, изменение, удаление информации;

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

выполнение специальных задач, при возникновении нестандартных ситуаций.

3.2 Тестирование приложений

Тестирование приложения “Прайс”.

Прежде всего, была осуществлена попытка доступа к приложению, пользователем “Serebrinnikov_OA” с ролью “Склад”, которая дает права доступа к приложению “Склад” и, частично, “Заказы”, но не дает права доступа к приложению “Прайс”. Результат - отказ в доступе. После входа в систему под учетной записью администратора, были изменены права доступа для данного пользователя и эта учетная запись получила право на чтение, удаление, добавление товаров в прайс-листе. Добавим группу товаров “Нестандартное оборудование” с родителем “Все товары” в дерево товаров. Добавим в эту группу товар “Часы с флэш-накопителем 64Mb Casio-I32” и товар “ИК-порт ACTiSYS IR”. Добавление, удаление этих товаров из прайса, а также редактирование их свойств проходит нормально. При попытке удаление удаления товара “Монитор Sony Multiscan E100” получаем сообщение: “Товар “Монитор Sony Multiscan E100” не может быть удален, так как он включен в счет, заказ или поставку”. При удалении непустой группы товаров, при наличии в ней хотя бы одного товара, фигурирующего в счетах, заказах или поставках получаем такое же сообщение и все изменения в группе отменяются. Попытка другого пользователя изменить свойства товара, в то время, когда их редактирует пользователь “Serebrennikov_OA” приводит к появлению сообщения: “Редактирование текущей записи невозможно. Запись заблокирована пользователем Serebrinnikov_OA 13:20 19.02.2006”.

Тестирование приложения “Счета”.

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

3.3 Анализ результатов, полученных при тестировании

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

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

Рис. 15 Окно «Добро пожаловать».

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

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

Программный комплекс работает устойчиво, если выполняются перечисленные ниже требования:

Сеть функционирует нормально;

Если правильно указаны параметры подключения;

Сервер функционирует нормально;

Проверка работы поисков показала, что алгоритмы поисков работают

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

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

Соответственно, при несоблюдении каких-либо требований, в работе приложения возможно возникновение сбоев или ошибок.

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

Глава 4. Расчет экономической эффективности проекта

4.1 Анализ рыночных возможностей продукта

На рынке автоматизированных систем для крупных организаций и финансово-промышленных групп на сегодня можно выделить два основных субъекта: это рынок автоматизированных банковских систем (АБС) и рынок корпоративных информационных систем промышленных предприятий. Не смотря на сильную взаимосвязь этих двух рынков систем автоматизации, предлагаемые на них решения, пока еще не достаточно интегрированы между собой, чего следует ожидать в недалеком будущем. Создавая свои отделы и управления автоматизации, предприятия и банки пытались обустроиться своими силами. Однако периодическое "перетряхивание" инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, непрерывная работа программистов по удовлетворению все новых и новых пожеланий отдельных работников и как следствие - недовольство руководителей своими программистами несколько остудило пыл как тех, так и других. Итак, первый подход к решению этой проблемы сводился к проектированию "снизу-вверх". В этом случае, при наличии квалифицированного штата программистов, вполне сносно были автоматизированы отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривалась недостаточно хорошо, особенно в перспективе. Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть здесь будущий рынок и инвестировать средства в создание программного аппарата для этого растущего рынка. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов (для банков это в основном - расчетно-кассовое обслуживание, для промышленных предприятий - автоматизация процессов проектирования и производства, имеется в виду не конкретных станков и т.п., а информационных потоков). Учитывая тот факт, что ядром АИС безусловно является аппарат, обеспечивающий автоматизированное ведение аналитического учета, большинство фирм начали с детальной проработки данной проблемы. Системы были спроектированы "сверху", т.е. в предположении, что одна программа должна удовлетворять потребности всех пользователей.

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

4.2 Расчет единовременных затрат на разработку ПО

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

Таблица 4.1.

Содержание стадий научно-исследовательской работы (НИР).

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12