Цитаты из книги «Набор серебряных пуль»

На данный момент наиболее известны следующие типы диаграмм (см. сайт [9], книгу [2]): – Class (классов) – иерархии классов– Object (объектов) – взаимодействия объектов в run-time, связи и отношения между ними– Use-case (вариантов использования) –отношения между актерами и прецедентами– Sequence (последовательности) – взаимодействия между объектами классов посредством обмена сообщениями– Collaboration (взаимодействия) – аналогична Sequence, но упор на связях между объектами– Statechart (состояний) – состояния сущности и способы перехода между ними (деятельности) – бизнес-процессы, функциональная декомпозиция системы

Iconix Что-то среднее между очень громоздким RUP и весьма компактной ХР (см. книгу [1]). Я считаю самым важным отличием от остальных методик введение диаграмм для анализа пригодности. Книга замечательная, начиная от TOP10 ошибок для каждого этапа разработки ПО и заканчивая постоянными напоминаниями вида «Над этим долго не работайте, сейчас у вас нет полной информации, чтобы тратить на это много времени».

Методика серьезно проигрывает остальным по охвату этапов ЖЦ ПО, сконцентрировавшись только на сборе требований и бизнес-моделировании.

хорошо раскрывает только системы. В этом SADT успешно конкурирует с диаграммами деятельности языка UML.

Structured Analysis and Design Technique – Методология структурного анализа и проектирования. Известна как разработка компании SofTech, либо как только функциональный вариант в правительственной версии (IDEF0).

«чем ниже уровень описания целей, тем менее полезными и наглядными становятся диаграммы». Из этого следует идея о «разделении труда» между различными CASE-средствами: для составления диаграмм высокого уровня (сценарий бизнес-процесса, схемы движения информации, диаграмма состояний основного документа системы, взаимодействие программных модулей) использовать инструменты, эффективно применяемые для рисования диаграмм, их связи друг с другом (Rational Rose, MS Visio), а для более детального описания применять «прецеденты по Коберну».

хорошая классификация целей – всегда нужно работать на одном уровне целей. Уровень повышается, если задать вопрос «Почему?» и понижается, если задать вопрос «Как?» (это большое искусство – быть на нужном уровне цели – диаграммы получаются мелкие и общие, или слишком большие и детализированные)

нового сотрудника можно быстрее научить писать текст в формате прецедентов Коберна, чем заставить использовать UML и продукт, его поддерживающий

В любом случае, лучше спокойно воспринимать мысль о том, что иногда нужно делать вещи, противоречащие фундаментальным принципам построения ИС.

«Если система местами «ненормальна» – то это лишь признак того, что она реально работает, а не создана в академических интересах». Ц