Комментарии 16
Подход понравился, надо будет посмотреть детальнее.
По мелочам. В (непронумерованной в числе остальных :) ) схеме "Процесс системного анализа" после ревью надо ли откатываться сразу в самое начало? Заранее причина неудачного ревью неизвестна, её надо валидировать, а это - шаг "Self-check"
не требует глубокого знания UML от системных аналитиков
На практике беда в том, что важны на таких схемах как раз детали: формы стрелок, правила описания данных / логики. Аналитиков надо учить соблюдать кучу глубоких, но важных формальных требований к оформлению такой диаграммы, если они решили в ней что-то исправить. Или хотя бы прочитать, вникнув до конца во все нужные им процессы.
Есть ощущение, что на практике такое применяют только на совсем огромных масштабах из-за того, что UML - вещь абстрактная, четкого стандарта того, как фичи должны работать в нем, нет. Кто-то пишет текстовую декларацию, кто-то привык стрелки раскидывать. У всех не очень совместимые друг с другом версии UML. Поэтому использование UML'ом надо вводить в компании с огромным гайдом по нему и учить пользоваться строго определенным софтом. То есть все-равно примерно с нуля придется создавать язык, на котором будут описаны диаграммы.
При таком раскладе уже проще взять "рисовалку квадратиков-стрелочек" с интерфейсом полегче и определиться, какие формы/цвета/размеры/border'ы у стрелок что значат, написав под это док. UML убивает отсутствие стандартизации :(
Мой опыт говорит, что вот такой подход, желание описать все, соблюсти все правила UML и перфекционизм в рисовании диаграмм, вместо перфекционизма в передаче требований и приводит к скатыванию к попыткам замены разработки нормальных полноценных моделей требований на описание системных требований в виде нумерованных списков в документах типа BRD или в тикетах в Jira/Redmine/etc
Довольно иронично, что в статье, посвященной преимуществам UML, диаграмма процесса системного анализа нарисована в нотации BPMN
Почему требуется планарность графа для диаграммы предметной области? Какие проблемы повлечёт непланарность?
Об этом, думаю, рассказать в отдельной статье, но если кратко - не планарность означает дублирование вычисляемой связи, обычно это говорит о не полном или не корректном понимании аналитиком реальной связи между объектами. Нарушение планарности нужно при проектировании ДБ, например, а точнее для оптимизации нагрузки при проектировании ДБ.
Из минусов подхода можно выделить два:
1. Заказчиков все еще нужно заставлять читать требования и читать им придется, водя пальчиком по диаграммам, иногда возвращаясь к развилкам, вместо зачастую более привычного им текста и списков.
Первый же минус ставит крест на подходе процентах в 70-80 случаев, а если речь идет о крупных заказчиках, то в 99%. потому что заставить заказчика что-то сделать почти нереально, у многих есть свои процессы, свои документы и шаблоны и свои подходы и ни один заказчик не будет подстраиваться под ваши процессы, если вы не безальтернативный монополист.
Ваши заказчики не согласовывают ТЗ ни в каком виде? Если не секрет, как вы актируете работы в таком случае?
Вчера на собесе в одну хорошую (без иронии) компанию (работает с госами) рассказал старшему аналитику ровно это же. А от меня ждали перечень конкретных диаграм, которые я должен показать заказчику.
К тому, что даже в опытных, казалось бы, компаниях есть какие-то детские болезни.
С другой стороны, специфика заказчика не должна отменять внутренние процессы описанного в статье анализа. Это надо для проекта/продукта
Подход к системному анализу