специалисты не должны привлекаться к прочим проектам и заданиям, их
рабочее время должно быть полностью посвящено разработке ИС.
- изменяющихся требований по ходу работы над проектом, которые
могут нарушить все сроки и оценки. Для снижения этих рисков необходимо
привлечение сотрудников склада на границах каждого этапа, чтобы
обнаруживать изменения на ранних стадиях работы над проектом системы.
- возникновения дефектов программного продукта вследствие
ошибок, допущенных на различных этапах разработки системы.
Классификация дефектов приведена в таблице 2.1.
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок Типы первичных дефектов и ошибок
программного средства и
документации
Разработка требований к ПО
Дефекты исходных требований
заказчика
Планирование работ
Дефекты, обусловленные реальной
сложностью проекта
Проектирование архитектуры системы Ошибки планирования и системного
проектирования программного
средства
Детальное проектирование ПО Системные и алгоритмические
дефекты и ошибки проекта
Кодирование ПО
Программные дефекты и ошибки
компонентов и документов
программного средства
Тестирование ПО
Программные и алгоритмические
ошибки программного средства и
документации
Разработка документации Дефекты и ошибки обобщающих
документов
64
Н а эт апе эксплуат ации возможны риски, возникающие по причинам:
1) Злоумышленных, активных воздействий заинтересованных лиц. Для
защиты от внешних угроз необходимо применять средства обеспечения
защиты программ и данных (аутентификация пользователей, защита
локальной сети при помощи межсетевых экранов, применение антивирусных
программ и пр.).
2) Случайных негативных проявлений внешней среды, дефектов
системы или ошибочных действий пользователей. Основными источниками
отказовых ситуаций могут быть некорректные исходные требования, сбои и
отказы в аппаратуре, дефекты или ошибки в программах и данных
функциональных задач, проявляющиеся при их исполнении в соответствии с
назначением. При таких воздействиях внешняя, функциональная
работоспособность систем может разрушаться не полностью, однако
невозможно полноценное выполнение заданных функций и требований к
качеству информации для потребителей.
Для снижения рисков, связанных с дефектами системы, необходимо
проводить тщательное тестирование на контрольных примерах,
приближенных к действительности. Для снижения рисков, связанных с
ошибочными действиями пользователей, необходимо предусмотреть защиту
от применения ошибочных действий по удалению и порче данных.
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Под информационной безопасностью (ИБ) АИС понимается состояние
защищенности информационной среды АИС, обеспечивающее её
формирование, использование и развитие, которое не приводит к искажению,
разрушению или несанкционированному использованию информационных
ресурсов, включая хранимую, обрабатываемую и передаваемую
информацию, а также программные средства. [2, с.147]
65
Выделяют следующие основные цели ИБ:
♦ конфиденциальность (доступность информации только
определенному кругу лиц);
♦ доступность (возможность получения информации авторизованными
пользователями в нужное для них время);
♦ целостность (гарантия существования информации в неискаженном,
истинном виде).
Информация, обрабатываемая и сохраняемая в, является ценной:
- технологическая - это наличие на складе товаров различных
категорий; их размещение, остаток, кому предназначаются. Эта информация
не является конфиденциальной, но в любой момент она должна быть
целостной и доступной, иначе работа склада остановится, и предприятие
понесет убытки.
- деловая - списки поставщиков, складские и бухгалтерские
документы. Эта информация должна быть конфиденциальной, доступной и
целостной.
Само функционирование системы также относится к ценным активам
компании, т.к. нарушение работы ИС приведет к потере доступа к ценной
информации. Поставки будут сорваны, рабочее время потеряно.
Определим, какие угрозы имеются с точки зрения информационной
безопасности [9]:
- внутренние угрозы (исходящие от так называемых «инсайдеров» -
сотрудников компании). Это может быть умышленная и непредумышленная
порча или удаление файлов с ценной информацией, ввод неверных данных, а
также незаконное копирование (хищение) информации;
- внешние угрозы: действия хакеров, промышленный шпионаж, вирусы
и т.п.;
- нарушение связи по вычислительной сети с офисом;
- отключения электропитания, пожары, наводнения и т.п.
2.2 Управление проектом автоматизации
66
2.2.1 Описание системы принятия управленческих решений
К общим признакам, отличающим проект от других видов
деятельности, относятся:
- направленность на достижение конкретных целей;
- координированное выполнение взаимосвязанных действий;
- ограниченная протяженность во времени, с определенным началом и
концом;
- неповторимость и уникальность (в определенной степени).
Следует отметить, что:
1. Современные методы ведения и управления бизнесом с
использованием экономических информационных систем типа CSRP
(Customer Synchronized Resource Planning) - синхронизированное с
покупателем внутреннее планирование и производство и ERP II (Enterprise
Resource and Relationship Processing) - управление внутренними ресурсами и
внешними связями предприятия позволяют осуществлять проекты в рамках
серийного производства.
2. Методики планирования ресурсов, используемые в проектах, имеют
общие корни с серийным производством, но существенно отличаются по
форме и содержанию. Это обусловлено однократностью и уникальностью
проектов.
Для такого сложного понятия как «проект» существует несколько
определений, в учебном пособии будет использоваться наиболее полно
отражающее содержание термина.
Проект - это ограниченное во времени целенаправленное изменение
отдельной системы с изначально четко определенными целями,
установленными требованиями к качеству результатов, срокам, риску,
рамкам расходуемых средств и ресурсов и специфической организацией.
Словосочетание «отдельной системы», включенное в определение,
указывает не только на целостность проекта и его разграниченность с
другими предприятиями, но и подчеркивает единственность проекта (в
67
отличие от серийного производства), а значит - его неповторимость и
признаки новизны (рис. 2.2).
Рисунок 2.2 - Схема проекта
Как объекта управления проект характеризуется следующими
признаками:
1. Изменчивость - целенаправленный перевод системы из
существующего в некое желательное состояние, описываемое в терминах
целей проекта.
2. Ограниченность конечной цели.
3. Ограниченность продолжительности, бюджета, ресурсов.
4. Новизна для предприятия, на котором реализуется проект.
5. Комплексность - наличие большого числа факторов, прямо или
косвенно влияющих на прогресс и результаты проекта.
6. Правовое и организационное обеспечение - создание специфической
организационной структуры на время реализации проекта.
С точки зрения теории управления, проект рассматривается как
динамический объект, а система управления проектом должна допускать
гибкую модификацию без глобальных изменений в программе выполнения
проекта. Следовательно, проект должен быть наблюдаем (выбирают
параметры и механизмы регулирования, по которым проект можно
контролировать и менять ход выполнения проекта) и управляем (выбранные
параметры и механизмы регулирования должны влиять на ход его
реализации).
В системном плане проект может быть представлен «черным ящиком»,
входом которого являются технические требования, необходимые ресурсы, в
том числе и финансовые, а выходом - достижение требуемого результата
выполнения проекта (рис. 2.3).
68
Технические гребован и я
Условия финансирования
Управлен не
Возмущаюшне
воздействия
Ресурсы
Рисунок 2.3 - Представление проекта в виде черного ящика
К важнейшим характеристикам проекта относятся технико
экономические показатели:
- объем работ;
- сроки выполнения;
- себестоимость;
- экономическая эффективность, обеспечиваемая реализацией проекта;
- социальная и общественная значимость проекта.
На основе характеристик проекта осуществляется: обоснование
целесообразности и осуществимости проекта, анализ хода его реализации,
заключительная оценка степени достижения поставленных целей проекта и
сравнение фактических результатов с запланированными требованиями.
Формирование команды проекта автоматизации
2.2.2 Формирование команды проекта автоматизации
Любой проект, будь то создание нового продукта или установка новой
информационной системы, тем или иным образом будет связан с различными
группами людей.
Прежде всего, это основная группа специалистов, выделенных для
выполнения проекта, т.е. команда проекта, осуществляющая работы по
проекту на протяжении всего жизненного цикла. В эту группу могут входить
еще и профессионалы, которые будут выполнять конкретные работы по
проекту в какое-то определенное время, т.е. приглашенные специалисты.
Во-вторых, в рамках организации существуют группы, которые прямо
или косвенно связаны с проектом. Это, прежде всего, высшее руководство,
69
которому подотчетен менеджер проекта. Это могут быть обеспечивающие
ресурсы функциональные менеджеры, которые отвечают за конкретные
направления проекта, сотрудники административных служб, финансовые
менеджеры и т. д.
В зависимости от характера проекта могут существовать внешние
факторы, влияющие на успех проекта; наиболее важным из них является
наличие заказчика, для которого был разработан проект.
Учитывая сложность современных ИТ-проектов, можно сказать, что
условием успеха проекта является тесное сотрудничество между заказчиком
и разработчиком. Сотрудничество должно происходить на всех фазах
жизненного цикла проекта.
Для реализации проекта, как со стороны заказчика, так и со стороны
разработчика должны быть созданы проектные команды, которые будут
тесно взаимодействовать друг с другом. Состав команд будет определяться
характером и масштабом проекта. Например, Р. Денис Гиббс предлагает
следующую структуру команд заказчика и разработчика (рисунок 2.4).
Руководитель проекта нужен во всех проектах. Обязанности
руководителя проекта в организациях заказчика и разработчика отличаются
друг от друга, но, тем не менее, сходство между ними состоит в том, что вся
их деятельность направлена на то, чтобы все члены расширенной команды
занимались нужными делами в нужное время.
Руководитель проекта определяет и распределяет множество задач по
проекту, делится своей концепцией и подходом к реализации проекта с
командой. Он тесно сотрудничает с командой, прилагает все усилия к тому,
чтобы у каждого члена команды были ресурсы, необходимые ему для
успешной работы.
Ведущий представитель пользователей со стороны заказчика выступает
в роли посредника между сообществом пользователей организации и
аналитиками организации разработчика. Задача этого человека - донести
70
нужды пользователей до аналитиков. Он работает в тесном взаимодействии с
аналитиком организации разработчика.
В свою очередь аналитик отвечает за перевод пожеланий
пользователей в конкретные требования, пригодные для реализации,
тестирования и документирования в процессе разработки.
Архитектор проекта обычно требуется, когда проект достаточно
большой и возникает необходимость в привлечении нескольких компаний
разработчиков, каждая из которых разрабатывает отдельную часть системы.
Организация
заказчик
Руководитель
проекта
Внутренний
лидер проекта
Руководитель
ИТ-подразделения
ft
?
Архитектор
проекта
Ведущий
представитель
пользователей
Специалист по заключению
контрактов
Технический
лидер группы
ft
Аналитик
требований
Управление
конфигурацией
Организация
разработчик
ft
Архитектор
ft
Разработчик
Тестировщик
Специалист по
инструментальным средствам
Рисунок 2.4 - Проектные команды
Архитектор команды разработчиков отвечает за разработку
архитектуры своей части системы. Эта роль важна, так как архитектор
определяет и разрабатывает основание всей будущей системы и неудачное
решение может привести к провалу проекта. Архитектура - это область
повышенного риска и последствия неудачи здесь очень значительны.
Реализация решений лежит на разработчике. Эта роль требует
соблюдения баланса между творческим подходом к решению задач и
соблюдением требований к проекту. Необходимо также приспосабливаться к
изменяющимся ситуациям, так как у заказчика могут меняться требования к
71
системе. Современные технологии создания ПО позволяют отслеживать эти
изменения за счет итеративного характера разработки.
Технический лидер - это самый опытный разработчик в команде. Он
направляет деятельность разработчиков, тестировщиков и аналитиков.
Технический лидер - это правая рука руководителя проекта.
Во всех проектах по разработке программного обеспечения команда
разработчиков использует множество различных инструментов, технологий и
процессов. Специалист по инструментальным средствам устанавливает и
настраивает инструментарий среды разработки и подготавливает его для
использования.
Руководитель ИТ-подразделения отвечает за поддержку и работу
продукта, разработанного в проекте, при его внедрении у заказчика, за
организацию рабочей среды, за обеспечение необходимыми аппаратными
средствами, за соблюдение стандартов безопасности.
Специалист по заключению контрактов работает со всеми контрактами
по проекту, в его компетенцию входит управление проектом с точки зрения
бизнеса.
В больших проектах, связанных со сложными бизнес - процессами,
аналитик группы разработчиков должен хорошо понять бизнес заказчика,
чтобы построить адекватную модель данных для разработки ПО. При этом
он тесно сотрудничает с членами команд заказчика и разработчика при
описании структуры организации, ее бизнес - процессов. На основе описания
бизнес - процессов определяются требования к разрабатываемой системе.
Процесс бизнес моделирования рассматривается как работа над
проектом по созданию ПО на начальной фазе проекта. Моделирование
бизнес - процессов включает их выявление и классификацию, уточнение
связей между бизнес - процессами, описание реализации бизнес - процессов,
определение ролей и их обязанностей внутри бизнес - процесса.
Различные методологии, используемые в сфере ИТ, предлагают свои
принципы формирования команды ИТ проекта и распределения ролей между
72
членами команды. Например, методология Microsoft Solutions Framework
(MSF) предлагает модель проектной группы, состоящую из шести ролевых
кластеров:
1. Управление продуктом (product management),
2. Управление программой (program management),
3. Разработка (development),
4. Тестирование (test),
5. Удовлетворение потребителя (user experience)
Таблица 2.3
Функции ролевых кластеров
Ролевой кластер Ф ункции
У правлен ие
продуктом
В ы ступает в роли представителя заказчи ка
Ф орм ирует общ ее ви дение/рамки проекта
О рганизует работу с требованиями заказчика
Разви вает сф еры прим енения в бизнесе
Ф орм ирует ож идания заказчика
О пределяет ком пром иссы меж ду парам етрам и «возм ож ности
продукта- время - ресурсы»
О рганизует маркетинг, PR
Разрабаты вает, поддерж и вает и исполняет план ком м уникаци й
У правление
программой
У правляет процессом разработки с целью получения готового
продукта в отведен ны е сроки
Ф ормулирует спецификацию продукта и разрабаты вает его
архи тектуру
Регулирует взаим оотн ош ения и ком м уникацию внутри п роектной
группы
С ледит за врем енны м граф иком проекта и готовит отчетность о его
состояни и
П ро води т в ж изнь важ ны е ком пром иссны е реш ения
Разрабаты вает, поддерж и вает и исполняет сводны й план и
календарны й граф ик проекта
О рганизует управление рисками
Разработка О пределяет детали ф изического дизай на
О ценивает необходи м ы е время и ресурсы на реали зацию каж дого
элем ен та дизайна
Разрабаты вает или контролирует разработку элем ентов
П одготавливает продукт к внедрению
К онсультирует команду по технологическим вопросам
Тестирование
О беспечивает обнаруж ение всех деф ектов
Разрабаты вает стратегию и планы тести ровани я
О сущ ествляет тестирование
У довлетворение
потребителя
П редставляет интересы потребителя в ком анде
О рганизует работу с требованиями пользователя
П роектирует и разрабаты вает систем ы поддерж ки
73