Use Case Diagrams

Интересно, это только я думаю, что Use Case Diagram в UML - вещь не только бессмысленная, но и вредная?

Что перечень сценариев и вовлеченных ролей проще и понятнее описывать в виде таблицы?

Что UCD без детального описания сценариев не имеет смысла, а с описанием - избыточна?

Что с заказчиком диаграммы Use Case непосогласовываешь?

Что отношения сценариев использования на обзорной таблице абсолютно бессмысленны и дезориентируют, что их лучше описывать непосредственно в описании сценария?

Сравнительный анализ современных .net ORM

Задача

Необходимо было аргументированно выбрать ORM для большого .Net проекта. Рассматриваемые (пока) ORM: Entity Framework, BLTooklit, SubSonic.

Результат

* Аналитический отчет
* Сводная таблица с баллами, набранными каждой из ORM

Ваша критика/пожелания приветствуется. Надеюсь продолжить этот опыт и рассмотреть еще и другие (не менее интересные ORM)

100% of requirements in spec?

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

http://stump-workshop.blogspot.com/2008/03/100.html

Человеческий фактор в проектировании систем. Otvety.*.ru

Вот есть две системы - http://otvety.mail.ru/ и http://otvety.google.ru/

Одна - интересная, удобная и полезная, а другая - бесполезная, некрасивая, дурацкая.

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

Домашнее задание: почему получились такие разные результаты?

"При переходе в раздел осуществляется переход в раздел"

Читаю спецификацию, которую создали крутейшие системные интеграторы, зубры-динозавры.

п 1.2.3 Требования к разделу «Управление справочником действий»

При переходе пользователя в раздел «Управление справочником действий» должен осуществляться переход на страницу «Управление справочником действий».

Покалеченные люди, бедный их русский язык.

Лучший способ определить предметную область (domain) проекта

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

Предметную область надо обсуждать с юристами заказчика. Они часто разбираются в терминах гораздо лучше самого заказчика (и - главное - непротиворечиво!)