86
и спланировать организационные и технические мероприятия на этапе
промышленного внедрения. Пилотный проект позволяет уменьшить затраты и
ускорить полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана,
потому что это наиболее часто используемая компаниями стратегия. Такой
подход снижает риск и наиболее надежен.
Таким образом, каскадный метод более всего подходит к конкретной
разработке, следовательно, используем стандарт ISO/IEC 12207.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Данный раздел описывает риски, которые могут возникнуть на этапах ЖЦ
разработки интернет-магазина для ООО «ТС-авто». Риском является возможность
появления обстоятельств, обусловливающих неуверенность или невозможность
получения ожидаемых результатов от реализации поставленной цели, нанесение
материального ущерба, опасность валютных потерь и др. Существуют следующие
типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений и человеческим фактором, а именно риски,
связанные с неспособностью специалистов выполнить необходимую задачу.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски сокращения
бюджета, приводящие не только к сокращению проекта и его задач, но и к его
полному провалу в случае не достижения основной цели; риск потери интереса к
задаче ведения и учета внутренних заказов оборудования со стороны конечных
пользователей, риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать.
87
Различают две основные категории рисков – прямые и опосредованные. На
прямые риски проектная команда может каким-то образом повлиять, а
опосредованные риски команда контролировать не может в принципе.
Риски делятся на следующие основные виды:
Ресурсные риски:
Организация (выполняла ли организация прежде проекты такого
масштаба, существует ли формальный процесс разработки программного
обеспечения и т.п.);
Финансирование (полностью ли обеспечено финансирование
проекта, фиксирована ли стоимость проекта или она является предметом для
обсуждения, точно ли выполнена оценка затрат и т.п.);
Люди (достаточно ли людей для выполнения проекта, обладают ли
они необходимыми навыками и опытом, работали ли они вместе раньше и т.п.);
Время (реалистичен ли план проекта, насколько критичной является
дата окончания проекта и т.п.);
Бизнес (что произойдет, если конкурент выйдет на рынок первым,
выгода, полученная от реализации проекта больше, чем затраты на него, что
произойдет, если ключевые поставщики не смогут выполнить свои обязательства
и т.п.);
Технические риски:
Область действия (scope) проекта (могут ли быть измерены критерии
успешного завершения проекта, требования стабильны и хорошо поняты, область
действия жестко фиксирована или может расширяться в будущем и т.п.);
Технологии (отлажена ли применяемая технология или она только
была разработана, существуют ли необычные или инновационные технические
требования, с которыми проектная команда никогда раньше не сталкивалась и
т.п.);
Внешние зависимости (зависит ли проект от других параллельных
проектов, зависит ли успех проекта от внешних поставщиков технологий и/или
продуктов и т.п.).
88
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих
большой опыт работы в соответствующей области и при этом взаимозаменяемых
на сотрудников, не менее соответствующих данным характеристикам (таблица
2.1).
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок
Типы первичных
дефектов и ошибок
программного средства и
документации
Формирование требований
Разработка требований к
ПО
Дефекты исходных
требований заказчика
Проектирование
Планирование работ
Дефекты, обусловленные
реальной сложностью
проекта
Проектирование
архитектуры системы
Ошибки планирования и
системного
проектирования
программного средства
Детальное проектирование
ПО
Системные и
алгоритмические
дефекты и ошибки
проекта
Реализация
Кодирование ПО
Программные дефекты и
ошибки компонентов и
документов
программного средства
Тестирование
Тестирование ПО
Программные и
алгоритмические ошибки
программного средства и
документации
Ввод в действие
Разработка документации
Дефекты и ошибки
обобщающих документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
На этапе эксплуатации возможны риски, возникающие по причинам:
1) Злоумышленных, активных воздействий заинтересованных лиц. Для
защиты от внешних угроз необходимо применять средства обеспечения защиты
89
программ и данных (аутентификация пользователей, защита локальной сети при
помощи межсетевых экранов, применение антивирусных программ и пр.).
2) Случайных негативных проявлений внешней среды, дефектов системы
или ошибочных действий пользователей. Основными источниками отказовых
ситуаций могут быть некорректные исходные требования, сбои и отказы в
аппаратуре, дефекты или ошибки в программах и данных функциональных задач,
проявляющиеся при их исполнении в соответствии с назначением. При таких
воздействиях внешняя, функциональная работоспособность систем может
разрушаться не полностью, однако невозможно полноценное выполнение
заданных функций и требований к качеству информации для потребителей.
Для снижения рисков, связанных с дефектами системы, необходимо
проводить тщательное тестирование на контрольных примерах, приближенных к
действительности. Для снижения рисков, связанных с ошибочными действиями
пользователей, необходимо предусмотреть защиту от применения ошибочных
действий по удалению и порче данных.
На стадии доработки могут возникнуть следующие риски:
увеличение нагрузки на персонал; - несогласованность действий
персонала исполнителя и сотрудников предметных областей;
трудности с обучением персонала заказчика из-за нежелания
работать с новой системой;
отсутствие поддержки внедрения ИС со стороны отдельных
ключевых участников проекта;
неучастие руководителей в проекте.
Для минимизации указанных рисков необходимо принимать следующие
меры:
проведение обучения персонала работы с системой;
доведение до персонала смысла внедрения автоматизированной
системы;
активное вовлечение высшего руководства в проект, активное
взаимодействие с ним в ходе проекта и своевременное принятие решений,
необходимых для нормальной реализации проекта.
90
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе включает
в себя следующие аспекты:
защита информации непосредственно в информационной системе от
внутренних угроз;
защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.2.
Таблица 2.2
Разграничение прав пользователей
Группы
пользователей
Модуль
«Клиенты»
Модуль
«Отчеты»
Модуль
«Справочники»
Модуль
«Заказы»
Клиенты
нет
нет
Чтение
Полный
Администратор
Интернет-
магазина
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
- использованием программно-аппаратных комплексов;
- разработкой и соблюдение политик безопасности;
- использованием защищенных каналов связи при передаче информации;
- использованием антивирусных средств;
- физической защитой помещений с наиболее ценной информацией.
В рассматриваемой компании для обеспечения информационной
безопасности лицом, ответственным за информационную безопасность
предприятия, разрабатываются следующие нормативно-правовые и
организационно-распорядительные документы:
91
1. Концепция обеспечения информационной безопасности организации
2. Правила обеспечения информационной безопасности при работе
пользователей в корпоративной сети организации
3. Политика и Регламент резервного копирования и восстановления
данных
4. Комплексный план защиты информационных ресурсов организации
от несанкционированного доступа
5. Политика обеспечения безопасности при взаимодействии с сетью
Интернет
6. Антивирусная политика, Инструкция по защите от компьютерных
вирусов, Стандарт на антивирусное ПО
7. Парольная политика
8. Политика управления доступом к ресурсам корпоративной сети
9. Руководство по защите конфиденциальной информации, Перечень
сведений, составляющих конфиденциальную информацию, Соглашение о
конфиденциальности
10. Политика информационной безопасности
11. Политика обеспечения физической безопасности помещений и
оборудования
В данных документах указываются положения в соответствии с их
названием, а также установлены ответственные лица и ответственность за
нарушение указанных правил.
2.2 Управление проектом автоматизации
2.2.1 Описание системы принятия управленческих решений
Нынешняя концепция управления проектом определена на понятии
«проект», где проект выступает не только в качестве объекта управления,
92
обладающего отдельными присущими только ему свойствами, но и как общая
характеристика сути, как основное свойство управления проектом.
Сейчас имеется большое количество трактовок понятия «проект». И все они
основаны на стандартных характеристиках проекта: единая цель, лимиты во
времени, ограниченность ресурсов. Существует два недостатка - недоступность
связи между проектом как заранее созданным планом и проектом как процедурой
внедрения этого плана, а также отсутствие отношения между проектом и
управлением проектом.
Исходя из указанного выше, имеем следующие определения.
Проект является системным комплексом плановых (технологических,
денежных, организационных и др.) документов, включающих в себя комплексно-
системную модель методик, направленных на следование указанной цели. При
этом не нужно понимать сам проект, как особый вид работ по управлению чем-
либо. Проект - это совокупный план, законченная модель действий. Его важно
создать и внедрить, что и составляет укрупненное содержание проектного
управления.
Управление проектом является уникальным типом управленческой
деятельности, определяемой предварительной коллегиальной реализацией
комплексно-системной модели действий по следованию исходной цели и
направленный на внедрение этой модели.
Отличие проекта от производственной системы состоит в том, что проект
можно назвать однократной нецикличной деятельностью. Массовый же выпуск
продукции не имеет заранее оказанных временных рамок и зависит только от
объема спроса. Когда он исчезает, цикл производства останавливается. Сами же
циклы в своем естественном виде проектами назвать нельзя. Но сейчас проектный
подход зачастую начинает использоваться в процессах, направленных на
постоянное производство. К примеру, проекты развития производства до
необходимого уровня в рамках некоторого определенного периода, опираясь на
заданный бюджет, или реализация определенных заказов с договорными сроками
поставки.
Проект как система деятельности живет лишь тогда, пока он требуется для
93
получения финального результата. Концепция проекта, однако, не идет в разрез
концепции фирмы или компании и может быть совместима с ней. Тем более,
проект иногда становится базовой формой деятельности компании.
2.2.2 Формирование команды проекта автоматизации
Среди общераспространенных проблем процесса разработки программного
обеспечения встречаются следующие:
Изменение требований непосредственно в процессе разработки.
Нечеткое распределение ответственности за выполняемую работу и
ее результат.
Наличие непрерывного потока мелких, «быстрых», наваливающихся
требований, отвлекающих разработчиков и менеджеров от основного
направления работ.
Как следствие, срыв сроков, раздувание бюджетов, потеря качества.
Для решения задачи успешной организации процесса разработки ПО была
создана гибкая методология разработки проектов.
Принципы, методы, модели и процессы «гибкого» проектного управления
получили свое развитие в отрасли высокотехнологических проектов, связанных с
созданием и внедрением сложных программных комплексов. Гибкое проектное
управление можно рассматривать как концептуально-практическую платформу,
лежащую в основе целого семейства методик управления инновационными, в
первую очередь информационно-технологическими проектами. Основные
принципы гибкого проектного управления изложены в работах Дж.Хайсмита [1],
Г.Аллемана [8], Г.Чина [11]. Сравнительный анализ различных прикладных
методик гибкого управления инновационными проектами можно найти в работах
К.Лармана [27] и П.Абрамсона и других [5]. Ситуационный подход к выбору
оптимальной методики гибкого проектного управления изложен в книге А.С.Коха
[3].
Дж.Хайсмит описывает основное качество данного подхода следующим
образом. «Гибкость (agility) - это способность одновременно создавать и отвечать
94
на изменения, создавая прибыль в турбулентных экономических условиях.
Гибкость есть способность балансировать между хаосом и стабильностью» [16].
Он продолжает, что «многие ошибочно полагают, что подвижность означает
отсутствие структуры. Но отсутствие структуры или стабильности означает хаос.
С другой стороны, избыток структурной упорядоченности создает жесткость.
Теория сложности говорит, что инновации, т.е. создание чего-то нового методами,
которые сложно заранее определить, возникают часто в точке баланса между
хаосом и порядком, между гибкостью и стабильностью. Ученые полагают, что
возникновение и создание нового имеет место на границе хаоса (edge of chaos)»
[16]. На поиск, казалось бы, невозможного баланса между порядком и хаосом
направлены все усилия гибкого проектного управления. Причем идет оно от
упорядоченности процессов, методов и инструментария, предлагаемых
традиционными школами проектного управления в сторону деструктуризации,
деконструкции избыточно упорядоченных организационных условий
осуществления проектов, к выработке простых и «мягких» (ориентированных на
людей методов и инструментов, обеспечивающих способность гибко
адаптироваться к постоянно меняющимся условиям. Если традиционными
функциями управления проектами рассматривались планирование, оптимизация
и контроль, то гибкое управление проектами видит в качестве главных усилий
естественную эволюцию и адаптация.
В 2001 году создатели и приверженцы нескольких близких по духу и
направленности методик управления ИТ-проектами сформулировали «манифест»
гибкого управления инновационными проектами. Манифест закрепляет 4
основные идеи и 12 принципов [17]. Разработчики манифеста, представители
таких методик как «Экстремальное программирование» (Extreme programming)
[9], «Скрам» (Scrum) [6], «Адаптивная разработка программного обеспечения»
(Adaptive Software Development) [11] и другие, сознательно не пожелали сводить
гибкое управление проектами к моделям, средствам и инструментам, но
представили его в виде гибких и адаптивных принципов и идей, предназначенных
для свободного и творческого воплощения в контексте конкретной ситуации. Идеи
95
и принципы гибкого управления проектами не следует рассматривать как
сложившиеся законы и правила.
Основные идеи гибкого проектного управления состоят в следующем:
личности и их взаимодействия важнее, чем процессы и инструменты;
работающее программное обеспечение (в общем случае - ценный для
пользователя продукт или услуга) важнее, чем полная документация (или
исполнение планов и бюджетов);
сотрудничество с заказчиком важнее, чем контрактные обязательства;
реакция на изменения важнее, чем следование плану.
Принципы гибкого управления проектами включают в себя следующие:
удовлетворение клиента за счёт быстрой и надежной разработки
продукта, обладающего ценностью для клиента;
положительное отношение к изменению требований к продукту, даже
в конце разработки, если это создает ценность для клиента и приводит к
повышению конкурентоспособности продукта;
частая разработка и поставка работающих модулей или версий
продукта (каждый месяц или неделю, или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на
протяжении всего проекта, выходящее за рамки контрактных отношений;
высокий уровень мотивации участников проекта, которые
обеспечены нужными условиями работы, поддержкой и доверием;
личный разговор, как основной метод передачи информации в рамках
проекта;
работающий и ценный для клиента продукт есть лучший измеритель
успеха проекта;
участники проекта, в первую очередь разработчики и пользователи,
должны иметь возможность поддерживать постоянный темп работы на
неопределенный срок;
постоянное улучшение технического мастерства исполнителей и
совершенствование продукции;
стремление к простоте, искусство НЕ делать лишней работы;