47
предоставляет доступ внешним приложениям к базе данных, обеспечивает ее
работу.
База данных проектируется и создается для каждого конкретного проекта,
СУБД же выбирается из небольшого списка стандартных средств.
В данной работе в качестве базы данных была выбрана СУБД Microsft
Access.
Ее достоинства.
1. очень простой графический интерфейс, который позволяет не только
создавать собственную базу данных, но и разрабатывать приложения,
используя встроенные средства,
2. хранит все данные в одном файле, хотя и распределяет их по разным
таблицам, как и положено реляционной СУБД. К этим данным относится не
только информация в таблицах, но и другие объекты базы данных.
1.4.3 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение - совокупность технических средств,
специализированных для работы информационной системы, а кроме того
надлежащая документация на эти средства и технологические процессы[3].
Совокупность технических средств составляют:
компьютеры;
устройства сбора, накопления, обработки, передачи и вывода
информации - жесткие диски, устройства хранения данных, сканеры, принтеры,
факсимильные аппараты;
устройства передачи данных и линий связи - модемы;
эксплуатационные материалы - бумага, CD (DVD) - диски и т.п.
В нашем случае главными компонентами технического обеспечения
будут:
автоматизированные рабочие места персонала организации
48
Сеть интернет и локальная вычислительная сеть, которая может
состоять из сетевых устройств (маршрутизаторов, коммутаторов и т.д.), и
соединяющего их кабеля.
В качестве АРМ необходимо использовать персональные компьютеры со
следующей минимальной конфигурацией:
Частота процессора 2,8 ГЦ и выше
Оперативная память объемом 2048 или выше
·Жесткий диск 200,0 Gb или выше.
Привод DVD.
Монитор 17" или выше
ИБП APC Back-CS500VA, аналогичный или лучше.
Такая конфигурация даст возможность реализовать работу в
разрабатываемом модуле с значительной степенью надежности. Кроме
указанных элементов еще необходима сетевая карта для возможности
подключения к локальной сети предприятия, но в данный момент найти
материнскую плату без встроенной сетевой картой очень сложно.
49
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла - структура, содержащая процессы, действия и
задачи, которые осуществляются в ходе разработки, функционирования и
сопровождения программного продукта в течение всей жизни системы, от
определения требований до завершения ее использования. Имеется несколько
моделей и стандартов, в какой-то степени регламентирующих жизненный цикл,
большая часть из них принадлежит заказному ПО (автоматизированным
системам АС, и др.) и помимо непосредственно ЖЦ регламентируют кроме
того и процессы разработки:
Custom Development Method (и, технология Oracle) по разработке
прикладных информационных систем под заказ – определенный материал,
конкретизированный вплоть до степени заготовок проектных документов,
предназначенных на применение в проектах с применением Oracle. Степень
адаптивности CDM ограничивается 3-мя моделями ЖЦ: "классическая"
(учтены все без исключения работы/задачи и этапы), "быстрая разработка"
(Fast Track), "упрощенный подход", предлагаемый в случае небольших
проектов и возможности ускоренно прототипировать приложения.
Rational Unified Process (RUP) предлагает итеративную модель
разработки, включающую четыре фазы: начало, исследование, построение и
внедрение. Прохождение через четыре ключевые фазы именуется циклом
разработки, при этом каждый цикл заканчивается генерацией версии системы.
Microsoft Solution Framework (MSF) аналогична с RUP, точно так же
содержит четыре фазы: исследование, проектирование, разработка,
стабилизация, является итерационной, подразумевает применение объектно-
ориентированного моделирования. MSF в сопоставлении с RUP в большей
части нацелена на разработку бизнес-приложений.
50
Extreme Programming (XP). Экстремальное программирование считается
наиболее новейшим из числа рассматриваемых методологий, сложилась в 1996
году. В основе методологии командная деятельность, результативная связь
между заказчиком и исполнителем на протяжении всего проекта по созданию
ИС, а создание проводится с использованием поочередно дорабатываемых
прототипов.
Главными аспектами для выбора стандарта ЖЦ будут:
актуальность и современность применяемых методов
контролирования разработки
разработка в итерационном режиме с возможностью осуществлять
контроль риски
и исполнения самого проекта на некоторых контрольных точках,
отсутствие добавочных требований по моделированию процесса разработки и
внедрения.
Резюмируя представление стандартов выше итерационными из них
считаются 4 стандарта: MSF, RUP, COBIT, XP .
Стандарт COBIT не подходит, потому что основной целью его
использования “является проведения аудита и стратегического планирования
ИС и IT инфраструктуры в целом”.
Стандарт XP тоже не подходит, так как он не содержит полноценных
этапов ЖЦ, таких как выработка концепции, планирование, разработка,
стабилизация, внедрение.
Таким образом, перед выбором стоит Rup и MSF. Эти два стандарта
считаются молодыми и поддерживающими всё новейшие технологии
продуктивной разработки и контролирования их исполнения.
Ключевые характерные особенности MSF, RUP и XP объединены в
таблицу 2.1. Согласно этой таблицы по ней возможно судить, что Rational
Unified Process считается хорошо сбалансированным решением для средних по
размерам коллективов разработчиков, работающих с применением продуктов и
технологий компании Rational.
51
Extreme Programming хорошо подойдет для проектных групп небольшого
размера и для малых систем с зачастую модифицируемыми требованиями.
Основная трудность XP - сопровождение. В случае текучки сотрудников в
коллективе разработчиков существенная доля проектных данных может быть
утрачена из-за почти отсутствующей документации. В таблице 2.1 показаны
ключевые характеристики Жизненного цикла ИС
Таблица 2.1
Технологии MSF, RUP и XP
Технология
Лучший
размер
команды
Соответствие
стандартам
Допустимые
технологии и
инструменты
Удобство
модификации и
сопровождения
Rational
Unified
Process
10 - 40 чел.
стандарты
Rational
UML и
продукты
Rational
Удобно (RUP)
Microsoft
Solutions
Framework
3 - 20 чел.
адаптируема
любые
Удобно
(MSF+MOF)
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно
(зависимость от
конкретных
участников
коллектива)
Microsoft Solutions Framework является наиболее сбалансированной
технологией, ориентированной на проектные группы малых и средних
размеров.
Разрабатываемая ИС считается небольшой. Помимо этого главным
преимуществом MSF считается итерационная модель одновременно с
уточняющими вехами (аналог каскадной модели). То есть, реализация MSF
предприняла попытку совместить каскадную и итерационную модель
разработки и внедрения ПО.
По описанным выше преимуществам, был выбран стандарт MSF как
наиболее гибкий и удобный для реализации ИС.
Этапы разработки АИС показаны в таблице 2.2
52
Таблица 2.2
Этапы разработки АИС
Этап проекта
Начало
Длитель
ность
Конец
Фаза выработки концепции
Изучение и анализ предметной области
07.02.2019
4
12.02.2019
Изучение и анализ области внедрения
13. 02.2019
4
18.02.2019
Фаза планирования
Составление технического задания
19. 02.2019
2
20.02.2019
Фаза разработки
Построение концептуальной модели ИС
21. 02.2019
2
22.02.2019
Описание входных и выходных данных
25.02.2019
4
28.02.2019
Разработка структур данных
01. 03.2019
2
04.03.2019
Разработка технического проекта
05. 03.2019
6
14.03.2019
Написание программ, модулей утилит
15. 03.2019
20
11.04.2019
Фаза стабилизации
Отладка
12. 04.2019
2
15.04.2019
Тестирование
16. 04.2019
4
19.04.2019
Разработка документации
19. 04.2019
2
22.04.2019
Фаза внедрения
Внедрение
23. 04.2019
4
26.04.2019
Итого
56
рабочих
дней
Проектная группа состоит из 1 человека.
Результатом фазы выработки концепции было следующее
Формулировка видения. Разработанная система ведения документации и
отчетности позволит НУЗ повысить эффективность учета посещения
пациентами поликлиники и анализа загруженности работы врачей.
Цели системы:
работать с врачами и пациентами;
выписывать талоны на посещение врачей.
Задачи системы:
работать с базой данных поликлиники;
выписывать талоны
В нашем случае на системы накладываются следующие ограничения:
система не является распределенной;
интерфейс системы представлен в одном окне;
система должна наглядно демонстрировать формы и способы
53
хранения и взаимодействия данных.
Функциональность решения
Хранилище находится в оперативной памяти
Добавление пациентов по нажатию кнопки
Проверка корректности введены данных
o Проверка существования пациента с введенным номером СНИЛС
Создание визуальной формы для отображения данных пациентов
Добавление талона
Проверка корректности введены данных
o Проверка существования талона с введенными данными
Добавление в визуальные формы талонов информации о
добавленных талонах
Удаление талонов
Удаление всех сопутствующих данных
Фаза планирования
Результатом данной фазы является техническое задание и план
разработки ПО, приведенный в таблице 2.2.
Фаза разработки
Результатом данной фазы явилась разработанная концептуальная модель
базы данных с указанием сущности и атрибутов каждой сущности. Приведены
входные и выходные документы. После этого разработано технический проект,
написана программа.
Фаза стабилизации
Во время фазы стабилизации было проведено тестирование
разработанного программного обеспечения. При этом тестирование
проводилось наиболее приближенно работе в поликлинике.
Во время этой фазы была разработана инструкция пользователя по работе
с программой. Проектная группа при этом занималась приоритезацией и
устранением ошибок программирования.
Фаза внедрения
54
Во время этой фазы необходимо будет установить и настроить MySQL на
предприятии.
При этом при эксплуатации пользователи работают с модулем, вводя
реальные данные, но при этом параллельно используется прежняя старая
система, в которой предприятия до этого времени осуществляла свою работу.
Этот этап необходим для того, чтобы можно было сопоставить результаты
работы в новой системе с результатами, которые получены были прежним
способом.
При внедрении будет использоваться стратегия «жесткого» внедрения.
Такая стратегия позволяет внедрить быстро и требуемый функционал,
чтобы получать нужные отчеты.
При таком подходе руководителю проекта внедрения нужно быть
готовым к следующим последствиям:
Пользователи будут жаловаться;
Обучение работе с программой займет больше времени, так как сразу
вводится весь функционал;
В единицу времени обращений пользователей по поводу работы
программы будет много. При этом необходимо их все обрабатывать,
иначе недовольство пользователей будет нарастать;
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
В фазе формирования концепции имеют все шансы возникнуть
последующие риски:
Недальновидный анализ сроков проекта и его бюджета
Для ликвидации подобного рода рисков необходимо более подробно
изучать задачи и цели проекта, установить больше контрольных точек.
Неправильно выбранный проектный состав исполнителей способен
спровоцировать полное отсутствие командной работы
55
Данный риск снижается более кропотливым выбором профессионалов в
проектную группу.
На фазе планирования возможно появление следующих рисков:
Неправильно либо не совсем верно сформирована структура
выбираемого решения
Возможность возникновения данного риска находится в зависимости от
компетенции управляющего проектом, на котором лежит принятие решение о
выборе архитектуры разрабатываемого решения
В фазе разработки вероятны последующие риски:
Неправильное понимание технического задания и равно как
результат некорректное программирование архитектуры и сдвиг сроков .
Минимизацией этого риска является более точное написание
технического задания, понятного программисту
Еще одним важным риском в этом плане считается недостаток
должной квалификации у разработчика в том языке, на котором принято
решение реализовывать программу заказчика, которая будет распределять
заявки между инженерами.
В случае, если разработчик программного обеспечения не будет
укладываться в установленные временные рамки календарного плана проекта,
придеться привлекать внешнего разработчика, так называемый “аутсорсинг”
либо “фриланс”.
В фазе тестирования имеют все шансы появиться последующие риски:
Риски неоконченного тестирования.
Может случиться ситуация что программный продукт будет
протестирован не до конца.
Решается посредством проведения повторного тестирования на
следующей итерации разработки.
В фазе внедрения имеют все шансы возникнуть последующие риски:
Риски неверного принятия решения о законченности некой части
проекта.
56
Возникновение этих рисков приводит за собой проблему
незаконченности решения и вероятность возникновения нестыковок с иными
элементами разрабатываемой ИС. Устраняется это путем доделки при
последующей итерации.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Создание систем информационной безопасности в ИС основывается на
следующих принципах: системный подход, принцип непрерывного развития
системы, разделение и минимизация полномочий, обеспечение экономической
целесообразности.
В результате решения проблем безопасности информации
разрабатываемая ИС должна обладать следующими основными признаками:
Наличием информации различной степени конфиденциальности.
Иерархичностью полномочий субъектов доступа к компонентам
ИС.
Обязательным управлением потоками информации, как в
локальных сетях, так и при передаче по каналам связи на далекие расстояния.
Наличием механизма предотвращения несанкционированного
доступа.
Обязательной целостностью программного обеспечения и
информации.
В основу нормативно-правового обеспечения входят нормы и регламенты
деятельности компании, служб и средств, реализующих функции защиты
информации, различного рода методики, обеспечивающие деятельность
пользователей при выполнении своей работы в условиях жестких требований
соблюдения конфиденциальности.