Post #484

Ладно, а теперь серьёзно: второй день Flow начинается с двух докладов, в которых есть кое-что общее. Один — рассказ Дениса Котова про метод разработки BPMN. Так и называется: "BPMN — стандарт, но все всё равно рисуют ерунду. Что делать?". Проблема в том, что BPMN — стандарт графической нотации. Что может быть и что не может быть нарисовано. Но как выявлять процесс и его шаги — об этом BPMN не говорит. Не задаёт методику работы. Второй — интерактивный и провокационный — доклад Сергея Нужненко "Как аналитику подняться от уровня «ноги с ушами» и стать инженером". Сергей показывает задачки с собеседований, вроде бы несложные, но на них срезается половина аналитиков. А чтобы не срезаться — вспоминает методы структурного анализа, откуда к нам пришли IDEF0 и DFD, и которые являются именно методами, то есть инструкциями, как действовать, какие шаги выполнять и как результаты предыдущего шага трансформировать на следующем шаге. В этом проблема: если мы возьмем те же UML или BPMN, это будут просто нотации. В случае UML "Три амиго" объединились для унификации нотации: какие графические элементы что означают, какие виды диаграмм имеет смысл выделить. Но они не договорились (и не собирались!) про метод их создания — с каких диаграмм нужно начинать, и какие вообще использовать. Метод у каждого был свой — у Буча имени Буча; у Рамбо — Object-Modeling Technique, OMT; у Якобсона — Objectory или OOSE (кстати, только в нём была Use Case Diagram). UML задумывался как нотация, которая поддерживает любую методологию — хоть одну из начальных, хоть какую-то новую. На практике произошло вот что: UML все начали использовать, но методологий никаких изучать не стали. То же касается интеграций: все уже знают, какими свойствами обладают разные технологии интеграций, и даже изучили OpenAPI и Swagger, но мало у кого есть метод проектирования API. Отсюда часто возникает вопрос: вот я прочитал много книг и статей про UML, юскейсы, API — но не понимаю, как всё это связать? Когда использовать одно, когда другое? В голове какая-то каша. А нужен метод работы! Или, по руководству INCOSE, набор формальных преобразований. Здесь мы с ними сходимся: если вы в принципе готовы рассматривать идею "требований", как отдельно существующих вещей, то эти требования обязаны быть результатом формальных преобразований: Формулировка требования — это итог формального преобразования одной или нескольких потребностей в согласованное обязательство. Это обязательство возлагают на сущность. Суть обязательства — при определенных ограничениях выполнять некоторую функцию или обладать некоторым качеством.