Предлагаю высказать своё мнение о данной статье: http://www.interface.ru/home.asp?artId=4822

На Ваш взгляд, стоит ли на неё опираться при проведении обследования предметной области и составлении документа описания предметной области?

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

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

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

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

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

Рисунок 9 тоже довольно странный, т.е. он далек от прагматики использования этой диаграммы

Спасибо за отзыв!
Эдуард, Мне тоже показалось, что некоторые диаграммы приведены с ошибками.

Спасибо за отзыв!
Эдуард, Мне тоже показалось, что некоторые диаграммы приведены с ошибками.

Вот почитайте, если интересно: Смерть от UML иUML лихорадка – диагностика и лечение

Вот почитайте, если интересно: Смерть от UML иUML лихорадка – диагностика и лечение

Эдуард, спасибо за ссылки! Обязательно ознакомлюсь.

Возник вопрос: "Корректно ли такое сравнение, указанное в статье, что бизнес-требования - это виды деятельности, которые необходимо автоматизировать?"

Возник вопрос: "Корректно ли такое сравнение, указанное в статье, что бизнес-требования - это виды деятельности, которые необходимо автоматизировать?"

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

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

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

Вот почитайте, если интересно: Смерть от UML и UML лихорадка – диагностика и лечение

Эдуард, весьма поучительные и актуальные сведения, особенно для начинающих.
Кстати, интересно бы было выслушать мнение Дениса Иванова по поводу содержания данных статей.

Предлагаю высказать своё мнение о данной статье: http://www.interface.ru/home.asp?artId=4822

На Ваш взгляд, стоит ли на неё опираться при проведении обследования предметной области и составлении документа описания предметной области?

Нет не стоит.
Авторы слишком узко и односторонне рассматривают задачу.
Явные пробелы в области бизнес-моделирования и бизнес-процессах.

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

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

Полноценно "Описать БП" с помощью "activity diagram" - нельзя. Можно описать последовательность выполнения функций или подпроцессов бизнес-процесса.

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

Качество представленной картинки недостаточно чтобы понять что на данном примере в заголовках SWIMMER-LANE, и что написано в комментариях соединенных с "деятельностями".
Но вполне достаточно чтобы увидеть все activity выполняются в рамках одного подразделения, что никакую передачи "управления" между подразделениями на диаграмме не отображено. Где исполнители, где подразделения?

"Следует отметить: наш значительный опыт при описании бизнес-процессов с использованием различных CASE-средств, например, BPwin, Silverrun, Process Analyst и Rational Rose показал, что наиболее понятным описанием бизнес-процессов для обсуждения его с экспертами предметной области и получения от них конструктивных замечаний является представленная выше нотация в CASE Rational Rose."

Такая нотация не дает представления о том какие бизнес процессы происходят в компании.
Наиболее концептуальными методологиями для описания БП являются SADT и ARIS.
Кстати даже использование Flow Diagram, Cross-functional Diagram  и Basic Flowchar (блок-схема) и то более информативно. В этих нотациях больше количество элементов, чем в activity diagram
 
UML для описания БП приспособлен в наименьшей степени.

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

Вообще то выделение "сущностей" наоборот выполняется на самых ранних этапах анализа БП и предметной области.
Для этого предназначены диаграммы классов анализа, диаграммы классов и диаграммы объектов.

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

Думаю, что необходимо учитывать, что статья была написана 10 лет назад. А за 10 лет был совершен большой прорыв не только в методиках описания БП, разработке средств моделирования и т.п.

Продолжим "критику"
Рис. 2-6. Не понятно в чем смысл этих "картинок". Это фрагменты диаграмм пакетов?
Почему тогда не привести пример рисунка полностью диаграмма пакетов классов, диаграмма пакетов вариантов использования.
На диаграмме пакетов классов отобразить соответствующие ассоциации, например композиции между пакетами на рис 3. и пакетов на рис. 2.
Где рисунок с содержимым этих пакетов?
Где собственно диаграмма классов показывающая иерархию организационной структуры?

Думаю, что необходимо учитывать, что статья была написана 10 лет назад. А за 10 лет был совершен большой прорыв не только в методиках описания БП, разработке средств моделирования и т.п.

SADT и ARIS появились раньше чем UML, и как я уже упоминал выше, на мой взгляд являются более концептуальными и пригодными для моделирования бизнес-систем.
За 10 лет в этих методологиях мало что поменялось.
Вообщем новичкам, желающим разобраться с бизнес-процессами, рекомендую не изучать сомнительные статьи специалистов которые умеют "что то рисовать в CASE-средствах".
А начать с азов:
http://ru.wikipedia.org/wiki/ARIS
http://idefinfo.ru/