Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва



Скачать 101.31 Kb.
Дата29.12.2012
Размер101.31 Kb.
ТипДокументы

Секция “Стандарты и управление проектами”



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

Михайловский Николай Эрнестович

Лаборатория НТР”, Москва

nickm@ntrlab.ru

Два наиболее высокоуровневых типа стандартов предприятия в области информационных систем — стандарты, относящиеся к архитектуре и инфраструктуре информационной системы и стандарты, относящиеся к процессам ее создания. Их выбор и обоснование особенно сложны ввиду следующих объективных причин:

  1. при выборе архитектуры и инфраструктуры системы часто довольно трудно выбрать между двумя близкими решениями;

  2. при выборе процессов создания системы приходится постоянно сталкиваться с непониманием ключевыми лицами (stakeholders) необходимости тратиться на тот или иной процесс; с другой стороны, для проектов меньшего масштаба использование слишком “тяжелых” процессов не окупается.

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

1. Выбор архитектуры и инфраструктуры ИС на основе анализа рисков

1.1. Что такое архитектура ИС и инфраструктура ИС


Среди множества определений архитектуры ИС можно выделить два основных класса — определения “конструктивные” и “идеологические”.

Два основных идеологических определения архитектуры ИС таковы:

  1. “Архитектура ИС — это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой”.

  2. “Архитектура ИС — это набор ключевых решений, неизменных при изменении бизнес–технологии в рамках бизнес–видения”.

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

Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы:

  • что делает система;

  • на какие части она разделяется;

  • как эти части взаимодействуют;

  • где эти части размещены1.

Таким образом, архитектура ИС является логическим построением, или моделью. Как же она влияет на совокупную стоимость владения? Через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т.п. — то есть через то, что мы называем инфраструктурой ИС.
Еще раз подчеркну, что инфраструктура включает решения не только по программному обеспечению, но также и по аппаратному комплексу и организационному обеспечению. Это вполне соответствует пониманию системы в наиболее современных стандартах типа ISO/IEC 15288 [1].

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

1.2. Требования к методике разработки архитектуры


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

  • Фирменные методики навязывают, с разной степенью настойчивости, фирменную же архитектуру (таковы Oracle CDM и MSF).

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

Более подробно вопросы разработки архитектуры рассматриваются в традиционных методологиях разработки, основанных на каскадной модели (waterfall model). Наиболее известной методологией такого рода является метод Хэтли–Пирбхаи (Hatley–Pirbhai). Проблемами этого подхода (как и других аналогичных подходов) являются:

1) ориентированность на каскадную модель разработки;

2) ориентированность на архитектуру программной системы и дистанцирование от того факта, что система состоит не только из программных, но также и технических средств и людей;

3) разделение процессов технико–экономического обоснования системы, разработки бизнес–процессов и разработки архитектуры системы;

4)отсутствие привязки к бизнес–целям и целям использования системы.

В результате осмысления имеющихся методик нами были сформулированы следующие требования к методике разработки архитектуры:

  1. Должна отражать связь архитектуры и совокупной стоимости владения.

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

  3. Должна отражать итерационную природу разработки ИС.

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

1.3. Совокупная стоимость владения системой и риски


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

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

1) затраты на создание и эксплуатацию системы как таковой;

2) риски, возникающие в каждом процессе.

По всей видимости, с каждой из ячеек моделей типа Захмана или Зиндера [3] связаны свои специфические риски2. Этот вопрос требует дополнительной теоретической проработки. Однако и без нее можно выделить несколько наиболее практически значимых типов рисков:3

1) проектные риски при создании системы;

2) технические риски, состоящие в простоях, отказах, потере или искажении данных и т. п.;

3) риски бизнес–потери, связанные с эксплуатацией системы (возникающие в конечном счете из-за технических рисков). Такие риски бизнес–потерь назовем статическими бизнес–рисками. Каждый статический бизнес–риск принадлежит по крайней мере одному из бизнес Use case системы. Например, для Интернет–магазина бизнес–риски “Покупатель не может сделать заказ и уходит” и “Покупатель делает заказ, но уходит рассерженный функционированием системы” принадлежат бизнес Use case “Сделать заказ”.

4) риски бизнес–потери, связанные с вариативностью бизнес–процессов. При этом потери происходят оттого, что а) бизнес–процессы надо изменять, а информационная система не готова к этому и потери связаны с неоптимальным функционированием бизнеса и б) оттого, что имеется стоимость модификации системы. Такие риски бизнес–потерь назовем динамическими бизнес–рисками (RUP упоминает аналогичные по смыслу change cases — сценарии изменения).

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

Каждый бизнес Use case реализуется с помощью набора операций соответствующих бизнес процессов. Соответственно, бизнес риск возникает по причине неисполнения одной или нескольких операций бизнес–процесса — это мы называем операционными рисками. Таким образом, операционные риски являются источниками бизнес–рисков. Например, источниками риска “Покупатель не может сделать заказ и уходит” могут быть операционный риск “Информация о заказе не может быть передана для обработки в систему”.

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

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

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

1.3.1. Методика разработки архитектуры


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

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

  2. На основе описания бизнес–процессов описываются статические бизнес–риски. Каждый бизнес–риск оценивается в терминах бизнес–потерь. Это описание является параметрическим — бизнес–потери могут зависеть от продолжительности действия риска, частоты его возникновения и т. п. Критериями качества описания статических бизнес–рисков являются:

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

б) Одночленность. Если оценка бизнес–риска состоит из многих слагаемых без общих членов, то это на самом деле несколько бизнес–рисков.

  1. Уточняется описание бизнес–процессов до следующего уровня детальности. Для каждой операции этого уровня детальности строится операционный риск, как отрицание выполнения операции.

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

  3. Определяются возможные вариации бизнес–процессов. На их основе описываются динамические бизнес–риски.

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

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

  6. На основе матрицы соответствия технических рисков и бизнес–рисков оценивается часть общей стоимости владения системой, ассоциированная с бизнес–рисками.

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

  8. В качестве архитектуры системы выбирается архитектура–кандидат с минимальной оценкой совокупной стоимости владения.

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

2. Расширение для выбора процессов разработки


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

    1. Для каждого из процессов разработки рассматривается несколько вариантов его реализации.

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

    3. Выбирается реализация процесса с минимальной совокупной стоимостью владения и принимается как корпоративный стандарт.




  1. Литература

1. ISO/IEC CD 15288 FCD System Engineering -- System Life Cycle Processes, 2001.

2. Rational Unified Process 2002a, Rational Software, 2002.

3. Зиндер Е. З. "3D-предприятие" — модель трансформирующейся системы//CWR Директору информационной службы 2000. №4.

1 Этот список примерно соответствует архитектурным срезам (architectural views) RUP [2].

2 Модель Зиндера здесь интересна тем, что позволяет в одном ряду рассматривать как статические, так и динамические бизнес–риски, а также риски разработки — благодаря наличию измерения стратегического времени.

3 Знакомым с вышеуказанными моделями нетрудно будет отнести их к определенным ячейкам окружения архитектуры (architectural framework).

4 Такие характеристики обычно включаются в хорошие шаблоны business use cases.

- -

Похожие:

Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconЛекция № «Анализ и оценка рисков» Понятие анализа и оценки рисков. Методы анализа рисков
Анализ рисков включает оценку рисков и методы снижения рисков или уменьшения связанных с ним неблагоприятных последствий
Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconКак заказывать программное обеспечение? (Модель iso 15504 pulse) Н. Э. Михайловский, “Лаборатория нтр”
С другой стороны люди этой профессии, как правило, являются отличными менеджерами и хорошими специалистами в области информационных...
Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconА. С. Агапов "Лаборатория нтр", г. Москва
Модель для выбора методологии разработки программных систем на основе стандарта iso 15504
Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconРуководство по применению организационных мер безопасности и оценки рисков. Методология построения универсального дерева событий
Вновь принятые национальные стандарты, относящиеся к деятельности ОАО «Газпром», в соответствии с Информационным указателем «Национальные...
Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconЛитературная карта кузбасса
Федор Михайлович Достоевский, Николай Георгиевич Гарин Михайловский, писатель-народник Николай Иванович Наумов, поэт Василий Дмитриевич...
Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconВсероссийская олимпиада школьников по русскому языку 2011-2012
Сергей Ожегов, Соломон Михоэлс, Николай Новиков, Владимир Гиляровский, Дмитрий Писарев, Екатерина Воронцова-Дашкова, Константин Батюшков,...
Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconПроизводственная лаборатория
Производственная лаборатория создается и ликвидируется приказом директора предприятия
Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconОфис приема проб на анализ
Независимая испытательная лаборатория: Адрес: Москва, 2-ой Лихачевский пер., д. 1а. (схема проезда, фасад здания)
Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconСтандарты и управление проектами
Предлагая этот доклад, мы основываемся на собственном опыте и опыте наших коллег по созданию стандартов управления проектами уровня...
Стандарты уровня предприятия и анализ рисков Михайловский Николай Эрнестович “Лаборатория нтр”, Москва iconКомплексный анализ товарного ассортимента предприятия
В современных условиях развитой конкуренции на товарном рынке большую роль играет анализ ассортимента продукции предприятия
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org