88
Разработка начального варианта проекта, структура которого
включает в себя все требования, предъявляемые к производительности системы.
Есть 2 базовых подхода к созданию систем БД: внизу вверх и сверху вниз.
Первый подойдет для разработки простых БД с небольшим числом атрибутов.
Использования такого подхода сложно в процессе создания БД с огромным
числом атрибутов, и реализовать все возможные функциональные зависимости
очень непросто. При создании запутанных систем БД лучше всего использовать
подход сверху вниз, которых хорошо зарекомендовал себя в рамках модели
«сущность-связь». Тогда работа идет от определения сущностей и связей между
друг-другом, таких важных для данной разработки.
Весь процесс создания БД включает 3 фазы: создание концепции,
построение логической модели и проектирование прототипа. Любая фаза состоит
в разработке нужной модели данных, которая станет источником данных для
следующей фазы. Основной смысл в этом процессе заложен в концепцию данных,
реализуемую в рамках показателей, указанных в спецификации требований
пользователей. Проектировании концепции БД не связано с большими
подробностями ее создания, не описывается используемая целевая СУБД, тип
нужной вычислительной платформы и т.п., но качество такой модели станет
важным фактором, позволяющим отразить трудозатраты на разработку системы,
ее мощность и возможный успех. Опыт создания и внедрения ИС говорит о том,
что возможные ошибки на этом этапе очень трудно устраняемые и самые
серьезные, поскольку они встречаются потом только на этапе разработки или
обслуживании системы.
В рамках создания логической модели концепция данных превращается в
логическую модель, созданную на основе указанной модели хранения данных
исходной СУБД. Т.е., этот этап отражает, какая СУБД используется как целевая -
иерархическая, сетевая, реляционная или объектно-ориентированная. Тут же
пропускаются другие аспекты базовой СУБД – к примеру, отдельные нюансы
реализации физического хранения данных. Логическая модель, отражающая
особенности описаний реализуемой системе на несколько типов пользователей,
89
считается глобальной логической моделью информации. Существует пара
подходов для создания глобальной логической модели: метод обобщения
представлении и централизованный способ. Если готовится крупная ИС, логичнее
и правильнее использовать метод 1, когда глобальная логическая модель
информации реализуется методом совмещения нескольких моделей, отражающих
представления различных групп пользователей.
В процессе проектирования прототипа решаются задачи о способах
создания БД. Поэтому процесс проектирования сильно связан с исходной СУБД.
Между логической моделью и прототипом есть постоянная обратная связь, т.к.
все решения, принятые в процессе проектирования для повышения мощности
системы, окажут влияние и на структуру логической модели. Основной целью
создания прототипа БД называют характеристику метода физической реализации
проекта логической БД.
Сложности интерфейса пользователя в ИС. Совокупность методов
реализации взаимодействия с конечным пользователем сейчас становится
«интеллектуальным интерфейсом», создающим интерактивное решение
описанных проблем на ЭВМ. Нюансы разработки этих интерфейсов описаны в
работе, но важно заметить, что основной особенностью средств общения,
применяемых в современных ИС, считается сочетание языка общения с ними к
естественному. И подобная естественность языка взаимодействия «человек-ЭВМ
заключена не в том, что он использует весь словарь и методики синтаксиса и
семантики естественного языка, а в поддержке взаимодействия с ЭВМ
пользователя любого уровня подготовки. Поэтому естественным языком
состояния «человек-ЭВМ» является такой язык, использование которого иногда
не заставит пользователя применять заранее инструкции и учить различные
правила создания некоторых выражений.
Нужно указать достоинства среды WEB как методологии, используемой
для реализации интерфейса пользователя для работы с многочисленными БД.
Также становится понятно, что знакомая трехуровневая архитектура клиент-
серверных СУБД проецируется в среду Web, где Web-браузер считается более
90
«тонким» клиентом, а Web-сервер является в виде сервера приложений.
Трехуровневая архитектура растет до N-уровневой архитектуры, повышая
гибкость и расширяемость, делится на два уровня, при это первый выполняет роль
стандартного Web-сервера, а второй становится сервером приложений.
Среда Web, используемая в рамках платформы для программных продуктов
с БД, считается базой для современных решений в рамках внутри- и
межкорпоративных задач исследования данных.
Определение СУБД. В рамках работы с СУБД и ИС на их основе, учитывая
высказанные Е. Кодда, утверждаем, что все полномасштабные СУБД могут
выполнять отдельные описанные ниже действия, а именно:
Давать пользователям механизмы сохранения, обновления и
корректировки данных в БД, сохраняя в секрете конечного пользователя и
нюансы физического создания системы;
Давать разработчикам механизмы проектирования и быстрой
разработки приложений с автоматическим получением требуемой проектной и
рабочей документации;
Поддержка логичного и доступного как конечным пользователям,
так и системе каталога, который сохраняет в себе описание элементов данных.
Системный каталог или словарь данных считается хранилищем информации,
содержащей данные в БД, т.е. хранилищем метаданных, и становится средством
поддержания независимости программ от структур данных;
Доступная поддержка транзакций, механизмы корректного
обновления БД при запуске нескольких операции обновления группой
пользователей;
Включение компонентов, поддерживающих доступность к БД только
верифицированных пользователей, т.е. поддержка режима защищенности БД от
НСД;
Объединение с коммуникационным ПО для поддержки удаленного
доступа к центральной БД (в рамках системы обработки данных);
91
Обоснование механизмов для создания логичных и простых
пользовательских интерфейсов, которые становятся интеллектуальными
посредниками между системой и пользователями БД;
Встроенные механизмы контроля за тем, чтобы все изменения
данных отвечали заданным правилам, т.е. поддержка целостности данных;
Набор различных вспомогательных утилит, необходимых для
реализации помощи админу БД в процессе работы системы.
Цель определения СУБД основывается на выборе системы,
удовлетворяющей на 100% описанным выше требованиям, учитывая повышение
возможностей ИС при реальном уровне затрат, составляющих расходы на
получение СУБД и периферийного программного и аппаратного обеспечения, а
также средства, потраченные на переход к обновленной системе и организацию
обучения сотрудников.
Для оценки возможности СУБД используются различные параметры, а
также весовые коэффициенты, отражающие текущую важность конкретных
параметров или их групп. По итогу после сложения всех параметров остается
некая количественная оценка, используемая для сравнения разных систем.
Опыт разработки БД и других ИС говорит о том, что самыми сложными
моментами в процессе их создания становятся этапы их разработки и выбора
СУБД.
В процессе работы над ИС особую роль играют процессы подготовки
пользовательского интерфейса, описывающие наибольшее удовлетворение
пользователей в рамках их информационных потребностей и простоты работы в
системе.
Для выполнения данных требований необходимо и достаточно разработать
базу данных в среде СУБД Sqlite [5].
1.5.3 Обоснование проектных решений по техническому обеспечению
92
Техническое обеспечение включает в себя ПК, оргтехнику, линии связи,
сетевое оборудование. Вид ИТ, зависящий от технической оснащенности
(автоматизированный, удаленный или ручной) оказывает влияние на сбор,
обработку и передачу данных.
В совокупность технических средств включаются:
ПК;
устройства сбора, хранения, обработки, передачи и вывода данных –
жесткие диски, сканеры, принтеры, факсимильные аппараты;
устройства передачи данных и линий связи – коммутаторы,
маршрутизаторы;
эксплуатационные материалы – оптические носители, бумага и т. п.
В процессе выбора ПК важно опираться на ряд характеристик. К ним
относятся надежность, итоговая стоимость, мощность, простота использования и
др. От указанных параметров зависит доступность работы с необходимым ПО, и
как следствие, успех создания системы.
Каждый элемент данной схемы имеет перечень критериев, которые
оказывают особое влияние при выборе технического обеспечения. К ним
относятся:
Частота работы процессора;
Максимальное разрешение монитора;
Общий объем ОЗУ.
Разрабатываемый программный продукт имеет клиент-
серверную архитектуру.
Архитектура клиент-сервер основана на распределении функций между
двумя типами независимых и автономных процессов: серверами и клиентами.
93
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Процессы жизненного цикла проекта автоматизации
ЖЦ является непрерывным процессом, начинающимся с момента
зарождения решения о важности его создания и заканчивающимся тогда, когда
продукт изымается из эксплуатации [23].
Самые распространенные стандарты, это: [1]:
• ГОСТ 34.601-90 – относится к АИС и устанавливает части и этапы их
создания. Также в нем описано содержание работ на любом этапе. Этапы и стадии
проекта, указанные в стандарте, зачастую соответствуют каскадной модели ЖЦ
[27].
• ISO/IEC 12207 - стандарт на процессы и реализацию ЖЦ. Относится
ко всем видам заказного ПО. Стандарт не включает описания фаз, этапов и стадий
[7].
• Custom Development Method от Oracle по созданию прикладных ИС -
технологический материал, разработанный до уровня шаблонов проектных
документов, которые рассчитаны на применение в проектах, связанных с Oracle.
Используется CDM для стандартной модели ЖЦ (есть все задачи и типы), а также
для вариантов оперативной разработки (Fast Track) или простого подхода,
которые применяются в случае малых проектов [8].
• Rational Unified Process (RUP) описывает итеративную модель
разработки, состоящую из 4 фаз: начало, анализ, разработка и применение.
Каждая фаза делиться на этапы (итерации), по итогу которых выпускается версия
для применения внутри или вне [24]. Завершение всех 4 фаз считается циклом
разработки, каждый цикл по итогу представляет версию системы. Если после
этого проект не завершается, полученный продукт развивается дальше и проходит
все эти же фазы. Суть проекта в рамках RUP - это разработка и сопровождение
моделей на базе UML [37].
94
• Microsoft Solution Framework (MSF) схожа чем-то с RUP, имеет 4
фазы: анализ, подготовка, создание, тестирование, является итерационной, может
применять объектно-ориентированного моделирования. MSF в отличии от RUP
более ориентирована на создание бизнес-приложений [38].
• Extreme Programming (XP) - экстремальное программирование
(современная методология) была предложена в 1996 году. В базе методологии
командная работа, отличная коммуникация между исполнителем и заказчиком в
рамках выполнения всего проекта по созданию ИС, а сам процесс реализуется
посредством последовательно оптимизируемых прототипов [28].
В процессе подбора стандарта главным фактором становится полноценное
и подробное описание работ на этапах и стадиях разработки АИС.
Стандарт ISO/IEC 12207 не имеет полноценного описания работ на этапах
и стадиях создания АС.
Стандарт CDM применяется в проектах с Oracle технологиями, а в данном
проекте они не используются.
Стандарт MSF, исходя из описанного ранее, чаще всего ориентирован на
создание бизнес-приложений [8].
Стандарт XP относится к командной работе. В данном проекте применяется
ГОСТ 34.601-90, поскольку он включает описание работ на всех этапах создания
АС.
Главные этапы разработки ИС (рисунок 2):
1. Подготовка требований к системе;
2. Подготовка концепции;
3. Написание ТЗ;
4. Подготовка проекта;
5. Создание документов;
6. Применение.
95
1) Формирование требований к системе;
2) Разработка концепции;
6) Внедрение.
3) Техническое задание;
4) Технический проект;
5) Оформление документации;
Рисунок 2.1 Основные стадии создания ИС
На этапе “Формирование требований к системе”, производится следующие
работы:
- обследование объекта;
- формирование требований пользователя;
- обоснование необходимости разработки системы.
На данном этапе задействованы следующее участники: IT-менеджер,
начальник отдела делопроизводства. После выполнения всех работ формируется
отчет о проделанных работах - характеристика объекта автоматизации, описание
требований к системе, определение затрат на разработку, введение в
эксплуатацию и сопровождение, ожидаемый эффект от системы и условия
создания и эксплуатации системы[29].
После выполнения этапа “Формирования требований к системе”
разрабатываются варианты концепции. Производят разработку альтернативных
вариантов концепции и планов реализации, оценку необходимых ресурсов на
реализацию ИС и дальнейшее функционирование, оценка преимуществ и
96
недостатков каждого варианта, сопоставление требований пользователя и
характеристик предлагаемой системы[25].
На этапе “Разработка концепции” участвует IT-менеджер. После
выполнения данных работ выбирается один из подходящих вариантов концепции
удовлетворяющий всем требованиям[39].
После этапа “Разработка концепции” разрабатывается техническое задание
(ТЗ) проекта автоматизации. После разработки и оформления ТЗ, необходимо его
согласовать и утвердить. Участники на данном этапе работ: IT-менеджер,
начальник отдела делопроизводства[9]. В результате данный пункт определяет:
функции ИС, функции подсистем, состав комплекса задач и отдельных задач,
концепция информационной базы, функции систем управления базой данных, а
также функции и параметры программных средств[26].
Следующим этапом после разработки и утверждения ТЗ идет разработка
проектного решения. IT-менеджер, совместно с программистом, разрабатывают
физическую и логическую модель БД, определяют организацию базы данных [30].
По завершению этапа “Технический проект” IT-менеджером совместно с
программистом производится оформления рабочей документации, включающие
в себя: технические требования, программные требования, руководство
пользователя. После выполнения всех работ и оформления рабочей документации
остается этап внедрения разрабатываемого проекта[27].
На этапе внедрения происходит: подготовка объекта автоматизации,
обучение персонала, производятся строительно-монтажные работы,
пусконаладочные работы, проведение предварительных испытаний, проведение
опытной эксплуатации и проведение приемочных испытаний. Участники данного
этапа: IT-менеджер, системный администратор, начальник отделе
делопроизводства. После чего анализируются испытания ИС, проверка на
соответствие ТЗ, устраняются неполадки и подписываются необходимые акты.
В настоящее используются следующие модели жизненного цикла:
97
Каскадная модель (рисунок 2.2) предусматривает последовательное
выполнение всех этапов проекта в строго фиксированном порядке. Переход на
следующий этап означает полное завершение работ на предыдущем этапе;
Разработка требований
Проектирование
Реализация
Тестирование
Ввод в действие
Рисунок 2.2 - Каскадная модель ЖЦ ИС
Поэтапная модель с промежуточным контролем (рисунок 2.3).
Разработка ИС ведется итерациями с циклами обратной связи между этапами.
Межэтапные корректировки позволяют учитывать реально существующее
взаимовлияние результатов разработки на различных этапах; время жизни
каждого из этапов растягивается на весь период разработки;
Разработка требований
Проектирование
Реализация
Тестирование
Ввод в действие
Рисунок 2.3 - Поэтапная модель с промежуточным контролем
Спиральная модель (рисунок 2.4). На каждом цикле выполняется
создание очередной версии продукта, уточняются требования проекта,
определяется его качество и планируются работы следующего цикла[4]. Особое