Следующая глава Model Driven Engeneering книги Software & System Requirements Engineering in Practice посвящена моделированию, его разновидностям, назначении и ошибкам. Что особенно бросилось в глаза и показалось очень разумным, так это разделение моделирования и работы с требованиями. Другими словами, модель - средство анализа, на основе которого формируются требования. Модель - картинка или диаграмма в CASE средстве. Требования - записи в базе данных. Отлично, если модель и требования могут храниться в одной системе в связном виде, но чаще это разные средства и связи (трассировки) приходится поддерживать вручную, увы.
Модель не может заменить требования (интересно, как вы будете по модели тестировать или разбивать модель на итерации). Да, специалисты-аналитики понимают, что написав требования без моделирования, мы не можем сами себя проверить ни на полноту, ни на непротиворечивость этих требований, ни отследить взаимосвязи и т.п. Но модель - это скорее средство анализа, наша внутренняя профессиональная кухня. Потребители наших артефактов ждут в первую очередь требований.
Конечно, в книге на этом аспекте не так много внимания заострено, просто авторы четко разделяют понятия модели и требований. Почему я так акцентирую на этом внимание? Потому что по моим наблюдениям и опыту мы, аналитики, очень часто путаем цель и средство. Нам очень нравится рисовать картинки с юзкейсами-"яичками" и очень скучно писать формальным языком настоящие требования. А потому мы сетуем, что так мало людей понимают такой "интуитивно понятный" UML, не всегда осознавая, что это еще не требования.
Mind map главы как обычно прилагается. Интересно обратить внимание на список типичных ошибок, которых следует избегать в моделях, а также на признаки готовности модели. Это можно использовать в работе для (само)контроля качества.
Часть 2
Часть 1
Модель не может заменить требования (интересно, как вы будете по модели тестировать или разбивать модель на итерации). Да, специалисты-аналитики понимают, что написав требования без моделирования, мы не можем сами себя проверить ни на полноту, ни на непротиворечивость этих требований, ни отследить взаимосвязи и т.п. Но модель - это скорее средство анализа, наша внутренняя профессиональная кухня. Потребители наших артефактов ждут в первую очередь требований.
Конечно, в книге на этом аспекте не так много внимания заострено, просто авторы четко разделяют понятия модели и требований. Почему я так акцентирую на этом внимание? Потому что по моим наблюдениям и опыту мы, аналитики, очень часто путаем цель и средство. Нам очень нравится рисовать картинки с юзкейсами-"яичками" и очень скучно писать формальным языком настоящие требования. А потому мы сетуем, что так мало людей понимают такой "интуитивно понятный" UML, не всегда осознавая, что это еще не требования.
Mind map главы как обычно прилагается. Интересно обратить внимание на список типичных ошибок, которых следует избегать в моделях, а также на признаки готовности модели. Это можно использовать в работе для (само)контроля качества.
Часть 2
Часть 1
Комментариев нет:
Отправить комментарий