Рисунок 14. Каскадная модель жизненного цикла
Именно каскадная модель была выполнена для реализации проекта в
данной работе.
Весь процесс разработки, в соответствии с данной моделью
разбивается на несколько этапов, переход от одного этапа к другому
происходит только после полного выполнения предыдущего этапа.
Это означает, что на каждом этапе формируется законченный набор
проектной документации, этого набора должно быть абсолютно достаточно
для передачи проекта другой группе разработчиков, функционирующих на
следующем этапе жизненного цикла по разработке информационной
системы. Так же одним из положительных моментов каскадной модели
является возможность планирования сроков завершения работ и затрат на их
выполнение. Как и у любой модели, у каскадной модели есть свой
недостаток. Он заключается в том, что сложно уложить реальный процесс
создания программного обеспечения в такую жесткую схему. В связи с этим
часто возникает потребность возврата на предыдущий этап, с целью
уточнения и пересмотра решений, принятых ранее.
Весь процесс разработки программного обеспечения начинается с
изучения предметной области. В случае разработки данного приложения
изучение ведется в направлении набора уже используемых программ на
предприятии для информационного обмена.
При данной модели разработки сначала осуществляется чертеж на
бумаге. Этот этап называется проектированием. Проектируется база данных,
а именно, наименование таблиц, наименование и структура полей таблиц,
связей между таблицами. Далее осуществляется чертеж эскиза форм и
прочих элементов интерфейса. Чертеж начинается с основной формы MDI и
ее меню. Далее, последовательно чертятся формы, информация в которых
отображается из справочных таблиц и формы, содержащие информацию из
учетных (оперативных) таблиц. Следующим этапом разработки является
проектирование дизайна в среде программирования, то есть построение
пользовательского интерфейса. Осуществляется в той же
последовательности. На данном этапе интерфейс пока еще не выполняет
своих функций.
При наступлении третьего этапа начинается "оживление"
пользовательского интерфейса посредством записи процедур и функций.
Последовательность разработке такая же, как при составлении эскизов.
Разрабатываются различные модули для осуществления рабочих функций
приложения. Тестируется каждый модуль на наличие возможных ошибок.
После кодирования созданное приложение необходимо
протестировать на наличие ошибок уже комплексно. Здесь следует
предусмотреть все нелепые операции, которые может осуществить
пользователь, который будет работать с данным программным обеспечением.
Далее следует этап внедрения. на этом этапе часто появляется много
ошибок, которые в следующих релизах приложения должны быть
исправлены.
После успешного прохождения теста, программе необходима
техническая поддержка в виде сопровождения по внесению определенных
изменений, которые будут происходить в регламенте организации.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Так как начальный процесс в построении системы является процесс
изучения предметной области, то становится очевидным, что для того, чтобы
начать проектировать базу данных, то есть перейти на следующий этап
проектирования, следует максимально разбираться в той предметной
области, в которой будет вестись разработка. Следует отметить, что для того,
чтобы обеспечить функциональность приложения, собирается целая команда
разработчиков, в которую входят не только программисты, но и другие
специалисты. Это, прежде всего специалисты той предметной области,
которую собираются программировать [10. стр.42]., поскольку программисты
не могут, например, разбираться так же хорошо в вопросах экономики, как
это делают экономисты. Применительно к системе автоматизации учета
заявок, следует хорошо себе представлять общую структуру организации,
процесс взаимодействия клиентов и технических специалистов, вопросы
организации учета заявок, следует знать, какие документы регулируют эти
вопросы. Таким образом, в организации представляются правила
документооборота. И первым специалистом в данной области, который
непосредственно занимается документооборотом в исследуемой предметной
области организации является технический специалист. Именно он
занимается процессом приема заявок. Поэтому для разработчика,
технический специалист предоставляет некий технический план разработки
для его дальнейшего использования специалистами по проектированию базы
данных. Основной риск здесь может заключаться в том, что технический
специалист может в техническом задании отметить не все функции, которые
он выполняет при традиционной работе. В этом случае программисты,
разрабатывающие структуру базы данных, могут вернуть техническому
специалисту проект на доработку (на предыдущий этап).
Уже после повторной доработки технического задания станет ясно,
достаточно ли данной информации для проектирования базы данных, либо
нет. В процессе возврата проекта на предыдущий этап нет ничего
необычного. Это процесс доработки. Именно так и должна проходить любая
разработка программного обеспечения. Процесс проектирования базы
данных сначала делается на обычном листе карандашом. Чертятся таблицы,
дается название полям, чертятся связи между таблицами по ключевым полям.
После успешного проектирования на бумаге начинается непосредственное
проектирования на выбранного для проекта СУБД. В данном случае был
выбран СУБД MySQL [14. стр. 91].
После проектирования базы данных наступает следующий этап
проектирование. Это процесс проектирования экранных форм. Начинается он
так же с бумажного проектирования. Для этого в команде разработчиков
присутствуют дизайнеры пользовательского интерфейса. Это специально
обученный люди, которые хорошо разбираются в психологии человека и
знают, как будет реагировать пользователь на те или иные действия
программы. Поэтому эти специалисты чертят эскизы форм, меню, кнопок и
так далее. В исследуемом проекте нет отдельных специалистов-дизайнеров,
поэтому дизайн пользовательского интерфейса выполняет программист,
который будет непосредственно разрабатывать приложение. Тем не менее,
сам процесс, все равно начинается с бумажного проектирования.
После бумажного проектирования разработка перетекает в
следующий процесс, называемый реализацией. Здесь физически создаются
нарисованные формы. После их создания они "оживляются", то есть, в
модулях форм и модулях данных пропиваются процедуры и функции на
выбранном для проекта языке программирования и среды
программирования. Происходит непосредственный этап разработки. Здесь
тоже могут возникнуть определенные риски, связанные с неудобством в
разработке функциональной части, поскольку спроектированный на
предыдущем этапе пользовательский интерфейс может оказаться крайне
неудобным при разработке функционала. В этом случае программист может
вернуть проект дизайнеру для доработки. В нашем случает программист
самостоятельно делает корректировки в дизайне форм и далее продолжает
писать программный код.
Следующий этап разработки называется внедрение. Внедрение
связано с официальным функционирование разработанного приложения на
предприятии. Очень часто такая разработка сопровождается с предыдущей
технологией, поэтому на сотрудников организации ложиться двойная работа.
Это делается потому что, есть риск того, что новая программа где-то может
дать ошибку, которая недопустима в регистрации и обработке заявок. Таким
образом, на этом этапе возникают именно психологические риски, когда
сотрудники, привыкшие каждый день выполнять одинаковую работу на
автомате, начинают использовать другую технологи. В этом время они
испытывают сильный стресс и даже не желание продолжать работать на
предприятии. В нашем исследовании такого психологического дискомфорта
не наступало.
Процесс внедрения можно охарактеризовать точным синонимом ‒
отладка. Это не что иное, как отладка в реально-рабочей обстановке. Именно
здесь могут возникать множественные ошибки самой программы, поскольку
поведение пользователя до конца не предсказуемо и трудно моделировать то,
что каждый из сотрудников может ввести в то или иное информационное
окно. Поэтому здесь, наиболее часто внедрение может откатываться обратно
к процессу реализации, то есть доработки программного кода на предмет
исключения из него ошибок выполнения. Далее, снова проект переходит на
стадию внедрения и процесс возврата и дальнейшей передачи
осуществляется до тех пор, пока ошибки в работе не исчезнут.
Лишь после этого наступает последний этап ‒ сопровождение.
Сопровождение связано, как правило, с изменениями в регламенте
организации и законодательстве.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Цель приложения заключается в создании так называемой электронной
очереди заявок на техническую поддержку. Никакой конфиденциальности
такая процедура не содержит, поэтому требования к информационной
безопасности сводятся лишь к резервному копированию базы данных на
сервер организации. А вот к серверу, как к аппаратной части уже
предъявляются определенные требования.
Прежде всего, следует отметить, что SQL-сервер и база данных должны
быть расположены на одном из серверов организации в серверной комнате,
доступ к которой должен осуществляться только администратором системы,
дверь в помещение должна быть надежно закрываться и опечатываться.
Одним из элементов надежности работы сервера является постоянная
температура помещения, в котором располагаются сервера. Она
соответствует приблизительно 19 градусам по Цельсии. Для выполнения
таких требований следует установить надежную сплит-систему в серверное
помещение, которая будет поддерживать на протяжении длительного
времени постоянную температуру помещения. Это обеспечит
отказоустойчивость сервера системы. Так же, в помещении следует
проводить регулярную влажную уборку.
Еще одним немаловажным фактором к обеспечению надежности
системы является организация создания резервных копий базы данных. Это
может осуществляться в ночной период времени, когда организация не
работает. Для автоматического создания резервный копий будет применять
приложения фирмы Acronis.
Требования к базе данных:
Разрабатываемая система будет иметь двухуровневую клиент-
серверную структуру, где на первом уровне будет база данных с
установленным на ней сервером SQL, а на втором ‒ приложение "Толстый"
клиент.
В базе данных должна поддерживаться целостность записей. Должно
быть организовано каскадное удаление и каскадное обновление на уровне
БД.
Идентификация пользователя должна осуществляться по логину и
паролю. В качестве антивирусной защиты в организации используется
антивирус Касперского.
2.2. Информационное обеспечение задачи
2.2.1. Характеристика нормативно-справочной, входной и оперативной
информации
Нормативно-справочная информация ‒ представляет собой
информацию, которая относится к виду условно-постоянной. Она
характеризуется более редким изменением данных.
В базе данных нормативно-справочная информация хранится в
справочных таблицах. Такие таблицы называются родительскими.
Оперативная информация – это вид часто меняющейся, "рабочей"
информации.
В базе данных tehsupportzerobit для хранения оперативной информации
предназначены таблицы. В таблице 4 приведен перечень справочных таблиц.
Таблица 4
Справочники базы данных tehsupportauto
Название справочника
Ответственный
за ведение
справочника
Средний
объем
справочника в
записях
Средняя
частота
актуализа
ции
otdel
Администратор
25
Раз в год
sotr
Администратор
125
1 раз в
месяц
Справочник "otdel" содержит следующие реквизиты:
kod_otdela. Автоинкрементное поле. Является первичным ключом.
name_otdela. Полное или краткое наименование организации /
отдела.
Несмотря на то, что таблица "sotr" является подчиненной по
отношению к таблице "otdel", тем не менее она является полноценным
справочником, поскольку ее информация является справочной для таблиц
"zaiavki" и "chat".
Справочник "sotr" имеет следующие реквизиты:
kod_otdela. Это поле является внешним ключом и предназначено для
связи с таблице otdel.
kod_sotr. Поле является первичным ключом и содержит код
сотрудника для связи с таблицами zaiavki и chat.
fio. ФИО сотрудника.
dolgnost. Должность сотрудника в отделе.
telefon. Городской телефонный номер с кодом города.
e-mail. Адрес электронной почты.
login. Логин сотрудника для авторизации в системе. Заводится
администратором системы.
password. Пароль сотрудника как пользователя в системе.
status_sotr. Статус пользователя. Либо администратор, либо
оператор, либо технический специалист Выбор жестко фиксирован
в программном коде.
Рассмотрим состав оперативной информации.
Для хранения и обработки оперативной информации в базе данных
tehsupport предназначены две таблицы "zaiavki" и "chat" В таблице " zaiavki"
создаются и хранятся все заявки на обслуживание. Реквизитный состав
следующий:
kod_sotr. Код сотрудника, который создает заявку.
kod_sotr_support. Код сотрудника, который закрывает заявку.
kod_zaiavki. Код заявки. Первичный ключ.
krat_name. Краткое наименование заявки.
opis. Подробное описание проблемы.
status. Статус заявки (Открыта, в работе, закрыта).
date_open. Дата создания заявки.
date_close. Дата закрытия заявки.
job. Описание работы, что было сделано. Заполняется техническим
специалистом, закрывающим заявку.