Управление жизненным циклом информационных систем

 

Лекция 5

 

Тема лекции: «Создание ИС в соответствии с методологиями и стандартами»

1. Корпоративные методологии.

2. Индустриальные стандарты и методологии.

3. Сервисный подход к эксплуатации ИС.

1. КОРПОРАТИВНЫЕ МЕТОДОЛОГИИ.

 

1.1. IBM (Rational Unified Process, RUP).

 

Один из наиболее ориентированных на пользователя подходов, RUP (Rational Unified Process) предполагает итеративную разработку, большое внимание к архитектуре, к потенциальным рискам, и главное – к управлению на основе пользовательских «юзкейсов» (use-cases).

 

«Юзкейсы определяют соглашение между стейкхолдерами системы относительно ее поведения. Юзкейс описывает поведение системы при различных условиях в ответ на запрос со стороны одного из стейкхолдеров» (Коберн).

 

По сути юзкейсы описывают варианты использования системы и ее действия по достижению поставленных целей. Стейкхолдерами могут быть: заказчики (определяющие конечную цель), менеджеры (ответственные за оперативное управление), аналитики (документирующие требования), разработчики (понимающие реальные потребности заказчика), а также специалисты по тестированию, техническому описанию и разработке интерфейсов пользователя, понимающие поведение системы. Для каждого из них определяются необходимые действия и варианты поведения, но во избежание «тяжеловесности» методологии она предполагает возможность отказаться от определенных работ и задач, в которых нет необходимости для конкретного проекта. Все эти работы и задачи сформированы в рамках четырех основных этапов и сочетания шести основных и трех вспомогательных рабочих процессов. Важно, что RUP, представляя собой, в конечном счете,  набор решений оптимизации разработки ПО, автоматизируем. В частности, компания Rational Software (в 2003-м году ставшая подразделением IBM), описав возможные роли участников проектов, все возможные виды проектных документов для каждого из них, как и формы распределения ответственности, создала программное решение для поддержки всего процесса разработки. И его использование, по сути, гарантирует достижение третьей стадии зрелости модели CMM, что для многих процессов многих организаций является достаточным уровнем развития. Данный инструмент, IBM Rational Method Composer, позволяет создавать, конфигурировать и публиковать определенные процессы разработки.

 

И наконец, RUP содержит шесть основных «лучших практик», описанных в RUP и направленных на повышение продуктивности и снижение вероятности появления ошибок (снижение рисков):

 

Основные 6 «лучших практик» RUP следующие.

 

1. Итеративная разработка.

 

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

 

2. Управление требованиями.

 

3. Компонентный подход.

 

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

4. Визуальное моделирование.

 

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

 

5. Поддержание уровня качества.

 

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

 

6. Мониторинг изменений.

 

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

 

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

1.2. Microsoft (Microsoft Solution Framework, MSF).

 

Компания Microsoft, будучи мировым гигантом в сфере разработки программного обеспечения, подготовила и применяет несколько методик для покрытия не только ЖЦ информационных систем, но и технологической инфраструктуры, и поддерживающей. Однако в контексте рассмотрения ЖЦ ПО нас интересует именно методология разработки: как являющийся одним из основных аспект управления и взаимодействия участников процесса, так и другие области знаний (управление рисками, планирование). В целом охватываемые MSF дисциплины описаны в пяти частях (т.н. «белых книгах»), однако интересно, что командами консультантов Microsoft применяется на практике не этот ресурс, а методика MSF for Agile Software Development, являясь прикладным вариантом MSF и разумеется, отражая общий методологический подход к итеративной разработке.

 

Если обратиться непосредственно к процессу разработки / внедрения, то его характеризуют:

1. Итеративность.

 

2. Формирование в качестве результата ИТ-решения.

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

 

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

 

3. Базируемость на вехах (основных и вспомогательных) и артефактах как результатах их достижения.

ПРИМЕР.

 

На схеме концепции MSF основными вехами являются

 

«Концепция проекта утверждена».

 

«Разработка завершена».

 

В то же время, промежуточными вехами между ними могут быть:

 

«Верификация технологий осуществлена».

 

«Базовая версия функциональной спецификации создана».

 

«Базовая версия сводного плана создана».

 

«Базовая версия сводного календарного графика проекта создана».

 

Среды разработки и тестирования развернуты».

 

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

 

Среди шести упомянутых кластеров:

 

- управление программой (архитектурным решением);

 

- разработка (программной и технической архитектуры);

 

- тестирование (планирование, разработка, отчетность);

 

- управление релизами;

 

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

 

- управление продуктом (по сути, управление требованиями бизнес-заказчика и бизнес-приоритетами).

 

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

 

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

 

Допустимо совмещать, например:

 

Управление продуктом, Тестирование, Управление требованиями заказчика;

 

Управление релизами и Тестирование.

 

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

 

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

 

1.3. On Target.

 

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

 

Рассмотрим основные этапы внедрения в соответствии с On Target:

 

Подготовка проекта.

 

Формирование проектной команды и подготовка документации.

 

Анализ.

 

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

 

Дизайн.

 

Разработка и согласование технического задания и эскизного проекта. Финализация плана проекта и бюджета.

Разработка и тестирование.

 

Написание программного кода, разработка интерфейсов, настройка и тестирование.

 

Развертывание.

 

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

 

Опытная эксплуатация.

 

Приемка в ОПЭ, окончательная верификация данных и процедур после миграции, опытная эксплуатация, передача в промышленную эксплуатацию.

В силу того, что к моменту приобретения Navision у Microsoft уже применялись свои проверенные корпоративные методологии MSF и MOF, в дальнейшем On Target была дополнена и к моменту выведения на рынок Microsoft Dynamics превратилась в результате доработок в MS Dynamics Sure Step / Microsoft Business Solutions Partner Methodology.

 

1.4. Microsoft Dynamics Sure Step и Microsoft Business Solutions Partner Methodology.

 

Sure Step была разработана для партнерской сети Misrosoft с целью обеспечения единого подхода к внедрению решений класса MS Dynamics (почему и получила название MS Business Solutions Partner Methodology, в частности используемое для программного решения Modeling Tool). Она основывается на лучших практиках проектов внедрения и для соответствия различным сценариям предлагает несколько компонентов:

 

Этапы.

С предшествующей методологии On Target отличия незначительные:

 

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

 

Процессы.

 

ПРИМЕР.

 

На стадии дизайна схема процессов выглядит следующим образом:

Предложения.

 

MS Dynamics Sure Step предоставляет возможность не обязательно проходить все этапы модели методологии, но и выбирать необходимые в соответствии со спецификой бизнеса и задачами проекта, что и отражается в компоненте Предложения.

 

ПРИМЕР.

 

Диагностика, подробный анализ; внедрение (полное либо быстрое); оптимизация.

 

Отчетные материалы.

 

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

 

оценка инфраструктуры;

 

план проекта;

 

функциональные требования;

 

план и контрольный список реализации.

 

Отчетные материалы являются прямыми результатами соответствующих процессов этапов.

 

Межэтапные (постоянные) процессы.

 

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

 

анализ бизнес-процесса;

 

конфигурация;

 

перенос данных;

 

инфраструктура;

 

инсталляция;

 

интеграция;

 

тестирование;

 

обучение.

 

Выделяются те операции, которые относятся к конкретным процессам и охватывают несколько этапов.

 

Процедуры управления проектами.

 

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

 

Роли консультантов и клиентов.

 

MS Dynamics Sure Step определяет основные роли специалистов со стороны заказчика внедрения и подрядчиков и охватывает рекомендации для каждой из них.

 

Со стороны заказчика:

 

Руководитель, принимающий решения.

 

Руководитель проекта.

 

Руководитель отдела ИТ.

 

Ключевой пользователь.

 

Конечный пользователь.

 

Со стороны исполнителя:

 

Руководитель проекта.

 

Менеджер по контактам.

 

Архитектор решений.

 

Консультант по приложениям.

 

Консультант по разработке.

 

Технический консультант.

 

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

 

Таким образом, MS Dynamics Sure Step представляет собой комплексную методологию внедрения, оптимальную для программных продуктов Dynamics CRM, AX, NAV за счет подробных шаблонов и схем процессов, а также средств редактирования для адаптации методологии к специфике предприятия и отрасли. Методология определяет необходимые шаги каждого этапа внедрения продуктов MS Dynamics как в виде иерархической структуры работ, так и в виде графических схем процессов MS Visio.

1.5. SAP (Accelerated SAP).

 

Призванная снижать риски, стоимость и время внедрения программных продуктов, методология ASAP основывается на собственном опыте SAP в области разработки технических решений и бизнес-консалтинга, со значительным фокусом на уже проверенных методиках управления проектами и инфраструктуре PMBoK. Так, пять ключевых этапов маршрутной карты SAP достаточно четко соотносятся с этапами проектного менеджмента PMBoK [2].

 

В целом же корпоративная методология Accelerated SAP (ASAP) предлагает комплексный инструментарий, сочетающий технологическую и управленческую части в виде трех основных компонентов:

 

1. Синхронизация бизнес-приоритетов клиента (в зависимости от индустрии) с конкретными решениями SAP через отраслевые карты бизнес-ценностей (value maps) инструмента Solution Explorer.

 

2. Карты управления проектами (маршрутные карты) с основными этапами и активностями по ним.

 

3. Проектирование, настройка, тестирование и эксплуатация решения при помощи менеджера решений SAP Solution Manager.

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

 

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

 

1.6. Oracle (Oracle Unified Method, OUM).

 

Oracle Unified Method (OUM) – корпоративная методология поддержки ЖЦ информационных технологий на предприятии, содержащая общее руководство по настройке и типовую структуру работ, а также набор шаблонов, комплекты материалов по конкретным продуктам Oracle и необходимые программные инструменты.

 

Изначально основой методологии Oracle стала модель унифицированного процесса разработки (Unified Process), которая была адаптирована также IBM для формирования собственной корпоративной методологии Rational Unified Process.

 

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

Выделяя, аналогичные ASAP,  пять стадий, Oracle изначально предполагает возможность итераций внутри каждой из них (две итерации проектирования, три итерации разработки) с наглядным представлением, на каком именно из 15-ти процессов разработки следует фокусироваться в каждый конкретный момент [2].

 

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

 

2. ИНДУСТРИАЛЬНЫЕ СТАНДАРТЫ И МЕТОДОЛОГИИ.

 

2.1. AGILE.

 

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

 

Приоритет взаимодействия людей над процессами и традиционными инструментами управления.

 

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

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

 

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

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

 

В качестве одного из важнейших элементов Agile-подхода к разработке выступают пользовательские истории (user stories). Это описанные одним или несколькими предложениями основные аспекты функциональности системы, необходимые для выполнения пользователем своей работы. В достаточно сжатом виде, они должны отвечать на вопросы: «Кто?», «Что?» и «Почему?» и могут создаваться как менеджером проекта по результатам обследования как один из форматов фиксирования требований, так и разработчиками для выражения нефункциональных требований (например, к безопасности, производительности, качеству решения).

 

ПРИМЕР.

 

Отдельные требования, представленные в виде user stories:

 

Как ответственный за проведение рассылок, я должен вести мониторинг адресатов по разным категориям.

 

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

 

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

 

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

 

Как ответственный за проведение рассылок, я бы хотел создавать их план в перспективе на 2 недели вперед.

 

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

 

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

 

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

 

Итоговая user story на «техническом» языке:

 

Как ответственному за проведение рассылок, пользователю необходимо обеспечить следующую функциональность:

 

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

 

Иметь несколько уровней прав доступа к рассылкам (на просмотр статистики, на выгрузку e-mail адресов, на отправку рассылок).

 

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

 

 

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

 

2.2. SCRUM.

 

В переводе с английского языка «SCRUM» означает «схватка». Впервые подобная методология была введена в употребление профессорами японского Hitotsubashi University в их статье «Новая игра в производстве продукта» («The New Product Development Game»), написанной в 1986 году. В ней разработка продукта была сравнена со схваткой вокруг мяча в регби – приемом, называемым «скрам». Тем не менее, авторами концепции считаются разработчики из США, Кен Швабер и Джефф Сазерленд, впервые определившие и описавшие основополагающие принципы SCRUM – «гибкой» методологии управления проектами (чаще всего применяющейся в области разработки ПО).

 

По своей сути SCRUM представляет собой набор принципов разработки, которые позволяет представлять конечному пользователю (и заказчику) действующий продукт / прототип, обладающий новыми функциями и возможностями с наивысшим приоритетом. Работа в этом случае проводится в четко фиксированные недлительные (в среднем от 1 до 6 недель, чаще от 2 до 4) итерации (спринты). Ожидаемые результаты спринта определяются командой под руководством SCRUM-мастера в самом его начале и НЕ могут изменяться до завершения. К ним под руководством SCRUM-мастера (по сути руководителя проекта) и product-мастера (заказчика, владельца проекта) создается список работ на период спринта и на весь проект (sprint-backlog и product-backlog соответственно).

 

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

 

Однако при более глубоком рассмотрении SCRUM имеет очень важные основы: методология предполагает циклический и очень активный процесс, минимизирующий неопределенность требований за счет коротких итераций и предоставляя возможность детального прототипирования. Долгие, нестандартные, динамические проекты, при расплывчатом представлении о конечном ожидаемом результате и постоянной смене приоритетов не являются проблемой для SCRUM, и именно поэтому он часто применяется на первых этапах, затем в целях экономии средств / ресурсов переходя к использованию другой методологии. Соответственно, SCRUM может применяться практически любым типом организаций – от стартапов с их высокой неопределенностью до госзаказчиков с частым изменением требований и частой необходимостью демонстрации текущей версии для отчета о результатах.

 

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

 

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

 

2.3. RAD.

 

Методология быстрой разработки приложений RAD (rapid application development) предполагает наличие трех основных элементов: небольшой команды до 10 человек, непродолжительный период внедрения в 2-6 месяцев и итеративный цикл, в основе которого спиральная модель жизненного цикла ИС.

 

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

 

Однако есть и некоторые отличия с традиционной спиральной моделью.

 

В силу этого же итеративного подход, как и другие подобные методологии, RAD не может применяться для разработки сложных систем (например, от которых зависит безопасность людей, таких, как системы управления кораблями или самолетами), так как первые версии не будут полностью работоспособны. Не следует удивляться также и предложению подрядчика использовать принципы RAD на первых этапах, затем переписывая часть кода на «традиционном» языке программирования – таком, как C# или C++.

 

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

 

2.4. XP.

 

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

 

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

 

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

 

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

 

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

 

Коллективная работа по написанию кода / внесению изменений в настройки. Этот принцип относится к двум аспектам. В первую очередь, это «коллективное владение кодом», когда любой участник команды разработчиков может внести изменения благодаря единым правилам оформления кода и использованию стандартов для ПО. С другой стороны, применяется метод «парного программирования», в соответствии с которым двое разработчиков используют один компьютер, чередуя написание кода и доработку настроек, реализацию требований и прочие вопросы.

ЭЛЕМЕНТЫ УПРАВЛЕНИЯ КОРПОРАТИВНЫМИ ИТ

 

1. СobiT

 

CobiT (сокращение от Control Objectives for Information and Related Technology, «Задачи информационных и смежных технологий») представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления IT, аудита и IT-безопасности.

 

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

 

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

 

Информационная безопасность.

 

Управление рисками.

 

Управление непрерывностью бизнеса.

 

Управление качеством.

 

Обеспечение соответствия требованиям регуляторов.

 

Защита интеллектуальной собственности.

 

COBIT, будучи единым сборником рекомендаций, включает некоторые элементы таких концепций и методологий, как Закон Сарбейнса-Оксли (Sarbanes-Oxley), Базельское соглашение (Basel III), COSO, ITIL, PRINCE2, TOGAF, PMBOK, PCI DSS. Среди данного списка отсутствуют такие популярные руководства, как Val IT и Risk IT, так как пятая версия интегрирует их содержание.

 

Далее рассмотрим основные элементы стандарта для формирования представления о его структуре.

 

Модель связи целей бизнеса и ИТ.

 

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

 

ПРИМЕР.

 

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

 

Руководящие принципы CobiT.

 

Соответствие потребностям заинтересованных сторон.

 

Комплексный взгляд на предприятие.

 

Применение единой интегрированной методологии.

 

Обеспечение целостности подхода.

 

Разделение руководства и управления.

 

Драйверы для заинтересованных сторон

 

Потребности заинтересованных сторон.

 

Реализация выгод.

 

Оптимизация рисков.

 

Оптимизация ресурсов.

 

Цели предприятия.

 

ИТ-цели.

 

Цели в области факторов влияния.

 

7 факторов влияния CobiT (CobiT Enablers).

 

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

 

Принципы, политики и концепции – основные инструменты «трансляции» предлагаемой линии поведения в области управления ИТ.

 

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

 

Организационные структуры – основные сущности в области принятия решений на предприятии.

 

Культура, этика и поведение – важный фактор успеха при управлении.

 

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

 

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

 

Сотрудники, навыки и компетенции – необходимые составляющие деятельности компании.

 

Общая модель факторов влияния представлена ниже.

 

Среди атрибутов факторов влияния:

 

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

 

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

 

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

 

Передовые практики. Примеры наиболее эффективной реализации факторов влияния, их входов и выходов.

 

Процессы CobiT

 

CobiT делит всю деятельность ИТ на 5 доменов (группы или сферы деятельности), которые включают 37 процесса (в версии CobiT 5).

 

В терминах CobiT процесс – «набор задач (действий), объединенных естественным образом и содержащих детальные цели контроля».

 

Цели контроля описывают требования по эффективному контролю и представляют собой:

 

Формулировки управленческих действий,

 

Политики, процедуры, практики, организационные структуры.

 

ПРОЦЕССЫ,  ТАКИМ ОБРАЗОМ,  ОБЪЕДИНЯЮТСЯ В СЛЕДУЮЩИЕ ДОМЕНЫ (ГРУППЫ):

 

Координация, планирование и организация,  APO (процесс управления Plan and Organise в CobiT 4.1).

 

 

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

 

Разработка, приобретение и внедрение, BAI (процесс управления Acquire and Implement в CobiT 4.1).

 

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

 

Предоставление, обслуживание и поддержка, DSS (процесс управления Deliver and Support в CobiT 4.1).

 

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

 

Мониторинг, оценка и анализ, MEA (процесс управления Monitor and Evalutate в CobiT 4.1).

 

Обеспечение обратной связи: «эффективность ИТ» – «цели бизнеса», корпоративное управление ИТ и оценка эффективности ИТ.

 

Оценка, задание направления и мониторинг, EDM (процесс руководства, отсутствующий в CobiT 4.1).

COBIT также приводит процессы на более детализированном уровне, полная схема приведена в приложении.

 

ПРИМЕР.

 

DSS (Предоставление, обслуживание и поддержка):

 

DSS01 – Управление эксплуатацией.

 

DSS02 – Управление запросами на обслуживание и инцидентами.

 

DSS03 – Управление проблемами.

 

DSS04 – Управление непрерывностью.

 

DSS05 – Управление услугами безопасности.

 

DSS06 – Управление контролями бизнес-процессов.

 

Именно в подобной модели процессов и становится более очевидной связь с ITIL и TOGAF в силу использования соответствующей терминологии и сходства упоминаемых процессов.

 

Также для каждого процесса определены:

 

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

 

2. Ключевые показатели эффективности (KPI) – метрики, которые показывают, насколько хорошо работает ИТ-процесс.

 

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

 

Цели и метрики процессов.

 

Важной особенностью пятой версии документа является новое понятие модели возможностей процессов. Она создана как способ измерения производительности процессов доменов руководства и управления ИТ (EDM и PBRM соответственно). Отдельно основные отличия данного подхода рассмотрены в публикации ISACA COBIT Process Assessment Model (PAM).

 

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

 

ПРИМЕР.

 

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

 

Уровень 0. Неполный процесс.

 

Процесс еще не внедрен либо неспособен систематически достигать своих целей.

 

Уровень 1. Осуществленный процесс.

 

Внедренный процесс соответствует своему назначению.

 

Уровень 2. Управляемый процесс.

 

Осуществленный процесс планируется, отслеживается и корректируется.

 

Уровень 3. Установленный процесс.

 

Управляемый процесс достигает ожидаемых результатов.

 

Уровень 4. Предсказуемый процесс.

 

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

 

Уровень 5. Оптимизируемый процесс.

 

Предсказуемый процесс непрерывно улучшается.

 

Матрица ответственности RACI.

 

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

 

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

 

ответственный (Responsible);

 

утверждающий (Accountable);

 

консультирующий (Consulting);

 

информируемый (Informed).

 

2. ITIL.

 

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

ITIL (IT Infrastructure Library) – библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

 

Библиотека ITIL появилась около 25 лет назад по заказу британского правительства. В семи томах библиотеки описан весь набор процессов, необходимых для того, чтобы обеспечить постоянное высокое качество ИТ-сервисов и повысить степень удовлетворенности пользователей. Официально данные книги носят название OGC Service Books (OGC – правительственное агентство Великобритании, выпустившее данные издания).

 

ПРИМЕР.

 

OGC Service Strategy Book. TSO (The Stationery Office), 2007.

 

Третья, выпущенная в 2007 году, редакция ITIL (с последующим обновлением в 2011) включила в себя пять основных книг, поддерживающих концепцию «жизненного цикла услуг»:

 

1. Стратегия услуг (Service Strategy).

 

2. Проектирование услуг (Service Design).

 

3. Преобразование услуг (Service Transition).

 

4. Эксплуатация услуг (Service Operation).

 

5. Постоянное улучшение услуг (Continual Service Improvement).

 

Основные положения ITIL

 

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

 

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

 

Подробнее опишем десять вышеприведенных процессов.

 

Управление инцидентами (Incident management).

 

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

 

Управление проблемами (Problem management).

 

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

 

Управление конфигурациями (Configuration management).

 

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

 

Управление изменениями (Change management).

 

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

 

Управление релизами (Release and deployment management).

 

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

 

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

 

Управление уровнем сервиса (Service level management).

 

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

 

Управление финансами (Financial management).

 

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

 

Управление мощностями (Capacity management).

 

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

 

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

 

Управление непрерывностью (Continuity management).

 

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

 

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

 

Управление доступностью (Availability management).

 

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

 

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

 

РОССИЙСКИЕ И МЕЖДУНАРОДНЫЕ СТАНДАРТЫ.

 

1. SWEBOK.

 

Одним из самых полных руководств по системной инженерии на сегодняшний день является Руководство к методическому справочнику по программной инженерии (Guide to the Software Engineering Body of Knowledge, SWEBOK). Формально данный документ не является стандартом или методологией и представляет собой использующийся тысячами компаний систематизированный справочник по основным десяти областям знаний по разработке программного обеспечения.

 

Ключевые 10 процессов (глав) SWEBOK:

 

1. Программные требования (Software requirements).

 

2. Дизайн / архитектура (Software design).

 

3. Конструирование программного обеспечения (Software construction).

 

4. Тестирование (Software testing).

 

5. Эксплуатация / поддержка программного обеспечения (Software maintenance).

 

6.  Конфигурационное управление (Software configuration management).

 

7. Управление в программной инженерии (Software engineering management).

 

8. Процессы программной инженерии (Software engineering process).

 

9. Инструменты и методы (Software engineering models and methods).

 

10.  Качество программного обеспечения (Software quality).

 

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

 

Системная инженерия (Software engineering professional practice).

 

Экономика систем (Software engineering economics).

 

Основы информатики (Computing foundations).

 

Основы математики (Mathematical foundations).

 

Основы инжиниринга систем (Engineering foundations).

 

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

 

ПРИМЕР.

 

В качестве примера рассмотрим четвертую главу SWEBOK «Тестирование ПО». В ней рассматриваются не просто процессы или активности по формированию технического проекта, но и все смежные вопросы: от основной терминологии до деталей существующих техник и методик.

 

Тестирование программного обеспечения (Software Testing).

 

1. Основы тестирования ПО (Software Testing Fundamentals).

 

1.1. Терминология тестирования (Testing-Related Terminology).

 

1.2. Ключевые аспекты (Key Issues).

 

1.3. Связь тестирования с другими активностями (Relationshops of testing with other activities).

 

2. Уровни тестирования (Test Levels).

 

2.1. Объекты тестирования (The target of the test).

 

2.2. Цели тестирования (Objectivies of Testing).

 

3. Техники тестирования (Test Techniques).

 

3.1. Техники, базирующиеся на интуиции и опыте разработчика (Based on the software engineer’s intuition and experience).

 

3.2. Техники, базирующиеся на исходных данных (Input-based techniques).

 

3.3. Техники, базирующиеся на программном коде (Code-based techniques).

 

3.4. Тестирование, базирующееся на выявлении дефектов (Fault-based techniques).

 

3.5. Техники, базирующиеся на условиях использования (Usage-based techniques).

 

3.6. Техники, базирующиеся на моделях (Model-based techniques).

 

3.7. Техники, базирующиеся на структуре приложения (Techniques based on the nature of the application).

 

3.8. Выбор и комбинация различных техник (Selecting and combining techniques).

 

4. Измерение результатов тестов (Test-related measures).

 

4.1. Оценка программы в процессе тестирования (Evaluation of the program under test, IEEE 982.1-98).

 

4.2. Оценка проведенных тестов (Evaluation of the tests performed).

 

5. Процесс тестирования (Test Process).

 

5.1. Практические соображения (Practical considerations).

 

5.2. Активности в рамках тестирования (Test Activities).

 

Таким образом, SWEBOK, изначально разработанный в рамках совместного проекта IEEE и ассоциации ACM при поддержке крупнейших компаний (SAP, Boeing, Rational Software), остается важнейшим источником систематизированной из многих первоисточников информации об активностях программной инженерии.

 

2. PMBOK.

 

Вряд ли есть менеджеры, не слышавшие о PMBoK. Свод знаний по управлению проектами (Project Management Body of Knowledge) интегрирует в себе множество аспектов, связанных с проектным управлением, основываясь на лучших мировых практиках.

 

Различные стандарты и методологии предлагают разные определения проекта:

 

Проект – предпринимаемое усилие, организующее человеческие, материальные и финансовые ресурсы в неизвестный путь в рамках уникального предмета работы, заданной спецификации, с ограничениями на затраты и время, с тем, чтобы следование стандартному жизненному циклу проекта приводило к осуществлению успешных изменений, определенных посредством количественных и качественных целей и задач. (см.: IPMA Competence Baseline. Version 2.0).

 

или

 

Проект – уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам. (см.: ISO/TR 10006 Guidelines to quality in Project Management).

 

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

 

Начинается PMBoK с описания общего жизненного цикла управления проектом и его основных групп процессов:

 

Инициация.

 

Планирование.

 

Исполнение.

 

ПРИМЕР.

 

PMBoK рассматривает следующие процессы исполнения:

 

Руководство и управление исполнением процесса.

 

Подтверждение качества.

 

Набор команды проекта.

 

Развитие команды проекта.

 

Управление команды проекта.

 

Распространение информации.

 

Управление ожиданиями заинтересованных сторон.

 

Осуществление закупок

 

Мониторинг и управление.

 

Завершение проекта.

 

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

 

Более интересны выделяемые PMBoK области знаний:

 

- управление интеграцией;

 

- управление содержанием;

 

- управление сроками;

 

- управление стоимостью;

 

- управление качеством;

 

- управление человеческими ресурсами;

- управление коммуникациями;

 

- управление рисками проекта;

 

- управление поставками;

 

- управление стейкхолдерами (область знаний, появившаяся только в 5-й версии PMBoK, опубликованной в 2013 году).

 

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

 

PRINCE2.

 

Методология управления программами / проектами в организации PRINCE2 (PRojects IN Controlled Environments) – методология, концентрирующаяся на организации, менеджменте и мониторинге хода ИТ-проектов с точки зрения продукта.

 

Окружение методологии PRINCE2 состоит из трех основных типов элементов: 7 принципов, 7 тем (далее – элементов) и 7 процессов (для каждого из которых определяются входные и выходные объекты, цели и ключевые активности).

 

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

 

1. Постоянное бизнес-обоснование.

 

2. Обучение на собственном опыте.

 

3. Определение ролей и ответственности.

 

4. Управление по стадиям.

 

5. Управление исключениями.

 

6. Фокус на продуктах.

 

7. Адаптация к условиям конкретного проекта.

 

Каждый проект должен быть целесообразен и обоснован с точки зрения соотношения: «затрат / выгод»   его реализации.

 

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

 

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

 

Планирование, мониторинг и контроль проектов на каждом этапе.

 

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

 

Определение требований к качеству результатов проекта и их характеристик.

 

Адаптация методологии в зависимости от масштабов / сложности / важности / окружения конкретного проекта.

 

Роль проектной команды в данном случае может быть описана пятью ключевыми активностями:

 

1. Адаптация семи элементов PRINCE2 к условиям проекта.

 

2. Применение / адаптация специфической терминологии.

 

3.  Адаптация описаний продукта к условиям проекта.

 

4. Адаптация описаний ролей в соответствии с PRINCE2.

 

5. Адаптация процессов для соответствия вышеописанным принципам.

 

Все эти активности и их особенности подробно описываются в тексте методологии.

 

7 основных элементов.

 

1. Бизнес-кейс (Обоснование проекта) = «Почему?».

 

Основная цель создания подобного бизнес-кейса состоит в создании механизмов оценки целесообразности (и возможности) реализации проекта.

 

2. Организация = «Кто?».

 

Определение и создание проектной структуры ответственности.

 

3. Качество = «Что?».

 

Определение методов создания качественного продукта (включая аспект контроля качества).

 

4. Риск = «Что если?».

 

Определение, оценка и контроль всех рисков.

 

5. Планы = «Как? Сколько? Когда?».

 

Определение способов создания / распространения продуктов, прогнозирование динамики спроса.

 

6. Изменения = «Какое влияние?».

 

Определение эффекта от внедрения одобренных изменений проекта.

 

7. Прогресс = «Где мы сейчас? Куда направляемся?».

 

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

 

И наконец, PRINCE2 предлагает собственную карту процессов управления проектом.

 

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

3. СЕРВИСНЫЙ ПОДХОД К ЭКСПЛУАТАЦИИ ИС.

 

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

 

Сервис (услуга) – способ предоставления ценности заказчикам посредством содействия им в получении требуемых результатов без овладения специфическими расходами и рисками (ITIL v3).

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

 

ПРИМЕР.

 

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

 

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

 

Качество (а также объем и время предоставления) услуг оговариваются заранее в виде соглашений об уровне предоставления услуг SLA – и именно под эти соглашения / условия выделяется финансирование.

 

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

 

ПРИМЕР.

 

Приведем пример некоторых метрик соглашений SLA:

 

Название сервиса: Услуги удостоверяющего центра.

 

Краткое описание: Обеспечение использования сервисов защиты информации на основе сертификатов открытых ключей (с применением шифрования и ЭЦП).

 

Доступность сервиса: 24/7/365.

 

Контрольное время реакции: 60 минут с момента регистрации инцидента.

 

Контрольное время устранения инцидента: 1 сутки с момента регистрации заявки.

 

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

 

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

 

Ответственный за сервис: ФИО, контактные данные.

 

Стоимость услуг:

 

Сервисная годовая поддержка: ___ руб.

 

Аутентификация домена в AD и на ЭТП компании: ___ руб.

 

Внутренний почтовый документооборот: ___ руб.

 

Подключение сервиса у оператора: ___ руб.

 

Дополнительные услуги:

 

Сервисная поддержка с выездом специалиста: ___ руб./час (за выезд)

 

SSL-сертификат (одно- и мульти-доменный): ___ руб. / 3 года

 

Восстановление сервиса при утрате носителя: ___ руб.

 

Подключение к VPN: ___ руб. (при подключении).

 

Говоря о качестве услуг, невозможно не упомянуть столь важный его критерий, как доступность информационной системы. Чем реже происходят отказы (в идеале – никогда!) и чем к меньшему числу часов вынужденных простоев они приводят (чем быстрее устраняются), тем выше доступность ИС. Основные методы достижения максимальной надежности системы направлены на управление тремя взаимозависимыми факторами:

 

1. Снижением вероятности отказов системы.

 

2. Уменьшение влияния этих отказов на работоспособность системы – и как следствие.

 

3. Сокращение времени простоев при отказе [2].

 

Среди факторов, влияющих на обеспечение доступности / снижение вероятности отказов системы:

 

1)   Соответствие выбранного программно-аппаратного решения специфике бизнес-процессов предприятия.

 

2)   Низкая степень сложности архитектуры системы.

 

3)   Надежность (отсутствие ошибок) программного продукта и проведенных в дальнейшем настроек.

 

4)   Минимизация риска некорректного использования системы и внесения нежелательных изменений со стороны пользователя.

 

5)   Организация регламентно-профилактического обслуживания во время эксплуатации системы для обнаружения и предотвращения ошибок.

 

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

 

ПРИМЕР.

 

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

 

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

 

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

 

Как правило, при выборе площадки для дата-центра в первую очередь обращают внимание на его стоимость эксплуатации и отказоустойчивость, однако с точки зрения ИТ важны также безопасность и энерговооруженность, так как возможности выбранной площадки дата-центра должны соответствовать задачам и потребностям самого бизнеса. Для размещения ИТ-инфраструктуры критически важных бизнес-сервисов (например, системы онлайн-процессинга операций по карточкам для банка) возможно выбрать более дорогой и надежный ЦОД уровня TIER IV (отказоустойчивость 99.995 % – простои не более 24 минут в год), ведь банк несет ответственность как перед международными системами типа Visa и Mastercard, так и своими клиентами за беспрерывное качественное предоставление сервиса обработки транзакций. В это же время для инфраструктуры остальных сервисов (например, call-центра) довольствоваться более дешевым решением TIER II с допускаемыми перерывами в работе до 22 часов в год.

 

TIER (англ. уровень) – классификация ЦОД по четырем уровням надежности.

 

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

 

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

 

Первым российским дата-центром, получившим сертификат подтверждения высшего уровня надежности TIER IV от Uptime Institute, стал ЦОД «Технопарк-Мордовия», открытый в ноябре 2013 года.

 

Существуют два основных документа, регламентирующие требования к уровням TIER:

 

1. Стандарт рекомендательного характера TIA 942 с пошаговыми инструкциями и схемами, на соответствие которым проверяется проектная документация.

 

2. Методология нормирования отказоустойчивости Uptime Institute, строгое соответствие требованиями которой как во время создания ЦОД, так и в процессе его эксплуатации необходимо для получения сертификации площадки.

 

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

 

 

СПИСОК РЕКОМЕНДОВАННОЙ ЛИТЕРАТУРЫ.

 

[1] Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. Курс лекций. Учебное пособие для студентов вузов, обучающихся по специальностям в области информационных технологий.  – М.: Интернет ун-т Информ. Технологий, 2005. – 304 с., ил.

 

[2] Зараменских Е.П. Управление жизненным циклом информационных систем: Монография – Новосибирск: Издательство ЦРНС, 2014. – 270 с.

[3] Информационные системы в экономике: Учебник. /Под ред. Г.А. Титоренко. – 2-е изд., перераб.  и доп. – М.: ЮНИТИ-ДАНА, 2008. – 463 с.

    

[4] Информационные системы и технологии в экономике и  управлении: Учебник / Под ред. проф. В.В. Трофимова. — М.: Высшее  образование, 2006.-480 с.

 

[5] Советов Б.Я., Цехановский В.В.  Информационные технологии: Учебник для вузов –  3-е изд., стер. – М.: Высш. шк., 2006. – 263 с: ил.