47
1. процессор – Intel(R) Xeon® CPUE5-2690 0 @ 2.90 ГГц (4 ядра);
2. платформа - 32-х или 64-х разрядная;
3. оперативная память - не менее 10 Гб;
4. дисковая подсистема - не менее 750 Гб;
5. сетевой адаптер – 100/1000 Мбит.
Требования к техническим характеристикам ПК пользователей и ПК
администратора системы:
1. процессор – Intel Pentium Dual Core 2.8 ГГц;
2. объем оперативной памяти – 4 Гб;
3. дисковая подсистема – 500 Гб;
4. устройство чтения компакт-дисков (DVD-ROM);
5. сетевой адаптер – 100/1000 Мбит.
48
2 ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Под жизненным циклом (ЖЦ) программного обеспечения понимают период
от начала разработки нового программного средства до снятия его с эксплуатации
у потребителя.
Разработка системы разбивается на следующие этапы:
техническое задание (ТЗ);
эскизный проект (ЭП);
технический проект (ТП);
предварительное проектирование;
рабочий проект (РП);
внедрение.
При использовании CASE-технологии стадии «техническое задание»,
«эскизный проект» и «технический проект» объединяются в одну стадию
«предварительное проектирование».
Общая трудоемкость и длительность создания системы рассчитывается на
основе алгоритма разработки (см. таблица 2.1).
Таблица 2.1 - Алгоритм разработки системы
Источник
формирования ТЗ
Стадии разработки системы
а
б (выбранный
алгоритм)
в
Традиционные
стадии разработки
ПП
С использованием
CASE-технологии
Стадии при
объединении
технического и
рабочего проекта
ТЗ формируется
разработчиком
«Техническое
задание»;
«Эскизный
проект»;
«Техническое
задание»;
«Предварительное
проектирование»;
«Техническое
задание»;
«Эскизный
проект»;
49
«Технический
проект»;
«Рабочий проект»;
«Внедрение»;
«Рабочий проект»;
«Внедрение»;
«Технорабочий
проект»;
«Внедрение»;
Трудоемкость разработки системы зависит от степени новизны разработки,
сложности алгоритма её функционирования, объема используемой информации и
виде её обработки, уровня используемого алгоритмического языка
программирования.
По степени новизны разрабатываемый системы относится к группе «В»
(разработка программной продукции, имеющей аналоги). По степени сложности
алгоритма функционирования системы относится к 3-ей группе (программная
продукция, реализующая алгоритмы стандартных методов решения задач).
Модель жизненного цикла представляет собой структуру, состоящую из
процессов, действий и задач, которые реализуются при разработке,
функционировании и сопровождении программного продукта в продолжение всей
жизни системы, от установления требований до завершения ее применения.
Имеется ряд моделей и стандартов, в определенной мере направленных на
регламентирование жизненного цикла, многие из них принадлежат к заказному ПО
(автоматизированным системам АС, и др.) и помимо непосредственно ЖЦ
регламентируют также и процессы разработки:
1. ГОСТ 34.601-90 касается автоматизированных систем и определяет
стадии и этапы их создания. К тому же, стандарт содержит описание
содержания работ на всех этапах. Стадии и этапы работы, которые
закреплены в стандарте, в большей мере подходят под каскадную модель
жизненного цикла;
2. ISO/IEC 12207:1995 стандарт касается процессов и организации
жизненного цикла. Затрагивает все виды заказного ПО. В стандарте не
содержится описание фаз, стадий и этапов;
3. Custom Development Method (и, методика Oracle) по разработке
прикладных информационных систем под заказ – является конкретным
материалом, детализированным до уровня заготовок проектных
50
документов, которые рассчитаны на применение в проектах с
использованием Oracle. Степень адаптивности CDM ограничивают три
модели ЖЦ: "классическая" (предусматриваются все работы/задачи и
этапы), "быстрая разработка" (FastTrack), "облегченный подход", который
рекомендуется в малых проектах и при возможности быстрого
прототипирования приложения;
4. Rational Unified Process (RUP) предлагает итеративную модель
разработки, состоящую из четырех фаз: начала, исследования, построения
и внедрения. Каждую фазу можно разбить на этапы (итерации), в
результате которых происходит выпуск версии для внутреннего или
внешнего применения. Прохождение через четыре главные фазы
обозначают как цикл разработки, каждый цикл завершает генерация
версии системы. Если после этого работа над проектом не завершается, то
развитие полученного продукта продолжается, и он снова проходит те же
фазы. Суть работы в рамках RUP - это создавать и сопровождать модели,
а не бумажные документы, поэтому данный процесс привязан к
пользованию конкретными средствами моделирования (UML), а также
конкретной технологией проектирования и разработки (объектно-
ориентированный анализ, object-oriented analysis, OOA, объектно-
ориентированное программирование, object-oriented programming, OOP);
5. Microsoft Solution Framework (MSF) сходна с RUP, также состоит из
четырех фаз: анализа, проектирования, разработки, стабилизации,
считается итерационной, предполагает пользование объектно-
ориентированным моделированием. MSF, если сравнивать с RUP, в
большей мере ориентирована на разработку бизнес-приложений.
Основные критерии для выбора стандарта ЖЦ представлены:
1. актуальностью и современностью применяемых методик контроля
разработки;
2. разработкой в итерационном режиме с возможностью осуществлять
контроль рисков и выполнять сам проект на неких контрольных точках,
51
отсутствием дополнительных требований по моделированию процесса
разработки и внедрения.
Резюмируя описание стандартов выше, отметим, что итерационными из них
считаются 4 стандарта: MSF, RUP, COBIT, XP .
Стандарт COBIT не подходит, так как основная цель его применения – это
проведение аудита и стратегического планирования ИС и IT инфраструктуры в
целом.
Стандарт XP не подходит, поскольку в нем не содержатся полноценные
этапы ЖЦ, представленные выработкой концепции, планированием, разработкой,
стабилизацией, внедрением.
Соответственно, необходимо выбрать Rup или MSF. Оба стандарта молодые
и поддерживают все новые технологии продуктивной разработки и контроля их
выполнения.
Rational Unified Process представляет собой хорошо сбалансированное
решение для средних по размерам коллективов разработчиков, которые работают с
использованием продуктов и технологий компании Rational. Сопровождение
разработки системы и самой системы регламентирует методология RUP, но все же
эта технология весьма сильно ориентирована на внутрифирменные
инструментальные средства.
Extreme Programming хорошо подходит для проектных групп, имеющих
малый размер, и для небольших систем, в которых часто изменяются требования.
Ключевая проблема XP выражена сопровождением. Если имеет место
текучка кадров в коллективе разработчиков, то значительную часть проектной
информации можно потерять вследствие практически отсутствующей
документации.
Microsoft Solutions Framework представляет собой наиболее
сбалансированную технологию, ориентированную на проектные группы, имеющие
малые и средние размеры. MSF не накладывает никаких ограничений на
применяемый инструментарий и содержит довольно общие рекомендации. Однако,
этими рекомендациями можно воспользоваться, чтобы построить конкретный
процесс, соответствующий потребностям коллектива разработчиков. Помимо
52
этого, основное преимущество MSF представлено итерационной моделью
одновременно с уточняющими вехами (аналог каскадной модели). Итак, в
реализации MSF сделана попытка объединения каскадной и итерационной модели
разработки и внедрения ПО.
Исходя из описанных выше преимуществ, мы выбрали стандарт MSF как
самый гибкий и удобный для осуществления АИС.
Одно из преимуществ выбранного стандарта представлено возможностью
управления одновременно и проектом разработки приложения и внедрением
инфраструктуры.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Поскольку весь ЖЦ проекта разделён на этапы, каждый этап обладает
ролями, за которыми закреплены цели, которые следует достигнуть, и всё же на
каждой фазе имеются некоторые риски:
В фазе выработки концепции возможно возникновение следующих рисков:
1. недальновидный анализ сроков проекта и его бюджета. Чтобы
ликвидировать такой риск, необходимо более детально прорабатывать
задачи и цели проекта, устанавливать больше контрольных точек;
2. неправильно подобранный проектный состав исполнителей может
привести к полному отсутствию командной работы. Для уменьшения
данного риска более тщательно подбирают специалистов в проектную
группу, тестируя не только профессиональные навыки, но и личностные
качества.
На фазе планирования возможно возникновение следующих рисков:
1. неверно или не совсем корректно сформированная архитектура
выбираемого решения. На возможность возникновения данного риска
влияет компетенция руководителя проекта, который должен принять
решение о выборе архитектуры разрабатываемого решения.
В фазе разработки возможно возникновение следующих рисков:
1. неправильная интерпретация технического задания и как результат
неправильное программирование архитектуры и сдвиг сроков. Чтобы
53
минимизировать данный риск, нужно более чётко написать техническое
задание, понятное для программиста;
2. еще один немаловажный риск в этом проекте представлен отсутствием
необходимой квалификации у программиста в том языке, на котором
решено реализовывать программу, которая будет распределять заявки
между инженерами.
В случае, если программист не будет успевать в заданное время
календарного плана проекта, придется воспользоваться внешним разработчиком,
так называемым “аутсорсингом” или “фрилансом”.
В фазе тестирования возможно возникновение следующих рисков:
1. риски неоконченного тестирования. Возможна ситуация, когда
программный продукт будет протестирован не до конца. При этом
необходимо провести повторное тестирование на следующей итерации
разработки.
В фазе внедрения возможно возникновение следующих рисков:
1. риски неправильного принятия решения о законченности части проекта.
Данные риски приводят к проблеме незаконченности решения и
возможности появления нестыковок с другими частями разрабатываемой
ИС. Для устранения необходимо доработать при следующей итерации.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для данного комплекса задач имеется несколько вариантов осуществления
информационной безопасности.
Защита от внутренних угроз. Подразумевает, что разграничиваются права
пользователей ИС HP OpenView Service Desk. О подробных правах пользователей
говорится в таблице 2.2.
Таблица 2.2 - Разграничение прав пользователей
Группы
пользовате
Создан
ие
Возможно
сть
Возможно
сть
Работа с БД
54
лей
билета
просмотр
а всех
билетов
покупки
билета на
киносеанс
Администра
тор
Есть
Есть
Нет
Чтение/создание/удаление/редакт
ирование
Клиент
Нет
Нет
Есть
Чтение/создание
Защиту от внешних угроз реализуют следующие параметры [18]:
1. сервер не имеет установленных сторонних средств удаленного
администрирования, таких как Remote administrator/Dame Ware/Team
Viewer. Доступ организован через Remote desktop protocol, на нужный
сервер, в том числе и сервер приложений и СУБД. Вход производится
лишь по доменной авторизации согласно уровню доступа;
2. на предприятии пользуются всеми возможными методами защиты
информации, поскольку отсутствует уникальный один метод,
обеспечивающий полную информационную безопасность, а сочетание
всех методов способствует реализации максимальной информационной
безопасности.
Для работы с АИС имеется два вида ролей:
1. администратор;
2. клиент.
Каждая из ролей имеет свои права доступа к функционалу АИС.
Администратор имеет следующие права:
1. авторизация в системе;
2. редактирование/добавление/удаление пользователей системы;
3. редактирование/добавление/удаление билетов;
4. редактирование/добавление/удаление вспомогательных данных (сеансы,
кинозалы и т.д.);
5. редактирование/добавление/удаление заявок клиентов;
6. просмотр отчетности.
Клиент имеет следующие права:
55
1. авторизация в системе;
2. регистрация в системе;
3. просмотр киносеансов;
4. покупка билета (создание заявки);
5. редактирование личной информации.
Схематически разделение ролей представлено на рисунке 2.1.
Рисунок 2.1 – Система ролей системы
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель БД - это отражение предметной области, для
которой разрабатывается база данных, некая диаграмма с принятыми
обозначениями элементов.
Все объекты, обозначающие сущности, обозначаются в виде
прямоугольника. Атрибуты, характеризующие объект - в виде овала, а связи между
объектами - ромбами. Мощность связи обозначаются стрелками (в направлении,
где мощность равна многим - двойная стрелка, а со стороны, где она равна единице
- одинарная).
На рисунке 2.2 показана информационная модель предметной области.
56
Рисунок 2.2 – Информационная модель
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
Исходные данные разрабатываемой АИС представляют собой текстовую
информацию, которая будет заноситься в АИС через клавиатуру и храниться в БД.
Такими исходными данными может быть:
1. ФИО клиента;
2. данные заявки;
3. данные билетов;
4. контактные данные.
2.2.3 Характеристика результатной информации
Выходная информация, разумеется, будет формироваться на основании
текстовой информации, которая имеется в БД и представлять собой:
1. любой вид отчета (отчет по созданным заявкам, отчет по заявкам за
выбранный период);
2. количество созданных заявок клиентов.