Механизм интеграции

Моделирование бизнеса — IDEF, UML, ARIS

Классификация моделей

Понятие модели

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

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

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

Модель внешнего вида часов
модель внешнего вида часов
Структурная схема часов
структурная схема часов

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

Процесс моделирования имеет свойство динамичности: модели развиваются, уточняются, переходят одна в другую.

Классификация моделей

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

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

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

Классификация моделей материальные абстрактные
Материальные модели построены из реальных объектов.
Абстрактные модели — это идеальные конструкции, выполненные средствами мышления, сознания.

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

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

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

Языки описания моделей

Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические.

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

Требования к нотации:

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

Содержание модели бизнеса

В модели бизнеса отражают:

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

Методы моделирования бизнеса

Структурные методы

Структурные методы
Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.

Принципы структурного подхода:

  • «разделяй и властвуй» — разбиение сложных проблем на множество меньших задач, легких для понимания и решения;
  • иерархическое упорядочивание – организация составных частей проблемы в иерархические древовидные структуры.

Две группы методов: моделирующие функциональную структуру и структуру данных

Наибольшее распространение получили методологии:

  • IDEF0 – функциональные модели, основанные на методе SADT;
  • IDEF1X – диаграммы данных «сущность-связь» (ERD);
  • IDEF3 — диаграммы потоков работ (Work Flow Diagrams);
  • DFD — диаграммы потоков данных (Data Flow Diagrams).

Методы объектно-ориентированного моделирования

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

Наиболее известные методы:

  • Booch’93 Г. Буча,
  • OMT Дж. Румбаха
  • OOSE А. Джекобсона
  • UML (Unified Modeling Language) – на основе Booch’93, OMT, OOSE

Главным структурообразующим элементом является объект.
В программировании объект — это структура, объединяющая данные и процедуры.
В модели бизнеса объекты – это участники бизнес-процесса (активные объекты) и пассивные объекты (материалы, документы), над которыми выполняют действия активные объекты.

Методы имитационного моделирования

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

Наиболее распространенные методы:

  • сети Петри и раскрашенные сети Петри (CPN, Colored Petri Nets);
  • GPSS (General Purpose Simulating System) – унифицированный язык имитационного моделирования;
  • SIMAN (SIMulation ANalysis) – язык визуального моделирования.

Интегрированные методы

Интегрированные методы
Интегрированные методы моделирования объединяют различные виды моделей – структурного анализа, объектно-ориентированные, имитационные и др.

  • ARIS (Architecture of Integrated Information System) позволяет отражать в единой интегрированной модели: оргструктуры, функции, данные, процессы. Использует множество типов моделей.
  • G2 — методология создания динамических интеллектуальных систем позволяет моделировать процессы с использованием знаний эксперта.
  • BRM (Business Rules Management) – методология управления бизнес-правилами.

Структурные методологии

Методология IDEF0

Методология IDEF0
Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований.
IDEF0-модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).

Основные элементы модели:

  • Функциональный блок (Activity) – преобразование (активность);
  • Выходы (Output) – результат преобразования;
  • Входы (Input) — объекты, которые преобразуются в Выходы;
  • Управление (Control) — информация, как происходит преобразование;
  • Механизм (Mechanism) – объекты, осуществляющие преобразование.

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

  • I (Input),
  • C (Control),
  • O (Output) и
  • M (Mechanism).

Типы связей между блоками:
Выход-вход
Выход-вход
Выход-управление
Выход-управление
Выход-механизм
Выход-механизм
Обратная связь по управлению
Обратная связь по управлению
Обратная связь по входу
Обратная связь по входу

Методология IDEF3

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

Выделяют четыре элемента IDEF3-модели:
Единицы работ (Unit of work) IDEF3 Единица работы — отображают действия, процессы, события, этапы выполнения работ. Единица работы может иметь только один вход и один выход

Ссылки (Referents):
необходимые элементы для выполнения процесса (сырье, материалы);
результат процесса (изделие);
активаторы процесса (клиент, поставщик).
Ссылки (Referents) idef3

Связи (Links), которые бывают двух типов:
передают действия от одной единицы работ к другой
Связи (Links) idef3
соединяют ссылку с единицей работ (активируют единицу работ)
Связи (Links) idef3

Перекрестки (Junctions) – элементы модели, за счет которых описывается логика и последовательность выполнения этапов процесса.
Бывают двух видов:
перекрестки слияния – Fan-in
перекрестки слияния – Fan-in idef3
перекрестки ветвления – Fan-out
перекрестки ветвления – Fan-out

Типы перекрестков

Асинхронное И (Asynchronous AND)
выходной процесс запустится, если завершились все входные процессы
26_asynchronous_and_zavershilis_vse_vhodnie
после завершения входного процесса запустятся все выходные процессы
Асинхронное И (Asynchronous AND)

Синхронное И (Synchronous AND)
выходной процесс запустится, если завершились одновременно все входные процессы
Синхронное И (Synchronous AND)
после завершения входного процесса запустятся все выходные процессы, причем запустятся одновременно
Синхронное И (Synchronous AND)

Асинхронное ИЛИ (Asynchronous OR)
выходной процесс запустится, если завершится один или несколько входных процессов
Асинхронное ИЛИ (Asynchronous OR)
после завершения входного процесса запустятся один или несколько выходных процессов
Асинхронное ИЛИ (Asynchronous OR)

Синхронное ИЛИ (Synchronous OR)
выходной процесс запустится, если завершились один или несколько входных процессов, причем завершились одновременно
Синхронное ИЛИ (Synchronous OR)
после завершения входного процесса запустится один или несколько выходных процессов, причем запустятся одновременно
Синхронное ИЛИ (Synchronous OR)

Исключающее ИЛИ (XOR, Exclusive OR)
выходной процесс запустится, если завершился только один входной процесс
34_XOR_Exclusive_OR_input
после завершения входного процесса запустится только один выходной процесс
Исключающее ИЛИ (XOR, Exclusive OR)

Пример IDEF3

Пример IDEF3

Правила создания перекрестков

  1. Каждому перекрестку слияния должен предшествовать перекресток ветвления.
  2. Перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ».
  3. Перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И».
  4. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
  5. Перекресток не может быть одновременно перекрестком слияния и ветвления. В ситуации, когда необходимо одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков.

Правило относительно единиц работ

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

Номер работы А13.1.2 означает:
родительская работа имеет код А13,
номер декомпозиции – 1
номер работы на текущей диаграмме – 2.

Методология DFD

Диаграммы потоков данных DFD позволяют эффективно и наглядно описать процессы документооборота и обработки информации.
Используются две нотации: Йордана и Гейна-Сарсона

Типы структурных элементов (в нотации Гейна-Сарсона):
1. Процессы (функции, операции, действия), которые обрабатывают и изменяют информацию. Процессы показывают, каким образом входные потоки данных преобразуются в выходные
Методология DFD Процессы
2. Потоки данных, которые обозначают взаимодействие процессов с внешним миром и между собой. Поток данных соединяет выход процесса (объекта) с входом другого процесса (объекта).
Поток данных соединяет выход процесса (объекта) с входом другого процесса (объекта)
3. Хранилища данных — представляют собой собственно данные, к которым осуществляется доступ. Эти данные могут быть созданы или изменены процессами.
Хранилища данных - представляют собой собственно данные, к которым осуществляется доступ.
4. Внешние сущности — определяют внешние элементы, которые участвуют в процессе обмена информацией с системой. Внешние сущности изображают входы в систему (источники информации) и/или выходы из системы (приемники информации). Примеры: заказчик, персонал, поставщик, клиент, склад, банк
Внешние сущности - определяют внешние элементы, которые участвуют в процессе обмена информацией с системой

Пример:
Методология DFD пример

Объектно-ориентированный язык UML

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

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

Прецедентная модель бизнеса

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

Актор (действующее лицо, business actor) — субъект окружения бизнеса. Примеры акторов: Клиент, Покупатель, Поставщик, Партнер, Акционер, Заказчик.
Актор (действующее лицо, business actor)

Прецедент (вариант использования, business use case) — относительно законченная последовательность действий в рамках некоторого бизнес-процесса, приносящая ощутимый результат конкретному актору .
Примеры прецедентов: Производство продукта Продажа продукта, Сервисное обслуживание, Разработка продукта, Маркетинг и сбыт.
Прецедент (вариант использования, business use case)

Экземпляр (реализация) прецедента – конкретный вариант хода событий класс прецедентов — обобщенный прецедент.

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

Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate).
Они моделируют взаимосвязи прецедентов с окружением (информационные и материальные потоки)
Между прецедентами, как правило, устанавливаются только отношения зависимости а также отношения, структурирующие прецеденты – отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend).
отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend)

Для каждого из элементов модели составляется спецификация.
В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.

В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов

Поток событий прецедента

Поток событий — описание прецедентов последовательностью шагов

Поток событий прецедента «Продажа продукта»:

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

Диаграмма деятельности (Activity Diagram)

Диаграмма деятельности (Activity diagram)

Элементы диаграммы деятельности

Элементы диаграммы деятельности

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

Структурирование прецедентов

Чтобы упростить описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования.
1. Выделение фрагментов
Если из описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент. Между выделенным прецедентом и базовым устанавливается отношения включения (include).
Иногда используют отношение расширения (extend). Оно устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях.

2. Обобщение
Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский). Между каждым из частных прецедентов и родительским устанавливается отношение обобщения (generali-zation).

Объектная модель бизнес-процесса

Раскрывает внутреннее устройство бизнеса: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют.
Классы объектов модели бизнеса:
активные — исполнители процессов (стереотип business worker), например, Продавец, Изготовитель, Разработчик;
53_uml_aktivnie_klassi
пассивные — сущности (стереотип business entity), например, Продукт, Заказ, Счет.
пассивные - сущности (стереотип business entity)

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

Классы и объекты

Класс – некоторый тип объектов (множество похожих объектов),
Экземпляр – конкретный объект (представитель класса).
Экземпляр – конкретный объект (представитель класса)

Объекты имеют:
имя (через двоеточие может быть указано имя класса)
свойства — описываются с помощью атрибутов
поведение — представляется с помощью операций

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

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

Динамическая диаграмма взаимодействия

Прецедент «Продажа заказного продукта»:
Продавец получает заявку клиента
Продавец формирует заказ и передает его Изготовителю продукта.
Изготовитель изготавливает продукт.
Изготовитель отправляет продукт на Склад и сообщает о готовности Продавцу.
Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату.
Продавец сообщает Отправителю адрес клиента и заказывает транспорт.
Отправитель получает продукт со склада и доставляет его клиенту.
Динамическая диаграмма взаимодействия

Элементы диаграммы последовательности

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

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

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

Статическая диаграмма взаимодействия

Диаграмма кооперации (Collaboration Diagram)
Статическая диаграмма взаимодействия

Диаграмма классов

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

Описание объектов

Спецификация объекта состоит из описания свойств (атрибутов) и поведения (обязательств, операций).
Спецификация объекта состоит из описания свойств (атрибутов) и поведения (обязательств, операций).

Интегрированная методология ARIS


Методология ARIS (Architecture of Integrated Information System) разработана в 1990-х годах профессором А.-В. Шеером
Интегрированная методология ARIS
Для каждого из этих представлений можно построить несколько типов моделей (в ARIS 5.0 общее количество типов диаграмм — 130)

Выделено четыре основных вида моделей (четыре представления):

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

Организационная схема

К организационным моделям относится Организационная схема (Organizational chat).
Основные типы объектов этой модели:
Организационная схема (Organizational chat)

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

Дерево функций

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

Событийная цепочка процесса

К моделям процессов/управления относится Диаграмма eEPC (extended Event driven Process Chain)
К моделям процессов/управления относится Диаграмма eEPC (extended Event driven Process Chain)
Основные типы объектов:
67_aris_diagram_eEPC_tipi_objectov

Элементы диаграммы eEPC

  • Функция – некоторое (шаг процесса). С функцией могут быть связаны: исполнители, входные и выходные документы, программное обеспечение и т.д.
  • Событие — какое-либо завершенное состояние объекта, которое влияет на дальнейший ход процесса. С одной стороны события являются стимулом к выполнению функций, с другой – их результатом.
  • Логические операторы (И, ИЛИ, XOR) показывают разветвления в потоке процесса.

Примеры:
Элементы диаграммы eEPC

Интеграция моделей

Взаимосвязь моделей ARIS обеспечивается с помощью двух механизмов: интеграции и детализации
1. Механизм интеграции
Благодаря хранению объектов в едином репозитории (специальной базе данных).
При создании нового объекта в репозитарии появляется отдельная запись, задающая описание объекта.
Объект можно скопировать из одной модели и вставить в другую с помощью команд Copy/Paste.
Механизм интеграции

Детализация моделей

2. Механизм детализации: для объектов текущей модели можно задавать ссылки на другие модели, являющиеся подробным описанием этого объекта.
Типы детализации, разрешенные к использованию, зависят от типа объекта
70_aris_detalizaciya_modeley

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

Инструментальные средства

Возможности инструментальных средств

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

Использованная литература

1. Национальный исследовательский Томский политехнический университет. Томск. Силич В.А. 2016. 75 с. Презентация к лекции.


Зрелость аналитических данных

Зрелость аналитических данных

Что такое отчет и что такое анализ

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

Отчет показывает, что произошло: в четверг в 10:03 на сайте наблюдалось максимальное число посетителей – 63 000 человек. Он дает конкретные цифры.
Анализ показывает, почему это произошло: в 10:01 о компании упомянули в ТВ шоу 60 Minutes, – и рекомендует, что компании следует делать, чтобы оставаться примерно на этом же уровне.

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

Гипотетические основные вопросы, на которые отвечает аналитика, по Дэвенпорту. Пункт D представляет собой ценную аналитику, пункты E и F обеспечивают управление на основе данных, если эта информация стимулирует конкретные действия (подробнее об этом ниже).
аналитика по Дэвенпорту

В нижнем ряду таблицы отражены действия, приводящие к выводам. Составление отчетов (А) и оповещение (В) – не управление на основе данных: они отмечают, что уже произошло или что необычное или нежелательное происходит сейчас, но при этом не дают объяснений, почему это произошло или происходит, и не дают рекомендаций по улучшению ситуации. Предвестником управления на основе данных служит дальнейшее изучение причинно следственных связей с помощью моделей или экспериментов (D). Только понимая причины произошедшего, можно сформулировать план действий или рекомендации (Е). Пункты E и F обеспечивают управление на основе данных, но только если полученная информация стимулирует конкретные действия.
Пункт С представляет собой опасную зону, поскольку слишком велик соблазн распространить существующий тренд на будущее: в Excel выберите «Диаграмма» (Chart), нажмите «Добавить линию тренда» (Add trendline) – и вот вы уже экстраполировали текущие данные на другие ячейки и делаете необоснованные прогнозы. Даже при обдуманном выборе функциональной формы модели может быть множество причин, почему этот прогноз ошибочен. Для уверенности в прогнозах следует использовать модель учета причинно следственных связей.

Уровни аналитических данных (Зрелость аналитических данных)

В 2009 году Джим Дэвис, старший вице президент и директор по маркетингу SAS Institute, выделил восемь уровней аналитических данных.

Стандартные отчеты

Что произошло? Когда произошло? Например, ежемесячные финансовые отчеты.

Ad hoc отчеты

Как много? Как часто? Например, специальные отчеты.

Детализация по запросу (или интерактивная аналитическая обработка, OLAP)

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

Оповещения

Когда нужно действовать? Какие действия нужно предпринять немедленно? Например, загрузка ЦП, о которой говорилось ранее.

Статистический анализ

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

Прогнозирование

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

Прогнозное моделирование

Что произойдет дальше? Как это повлияет на бизнес? Например, казино прогнозируют, кто из VIP посетителей будет больше заинтересован в конкретных пакетных предложениях по отдыху.

Оптимизация

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

Представленные идеи формируют график из книги Дэвенпорта и Харриса Competing on Analytics (2006).
Бизнес информация и аналитика

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

Рон Шевлин рационально отмечает:

С точки зрения возможностей нет причин, почему компания не может прогнозировать, например, объем продаж («уровень» 6), не зная, в чем конкретно «проблема» с продажами («уровень» 3)… Но как я, будучи руководителем, должен отвечать на вопрос «Какие действия нужно предпринять немедленно?» без понимания «Что будет, если этот тренд продолжится?» и «Что произойдет дальше?» («уровни» 6 и 7)?

Мне кажется, верный способ интерпретации – подумать о том, что максимальный уровень развития аналитики в компании положительно коррелирует с уровнем инвестиций в аналитику, использованием данных и прочими составляющими аналитической конкурентоспособности, о которой говорят Дэвенпорт и Харрис. Например, если аналитическая команда состоит из кандидатов и докторов наук, перед которыми поставлена задача оптимизировать глобальную цепочку сбыта, очевидно, что компания серьезно инвестирует в направление работы с данными. Если в компании принято работать только с оповещениями и специальными отчетами, значит, она в меньшей степени инвестирует в аналитическое направление и для нее в меньшей степени характерно управление на основе данных.
Можно предположить, что более сложная аналитика по умолчанию лучше и что она способна сделать компанию более конкурентоспособной. Так ли это на самом деле? В интереснейшем исследовании , проведенном MIT Sloan Management Review совместно с IBM Institute for Business Value, были опрошены 3 тыс. руководителей и специалистов по работе с данными в 30 отраслях: как они используют аналитическую работу и что думают о ее ценности?

Один из вопросов касался конкурентного положения компании на рынке, и для него были предложены четыре ответа:

  1. значительно лучше, чем у других компаний отрасли;
  2. несколько лучше, чем у других компаний отрасли;
  3. наравне с другими компаниями;
  4. несколько или значительно хуже, чем у других компаний отрасли.

Компании, выбравшие первый и четвертый варианты ответов, считались лидерами и аутсайдерами отрасли соответственно. Что интересно, от аутсайдеров компании лидеры отличались следующим:

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

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

Таблица «Уровни аналитических возможностей: желательный, опытный, преобразованный»
Уровни аналитических возможностей: желательный, опытный, преобразованный

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

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

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

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

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


Заявление о видении компании - Аналитическая культура

Заявление о видении компании — Аналитическая культура

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

В процветающей компании с управлением на основе данных [название компании] присутствует следующее.
Заявление о видении компании - Аналитическая культура
Continue reading


Специалисты по аналитике

Специалисты по аналитике

По-настоящему хороший аналитик должен будоражить людей… Я знаю, что я первый получаю данные, а значит, я первый узнаю историю. Открывать что-то новое увлекательно.
Дэн Мюррей

Человеческий фактор – важный компонент компании с управлением на основе данных. Кто такие специалисты по аналитике и как должна быть организована их работа?
Эта статья посвящена специалистам по аналитике: разным их типам и навыкам, которыми они должны обладать. Мы рассмотрим самые разные позиции и познакомимся с людьми, которые их занимают. Кроме того, мы обсудим плюсы и минусы разных организационных структур для выполнения аналитической работы.
Continue reading


Kachestvo_dannih_i_reshenie_mini

Качество данных

80 % времени я трачу на очистку данных. Качественные данные всегда выигрывают у качественных моделей.
Томсон Нгуен

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

Специалистам‑аналитикам нужны правильные данные, собранные правильным образом и в правильной форме, в правильном месте, в правильное время. (Они просят совсем не много.) Если какое‑то из этих требований не выполнено или выполнено недостаточно хорошо, у аналитиков сужается круг вопросов, на которые они способны дать ответ, а также снижается качество выводов, которые они могут сделать на основании данных.
Continue reading


smart модель

SMART-модель для анализа Big Data в Вашем бизнесе

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

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

smart модель

Для проработки стратегии можно использовать стратегическую панель:
Панель для разработки стратегии

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

Бизнес-аналитика на базе QlikView


бизнес-процесс

Бизнес-процесс. Управление и моделирование в BPM (Business Process Management)

Введение в управление бизнес-процессами (Business Process Management, BPM)

Распространенные роли в управлении бизнес-процессами:

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

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

Видео по бизнес-процессам:

Рисунок «Три взгляда на BPM»

Три взгляда на BPM

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

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

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

Управление бизнес процессами

Что такое управление бизнес процессами (BPM)?

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

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

  1. Бизнес процессы, поддерживающие управление бизнес процессами. Например, у организации должны быть процессы, которые обеспечивают:
    • описание и проектирование бизнес процессов;
    • разработку и внедрение бизнес процессов;
    • мониторинг и контроль исполнения бизнес процессов;
    • непрерывное и постоянное улучшение бизнес процессов, несмотря на и в ответ на внутренние и внешние изменения.
  2. Определенные роли (люди), вовлеченные в управление бизнес процессами . Таковые включают (не ограничиваясь ими) следующие:
    • архитектор процессов, который отвечает за описание и проектирование бизнес процессов;
    • процессный аналитик, который отвечает за построение, внедрение, мониторинг и оптимизацию бизнес процессов;
    • владелец процесса, который отвечает за исполнение бизнес процесса от начала до конца, в соответствии с определенными целевыми показателями эффективности и в конечном итоге за создание ценности для потребителя.
  3. Внедрение специализированных информационных технологий управления бизнес процессами , обеспечивающих следующую функциональность:
    • описание бизнес процессов в контексте корпоративной архитектуры;
    • проектирование бизнес процессов с целью внедрения;
    • исполнение бизнес процессов в контексте операционной деятельности;
    • мониторинг целевых показателей эффективности бизнес процессов;
    • анализ бизнес процессов с целью выявления и оценки возможностей для улучшения;
    • управление изменениями бизнес процесса.

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

Рисунок «Бизнес-процесс»

бизнес-процессКонцепция потребителя во взаимодействии функций внутри организации

Концепция потребителя в бизнес-процессе BPMЦенность в виде проектных спецификаций

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

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

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

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

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

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

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

schema_rascheta_kpi_bizness_processa

Категории бизнес-процессов

Бизнес-процессы можно разделить на три категории:

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

Модель зрелости BPM

Модель зрелости бизнес-процессов BPM:

Модель зрелости бизнес-процессов BPM

Моделирование бизнес-процессов

Цели моделирования процессов

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

Процессные модели – это средства:

  • управления процессами организации;
  • анализа эффективности процесса;
  • описания изменений.

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

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

Причины моделирования бизнес-процессов

Процессные нотации

Распространенные процессные нотации:

Процессные нотации

BPMN:
BPMN диаграмма

Диаграмма с дорожками Брюса Силвера:
Диаграмма с дорожками

Блок-схема:
Блок схема

Процессная цепочка, управляемая событиями (EPC):
Процессная цепочка, управляемая событиями (EPC)

UML:
uml

IDEF:
IDEF

Карта потока создания ценности:
Карты потока создания ценностиСпециализированные подходы к моделированию процессов

Специализированные подходы к моделированию процессов:
Специализированные подходы к моделированию процессов

Процессная иерархия

Процессная иерархия:
Процессная иерархия

Основные принципы моделирования бизнес-процессов

Что означает моделирование бизнес-процессов на практике? Моделирование бизнес-процессов в компании может быть направлено на решение большого числа различных задач:

  • Точно определить результат бизнес-процесса и оценить его значение для бизнеса.
  • Определить набор действий, составляющих бизнес-процесс. Ясное определение набора задач и действий, которые необходимо выполнить, чрезвычайно важно для детального понимания процесса.
  • Определить порядок выполнения действий. Действия в рамках одного бизнес-процесса могут выполняться как последовательно, так и параллельно. Очевидно, что параллельное исполнение, если оно допустимо, позволяет сократить общее время выполнения процесса и, следовательно, повысить его эффективность.
  • Произвести разделение зон ответственности: определить, а затем отслеживать, какой сотрудник или подразделение компании несет ответственность за выполнение того или иного действия или процесса в целом.
  • Определить ресурсы, потребляемые бизнес-процессом. Точно зная, кто какие ресурсы использует и для каких операций, можно повысить эффективность использования ресурсов посредством планирования и оптимизации.
  • Понять суть взаимодействий между участвующими в процессе сотрудниками и подразделениями компании и оценить, а затем повысить эффективность коммуникации между ними.
  • Увидеть движение документов в ходе процесса. Бизнес-процессы производят и потребляют различные документы (в бумажной или электронной форме). Важно разобраться, откуда и куда идут документы или информационные потоки, и определить, оптимально ли их движение и действительно ли все они необходимы.
  • Определить потенциальные узкие места и возможности для улучшения процесса, которые будут использованы позже для его оптимизации.
  • Более эффективно внедрить стандарты качества, например ИСО 9000, и успешно пройти сертификацию.
  • Использовать модели бизнес-процессов в качестве руководства для новых сотрудников.
  • Эффективно произвести автоматизацию бизнес-процессов в целом или отдельных их шагов, включая автоматизацию взаимодействия с внешней средой — клиентами, поставщиками, партнерами.
  • Разобравшись в совокупности бизнес-процессов компании, понять и описать деятельность предприятия в целом.

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

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

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

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

Шаги построения модели бизнес-процесса

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

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

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

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

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

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

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

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

Пояснение принципа прослеживания требований

Сбор и анализ требований

Сбор и анализ требований

Первые 90% работы отнимают
10% времени, а последние 10%
— оставшиеся 90% времени.
Правило 90/90

Все требования к проектируемой системе предлагается размещать на нескольких иерархических уровнях. На самом нижнем уровне располагаются требования, которые одинаково подходят для автоматизации технологических процессов в целом без учета особенностей конкретной прикладной области. Здесь необходимо обратиться к ГОСТам и другим нормативным документам. Далее следует уровень требований к автоматизированной системе определенного (заданного) класса с учетом соответствующих нормативных документов, определяющих порядок и описание заданного технологического процесса. И наконец, третий уровень составляют требования к конкретной системе. Кроме того, в стандарте IEEE 830-1993 Спецификация требований к ПО (Software Requirements Specification – SRS) проведено деление всех требований на две группы. Первая группа документирует потребности заказчика и записывается на языке, понятном заказчику – это т.н. С-требования. Вторая группа документирует требования в специальной, структурированной форме. Этот документ называют требованиями разработчика, или D-требованиями.

В ГОСТ 24.103-84 «Автоматизированные системы управления. Основные положения» перечислены общесистемные принципы, которые необходимо соблюдать при создании АСОИУ:

  1. системность – заключается в том, что при создании, функционировании и развитии АСУ должны быть установлены и сохранены связи между структурными элементами, обеспечивающие ее целостность;
  2. развитие – заключается в том, что АСУ должна создаваться с учетом возможности пополнения и обновления функций и видов ее обеспечения путем доработки программных и (или) технических средств или настройкой имеющихся средств;
  3. совместимость – заключается в обеспечении способности взаимодействия АСУ различных видов и уровней в процессе их совместного функционирования;
  4. стандартизация и унификация – заключается в рациональном применении типовых, унифицированных и стандартизованных элементов при создании и развитии АСУ;
  5. эффективность – заключается в достижении рационального соотношения между затратами на создание АСУ и целевыми эффектами, получаемыми при ее функционировании.

Кроме того, в п.3.4. ГОСТ 24.103-84 при создании АСУ рекомендуется максимально использовать типовые проектные решения, пакеты прикладных программ, унифицированные пакеты а также применять для новых объектов управления ранее созданные проекты АСУ. Это положение полностью соответствует принципам инженерии ПО, в особенности, концепции повторного использования компонентов.
ГОСТ 24.104-85 «Автоматизированные системы управления. Общие требования» устанавливает требования к каждому виду обеспечения отдельно. Перечислим те из них, на которые нужно обратить внимание.

Требования к программному обеспечению:

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

Требования к информационному обеспечения АСУ

  1. Форма представления выходной информации АСУ должна быть согласована с заказчиком (пользователем) системы.
  2. В АСУ должны быть предусмотрены необходимые меры по контролю и обновлению данных в информационных массивах АСУ, восстановлению массивов после отказа каких-либо технических средств АСУ, а также контролю идентичности одноименной информации в базах данных.

Требования безопасности

  1. Неправильные действия персонала АСУ не должны приводить к аварийной ситуации.

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

Кроме сбора требований особое значение имеет процесс управления требованиями. В технологии Rational Unified Process определяются пять уровней зрелости процесса управления требованиями:

  1. требования записаны в согласованном формате;
  2. требования организованы, используются стандартные форматы и метаданные о требованиях, поддерживается контроль версий;
  3. требования структурированы в соответствии со своими типами (функциональными и нефункциональными);
  4. требования отслеживаются в соответствии с их типом;
  5. требования интегрируются с процессами управления изменениями, моделирования, кодирования и т.д.

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

Хорошую спецификацию отличают следующие элементы:

  1. Акцент на деталях и их четкое определение.
  2. Забота о недопущении неверного толкования.
  3. Непротиворечивость внутри данной спецификации и другими спеками.
  4. Логическая взаимосвязь компонентов.
  5. Полнота охвата предмета.
  6. Соответствие нормативным актам.
  7. Соответствие деловой практике.

С-Требования

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

Перед проведением интервью:

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

Во время интервью:

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

После интервью:

  • составить черновик С-требований SRS с использованием CASE-инструментов;
  • определить конфигурацию оборудования;
  • передать черновик С-требований заказчику для получения его замечаний.

Рисунок – Порядок составления С-требований
Порядок составления С-требований

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

  • Методология SADT;
  • Диаграммы вариантов использования (use case) UML.
  • Диаграммы последовательности (sequence diagram) UML.
  • Диаграммы состояний (statechart diagram) UML.
  • Прототипирование дизайна пользовательского интерфейса входит в фазу проектирования программного обеспечения, однако его также можно считать и частью фазы формирования требований.

Порядок анализа требований заказчика включает следующие шаги:
1. Если требование простое и не имеет связей с другими требованиями, его выражают четкими предложениями в соответствующем разделе SRS.
2. Если требование представляет собой взаимодействие пользователя и приложения, то его, как правило, выражают с помощью варианта использования. Для этого:
2.1. Задают имена вариантам использования;
2.2. Определяют действующие лица;
2.3. Записывают последовательность действий пользователя и приложения;
2.4. Минимизируют ветвление.
3. Если требование затрагивает элементы обработки, каждый из которых получает и выдает данные, используют диаграмму потоков данных (DFD). При этом:
3.1. Определяют элементы обработки (обычно высокого уровня);
3.2. Определяют хранилища данных;
3.3. Показывают пути передачи данных между обрабатывающими элементами. Указывают типы данных, передаваемых в каждом случае.
4. Если требование затрагивает состояния, в которых может находиться программа (или части программы), строят диаграмму состояний в следующей последовательности:
4.1. Определяют состояния (каждое состояние обычно определяют отглагольным существительным, например «Ожидание»);
4.2. Указывают исходное и конечное состояние.
4.3. Определяют события, происходящие вне рассматриваемой части системы, и приводящие к переходу между состояниями;
4.4. Определяют вложенные состояния.

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

D-Требования

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

Рисунок – Порядок получения D-требований
Порядок получения D-требований

Существуют несколько типов D-требований:
1. Функциональные требования – определяют работу, которую должно выполнять проектируемая система (например, «приложение будет вычислять стоимость портфеля акций пользователя»).
2. Нефункциональные требования.
2.1. Производительность. Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Заказчики и разработчики обсуждают ограничения по времени вычислений, использованию оперативной памяти, объему запоминающих устройств и т. д.
2.2. Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Требования такого типа предполагают вероятность неидеальной работы программы и ограничивают область ее несовершенства. Особое внимание в ПЗ необходимо уделить вопросам обеспечения безопасности системы с учетом возможности искажения данных посредством несанкционированного доступа, сбоя системного или прикладного ПО.
2.3. Обработка ошибок. Эта категория требований объясняет, как программа должна реагировать на возникающие ошибки. Например, что должна делать программа, если она получает сообщение из другой программы в неразрешенном формате? Это не касается ошибок, генерируемых самой программой.
2.4. Интерфейсные требования. Интерфейсные требования описывают формат, в котором программа общается с окружением.
2.5. Ограничения. Ограничения на проектирование или реализацию описывают границы или условия того, как приложение должно быть задумано и разработано. Например, накладываются ограничения на инструменты и языки программирования ввиду сложившихся традиций организации, опыта программистов, совместимости и проч.
3. Обратные требования – это функционал, который система не обеспечивает.

 

Типичная последовательность получения функциональных D-требований с использованием объектно-ориентированного подхода приведена ниже:

1. Процесс начинается с перечисления классов, упомянутых в вариантах использования – это т.н. классы анализа.
2. Полученный набор классов обычно неполон и следует попытаться найти остальные классы предметной области.
3. Для каждого из полученных классов выписывается вся необходимая функциональность программы, за которую отвечает данный класс. Например, «у каждого клиента будет имя» (атрибут класса Клиент) и «программа должна иметь возможность вычислять капитал каждого клиента» (метод класса Клиент). События, которые должны обрабатывать объекты класса, также должны быть определены. В это же время должны быть разработаны и планы тестирования для каждого D-требования.
4. Связи между классами определяются в два этапа:
4.1. Начальный набор связей определяется на основе анализа диаграмм сотрудничества (collaboration) или диаграмм последовательности. Если два объекта взаимодействуют (обмениваются сообщениями), между ними на диаграмме должна существовать связь (путь взаимодействия), которая преобразуется в двунаправленную ассоциацию между соответствующими классами. Если сообщения между некоторой парой объектов передаются только в одном направлении, то для соответствующей ассоциации вводится направление навигации.
4.2. Анализируются и уточняются ассоциации между классами-сущностями. Задаются мощности ассоциаций, могут использоваться множественные ассоциации, агрегации, обобщения и ассоциации-классы.
5. D-требования проверяются и сравниваются с С-требованиями.
6. D-требования проверяются заказчиком и, затем, публикуются.

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

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

  1. Класс анализа является четкой абстракцией, моделирующей один конкретный элемент предметной области. Он должен имеет от 3-х до 5-ти операций. Все свойства класса служат реализации его назначения. Однако для реализации своего назначения класс должен иметь минимальное количество связей с другими классами.
  2. В классах анализа содержаться только ключевые атрибуты и операции, определенные на очень высоком уровне абстракции. Как правило, каждая операция уровня анализа затем разбивается на несколько операций уровня проекта.
  3. Необходимо избегать глубоких деревьев наследования (3 и более уровней), поскольку частой ошибкой при построении иерархии наследования является использование функциональной декомпозиции, где каждый уровень абстракции имеет только одну операцию. Наследование использует только там, где есть явная иерархи наследования, вытекающая непосредственно из предметной области.
  4. При выявлении классов посредством анализа текста С-требования, существительные указывают на классы или атрибуты, а глаголы служат признаком операций. Однако синонимы и омонимы могут стать причиной появления ложных классов.
  5. При выявлении классов совместно с пользователями часто используют т.н. CRC(Class-Responsibilities-Collaborators)-анализ с помощью стикеров и мозговой штурм.

Без возможности четкого контроля каждого требования от проекта до программного кода, реализующего это требование, было бы сложно убедиться в том, что программа разработана в соответствии с установленными требованиями. Когда требования меняются (чего следует ожидать), это становится еще сложнее. Возможность отображать каждое требование на соответствующие части проекта и программы называется прослеживанием.
Один из способов, помогающих обеспечить прослеживание, заключается в отображении каждого функционального D-требования на конкретную функцию целевого языка. На рисунке демонстрируется обеспечение принципа прослеживания для некоторого требования №NNN «Поиск учебно-методических материалов (УММ)»:

  1. С-требования, сформулированные заказчиком при проведении анкетирования (или интервью), отображаются на диаграмме вариантов использования;
  2. на этапе проработки D-требований, каждое С-требование представляется комплектом из трех диаграмм: деятельности, классов и последовательностей;
  3. при проектировании архитектуры системы для удовлетворения требования №NNN в некотором классе слоя предметной области предусматривается соответствующий метод(ы) (например, «findByAuthor» и «findByTitle)»;
  4. на стадии детального проектирования прорабатывается алгоритм метода, отвечающего за выполнение требования №NNN, а также создается ER-диаграмма БД и конструируется SQL-запрос(ы), выполнение которого обеспечит удовлетворение данного требования;
  5. на стадии реализации для выполнения требования №NNN разрабатываются листинги соответствующих методов и, наконец, на стадии тестирования выполнение требования №NNN проверяется с использованием составленного плана тестирования.

Рисунок – Пояснение принципа прослеживания
Пояснение принципа прослеживания требований

На протяжении всего процесса проектирования необходимо прилагать усилия по планированию будущего тестирования. Существует несколько преимуществ в написании тестов одновременно с требованиями.
Во-первых, это позволяет прояснить требование.
Во-вторых, это переносит некоторую часть работы из фазы тестирования проекта в фазу разработки требований. Пусть, например, SRS включает в свой состав D-требование №NNN следующего содержания: «NNN. ФИО каждого студента информационной системы «Деканат» будет представлять собой строку символов от 1 до 256». C целью планирования процедуры тестирования необходимо составить проект плана тестирования, примерная форма которого может быть представлена в виде таблицы .

Таблица «Тестовые данные для проверки D-требования №nnn»

№ п/п Входные тестовые данные Ожидаемый результат
1 Иванов Иван Иванович Иванов Иван Иванович
2 length()<10 Сообщение с вопросом о корректности вводимых данных
3 length()>256 Сообщение с вопросом о корректности вводимых данных
4

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

Рисунок «Шаблон таблицы для проверки D-требований»
Шаблон таблицы для проверки D-требований

Во втором столбце таблицы приводится идентификатор D-требования. В столбце 3 приводится идентификатор С-требования, в состав которого входит данное D-требование. В столбце 4 приводятся идентификаторы D-требований, выполнение которых необходимо и достаточно для реализации данного D-требования. В столбце 5 делают отметку, если данное D-требование не противоречит никакому другому D-требованию из перечисленных в таблице. В столбце 6 делают отметку, если данное D-требование может быть реализовано с учетом ограничений, накладываемых другими С- или D-требованиями, средой разработки, аппаратной платформой и т.д.

В столбце 7 делают отметку, если данное D-требование не может быть истолковано двояко. В столбце 8 делают отметку, если данное D-требование сформулировано предельно просто. В случае отсутствия отметки необходимо привести дополнительные разъяснения по содержанию такого требования. В столбце 9 делают отметку, если в данном требовании указаны допустимые отклонения от необходимого результата. В столбце 10 делают отметку, если формулировка данного D-требования не претерпит существенных изменений при возникновении в будущем необходимости наращивания функциональных возможностей системы. В столбце 11 делают отметку, если для данного требования составлен план тестирования. В столбце 12 делают отметку по окончании реализации данного D-требования в виде программного кода.

Порядок разработки каждого D-требования показан выше на рисунке и включает следующие шаги:

  1. Предварительный анализ требования:
    1. Классификация требования как функциональное или нефункциональное (рекомендуется использовать подсказки IEEE SRS для большинства нефункциональных требований);
    2. выбор метода организации функциональных требований.
  2. Обеспечение прослеживания требования. Убедиться в возможности прослеживания при проектировании и реализации.
  3. Обеспечение тестируемости требования. Спланировать конкретный тест, устанавливающий выполнение требования.
  4. Проверка недвусмысленности требования.
  5. Назначение требованию приоритет. Например, высокий («важно»), средний («желательно») или низкий («не обязательно»).
  6. Проверка полноты требования. Для каждого требования следует убедиться в присутствии всех остальных необходимых или сопутствующих требований.
  7. Добавление состояния ошибки:
    1. сформулировать, что требуется выполнить при возникновении нештатных ситуаций;
    2. в критичных местах добавить состояния ошибок программирования.
  8. Проверка согласованности. Необходимо убедиться, что ни одно требование не противоречит каким-либо аспектам другого требования.

Как только все D-требования собраны, необходимо обновить SPMP и передать D-требования под управление конфигурациями.
Для формализации и детальной фиксации требований рекомендуется использовать спецификацию требований к программному обеспечению (Software Requirements Specification — SRS) в соответствии со стандартом IEEE 830-1993.


Модель системы менеджмента качества

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

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

  • Фил Кросби: Качество — это соответствие пользовательским требованиям.
  • Уотс Хемпфри: Качество — это достижение отличного уровня пригодности к использованию.
  • Компания IBM: ввела в оборот фразу «качество, управляемое рыночными потребностями (market-driven quality)».
  • Критерий Бэлдриджа: «качество, задаваемое потребителем (customer-driven quality)».
  • Система менеджмента качества ISO 9001: Качество — это степень соответствия присущих характеристик требованиям.

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

Качество в проектной деятельности:

  • Управление требованиями («атрибуты качества» как категория нефункциональных требований);
  • Тестирование (т.н. наработка на отказ, такие метрики как MTTF — Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, и т.п. ).

«Приемлемое качество» можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement. То есть, приемлемое качество может рассматриваться как <количественно выраженный> компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах <решения задач> заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как «cost of quality» – «стоимость качества»).

Рисунок «Область знаний — Качество программного обеспечения»

Область знаний - Качество программного обеспеченияРисунок «Модель системы менеджмента качества»

Модель системы менеджмента качества

Основы качества программного обеспечения (Software Quality Fundamentals)

Согласие, достигнутое по требованиями к качеству (в оригинале — quality requirements), наравне с четким доведением до инженеров того, что составляет качество <получаемого продукта>, требуют обсуждения и формального определения многих аспектов качества.

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

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

Культура и этика программной инженерии (Software Engineering Culture and Ethics)

Ожидается, что инженеры по программному обеспечению воспринимают вопросы качества программного обеспечения как часть своей <профессиональной> культуры.
Этические аспекты могут играть значительную роль в обеспечении качества программного обеспечения, культуре и отношении инженеров <к своей работе>. IEEE Computer Society и ACM разработали кодекс этики (“моральный кодекс” – code of ethics) и профессиональной практики, основанный на восьми принципах, помогающих инженерам укрепить их отношение к качеству и независимость <в решении вопросов обеспечения достойного качества создаваемых программных продуктов> в их повседневной работе.

Значение и стоимость качества (Value and Costs of Quality)

Понятие “качество”, на самом деле, не столь очевидно и просто, как это может показаться на первый взгляд. Для любого инженерного продукта существует множество <интерпретаций> качества, в зависимости от конкретной “системы координат”. Множество этих точек зрения необходимо обсудить и определить на этапе выработки требований к программному продукту. Характеристики качества могут требоваться в той или иной степени, могут отсутствовать или могут задавать определенные требования, все это может быть результатом определенного компромисса.

Стоимость качества (cost of quality) может быть дифференцирована на:

  • стоимость предупреждения <дефектов> (prevention cost),
  • стоимость оценки (appraisal cost),
  • стоимость внутренних сбоев (internal failure cost),
  • стоимость внешних сбоев (external failure cost).

Движущей силой программных проектов является желание создать программное обеспечение, обладающее определенной ценностью. Ценность программного обеспечения в может выражаться в форме стоимости, а может и нет. Заказчик, обычно, имеет свое представление о максимальных стоимостных вложениях, возврат которых ожидается в случае достижения основных целей создания программного обеспечения. Заказчик может, также, иметь определенные ожидания в отношении качества ПО. Иногда, заказчики не задумываются о вопросах качества и связанной с ними стоимостью. Является ли характеристики качества чисто декоративными или, все же, это неотъемлемая часть программного обеспечения? Ответ, вероятно, находится где-то посередине, как почти всегда бывает в таких случаях, и является предметом обсуждения степени вовлечения заказчика в процесс принятия решений и полного понимания заказчиком стоимости и выгоды, связанной с достижением того или иного уровня качества. В идеальном случае, большинство такого рода решений должно приниматься процессе работы с требованиями, однако эти вопросы могут подниматься на протяжении всего жизненного цикла программного обеспечения. Не существует каких-то <“стандартных”> правил того, как именно необходимо принимать такие решения. Однако, инженеры должны быть способны представить различные альтернативы и их стоимость.

Модели и характеристики качества (Models and Quality Characteristics)

ISO/IEC определяет три связанных модели качества программного обеспечения (ISO 9126-01 Software Engineering — Product Quality, Part 1: Quality Model):

  • внутреннее качество,
  • внешнее качество и
  • качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного обеспечения (ISO14598-98 Software Product Evaluation).

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

Управление качеством (software quality management) и качество процессов программной инженерии (software engineering process quality) имеют непосредственное отношение к качеству создаваемого программного продукта.

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

  • TickIT — касается рассмотрения общей системы менеджмента качества ISO 9001-00 в приложении к программным проектам.
  • Другой важный стандарт – CMMI, обсуждаемый в области знаний “Процесс программной инженерии”, предоставляет рекомендации по совершенствованию процесса. Непосредственно с управлением качеством связаны процессные области (области компетенции) CMMI:
    • обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI “Support”),
    • проверка (verification, категория “Engineering”) и
    • аттестация (validation, категория “Engineering”).

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

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

Качество программного продукта (Software product quality)

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

Стандарт ISO 9126-01 (Software Engineering — Product Quality, Part 1: Quality Model) определяет для двух из трех описанных в нем моделей, связанные характеристики и «суб-характеристики» качества, а также метрики, полезные для оценки качества программных продуктов.

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

  • полная спецификация системных требований (system requirements specification),
  • спецификация программных требований для программных компонент системы (software requirements specification, SRS),
  • модели,
  • код,
  • тестовая документация,
  • отчеты, создаваемые в результате работ по анализу качества.

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

Повышение качества (Quality Improvement)

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

  1. процессами жизненного цикла,
  2. процессом обнаружения, устранения и предотвращения сбоев/дефектов и
  3. процессов улучшения качества.

К программной инженерии применимы теории и концепции, лежащие в основе совершенствования качества. Например, предотвращение и ранняя диагностика ошибок, постоянное совершенствование (continuous improvement) и внимание к требованиям заказчика (customer focus), составляющие принцип “building in quality”. Эти концепции основываются на работах экспертов по качеству, пришедших к мнению, что качество продукта напрямую связано с качеством используемых для его создания процессов.

Такие подходы, как TQM (Total Quality Management – всеобщее управление качеством) и PDCA (Plan, Do, Check, Act – Планирование, Действие, Проверка, Реакция/Корректировка), являются инструментами достижения задач, связанных с качеством. Поддержка менеджмента помогает в выполнении процессов, оценке продуктов и получению всех необходимых данных. Кроме этого, разрабатываемая программа совершенствования (improvement program, обычно является целевой и охватывает работу подразделения или организации, в целом) детально идентифицирует все действия и проекты по улучшению <отдельных аспектов деятельности> в рамках определенного периода времени, за который такие проекты можно осуществить с успешным решением соответствующих задач. При этом, поддержка менеджмента означает, что все проекты по улучшению обладают достаточными ресурсами для достижением поставленных целей. Поддержка менеджмента тесно связана с реализацией активного взаимодействия в коллективе, и должна предупреждать возникновение потенциальных проблем (и пассивного или даже активного противодействия реализации программы совершенствования или отдельных ее проектов). Формирование рабочих групп, поддержка менеджеров среднего звена и выделенные ресурсы на уровне проекта – эти вопросы обсуждаются в области знаний “Процесс программной инженерии”.

Процессы управления качеством программного обеспечения (Software Quality Processes)

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

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

Планирование качества программного обеспечения включает:

  1. Определение требуемого продукта в терминах характеристик качества.
  2. Планирование процессов для получения требуемого продукта.

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

SQM может использоваться для оценки и конечных и промежуточных продуктов. Некоторые из специализированных процессов SQM определены в стандарте 12207:

  • Процесс обеспечения качества (quality assurance process);
  • Процесс верификации (verification process);
  • Процесс аттестации (validation process);
  • Процесс совместного анализа (joint review process);
  • Процесс аудита (audit process).

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

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

Управление рисками также может играть значительную роль для выпуска качественного программного обеспечения. Включение “регулярного” (как постоянно действующего, а не периодического; в оригинале – disciplined) анализа рисков и <соответствующих> техник управления <рисками> в процессы жизненного цикла программного обеспечения может увеличить потенциал для производства качественного продукта. Более подробную информацию по управлению рисками можно найти в области знаний “Управление программной инженерией”.

Подтверждение качества программного обеспечения (Software Quality Assurance, SQA)

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

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

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

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

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

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

Кроме того, SQA-план касается и вопросов работ по обеспечению качества, относящихся к другим типам деятельности, описанным в <различных> планах по созданию программного обеспечения, к которым также относятся поставка, установка, обслуживание заказных и/или тиражируемых/готовых программных решений (commercial off-the-shelf, COTS), необходимых для данного проекта программного обеспечения. SQA-план может содержать необходимые для обеспечения качества критерии приемки программного обеспечения и действия по формированию отчетности и управлению <и контролю над> работами.

Проверка (верификация) и аттестация (Verification and Validation, V&V)

Проверка и аттестация программного обеспечения – упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований.
V&V напрямую адресуется вопросам качества программного обеспечения и использует соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V может применяться для промежуточных продуктов, однако, в том объеме, который соответствует промежуточным “шагам” <соответствующих> процессов жизненного цикла.

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

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

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

Оценка (обзор) и аудит (Review and Audits)

Пять типов оценок и аудитов:

  • Управленческие оценки (management reviews)
  • Технические оценки (technical reviews)
  • Инспекции (inspections)
  • “Прогонки” (walk-throughs)
  • Аудиты (audtis)

Управленческие оценки (Management Reviews)

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

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

Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), V&V-отчетов, а также различных типов планов — управления рисками проекта/проектного управления, конфигурационного управления, безопасности <использования> программного обеспечения (safety), оценки рисков и т.п.

Технические оценки (Technical Reviews)

Назначением технических оценок является исследование программного продукта для определения его пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с утвержденными спецификациями и стандартами. Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее решения (decision-maker); лидер оценки (review leader); регистратор (recorder); а также технический персонал, поддерживающий (непосредственно исполняющий) действия по оценке.

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

  • Формулировки целей
  • Конкретного программного продукта (подвергаемого оценке)
  • Заданного плана проекта (плана управления проектом)
  • Списка проблем (вопросов), ассоциированных с продуктом
  • Процедуры технической оценки

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

Инспекции (Inspections)

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

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

Инспектирование программного обеспечения всегда вовлекает авторов промежуточного или конечного продукта, в отличие от оценок, которые не требуют этого в обязательном порядке. Инспекции (как временные организационные единицы – группы, команды) включают лидера, регистратора, рецензента и нескольких (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в различных областями экспертизы (обладать различными областями компетенции), например, предметной области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональных требований или атрибутов качества, прим. автора). Каждый член команды должен исследовать программный продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические техники в небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией <инспекции> и проверяет, что все <члены команды> подготовились к инспектированию.

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

  1. Принятие <продукта> с отсутствием либо малой необходимостью переработки
  2. Принятие <продукта> с проверкой переработанных фрагментов
  3. Необходимость повторной инспекции

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

Прогонки (Walk-throughs)

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

Главные цели прогонки состоят в:

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

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

Аудиты (Audits)

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

Аудит является формально организованной деятельностью, участники которой выполняют определенные роли, такие как главный аудитор (lead auditor), второй аудитор (another auditor), регистратор (recorder) и инициатор (initiator). В аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате аудита идентифицируются случаи несоответствия и формируется отчет, необходимый команде <разработки> для принятия корректирующих действий.

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

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

Требования к качеству программного обеспечения (Software Quality Requirements)

Факторы влияния (Influence factors)

На планирование, управление и выбор SQM-действий и техник оказывают влияние различные факторы, среди которых:

  • Область применения системы, в которой будет работать программное обеспечение (критичное для безопасности <людей>), критичное для бизнеса и т.п.)
  • Системные и программные требования
  • Какие компоненты используются в системе – коммерческие (внешние) или стандартные (внутренние)
  • Какие стандарты программной инженерии применимы в заданном контексте
  • Каковы методы и программные инструменты, применяемые для разработки и сопровождения, а также для обеспечения качества и совершенствования (продукта и процессов)
  • Бюджет, персонал, организация проектной деятельности, планы и расписания для всех процессов
  • Кто целевые пользователи и каково назначение системы
  • Уровень целостности системы

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

Гарантоспособность (Dependability)

Гарантоспособость – гарантия <высокой> надежности, защищенности от сбоев.
В случаях, когда сбой системы может привести к крайне тяжелым последствиям (такие системы иногда называют в англоязычных источниках “high confidence” или “high integrity system”, в русском языке к ним иногда применяют название “системы повышенной надежности”, “высокой доступности” и т.п.), общая (совокупная) гарантоспособность системы (как сочетания аппаратной части, программного обеспечения и человека) является главным и приоритетным требованием качества, по отношению к основной функциональности <системы>.

Гарантоспособность (dependability) программного обеспечения включает такие характеристики, как защищенность от сбоев (fault-tolerance), безопасность использования (safety – безопасность в контексте приемлемого риска для здоровья людей, бизнеса, имущества и т.п. ), информационная безопасность или защищенность (security – защита информации от несанкционированных операций, включая доступ на чтение, а также гарантия доступности информации авторизованным пользователям, в объеме заданных для них прав), а также удобство и простота использования (usability). Надежность (reliability) также является критерием, который может быть определен в терминах гарантоспособности.

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

Уровни целостности программного обеспечения (Integrity levels of software)

Уровень целостности программного обеспечения определяется на основании возможных последствий сбоя программного обеспечения и вероятности возникновения такого сбоя. Когда важны различные аспекты безопасности (применения и информационной безопасности), при разработке планов работ в области идентификации возможных очагов аварий могут использоваться техники анализа опасностей (в контексте безопасности использования, safety) и анализа угроз (в информационной безопасности, security). История сбоев аналогичных систем может также помочь в идентификации наиболее полезных техник, направленных на обнаружение сбоев и <всесторонней> оценки качества программного обеспечения.

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

Характеристика дефектов (Defect Characterization)

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

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

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

Частичные определения понятий такого рода выглядят следующим образом:

  • Ошибка (error): “Отличие … между корректным результатом и вычисленным результатом <полученным с использованием программного обеспечения>”
  • Недостаток (fault): “Некорректный шаг, процесс или определение данных в компьютерной программе”
  • Сбой (failure): “<Некорректный> результат, полученный в результате недостатка”
  • Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее к некорректному результату”

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

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

Данные о несоответствиях и дефектах, найденных в процессе реализации соответствующих техник SQM, должны фиксироваться для предотвращения их потери. Для некоторых техник (например, технической оценки, аудита, инспекций), присутствие регистратора (recorder) – обязательно, именно для фиксирования такой информации, наравне с вопросами (в том числе, требующими дополнительного рассмотрения) и принятыми решениями. В тех случаях, когда используются соответствующие средства автоматизации, они могут обеспечить и получение необходимой выходной информации о дефектах (например, сводную статистику по статусам дефектов, ответственным исполнителям и т.п.). Данные о дефектах могут собираться и записываться в форме запросов на изменения (SCR, software change request) и могут, впоследствии, заноситься в определенные типы баз данных (например, в целях отслеживания кросс-проектной/исторической статистики для дальнейшего анализа и совершенствования процессов), как вручную, так и в автоматическом режиме из соответствующих средств анализа (ряд современных средств проектирования и специализированных инструментов позволяют анализировать код и модели с применением соответствующих метрик, значимых для обеспечения качества продуктов и процессов). Отчеты о дефектах направляются управленческому звену организации/организационной единицы или структуры (для принятия соответствующих решений в отношении проекта, продукта, процесса, персонала, бюджета и т.п.).

Техники управления качеством программного обеспечения (Software Quality Management Techniques)

Техники SQM могут быть распределены по нескольким категориям:

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

Статические техники (Static techniques)

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

Техники коллективной оценки (People-intensive techniques)

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

Аналитические техники (Analytical techniques)

Инженеры, занимающиеся программным обеспечением, как правило, применяют аналитические техники. С точки зрения Agile-методик и подходов, individuals and interactions предполагает <непосредственное> общение и постоянное взаимодействие членов команды.

Иногда, несколько инженеров используют одну и ту же технику, но в отношении разных частей продукта. Некоторые техники базируются на специфике применяемых инструментальных средств, другие – предполагают “ручную” работу. Многие могут помогать находить дефекты напрямую, но чаще всего они используются для поддержки других техник. Ряд техник также включает различного рода экспертизу (assessment) как составной элемент общего анализа качества. Примеры таких техник — анализ сложности (complexity analysis), анализ управляющей логики (или анализ контроля потоков управления — control flow analysis) и алгоритмический анализ (algorithmic analysis).

Каждый тип анализа обладает конкретным назначением и не все типы применимы к любому проекту. Примером техники поддержки является анализ сложности, который полезен для определения фрагментов дизайна системы, обладающих слишком высокой сложностью для корректной реализации, тестирования или сопровождения. Результат анализа сложности может также применяться для разработки тестовых сценариев (test cases). Такие техники поиска дефектов, как анализ управляющей логики, может также использоваться и в других случаях. Для программного обеспечения с обширной алгоритмической логикой крайне важно применять алгоритмические техники, особенно в тех случаях, когда некорректный алгоритм (не его реализация, а именно логика, прим. автора) может привести к катастрофическим результатам (например, программное обеспечение авионики, для которой вопросы безопасности использования – safety играют решающую роль).

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

Динамические техники (Dynamic techniques)

В процессе разработки и сопровождения программного обеспечения приходится обращаться к различным видам динамических техник. В основном, это техники тестирования. Однако, в качестве динамических техник могут рассматриваться техники симуляции, проверки моделей и “символического” исполнения (symbolic execution, часто предполагает использование модулей-“пустышек” с точки зрения выполняемой логики, с эмулируемым входом и выходом при рассмотрении общего сценария поведения многомодульных систем; иногда под этим термином понимаются и другие техники, в зависимости, от выбранного первоисточника).

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

В зависимости от организации <ведения> проекта, определенные работы по тестированию могут выполняться при разработке программных систем в SQA и V&V процессах. В силу того, что план SQM адресуется вопросам тестирования, данная тема включает некоторые комментарии по тестированию.

Тестирование (Testing)

Процессы подтверждения <качества>, описанные в SQA и V&V <планах>, исследуют и оценивают любой выходной продукт (включая промежуточный и конечный), связанный со спецификацией требований к программному обеспечению, на предмет:

  • трассируемости (traceability),
  • согласованности (consistency),
  • полноты/завершенности (completeness),
  • корректности (correctness)
  • и непосредственно выполнения <требований> (performance).

Такое подтверждение также охватывает любые выходные артефакты процессов разработки и сопровождения, сбора, анализа и количественной оценки результатов. SQA-деятельность обеспечивает гарантию того, что соответствующие (необходимые в заданном контексте проекта) типы тестов спланированы, разработаны и реализованы, а V&V – разработку планов тестов, стратегий, сценариев и процедур <тестирования>.
Вопросы тестирования детально обсуждаются в области знаний “Тестирование”. Два типа тестирования следуют задачам, задаваемым SQA и V&V, потому как на них ложится ответственность за качество данных, используемых в проекте:

  • Оценка и тестирование инструментов, используемых в проекте
  • Тестирование на соответствие (или оценка тестов на соответствие) компонент и COTS-продуктов (COTS — commercial of-the-shelf, готовый к использованию продукт) для использования в создаваемом продукте.

Иногда, независимые V&V-организации могут требовать возможности мониторинга процесса тестирования и, в определенных случаях, заверять (или, чаще, документировать/фиксировать) реальное выполнение <тестов> на предмет их проведения в соответствии с заданными процедурами. С другой стороны, может быть сделано обращение к V&V может быть направлено на оценку и самого тестирования: достаточности планов и процедур, соответствия и точности результатов.

Другой тип тестирования, которое проводится под началом V&V-организации – тестирование третьей стороной (third-party testing). Такая третья сторона сама не является разработчиком продукта и ни в какой форме не связана с разработчиком продукта. Более того, третья сторона является независимым источником оценки, обычно аккредитованным на предмет обладания соответствующими полномочиями (например, организацией-разработчиком того или иного стандарта, соответствие которому оценивается независимым экспертом и чьи действия подтверждены создателем стандарта). Назначение такого рода тестирования состоит в проверке продукта на соответствие определенному набору требований (например, по информационной безопасности).

Количественная оценка качества программного обеспечения (Software Quality Measurement)

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

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

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

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

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

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

  • Основанные на статистических методах (например, анализ Pareto, нормальное распределение и т.п.)
  • Статистические тесты
  • Анализ тенденций
  • Предсказание (например, модели надежности)

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

Характеристики качества программного обеспечения

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

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

Примечания:

  1. Износ или старение программного обеспечения не происходит. Ограничения надежности проявляются из-за ошибок в требованиях, проекте и реализации. Отказы из-за этих ошибок зависят от способа использования программного обеспечения и ранее выбранных версий программ.
  2. В определении ИСО 8402 «надежность» — «способность элемента выполнять требуемую функцию». В настоящем стандарте функциональная .возможность является только одной из характеристик качества программного обеспечения. Поэтому определение надежности расширено до «сохранения своего уровня качества функционирования» вместо «выполнения требуемой функции».

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

Примечания:

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

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

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

Примечания:

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

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

Качество программного продукта

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

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

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

Представление пользователя

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

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

  • Имеются ли требуемые функции в программном обеспечении?
  • Насколько надежно программное обеспечение?
  • Насколько эффективно программное обеспечение?
  • Является ли программное обеспечение удобным для использования?
  • Насколько просто переносится программное обеспечение и другую среду?

Представление разработчика

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

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

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

Представление руководителя

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

Оценка качества программного продукта

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

Рисунок «Модель процесса оценивания»

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

Модель качества процесса

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

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

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

Руководство по применению характеристик качества

1 Применяемость

2 Представления о качестве программного

2.1 Представление пользователя
2.2 Представление разработчика
2.3 Представление руководителя

3 Модель процесса оценивания

3.1 Установление требований к качеству

3.2 Подготовка к оцениванию

3.2.1 Выбор метрик (показателей) качества
3.2.2 Определение уровней ранжирования
3.2.3 Определение критерия оценки

3.3 Процедура оценивания

3.3.1 Измерение
3.3.2 Ранжирование
3.3.3 Оценка

Комплексные показатели (подхарактеристики) качества

Комплексные показатели (подхарактеристики) качества

1 Введение

2 Определение комплексных показателей качества

2.1 Функциональные возможности (Functionality)

2.1.1 Пригодность (Suitability)
2.1.2 Правильность (Accuracy)
2.1.3 Способность к взаимодействию (Interoperability)
2.1.4 Согласованность (Compliance)
2.1.5 Защищенность (Security)

2.2 Надежность (Reliability)

2.2.1 Стабильность (Maturity)
2.2.2 Устойчивость к ошибке (Fault tolerance)
2.2.3 Восстанавливаемость (Recoverability)

2.3 Практичность (Usability)

2.3.1 Понятность (Understandability)
2.3.2 Обучаемость (Learnability)
2.3.3 Простота использования (Operability)

2.4 Эффективность (Efficiences)

2.4.1 Характер изменения во времени (Time behavior)
2.4.2 Характер изменения ресурсов (Resource behavior)

2.5 Сопровождаемость (Maintainability)

2.5.1 Анализируемость (Analysability)
2.5.2 Изменяемость (Changeability)
2.5.3 Устойчивость (Stability)
2.5.4 Тестируемость (Testability)

2.6 Мобильность (Portability)

2.6.1 Адаптируемость (Adaptability)
2.6.2 Простота внедрения (Installability)
2.6.3 Соответствие (Conformance)
2.6.4 Взаимозаменяемость (Replaceabilily)

Примечания:

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

Качество проекта

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

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

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

Принципы качества (ISO 9000)

  1. Ориентация на потребителя
  2. Ответственность руководства
  3. Вовлечение людей
  4. Процессный подход
  5. Системный подход к менеджменту
  6. Постоянное улучшение
  7. Принятие решений, основанное на фактах
  8. Взаимовыгодные отношения с поставщиками

Рисунок «Различия в понимании управления качеством в ISO 9000 и PMBoK»

Различия в понимании управления качеством в ISO 9000 и PMBoK

Управление качеством проекта (PMI): подпроцессы

  • Планирование качества
  • Обеспечение качества
  • Контроль качества

Планирование качества

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

Процесс планирования качества: входы

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

Процесс планирования качества: инструменты и технологии

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

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

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

Обеспечение качества

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

Процесс обеспечения качества: входы

  • План управления качеством. Выход процесса планирования качества.
  • Рабочие инструкции. Еще один выход процесса планирования качества.
  • Результаты контрольных измерений качества. Выход процесса контроля качества.

Процесс обеспечения качества: инструменты и техники

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

Аудиты качества

Структурированные «осмотры», которые подтверждают «выученные уроки». Типы аудита качества бывают:

  • внутренними / внешними,
  • системными / продукта / процессов / организации,
  • плановые / регулярные,
  • специальные и усложненные.

Процесс обеспечения качества: выходы

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

Контроль качества

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

Процесс контроля качества: входы

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

Контроль качества: инструменты и техники

  • Инспекции. Включают такие деятельности, как измерения, испытания, тестирования, чтобы удостовериться, что результат удовлетворяет требованиям.
  • Контрольные диаграммы. Run-Диаграммы статистически определяют верхний и нижний пределы, отраженные по обе стороны от средних значений процесса.
  • Диаграммы: Ишикавы, Парето.
  • Статистическая выборка.
  • Анализ трендов.

«Цель использования инструментов – зафиксировать результаты или изменения, отобразить их графически, и далее выявить и скорректировать проблемы подходящим способом».

Процесс контроля качества: выходы

  • Улучшение качества. Выход из процесса обеспечения качества.
  • Принятие решений. Решения принимаются в зависимости от того, принят или отклонен проинспектированный объект.
  • Корректирующие действия. Действие, проводимое, чтобы привести в соответствие несоответствующий объект.
  • Заполненные проверочные списки.
  • Настройка процесса.

Использованная литература

  • http://sorlik.blogspot.com, Сергей Орлик, 2004-2005
  • Генельт А.Е. Учебно-методическое пособие по дисциплине «Управление качеством разработки ПО» 2007, Санкт-Петербург

ТРИЗ (Теория решения изобретательских задач)

ТРИЗ — Теория решения изобретательских задач

Что такое ТРИЗ?

Теория решения изобретательских задач, или ТРИЗ — область знаний о механизмах развития технических систем и методах решения изобретательских задач. ТРИЗ не является строгой научной теорией, а представляет собой обобщённый опыт изобретательства и изучения законов развития науки и техники. В результате своего развития ТРИЗ вышла за рамки решения изобретательских задач в технической области, и сегодня используется также в нетехнических областях (бизнес, искусство, литература, педагогика, политика и др.).
YouTube Трейлер

  1. Перевыставить задачу (найти суть задачи)
  2. Выставление эталона
    • Подбор примеров (как это уже сделано?)
    • Как бы задача была решена если бы была волшебная палочка?
    • Как решить задачу ничего не делая?
  3. Преодоление технического противоречия

Структура и функции ТРИЗ

Цель ТРИЗ — выявление и использование законов, закономерностей и тенденций развития технических систем.

Основные функции ТРИЗ

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

Вспомогательные функции ТРИЗ

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

Структура ТРИЗ

  • Законы развития технических систем (ТС)
  • Информационный фонд ТРИЗ
  • Вепольный анализ (структурный вещественно-полевой анализ) технических систем
  • Алгоритм решения изобретательских задач — АРИЗ
  • Методы развития творческого воображения

Список приемов устранения технических противоречий

1. Принцип дробления:
а) разделить объект на независимые части;
б) выполнить объект разборным;
в) увеличить степень дробления объекта.

2. Принцип вынесения:
отделить от объекта “мешающую” часть (“мешающее” свойство) или, наоборот, выделить единственно нужную часть (нужное свойство).

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

4. Принцип асимметрии:
а) перейти от симметричной формы объекта к асимметричной;
б) если объект асимметричен, увеличить степень асимметрии.

5. Принцип объединения:
а) соединить однородные или предназначенные для смежных операций объекты;
б) объединить во времени однородные или смежные операции.

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

7. Принцип “матрешки”:
а) один объект размещен внутри другого, который, в свою очередь, находится внутри третьего и т. д.;
б) один объект проходит сквозь полости в другом объекте.

8. Принцип антивеса:
а) компенсировать вес объекта соединением с другим, обладающим подъемной силой;
б) компенсировать вес объекта взаимодействием со средой (за счет аэро- и гидродинамических сил).

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

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

11. Принцип “заранее подложенной подушки”:
компенсировать относительно невысокую надежность объекта заранее подготовленными аварийными средствами.

12. Принцип эквипотенциальности:
изменить условия работы так, чтобы не приходилось поднимать или опускать объект.

13. Принцип “наоборот”:
а) вместо действия, диктуемого условиями задачи, осуществить обратное действие;
б) сделать движущуюся часть объекта или внешней среды неподвижной, а неподвижную — движущейся;
в) перевернуть объект “вверх ногами”, вывернуть его.

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

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

16. Принцип частичного или избыточного действия:
если трудно получить 100% требуемого эффекта, надо получить “чуть меньше” или “чуть больше” — задача при этом существенно упростится.

17. Принцип перехода в другое измерение:
а) трудности, связанные с движением (или размещением) объекта по линии, устраняются, если объект приобретает возможность перемещаться в двух измерениях (т. е. на плоскости). Соответственно задачи, связанные с движением (или размещением) объектов в одной плоскости, устраняются при переходе к пространству в трех измерениях;
б) использовать многоэтажную компоновку объектов вместо одноэтажной;
в) наклонить объект или положить его “на бок”;
г) использовать обратную сторону данной площади;
д) использовать оптические потоки, падающие на соседнюю площадь или обратную сторону имеющейся площади.

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

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

20. Принцип непрерывности полезного действия:
а) вести работу непрерывно (все части объекта должны все время работать с полной нагрузкой);
б) устранить холостые и промежуточные ходы.

21. Принцип проскока:
вести процесс или отдельные его этапы (например, вредные или опасные) на большой скорости.

22. Принцип “обратить вред в пользу”:
а) использовать вредные факторы (в частности, вредное воздействие среды) для получения положительного эффекта;
б) устранить вредный фактор за счет сложения с другими вредными факторами;
в) усилить вредный фактор до такой степени, чтобы он перестал быть вредным.

23. Принцип обратной связи:
а) ввести обратную связь;
б) если обратная связь есть, изменить ее.

24. Принцип “посредника”:
а) использовать промежуточный объект, переносящий или передающий действие;
б) на время присоединить к объекту другой (легкоудаляемый) объект.

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

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

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

28. Принцип замены механической схемы:
а) заменить механическую схему оптической, акустической или “запаховой”;
б) использовать электрические, магнитные и электромагнитные поля для взаимодействия с объектом;
в) перейти от неподвижных полей к движущимся, от фиксированных — к меняющимся во времени, от неструктурных — к имеющим определенную структуру;
г) использовать поля в сочетании с ферромагнитными частицами.

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

30. Принцип использования гибких оболочек и тонких пленок:
а) вместо обычных конструкций использовать гибкие оболочки и тонкие пленки;
б) изолировать объект от внешней среды с помощью гибких оболочек и тонких пленок.

31. Принцип применения пористых материалов:
а) выполнить объект пористым или использовать дополнительные пористые элементы (вставки, покрытия и т. д.);
б) если объект уже выполнен пористым, предварительно заполнить поры каким-то веществом.

32. Принцип изменения окраски:
а) изменить окраску объекта или внешней среды;
б) изменить степень прозрачности объекта или внешний среды.

33. Принцип однородности:
объекты, взаимодействующие с данным объектом, должны быть сделаны из того же материала (или близкого ему по свойствам).

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

35. Принцип изменения физико-химических параметров объекта:
а) изменить агрегатное состояние объекта;
б) изменить концентрацию или консистенцию;
в) изменить степень гибкости;
г) изменить температуру.

36. Принцип применения фазовых переходов:
использовать явления, возникающие при фазовых переходах, например, изменение объема, выделение или поглощение тепла и т. д.

37. Принцип применения теплового расширения:
а) использовать тепловое расширение (или сжатие) материалов;
б) использовать несколько материалов с разными коэффициентами теплового расширения.

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

39. Принцип применения инертной среды:
а) заменить обычную среду инертной;
б) вести процесс в вакууме.

40. Принцип применения композиционных материалов:
перейти от однородных материалов к композиционным.

Использование ТРИЗ в IT-технологиях

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