Автоматизация сети аптек

4.1.2.          требования к численности и квалификации персонала системы и режиму его работы;

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

4.1.3.          требования к надежности;

Надежность системы определяется по следующим критериям:

                       Корректность проводимых расчетов.

                       Целесообразность введенных данных.

                       Отсутствие программных ошибок.

                       Отсутствие пересечения связей и вводимых данных.

                       Качество защиты информации.

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

                       Вывод неправильных результатов.

                       Логическое несоответствие вводимых данных.

                       Неправильно построенные логические алгоритмы.

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

                       по мере решения функциональных задач,

                       в процессе эксплуатации системы на сетевом уровне,

                       на уровне оценки качества защиты информации,

                       в течение проверки системы на отказоустойчивость.

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

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

4.1.5.          требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

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

4.1.6.          Требования к защите информации от несанкционированного доступа- доступа :

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

4.1.7.          Требования по сохранности информации при авариях

                       Неполадки в операционной системе.

                       Кража компьютера

                       Высокий подъем напряжения

                       Сбой в INTERNET

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

4.1.8.          Требования к защите от влияния внешних воздействий;

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

4.1.9.          Требования по стандартизации и унификации

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

4.1.10.     Дополнительные требования

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

4.2.                требования к функциям (задачам), выполняемым системой; 

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

                       Заполнение Таблиц (1.01-15.03)

                       Выполнение Запросов (16.03-15.04)

                       Проведение Статистики (16.04 -25.05)

                       Подготовка Отчетов (26.05- 25.05)

4.2.2.          Требования к качеству реализации каждой функции

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

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

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

4.2.3.          Перечень и критерии отказов для каждой функции

                       Не полный ввод данных в конкретную таблицу.

                       Заполнение не всех таблиц.

                       Ввод данных несоответственного типа.

                       Выполнение не всех Запросов по выбранной области.

                       Отказ от проведения анализа того объекта по которому нет подготовленных данных по запросам.

                       Отказ от организации отчетов по тому объекту, по которому не был проведен анализ .

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

4.3.1.          Информационное обеспечение системы:

Данные в системе организованы по методике SADT технологий, т.е. идет взаимосвязь м/у потоками входными и выходными, одновременно которые контролируют потоки управления и механизмов. Т.е. модели построены на базе IDEF0  стандарта. В данное время ведутся очень большие споры по поводу эффективности данного варианта так как, существуют не менее эффективный DFD стандарт, смысл которого заключается в отсутствии управления и механизмов. Но в нашем проекте наблюдается очень четкая граница между входными/выходными и управляющими данными, т.к. система основана полностью на расчетных алгоритмах, которые в свою очередь являются управляющими. Так как создан ряд первичных документов, это есть база от которой мы отталкиваемся, решая вопрос обмена данными м/у компонентами анализа. Первичные таблицы баз данных, это структура разработанная для всей системы в целом, а не для каждого компонента по отдельности, поэтому обмен данными является вполне обычным явлением в заданном проекте. Программные продукты на которых велась разработка являются довольно совместимыми, некоторые даже позволяют операцию импорта или экспорта м/у друг другом. Основный принцип построения базы данных заключается в том что есть таблицы хранящие ключевую информацию. Также существуют вспомогательные таблицы, которые хранят в себе дежурные данные такие, как например номера счетов, разделы баланса, классификация депозитов и т.д. Основное требование к процессу сбора , обработки, и передачи информации это разделение процесса работы с информации на следующие этапы: Ввод в таблицы, Выполнение Запросов, Проведение Анализа(Общего и по кредитному делу), Выполнение Отчетов.

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

                       Eclipse ;

                       SQL Server 2008;

                       BPWin Process Modeler 7;

                       ERWin Diagram Builder 7;

                       Microsoft Project Manager 10;

5.                      Состав и содержание работ по созданию системы

5.1 содержание работ, сроки выполнения и исполнитель.

Исполнителем является один человек непосредственно автор дипломной работы.

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

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

                       Отчеты входных данных, инициализируемых программой.

                       Запросы оформленные в виде отчетов.

                       Выходные отчеты с данными, прошедшими требуемый анализ.

                       Руководство пользователя.

                       Консалтинговые модели  AS IS и  TO BE для последующих корректировок.

5.3.                вид и порядок проведения экспертизы технической документации;

                       Подготовка первичных материалов.

                       Раздел заполнения информации.

                       Аналитический раздел.

                       Прогностический раздел.

                       Раздел формирования результативных отчетностей.

5.4.                программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);

                       Подробное изучение предметной области.

                       Составление концепции, точки зрения проекта.

                       Подготовка технического задания.

                       Подбор функций и соответствующих данных.

                       Моделирование основных бизнес потоков.

                       Ручная организация первичной документации.

                       Моделирование основных процессов самого проекта.

                       Разработка первичной диаграммы Баз Данных.

                       Переработка и Нормализация БД.