44
2 ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации обработки заявок
отделом техподдержки ЦКБ ГА
2.1.1 Этапы жизненного цикла проекта автоматизации
обработки заявок отделом техподдержки ЦКБ ГА
Модель жизненного цикла отражает различные состояния системы,
начиная от первой потребности в ПО и заканчивая датой его полного выхода из
употребления. Модель жизненного цикла программного средства представляет
собой структуру, которая содержит процессы, действия и задачи, что могут
осуществляться в ходе разработки, функционирования и сопровождения
программного средства на протяжении всей жизни системы, от определения
требований до завершения ее использования [7].
В учебном пособии Орлова С. А. «Технологии разработки программного
обеспечения»
были выделены следующие этапы жизненного цикла ИС [23]:
планирование и анализ – определяет, что должна выполнять ИС;
проектирование – определяет как будет функционировать система;
разработка - создание функциональных компонентов и отдельных
подсистем, соединение подсистем в единое целое;
тестирование - проверка функционального и параметрического
соответствия системы показателям, определенным на этапе анализа;
внедрение - установка и ввод в эксплуатацию информационной
системы;
техническое обслуживание - обеспечение нормального процесса
работы системы на предприятии заказчика.
В вышеуказанном учебном пособии сказано, что состав требований и
выбранная модель процесса, опыта проектировщика влияют на зависимость хода
процесса проектирования и его результаты. Наиболее распространенными
моделями ЖЦ являются:
каскадная модель;
поэтапная итерационная модель;
45
спиральная модель.
«Водоворот» или каскадная модель с промежуточным контролем.
В этой модели жизненного цикла промежуточный контроль
обеспечивается за счет обратной связи. Но это достоинство создает недостатки.
Стоимость проекта при таком подходе увеличивается почти в 10 раз.
Рисунок 2.1 – «Водоворот» или каскадная модель с промежуточным контролем
Обычно проблемы возникают, когда ошибки сделаны на ранних стадиях.
Это может быть связано с изменениями требований, сменой подрядчиков,
изменениями в политических и производственных аспектах, изменениями в
отраслевых стандартах, появлением конкурирующих продуктов и т. д. Это и
заставляет возвращаться и дорабатывать программное обеспечение под
изменившиеся требования.
Итерационные или инкрементальные модели (известно несколько таких
моделей) предполагают, что системы могут быть созданы с различными
последовательностями проходов для всех их заданий или их частей.
Каскадная модель с возможностью возврата к предыдущему шагу, если
необходимо пересмотреть ее результаты, становится итерационной.
Итерационный процесс предполагает, что различные действия не тесно
связаны с конкретными этапами разработки, а выполняются по мере
необходимости, иногда повторяются, пока не будет получен желаемый результат
(рисунок 2.2).
46
Рисунок 2.2 – Итерационная модель
Вместе с гибкостью и способностью быстро реагировать на изменения,
итерационные модели создают дополнительные трудности в управлении
проектом и отслеживании его прогресса. При использовании итеративного
подхода становится намного сложнее адекватно оценивать текущее состояние
проекта и планировать долгосрочное развитие событий, а также прогнозировать
время и ресурсы, необходимые для обеспечения определенного качества
результатов.
Спиральная модель жизненного цикла программного обеспечения
прекрасно сочетает в себе пошаговое прототипирование и дизайн. И из
восходящих и нисходящих понятий все лучшее было взято в эту модель.
Рисунок 2.3 – Спиральная модель
47
Преимущества модели:
˗ Результат достигается в кратчайшие сроки.
˗ Конкурентоспособность довольно высокая.
˗ При изменении требований не нужно начинать с нуля.
Но у этой модели есть один существенный недостаток: невозможность
регулирования этапов реализации.
Для разработки программного обеспечения в данной работе была выбрана
итеративная модель жизненного цикла или так называемая пошаговая модель с
промежуточным управлением [30].
Ключом к успешному использованию жизненного цикла итеративной
разработки программного обеспечения является тщательная проверка
требований и каждой версии программного обеспечения на соответствие этим
требованиям в каждом цикле модели [32].
Итеративная модель зарекомендовала себя при построении
информационных систем, для которых в самом начале разработки можно
сформулировать все требования достаточно точно и полностью, чтобы дать
разработчикам свободу их реализации с максимальной технической
эффективностью.
Использование итеративной модели оправдано в этой работе, так как
требования к системе и их реализации максимально четко определены и
понятны.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Риски любого ИТ-проекта можно классифицировать следующим образом
[33]:
Технические риски. Практически в любом ИТ-проекте есть риски,
связанные с оборудованием (поломка и неисправность оборудования, ошибки
при установке и т. д.).
Сроки оценки рисков. Большинство ИТ-проектов (особенно в проектах
разработки и внедрения программного обеспечения) характеризуются ошибками
в оценках сроков проекта.
48
Интеграционные риски. Риски интеграции в ИТ-проектах, особенно в
крупных компаниях, всегда высоки, поскольку любое ИТ-решение должно быть
интегрировано в существующую инфраструктуру.
Риски, связанные с неприятием проекта продукта пользователями. Любой
проект, в т.ч. в сфере IT - это, прежде всего, изменение технологии работы.
Техническая составляющая любого проекта, безусловно, важна, но
организационная часть также важна.
Коммерческие риски. Это риски, связанные с выбором технологии и
поставщика. Необходимо оценить успех технологии на рынке, ее актуальность
на протяжении всего жизненного цикла ИТ-проекта, наличие необходимого
оборудования и программного обеспечения, его качество и периодичность
модернизации.
Риски несоблюдения технологии. Эти риски возникают в том случае, если
руководитель проекта принимает решение самостоятельно (идентификация,
анализ, выбор метода реагирования). Чем крупнее и сложнее проект, тем выше
риск.
Таблица 2.1
Факторы риска
Тип
(категория
риска)
Риск
Последствия
Меры по
предотвращению
Вероят-
ность
сверше-
ния риска
[P]
Сте-
пень
ущерб
а [L]
Влияние
(фактор
риска)
[R] = [P] x
[L]
Проектный
(технологи-
ческий)
Интерфейс
разработан
без учета
юзабилити,
слабый
дизайн и
оформление
Минимум
функциональности,
нет заинтересован-
ности пользовате-лей
в использовании ПО
Заказать разработку
программного
обеспечения (ПО)
профессионалам,
оплатить ПО для
разработки
8
8
64
Технологи-
ческий риск
(связанный
с персона-
лом)
Недостаточн
ый
профессио-
нализм
сотрудни-
ков, боязнь
нововведени
й
Нет повышения
производитель-ности,
нежелание обучения
работе с новым ПО
Тщательный
рекрутинг
сотрудников,
своевременное
повышение их
квалификации и
обучение работе с
ПО
6
5
30
49
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации ЦКБ ГА
Создание системы информационной безопасности на предприятии,
которое обрабатывает информацию, так или иначе связано с вопросами
конфиденциальности, которые должны быть приведены в соответствие с
действующим законодательством и соответствовать требованиям норм и правил
в области информационной безопасности.
Среди основных документов по защите информации, в первую очередь,
Конституция Российской Федерации [1]. В ст. 23 устанавливается право на
неприкосновенность частной жизни, личную и семейную тайну, тайну
телефонных переговоров, почтовых и других сообщений. В этом случае
ограничение этого права допускается только на основании судебного решения.
Конституция Российской Федерации не допускается сбор, хранение,
использование и распространение информации о частной жизни лица без его
согласия.
27 июля 2006 Президент России подписал два важных для сферы
управления делопроизводством федеральных закона: № 149 - ФЗ «Об
информации, информационных технологиях и о защите информации» и № 152 -
ФЗ «О персональных данных».
10 января 2002 года Президент подписал закон «Об электронной
цифровой подписи», разрабатывающий и детализирующий положения
указанного выше закона № 149.
Основные законы Российской Федерации, также «О государственной
тайне» от 22 июля 2004; «О коммерческой тайне» от 29 июля 2004 года (он
содержит информацию, которая является коммерческой тайной, коммерческую
тайну, разглашение сведений, составляющих коммерческую тайну); «Об
утверждении перечня сведений, которые не могут быть коммерческой тайной»,
«Об утверждении перечня конфиденциальной информации», «Об утверждении
перечня сведений, составляющих государственную тайну». Ряд подзаконных
нормативных актов регулируют организацию защиты государственной тайны,
ведение секретного делопроизводства, порядок допуска к государственной тайне
50
должностных лиц и граждан Российской Федерации: «Об утверждении
Положения о лицензировании деятельности по технической защите
конфиденциальной информации» и т. д.
Ряд вопросов, связанных с защитой конфиденциальной информации,
регулируется Уголовно-процессуального кодексом, он содержит положения,
касающиеся тайны переписки, телефонных и иных переговоров, почтовых,
телефонных и иных сообщений [6].
Нормы, регулирующие отношения, возникающие при работе с
конфиденциальной информацией, также содержатся в Гражданском кодексе.
Критерии, по которым информация является конфиденциальной и коммерческой
тайной, содержатся в ст.139 Гражданского кодекса. В нем говорится, что
информация является служебной или коммерческой тайной в случае, когда:
˗ Эта информация имеет действительную или потенциальную ценность в
силу неизвестности ее третьим лицам.
˗ Эта информация не является свободно доступной на законном основании
и обладатель принимает меры по охране ее конфиденциальности.
Кроме того, определение коммерческой тайны, содержащиеся в ст.727
Гражданского кодекса.
Уголовный кодекс содержит ряд положений, касающихся защиты
информации с ограниченным доступом и ответственности за ее неправильное
использование.
Особый вид ответственности установлен за нарушение коммерческой
тайны: лишение соответствующей сертификации, лицензии уполномоченным
органом. Но привлечение к этому типу ответственности, как правило, не
получило к настоящему времени широкого распространения [6].
Правовые нормы, регулирующие использование конфиденциальной
информации в судебных процессах - Эти нормы, в частности, установить в
Гражданско-процессуального кодекса Российской Федерации.
Основные требования к обращению с конфиденциальной информацией в
государственных и коммерческих структурах также содержатся в Федеральном
законе «О противодействии легализации (отмыванию) доходов, полученных
преступным путем, и финансированию терроризма».
51
Законодательные акты не в полной мере регулируют порядок учета,
хранения и использования документов, содержащих конфиденциальную
информацию. Тем не менее, некоторые законы содержат определенные
положения, которые определяют общие принципы учета, хранения и
использования документов, содержащих конфиденциальную информацию.
Система безопасности информации основана на международном
стандарте для информационной безопасности ISO 17799 ( «Правила и нормы при
обеспечении безопасности информации»). ISO 17799 содержит общие
рекомендации по организации информационной безопасности, обеспечивая
базовый уровень безопасности информационных систем, типичных для
большинства организаций.
Таким образом, весь комплекс вопросов, которые возникают при решении
организационно-правовой поддержки, может быть представлен в виде схемы,
показанной на рисунке 2.4.
Рисунок 2.4 – Обеспечение организационно-правовой защиты
информации
52
Средства программно-аппаратной реализации защищенности
информационных систем на предприятии:
- Antiviral Toolkit Pro;
- Doctor WEB;
- Aidstest;
- Integrity Anti-Spyware;
- корпоративные продукты Safe’n’Sec;
- программное средство DeviceLock;
- Outpost Security Suite/Firewall 7.0.4 (3403.520.1244);
- BestCrypt для криптографической протекции информации;
- Online Security Audit.
Методы протекции информации и данных от большинства угроз
базируются на инженерных и технических мероприятиях. Инженерно-
техническая защита – это совокупность специальных органов, технических
методов и способов и мероприятий, функционирующих совместно для
выполнения определенной задачи по защите информации и данных предприятия.
Для инженерно-технической защиты используются такие средства:
˗ физические методы;
˗ аппаратные методы;
˗ программные методы;
˗ криптографические методы.
Физические средства включают в себя различные инженерные средства и
сооружения, препятствующие физическому проникновению злоумышленников
на объекты защиты и защищающие персонал (личные средства защищенности),
материальные средства и финансы, информацию от противоправных действий.
Способы и методы инженерно-технической реализации:
˗ сигнализация и телевидение (охранные);
˗ усиление конструкции дверей, стен, потолков, решеток на окнах;
˗ ведомственная охрана;
˗ устройство пожарной сигнализации;
˗ резервное копирование данных;
53
˗ устройство для протекции линий электропитания и заземления от
утечки информации «Соната-РС1»;
˗ система «Молния» для выжигания устройств для съема информации в
проводных линиях связи и в обесточенной электросети.
2.2 Информационное обеспечение задачи выполнения заявок
пользователей в отделе техподдержки
2.21. Информационная модель и ее описание
При разработке системы автоматизации процесса приёма заявок
пользователей необходима организация всех видов деятельности в отделе
технической поддержки. Эти виды деятельности образуют процессы,
составляющие основу для развития системы учета и контроля заявок
пользователей на ремонтные работы. Каждый из этих процессов на
определенном уровне автоматизации решает одну или несколько задач, такие
как разработка сервисов, управление инфраструктурой, предоставление и
поддержка услуг.
В данном случае разрабатывается недорогая универсальная
информационая система, не требующая титанических усилий по настройке на
специфику определенного учреждения, и не узко профилированный
программный продукт, пригодный для использования только в пределах одного
конкретного учреждения.
В создаваемом программном продукте можно будет произвести
тщательную настройку готовых модулей системы под нужды учреждения, а
также, при необходимости, изменить существующие или дописать новые
модули.
По всем вопросам, связанным с использованием системы, сотрудники
ЦКБ ГА должны будут обращаться только в отдел технической поддержки.
Причем, для них будет разработан порядок такого обращения. Если раньше
заявка на ремонтные работы техники от пользователя проходила сложную
цепочку инстанций, то теперь обращения пользователей за помощью
непосредственно в отдел технической поддержки с помощью разработанной
системы учета принятия заявок должны стать нормой. Но при этом пользователь