вторник, 27 декабря 2016 г.

Сравнение бизнес-анализа и системного мышления


Резюме после пролистанных по диагонали 120 страниц.


Бизнес-анализ примерно соответствует инженерии требований. Главными артефактами работы аналитика, работающего на основе BABOK является гармонизированный набор требований и логической архитектуры решения.


Два ключевых отличия аналитика от инженера по требованиям:

1) Не используется прием абстрагирования системы как черного ящика с сервисом и интерфейсом, требованиями называются как требования, так и ограничения и архитектура;
2) Не рассматривается воплощение системы, работа аналитика завершается выпуском т.н. "архитектуры требований", которая состоит из гармонизированного набора требований и логической архитектуры. Модели привязаны (оттрассированы к модулям).

В чем системное мышление и бизнес-анализ схожи?


  1. Работают со стейкхолдерами, сгруппированными по интересам. Каждому интересу предъявляют свой частный метод описания и частное описание.
  2. Работают с потребностями, потребности фокусируют требования. Используется целеориентированная инженерии требований, есть трассировка от стейкхолдеров и их целей к требованиям и архитектуре. Требования рассматриваются как функциональный объект (альфа), с набором состояний.
  3. Используется функциональная декомпозиция, требования трассируются к модулям.
  4. Есть понятие платформы системы как набора типовых архитектурных решений
В чем системное мышление и бизнес-анализ различаются?
  1. Требования и архитектура (requirements and designs) постоянно путаются и смешиваются. Прямо заявляется "Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements. The shift in focus is often subtle".
  2. Состояния альфы "Требования" определяется по усмотрению, нет чек-листа для определения состояния требований.
  3. Под верификацией БА подразумевает " Requirements (verified): a set of requirements that have been verified to be of sufficient quality to be used as a reliable body of work for further specification and development...Verify Requirements: ensures that a set of requirements or designs has been developed in enough detail to be usable by a particular stakeholder, is internally consistent, and is of high quality." Т.е., верификация требований в БА - это соответствие требований требованиям к требованиям.
  4. Под валидацией БА подразумевает "Validate Requirements: ensures that a set of requirements or designs delivers business value and supports the organization's goals and objectives", т.е., валидация производится против требований к обеспечивающей системе.
  5. Методы БА не могут быть рекурсивно использованы на любом уровне холархии системы. Системы задаются объективно. Холархия требований отсутствует.
  6. Воплощение системы не рассматривается, жизненный цикл системы с выделенной стадией эксплуатации не используется, хотя стейкхолдеры из стадий использования и обслуживания заявлены.
  7. Стейкхолдеры не рассматриваются в ролях, 4Д экстенсионализм к ним не применяется. Роль стейкхолдера фиксирована на исполнителе.
  8. В БА платформы системы не содержит типовых интерфейсов и модулей.
  9. БА использует пять аспектов рассмотрения системы "The perspectives included in the BABOK® Guide are:• Agile• Business Intelligence• Information Technology• Business Architecture• Business Process Management"
  10. Функциональное разбиение используется по большей части при анализе оргпроцессов, не используется при модульном синтезе. Модульный синтез основан на фольклоре (мозговые штурмы, рабочие встречи), нет метода.
  11. Логическая и физические архитектуры не связаны "Requirements architecture is the structure of all of the requirements of a change. A requirements architecture fits the individual models and specifications together to ensure that all of the requirements form a single whole that supports the overall business objectives and produces a useful outcome for stakeholders.Business analysts use a requirements architecture to:• understand which models are appropriate for the domain, solution scope, and audience,• organize requirements into structures relevant to different stakeholders,• illustrate how requirements and models interact with and relate to each other, and show how the parts fit together into a meaningful whole,• ensure the requirements work together to achieve the overall objectives, and• make trade-off decisions about requirements while considering the overall objectives. Requirements architecture is not intended to demonstrate traceability, but rather to show how elements work in harmony with one another to support the business requirements, and to structure them in various ways to align the viewpoints of different stakeholders. Traceability is often used as the mechanism to represent and manage these relationships (see Trace Requirements (p. 79)). Traceability proves that every requirement links back to an objective and shows how an objective was met. Traceability does not prove the solution is a cohesive whole that will work."

4 комментария:

  1. Больная тема.
    Различие номер 7 (про стейкхолдеров) очень серьезно. Это, боюсь, главная проблема коммуникации CBAPов (сертифицированных бизнес-аналитиков) и системных инженеров. Из персонифицированной модели стейкхолдеров в BABOKе вытекает классификация требований на business/stakeholder/solution и тут уже я не знаю, как вести дискуссию, кроме как навязать аналитикам концепцию стейкхолдеров-ролей.

    С пунктом 4 различий я не согласен, но, может быть, я не понял мысль. Я понимаю текст из BABOK так, что требования валидируются эксплуатацией системы, тем, что она приносит 'business value'. Как раз по vee диаграмме. Другое дело, что в тексте слова система/решение нет, поэтому можно двояко понять.

    Спасибо, ценная мысль сравнить BABOK и "системное мышление", как оно преподается Левенчуком.

    ОтветитьУдалить
  2. 7. BABOK в явном виде дает понятие concern и viewpoint, через это и надо разговаривать с CBAPами. Это почти системный подход, особенно если начать моделировать 4Д в Архимейте или UML
    4. Давайте переформулирую - BABOK подразумевает, что использующая система проекта всегда предприятие. Очень бюрократический подход, не находите? Т.е., валидация проводится против потребностей генерального директора, правления, акционеров, а не против клиентов.

    ОтветитьУдалить
  3. Я был немного удивлен прочитав "Бизнес-анализ примерно соответствует инженерии требований. " и "Главными артефактами работы аналитика, работающего на основе BABOK является гармонизированный набор требований и логической архитектуры решения."

    Все таки БА - это далеко не только требования. В БА входит выработка решений (дизайн, проектирование) и даже иногда реализация этих решений (управление проектом).
    Главный артефакт БА - это описание самого решения с его обоснованием и планом реализации.
    ПО крайней мере, у меня именно так, да и BABOK это как бы подтверждает: "Business analysis is the practice of enabling change in an enterprise by defining
    needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value."
    "Business analysts play a role in aligning the designed and delivered solutions with
    the needs of stakeholders. The activities that business analysts perform include:
    • understanding enterprise problems and goals,
    • analyzing needs and solutions,
    • devising strategies,
    • driving change, and
    • facilitating stakeholder collaboration."

    ОтветитьУдалить
    Ответы
    1. Покажите мне место в ВАВОК, где показан процесс/практика разработки решения.

      Удалить