Комментарии 7
Есть входные данные (живой мамонт), есть бизнес-процедура с копьями и стрелами, есть мертвый мамонт.
Вы правда считаете, что бизнес-аналитик описал бы процесс так?
У делопроизводителя лучше. Почему?
Потому что вы играете на его стороне.
Потому что первый строит модель на основе объектов, а второй на основе процессов.
Потому что первый мыслит существительными, а второй глаголами.
Это какие-то выдуманные вами разделения. Хороший аналитик мыслит бизнес-процессами, смоделированными в нескольких представлениях, из которых одно — сущностное, другое — по действиям, третье — по сценариям, четвертое — по акторам и так далее.
Недавно один профессионал в части построения систем с полной уверенностью заявил мне, что бухгалтерский счет не является документом. [...] Насколько же глубоко в мозги должно засесть процессо-ориентированное мышление, чтобы основание для платежа с номером, датой, подписями не считать документом, а считать одной из отчетных форм процесса.
Добро пожаловать в мир тщательно выкопанных ям-ловушек (их изобрели вместе с охотой на мамонтов). В оригинальной фразе было написано «счета и проводки — не документы». А знаете, почему? Потому что вы под счетом понимаете документ на оплату предоставленных услуг/товаров, а фраза — счет в банке или другой кредитной организации. Такой, знаете, с которого деньги списывают, зачисляют и так далее.
Бизнес-аналитик: Заявка – это процесс.
Собственно, наглядная демонстрация всей вашей статьи: вы выдумали себе некоего идеально плохого бизнес-аналитика и идеально хорошего делопроизводителя, и сравниваете их.
Поэтому давайте немножко уравняем шансы, и за бизнес-аналитиков будет играть не вы, чтобы не было поддавков (заодно вы еще и пытаетесь автоматизировать процесс, который я знаю наизусть):
1. Заявка — это сущность, инициирующая бизнес-процесс.
ДП: Заявка может иметь документ-основание: например входящее письмо, расписанное на исполнителя с резолюцией «Прошу извести жука и дать ответ заявителю». Это значит, что ответ заявителю будет на нее ссылаться.
Б-А: ну и что? Вот такой у нас процесс.
2. Сущность заявка действительно может быть связана с сущностью документ-основание, но это зависит от процесса (и я не знаю ни одного процесса управления ошибками, где был бы выделенный документ-основание). Скорее всего, это разделение избыточно, и достаточно говорить о заявке, у которой может быть сложный атрибутивный состав.
ты не понимаешь. Входящий сканируют и присоединяют, статус процесса меняется, начальник должен наложить резолюцию…
Этого в управлении ошибками не бывает, поэтому пропускаем весь кусок.
Заявку рассматривает руководитель проекта и расписывает на исполнителей.
Прекрасно.
резолюция достаточно сложный объект: она содержит текст, фамилии, сроки, срочность и пр. Кроме того, резолюций может быть несколько, и у каждой будет свой жизненный цикл. А документом я ее называю, потому что после сохранения она должна стать неизменяемой.
В управлении ошибок это формулируется совершенно не так.
3.
Вариант (1), простой: заявке напрямую назначается ответственный, он же является исполнителем.
Вариант (2), сложный: заявке напрямую назначается ответственный, создаются дочерние задачи, каждая из которых назначается на исполнителя.
Требований на неизменяемость в управлении ошибками обычно нет, а вот требования на историчность — есть.
Исполнитель начинает работу по изведению жука.
Бизнес-аналитик: Работа – это процесс. Любого спроси.
Пользователь: Ты прав.
Делопроизводитель: в базу записывается не работа, а отчет о работе (начало, содержание, процент выполнения) – а это документ. [...]
Б-А: Какой-такой доко-бд-монго-дб? База должна быть реляционной и три раза нормализованной. Посмотри вокруг: большинство систем в мире создано нами.
Тут, надо заметить, и делопроизводитель, и аналитик совершили непозволительную ошибку — начали навязывать реализацию до завершения анализа, хотя это не их компетенция. Но не важно.
4. Заявка (в формализованном процессе — задача по заявке) перешла в статус «в работе» и позже — «выполнена».
Все, большая часть анализа по вашему процессу завершена. Описываем сущности, сценарии использования — получаем требования на систему.
И, заметим, никакой — вообще никакой — объектно-ориентированности (ни с какой стороны). Потому что ООП — это парадигма проектирования, а не анализа.
Недавно один профессионал в части построения систем с полной уверенностью заявил мне, что бухгалтерский счет не является документом.
В чем я его полностью поддержу. Думаю, это терменологическая путаница. Бухгалтерский счет (синтетический, аналитический) документом не является. А вот счет, выписываемый на оплату — безусловно документ, как документом может быть и выписка по счету.
Модель мира (неважно, большого или малого) может быть реализована только в документо-ориентированной базе данных.
Что-то я по первому чтению пропустил этот пункт.
Я надеюсь, вы можете обосновать это — без сомнения, смелое — утверждение? Я же правильно понимаю, что вы имеете в виду, что любая модель, для любых целей может быть реализована только в документо-ориентированной БД? Или, если вы имели в виду что-то другое, то что именно?
Мир состоит из коллекций объектов, а не из прямоугольных таблиц.
Почему, я не знаю.
Свойства объекта удобнее хранить как документ, а не как строчку в таблице.
Если бы замечательный артефакт «1С» имел документо-ориентированную основу,
доработка 1С не была бы самой востребованной работой для программиста в России.
Это мое скромное мнение.
Почему, я не знаю.
Свойства объекта удобнее хранить как документ, а не как строчку в таблице.
Если бы замечательный артефакт «1С» имел документо-ориентированную основу,
доработка 1С не была бы самой востребованной работой для программиста в России.
Это мое скромное мнение.
Мир состоит из коллекций объектов, а не из прямоугольных таблиц.
Ну вообще — нет, не состоит. Уже термин «коллекция» — это абстракция, которой в мире нет.
Свойства объекта удобнее хранить как документ, а не как строчку в таблице.
Удобнее для чего?
Вы правда искренне не понимаете, что модель определяется задачей, и для одной задачи подходит одна модель, а для другой — другая?
модель определяется задачей
Увы, это заблуждение.
Модель определяется тем, кто ее строит, его пониманием задачи.
для одной задачи подходит одна модель, а для другой — другая
об этом и речь. О том, что документо-ориентированные задачи загоняют в реляционные таблицы.
Увы, это заблуждение.
Модель определяется тем, кто ее строит, его пониманием задачи.
для одной задачи подходит одна модель, а для другой — другая
об этом и речь. О том, что документо-ориентированные задачи загоняют в реляционные таблицы.
модель определяется задачей
Увы, это заблуждение.
Модель определяется тем, кто ее строит, его пониманием задачи.
Это, к сожалению, демагогия. Модель определяется именно задачей, понимание того, кто ее строит — не более чем посредник.
О том, что документо-ориентированные задачи загоняют в реляционные таблицы.
Вы выше говорили, что любая модель для любой задачи может быть реализована только в документо-ориентированной БД. Нет, я неправильно вас понял?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объектно-ориентированная охота на мамонта (записки делопроизводителя)