55
и исполнения самого проекта на некоторых контрольных
точках, отсутствие добавочных требований по моделированию процесса
разработки и внедрения.
Резюмируя представление стандартов выше итерационными из них
считаются 4 стандарта: MSF, RUP, COBIT, XP .
Стандарт COBIT не подходит, потому что основной целью его
использования “является проведения аудита и стратегического
планирования ИС и IT инфраструктуры в целом”.
Стандарт XP тоже не подходит, так как он не содержит полноценных
этапов ЖЦ, таких как выработка концепции, планирование, разработка,
стабилизация, внедрение.
Таким образом, перед выбором стоит Rup и MSF. Эти два стандарта
считаются молодыми и поддерживающими всё новейшие технологии
продуктивной разработки и контролирования их исполнения.
Ключевые характерные особенности MSF, RUP и XP объединены в
таблицу 2.1. Согласно этой таблицы по ней возможно судить, что Rational
Unified Process считается хорошо сбалансированным решением для
средних по размерам коллективов разработчиков, работающих с
применением продуктов и технологий компании Rational.
Extreme Programming хорошо подойдет для проектных групп
небольшого размера и для малых систем с зачастую модифицируемыми
требованиями. Основная трудность XP - сопровождение. В случае текучки
сотрудников в коллективе разработчиков существенная доля проектных
данных может быть утрачена из-за почти отсутствующей документации. В
таблице 2.1 показаны ключевые характеристики Жизненного цикла ИС
Таблица 2.1
Технологии MSF, RUP и XP
Технология
Лучший
размер
Соответствие
стандартам
Допустимые
технологии и
Удобство
модификации и
56
команды
инструменты
сопровождения
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
Таблица 2.2
Этапы разработки АИС
Этап проекта
Начало
Длительност
ь
Конец
Фаза выработки концепции
57
Изучение и анализ предметной области
07.02.201
9
4
12.02.201
9
Изучение и анализ области внедрения
13.
02.2019
4
18.02.201
9
Фаза планирования
Составление технического задания
19.
02.2019
2
20.02.201
9
Фаза разработки
Построение концептуальной модели ИС
21.
02.2019
2
22.02.201
9
Описание входных и выходных данных
25.02.201
9
4
28.02.201
9
Разработка структур данных
01.
03.2019
2
04.03.201
9
Разработка технического проекта
05.
03.2019
6
14.03.201
9
Написание программ, модулей утилит
15.
03.2019
20
11.04.201
9
Фаза стабилизации
Отладка
12.
04.2019
2
15.04.201
9
Тестирование
16.
04.2019
4
19.04.201
9
Разработка документации
19.
04.2019
2
22.04.201
9
Фаза внедрения
Внедрение
23.
04.2019
4
26.04.201
9
Итого
56
рабочих
58
дней
Проектная группа состоит из 1 человека.
Результатом фазы выработки концепции было следующее
Формулировка видения. Разработанная система учета проектов
повысит эффективность разработки и ведения документации проекта.
Разработанная АИС обеспечит ограниченный доступ к данной
докуменатции
Цели системы:
работать с документаций по проектам;
учет документации.
Задачи системы:
работать с базой данных предприятия;
хранить данные о проектах
В нашем случае на системы накладываются следующие ограничения:
система не является распределенной;
интерфейс системы представлен в одном окне;
система должна наглядно демонстрировать формы и способы
хранения и взаимодействия данных.
Функциональность решения
Хранилище находится в оперативной памяти
Добавление пациентов по нажатию кнопки
Проверка корректности введены данных
Проверка существования проекта с введенным названием
Создание визуальной формы для отображения данных проекта
Добавление проекта
Проверка корректности введены данных
Добавление в визуальные формы проектов информации о
добавленных проектах
59
Удаление проектов
Удаление всех сопутствующих данных
Фаза планирования
Результатом данной фазы является техническое задание и план
разработки ПО, приведенный в таблице 2.2.
Фаза разработки
Результатом данной фазы явилась разработанная концептуальная
модель базы данных с указанием сущности и атрибутов каждой сущности.
Приведены входные и выходные документы. После этого разработано
технический проект, написана программа.
Фаза стабилизации
Во время фазы стабилизации было проведено тестирование
разработанного программного обеспечения. При этом тестирование
проводилось наиболее приближенно работе предприятия.
Во время этой фазы была разработана инструкция пользователя по
работе с программой. Проектная группа при этом занималась
приоритезацией и устранением ошибок программирования.
Фаза внедрения
Во время этой фазы необходимо будет установить и настроить
MySQL на предприятии.
При этом при эксплуатации пользователи работают с АИС, вводя
реальные данные, но при этом параллельно используется прежняя старая
система, в которой предприятия до этого времени осуществляла свою
работу. Этот этап необходим для того, чтобы можно было сопоставить
результаты работы в новой системе с результатами, которые получены
были прежним способом.
При внедрении будет использоваться стратегия «жесткого»
внедрения.
Такая стратегия позволяет внедрить быстро и требуемый
функционал, чтобы получать нужные отчеты.
60
При таком подходе руководителю проекта внедрения нужно быть
готовым к следующим последствиям:
Пользователи будут жаловаться;
Обучение работе с программой займет больше времени, так как
сразу вводится весь функционал;
В единицу времени обращений пользователей по поводу
работы программы будет много. При этом необходимо их все
обрабатывать, иначе недовольство пользователей будет нарастать;
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
В фазе формирования концепции имеют все шансы возникнуть
последующие риски:
Недальновидный анализ сроков проекта и его бюджета
Для ликвидации подобного рода рисков необходимо более подробно
изучать задачи и цели проекта, установить больше контрольных точек.
Неправильно выбранный проектный состав исполнителей
способен спровоцировать полное отсутствие командной работы
Данный риск снижается более кропотливым выбором
профессионалов в проектную группу.
На фазе планирования возможно появление следующих рисков:
Неправильно либо не совсем верно сформирована структура
выбираемого решения
Возможность возникновения данного риска находится в зависимости
от компетенции управляющего проектом, на котором лежит принятие
решение о выборе архитектуры разрабатываемого решения
В фазе разработки вероятны последующие риски:
Неправильное понимание технического задания и равно как
результат некорректное программирование архитектуры и сдвиг сроков .
61
Минимизацией этого риска является более точное написание
технического задания, понятного программисту
Еще одним важным риском в этом плане считается недостаток
должной квалификации у разработчика в том языке, на котором принято
решение реализовывать программу заказчика, которая будет распределять
заявки между инженерами.
В случае, если разработчик программного обеспечения не будет
укладываться в установленные временные рамки календарного плана
проекта, придеться привлекать внешнего разработчика, так называемый
“аутсорсинг” либо “фриланс”.
В фазе тестирования имеют все шансы появиться последующие
риски:
Риски неоконченного тестирования.
Может случиться ситуация что программный продукт будет
протестирован не до конца.
Решается посредством проведения повторного тестирования на
следующей итерации разработки.
В фазе внедрения имеют все шансы возникнуть последующие риски:
Риски неверного принятия решения о законченности некой
части проекта.
Возникновение этих рисков приводит за собой проблему
незаконченности решения и вероятность возникновения нестыковок с
иными элементами разрабатываемой ИС. Устраняется это путем доделки
при последующей итерации.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Создание систем информационной безопасности в ИС основывается
на следующих принципах: системный подход, принцип непрерывного
62
развития системы, разделение и минимизация полномочий, обеспечение
экономической целесообразности.
В результате решения проблем безопасности информации
разрабатываемая ИС должна обладать следующими основными
признаками:
Наличием информации различной степени
конфиденциальности.
Иерархичностью полномочий субъектов доступа к
компонентам ИС.
Обязательным управлением потоками информации, как в
локальных сетях, так и при передаче по каналам связи на далекие
расстояния.
Наличием механизма предотвращения несанкционированного
доступа.
Обязательной целостностью программного обеспечения и
информации.
В основу нормативно-правового обеспечения входят нормы и
регламенты деятельности компании, служб и средств, реализующих
функции защиты информации, различного рода методики,
обеспечивающие деятельность пользователей при выполнении своей
работы в условиях жестких требований соблюдения конфиденциальности.
Любая информационная система потенциально подвержена угрозам
безопасности - кража данных или нарушение работы системы. Поэтому
разработчики ИС должны позаботиться о её безопасности.
Комплексная защита информации в сетях ЭВМ предполагает
реализацию четырех уровней защиты:
правовой (юридические нормы, законы; преследуется
незаконное использование секретных данных или информации,
составляющей объект авторского права)
63
административный/организационный (определяется, кто и
какую информацию может собирать и хранить; устанавливаются способы
доступа к ней и условия ее распространения, права и обязанности
работников, их компетенция и ответственность; должностные
инструкции).
аппаратно-программный (применяется процедура
идентификации пользователя, которая открывает доступ к данным и
программным средствам. Аппаратная защита может быть выполнена в
виде кодовой карточки, ключа и т.п.)
Описание разграничение прав пользователей приведено в таблице
2.3.
64
Таблица 2.3
Разграничение прав пользователей
Группы
пользоват
елей
Экранная
форма
"Должност
и"
Экранная
форма
"Сотрудни
ки"
Экранная
форма
"Врачебны
е
специальн
ости"
Экранная
форма
"Фирмы-
производи
тели"
Экранная
форма
"Вид
оборудова
ния"
Экранная
форма
"оборудов
ание"
Экранная
форма
«Проекты»
отчет
«Отчет
по
проект
»
Отчет
«Все
проект
ы
сотруд
ника
Админист
ратор
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просм
отр
Просмо
тр
Менеджер
Нет
доступа
Нет
доступа
Просмотр
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просмотр/
добавлени
е/
редактиро
вание/
удаление
Просм
отр
Просмо
тр
Регистрат
ор
Нет
доступа
Нет
доступа
Нет
доступа
Нет
доступа
Нет
доступа
Нет
доступа
Просмотр/
добавлени
е/
редактиро
вание
Просм
отр
Просмо
тр