35
1.5.4 По технологическому обеспечению
При разработке программы одним из важных вопросов является выбор
типа многопользовательской архитектуры. В данной работе наиболее
целесообразно использовать архитектуру «файл-сервер» (разделяемый
пользователями файл на компьютере-сервере). Организация модели удаленного
доступа к данным достаточно проста и не требует установки на сервер СУБД с
большими вычислительными ресурсами, существенно «загружающей» сервер.
Существует несколько способов защиты информации, хранящейся в базе
данных:
Установка пароля для открытия базы данных. После установки
пароля при каждом открытии базы данных будет появляться диалоговое окно, в
которое требуется ввести пароль. Пароль шифруется, поэтому к нему нет
доступа при непосредственном чтении файла базы данных.
Защита на уровне пользователей. Этот способ защиты подобен
способам, используемым в большинстве сетевых систем. Основными
причинами использования защиты на уровне пользователей являются защита
приложения от повреждения из-за неумышленного изменения пользователями
таблиц, запросов, форм, отчетов и макросов, от которых зависит работа
приложения и защита конфиденциальных сведений в базе данных. Группам и
пользователям предоставляются разрешения на доступ, определяющие
возможность их доступа к каждому объекту базы данных.
Аудит работы с файлом базы данных, позволяющий отследить какой
пользователь и каким образом работал с файлом базы данных.
Этап ввода информации в ПК является наиболее ответственным с точки
зрения обеспечения достоверности информации. Причины, приводящие к
возникновению ошибок во вводимой информации, на этапе ввода, могут
зависеть либо от состояния оборудования, на котором осуществляется ввод,
либо от организации процесса ввода.
36
Для уменьшения ошибок при вводе информации в ПК в некоторых полях
базы данных задаются условия на значение. В самом простом случае условие на
значение должно гарантировать, что из-за ошибки ввода в числовом поле не
окажутся буквенные символы. Другие условия могут определять область или
диапазоны допустимых значений. Заданное условие на значение всегда будет
проверяться при вводе или изменения значения поля в таблице.
Кроме того, для уменьшения ошибок при вводе данных используется
маска ввода. Маска ввода удобна при использовании полей, размер и
смысловая нагрузка которых заранее известна.
Для взаимодействия с пользователем программы предполагается
использование меню, подсказок, полей, отвечающих за ввод информации, а
также кнопок, результатом нажатия на которые будет отображение того или
иного запроса к базе данных.
В результате работы программы пользователь может столкнуться с
ошибками, связанными с получением результатной информации. Для
устранения таких ошибок используется процесс отладки программного
средства. Процесс отладки осуществляется в некотором контрольном наборе
данных. При этом значения, полученные программным путем, сравниваются со
значениями, полученными в результате ручных вычислений.
37
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Понятие жизненного цикла является одним из базовых понятий
методологии проектирования информационных систем. Жизненный цикл
информационной системы представляет собой непрерывный процесс,
начинающийся с момента принятия решения о создании информационной
системы и заканчивается в момент полного изъятия ее из эксплуатации.
Жизненный цикл информационной системы охватывает все стадии и
этапы ее создания, сопровождения и развития:
исследование предметной области с последующим формированием
функциональной и информационной моделей объекта, для которого
предназначено автоматизированное рабочее место;
проектирование системы, заключающееся в разработке проектных
решений, удовлетворяющих всем требованиям ТЗ;
разработку системы (в том числе программирование и тестирование
прикладных программ на основании проектных спецификаций
подсистем, выделенных на стадии проектирования);
тестирование информационной системы и выявление сбоев с
последующим их устранением;
эксплуатацию системы и ее сопровождение;
развитие системы.
Жизненный цикл протекает в соответствии с выбранной моделью ЖЦ.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в
некоторых случаях и процессы разработки.
Среди наиболее известных стандартов можно выделить следующие:
ГОСТ 34.601-90 - распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
38
описание содержания работ на каждом этапе. Стадии и этапы работы,
закрепленные в стандарте, в большей степени соответствуют каскадной модели
жизненного цикла .
ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного
цикла. Распространяется на все виды заказного ПО. Стандарт не содержит
описания фаз, стадий и этапов .
Custom Development Method (методика Oracle) по разработке прикладных
информационных систем - технологический материал, детализированный до
уровня заготовок проектных документов, рассчитанных на использование в
проектах с применением Oracle. Применяется CDM для классической модели
ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий
"быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых
в случае малых проектов.
Rational Unified Process (RUP) предлагает итеративную модель
разработки, включающую четыре фазы: начало, исследование, построение и
внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате
которых выпускается версия для внутреннего или внешнего использования.
Прохождение через четыре основные фазы называется циклом разработки,
каждый цикл завершается генерацией версии системы. Если после этого работа
над проектом не прекращается, то полученный продукт продолжает
развиваться и снова минует те же фазы. Суть работы в рамках RUP - это
создание и сопровождение моделей на базе UML.
Microsoft Solution Framework (MSF) сходна с RUP, так же включает
четыре фазы: анализ, проектирование, разработка, стабилизация, является
итерационной, предполагает использование объектно-ориентированного
моделирования. MSF в сравнении с RUP в большей степени ориентирована на
разработку бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование (самая
новая среди рассматриваемых методологий) сформировалось в 1996 году. В
39
основе методологии командная работа, эффективная коммуникация между
заказчиком и исполнителем в течение всего проекта по разработке АРМ, а
разработка ведется с использованием последовательно дорабатываемых
прототипов.
Стандарт ISO/IEC серии 15288
В стандарте ISO/IEC 12207 не предлагается конкретной модели
жизненного цикла и методов разработки, его рекомендации являются общими
для любых моделей жизненного цикла. Под моделью обычно понимается
структура, определяющая последовательность выполнения и взаимосвязи
процессов, действий и задач на протяжении жизненного цикла.
В настоящее время существует две основные модели жизненного цикла –
это каскадная и спиральная модели. В каскадной модели процесс разработки
идет поэтапно, шаг за шагом. Переход к следующему этапу происходит только
после завершения предыдущего. В спиральной модели разработка проходит по
нарастающей. На начальном этапе разрабатывается система с высоким уровнем
абстракции, а на последующих витках эта разработка все больше и больше
конкретизируется. Для жизненного цикла текущего проекта была выбрана
каскадная модель, так как для разрабатываемой системы больше подходит
поэтапная разработка. Переход к следующему этапу происходит только после
завершения всех работ на предыдущем этапе (Error: Reference source not
found1), включая подготовку полного пакета документации, достаточной для
того, чтобы разработка могла быть продолжена другой группой разработчиков
и есть возможность планирования сроков завершения работ и затрат на их
выполнение.
40
Рисунок 2.1 Каскадная схема разработки ПО.
Каскадный метод хорошо подходит для построения систем, где в самом
начале разработки можно достаточно точно и полно сформулировать все
требования, с тем, чтобы предоставить разработчикам свободу реализовывать
их как можно лучше с технической точки зрения. Однако в случае, если в
середине разработки вскрываются ошибки, допущенные в начале, то
приходится прибегать к энтраверсии проекта и реальная схема каскадной
модели приобретает другой вид (Error: Reference source not found). Таким
образом, каскадный метод более всего подходит к конкретной разработке.
Рисунок 2.2 Реальный процесс разработки ПО по каскадной схеме.
41
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание.
Любой проект по созданию информационной системы предприятия
всегда включает множество задач, связанных с общим управлением проектом,
разработкой ПО, проектированием АРМ, внедрением, каждая из которых сама
по себе является проектом с присущими ему особенностями. Поэтому в ходе
разработки существуют различные риски.
Риски заказчика связаны с неполным достижением целей проекта и не
эффективно израсходованными средствами, а риски исполнителя - с
возможностью резкого превышения фактической себестоимости работ по
сравнению с плановой. Необходимость ведения параллельных и подчас
принципиально отличающихся по своему характеру работ приводит к тому, что
многократно возрастает уровень риска проекта.
Наиболее характерные риски и методы из минимизации приведены в
таблице 2.1.
Таблица 2.1 Возможные риски проекта и способы их минимизации
Виды рисков/варианты
менеджмента рисков
Снижение видов
риска
Снижение вероятности
возникновения риска
Риски, связанные с
масштабом проекта
Детальный анализ
каждого этапа работ,
взаимодействия участников,
организации работ
Детально проработанная
программа качества,
отработанное управление
конфигурацией проекта,
специальные процедуры
взаимодействия участников
Риски, связанные с
недостаточным опытом в
сфере ИТ
Проведение обучения
пользователей, включая
руководство, соблюдение
технологий работы
Разработка и
утверждение концепции
проекта на возможно более
ранней его стадии
Технические риски
проекта
Строгий отбор
проектной команды по
Использование
стандартов предприятия на
проектные работы,
42
квалификационным
критериям. Обучение
участников проекта
технологии проектных
работ, инструментальным
средствам
разработка стандартов
проекта
Организационные риски
проекта
Обучение участников
проекта (курс "управление
проектом"), тренинги
команды, как можно более
полная формализация
деятельности
Включение в команду
администратора проекта,
детальное распределение
ролей в проекте
Операционные риски
проекта
Многократное
тестирование созданных
продуктов, тщательная
экспертиза документов
Строгое выполнение
процедур программы
качества
2.2. Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель предназначена для описания информационных
потоков предметной области. В информационной модели должна быть
отражена вся информация, необходимая для решения поставленной задачи. Для
каждого информационного потока необходимо указать его источник, пути
преобразования и приемник. Информационная модель отражает не только
состав и способы получения исходной информации, но и распределение ее по
задачам. При описании процесса преобразования информационного потока в
информационной модели фиксируются характеристики информации на каждом
этапе ее обработки, а также отображаются взаимосвязи входных,
промежуточных и результатных данных. Для каждого информационного
потока указывается способ выдачи результатных данных и приводится
перечень адресатов, для которых эти данные предназначены.
43
Информационная модель должна описывать все информационные потоки
предприятия, вне зависимости от того, какие типы носителей используются для
хранения и передачи данных. Более того, в информационной модели
фиксируется состав и структура всех документов, необходимых для работы
системы. Состав файлов, используемых для получения информации, или
генерируемых при работе системы с целью хранения промежуточной и
результатной информации, также должен быть отражен в информационной
модели.
Модель имеет семь логических уровней:
Источники информации;
Первичные документы или файлы;
Таблицы с первичными документами;
Справочники;
Таблицы и справочники с результатной информацией:
Результатные документы или файлы;
Получатели информации;
2.2.2. Используемые классификаторы и системы кодирования
Классификатор (от лат. classis — разряд и facere — делать) —
систематизированный перечень наименований объектов, каждому из которых в
соответствие дан уникальный код. Классификация объектов производится
согласно правилам распределения заданного множества объектов на
подмножества (классификационные группировки) в соответствии с
установленными признаками их различия или сходства. Применяется в
Автоматизированных системах управления и обработке информации.
Классификатор является стандартным кодовым языком документов,
финансовых отчётов и автоматизированных систем.
44
Классификаторы разрабатываются как на уровне отдельных предприятий
(организаций), так и на уровне государств. Существуют следующие уровни
классификаторов:
международные — стандартные классификаторы, используемые по всему
миру;
межгосударственные — классификаторы, используемые в рамках
экономических союзов и других межгосударственных объединений:
например, классификаторы используемые в ЕС, СНГ и т. д.
национальные, или межотраслевые — классификаторы, используемые в
пределах государства. Не должны противоречить международным
классификаторам;
отраслевые — классификаторы, используемые в рамках одной отрасли;
системные — классификаторы, принятые отдельным предприятием
(организацией) для применения в рамках своей автоматизированной
системы. Они содержат информацию, необходимую для решения задач в
конкретной АС и отсутствующую в национальном или отраслевом
классификаторе.
К объектам классификации и кодирования относятся:
справочные реквизиты-признаки, описывающие процессы, место, время
выполнения процессов, субъекты и объекты действия, отражаемые в
показателе,
наименования показателей и документов, наименования компонентов
проекта АРМ (файлов, задач, подсистем, программных модулей, и прочее).
В классификаторах применяется два метода классификации:
иерархический и фасетный. Выбор между этими двумя методами зависит от
особенностей конкретной предметной области.
При решении поставленной задачи разработки АРМ использовалась
иерархическая система классификации.