Главная страница Случайная страница
Разделы сайта
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
Основы системной инженерии
|
|
1.2.1. Стейкхолдеры. Люди, группы и организациии, которые имеют какое-либо отношение к проекту, – стейкхолдеры (stakeholders/заинтересованные стороны). Стейкхолдеры условно делятся на " внешних" и " членов команды".
Стейкхолдеры обеспечивают возможности.
Возможности мотивируют стейкхолдеров заниматься инженерным проектом.
Возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.
Стейкхолдеры требуют согласовывать с ними определение системы
(Прежде всего, требования – определение системы как " чёрного ящика"; внутреннее устройство системы интересует далеко не всех стейкхолдеров).
Стейкхолдеры используют воплощение системы, ради создания которого затевается проект.
Простейший рабочий продукт, отражающий альфу " стейкхолдеры", – список стейкхолдеров.
Из информационных систем со стейкхолдерами работают CRM(customer relationship management / управление взаимоотношениями с клиентами).
Конфликтология (в части методов ведения переговоров с целью снять противоречия между требованиями различных стейкхолдеров.
Например – метод " принципиальных переговоров" или " гарвардский метод ").
Коммуникация (communications) для налаживания продуктивного диалога со стейкхолдерами
Техники представления стейкхолдеров (например, " метод персонажа")
https://rutracker.org/forum/viewtopic.php? t=1227489,
https://praxos.ru/index.php/%D0%98%D0%B4%D0%B5%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9%D0%90%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B5%D1%80).
1.2.2. Возможности. Инженерный проект начинается с появления возможностей (opportunity) его проведения, обстоятельств, которые делают возможным разработку (доработку – изменение) системы.
Время.
" Окно возможностей " – период времени, в течение которого существует возможность выполнения проекта.
Пользовательские потребности (user needs)
То, что хотят пользователи такого, для чего им поможет воплощенная система.
Наличие возможностей команды
Имеющиеся в распоряжении команды технологии и финансовые ресурсы.
Возможности описываются целым рядом возможных рабочих продуктов:
" Бизнес-план",
" Концепция",
" Интервью пользователей",
" Обоснование инвестиций" и т.д..
В рабочих продуктах обосновывается польза от выполнения проекта, извлекаемаястейкхолдерами.
Применяют
Маркетинг и продажи, стратегирование и предпринимательство (установление потребностей).
Управленческий (финансовый) учёт (обоснования прибыльности).
Важны не только нужды/потребности/ожидания пользователей, но и нужды /потребности /ожидания / других стейкхолдеров.
1.2.3. Воплощение системы. Воплощение системы (system realization) – это сама система.
Воплощение системы реализует возможности, отвечает нуждам/ потребностям/ ожиданиям стейкхолдеров проекта.
1.2.4. Команда. Команда (team) проекта. Люди с совершенно определённым набором компетенций (инженерных, менеджерских и других), нужных для создания системы (реализации проекта).
1.2.5. Работы. Чтобы инженерный проект был успешно реализован, команде проекта нужно провести работы (works) и отслеживать состояние этих работ в ходе всего проекта.
Учитывать работы во всём их содержательном разнообразии, чтобы ответить на вопрос " что делать"
Планировать (schedule) работы, т.е. предлагать распределение этих работ во времени и назначать исполнителей.
Определять достаточность ресурсов и контролировать выполнение плана работ.
1.2.6. Технология. Способ работы (way of working), поддержанный необходимыми рабочими продуктами и инструментами.
Практика = дисциплина+технология
Метод = полный набор дисциплин и технологий для выполнения какой-то работы.
1.2.7. Определение системы (system definition). Систему нужно определить. Определение системы имеет отдельные моменты, прежде всего:
Требования – описание назначения системы в её операционном окружении.
Требования определяют систему как " чёрный ящик ".
1.3. Состояния «альф»
Каждая альфа инженерного проекта проходит по графу состояний.
Альфа " Работа " проходит состояния:
- Инициирована (работа была запрошена).
- Подготовлена (все предусловия для начала работы выполнены).
- Начата (работа происходит).
- Под контролем (работа продвигается хорошо, риски под контролем, уровень производительности достаточен для достижения удовлетворительного результата).
- Закончена (работа по производству результата была закончена).
- Закрыта (все остающиеся служебные задачи завершены, работа официально закрыта, полученные уроки сформулированы, записаны и обсуждены).
Такая последовательность упрощает реальность. На самом деле граф состояний может иметь сложную структуру. Альфа «Работа» и другие Альфы могут проходить через состояния циклически, какие-то состояния могут пропускаться, могут существовать альтернативные пути.
 |
Стадии ЖЦ показаны разными оттенками зелёного:
- разработка концепции,
- разработка системы,
- усиление системы,
- сопровождение/обслуживание системы).
Практики – секторы круга. Практики последовательно выполняются на каждом витке спирали: " водопад".
Ключевая предпосылка " водопада" – практики совпадают со стадиями ЖЦ.
Проектирование – это и практика, и стадия ЖЦ.
Тестирование – это и практика, и стадия ЖЦ.
 |
В 2001 году группа программистов предложила Agile manifesto https://agilemanifesto.org
Agile (быстрый и гибкий) – манифест разработки программного обеспечения
Занимаясь разработкой мы постоянно открываем для себя более совершенные методы разработки.
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Манифест полностью разделял стадии ЖЦ и практики, установил " гибкость" в планировании работ, исключил " водопад" в любых его проявлениях.
В системной инженерии " железных" систем методы agile пока используются мало.
В существенной мере действует " водопадная" модель.
Временной лаг: модные в программной инженерии идеи попадают в системную инженерию с задержкой в примерно 10-15 лет.
Сейчас ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы те же практики, которые хорошо зарекомендовали себя при разработке программного обеспечения.
Какие-то agile элементы в системной инженерии возможны.
Воплощение системы обычно проходит в стиле " водопада": если хорошо проработан проект, и имеется большой опыт создания аналогичных систем, то неожиданностей и " возвратов назад" в проекте будет мало, сборка проходит в точном соответствии с планом, испытания проходят с первого раза.
Вместо водопадных и agile стилей предложено:
https://csse.usc.edu/csse/TECHRPTS/2009/usc-csse-2009-502/usc-csse-2009-502.pdf
различать паттерны:
- Купи готовое (Use Single NDI),
- Гибкий (Agile),
- Гибкий с архитектурой (Architected Agile),
- Формальные методы (Formal Methods),
- Оборудование с программными компонентами (Hardware with embedded Software component),
- Неделимость для начала эксплуатации (Indivisible Initial Operational Capability),
- Много закупок (NDI-intensive) – проектирование (в отличие от конструирования)
- Гибрид гибкости и плана (Hybrid agile/plan-driven system),
- Много собственников в системе систем (Multiowner system of systems),
- Семейство систем (Family of systems),
- Brownfield (модернизация)
- Акцент на сервисах (Services-Intensive)
Нет никакой возможности обойтись одним и тем же вариантом ЖЦ для разных типов проектов. Каждый проект должен получить свой индивидуальный метод разработки, индивидуальную модель ЖЦ.
При повторении одного и того же проекта ЖЦ будут разные:
- первое выполнение проекта даст ответы на многие вопросы по рискам
- приобретённый опыт позволит изменить вид ЖЦ для второго проекта в их серии.
Задача управления ЖЦ заключается не только в том, чтобы альфы воплощения и определения системы продвигались по своим состояниям, но и в синхронизации достижения состояний всех основных альф инженерного проекта.
Синхронизация состояний альф кладётся в основу планирования работ по проекту.
В план работ включаются и работы по не инженерным альфам (в инженерных проектах очень часто существенно не хватает менеджерских работ, возникает перегрузка менеджеров, операционистов, и специалистов, работающих с клиентами).
Определение ЖЦ отслеживается в ходе инженерного проекта. ЖЦ – объект, который следует рассматривать в качестве:
- подальфы альфы " Определения системы" (определение ЖЦ связано в существенной мере с «Работой»),
- подальфы альфы " Работы" (ЖЦ лежит в основе работ по планированию проекта),
- подальфы альфы " Технологии" (вид ЖЦ определяет используемые практики).
1.4.Жизненный цикл системы. (ISO 15288. Системная инженерия: процессы ЖЦ систем /Приложение D).
1.4.1. Концепции ЖЦ. Каждая система имеет свой ЖЦ. ЖЦ может быть описан с использованием абстрактной функциональной модели (см. стандарт IDEF0 ), представляющей концептуализацию потребности в системе, ее реализации, применения, развития и ликвидации.
Модель ЖЦ. Система развивается на протяжении ЖЦ в результате действий, осуществляемых и управляемых людьми, работающими в организациях и использующими определенные процессы в своей деятельности.
Детали модели ЖЦ выражаются в терминах этих процессов, их результатов, взаимосвязи и возникновения. Стандарт определяет множество процессов, названных процессами ЖЦ, при помощи которых может быть смоделирован ЖЦ системы.
Стадии ЖЦ. ЖЦ различаются по свойствам, целям, использованию системы, а также по преобладающим условиям. Несмотря на очевидное множество различий в ЖЦ систем, существует базовый набор стадий ЖЦ, составляющих полный ЖЦ любой системы.
Компьютерное сопровождение жизненного цикла изделий
Идеология компьютерного сопровождения жизненного цикла изделий военного назначения (CALS) зародилась по инициативе министерства обороны США в середине 80-х годов. Тогда эта аббревиатура расшифровывалась как компьютеризированная поддержка процессов материально-технического обеспечения — Computer-Aided Logistics Support (компьютеризированная логистическая поддержка).
CALS-технология изначально предназначалась для
повышения эффективности управления и сокращения затрат на информационное взаимодействие между государственными учреждениями и коммерческими предприятиями в процессах заказа, поставок и эксплуатации средств вооружения и военной техники (ВВТ).
На начальных этапах разработки и внедрения CALS-технологии было организовано единое информационное пространство, обеспечивающее оперативный обмен данными между заказчиками, производителями и потребителями ВВТ, а также повышение управляемости, сокращение бумажного документооборота и связанных с ним затрат.
Концепция CALS изначально базировалась на идеологии ЖЦ средств ВВТ и охватывала в основном фазы производства и эксплуатации.
Доказав свою эффективность, концепция CALS начала активно применяться в промышленности, строительстве, транспорте и других отраслях экономики, расширяясь и охватывая все этапы жизненного цикла наукоемкой продукции — от замысла до утилизации.
В 1988 году с CALS были сняты типично военные ограничения и она стала называться Computer-Aided Acquisition and Support — «компьютеризированные поставки и материально-техническое обеспечение». В этом варианте была усилена организационная направленность CALS.
Концепция, появившаяся в 1993 году, сохранила существующую аббревиатуру CALS, но получила более широкую трактовку — Continuous Acquisition and Life-cycle Support (бесперебойные поставки и поддержка жизненного цикла).
В новом названии учитывалась методология параллельного проектирования, интегрированной логистической поддержки, управления конфигурацией и управления документопотоком. Это позволило интегрировать процессы на всем протяжении жизненного цикла изделий от выражения потребности в изделии до его утилизации.
CALS иногда называют «бизнесом в высоком темпе» (Commerce At Light Speed), чем подчеркивается переориентация этих технологий в направлении информационных магистралей и электронной коммерции.
Идея, изначально связанная только с поддержкой логистических систем, превратилась в глобальную стратегию перехода на безбумажную электронную технологию, повышающую эффективность процессов жизненного цикла изделий за счет совместного использования информации на всех его этапах.
Сегодня CALS — это стратегия правительства и промышленности, направленная на эффективное создание, обмен и использование электронных данных, обеспечивающая управление жизненным циклом изделия с помощью международных стандартов, реорганизации предпринимательской деятельности и передовых информационных технологий.
Компьютерное сопровождения процессов ЖЦ изделий — Continuous Acquisition and Life Cycle Support (CALS) – бесперебойные поставки и поддержка ЖЦ.
CALS-технологии внедряются в различных отраслях промышленности.
Русскоязычное название технологии CALS: технология информационного сопровождения и поддержки этапов ЖЦ наукоемких изделий (сокращенно — ИПИ-технология). CALS следует понимать как компьютерное сопровождение процессов жизненного цикла изделий.
Каждая стадия имеет определенную цель и вклад в полный ЖЦ и рассматривается при планировании и выполнении ЖЦ системы.
Стадии представляют собой основные периоды ЖЦ, связанные с системой и относящиеся к состоянию описания системы или непосредственно к системе.
Стадии отображают значимый прогресс и достижение запланированных этапов развития системы на протяжении всего ЖЦ и дают начало важнейшим решениям относительно своих входов и выходов. Эти решения используются организациями для учета неопределенностей и рисков, непосредственно связанных с затратами, сроками и функциональностью при создании или применении системы.
Стадии обеспечивают организации структурой работ, в рамках которых управление предприятием обладает высокой способностью для обзора и контроля проекта и технических процессов.
Организации проходят стадии ЖЦ различными способами, устраняя противоречия между стратегией осуществления бизнеса и стратегией уменьшения рисков.
Параллельное прохождение стадий или их прохождение в различном порядке может привести к формам ЖЦ с совершенно разными характеристиками.
Часто в качестве альтернативных вариантов используются последовательная, инкрементная или эволюционная формы ЖЦ; в отдельных случаях могут быть разработаны комбинации этих форм.
Выбор и разработка организацией конкретных форм ЖЦ зависят от ряда факторов, включая бизнес-контекст, природу и сложность системы, стабильность требований, технологические возможности, потребность в различных системных возможностях во времени и наличие бюджетных средств и ресурсов.
Аналогично тому, как все системные элементы осуществляют вклад в систему как в единое целое, так и каждая стадия ЖЦ должна учитываться на любой другой ее стадии. Участвующие стороны должны координировать свои действия и кооперироваться друг с другом на протяжении всего жизненного цикла.
Синергия стадий ЖЦ и сторон, вкладывающих средства в реализацию функциональностей на этих стадиях, является необходимой для успешного осуществления проектных мероприятий. Тесная связь и, по возможности, единение проектных команд, различных функций и организаций, ответственных за другие стадии ЖЦ, приводят к логичности и согласованности ЖЦ.
1.4.2. Стадии рассматриваемой системы и обеспечивающих ее систем. Каждая обеспечивающая система (как и любая система) имеет свой собственный ЖЦ. Каждый ЖЦ привязывается и синхронизируется с циклом рассматриваемой системы. Например, если рассматриваемая система еще не существует, то требования к обеспечивающей системе определяются на стадии планирования рассматриваемой системы (или позднее, если позволяют сроки), когда обеспечивающая система используется для предоставления конкретных услуг рассматриваемой системе (см. рисунок D.6, Приложение D, ISO 15288).
Обеспечивающая система может существовать еще до появления рассматриваемой системы, то есть быть фактической составляющей инфраструктуры организации, ответственной за рассматриваемую систему, или существовать в организации поставщика. В этом случае существующие обеспечивающие системы могут налагать дополнительные ограничения на рассматриваемую систему.
Каждую обеспечивающую систему можно представлять как рассматриваемую систему, которая, в свою очередь, может иметь свои обеспечивающие системы. ISO 15288 может применяться и для обеспечивающих систем.
Управление ЖЦ охватывает инженерные практики, практики маркетинга /стратегирования, практики менеджерские.
Каждый процесс ЖЦ при необходимости может быть начат в любой момент ЖЦ, при этом нет определенного порядка в использовании процессов.
Любой процесс может выполняться одновременно с любыми другими процессами ЖЦ и может быть реализован на любом уровне иерархии структуры системы.
Процессы ЖЦ распространяются на любой уровень системной иерархии и на любую стадию ЖЦ.
Процессы ЖЦ основываются на принципах модульности (максимальная слаженность функций процесса и минимальная связь между процессами) и собственности (процесс связывается с ответственностью).
Функции, которые осуществляются данными процессами, определяются в зависимости от конкретных целей, результатов и набора действий, составляющих данный процесс.
Процессы не препятствуют и не исключают использование дополнительных процессов, которые организация посчитает полезными.
1.4.3. Ответственность и соглашения внутри и между организациями. Организации различают разные области управленческой ответственности и действий. Взятые вместе, эти области вносят вклад в способность организации продвигать свою продукцию на рынок.
В стандарте используется модель процессов, основанная на трех основных областях (уровнях) ответственности (рис.D7, приложение D, ISO 15288):
- ответственность предприятия,
- ответственность проекта,
- техническая ответственность.
В рамках каждой организации скоординированное множество процессов предприятия, проектных и технических процессов способствует эффективному созданию и использованию систем, содействуя, таким образом, достижению целей организации.
Различные организации и различные области ответственности внутри организации устанавливают между собой рабочие взаимоотношения и подтверждают свою ответственность путем заключения соглашений.
Организации одновременно или поочередно выступают и как приобретатели, и как поставщики систем. На рис. D.7 вертикальные отношения организаций А и В могут рассматриваться как отношения организаций-поставщиков, осуществляющих торговлю в течение одного этапа жизненного цикла. Аналогично отношения организаций А и С могут представлять отношения организаций, последовательно принимающих ответственность за осуществление стадий жизненного цикла.
Соглашения унифицируют и координируют вклады, сделанные различными областями ответственности с целью достижения общих бизнес-целей.
Процессы заключения соглашения. Организации являются производителями и потребителями систем. Они торгуют продуктами и услугами. Одна организация может, выступая в качестве приобретающей стороны, ставить задачу другой организации, выполняющей роль поставщика продуктов или услуг, что достигается путем соглашений между ними.
Процессы заключения соглашений могут применяться с меньшими формальностями, если приобретающая сторона и поставщик принадлежат одной организации. Подобным же образом эти процессы могут использоваться в рамках организации для согласования распределения ответственностей на уровне предприятия, проекта и технических функций.
1.4.4. Процессы предприятия. Процессы предприятия связаны с гарантиями того, что потребности и ожидания заинтересованных сторон, взаимодействующих с организацией, будут удовлетворены.
На стратегическом уровне процессы предприятия связаны:
- с управлением и совершенствованием бизнеса или обязательств организации,
- с обеспечением и развертыванием ресурсов и активов.
- с управлением рисками в конкурентных или неопределенных ситуациях.
Ответственность за эти процессы обычно несет высший уровень организации. Процессы предприятия создают устойчивый имидж предприятия для многих организаций и подразумевают в качестве движущей силы коммерческий успех или прибыль.
Стандарт может применяться как бесприбыльными, так и создающими прибыль организациями. Процессы предприятия в равной степени относятся и к бесприбыльным организациям, поскольку эти организации также подотчетны заинтересованным сторонам, ответственны за ресурсы и сталкиваются с рисками в своей деятельности.
1.4.5. Процессы проекта. Процессы проекта связаны с управлением ресурсами и активами, распределяемыми управленческим персоналом предприятия, и с их использованием для безусловного выполнения соглашений, заключенных организацией.
Они относятся к управлению проектами:
- к планированию в терминах затрат, сроков выполнения и достижения результатов,
- к контролю мероприятий для гарантии того, что они соответствуют планам и техническим критериям,
- к определению и выбору корректирующих действий, устраняющих задержки в развитии и недостатки в достижениях.
Обычно в одной организации может осуществляться сразу несколько проектов.
Процессы проекта могут использоваться для обеспечения инфраструктуры организации на корпоративном уровне, например, оборудования, обеспечивающих служб, технологической базы.
1.4.6. Технические процессы. Технические процессы связаны с техническими мероприятиями, проводимыми в течение ЖЦ. Они преобразуют потребности правообладателей сначала в продукт, а затем, используя данный продукт, обеспечивают устойчивую реализацию услуги тогда и там, где это необходимо, с целью удовлетворения заказчика.
Технические процессы применяются для создания и использования системы независимо от того, представлена ли она в виде модели или в виде конечного продукта. Технические процессы применяются на любом уровне иерархии структуры системы.
1.4.7. Применение процессов. Каждый процесс ЖЦ (см. рис. D.8 Приложения D, ISO 15288) может быть инициирован при необходимости в любой момент ЖЦ, причем не существует фиксированных правил его использования.
Подробности задач и сроки применения этих процессов на протяжении ЖЦ зависят от множества факторов, включая социальные, торговые, организационные и технические факторы, каждый из которых может изменяться в течение ЖЦ системы. Отдельный ЖЦ системы является сложной системой процессов, обычно обладающих параллельными, итеративными, рекурсивными и зависящими от времени характеристиками.
Процессы могут выполняться параллельно в рамках проекта (например, проектные действия и действия по подготовке к созданию системы выполняются одновременно) или между проектами, например, когда системные элементы разрабатываются одновременно в различных проектах.
Итеративное использование процессов, то есть повторное применение процесса или множества процессов на одном уровне иерархии, имеет важное значение для постоянного уточнения результатов процесса.Например взаимодействие между последовательными действиями по верификации и действиями по комплексированию может постепенно укреплять уверенность в соответствии продукта предъявленным требованиям.
Рекурсивное использование процессов, то есть повторное применение одного и того же процесса или множества процессов к последовательным уровням детализации иерархической структуры системы, является ключевым аспектом применения стандарта. Результаты процессов на любом уровне, будь то информация, артефакты или услуги, являются входами для таких же процессов, но реализуемых на более низком или более высоком уровнях. В итоге возникает ответная информация, артефакты или услуги, которые могут модифицировать первоначальный выход процесса.
Результаты процессов, полученные на всех уровнях системной архитектуры, могут быть согласованы и совместимость их достигнута, например, в виде описаний системных элементов, формирующих системную архитектуру.
Изменяющийся характер воздействий на систему (например, изменения среды функционирования, новые возможности реализации системных элементов, модифицированная структура и обязанности в организациях) требует постоянной проверки выбора и синхронизации использования процессов. Таким образом, применение процесса в течение ЖЦ является интенсивно меняющимся во времени действием, реагирующим на множество внешних воздействий на систему.
Стадии ЖЦ помогают при планировании, выполнении и управлении процессами ЖЦ, несмотря на их сложность, обеспечивая достижимые и распознаваемые цели и структуру на высоком уровне. В частности, предшествующий опыт работы на аналогичных рынках или в аналогичных производственных секторах может помочь в выборе стадий и применении процессов ЖЦ для построения соответствующей и эффективной модели ЖЦ для любой системы.
Пример: стандарт CobiT
В состав стандарта входят шесть книг:
1. Резюме для руководителя. Для TOP -менеджеров, принимающих решение о применимости стандарта в организации. Описание стандарта CobiT (инструменты для внедрения стандарта): обзор; опыт; примеры; контроль понимания; диагностика ИТ-контроля. На русском языке: https://www.isaca.ru.
2. Описание структуры. Развернутое описание структуры стандарта и целей высокого уровня, поддерживающих навигацию и эффективную работу со стандартом.
3. Объекты контроля. Детальные описания объектов управления и контроля.
4. Принципы управления. Для руководителей ИТ-служб. Ответы на вопросы: управления ИТ; постановки целей; достижения целей; контроля полноты и завершенности решений. Главные моменты: модели зрелости; КФУ (критические факторы успеха); КИЦ (критические индикаторы цели); КИР (ключевые индикаторы результата).
5. Принципы аудита. Для внутренних и внешних аудиторов ИТ, для консультантов в сфере ИТ. Правила проведения ИТ-аудита. Ответы на вопросы: источники информации; способы проверки информации.
6. Набор инструментов внедрения стандарта. Для внутренних и внешних аудиторов ИТ, для консультантов в сфере ИТ. Рекомендации по практическому использованию стандарта в управлении и аудите ИТ.
CobiT: единый подход к сбору и анализу информации, подготовке выводов и заключений на всех этапах управления, контроля и аудита ИТ; бенчмаркинг ИТ-процессов с " лучшими" практиками (в том числе отраслевыми).
CobiT должен обеспечить соответствие ИТ требованиям бизнеса. Ресурсы ИТ управляются бизнес-процессами.
CobiT обеспечивает управление и контроль на высшем уровне - 34 цели. Одна цель на один ИТ-процесс
Все ИТ-процессы образуют 4 домена:
Планирование и Организация; Проектирование и Внедрение; Эксплуатация и Сопровождение; Мониторинг.
На этой базе создается адекватная система контроля ИТ-среды.
Система учитывает задействованные ресурсы ИТ. Аудиторам необходимо оценить ИТ.
CobiT предлагает семь информационных критериев:
1. Эффективность - актуальность информации для соответствующего бизнес-процесса, гарантия своевременного и регулярного получения правильной информации
2. Продуктивность - доступность информации благодаря оптимальному применению ресурсов
3. Конфиденциальность - защита информации от неавторизованного использования
4. Целостность - точность, полнота, достоверность информации в оценках бизнеса
5. Пригодность - предоставление информации по требованию бизнес-процессов
6. Согласованность - соответствие законам, правилам и договорным обязательствам
7. Надежность — доступ руководства организации к информации, необходимой для текущей деятельности, создания финансовых отчетов, оценки степени соответствия.
ИТ-ресурсы генерируют информацию для принятия решений на уровне бизнес-процессов. ИТ-ресурсы должны соответствовать требованиям бизнеса.
1. Работники – компетенции, навыки в сфере ИТ
2. Приложения - автоматизированные и «ручные» процедуры
3. Технологии – Hard, Soft, операционные системы, СУБД, средства сетевого управления, multimedia
4. Оборудование – ресурсы разработки и поддержки ИТ
5. Данные - внутренние и внешние, структурированные и неструктурированные, видео- аудио и т.д.
|
|