42
при реализации алгоритмов указанного приложения не нужно использовать какие-
либо специфические функции ОС. Оба упомянутых типа операционных систем
дают возможность разрабатывать ПО без потери его функциональности, т.к. они
обладают программными средами (языками программирования) для обоих этих
типов операционных систем.
И Windows, и Linuxсодержат интерфейсы межсетевого взаимодействия, что
позволит использовать программное приложение в сети Центра – для обмена
данными и одновременной работы нескольких копий ПО с одними исходными
данными. Два указанных типа операционных систем уже содержат в себе
качественный пользовательский интерфейс, что также даст возможность
производить разработку ПО для любой из этих ОС.
В качестве ОС для разработки и применения программы была выбрана
Windows, в частности операционная система Windows XP. Этот выбор обусловлен
тем, что Windows XPпродолжает оставаться сегодня одной из наиболее
распространенных операционных систем. ОС WindowsXP имеет привычный
функционал и обеспечивает стабильность работы, предоставляя возможность её
пользователям сосредоточиться на выполняемой работе.
Одним из основных требований, предъявляемых к проектированию ИС,
совместно эксплуатируемых на базе технологии с весьма ограниченными
возможностямий, является большая их однородность, которая позволяет
обеспечитьмобильность, совместимость, переносимость.
Подбор СУБД, системы управления баз данных – это сложная
многопараметрическая задача,один из важных этапов при создании приложений
баз данных. Отобранный программный продукт обязан бюыть таким, который
удовлетворяет как текущие, так и будущие потребности организации. При этом
следует учитывать расходы на приобретение нужного оборудования, самой
системы, разработку специальногоПО на ее основе и , на обучение сотрудников.
Также нужно узнать, способна ли новая СУБД принести организации реальную
выгоду.
Самый простой подход при подборе СУБД основан на понимании того, в
какой мере наличествующие системы адекватны основным требованиям нового
проекта ИС [14]. Более дорогостоящим и сложным является создание тестового
43
проекта на основе более одной СУБД и дальнейший выбор наиболее подходящего
из кандидатов. Однако и в данном случае нужно ограничивать круг потенциальных
систем, опираясь на собсвтенные критерии отбора. В нашем случае можно
выделить несколько таких групп критериев:
- производительность,
- моделирование данных,
- контроль работы системы,
- требования к рабочей среде,
-функциональные возможности.
- надежность,
-особенности архитектуры,·
- особенности разработки приложений
- смешанные критерии
Главный принципом выбора СУБД – определение ПО, которое бы в
наибольшей мере соответствовало предъявляемым требованиям. Эту задачу не
просто решить. Во-первых, СУБД имеют значительное число разнообразных
параметров, и это затрудняет их сравнение. Во-вторых, источники информации о
СУБД могут быть недостоверными (рекламный сайт, заказанная обзорная статья).
В-третьих, к СУБД предъявляется большое число требований и эти требования
постоянно изменяются.
Выбор СУБД необходимо проводить в три этапа:
1) оценка предлагаемых программные продуктов на предмет пригодности;
2) анализ технических характеристик отобранного ПО;
3) анализ производительности ПО.
В перечень основных показателей пригодности ПО входят:
- вид ПО;
- категории обслуживаемых пользователей (конечные пользователи,
пользователи-разработчики приложений, программисты, администраторы баз
данных, различные комбинации вышеуказанных категорий);
- простота и удобство в пользовании (легкая установка, удобный интерфейс,
простота выполнения базовых операций, таких, как созданиебазы данных,
навигация, модификация, подготовка данных, выполнение запросов и отчетов ит.д.;
44
присутствие системы подсказок для новичков, помощи в процессе обучения
илиработы);
- модель представления данных (сегодня самая популярная модель данных –
это реляционная; модели с объектной ориентацией – перспективные модели, т.к.
они позволяют максимально полно отражать семантику предметной области);
- качество средств разработки (при анализе качества средств разработки
берутся во внимание следующие характеристики: мощность языка
программирования, возможность создания пользовательских интерфейсов,
автоматизация разработки разных объектов, таких как экранные формы, запросы,
отчеты; системам, которые имеют полнофункциональные генераторы и
обеспечивают удобство использования, отдается предпочтение);
- качество средств контроля корректности и защиты БД (важнейшие
функции контроля корректности: проверка корректности введенных значений в
базу данных, обеспечение уникальности записей по первичному ключу,
автоматический контроль целостности межтабличных связей при выполнении
операций обновления / вставки / удаления записей; доступ к защитным функциям
должен быть предусмотренкак на уровне пользователя, так и на уровнесредств
программной разработки);
- качество коммуникационных средств (при анализе качества
коммуникационных средств следует обращать внимание на такие свойства ПО, как
наличие средств групповой работы с БД, поддержка сетевых
протоколов,поддержка стандартных интерфейсов с БД, возможность использовать
и модифицировать БД иных форматов без преобразования иимпортирования);
- компания – разработчик (компания-разработчик пакета должна
предоставлять программные продукты высокого качества, документацию и
методические материалы, «горячую линию» для консультаций по текущим
вопросам).
При выборе ПО необходимо обращать внимание на дату его появления. Чем
новее ПО, тем больше у него перспектив развития и поддержки со стороны
компании-разработчика. Также необходимо обращать внимание на его стоимость,
которая на отечественном рынке как правило,варьируется от 10 000 рублей
(MSAccess) до 160 000 (OracleMySQL). В общую стоимость входит стоимость
45
компонентов настройки конфигурации, прикладных компонентов,
администрирования и сопровождения баз данных. Основным фактором, влияющим
общую стоимость системы, в основном является количество поддерживаемых
пользователей.
Разнообразие СУБД на уровне технических характеристик еще больше, чем
на качественном уровне. В технические характеристики включают:
1) общие параметры (потребность в оперативной памяти, операционная
среда, предел максимально допустимой по объему БД и проч.);
2) типы данных;
3) ограничения на операции с данными;
4) возможности средств создания и выполнения запросов;
5) возможность работы в многопользовательских средах;
6) инструменты разработки приложений;
7) возможности импорта/ экспорта.
Оценка производительности осуществляется методом тестирования при
помощи эталонных тестов, взятых из набора ANSI SQL Standard Scalable and
Portable(AS3AP). В них анализируется широкий спектр часто встречающихся
операций БД и моделируются одно- и многопользовательские среды.
В нашем дипломном проекте в качестве СУБД был выбран MicrosoftAccess
2007 из-за его простоты в использовании и дешевизны.
Языком программирования для СЭД «Документооборот ЦМК» выбран
Delphi версии 7.0.
1.4.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение включает в себя персональный компьютер,
оргтехника, линии связи, оборудование сетей. Информационная технология,
зависит от её технической (автоматизированный, ручной или удаленный)
оснащенности, которая, по сути, влияет на сбор / обработку / передачу единиц
информации.
В комплекс технических средств входят:
а) компьютеры;
46
б) устройства, накапливающие, обрабатывающие, передающие и выводящие
информацию – винчестеры, устройства хранения данных, принтеры, сканеры;
в) устройства передачи данных и линий связи – модемы;
г) эксплуатационные материалы – CD- и DVD- диски,флеш-носители,
бумагаи проч.
При выборе ПК следует руководствоваться рядом характеристик. К таким
характеристикам относят производительность (на него влияет тактовая частота
процессора,объем оперативной памяти), надежность, расходы на покупку, простоту
использования и проч. (например, разрешение монитора)От значения данных
параметров зависит возможность работы в требуемых программных средах, а
значити успех создания системы.
После анализа уже имеющихся в Центре АРМов можно сделать заключение,
что они по всем, предъявленным к ним требованиям,подходят.
Для печати, сканирования и копирования документов должно
наличествовать соответствующее оборудование. Для обеспечения сохранности
данных во время ремонтных работ или аварийного отключения электропитания ПК
должен быть оборудован источником бесперебойного питания.
Поскольку рабочие места пользователей, как правило, оборудованы и
многофункциональными устройствами, и устройствами бесперебойного питания,
поэтому внедрение проектируемой нами системы не требует дозакупки и
установки какой-либо дополнительной техники.
47
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1.Этапы жизненного цикла проекта автоматизации
«Жизненный цикл»- это одно из базовых понятий методологии разработки
информационной системы. Жизненный цикл ИС являет собой непрерывный
процесс, которые начинается с момента принятия решения о создании ИС и
заканчивается в момент её полного изъятия из эксплуатации[1].
Жизненный цикл (далее – ЖЦ) ИС охватывает все этапы и стадии ее
создания, сопровождения и развития:
- исследование предметной области с дальнейшим формированием
информационной и функциональной моделей объекта, для которого
ИСпредназначена;
- проектирование системы (разработка проектных решений,
удовлетворяющих требованиям ТЗ);
- разработку системы (в т.ч. программирование и дальнейшее тестирование
прикладного ПО на основании проектных спецификаций подсистем, выбранных на
стадии проектирования);
- тестирование ИС, а также выявление, анализ и устранениеошибок;
- эксплуатацию и сопровождение ИС;
- развитие системы.
Жизненный цикл протекает в соответствии с его выбранной моделью.
Существует множество стандартов, регламентирующих жизненный цикл
ПО, а в отдельных случаях – и процессы разработки.
Из самых популярных стандартов можно выделить такие:
1) ГОСТ 34.601-90 (стандарт на автоматизированные системы –
устанавливает этапы и стадии их создания; в стандарте также имеется описание
содержания работ, которые нужно проводить на каждом отдельном этапе; этапы и
стадии работы, закрепленные в стандарте, соответствуют в большей степени
каскадной модели жизненного цикла).
48
2) ISO/IEC 12207:1995 (стандарт на организацию и процессы и жизненного
цикла; не содержит описания фаз, стадий, этапов и распространяется на все виды
программного обеспечениия, разрабатывающегося по чьему-либо заказу)[10]
3) Методика Oracle, илиCustom Development Method (стандарт на разработку
прикладных ИС; это, по сути, технологический материал, который детализирован
до уровня заготовок проектных документов для использования в проектах с
применением Oracle; CDM используется как для классической модели жизненного
цикла [предусмотрены все этапы, задачи, работы], так и для технологий Fast Track
["быстрой разработки"] или "облегченного подхода" – для малых проектов).
4) RUP, или Rational Unified Process (стандарт основывается на итеративной
модели разработки, включающей в себя четыре фазы: начало, исследование,
построение и внедрение – на базе UML; каждая из фаз может разбиваться на этапы
(или итерации), в результате которых создается версия для внутреннего / внешнего
использования; прохождение через ключевые фазы именуется циклом разработки,
а каждый цикл заканчивается генерацией новой версии системы; если работа над
проектом не завершается после прохождения указанных фаз, то полученный
продукт должен продолжать своё развитие и пройти заново все фазы).
5) MSF, или Microsoft Solution Framework (стандарт, как и RUP, на
итеративной модели и включает четыре основные фазы: анализ, проектирование,
разработку, стабилизацию; в отличии от RUP, MSFбольше ориентирована на
разработку бизнес-приложений)[13].
6) XP, или Extreme Programming («экстремальное программирование»; в
основе методологии данного стандарта лежит командная работа, эффективное
взаимодействие между исполнителем изаказчиком в течение всего периода
разработки ИС, а сама разработка ведется при помощи последовательно
дорабатываемых прототипов).
В стандарте ISO/IEC 12207 отсутствует конкретная модель жизненного
цикла и методы разработки, его рекомендации – это общие рекомендации для
любых моделей жизненного цикла. Под моделью, как правило, подразумевается
структура, которая на протяжении жизненного цикла определяет
последовательность выполнения и взаимосвязи действий,процессов и задач.
49
Сегодня существует две распространенные модели жизненного цикла –
спиральная и каскадная.
Согласно спиральной модели, разработка ПО проходит по нарастающей. На
первом этапе разрабатывается система с высоким уровнем абстракции, а в
дальнейшем эта разработка начинает четче и четче конкретизируется.
Согласно иной – каскадной – модели, процесс разработки проходит шаг за
шагом,поэтапно. Переход к новому этапу происходит только если завершается
предыдущий этап.
Для жизненного цикла нашего проекта была выбрана именно каскадная
модель, т.к. для создаваемой ИС более подходит поэтапная разработка. Переход к
новому этапу происходит только после завершения всех разработок на более
раннем этапе, в т.ч. и подготовку полного пакета документов, достаточных для
того, чтобы разработка могла быть продолжена следующей группой разработчиков.
Кроме того, в выбранной модели есть возможность планирования сроков
окончания работ, а также расходов на их выполнение.
Анализ
Проектирование
Реализация
Внедрение
Сопровождение
На данном этапе проводится исследование
обозначенной проблемы, формулируются требования
заказчика; результат – согласованное всеми сторонами
техническое задание
Разработка проектных решений,
удовлетворяющих всем
требованиями, заявленным в ТЗ;
результат – комплект проектной
документации.
Разработка ПО в соответствии
с проектными решениями;
результат – готовый
программный продукт.
Проверка ПО на предмет
соответствия требованиям,
заявленным в ТЗ; опытная
эксплуатация, позволяющая выявить
разные скрытые недостатки системы.
Сдача готового проекта,
ввод его в эксплуатацию.
Рисунок 9. Каскадная модель разработки ПО в теории
Каскадная модель лучше всего подходит для построения ИС, в
которыхсначала можно достаточно полно и точно сформулировать все требования
для того, чтобы разработчикам предоставить полную свободу их реализации с
50
технической точки зрения. Но если в середине разработки обнаружатся изначально
допущенные ошибки, то придется использовать энтраверсию проекта, и тогда
реальная схема каскадной модели приобретает другой вид (см. Рис. 10).
Получается, что каскадная модель больше всего подходит к реальной, конкретной
разработке.
Анализ
Проектирование
Реализация
Внедрение
Сопровождение
Рисунок 10. Реальный процесс разработки ПО в соответствии с
каскадной моделью
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Уже при разработке проектной концепции может возникнуть риск
недальновидного анализа бюджета и сроков реализации проекта. Для ликвидации
данного риска необходимо более глубоко прорабатывать цели и задачи проекта,
ставить больше количество контрольных точек.
Неверно подобранный состав исполнителей проекта может привести к
полному отсутствию командной работы. Такого рода риск уменьшается более
качественным подбором в проектную группу специалистов, протестированных как
по своим профессиональным навыкам, так и личностным(психологическим)
качествам.
При планировании может возникнуть риск неправильной/ некорректно
сформированной архитектуры выбираемого решения. Возможность появления
такого риска зависит от компетентности руководителя проекта. На руководителе
лежит ответственность за принятие решения о выборе архитектуры
разрабатываемого решения.
51
Во время разработки возможен риск неправильного понимания технического
задания, а, следовательно, и неправильное программирование архитектуры, сдвиг
сроков. Для того, чтобы уменьшить риск подобного рода, нужно более чёткое и
ясное для программиста написание технического задания.
Также одним из рисков данного проекта является отсутствие необходимой
квалификации у программиста в том языке программирования, на котором
требуется реализовывать программу. Если программист не будет укладываться в
заданные ему временные рамки календарного плана проекта, тогда нужно будет
использовать внешнего разработчика. Это называется «аутсорсинг», или
«фриланс».
При тестировании может возникнуть риск неоконченного тестирования. Это
такая ситуация, когда программный продукт будет протестирован не до конца.
Устраняется путем повторного тестирования на следующей итерации разработки.
При внедрении может возникнуть риск неправильного принятия решения об
окончании части проекта.Возникновение такого рода рискатянет за собой
проблему незаконченности решения и возможность возникновения разногласий с
другими частями разрабатываемой ИС. Устраняется путем доработки при
следующей итерации.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер защиты информации в любой ИС включает в себя такие
аспекты, как:
- защиту от внутренних угроз;
- защиту от внешних угроз[8].
Для защиты от внутренних угроз в нашей системе применяется политика
разделения прав доступа. Характеристика политики приведена в таблице 3 (см.
ниже).
Также каждому новому пользователю присваивается свой логин и пароль
для входа в систему.
Введен пароль на базу данных.