Глава 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 и т. д.).
Выбор той или иной модели зависит от характера и масштаба проекта (объем, сроки), планируемой ИТ-архитектуры, степени сопровождаемости ПО и прочих факторов. В свою очередь, выбранная модель жизненного цикла окажет влияние на скорость разработки и качество продукта, стоимость и время выхода на рынок, стратегию управления изменениями, стратегию управления рисками в процессе разработки.
Наиболее прогрессивной в настоящее время является спиральная модель, которая обладает рядом преимуществ, по сравнению с другими моделями, и характеризуется повышенным вниманием к управлению рисками. По мнению автора спиральной модели Барри Боэма, «главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях спиральная модель становится эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность наилучшего соединения существующих подходов в контексте данного проекта».
Конец ознакомительного фрагмента.