Правила войны и систем

Maciashek_23

Политические требования и юридические требования зачастую подразумеваются, чем явно формулируются в документе описания требований. Подобная ошибка может обойтись очень дорого. [138]

Maciashek_22

Документ описания требований должен создать прецендент для системы. В частности, необходимо упомянуть обо всех усилиях, приложенных для обоснования необходимости системы. [136]

Maciashek_21

Используйте шаблоны документов описания требований.

Шаблоны для документов описания требований широко доступны. Их можно найти в учебниках, стандартах, выпускпаемых ISO, IEEE и т.д., на Web-страницах консалтинговых фирм, программных средствах разработки и т. д. Со временем каждая организация разрабатыввает свои собственные стандарты, которые соотвествуют принятой в организации практике, корпоративной культуре, кругу читателей, типам разрабатываемых систем. [135]

IEEE Recommended Practice for Software Requirements Specifications

Maciashek_20

Рамки системы

Наибольшее беспокойство при разработке доставляет так называемое «расползание рамок» системы.

Чтобы ответить на вопрос о рамках системы, необходимо знать, в каком контексте функционирует наша система.

Рамки системы можно определить обозначив внешние сущности и входные/выходные потоки между внешними сущностями и нашей системой.

Всякое требование, которое не может быть поддержано за счет внутрисистемных возможностей обработки, выходит за рамки системы.

Язык UML не обладает средствами построения визуальной модели, позволяющей определить границы системы. Поэтому зачастую для решения этой задачи прибегают к помощи контекстных диаграмм потоков данных DFD (Data Flow Diagrams) [130]

Maciashek_19

Комплекс моделей проекта

На этапе установления требований осуществляется выявление требований и их определение на естественном языке. При этом постоянно ведется деятельность по обобщенному визуальному представлению собранных требований т.н. бизнес-моделирование требований.

Бизнес-модель может быть представлена в виде трех общих диаграмм — диаграммы контекста, диаграммы бизнес-прецендентов и диаграммы бизнес-классов. [140]

Формальное моделирование требований на языке UML проводится на этапе спецификации требований.

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

Диаграммы прецендентов и моделей классов используются параллельно и поочередно играя роль «лидера гонки» в рамках последовательных итераций разработки.

Проектирование и реализация тесно переплетены и могут иницировать обратную связь с моделями спецификации требований. [129]

Maciashek_18

Управление изменениями

Требования к системе изменяются.

Изменения нельзя рассматривать как «удар», а вот неуправляемые изменения — это настоящий удар по проекту.

Чем дальше продвинулась разработка, тем дороже обходится внесение изменений.

Необходима сильная стратегия управления изменениями для документирования запросов на изменения (change request), оценки влияния оказываемого изменениями (change impact).

Поскольку изменение требований обходится дорого, для каждого запроса на изменение необходимо создавать бизнес-прецендент.

Управление изменениями включает отслеживание больших объемов взаимосвязанной информации в течение длительного времени. Без инструментов поддержки управление изменениями обречено.

Maciashek_17

Эффективность традиционных методов выявления требований (интервью, анкеты, наблюдение и изучение деловых документов) обратно пропорциональна риску проекта.

Высокий риск означает, что систему трудно реализовать — не вполне ясны даже обобщенные требования. [117]

Maciashek_16

Операции принадлежат скорее к сфере проектирования, чем анализа. [45,97]

Maciashek_15

При определении того, являются ли понятия присуствующие в требованиях классами следует ответить на вопросы:

— Является ли понятие «вместилищем» данных?

— Обладает ли оно отдельными атрибутами, способными принимать разные значения?

— Можно ли создать для него множество объектов-экземпляров?

— Входит ли оно в границы прикладной области? [45,93]

Maciashek_14

Основная непредсказуемая трудность при разработке программного обеспечения связана с участниками проекта — программный продукт должен дать участниками ощутимые выгоды; в противном случае его ждет провал. В «треугольник» факторов, обеспечивающих успех проекта, помимо человеческого фактора входят стабильный процесс и поддержка языка и средств моделирования. [45,59]

Maciashek_13

Не «измеряя» прошлого, организация не в состоянии точно планировать будущее. [45,53]

Maciashek_12

То, что нельзя спланировать, нельзя и осуществить. [45,52]