22
ходимым типом, диапазоном изменения возможных значений, маской
ввода и т.д.;
для добавления и редактирования данных необходимо использовать
экранные формы со всеми необходимыми полями ввода, а также по-
яснениями и управляющими элементам, предназначенными для вы-
работки управляющих воздействий (сохранение, отмена изменений)
и навигации (перемещению) по БД;
для обеспечения поиска данных следует использовать экранные
формы, позволяющие задавать различные значения (диапазоны зна-
чений) интересующей информации, с контролем допустимости зна-
чений условий поиска
в каждом из программных модулей системы предполагается наличие
всех необходимых отчетных форм для формирования и печати доку-
ментов установленной формы. Все отчеты должны генерироваться
автоматически, используя выборки информации из БД;
требование понятности пользователю (интерфейс программной сре-
ды должен быть «дружественным»;
требование масштаба (программная среда должна корректно рабо-
тать на малых и на больших системах с производительностью, кото-
рая увеличивается пропорционально вычислительной мощности си-
стемы);
требование минимизации затрат на сопровождение и поддержку;
требование эргономичности.
Для создания базы данных, а также самого разрабатываемого про-
граммного средства, осуществляющего доступ к данным базы, необходимо
использовать Microsoft Access 2010.
Access специально спроектирован для создания многопользователь-
ских приложений, где файлы базы данных являются разделяемыми ресур-
сами в сети.
23
Система Access поддерживает обработку транзакций с гарантией их
целостности. Кроме того, предусмотрена защита на уровне пользователя,
что позволяет контролировать доступ к данным отдельных пользователей и
целых групп.
Одна из самых мощных его возможностей одновременно является и
наиболее важной. Отношения позволяют связать таблицы графически.
Можно даже связывать таблицы, представляющие файлы разных типов
(например, таблицу Access и таблицу dBASE). После подобного связыва-
ния таблицы выступают уже как одно целое, и теперь можно строить за-
просы применительно к любым данным в них. Можно выбирать конкрет-
ные поля, определять порядок сортировки, создавать вычисляемые выра-
жения и вводить критерии отбора нужных записей. Можно отображать ре-
зультаты выполнения запроса в виде таблицы, формы или отчета. От поль-
зователя не требуется предварительной установки связей: вместо этого до-
статочно войти в конструктор запросов (например, когда требуется постро-
ить определенный отчет).
Запросы применяют и в других случаях. Можно создавать запросы,
которые обеспечивают вычисление итогов, отображение сгруппированных
и построение новых таблиц. Запрос можно использовать даже для обнов-
ления данных в таблицах, удаления записей и добавления одной таблицы к
другой.
В рамках разрабатываемого программного средства предполагается
создание процедур обработки данных ЭИС, предназначенной для разме-
щения на АРМ пользователя. Предполагаемый набор описанных выше
процедур включает в себя:
Процедуры извлечения данных из базы данных, в соответствии с
требованиями предметной области (данные таблиц, сведения из опреде-
ленных запросов к таблицам и т.п.).
Процедуры, поддерживающие редактирование данных и коррект-
ную запись их в базу данных.
24
Процедуры, поддерживающие удаление данных из базы в соответ-
ствии с потребностями пользователя.
Процедуры, поддерживающие обеспечение целостности базы дан-
ных.
Процедуры, поддерживающие защиту базы данных от несанкцио-
нированного доступа.
Процедуры, отвечающие за контроль вводимой в ПЭВМ информа-
ции, уменьшающие процент ошибок оператора при вводе данных.
Другие процедуры.
1.4.3 Обоснование проектных решений по информационному
обеспечению
Для обеспечения хранения данных можно использовать локальную
или распределенную базу данных.
В данном дипломном проекте целесообразнее использовать локаль-
ную базу данных, хранящуюся на сервере, применение которой позволит
уменьшить время работы с базой данных и уменьшить сложность настрой-
ки прикладного программного обеспечения.
Для обновления данных, хранящихся в базе и поддержания целост-
ности данных целесообразно использовать типовые процедуры обновления
данных. Их преимущество состоит в том, что они функционируют непо-
средственно в базе данных, то есть в серверной части приложения, поэто-
му скорость их работы достаточно высока. При изменении пользователем
каких-либо связных полей в клиентской части системы (в программе), в
серверной части системы (базе данных) запускаются типовые процедуры
обновления данных, поддерживающие целостность базы.
Входными документами для разрабатываемой программы является
приходы товары и прайс-листы поставщиков.
Выходными документами разрабатываемой программы являются
товарный чек.
25
Предполагаются следующие информационные решения, касающиеся
разрабатываемого программного средства:
сбор исходной информации, вводимой в базу данных, осуществ-
ляется распределено, т.к. база данных хранится на сервере сети, а инфор-
мация для базы данных может быть введена с любого АРМ, где установле-
на клиентская часть программы;
ввод информации в базу данных осуществляется вручную с бу-
мажных носителей. Информация записывается в базу автоматически;
обработка данных осуществляется в диалоговом режиме;
пользователь получает информацию из базы данных на экран
ПЭВМ, кроме того, информация может выдаваться на принтер в случае
распечатки различных стандартных форм. Информация выдается распре-
делено, т.к. каждый пользователь может получить различные виды инфор-
мации, работая с одной и той же базой данных;
резервирование базы данных осуществляется при помощи со-
хранения базы данных на каком-либо магнитном носителе, а восстановле-
ние – при помощи копирования базы данных с магнитного носителя на
сервер в ту папку, где должна находиться база данных;
база данных состоит из одного файла, имеющего расширение
«.mdb» (формат Microsoft Access 2010).
Структура пакета прикладных программ представлена в рисунке 1.2.
Рис. 1.2. Структура пакета прикладных программ
Главная форма
Пользовательские формы
26
Технология внутри машинной организации задается последователь-
ностью реализуемых процедур схем взаимосвязи программных модулей
и информационных массивов. Такая схема представляет собой декомпози-
цию общего процесса решения задачи на отдельные процедуры преобразо-
вания массивов, именуемыми модулями (это ввод, контроль, перезапись
информации с одного носителя на другой, сортировка, уплотнение данных,
редактирование, накопление, вывод на печать и т.п.).
Структуру программ можно описать основными блоками, представ-
ленными в рисунке 1.3.
Рис.1.3. Схема основных разделов программы
Раздел «Главное меню» предназначен для запуска основных проце-
дур программы и завершения работы с программой.
Раздел работы со справочниками включает в себя справочники:
номенклатура,
менеджеры,
поставщики;
реквизиты.
Назначение данного раздела является поиск и подготовка справочной
информации.
Раздел «Формирование входной информации» предназначен для вво-
да первичных данных и просмотра ранее занесенных. Данный раздел реа-
Справочники
Главное меню
Выход
Формиро-
вание
входной
информа-
ции
Форми-
рование
докумен-
тов
27
лизует задачи формирования номенклатуры материальных ценностей с по-
мощью специальных форм.
Раздел «Формирование документов» выполняет функции формиро-
вания печатных форм. Отчеты формируются, используя запросы, которые
обрабатывают исходную информацию в соответствии с заданными пара-
метрами пользователя.
1.4.4 Обоснование проектных решений по техническому обес-
печению
Требования к аппаратному обеспечению рабочей станции следую-
щие: компьютер, совместимый с IBM PC/AT, операционная система –
“Windows 7 Professional”, программа “Microsoft Office”, процессор с такто-
вой частотой не ниже core 2 duo 1.67 ГГц (рекомендуется 1.8 ГГц). Объем
памяти не менее 2048 мега байт, свободное пространство на жестком диске
не менее 20 Гбайт, манипулятор «мышь» и стандартная клавиатура, видео-
адаптер SVGA, принтер.
Величина минимально необходимого свободного пространства на
жестком диске сервера и рабочей станции выбрана на основе опыта экс-
плуатации аналогичной ЭИС в организации-конкуренте.
1.4.5 Обоснование проектных решений по технологическому
обеспечению
Этап ввода информации в ПЭВМ является наиболее ответственным с
точки зрения обеспечения достоверности информации. Причины, приво-
дящие к возникновению ошибок во вводимой информации, на этапе ввода,
могут зависеть либо от состояния оборудования, на котором осуществля-
ется ввод, либо от организации процесса ввода.
Для уменьшения ошибок при вводе информации в ПЭВМ в некото-
рых полях базы данных задаются условия на значение. В самом простом
случае условие на значение должно гарантировать, что из-за ошибки ввода в
28
числовом поле не окажутся буквенные символы. Другие условия могут
определять область или диапазоны допустимых значений. Заданное условие
на значение всегда будет проверяться при вводе или изменения значения
поля в таблице.
Кроме того, для уменьшения ошибок при вводе данных используется
маска ввода. Маска ввода удобна при использовании полей, размер и смыс-
ловая нагрузка которых заранее известна.
Для взаимодействия с пользователем программы предполагается ис-
пользование меню, подсказок, полей, отвечающих за ввод информации, а
также кнопок, результатом нажатия на которые будет отображение того или
иного запроса к базе данных.
В результате работы программы пользователь может столкнуться с
ошибками, связанными с получением результатной информации. Для
устранения таких ошибок используется процесс отладки программного
средства. Процесс отладки осуществляется в некотором контрольном набо-
ре данных. При этом значения, полученные программным путем, сравнива-
ются со значениями, полученными в результате ручных вычислений.
29
2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл (ЖЦ) программного средства (ПС) – это период
времени, который начинается с момента принятия решения о необходимо-
сти его создания, и заканчивается в момент его полного изъятия из эксплу-
атации.
Существует целый ряд методологий, описывающих жизненный цикл
ПО:
ГОСТ 34.601-90 [3] – стандарт на стадии и этапы создания ИС, соот-
ветствующие каскадной модели жизненного цикла ПО. В стандарте приво-
дится описание содержания работ на каждом этапе.
ISO/IEC 12207:1999 [4] «Information Technology – Software Life Cycle
Processes» – стандарт на процессы и организацию жизненного цикла заказ-
ного ПО. Он определяет структуру жизненного цикла, содержащую про-
цессы, действия и задачи, которые должны быть выполнены во время со-
здания ПО. Каждый процесс разделен на набор действий, каждое действие
– на набор задач. Каждый процесс, действие или задача инициируется и
выполняется другим процессом по мере необходимости, причем не суще-
ствует заранее определенных последовательностей выполнения.
Методология Oracle – технологический материал по разработке при-
кладных ИС, детализированный до уровня заготовок проектных докумен-
тов в расчете на использование Oracle. Применяется для классической мо-
дели жизненного цикла (предусмотрены все работы, задачи и этапы), а
также для технологий «быстрой разработки» или «облегченного подхода»,
рекомендуемых в случае малых проектов.
Методология RUP (Rational Unified Process) – технологический мате-
риал по реализации итеративной модели разработки, включающей 4 фазы:
начало, исследование, построение и внедрение. Каждая фаза разбита на
30
этапы (итерации), результатами которых являются версии для внутреннего
или внешнего использования. Каждый цикл завершается генерацией оче-
редной версии системы. Предполагает создание и сопровождение моделей
на базе UML.
Методология MSF (Microsoft Solution Framework) – технологический
материал по реализации итеративной модели разработки, аналогично RUP,
включает 4 фазы: анализ, проектирование, разработку, стабилизацию;
предполагает использование объектно-ориентированного моделирования.
Extreme Programming (XP) – экстремальное программирование. Ос-
новой методологии является работа в команде, эффективные коммуника-
ции между заказчиком и исполнителем в течение всего проекта; разработка
ИС ведется с использованием последовательно дорабатываемых прототи-
пов.
Стандарт ГОСТ 34.601-90 явно предполагает каскадную модель ЖЦ
ИС, а стандарт ISO/IEC 12207:1999 предлагает возможные варианты выбо-
ра ЖЦ, такие, как: каскадная, эволюционная, формирующая заранее пла-
нируемое улучшение продукта, спиральная модели.
Была выбрана каскадная модель разработки ИС, потому что она, во-
первых, достаточно проста для понимания и реализации на практике, а, во-
вторых, весьма эффективная и по сегодняшний день. Тем более для срав-
нительно небольших и несложных ИС, какой будет разрабатываемая в хо-
де дипломного проектирования система.
Согласно ГОСТ 34.601-90 выделяют такие этапы жизненного цикла
ИС:
1) Формирование требований к ИС.
2) Разработка концепции ИС.
3) Техническое задание.
4) Эскизный проект.
5) Технический проект.
6) Рабочая документация.
31
7) Ввод в действие.
8) Сопровождение ИС.
Преимущества применения каскадного способа заключаются в сле-
дующем:
на каждом этапе формируется законченный набор проектной доку-
ментации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволя-
ют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ИС,
для которых в самом начале разработки можно достаточно точно и полно
сформулировать все требования с тем, чтобы предоставить разработчикам
свободу реализовать их технически как можно лучше. Опять же, в рамках
данного проекта можно достаточно четко понимать, какая ИС нужна в ре-
зультате проектирования, поэтому использование каскадной модели ЖЦ
оправдано.
2.1.2.Ожидаемые риски на этапах жизненного цикла и их опи-
сание
При осуществлении любого проекта всегда возникает ситуация, свя-
занная с неопределенностью, неполнотой или неточностью информации об
условиях реализации проекта и связанных с ними затратах и результатах.
Все участники проекта заинтересованы в том, чтобы исключить возмож-
ность провала проекта из-за таких неопределенных ситуаций. Для того
чтобы снизить потери от возможных просчетов и избежать провала проек-
та в целом, методология управления проектами предусматривает специ-
альные процедуры, помогающие учесть факторы неопределенности и рис-
ка на всех фазах и этапах проекта.
Зная виды и значимость рисков, можно на них воздействовать, сни-
жая их отрицательное влияние на эффективность проекта. Следовательно,
создается реальная возможность управлять ими. Факторы риска и неопре-