56
связью с внешними таблицами и базами данных. Благодаря встроенному языку
VBA, в самом Access можно писать приложения, которые работают с базами
данных;
dBase - семейство широко распространённых систем управления базами
данных, а также язык программирования, который используется в них;
OracleDatabase или OracleRDBMS – представляет собой объектно-
реляционную систему управления базами данных компании Oracle;
MicrosoftSQLServer - система управления реляционными базами данных,
которую разработала корпорация Microsoft. Основным используемым языком
запросов является Transact-SQL, создан совместно с Microsoft и Sybase.
Применяется для того, чтобы работать с базами данных размером от
персональных до крупных баз данных масштаба предприятия; входит в
конкурирующие отношения с другими СУБД в данном сегменте рынка;
PostgreSQL – представлена cвободной объектно-реляционной системой
управления базами данных;
MySQL - свободная система управления базами данных. Продукт
распространяют как под свободной лицензией, так и под собственной
коммерческой лицензией. В самых ранних версиях возник механизм
репликации; [17]
SQLite – представляет собой легковесную встраиваемую реляционную
базу данных. Исходный код библиотеки передан в общественное достояние.
Предпочтения автора были отданы СУБД MySQL по следующим
причинам:
MySQL портирована на большое количество платформ
(Unix/MacOS/Windows);
MySQL имеет API для языковDelphi, C, C++, Java, Лисп, Perl, PHP,
Python, Ruby, Smalltalk, Компонентный Паскаль и Tcl, библиотеки для
языков платформы .NET, а также обеспечивает поддержку для ODBC
посредством ODBC-драйвера MyODBC; [16]
MySQL распространяется бесплатно;
гибкостьMySQLобеспечивается поддержкой большого числа типов
таблиц: тип MyISAM, которые поддерживают полнотекстовый поиск,
57
таблицыInnoDB, которые поддерживают транзакции на уровне
отдельных записей; [18]
MySQL является реляционной СУБД. [10]
1.4.2 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение системы должно максимально и самым
эффективным образом пользоваться имеющимися на предприятии техническими
средствами.
В состав системы следует включить следующие технические средства:
веб-сервер;
сервер СУБД;
ПК пользователей;
ПК администратора.
Веб-сервер необходимо оснастить функцией зеркалирования жестких
дисков и объединить в одну локальную сеть с клиентскими машинами,
имеющую пропускную способность не менее 100 Мбит/сек.
Требования к техническим характеристикам веб-сервера следующие:
процессор – Intel Corei5 3.7ГГц;
объем оперативной памяти – 8 Гб;
дисковая подсистема – 2 х 500 Гб;
устройство чтения компакт-дисков (DVD-ROM);
сетевой адаптер – 100/1000 Мбит;
дисковая подсистема 0,5 Тб RaidArray 5.
Выбор аппаратной составляющей для сервера СУБД во многом
определяется конкретной СУБД, предполагаемым количеством одновременно
работающих пользователей, спецификой проекта и результатами нагрузочного
тестирования прикладного проекта.
Требования к техническим характеристикам сервера СУБД:
процессор – Intel(R) Xeon® CPUE5-2690 0 @ 2.90 ГГц (4 ядра);
платформа - 32-х или 64-х разрядная;
оперативная память - не менее 10 Гб;
58
дисковая подсистема - не менее 750 Гб;
сетевой адаптер – 100/1000 Мбит.
Требования к техническим характеристикам ПК пользователей и ПК
администратора системы:
процессор – Intel Pentium Dual Core 2.8 ГГц;
объем оперативной памяти – 4 Гб;
дисковая подсистема – 500 Гб;
устройство чтения компакт-дисков (DVD-ROM);
сетевой адаптер – 100/1000 Мбит.
1.4.3. По технологическому обеспечению.
Для решения задачи в текущем варианте на предприятии компьютерная
техника используется частично. Ведомости и реестры заполняются вручную в
программе Excel.
Использование автоматизированной системы позволит значительно
ускорить время обработки заявок пользователей и реагирования на них.
При сборе и регистрации информации особое значение придается
достоверности, полноте и своевременности первичной информации. На
предприятии сбор и регистрация информации происходят при выполнении
различных хозяйственных операций.
Сбор информации, как правило, сопровождается ее регистрацией, т.е.
фиксацией информации на материальном носителе (документе, машинном
носителе), вводом в ЭВМ. Запись в первичные документы в основном
осуществляется вручную, поэтому процедуры сбора и регистрации остаются
пока наиболее трудоемкими. В условиях автоматизации управления компанией
особое внимание придается использованию технических средств сбора и
регистрации информации, совмещающих операции количественного измерения,
регистрации, накопления и передачи информации по каналам связи, ввод
непосредственно в ЭВМ для формирования нужных документов или накопления
полученных данных в системе. [13]
59
Хранение и накопление информации вызвано многократным ее
использованием, применением условно-постоянной справочной и других видов
информации, необходимостью комплектации первичных данных до их
обработки. Хранение и накопление информации осуществляется в
информационных базах, на машинных носителях в виде информационных
массивов, где данные располагаются по установленному в процессе
проектирования порядку.
С хранением и накоплением непосредственно связан поиск данных, т.е.
выборка нужных данных из хранимой информации, включая поиск информации,
подлежащей корректировке или замене. Процедура поиска информации
выполняется автоматически на основе составленного пользователем или ЭВМ
запроса на нужную информацию.
Обработка информации производится на ЭВМ в местах возникновения
первичной информации, где организуются автоматизированные рабочие места
(АРМ) специалистов. Обработка может производиться не только автономно, но
и в вычислительных сетях, с использованием набора ЭВМ программных средств
и информационных массивов для решения функциональных задач.
60
2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Под жизненным циклом (ЖЦ) программного обеспечения понимают
период от начала разработки нового программного средства до снятия его с
эксплуатации у потребителя.
Разработка системы разбивается на следующие этапы:
техническое задание (ТЗ);
эскизный проект (ЭП);
технический проект (ТП);
предварительное проектирование;
рабочий проект (РП);
внедрение.
При использовании CASE-технологии стадии «техническое задание»,
«эскизный проект» и «технический проект» объединяются в одну стадию
«предварительное проектирование».
Общая трудоемкость и длительность создания системы рассчитывается на
основе алгоритма разработки (см. таблица 2.1).
Таблица 2.1 - Алгоритм разработки системы
Источник
формирования ТЗ
Стадии разработки системы
а
б (выбранный
алгоритм)
в
Традиционные
стадии разработки
ПП
С использованием
CASE-технологии
Стадии при
объединении
технического и
рабочего проекта
ТЗ формируется
«Техническое
«Техническое
«Техническое
61
разработчиком
задание»;
«Эскизный
проект»;
«Технический
проект»;
«Рабочий
проект»;
«Внедрение»;
задание»;
«Предварительное
проектирование»;
«Рабочий проект»;
«Внедрение»;
задание»;
«Эскизный
проект»;
«Технорабочий
проект»;
«Внедрение»;
Трудоемкость разработки системы зависит от степени новизны
разработки, сложности алгоритма её функционирования, объема используемой
информации и виде её обработки, уровня используемого алгоритмического
языка программирования.
По степени новизны разрабатываемый системы относится к группе
«В» (разработка программной продукции, имеющей аналоги). По степени
сложности алгоритма функционирования системы относится к 3-ей группе
(программная продукция, реализующая алгоритмы стандартных методов
решения задач).
Модель жизненного цикла представляет собой структуру, состоящую из
процессов, действий и задач, которые реализуются при разработке,
функционировании и сопровождении программного продукта в продолжение
всей жизни системы, от установления требований до завершения ее применения.
Имеется ряд моделей и стандартов, в определенной мере направленных на
регламентирование жизненного цикла, многие из них принадлежат к заказному
ПО (автоматизированным системам АС, и др.) и помимо непосредственно ЖЦ
регламентируют также и процессы разработки:
ГОСТ 34.601-90 касается автоматизированных систем и определяет стадии
и этапы их создания. К тому же, стандарт содержит описание содержания работ
на всех этапах. Стадии и этапы работы, которые закреплены в стандарте, в
большей мере подходят под каскадную модель жизненного цикла;
ISO/IEC 12207:1995 стандарт касается процессов и организации
жизненного цикла. Затрагивает все виды заказного ПО. В стандарте не
62
содержится описание фаз, стадий и этапов;
CustomDevelopmentMethod (и, методика Oracle) по разработке прикладных
информационных систем под заказ – является конкретным материалом,
детализированным до уровня заготовок проектных документов, которые
рассчитаны на применение в проектах с использованием Oracle. Степень
адаптивности CDM ограничивают три модели ЖЦ: "классическая"
(предусматриваются все работы/задачи и этапы), "быстрая разработка"
(FastTrack), "облегченный подход", который рекомендуется в малых проектах и
при возможности быстрого прототипирования приложения; [4]
RationalUnifiedProcess (RUP) предлагает итеративную модель разработки,
состоящую из четырех фаз: начала, исследования, построения и внедрения.
Каждую фазу можно разбить на этапы (итерации), в результате которых
происходит выпуск версии для внутреннего или внешнего применения.
Прохождение через четыре главные фазы обозначают как цикл разработки,
каждый цикл завершает генерация версии системы. Если после этого работа над
проектом не завершается, то развитие полученного продукта продолжается, и он
снова проходит те же фазы. Суть работы в рамках RUP - это создавать и
сопровождать модели, а не бумажные документы, поэтому данный процесс
привязан к пользованию конкретными средствами моделирования (UML), а
также конкретной технологией проектирования и разработки (объектно-
ориентированный анализ, object-orientedanalysis, OOA, объектно-
ориентированное программирование, object-orientedprogramming, OOP);
MicrosoftSolutionFramework (MSF) сходна с RUP, также состоит из
четырех фаз: анализа, проектирования, разработки, стабилизации, считается
итерационной, предполагает пользование объектно-ориентированным
моделированием. MSF, если сравнивать с RUP, в большей мере ориентирована
на разработку бизнес-приложений.
Основные критерии для выбора стандарта ЖЦ представлены:
актуальностью и современностью применяемых методик контроля
разработки
разработкой в итерационном режиме с возможностью осуществлять
контроль рисков и выполнять сам проект на неких контрольных точках,
63
отсутствием дополнительных требований по моделированию процесса
разработки и внедрения.
Резюмируя описание стандартов выше, отметим, что итерационными из
них считаются 4 стандарта: MSF, RUP, COBIT, XP .
Стандарт COBIT не подходит, так как основная цель его применения – это
проведение аудита и стратегического планирования ИС и IT инфраструктуры в
целом.
Стандарт XP не подходит, поскольку в нем не содержатся полноценные
этапы ЖЦ, представленные выработкой концепции, планированием,
разработкой, стабилизацией, внедрением.
Соответственно, необходимо выбрать Rup или MSF. Оба стандарта
молодые и поддерживают все новые технологии продуктивной разработки и
контроля их выполнения.
RationalUnifiedProcess представляет собой хорошо сбалансированное
решение для средних по размерам коллективов разработчиков, которые
работают с использованием продуктов и технологий компании Rational.
Сопровождение разработки системы и самой системы регламентирует
методология RUP, но все же эта технология весьма сильно ориентирована на
внутрифирменные инструментальные средства. [4]
ExtremeProgramming хорошо подходит для проектных групп, имеющих
малый размер, и для небольших систем, в которых часто изменяются
требования.
Ключевая проблема XP выражена сопровождением. Если имеет место
текучка кадров в коллективе разработчиков, то значительную часть проектной
информации можно потерять вследствие практически отсутствующей
документации.
MicrosoftSolutionsFramework представляет собой наиболее
сбалансированную технологию, ориентированную на проектные группы,
имеющие малые и средние размеры. MSF не накладывает никаких ограничений
на применяемый инструментарий и содержит довольно общие рекомендации.
Однако, этими рекомендациями можно воспользоваться, чтобы построить
конкретный процесс, соответствующий потребностям коллектива
64
разработчиков. Помимо этого, основное преимущество MSF представлено
итерационной моделью одновременно с уточняющими вехами (аналог каскадной
модели). Итак, в реализации MSF сделана попытка объединения каскадной и
итерационной модели разработки и внедрения ПО.
Исходя из описанных выше преимуществ, мы выбрали стандарт MSF как
самый гибкий и удобный для осуществления АИС.
Для реализации системы был выбран стандарт MSF. Одно из преимуществ
выбранного стандарта представлено возможностью управления одновременно и
проектом разработки приложения и внедрением инфраструктуры.
В качестве стандарта жизненного цикла был выбран стандарт ГОСТ
34.601-90.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Поскольку весь ЖЦ проекта разделён на этапы, каждый этап обладает
ролями, за которыми закреплены цели, которые следует достигнуть, и всё же на
каждой фазе имеются некоторые риски:
В фазе выработки концепции возможно возникновение следующих
рисков:
недальновидный анализ сроков проекта и его бюджета. Чтобы
ликвидировать такой риск, необходимо более детально прорабатывать задачи и
цели проекта, устанавливать больше контрольных точек;
неправильно подобранный проектный состав исполнителей может
привести к полному отсутствию командной работы. Для уменьшения данного
риска более тщательно подбирают специалистов в проектную группу, тестируя
не только профессиональные навыки, но и личностные качества.
На фазе планирования возможно возникновение следующих рисков:
неверно или не совсем корректно сформированная архитектура
выбираемого решения. На возможность возникновения данного риска влияет
компетенция руководителя проекта, который должен принять решение о выборе
архитектуры разрабатываемого решения.
В фазе разработки возможно возникновение следующих рисков:
65
неправильная интерпретация технического задания и как результат
неправильное программирование архитектуры и сдвиг сроков. Чтобы
минимизировать данный риск, нужно более чётко написать техническое задание,
понятное для программиста;
еще один немаловажный риск в этом проекте представлен отсутствием
необходимой квалификации у программиста в том языке, на котором решено
реализовывать программу, которая будет распределять заявки между
инженерами.
В случае, если программист не будет успевать в заданное время
календарного плана проекта, придется воспользоваться внешним разработчиком,
так называемым “аутсорсингом” или “фрилансом”.
В фазе тестирования возможно возникновение следующих рисков:
риски неоконченного тестирования. Возможна ситуация, когда
программный продукт будет протестирован не до конца. При этом необходимо
провести повторное тестирование на следующей итерации разработки.
В фазе внедрения возможно возникновение следующих рисков:
риски неправильного принятия решения о законченности части проекта.
Данные риски приводят к проблеме незаконченности решения и возможности
появления нестыковок с другими частями разрабатываемой ИС. Для устранения
необходимо доработать при следующей итерации.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для данного комплекса задач существует несколько реализации
информационной безопасности.
Защита от внутренних угроз. Подразумевает разграничение прав
пользователей. Подробные права пользователей описаны в таблице 2.2.
Таблица 2.2 - Разграничение прав пользователей
Группы
пользовате
лей
Редактирова
ние заявки
Возможно
сть
просмотра
всех
Создан
ие
заявки
Работа с БД