Файл: Методические рекомендации по написанию магистерской диссертации для направления Прикладная информатика.doc

Наиболее оптимальным вариантом является:

• 
  выбор и обоснование одного из общеизвестных стандартов жизненного цикла ИС (ГОСТ 34, ISO 12207, ISO 15288, MSF, RUP, COBIT, Oracle CDM, XP);
  
• 
  краткое рассмотрение ключевых положений по каждому из этапов:
  
  • 
    цель этапа;
    
  • 
    ключевые участники;
    
  • 
    требования к входной информации;
    
  • 
    получаемые результаты.
    

Важно отметить, что данное описание должно относится непосредственно к автоматизируемой задаче, т.е. раскрывать последовательность разработки, внедрения и эксплуатации информационной системы, представленной к защите в рамках диссертации.

Для этапа внедрения обязательно:

• 
  выбрать и обосновать стратегию внедрения предлагаемого решения;
  
• 
  детально расписать все работы и их характеристики, которые планируется проводить на этапе внедрения разрабатываемого проектного решения в их логической последовательности;
  
• 
  описать роли участников процесса внедрения и их участие в каждой из работ.
  

Для этапа эксплуатации обязательно:

• 
  детально расписать все работы и их характеристики, которые необходимо производить на этапе эксплуатации разрабатываемого проектного решения в их логической последовательности;
  
• 
  описать роли участников процесса эксплуатации и их участие в каждой из работ.
  

Такое резюме по каждому из этапов должно дать возможность понимания заложенной логики построения проекта автоматизации и взаимосвязи выделяемых работ.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание

В разделе необходимо рассмотреть наиболее существенные риски проекта в разрезе их типов. Необходимо описать возможные риски вообще (применительно к каждому этапу ЖЦ ИС) и актуальные для разрабатываемого проекта в частности. Помимо краткого описаниях их сущности, необходимо описать те шаги, которые планируется предпринять для уменьшения величины каждого конкретного риска.

3. 
   Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации
   

В данном разделе необходимо дать полную и обоснованную характеристику проектируемым для решения задач средствам обеспечения ИБ и ЗИ. При этом необходимо отразить следующие аспекты.

---

1. Защита от внутренних угроз (разработка внутренней политики безопасности, разграничение прав доступа к информации и так далее). Для этого необходимо определить группы пользователей разрабатываемой системы и назначить им соответствующие права доступа к папкам и модулям системы, определить требования к паролям и частоте их смены, а также другие параметры использования ИС. Данные рекомендуется представить в форме таблиц. Пример такой обобщенной таблицы приведен ниже.
Разграничение прав пользователей.

Группы пользова-телей	Общая папка «Врачи»	Общая папка «Регистратор»	Модуль «Регистра-тура»	Модуль «Управле-ние»	Доступ в Internet
Врачи	Чтение/создание	Чтение	Чтение	Чтение	Нет
Главный врач	Чтение/создание/удаление	Чтение	Чтение	Полный	Ограничен
Регистраторы	Чтение	Чтение/создание	Полный	Нет	Нет
Старший регистратор	Чтение	Чтение/создание/ удаление	Полный	Чтение	Ограничен
Системный администратор	Чтение/создание/удаление	Чтение/создание/ удаление	Полный	Полный	Не ограничен

2. Защита от внешних угроз (безопасность каналов, протоколы, аутентификация, шифрование, безопасная пересылку ключей и т.д.).

Состав проектируемых программных и аппаратных средств может быть оформлен в виде таблицы с содержанием граф:

• 
  нормативно-правовые акты организации, стандарты (международные и отечественные);
  
• 
  антивирусные и антишпионские средства;
  
• 
  проактивная защита от внешних угроз и защита внешнего периметра;
  
• 
  защита от сетевых угроз;
  
• 
  защита от инсайдерских угроз и защита информационных ресурсов;
  
• 
  физическая защита информации.
  

---

3. Обоснование выбора политики безопасности, а также тех или иных программных и аппаратных средств, где должно быть:

• 
  обоснование организационно-правовым методам и программно-аппаратным средствам (средства должны быть конкретные, лицензионные, с требованиями соответствующих стандартов);
  
• 
  обоснование различным аспектам защиты системы: защита базы, резервное копирование, защита от хищения данных, защита от порчи данных, защита от инсайдерских угроз, уровни или сферы защиты (обоснование разрабатываемого решения на предмет уязвимостей, в том числе ошибки кода, ошибочные действия пользователя «защита от дурака»).
  

2.2 Управление проектом автоматизации

2.2.1 Описание системы принятия управленческих решений

Данный раздел включает в себя проведение сравнительного анализа существующих экономико-математических, управленческих методов и подходов к решению сформулированной задачии их использование с учетом специфики объекта исследования, анализ возможностей применения существующих методов для решения поставленной задачи. В данном разделе Вы рассматриваете инструментарий проектного управления и математических методов принятия решений, а также возможности и особенности его применения к объекту исследования.

Первым этапом предлагаемого раздела является идентификация и разработка альтернатив реализации проекта исследования. Далее проводится их количественная оценка согласно заданных критериев (определенность) или состояний окружающей среды (неопределенность). Поле постановки задачи осуществляется поиск оптимального решения одним из математических методов принятия решений (Метод свертывания критериев; критерий Вальда; принцип Сэвиджа; критерий Гурвица и др.).

Второй этап включает в себя применение моделей сетевого планирования и управления в рамках проекта исследования:

1. 
   Формулирование списка работ по проекту.
   
2. 
   Определение времени выполнения каждой из работ.
   
3. 
   Построение модели «Узел - работа» согласно запланированных работ по проекту исследования.
   
4. 
   Расчет критического пути по проекту исследования.
   
5. 
   Расчет полного (Total float) и свободного (Free float) резервов времени.
   
6. 
   Заполнение итоговой модели согласно полученного расчета.
   
7. 
   Резюме (выводы по расчету).
   

2.2.2 Формирование команды проекта автоматизации

---

Любой проект, будь то создание нового продукта или установка новой информационной системы, тем или иным образом будет связан с различными группами людей.

Прежде всего, это основная группа специалистов, выделенных для выполнения проекта, т.е. команда проекта, осуществляющая работы по проекту на протяжении всего жизненного цикла. В эту группу могут входить еще и профессионалы, которые будут выполнять конкретные работы по проекту в какое-то определенное время, т.е. приглашенные специалисты [3, С.27-35 ].

Во-вторых, в рамках организации существуют группы, которые прямо или косвенно связаны с проектом. Это, прежде всего, высшее руководство, которому подотчетен менеджер проекта. Это могут быть обеспечивающие ресурсы функциональные менеджеры, которые отвечают за конкретные направления проекта, сотрудники административных служб, финансовые менеджеры и т. д.

В зависимости от характера проекта могут существовать внешние факторы, влияющие на успех проекта; наиболее важным из них является наличие заказчика, для которого был разработан проект.

Учитывая сложность современных ИТ-проектов, можно сказать, что условием успеха проекта является тесное сотрудничество между заказчиком и разработчиком. Сотрудничество должно происходить на всех фазах жизненного цикла проекта.

Для реализации проекта, как со стороны заказчика, так и со стороны разработчика должны быть созданы проектные команды, которые будут тесно взаимодействовать друг с другом. Состав команд будет определяться характером и масштабом проекта. Например, Р. Денис Гиббс предлагает следующую структуру команд заказчика и разработчика (рис. 2).

Руководитель проекта нужен во всех проектах. Обязанности руководителя проекта в организациях заказчика и разработчика отличаются друг от друга, но, тем не менее, сходство между ними состоит в том, что вся их деятельность направлена на то, чтобы все члены расширенной команды занимались нужными делами в нужное время.

Руководитель проекта определяет и распределяет множество задач по проекту, делится своей концепцией и подходом к реализации проекта с командой. Он тесно сотрудничает с командой, прилагает все усилия к тому, чтобы у каждого члена команды были ресурсы, необходимые ему для успешной работы.

Ведущий представитель пользователей со стороны заказчика выступает в роли посредника между сообществом пользователей организации и аналитиками организации разработчика. Задача этого человека - донести нужды пользователей до аналитиков. Он работает в тесном взаимодействии с аналитиком организации разработчика [3, С.27-35 ].

---

В свою очередь аналитик отвечает за перевод пожеланий пользователей в конкретные требования, пригодные для реализации, тестирования и документирования в процессе разработки.

Архитектор проекта обычно требуется, когда проект достаточно большой и возникает необходимость в привлечении нескольких компаний разработчиков, каждая из которых разрабатывает отдельную часть системы.



Рисунок 2. Проектные команды [2, С. 60].

Архитектор команды разработчиков отвечает за разработку архитектуры своей части системы. Эта роль важна, так как архитектор определяет и разрабатывает основание всей будущей системы и неудачное решение может привести к провалу проекта. Архитектура – это область повышенного риска и последствия неудачи здесь очень значительны.

Реализация решений лежит на разработчике. Эта роль требует соблюдения баланса между творческим подходом к решению задач и соблюдением требований к проекту. Необходимо также приспосабливаться к изменяющимся ситуациям, так как у заказчика могут меняться требования к системе. Современные технологии создания ПО позволяют отслеживать эти изменения за счет итеративного характера разработки.

Технический лидер – это самый опытный разработчик в команде. Он направляет деятельность разработчиков, тестировщиков и аналитиков. Технический лидер – это правая рука руководителя проекта.

Во всех проектах по разработке программного обеспечения команда разработчиков использует множество различных инструментов, технологий и процессов. Специалист по инструментальным средствам устанавливает и настраивает инструментарий среды разработки и подготавливает его для использования.

Руководитель ИТ-подразделения отвечает за поддержку и работу продукта, разработанного в проекте, при его внедрении у заказчика, за организацию рабочей среды, за обеспечение необходимыми аппаратными средствами, за соблюдение стандартов безопасности.

Специалист по заключению контрактов работает со всеми контрактами по проекту, в его компетенцию входит управление проектом с точки зрения бизнеса.

В больших проектах, связанных со сложными бизнес - процессами, аналитик группы разработчиков должен хорошо понять бизнес заказчика, чтобы построить адекватную модель данных для разработки ПО. При этом он тесно сотрудничает с членами команд заказчика и разработчика при описании структуры организации, ее бизнес - процессов. На основе описания бизнес - процессов определяются требования к разрабатываемой системе.

---