Информатизация бизнеса. Управление рисками

Авдошин Сергей Михайлович

Песоцкая Елена Юрьевна

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

В основу учебного пособия положен многолетний опыт преподавания авторами дисциплины «Управление рисками» на отделении программной инженерии Высшей школы экономики.

Книга предназначена для студентов магистратуры, обучающихся по направлениям 080500.68 «Бизнес-информатика» и 231000.68 «Программная инженерия», а также для ИТ-специалистов, разработчиков и заказчиков программных продуктов, менеджеров ИТ-проектов.

 

Допущено УМО по образованию в области экономики, менежмента, логистики и бизнес-информатики в качестве учебника для студентов высших учебных заведений, обучающихся по направлению «Бизнес-информатика» (080700)

Рецензенты:

Козырев О. Р. – директор Нижегородского филиала Национального исследовательского университета Высшей школы экономики, заместитель директора Института информационных технологий НИУ ВШЭ, профессор кафедры прикладной математики и информатики НИУ ВШЭ;

Костогрызов А. И. – заслуженный деятель науки РФ, доктор технических наук, профессор, член-корреспондент Российской академии ракетных и артиллерийских наук и Российской академии естественных наук, действительный член Академии информатизации образования, лауреат премии Ленинского комсомола в области науки и техники.

 

Введение

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

Учебник целесообразно использовать при обучении студентов магистратуры по направлениям 080500.68 «Бизнес-информатика» и 231000.68 «Программная инженерия». Он также будет полезен аспирантам, руководителям ИТ-проектов, лидерам команд разработчиков, заказчиков ПО со стороны клиента, сотрудникам ИТ-служб.

Основная цель курса лекций – представить студентам, аспирантам и менеджерам проектов современный комплекс задач, методов и стандартов управления рисками ИТ-проектов при информатизации бизнеса – создания и развития сложных, тиражируемых программных средств (ПС), баз данных (БД), информационных систем (ИС), приложений инфраструктуры, сервисов и средств поддержки информационных технологий. Внимание акцентировано на комплексе методов и процессов, которые способны непосредственно обеспечить управление рисками сложных высококачественных программных продуктов, анализировать, планировать и контролировать проектные риски, эффективно работать в команде, создавать адекватную мотивацию продуктивной работы, использовать современные программные средства.

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

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

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

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

 

Предисловие

Настоящая монография предоставляет базовые понятия по управлению рисками при информатизации бизнеса, раскрывает специфику индустрии информационных технологий и разработки программного обеспечения. Поскольку по своему замыслу монография ориентирована на студентов магистратуры и начинающих руководителей ИТ-проектов, ее изложение построено как учебник. Но учебник не совсем обычный. Дело в том, что охватываются накопленные знания и опыт из области системной и программной инженерии, то есть того научно-практического направления, которое продолжает находиться в стадии формирования. В отличие от классиков (в России в первую очередь имеются в виду работы профессора Липаева В. В., см. также технический отчет «Руководство в области программной инженерии совокупности знаний – SWEBOK», включающий материалы исследований ученых, опубликованных в англоязычной технической литературе на протяжении последних 30 лет), учебник растолковывает азы и лишь обозначает вершины, к которым должны стремиться профессионалы.

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

• проникновении системной и программной инженерии в различные сферы человеческой жизнедеятельности;

• развитии и широком применении «процессного подхода» на уровне международных стандартов;

• достижении системных эффектов, определяемых возможностями применяемых ИТ и возникновением новых рисков, связанных с уязвимостями самих ИТ;

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

Сегодня эффективные решения и, как следствие, высокий уровень качества (в том числе безопасности) систем во многом связаны с рациональным применением стандартов. Действующие на практике стандарты лишь отражают суть научно-технических достижений, фиксируя де-юре те требования и рекомендации, выполнение которых может способствовать относительному совершенству. Конец прошлого века можно признать плодотворным для развития системной и программной инженерии. В целях адекватной реакции на новшества и развитие ИТ подкомитет SC7 «Программная инженерия» объединенного комитета JTC1 «Информационные технологии» преобразован в подкомитет «Системная и программная инженерия» (SС7 JTC1 ISO/IEC), что отражает стремление к целостному решению проблем стандартизации в направлении всеобъемлющего качества именно систем в их жизненном цикле, а не составных компонентов или процессов. К настоящему времени в мире уже не один год действуют стандарты для систем любой области приложения – это набравший популярность ISO 9001 «Системы менеджмента качества. Требования», ISO/IEC 15288 «ИТ. Системная инженерия – процессы жизненного цикла систем», существенно повлиявший на последующее развитие стандартизации – см. рис. 1, 2, а также стандарты серий ISO 14000 (менеджмент экологической безопасности), OHSAS 18000 (менеджмент охраны труда), ISO/IEC 20000 (сервис-менеджмент), ISO/IEC 27000 (менеджмент информационной безопасности), 31000 (менеджмент риска), развиваются стандарты серии ISO/IEC 33000 (оценка процессов) и др. Таким образом, столь естественное наличие типовых процессов и их идентичное развертывание во времени характеризуют логическую похожесть различного рода систем. Именно анализу системных процессов, регламентируемых этими стандартами, в монографии уделено особое внимание.

Чтобы понять важность рассматриваемой тематики, вспомним некоторые факты.

Рис. 1. Процессы предприятия с ориентацией на потребителя по ГОСТ РИСО 9001

Рис. 2. Процессы жизненного цикла систем по ГОСТ РИСО/МЭК 15288

Обратимся к абсолютно приземленным казусам современного интеллектуального рынка. Вспомним 1997 год, когда разразился мировой финансовый кризис. Все началось с обвала акций высокотехнологичных компаний. Ослабление валют стран Юго-Восточной Азии привело к реализованной на программном уровне реакции биржевых роботов (программных систем автоматической биржевой торговли, анализирующих ситуацию на рынках, сравнивающих ее с хранимыми в памяти ситуациями и автоматически принимающих решения). Последние в автоматическом режиме выставили на продажу громадные объемы валют, с учетом чего национальные валюты в этих странах упали в 30–100 раз! А затем дефолт 1998 года в России… Через 10 лет в августе 2007 года те же биржевые роботы среагировали столь же «адекватно», как и были запрограммированы на подобное развитие биржевой ситуации, – в результате выполнения автоматических приказов одновременно был сгенерирован вал заявок на продажу американских ипотечных облигаций. Физика процессов достаточно проста: брокер-человек справляется лишь с 3–4 портфелями одновременно и в день способен заключить до 10–15 сделок, в то время как биржевые роботы управляют 100 портфелями и могут заключать до 500 сделок в день. В погоне за прибылью не было сделано системных ограничений на вал автоматических заявок. В итоге $260 млрд. убытка – это лишь частный побочный эффект от подобной оптимизации на бирже. Подчеркнем, ущерб сопоставим с совокупным годовым бюджетом нескольких государств Восточной Европы! И если в 1997 году в инициировании кризиса объявили нескольких английских брокеров, спекулировавших в Сингапуре, то в 2007 году обвинять некого – не вредоносные, а сугубо мирные компьютерные программы инициировали глобальный финансовый кризис!

Другими словами, если 50 лет назад последствия от применения ядерного оружия оценивались как возможность многократного уничтожения жизни на земле, то сегодня проявления «мирных» угроз со стороны компьютеризированных систем оказываются соизмеримыми с применением того же самого ядерного оружия. То есть в ХХI веке военные угрозы дополнились еще более разрушительными «мирными» угрозами, связанными с широким внедрением ИТ!

На практике у каждого из заказчиков, разработчиков, производителей и пользователей современных систем неизбежно возникают принципиальные системные вопросы. Например: «Как достичь уровня международных стандартов?»; «Выполнимы ли задаваемые требования?»; «Каковы возможные ущербы?»; «Какой сделать выбор с учетом возможных рисков, затрат и ожидаемого результата?»; «Какие меры более эффективны?». Предполагаемая монография позволяет взглянуть на решение этих вопросов именно в контексте требований современных стандартов. Причем основные положения необходимо рассматривать не только для ИТ-проектов и систем, но и для любого рода систем, создаваемых или функционирующих с использованием средств автоматизации.

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

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

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

А. И. Костогрызов

 

Глава 1

Риски и неопределенности при информатизации бизнеса

 

1.1. Информатизация бизнеса и специфика ИТ-отрасли

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

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

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

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

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

Можно сформулировать следующие утверждения, которые помогут более полно осознать проблематику информатизации бизнеса и влияние информационных технологий на деятельность предприятия:

1) работа предприятий и их экономическая деятельность находятся в прямой зависимости от работоспособности средств автоматизации и общего уровня ИТ внутри предприятия;

2) качество ИТ определяет оперативность управлением – скорость обмена актуальной информацией, верность расчетов экономических показателей, возможности быстро принимать стратегические и прочие решения под воздействием внешних факторов, влияющих на экономическую систему;

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

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

Решение об информатизации бизнеса и переходе на новую информационную технологию должно приниматься на основе эффективности использования ИТ в данной области. В мировой практике затраты на информационные технологии связываются с оборотами компании и оцениваются в пределах 10–30 % от оборота. Естественно, что такой подход не дает ответа на главный вопрос: какие выгоды получит предприятие от использования анализируемых ИТ, – и не освобождает специалистов от необходимости расчета стоимости внедрения.

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

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

Успех ИТ-проекта зависит от многих факторов. Но из их числа можно выделить три основных: время, качество, ресурсы. Сбалансировать их между собой всегда трудно, поэтому популярна поговорка «Выбери два из трех». Если во главу угла ставится высокое качество исполнения всех работ по проекту, то это потребует либо много времени, либо большого числа ресурсов. Главная задача руководителя проекта – уложиться в выделенный бюджет и заданные сроки и обеспечить требуемое качество имеющимися трудовыми ресурсами. Любое нарушение этих ограничений чревато различного рода рисками, которые могут также привести как к негативным, так и к позитивным последствиям.

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

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

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

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

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

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

 привлекать независимых экспертов (не включенных в проектную команду) для оценки рисков. Если все решения по рискам проекта принимаются только людьми, которые мотивированы на успех проекта, многие технические и технологические трудности могут рассматриваться как несущественные;

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

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

В основном риски ИТ-проектов рассматриваются без стандартизированной методики управления рисками и общей системы управления рисками проекта ИТ.

На фоне постоянно улучшающихся технологий, создания новых методик разработки ПО рост успешности проектов из года в год незначительный – динамика успешности проектов за последние 14 лет практически не изменилась. Согласно статистике по поводу проектов ИТ и автоматизации предприятий, собранной международным агентством ИТ-услуг The Standish Group. СHAOS Summary 2009 (рис. 3):

• 32 % проектов завершились успешно;

• 44 % испытали различные трудности (превысили бюджет, выпали из сроков и прочее);

• 24 % проектов просто провалились;

• во всех завершенных проектах только 61 % требуемых свойств были реализованы.

Рис. 3. Статистика ИТ-проектов. The Standish Group. СHAOS Summary 2009

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

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

Еще одной очевидной причиной неудач в области ИТ-проектов является недостаточное внимание руководства к задаче управления рисками. Плохо выполненные задачи по идентификации и оценке рисков, отсутствие плана управления рисками, плана действий в случае возникновения непредвиденных обстоятельств, ответственных за тот или иной риск – все это негативно сказывается на реализации проекта внедрения информационных технологий.

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

В действительности методологические ограничения могут стать еще одной причиной неудач ИТ-проектов. По статистике Standish Group, с нехваткой технических знаний связано не более 10 % проблем в ИТ-проектах, остальные 90 % сводятся к неправильно организованному производственному процессу. К организационным и методологическим ограничениям можно отнести следующие:

• не используются стандарты управления;

• нет общей системы понятий и терминов;

• процессы проектной деятельности не определены;

• нет четких правил распределения ответственности в процессах проектной деятельности;

• опыт проектного управления не обобщается и не сохраняется.

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

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

 

1.2. Риски в ИТ: термины и определения

На сегодняшний день использование информационных технологий рассматривается как обязательное условие для эффективного управления промышленным предприятием и повышения его конкурентоспособности на рынке. В связи со стремительным развитием информационных технологий, которое отмечают большинство российских компаний в области ИТ, и желанием компаний не потерять место на рынке можно говорить о стремлении компаний автоматизировать свою деятельность, идти в ногу со временем и тратить драгоценное время не на решение рутинных вопросов, а на новые стратегические планы и их реализацию. Автоматизация деятельности предприятия всегда подразумевает создание новой системы управления и новых бизнес-процессов в компании, переход на другой качественный уровень работы с информацией и внедрение информационных систем (ИС), что представляет собой достаточно трудоемкий и болезненный процесс, сопровождающийся множеством рисков и непредвиденных ситуаций.

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

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

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

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

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

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

Согласно стандарту (PMBoK) Института управления проектами США, определением риска является неопределенное событие или условие, наступление которого может иметь как положительное, так и отрицательное влияние на проект, что представляет собой комбинацию вышеперечисленных концепций.

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

В различных источниках можно встретить несколько определений риска, так, например:

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

 риск – это вероятностное событие, связанное с неопределенностью, которое негативно влияет на проект;

 риск – это взвешенная линейная комбинация вариации и ожидаемой величины (математического ожидания) распределения всех возможных исходов;

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

 риск – это как вероятная опасность, действие наудачу в надежде на счастливый исход (словарь Ожегова) и др.

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

В классических работах по управлению проектами понятия «неопределенность» и «риск» отождествляются. Однако в ряде западных современных работ в этой области различают понятия риска («Risk»), неопределенности («Uncertainty») и неизвестности («Ignorance»).

Согласно концепции Института программной инженерии (SEI), «риск сам по себе не плох; риск необходим для прогресса, и неудача – часто ключевой момент для обучения. Но надо научиться соотносить возможные негативные последствия риска с потенциальными выгодами от возможностей, которые с ним связаны».

Обобщение различных точек зрения позволило выявить следующие отличия между понятиями «риск» и «неопределенность»:

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

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

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

Причинами неопределенности могут являться:

• недостаток информации об условиях реализации проекта (например, из-за ограниченного времени на этапе планирования или сложности получения информации);

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

• сознательное противодействие (например, действия конкурентов, принимаемые с учетом хода проекта).

Справедливо говорить о многообразии рисков, возникающих в процессе реализации ИТ-проекта. Основные риски, как правило, характерные для любых ИТ-проектов, заключаются в несоблюдении сроков реализации проекта, превышении стоимости и несоблюдении параметров качества.

Многогранность понятия «риск» обусловлена разнообразием факторов, характеризующих как особенности конкретного вида деятельности, так и специфические черты неопределенности, в условиях которой эта деятельность осуществляется. Эти факторы принято называть рискообразующими, понимая под ними сущность процессов или явлений, способствующих возникновению того или иного вида риска и определяющих его характер.

Существующие риски разнообразны и могут быть разделены на множество категорий. Выявить все рискообразующие факторы достаточно сложно. Во-первых, большинство рисков имеют как общие факторы, так и специфические. Во-вторых, конкретный риск может иметь различные причины возникновения в зависимости от вида деятельности компании. Для ИТ-проекта можно привести следующие примеры влияния тех или иных рискообразующих факторов на соответствующие виды рисков. Например, инфляция существенно влияет на валютные, кредитные и процентные риски в сфере финансирования проекта ИТ, закупки программного обеспечения и дополнительного оборудования, оплаты услуг консультантов, проведения мероприятий по обучению сотрудников и повышения уровня их компетенции. Изменение политической ситуации, в свою очередь, ведет к повышению инвестиционных, политических рисков. Политические риски ведут к рискам административных реформ в компании и смене руководства и заказчиков ИТ-проекта, что приводит к отсутствию заинтересованных сторон и административной поддержки реализации ИТ-проекта. Отсутствие поддержки со стороны высшего руководства – фактор риска, который может привести к риску противодействия сотрудников предстоящим изменениям в области ИТ, нежеланию переходить на новые технологии и процессы использования информационных ресурсов. В процессе исследования рисков ИТ-проекта пристальное внимание также следует уделить учету специфики его деятельности и взаимосвязи с деятельностью третьих сторон (субподрядчиков, партнеров, прочих).

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

Примером нейтивного фактора является возможное изменение цен на программное обеспечение (software), которое оказывает воздействие лишь на рыночные риски и никак не воздействует на организационные и технико-производственные риски.

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

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

Согласно методологии MSF (Microsoft Solution Framework), существуют четыре основные категории рискообразующих факторов: «люди», «процессы», «технологии», «внешние условия».

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

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

К третьей категории «технологии» относятся безопасность разработки, среда разработки и тестирования, инструментарий, операционная среда и прочее.

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

 

1.3. Классификация рисков в ИТ-проектах

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

Классификация рисков означает систематизацию множества рисков на основании каких-то признаков и критериев, позволяющих объединить подмножества рисков в более общие понятия.

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

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

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

• одни и те же риски могут немного отличаться по содержанию для разных видов деятельности и разных типов проектов;

• на практике существует очень большое число различных проявлений риска, зависящих от специфики конкретного проекта и различных факторов;

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

• зачастую оказывается весьма сложным разграничить отдельные виды риска и четко сформулировать требования к определению видов риска;

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

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

Выделяют следующие признаки при классификации рисков.

1. Функциональные. К функциональной разновидности рисков относятся риски, определяемые функциональной направленностью, – то есть финансовые риски, риски подрядчиков, проектные риски, прочие.

2. По областям проявления. По областям проявления можно выделить политические риски, информационные, стратегические, прочие.

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

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

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

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

7. По другим специфическим признакам, например:

• по типу источника риска;

• по степени влияния и характеру последствий (критические/допустимые);

• по степени управляемости (контролируемые/частично контролируемые);

• по степени предсказуемости (предсказуемые/непредсказуемые);

• по области происхождения (известные/неизвестные, внешние/внутренние риски).

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

Рис. 4. Пример классификации рисков ИТ-проекта по степени управляемости

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

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

Далее опишем риски, характерные практически для всех ИТ-проектов.

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

Технологические риски. Характеризуют способность интегрируемого решения «корректно накладываться» на имеющуюся инфраструктуру и информационные потоки и часто связаны с единоличным принятием менеджером проекта решений по рискам (идентификация, анализ, выбор метода реагирования). Чем больше и сложнее проект, тем выше данный риск, особенно в масштабах промышленной организации. Говоря о минимизации технологических рисков, следует инвестиции делать более «короткими», а проекты дробить на несколько взаимозаменяемых составляющих. Это поможет избежать неприятных последствий при ошибочном инвестировании на одном из этапов.

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

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

Риски оценки сроков. Для большинства ИТ-проектов, особенно в проектах по разработке и внедрению программного обеспечения (ПО) крупных промышленных холдингов, характерны ошибки в оценках сроков работ проекта. При этом реальные сроки работ могут отличаться от запланированных в разы.

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

Риски непринятия продукта проекта пользователями. Внедрение технологических решений без поддержки организационных преобразований. Любой проект, в том числе в сфере ИТ, – это в первую очередь изменение технологии работы. Техническая составляющая любого проекта безусловно важна, но не менее важна организационная часть. Необходимо убедиться, что все будущие пользователи системы в промышленной организации понимают необходимость введения новых технологий, процессов, регламентов взаимодействия и прочее.

Коммерческие риски (или риски третьих сторон). Могут быть определены на основе факторов бизнеса, например надежности поставщиков, платежеспособности заказчиков, опыта соисполнителей в подобных проектах, связаны с выбором технологии и поставщика. Необходимо оценить успешность технологии на рынке, ее актуальность на протяжении жизненного цикла ИТ-проекта, доступность необходимого аппаратного и программного обеспечения, его качество и частоту модернизации и т. д. Также следует оценить надежность поставщика необходимых технологий.

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

В отдельных случаях целесообразно применять технику структурирования рисков с использованием структурной декомпозиции риска (Risk Breakdown Structure, RBS), сформированной по аналогии, группирующей риски по источникам появления и служащей для определения суммарного воздействия рисков.

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

Таблица 1.

Классификация рисков в зависимости от типов внедрения 

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

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

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

Вторая часть формулировки риска называется следствием и описывает ту нежелательную ситуацию, которой следует избежать. Первая и вторая части формулировки описывают не жесткую, но возможную, с вероятностью меньше единицы, причинно-следственную связь (рис. 5).

Рис. 5. Формулировка риска, согласно методологии MSF

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

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

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

Эффективность управления зависит от правильного и полного понимания тех рисков, с которыми сталкивается проектная группа.

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

Знание о существовании рисков – необходимое условие эффективной работы над ними. Следовательно, перспективы успеха проектной группы от проведения работы по выявлению рисков лишь увеличиваются.

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

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

 

Глава 2

Обзор существующих стандартов и методологий управления рисками

 

2.1. Зачем нужны стандарты и методологии управления рисками

Выбор адекватных методологий управления рисками, моделей ЖЦ ПО, метрик ИТ-проектов, использования инструментальных средств и разработки ПО представляет собой достаточно сложную задачу для компаний – разработчиков ИТ-услуг и команд внедрения.

К сожалению, не существует очевидных правил, утверждающих, в каком конкретном случае следует применять ту или иную методологию управления ИТ-рисками, – нужно выбрать ту методологию, которая максимально отвечает задачам ИТ-проекта. Для этого при выборе методологии надо решить, какую степень формализма вы хотите обеспечить, исходя из масштаба ИТ-проекта, количества участников и прочих факторов. Чем больше команда ИТ-проекта и чем шире география членов команды проекта, чем выше неопределенность проекта (например, используется новая технология или нестабильны требования к проекту), тем детальнее и формализованнее должна быть методология.

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

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

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

• как эталон организации процессов, выполнения работ;

• для обоснования существующей практики управления;

• как руководство по достижению целей (методология);

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

• для получения требуемых компетенций и существующего опыта управления.

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

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

Подходы – это наиболее принципиальные компоненты методологии, которые определяют выбор и использование остальных ее компонентов. Например, подходы к выбору модели жизненного цикла программного обеспечения (спиральная модель, водопада и прочие). Или подходы к выбору методов и средств идентификации, оценки рисков.

Критерии (от греч. kriterion – средство для суждения) в методологии управления – это правила оценки, показатели, позволяющие определить, классифицировать, оптимизировать, оценить те или иные аспекты управленческой деятельности с учетом определенных условий и ограничений. Критерии характеризуют прежде всего то или иное качество управления. Критерии обычно тесно взаимосвязаны с подходами. Например, можно говорить об управлении по целям, результатам и т. п., причем достижение целей, результатов выступает критерием качества управления.

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

Инструменты управления подразумевают набор средств, с помощью которых выполняется та или иная функция, действий, приводящих к требуемому результату. К инструментам управления рисками можно отнести построение иерархической структуры рисков, использование показателей эффективности (KPI), матрицу вероятности и последствий, мозговой штурм, метод Делфи, SWOT-анализ, реестр рисков и многие другие. Некоторые методологии предлагают использование специализированного программного обеспечения в качестве инструмента эффективного управления.

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

 

2.2. Обзор методологий: достоинства и недостатки

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

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

Надо отметить, что методология управления ИТ-рисками, как правило, является частью общей методологии управления. При этом существует общий подход к управлению рисками ИТ-проектов, однако универсальной методики, получившей широкое признание, до сих пор не сформировано.

Среди всего многообразия стандартов принято выделять следующие основные типы стандартов.

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

Международные стандарты разрабатываются, как правило, специальными международными организациями на основе мирового опыта и лучших корпоративных стандартов. Имеют сугубо рекомендательный характер. Право сертификации получают организации (государственные и частные), прошедшие лицензирование в международных организациях.

Основными разработчиками международных стандартов являются организации ISO (International Organization for Standardization) – Международная организация по стандартизации, IEC – Международная электротехническая комиссия и PMI (Project Management Institute) – Международный институт проектного менеджмента (управления проектами).

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

К наиболее известным отраслевым стандартам для ИТ-индустрии можно отнести стандарты IEEE – Института инженеров по электронике и SEI (Software Engineering Institute) – Института программной инженерии.

Государственные стандарты (ГОСТы) принимаются государственными органами, имеют силу закона. Разрабатываются с учетом мирового опыта или на основе отраслевых стандартов. Могут иметь как рекомендательный, так и обязательный характер (стандарты безопасности). Для сертификации создаются государственные или лицензированные органы сертификации.

Для построения обобщенной классификации выделим следующие группы методологий управления и внедрения ИТ:

1) стандарты оценки и управления информационной безопасностью: ISO/IEC 27000/17799, BS 7799;

2) методологии ИТ-аудита: COSO, CobiT, SAC, SAS 55/78;

3) универсальные методологии: ГОСТ 34, PMI PMBOK, IPMA ICB, P2M, PRINCE2;

4) методологии внедрения ПО и управления в сфере ИТ: CobiT, SWEEBOK, MSF, RUP, CMM/CMMI (SEI), ORACLE AIM, ITIL, CRAMM, CORAS, OCTAVE.

Рассмотрим наиболее распространенные стандарты и методологии внутри выделенных категорий.

1. Стандарты оценки и управления информационной безопасностью. Семейство международных стандартов по информационной безопасности в области информационных технологий ISO/IEC 27000/17799, основанное на Британском стандарте BS 7799, включает в себя требования к системам управления информационной безопасностью, управление рисками, метрики и измерения, а также руководство по внедрению. В стандарте описаны жесткие требования к разработке, внедрению и совершенствованию Системы управления информационной безопасностью (СУИБ) и рекомендации к внедрению мер контроля и управления рисками, основанные на «лучших практиках».

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

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

Управление рисками в жизненном цикле программных проектов специально регламентировано международными стандартами ISO 12207 «Процессы жизненного цикла программных средств» и ISO 15504 «Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем», которые целесообразно использовать при разработке комплексов программ. В стандарте ISO 15504 содержится специальный раздел «МАН.4. Процесс управления рисками», назначением которого являются регламентирование и планирование процессов выявления и устранения рисков на протяжении всего жизненного цикла программного продукта.

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

Методология CobiT предоставляет методологию для корпоративного управления ИТ с отдельно выделенной книгой по ИТ-аудиту. Усиленное внимание аудиту ИТ в методологии объясняется тем, что первоначально CobiT разработан Ассоциацией аудита и контроля информационных систем (ISACA). Методология содержит подробное описание этапов, принципов и правил проведения ИТ-аудита, описание того, у кого можно получить необходимую информацию, как ее проверить, какие вопросы задавать.

Методология CobiT предоставляет огромные преимущества при проведении ИТ-аудита и внедрении корпоративного управления ИТ за счет обобщения лучших практик и международных стандартов и постоянного совершенствования. Электронная версия методологии постоянно обновляется и доступна, в том числе на русском языке, на сайте ISACA.

3. Универсальные методологии: ГОСТ 34.X, PMI PMBOK, IPMA ICB, P2M, PRINCE2. ГОСТ 34 является универсальным стандартом в области информационных технологий и объединяет комплекс стандартов на автоматизированные системы. Эти стандарты широко используются государственными предприятиями и зачастую служат основой проектной документации при разработке и использовании ИТ. Масштабность стандарта позволяет разработчикам ПО получить формализованный ответ практически на любой вопрос, который может возникнуть при внедрении. Вопросу управления рисками также уделено внимание, однако из-за масштабности ГОСТа и отсутствия структурированного описания этапов и методов управления рисками могут возникнуть сложности с поиском требуемой информации.

Общие методы анализа рисков в сложных системах регламентированы стандартом ГОСТ Р 51901 – «Управление надежностью. Анализ риска технологических систем». Основной задачей стандарта является обоснование решений, касающихся анализа риска реализации проектов и технологий сложных систем. Хотя стандарт и не направлен исключительно на проекты разработки программного обеспечения, изложенные в нем рекомендации могут быть применены в ИТ-проектах.

Методология PMBoK (Project Management Body of Knowledge), разработанная американским Институтом управления проектами PMI, прекрасно описывает все ключевые области управления проектом: управление коммуникациями, качеством, персоналом и в том числе управление рисками. PMBoK является сводом знаний по управлению проектами и предоставляет детальные инструкции по каждой области управления. Раздел «Управление рисками» содержит подробное описание этапов управления рисками, входной и выходной информации, методов и средств по каждому этапу. Поскольку изначально методология рассчитана на управление универсальными проектами, ее нельзя назвать специфичной в области ИТ и ориентированной на управление рисками ИТ-проектов. Однако стоит отметить, что руководители охотно пользуются данной методологией, учитывая специфику ИТ-проектов и адаптируя методы и средства управления под конкретные нужды ИТ.

4. Методологии внедрения ПО и управления в сфере ИТ: CobiT, SWEEBOK, MSF, RUP, CMM/CMMI (SEI), ORACLE AIM, ITIL, CRAMM, CORAS, OCTAVE. SWEBOK (Software Engineering Body of Knowledge) – это руководство к своду знаний по программной инженерии, в котором собраны основные теоретические и практические знания, накопленные в отрасли программной инженерии. Наравне с идеями общего управления рисками SWEBOK предлагает управлять рисками, уникальными для деятельности в области программной инженерии. Например, тенденция добавлять в получаемый программный продукт функциональные и другие возможности, не определенные на уровне требований, или риски, заложенные в самой природе программного обеспечения, связанные в первую очередь с его сложностью и архитектурно-технологической новизной, присутствующей в той или иной степени в любом программном проекте. В части управления рисками SWEBOK рекомендует проводить идентификацию и анализ рисков, оценку критических рисков и что необходимо сделать, чтобы их избежать, – шаги по смягчению рисков и планированию непредвиденных обстоятельств.

Наиболее признанная методология Microsoft Solutions Framework (MSF) представляет собой пакет руководств по эффективному проектированию, разработке, внедрению, тестированию и сопровождению ИТ-решений ПО. Знания базируются на опыте Microsoft, методология популярна среди разработчиков. Благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена для широкого круга ИТ-проектов.

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

Процесс управления рисками MSF состоит из шести логических шагов (выявление, анализ, планирование, мониторинг, корректирование и извлечение уроков), которые должны постоянно выполняться проектной группой в течение жизненного цикла проекта. Microsoft возводит процесс управления рисками проектов в ранг стратегической задачи ИТ-предприятия, затрагивающей все фазы проектов. При этом уделяется особое внимание извлечению уроков из опыта предыдущих проектов.

Согласно аннотации, приведенной в методологии: «После прочтения данного документа проектная группа, имеющая опыт применения MSF, должна быть способна превентивно управлять рисками ИТ-проектов. Тем же, кто не знаком с процессом управления рисками в ИТ-проектах, этот документ дает базовое понимание концепций, терминологии и принципов, необходимое для внесения собственного вклада в управление рисками во всем жизненном цикле ИТ-проектов». Огромным преимуществом является доступность методологии на сайте Microsoft, в том числе на русском языке.

Еще одна известная методология Rational Unified Process (RUP) представляет собой целостную модель организации процессов разработки программного обеспечения и успешно применяется в ИТ-проектах любых типов и объемов. Методология опирается на проверенные практикой методы анализа, проектирования и разработки ПО, методы управления проектами. RUP описывает итеративную схему процессов, разработанную в Rational Software. Итеративная разработка является ключевой особенностью методологии, поскольку позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. Сокращение рисков является основной целью методологии RUP.

В методологии даны полезные рекомендации по идентификации списка рисков, определению приоритетов, формированию стратегий по устранению риска. Процессы управления рисками в RUP проходят через все фазы и итерации разработки ПО.

Группа стандартов CMM/CMMI была создана Институтом программной инженерии SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Основная идея стандарта состоит в использовании модели CMM/CMMI (Capability Maturity Model / Integrated – модель зрелости возможностей) для приписывания каждой организации определенного уровня, с тем чтобы организации можно было бы сравнивать по уровням. Деление на уровни позволяет последовательно внедрять CMM/CMMI, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки. Для достижения стандартов рекомендуется использовать специализированные процессы разработки программного обеспечения: Personal Software Process / Team Software Process. Последовательное применение модели PSP/TSP дает возможность сделать нормой в организации наиболее зрелый (пятый) уровень CMM. Акцент поставлен на непрерывное управление рисками, которое, согласно определению Института программной инженерии, представляет собой инженерно-техническую подготовку программного обеспечения с процессами, методами и средствами для управления рисками в проекте. Согласно методологии, существуют семь принципов, которые обеспечивают основу для эффективного управления рисками: Глобальная перспектива, Обзор вперед, Открытые связи, Комплексное управление, Непрерывный процесс, Коллективное видение продукта, Командная работа.

Помимо стандартов CMM/CMMI, Software Engineering Institute разработал модель управления рисками при разработке программного обеспечения, частично вошедшую в PMBoK Guide 2000, включающую в себя как требования упомянутых стандартов, так и известные «хорошие практики» (best practices) управления рисками. Подготовку управления рисками проекта эта модель рекомендует проводить в следующей последовательности:

• постановка целей управления рисками в соответствии с целями проекта;

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

• идентификация и оценка рисков (обнаружение возможных рисковых ситуаций и оценивание влияния рисков на проект);

• подготовка к устранению рисков (разработка мероприятий по сокращению или устранению рисков и подготовка отчета с 235 рекомендациями для руководства проекта по анализу и управлению рисками);

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

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

К специфичным методологиям, уделяющим большее внимание управлению рисками ИТ-проектов, нежели процессу разработки программного обеспечения, можно отнести CRAMM и CORAS.

Методология CRAMM разработана британским Центральным компьютерным и телекоммуникационным агентством в 1985 году, применяется в области управления ИТ-рисками как для крупных, так и для небольших организаций правительственного и коммерческого сектора. CRAMM предполагает использование технологий оценки угроз и уязвимостей по косвенным факторам с возможностью проверки результатов. Для оценки рисков в методологии используется механизм моделирования информационных систем с позиции безопасности с помощью обширной базы данных по контрмерам. Компания Siemens предлагает программную реализацию методологии и представляет продукты CRAMM Expert и CRAMM Express.

Методология CORAS разработана в рамках программы Information Society Technologies. Ее суть состоит в адаптации, уточнении и комбинировании таких методов проведения анализа рисков, как Event-Tree-Analysis, цепи Маркова и прочие. В соответствии с CORAS информационные системы рассматриваются не только с точки зрения используемых технологий, но и с нескольких сторон, а именно как сложный комплекс, в котором учтен и человеческий фактор. Методология получила программную реализацию в виде Windows– и Java-приложений.

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

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

 

2.3. Риски при использовании методологий разработки ПО

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

В зависимости от назначения проектный менеджер выбирает наиболее подходящие для разработки и управления ПО модели зрелости и процессные модели, проектные методологии и индивидуальные и групповые практики. Универсальные концепции, а также управленческие стандарты, например серии ISO 9000, аккумулируют опыт и лучшие управленческие практики, которые стали основой методологий совершенствования деятельности компаний-разработчиков, таких как модели зрелости (CMM/CMMI), стандарты оценки и улучшения процессов (SPICE) и прочие. Объектами стандартизации в сфере ИТ являются:

• конструкторская документация (состав, структура, требования к оформлению);

• стандарты кодирования и оформления программных текстов;

• терминология и определения;

• модели процессов;

• модели жизненного цикла;

• требования к безопасности хранения и передачи информации и способы ее обеспечения;

• качество программного обеспечения, характеристики качества, методы получения данных по качеству;

• графические и нотации и инструменты формализованного описания требований и технических решений;

• форматы хранения данных, обмена и передачи данных.

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

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

В зависимости от «уровня зрелости» организации должна использоваться та или иная группа инструментальных средств. В основе каждой методологии лежит набор «принципов», которые могут быть истинными или ложными для ИТ-проекта. Также с выбором методологии происходит выбор ролей, навыков, видов деятельности, используемых техник, инструментария, поставляемых артефактов, стандартов, мер качества и приоритетов проекта. Многие методологии обвиняют в бюрократизме – чтобы следовать такой методологии, нужно выполнять так много различных предписаний, что замедляется весь темп работ. Некоторые методологии являются слишком общими и подходят для многих случаев разработки, однако не содержат специфических указаний, другие методологии основной целью полагают корректность программных продуктов, явность и повторяемость процесса. Гибкие методологии в первую очередь направлены на повышение продуктивности и снижение стоимости работ, при этом они не применимы для большой проектной команды.

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

Например, чем больше команда, тем «тяжелее» должна быть используемая методология и выше стоимость проекта. Чем критичнее проект, тем выше должны быть «плотность» и формализация методологии.

Для долгосрочных проектов, как правило, подходят «более тяжелые» и формализованные методологии, такие как MSF, RUP, CMM-SE. Тяжелые методологии дают наибольший эффект в крупных компаниях, занятых промышленным выпуском ПО и готовых на многолетние инвестиции в кардинальную перестройку организационной структуры. Такие подходы обычно дают очень хорошие результаты, но процесс внедрения растягивается на несколько лет. Стоимость использования подобной методологии достаточно высока. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, что является достоинством методологии. Однако в ряде случаев такая детальность планирования является излишней и не оправдывает затраченных ресурсов.

Методология RAD (Rapid Application Development) идеально подходит для быстрой разработки приложений (до 6 месяцев) с использованием ограниченной команды специалистов. Поскольку методология предполагает активное вовлечение пользователей в процесс разработки, отсутствие базовых навыков в области информационных технологий может стать ключевым риском в процессе разработки. Фаза построения и разработки приложения происходит крайне быстро, поэтому существуют определенные риски внесения изменений – дополнительных требований и пожеланий, которые практически невозможно реализовать из-за ограниченных сроков реализации. Также методологии быстрой разработки приложений и экстремального программирования (XP) характеризуются наличием сильного менеджера проекта. Его роль становится ключевой, поэтому крайне важно уделять внимание организационным аспектам, взаимодействию коллектива, компетентности команды.

По сравнению с монументальными методологиями, в гибких (Scrum, Crystal, Open Source, ASD) очевидно прослеживается меньшая ориентация на документацию, что выражается в меньшем ее объеме для каждой конкретной задачи. Легкие методологии дают возможность обрабатывать большие объемы информации, относящиеся к проекту, в процессе неформального, непосредственного, личного общения, а не с помощью документации. При этом отсутствие документации может быть ограничением использования методологии в государственных учреждениях или организациях, требующих высокой степени формализации и документирования. Поскольку практически все гибкие методологии ориентированы на максимально неформальный подход к разработке, зачастую возможны спорные вопросы при реализации тех или иных изменений, расстановке приоритетов.

При этом легкие методологии также отличаются друг от друга – Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология «Adaptive Software Development» разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках). Scrum характерен активным воздействием внешних лиц по отношению к рабочей группе, при этом у заказчика сохраняется максимальный приоритет. Заказчик продукта сам решает, как оформить бэклог продукта, выбирает требования для следующей итерации. При этом несоблюдение базовых принципов, заложенных в Scrum, таких как самонаправляемые команды, обязательная расстановка приоритетов или еженедельные обновления, может привести к срыву проекта.

 

2.4. Риски в жизненном цикле программного обеспечения

Анализ методологий в области разработки ПО и опыт менеджеров ИТ-проектов подсказывает, что для эффективной реализации ИТ-проектов обязателен анализ жизненного цикла.

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

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

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

Существует множество видов моделей жизненного цикла ПО. Поскольку универсальной модели нет, разработчики нередко прибегают к комбинированию моделей, чтобы использовать возможные преимущества. Как правило, все модели включают все стадии ЖЦ ПО и связаны с методологиями проектирования (модель синхронизации и стабилизации – MSF, каскадная и спиральная модель – RUP и т. д.).

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

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

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

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

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

Рис. 6. Спиральная модель

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

 

Глава 3

Улучшение качества ПО и снижение рисков

 

3.1. Понятие качества и его многомерность

Качество – наиболее важная характеристика программных продуктов. Зачастую качество является основным критерием выбора поставщика, программного обеспечения, информационных технологий. В ходе ИТ-проекта существует много возможностей для потери первоначально задуманного качества решения. Каждый этап жизненного цикла – инициация, внедрение, обновление, обслуживание – представляет особые риски для качества, которые необходимо учитывать. Специалистами отмечено, что вклад в качество, осуществленный на ранних стадиях, имеет более сильное влияние на конечный продукт, чем на поздних стадиях. При этом тестирование и измерение качества должны происходить на всех стадиях жизненного цикла, так же как и постоянное отслеживание и сравнение промежуточных этапов с первоначальным планом. Контроль качества ИТ-приложений на протяжении всего жизненного цикла позволяет ИТ-организациям соотнести процессы обеспечения качества с коммерческими результатами.

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

Проекты в области информационных технологий, а также информационные системы имеют ряд особенностей в разрезе управления качеством. Во-первых, ИТ-проекты отличают гибкость и практически не ограниченные возможности («запрограммировать можно все, что возможно описать словами»). Во-вторых, для ИТ-проектов характерна высокая сложность получающихся систем и, как следствие, большое количество ошибок в них. Поэтому, говоря о качестве ИТ-проектов, следует учитывать многомерность понятия качества. Для создания высококачественного проекта в области информационных технологий следует уделить внимание качеству организации, качеству используемых данных, сервисов и инфраструктуры, качеству информации и программного обеспечения. Так, например, наличие процесса разработки программного обеспечения, удовлетворяющего высокому уровню качества, не гарантирует выпуска программного обеспечения высокого качества. Управление качеством будет успешным, если под контролем находятся все измерения качества – продукта, процессов, организации и прочего.

Для расстановки приоритетов качества на каждом этапе жизненного цикла внедрения ИТ необходимо учитывать следующие вопросы:

1. Готова ли компания запустить приложение в эксплуатацию и все ли бизнес-процессы работают так, как было запланировано?

2. Обеспечены ли прозрачность и контроль над изменениями в приложении?

3. При возникновении проблем в эксплуатации можно ли их быстро выявить и устранить?

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

Говоря о качестве ИТ-проекта, следует отметить, что не существует единой метрики качества. Это объясняется тем, что не всегда можно однозначно ответить на вопрос, какие характеристики важнее – применение ПО, его производительность, результаты использования, стоимость и время разработки или же удовлетворение коммерческим требованиям.

При выборе метрик главными показателями являются адекватность метрик целям качества, прозрачность и четкость интерпретации, экономическая эффективность получения (рис. 7).