Предыдущая статья о реверсивном анализе требований стала поводом для обсуждения, что побудило меня составить небольшое продолжение к дискуссии. Надеюсь, это поможет создать общее понимание данного аспекта.
Дискуссионное мнение
Область применения реверсивного анализа требований лежит между требованиями к системе и требованиями заинтересованных сторон (ЗС). И Вы точно описали его отличие от реверс-инжиниринга. Добавлю еще одно соображение… Функция реверс-инжиниринга — это восстановление требований по готовой системе. У реверсивного анализа другая функция: по требованиям к системе восстановить бизнес-требования. Отсюда следует, что на вход для проведения реверсивного анализа нужны требования к системе. Они могут быть получены разными способами, в том числе, реверс-инжинирингом существующих систем-аналогов, или разработкой и исследованием прототипов (хотя я плохо представляю ситуацию, когда нужно исследовать только что написанный прототип). Соответственно, прототипирование можно противопоставить реверс-инжинирингу. Но я себе пока не представляю, как можно прототипирование использовать при реверсивном анализе требований.
В обеих статьях и в комментариях к ним используется термин «реверсивный анализ», однако, авторы понимают его по-разному и вкладывают в него разный смысл, а найти общепринятое определение данного термина достаточно сложно. Цель настоящего дополнения – выяснить и аргументировать смысл и роль реверсивного анализа в процессе разработки ПО.
В приведённом выше мнении, как и в предыдущей статье по данной теме, с первого взгляда всё кажется достаточно логичным и обоснованным, но меня насторожила основная идея этих публикаций: восстановление (а по сути разработка) бизнеса (пользовательских требований, если по К. Вигерсу) на основе функциональных требований аналога или прототипа – и это предлагается называть термином «реверсивный анализ».
Т. е. получается, что в этом случае, цель IT-аналитика (включая, бизнес-аналитика), входящего в команду разработчиков ПО, – это не выяснение того, что должна делать программная система в рамках конкретного бизнеса, а наоборот – подгонка самого бизнеса под уже более-менее готовый функционал программной системы…
Таким образом, IT-аналитик берёт на себя обязанности по разработке и координации конкретного бизнеса. Но, извините, это не его «епархия»! Там действуют совершенно другие методы и теория, там другие «гуру».
Задача IT-бизнес-аналитика в том, чтобы донести до бригады разработчиков суть самого бизнеса, а также нужд и потребностей заинтересованных в нём лиц. Задачами анализа и оптимизации бизнеса должны заниматься «канонические» бизнес-аналитики.
Совершенно не желательно смешивать эти две разные по сути специальности. Тогда получается плохой IT-аналитик (остальные члены бригады разработчиков вынуждены за него выполнять огромный объем работ, а престиж и ценность самой специальности падают) и никудышный бизнес-аналитик (в «каноническом» понимании), который своими решениями может навредить бизнесу.
К сказанному можно добавить и следующее: любая методика программного инжиниринга, включая реверсивный инжиниринг и реверсивный анализ, направлена на разработку ПО для бизнеса, а не на разработку самого бизнеса для ПО. Исходя из этого положения, я постараюсь строить свои дальнейшие рассуждения.
Также, в ранее приведённой мною цитате из BABOK, даётся намёк, что реверсивный анализ — это получение требований (не сказано правда, каких именно) из реализации: путём интервью разработчика, чтения кода, тестирования приложения (пер. автора). Т.е. при реверсивном анализе на входе обязательно должна быть реализация системы, из которой впоследствии и выявляются требования к системе. Учтём и это положение для дальнейших рассуждений.
Прямой и реверсивный потоки разработки
Теперь, для достижения цели настоящего дополнения на короткое время отвлечёмся от процессов разработки (водопад, RUP, Scrum и т.д.), от итерационных циклов, от понятий «аналог» и «прототип», а просто представим структуры прямого и обратного инжиниринговых потоков для случаев, когда реализация представляет собой разрабатываемую систему или её часть с работающим программным кодом, и когда в качестве реализации, принимается некий динамический интерактивный прототип, программный код и архитектура которого не имеют отношения к разрабатываемой программе.
В первом случае на входе прямого потока (рис.1) будут пользовательские требования, а на выходе — реализация (действующая программная система и её код — возможно, самая первая отладочная версия системы, которая тоже может называться прототипом).
Рисунок 1 Структура потока разработки в «прямом» программном инжиниринге
Это общепринятая «каноническая» модель программного инжиниринга. Заметим, что смысл пользовательских требований лишь в том, что они являются источником для дальнейшего выявления функциональных требований, а не средством влияния на бизнес или чем-нибудь другим.
В случае реверс-инжиниринга (рис.2) на входе — реализация (действующая программная система и её код), а поток делится на два условно независимых друг от друга направления. По одному из них на выходе будет восстановленная архитектура (по меньшей мере, классы) и, возможно, в чём я не уверен (поэтому стоит знак вопроса), нефункциональные требования или их часть. Архитектуру можно получить, читая и анализируя код, либо используя возможности обратного проектирования в CASE-инструментах. Этот процесс (восстановление архитектуры) называется обратным проектированием. В другом направлении, тестируя приложение через GUI, можно определить функциональные требования или их часть, а восстанавливаемая архитектура, чтение и анализ кода приложения могут оказаться дополнительным источником для их выявления. Восстановление функциональных требований из действующей реализации называется реверсивным анализом, а оба направления, как единое целое, следует называть реверсивным инжинирингом или реверс-инжинирингом.
Рисунок 2. Структура потока разработки в реверсивном программном инжиниринге
Обратите внимание, что реверсивный, как и привычный нам «традиционный» анализ заканчиваются разработкой именно функциональных, а не пользовательских требований.
Теперь рассмотрим ситуацию, где в качестве реализации выступает прототип – динамический, интерактивный, созданный, например, в Axure, или в другой оболочке для быстрого прототипирования (rapid prototyping) или быстрой разработки (RAD – rapid application development), например, в Omnis Studio.
Отличие этой реализации от аналогичной, описанной выше (рис.1 и рис.2) в том, что её код не передаёт особенности архитектуры проектируемой системы, как, например, архитектура робота-терминатора из одноимённого фильма не несёт информации об архитектуре внутренних органов человека, на которого он похож. Поэтому в этом случае уже не получится ни прямого, ни обратного проектирования (рис. 3, рис. 4), а понятия реверсивный анализ и реверсивный инжиниринг окажутся практически синонимами.
Примечание. Прошу уважаемых коллег снисходительно отнестись к следующим двум рисункам и терминологии на них. Терминов «прототип-инжиниринг» и «реверсивный прототип-инжиниринг» не существует, они введены, чтобы подчеркнуть аналогию с общепринятыми программный инжиниринг и реверсивный программный инжиниринг. Далее эти термины применяться не будут.
Термин «прототип-имитатор» введён искусственно, для того, чтобы подчеркнуть отличие прототипа, являющегося релизом разрабатываемой программной системы, от прототипа, представляющего исключительно её поведение (созданного, например, в Axure).
Рисунок 3. Структура потока разработки в «прямом» прототип-инжиниринге
Рисунок 4. Структура потока разработки в реверсивном прототип-инжиниринге
При рассмотрении обоих реверсивных потоков разработки мы видим, что независимо от реализации (реальный программный код или прототип, демонстрирующий функционирование GUI), содержание реверсивного анализа не изменяется — он начинается с реализации по которой затем восстанавливаются функциональные требования.
Вывод 1. Отличие обычного «традиционного» анализа от реверсивного в том, что первый в качестве источника функциональных требований использует пользовательские требования, а второй реализацию разрабатываемой программной системы.
Вывод 2. Разработка полного комплекта детальных функциональных требований, полностью соответствующих реальным потребностям ЗЛ – это основная задача анализа программных систем, независимо от того, используем ли мы реверсивный инжиниринг или нет, а также от того, что используется в качестве источника (пользовательские требования, первичная реализация системы, прототип и т.д.)
В каких случаях применяется реверсивный инжиниринг (реверсивный анализ)?
- Его можно и нужно применять, когда источник (пользовательские требования) не даёт всей полноты информации, достаточной для разработки функциональных требований;
- Если имеется устаревший релиз программной системы, который не соответствует актуальным пожеланиям пользователей, и требуется изменить его функционал и архитектуру;
- Отличие реверсивного инжиниринга от «традиционного» только в источнике для разработки функциональных требований. Если в начале разработки информации достаточно, чтобы практически сразу создать прототип и, используя последний, в тесном взаимодействии с пользователями разрабатывать функциональные требования, а по ним и саму программную систему, то по каким причинам следует от этого отказываться? Похожий принцип используется в Scrum.
Мысли к дискуссии
Ниже я постараюсь отразить своё мнение по некоторым положениям из постов уважаемых коллег аналитического сообщества. Чтобы меня не обвинили в предвзятости, я не буду писать имена и ставить ссылки на пост, надеюсь этим я не нарушу авторских прав и не обижу участников. Здесь важна не сама личность, а предлагаемая методика…
Дискуссионное мнение 1
Грубо говоря, заказчики и пользователи плохо представляют, чего они хотят. Вот в таких ситуациях реверсивный анализ позволяет продемонстрировать ЗС, чего они могут хотеть.
Думаю, не совсем так. Возможно, правильнее сказать: заказчики и пользователи плохо представляют, как программная система может помочь им в рамках их бизнеса, в таких ситуациях реверсивный анализ (прототип) позволяет продемонстрировать возможности системы и предоставить выбор использовать ли эти возможности или предложить другие.
Дискуссионное мнение 2
В случаях, когда технология разработки системы предусматривает разработку и демонстрацию прототипа заинтересованным сторонам, происходит частичная аннигиляция этапа работы с системными требованиями. Зачем ЗС изучать требования к системе, если они сразу могут увидеть работу будущей системы и оценить будущий результат?
Происходит не «частичная аннигиляция этапа работы с системными требованиями», а лишь упрощение этапа работы с пользовательскими требованиями, уменьшение формализма, с ними связанного. Всё, что касается функциональных требований здесь остаётся в силе!
Дискуссионное мнение 3
Динамика в прототипе — это конечно вау-вау, но потом надо доносить до заказчиков/разработчиков/тестировщиков, как оно работает. Они не должны занимать реверс-инжинирингом прототипов (вида «Так, а если ткнуть сюда, то что будет?»).
Так как мнение высказывалось по отношению к прототипам, созданным в Axure, то именно по ним постараюсь дать аргументированный ответ. Во-первых, в самой Axure имеются широкие возможности для ввода текстовых пояснений и графических материалов непосредственно в html-прототипы, например, к каждому элементу можно подсоединить дескриптор с текстом, можно спрятать подробные инструкции в динамических панелях и показывать их только по клику или по наведению мыши, можно, аналогичным образом, вводить диаграммы, подключать видео- и звуковые файлы – масса возможностей о которых лучше не читать, а пробовать. Но мне нравится ещё одна интересная возможность – использование мультимедийного редактора Snagit. Выводите на монитор html-прототип, запускаете Snagit, после чего выполняете в прототипе желаемые операции и комментируете их голосом, а редактор всё сохраняет в файле MPEG.
P.S. Буду рад Вашим отзывам, включая критику, замечания и предложения. Имею лишь одно пожелание, как приговорённый к высшей мере, давайте будем оценивать предлагаемые методики и технологии, а не конкретные личности, включая мою, пусть наши оценки и характеристики останутся прерогативой наших начальников.
Автор:
Николай Киреев,
старший преподаватель ИИТ БГУИР,
индивидуальный предприниматель (разработка ПО, студия информационных технологий WebMax.BY), руководитель проектов, аналитик (freelancer)
Skype: nousy123
Николай,
в статье я постарался четко определить проблему, для решения которой применяется реверсивный анализ требований — это ситуация, когда по каким-то причинам бизнес-аналитик не может выявить в полном объеме бизнес-требования. Учитывая, что ошибки на ранней стадии очень дорого обходятся в проекте, проблема неполных бизнес-требований является особенно актуальной.
Реверсивный анализ позволяет сформировать бизнес-требования, восстанавливая их из аналогов и др. источников. Это не означает, что восстановленные бизнес-требования без согласования с заинтересованными сторонами утверждаются как окончательные. Если по-простому, то в результате использования реверсивного анализа у бизнес-аналитика появляется возможность преобразовать коммуникации с заинтересованными сторонами из формата «что вы хотите? — на знаем» в формат «вы хотите, чтобы ваша бизнес-система после внедрения ИТ работала так? — да (или нет)».
Итак, цель реверсивного анализа состоит не в том, чтобы «восстановить бизнес», а в том, чтобы получить бизнес-требования в полном объеме. Достижение этой цели позволит минимизировать риск того, что полученная в результате ИТ-система не будет соответствовать бизнесу, для которого она предназначена, что повышает шансы на успех проекта.
Уважаемый Андрей, прежде всего большое спасибо за интерес к дискуссии и за высказанное Вами мнение.
Возможно, в своей статье и в последующем дополнении к ней я не смог обратить Ваше внимание на тот факт, что и в случае (рис.2), когда реверсивный инжиниринг выполняется на основе прототипа, представляющего собой реальную реализацию базовой функциональности (с соответствующей архитектурой и кодом приложения; так была задумана эта методика изначально т.е. исторически), и в случае (рис. 4), когда прототип лишь имитирует поведение разрабатываемой программной системы, результатом реверсивного анализа является разработка и уточнение именно функциональных требований, которые являются более конкретными и детальными, чем выше стоящие по уровню абстракции (см. К. Вигерс) пользовательские требования (бизнес-требования). Более того, именно на основе функциональных системных требований, а не на основе абстрактных бизнес-требований производится дальнейшее проектирование архитектуры (логических и физических структур приложения).
В связи с этим, у меня возникает вопрос: для кого и с какой целью бизнес-аналитик должен из конкретных и детальных функциональных требований выявлять более абстрактные бизнес-требования? При ответе прошу учесть тот факт, что сторона пользователей при этом получает не список (спецификацию) функциональных требований, в котором она действительно, возможно, не сможет разобраться, а действующую реализацию (прототип), по которому можно протестировать поведение системы и определить не только его соответствие их бизнес-требованиям, но и в какой-то степени соответствие принципам UX.
Уважаемый Николай,
я не совсем понимаю, почему Вы противопоставляете функциональные требования и бизнес-требования. Если Вы уж ссылаетесь на Вигерса, то у него бизнес-требования тоже относятся к категории функциональных.
Раз уж речь зашла о функциональных требованиях, то давайте разберемся с этой коллизией в рамках функционального анализа (ФА).
С точки зрения ФА ИТ-система является частью бизнес-системы, выполняет в бизнес-системе определенные функции. И наоборот, для ИТ-системы бизнес-система является над-системой. Соответственно, и ИТ-система и бизнес-система выполняют какие-то функции, причем функции ИТ-системы нужны для выполнения функций бизнес-системы. Очевидно также, что функции ИТ-системы не равны функциям бизнес-системы.
С точки зрения ФА цель реверсивного анализа состоит в том, чтобы определить, какие функции выполняет система. Примененный к ИТ-системе реверсивный анализ сводится к известному уже реверс-инжинирингу. Но область действия реверс-инжиниринга не распространяется на бизнес-системы. Здесь было пустое место, которое и было заполнено реверсивным анализом требований.
Еще раз, с точки зрения ФА реверс-инжиниринг восстанавливает функции ИТ-системы, а реверсивный анализ требований — функции бизнес-системы на основании функций ИТ-системы.
Теперь отвечаю на Ваш вопрос: для кого и с какой целью бизнес-аналитик должен из конкретных и детальных функциональных требований выявлять более абстрактные бизнес-требования?
Бизнес-аналитик восстанавливает бизнес-требования для заинтересованных сторон, которые связаны с бизнес-системой. Он делает это потому, что этим заинтересованным сторонам понятны бизнес-требования (например, сформулированные в виде функций бизнес-системы), но могут быть непонятны функциональные требования (функции) ИТ-системы.
Уважаемый коллега, извините пожалуйста, но я ни в коей мере и нигде не «противопоставлял» пользовательские требования (userrequirements у Вигерса, в Вашей статье, они вполне оправданно, называются бизнес-требованиями) низкоуровневым функциональным требованиям (functionalrequirements) и нигде не высказывал малейших сомнений в принадлежности первых к группе функциональных требований. Я только пытался донести мысль, что пользовательские требования следует рассматривать лишь в контексте источника для разработки функциональных требований, а не наоборот.
К сожалению, приведённый в конце Вашего поста ответ на мой вопрос по поводу целесообразности восстановления пользовательских требований из функциональных меня не вполне устраивает, т. к. в нашем случае имеется действующий прототип, тестируя который ЗЛ могут самостоятельно определить на сколько функциональные требования разрабатываемого приложения соответствуют пользовательским и высокоуровневым бизнес-требованиям (businessrequirementsпо Вигерсу).
И в любом случае, если мы имеем достаточно полные согласованные функциональные требования, то можно сразу переходить к проектированию и реализации системы, не теряя времени на восстановление и/или разработку пользовательских требований.
В принципе, свою позицию по поводу понятий «реверсивный инжиниринг», «реверсивный анализ» я изложил, нового добавить мне нечего. К сожалению, или к счастью, Ваши доводы не заставили меня изменить свои взгляды, поэтому, всецело уважая Ваше мнение, остаюсь при своём.
Только сейчас увидел, что при вставке текста из блокнота на сайт странным образом исчез пробел в латинских названиях (user requirements и т.д.) Коллеги не сочтите, пожалуйста, это за мою ошибку — техническая накладка!
Николай,
я не согласен с Вашим тезисом, что
Задача IT-бизнес-аналитика в том, чтобы донести до бригады разработчиков суть самого бизнеса, а также нужд и потребностей, заинтересованных в нём лиц. Задачами анализа и оптимизации бизнеса должны заниматься «канонические» бизнес-аналитики.
Для поддержания дискуссии попробую сформулировать свою точку зрения:
когда мы рассматриваем кейс «разработка и внедрение ИТ-системы по заказу бизнеса», мы должны понимать, что бизнес-система заказчика тоже меняется. Успех проекта в такой ситуации оценивается не только и не столько по таким факторам, как «в срок и без превышения бюджета». Ключевым фактором успеха является: бизнес-система после внедрения ИТ-системы стала лучше. Бывают случаи, когда проект выполнен точно в срок, но ИТ-система не сделала бизнес-систему лучше. Возникает закономерный вопрос: где и между кем проходит граница ответственности и компетенции?
Ответ есть в методологии бизнес-анализа, где выделяются роли
а) бизнес-аналитика, который отвечает за бизнес-систему в целом и решения по ее улучшению;
б) системного аналитика, который отвечает за ИТ-систему и ее соответствие установленным бизнес-требованиям.
Ни о каком ИТ-бизнес-аналитике упоминания я не встречал. Возможно, вы имели ввиду человека, который частично совмещает роли бизнес-аналитика и системного аналитика и, соответственно, принимает на себя только часть ответственности этих ролей в проекте. Если это так, то это явно не стандартный для бизнес-анализа кейс, полезность которого весьма сомнительна.
Вопрос должны ли разработчики ПО нести ответственность за то, улучшилась ли после внедрения ПО бизнес-система в целом или нет, достаточно сложный и далеко не однозначный. Тут возникает очень много факторов, включая разработку оценочных критериев приёмки всей бизнес-системы, а не только ПО.
Разработка/оптимизация всей бизнес-системы (включая разработку ПО) — это совершенно другой уровень, чем отдельная разработка ПО. В этом случае, следует предусматривать, соответствующие ресурсы, критерии приёмки, другие оценки рисков и т. д., а договор, который заключается с заказчиком, должен быть именно на разработку/оптимизацию всей бизнес-системы.
Таким образом, моё мнение, следующее: если у нас договор на разработку ПО, то необходимо скрупулёзно, точно, по возможности вложившись в срок и бюджет, разработать ПО, максимально полно соответствующее (по оговоренным критериям приёмки) реальным требованиям заказчика и ответственность за улучшение/ухудшение бизнес-системы в целом лежит на стороне заказчика; если договор заключен не только на ПО, а на разработку/оптимизацию бизнес-системы в целом, то соответственно вся ответственность лежит на исполнителе.
По поводу ИТ-бизнес-аналитика. Несколько удивлен, что Вам это название еще не встречалось… Передо мной лежит журнал Российского Отделения IIBA, который называется «IT Business Analysis», как-то на http://www.dev.by мне попалась вакансия от SaM Solutions на IT Business Analyst и т. д.
Я вкладываю в это понятие исключительно специализацию бизнес-аналитика, в моём контексте, это тот бизнес-аналитик, который задействован при разработке ПО. Естественно, есть и другие бизнес-аналитики (например, http://analyst.by/forum/obschie-voprosy/odnobokoe-otrazhenie-pozitsii-biznes-analitika), которые решают совершенно другие задачи и используют другие методологии. Точно также, как и у врачей, мало кто захочет, чтобы его детей лечил доктор Айболит – ветеринар-педиатр!
Цитата из статьи Избегайте «мертвой зоны» в бизнес-анализе:
«Если вы когда-либо ловили себя на мысли, что вы знаете бизнес лучше тех, кто в этом бизнесе варится, вы, возможно, находились в этой самой «мертвой зоне». Такая тактика может привести к пропущенным или неверно сформулированным требованиям. Несомненно, крайне полезно знать бизнес-область проекта, однако помните, что вы как бизнес-аналитик, в первую очередь являетесь связкой между бизнесом и ИТ, а не SME (Subject Matter Expert, эксперт в предметной области).»
Приведённая выше цитата полностью даёт ответ кто несёт ответственность за улучшения бизнес-системы. Я эту мысль полностью поддерживаю и стараюсь всегда ей следовать.
А я вот вспомнил бессмертное произведение Аркадия Райкина и его крылатую фразу: »К пуговицам претензии есть?»
Дык в чём проблема? Если платят за весь пиньжак (включая разработку/оптимизацию бизнеса), то получитес… всё в комплекте, а я буду заботиться чтобы спецов правильных подобрать (в том числе бизнес-экспертов, тех, которые в ентом бизнесе сами варятся, а не только из тех кто лишь требования в спецификацию сводить умеет…), но и заплатить соответственно придётся, тогда я ответственность и за бизнес, и за прогу на себя возьму. А если денежки жалко и заказец только на программу, то и бизнес-аналитик в строго определённых рамках работать должен и прилагать все усилия, чтобы с его участием как можно быстрее и качественнее адекватную архитектуру системы разработали, а после её в коде программном реализовали. И нате вам программу в точности, которую заказывали, а если что ещё надо, то нет проблем за дополнительную плату.
Дык а если бизнес-аналитик видит, что пиджак кривой? Что делать? Пуговицы на кривой пиджак пришивать или нет? Будет ли толк от пуговиц на кривом пиджаке и чувство глубокого внутреннего удовлетворения от проделанной работы?
Важно, не то, что видит бизнес-аналитик, который сам никогда в данном бизнесе и в данных конкретных условиях не работал, а то как к этому относится заказчик — главный эксперт в своём бизнесе. Сделайте ему предложение, а он решит под свою ответственность использовать его или нет, инвестировать ли в это дополнительные финансы или нет. Я скажу более того, достаточно часто бывает ситуация, когда даже истинные цели разрабатываемого ПО скрыты от разработчиков и у меня лично такие ситуации были.
Т.е. пуговицы шикарные, заказчик доволен и платит за них, а уж как будет выглядеть с ними пиджак — это не входит в границы ответственности производителя пуговиц
см. http://analyst.by/articles/k-voprosu-o-reversivnom-analize-trebovaniy-prodolzhenie#comment-665
Коллега, с пуговицами всё понятно, если мне заказали пуговицы, то я постараюсь в тесном взаимодействии с заказчиком сделать их подходящими под данный пиджак, но при этом, я не возьму на себя ответственности за весь пиджак в целом, даже если он кривой.
Этот пример для нашего обсуждения не очень показательный. Приведу другой: допустим, дирижёр симфонического оркестра заказал мне жилетку… Я подумал, сделал углублённый анализ его бизнеса и решил, что жилетка не очень-то для него подходит и лучше вместо жилетки сшить ему фрак… Как Вы думаете скажет он «Ва-а-у!!!»?