Распределение обязанностей в системе

Здесь речь идет о балансировке обязанностей между выявленными классами. Каждый класс должен хорошо делать что-то одно. Если абстрактный класс слишком велик и имеет функциональные связи с другими, то и его модель будет трудно модифицировать и повторно использовать. Кроме того, будет затруднено понимание и управление такими классами. Язык UML способен помочь в визуализации и спецификации баланса обязанностей между классами.

Моделирование распределения обязанностей в системе включает в себя следующие необходимые действия:

1. Идентификация совокупности классов, совместно отвечающих за некоторое поведение.

2. Определение обязанностей каждого класса.

3. Анализ полученных классов и разбиение тех из них, у которых слишком много обязанностей, на меньшие, и наоборот.

4. Перераспределение обязанностей между классами так, чтобы каждая абстракция стала в разумной степени автономной (с точки зрения своего поведения в рамках основных сценариев).

5. Рассмотрение того, как классы кооперируются друг с другом, и перераспределить обязанности с таким расчетом, чтобы ни один класс в рамках кооперации не делал слишком много или слишком мало.

Помимо программных сущностей в системе могут существовать и не программные сущности, а также примитивные типы (перечисление, целое и т.д). Сущности, внешние по отношению к системе, часто моделируются как акторы.

Таким образом, хорошо структурированный класс должен обладать следующими свойствами:

· являться четко очерченной абстракцией некоторого понятия из словаря предметной области или области решения;

· содержать небольшой, точно определенный набор обязанностей и выполнять каждую из них;

· поддерживать четкое разделение спецификаций абстракции, и ее реализации;

· быть понятным, простым, но в то же время допускать расширение и адаптацию к новым задачам.

Определение классов

CRC – карточки

Одним из наиболее полезных приемов, соответствующих хорошему стилю объектно-ориентированного программирования, является исследование механизмов системы. CRC – диаграммы (Class – Responsibility – Collaboration, класс – обязанность - кооперация), придуманные Уордом Каннингемом в конце 80 – х годов, выдержали проверку временем и стали высокоэффективным инструментом решения этой задачи.

Механизмы – это структуры, посредством которых объекты взаимодействуют друг с другом для достижения необходимого поведения более высокого уровня, и ведут себя так, как требуется. Если при разработке класса, фактически определяется поведение отдельных объектов, то механизмы служат для задания поведения совокупности объектов в сценариях вариантов использования или, другими словами, механизмы представляют шаблоны поведения.

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

Для использования CRC – карточек участники проекта должны собраться за столом, всем раздаются карточки (формата 3*5 дюйма), как показано на Рис. 4.20, после чего участники записывают наименования классов, которые они выявили, в верхней части каждой карточки. В левой части каждой карточки записываются ответственности класса, а в правой – с какими классами карточка взаимодействует, по ходу моделирования сценариев поведения. Далее, с помощью карточек, проигрываются различные сценарии работы системы, поднимая их над столом, в то время когда они активны, и передавая их по кругу в предположении того, что они посылают сообщения соответствующим объектам.

 

Заказ
Проверить наличие позиции	Строка Заказа
Определить цену	Клиент
Проверить правильность оплаты
Отправить по адресу доставки

Рис.4.20. Пример CRC – карточки

 

Важным моментом в CRC – методике является определение ответственностей.

Ответственность (responsibility) – это краткое описание того, что объект должен делать: операция, которую выполняет объект; некоторый объем знаний, который объект поддерживает; какие – либо важные решения, принимаемые объектом.

Идея состоит в том, чтобы можно было взять любой класс и сформулировать его разумно ограниченные обязанности.

Взаимодействие (collaboration): другие классы, с которыми должен работать рассматриваемый класс (имеется в виду связи на высоком уровне).
В процессе моделирования создается представление об ответственностях с их записью в карточки. Ответственность может соответствовать операции, атрибуту или, что более точно, неограниченной группе атрибутов и операций.

Отметим еще ряд подходов к определению классов объектов [20].

1. Использование грамматического анализа естественного языкового описания системы. Объекты и атрибуты – это существительные, операции и сервисы – глаголы.

2. Использование в качестве объектов событий и ситуаций реального мира из области приложения, например, самолетов, ролевых ситуаций менеджера, взаимодействий, подобных интерактивному общению на научных конференциях и т.д. Для реализации таких объектов могут понадобиться специальные структуры хранения данных (абстрактные структуры данных).

3. Применение подхода, при котором разработчик сначала полностью определяет поведение системы, затем определяются компоненты системы, отвечающие за различные поведенческие акты (режимы работы системы), при этом основное внимание уделяется тому, кто инициирует и кто осуществляет данные режимы. Компоненты системы, отвечающие за основные режимы работы, считаются классами.

4. Применение подхода, основанного на сценариях, в котором по очереди определяются и анализируются различные сценарии использования системы. Поскольку анализируется каждый сценарий, группа объектов, отвечающая за анализ, должна идентифицировать необходимые классы, атрибуты и операции. Метод анализа, при котором аналитики и разработчики присваивают роли объектам, показывает эффективность подхода, основанного на сценариях.

Каждый из перечисленных подходов помогает начать процесс определения классов. Но для описания объектов и классов объектов необходимо использовать информацию, полученную из разных источников. Классы и операции, первоначально определенные на основе неформального описания системы, вполне могут послужить отправной точкой при проектировании. Затем для усовершенствования и расширения описания найденных классов можно использовать дополнительную информацию, полученную из области применения ПО или анализа сценариев, в ходе обсуждения с пользователями, либо из анализа имеющихся систем.

Следующий подход для определения классов основан на классификации понятий (сущностей) (табл.4.2).

Таблица 4.2

Классификация понятий

Категория понятий - кандидатов	Примеры
1. Физические или материальные объекты	Компьютер – как целое
2. Спецификации, элементы дизайна или описания объекта – сохраняются в системе даже при отсутствии объектов	Спецификация товара, цвет
3. Место	Город, аэропорт, офис
4. Роль человека	Клиент, Продавец, Поставщик, Преподаватель
5. Контейнеры других объектов	Каталог – как совокупность описаний, окно интерфейса – как совокупность объектов управления
6. Содержание контейнеров	Часть, элемент
7. Другие компьютеры или внешние системы по отношению к разрабатываемой системе	Система бронирования билетов
8. Абстрактные классы	Вычислительный комплекс
9. Организация	Фирма, Университет, Предприятие
10. События	Прибытие, Встреча, Покупка билета
11. Процессы и их части	Покупка билета, Сдача экзамена, Оплата стоимости, Решение задачи
12. Правила и политика	Правила перевода студента на следующий курс, Правила аннулирования заказа
13. Записи трудовой, финансовой, юридической и другой деятельности, руководства, книги	Чек, книга пожеланий и предпочтений, должностная инструкция.

 

Качество классов и объектов

Опыт показывает, что процесс выделения классов и объектов является последовательным и итеративным. Поэтому, очень важно с самого начала, по возможности, максимально приблизиться к правильным решениям, чтобы сократить число последующих шагов приближения к истине. Для оценки качества выделяемых классов и объектов используются пять критериев [3]:

· зацепление;

· связность;

· достаточность;

· полнота;

· примитивность;

Зацепление – степень глубины связей между отдельными модулями. Систему с сильной зависимостью между модулями гораздо сложнее воспринимать и модифицировать. Сложность системы может быть уменьшена путем уменьшения зацепления между отдельными модулями.

Кроме зацепления между модулями в объектно – ориентированном анализе, существенно зацепление между классами и объектами. Существует определенное противоречие между явлениями зацепления и наследования. С одной стороны, желательно избегать сильного зацепления классов, с другой стороны, механизм наследования, тесно связывающий подклассы с суперклассами, помогает выгодно использовать сходство абстракций.

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

К идеям зацепления и связности тесно примыкают понятия достаточности, полноты и примитивности. Под достаточностью подразумевается наличие в классе или модуле всего необходимого для реализации логичного и эффективного поведения.

Под полнотой подразумевается наличие в интерфейсной части всех характеристик абстракции. Идея достаточности предъявляет к интерфейсу минимальные требования, а идея полноты охватывает все аспекты абстракции. Полнотой характеризуется такой класс или модуль, интерфейс которого гарантирует все для взаимодействия с конкретным пользователем.

Примитивными являются только такие операции, которые требуют доступа к внутренней реализации абстракции. Например, добавление к множеству элемента примитивна, а операция добавления n элементов нет, так как вполне эффективно реализуется через операцию добавления одного элемента.

В пределах каждого класса принято иметь только примитивные операции, отражающие отдельные аспекты поведения. Принято также определять методы, не связанные между собой. Это облегчает образование подклассов с переопределением поведения.

Отношения между классами и объектами связаны с конкретными действиями и с доступностью их ресурсов. Абстракции доступны одна другой только тогда, когда перекрывают их области видимости и даны необходимые права доступа. Таким образом, зацепление связано с видимостью.

Одним из полезных правил является закон Деметера, который утверждает, что « методы любого класса не должны зависеть от структуры других классов, а только от структуры (верхнего уровня) самого класса. В каждом методе посылаются сообщения только объектам из предельно ограниченного множества классов». Следование этому закону позволяет создавать слабо зацепленные классы, реализация которых скрыта. Такие классы достаточно автономны, и для понимания их логики нет необходимости знать строение других классов.

Иногда требуется выбирать между отношениями наследования, агрегации и зависимости. Например, должен ли класс Авто наследовать, содержать или использовать классы Двигатель и Колесо? В данном случае более целесообразны отношения использования (зависимости). Между классами А и В отношения наследования более пригодны тогда, когда любой объект класса В может одновременно рассматриваться и как объект А. С другой стороны, если объект является чем-то большим, чем сумма его частей, то отношение агрегации не совсем уместно.

Выводы

· Объект характеризуется состоянием, поведением и идентичностью.

· Структура и поведение одинаковых объектов описываются в общем для них классе.

· Состояние объекта определяет его статические и динамические свойства.

· Поведение объекта характеризуется изменениями его состояния в процессе взаимодействия (посредством передачи сообщений) с другими объектами.

· Идентичность объекта – это его отличия от всех других объектов.

· Иерархия объектов может строиться на принципах связи или агрегации.

· Множество объектов с одинаковой структурой и поведением является классом.

· Шесть типов иерархий классов включают: ассоциирование, наследование, агрегацию, использование, инстанцирование и метаклассирование.

· Классы и объекты, образующие словарь предметной области, называются ключевыми абстракциями. Их находят либо в самой предметной области, либо изобретают в процессе анализа и проектирования.

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

· Качество абстракций измеряется их зацеплением, связностью, достаточностью, полнотой и примитивностью.

· Идентификация классов и объектов – важнейшая задача объектно – ориентированного анализа и проектирования.

· Классификация - есть проблема группирования (кластеризации) объектов.

· Существует три подхода к классификации: классическое распределение по категориям (классификация по свойствам), концептуальная кластеризация (классификация по понятиям) и теория прототипов (классификация по схожести с прототипом).

· Метод сценариев – это мощное средство объектно – ориентированного анализа, его можно использовать для других методов: классического анализа, анализа поведения и анализа предметной области.

· Механизмы обозначают стратегические проектные решения относительно совместной деятельности объектов многих различных типов.

 

 

Контрольные вопросы:

1. Для обозначения интерфейсов и классов используется один и тот же символ?

2. Какие типы лучше всего изображать как атрибуты, а какие – как ассоциируемые классы?

3. Являются ли семантически схожими отношения агрегации и ассоциации?

4. Что является самым главным различием между отношениями агрегации и композиции?

5. Могут ли атрибуты обозначаться также как ассоциация?

6. Какими свойствами должен обладать хорошо структурированный объект?

7. Какими принципами необходимо руководствоваться при проектировании объектов на языке UML?

8. Разработайте объектную модель обработки данных в системе электронной почты, в случае, когда необходимо отдельно смоделировать отправку почты и ее получение.

9. Разработайте объектную модель, включающую диаграммы иерархии классов и агрегирования, и показывающую основные элементы системы персонального компьютера и его программного обеспечения.

10. На примере концептуальной модели предметной области для книжного Internet – магазина, смоделируйте различные сценарии обслуживания клиентов, используя метод CRC – карточек.

 

ИНЖЕНЕРИЯ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

Введение

 

Данную главу уместно начать с замечательной фразы Карла И. Вигерса [7]: «Из всех возможных способов совершенствования процесса разработка ПО наибольшее преимущество за формулированием требований». Слова известного лектора, автора и консультанта в области построения требований и совершенствования процесса разработки ПО, подтверждают оценки других ведущих специалистов о степени важности этапов установления и специализации требований для процесса разработки ПО, повышения производительности систем и снижения затрат на обслуживание и поддержку.

Иан Соммервилл, профессор инженерии программного обеспечения университета Ланкастера, Англия, определяет требование (requirement) как «формулировку сути системного сервиса или ограничения»[20]. Формулировка сути сервиса характеризует поведение системы по отношению к отдельным пользователям или ко всему контингенту пользователей. Описание системного сервиса фактически служит определением бизнес-правила, которое должно выполняться всегда (например, « книжный Internet – магазин должен обеспечивать защиту счетов с помощью пароля клиентов»). Формулировка сути сервиса может быть связана с некоторыми выполнениями, которые должны произвести система (например, «вычислить комиссионные продавца на основе объема продаж на прошлую среду с использованием конкретной формулы»).

Формулировка ограничения выражает ограничивающее условие на поведение системы или на разработку системы. Карл Вигерс трактует ограничения как формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. Выбор платформы и/или развертывания (протоколы, серверы приложений, баз данных и т.д.), которые, в свою очередь, могут относиться например, к внешним интерфейсам (интерфейс пользователя, интерфейсы с внешними устройствами, программные интерфейсы, коммуникационные интерфейсы). Примером ограничения на поведение системы может быть ограничение на безопасность: «только непосредственные руководители могут обращаться к информации о зарплате их персонала». Примером ограничения на разработку системы может быть формулировка: «Мы должны использовать инструмент Microsoft Dynamics CRM».

Различие между формулировкой ограничения на поведение системы и формулировкой услуги на основе бизнес – правила размыто. Это не составляет проблемы в том случае, если все требования идентифицированы и дублирование исключено.

Чтобы построить что-либо, прежде всего, необходимо понять, чем это должно быть. Процесс понимания (уяснения) и документирования этого и называется анализом требований. Обычно требования выражают, что приложение должно делать: зачастую здесь не пытаются сформулировать, как добиться выполнения этих функций. Например, следующее выражение

Система должна предоставлять пользователю доступ к балансу его банковского счета,

назовем его требованием (А), будет являться требованием для бухгалтерского приложения.

Следующее выражение, назовем его требованием (В),

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

не является требованием для приложения.

Выражение (В) касается того, как должно быть построено бухгалтерское приложение, а не того, что это приложение должно делать.

Требование на одном уровне часто переходит в одно или несколько конкретных требований на следующем, более подробном уровне. Более того, встречаются исключения из правила, запрещающего специфицировать в требованиях, как должно работать приложение. Например, у клиента могут быть особые причины потребовать, чтобы балансы счетов хранились в базе данных Access с конкретным именем, и тогда утверждение (В) действительно становится требованием.

Результатом анализа требований является документ, который обычно называют спецификацией требований к программному обеспечению (SRS – Software Requirements Specification). В SRS описывается так полно, как необходимо, ожидаемое поведение системы. Кроме документа спецификацией может быть база данных или крупноформатная таблица с требованиями, хранилище данных в коммерческом инструменте управления требованиями или даже, может быть, набор карточек для небольшого проекта. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом, и связанных с проектом функциях.

Функциональные требования записываются, как правило, с помощью предписывающих правил (утверждение А). Другим способом являются так называемые варианты использования (Uses Cases) – популярный и весьма продуктивный способ представления требований, который мы и будем рассматривать (пишем варианты использования как требования). Варианты использования дают руководству проекта возможность определить архитектуру системы, спланировать этапы разработки и контролировать их выполнение. Название каждого варианта использования указывает на цель, которую основное действующее лицо найдет в числе целей, поддерживаемых системой, а в теле каждого варианта использования содержатся сведения о том, что система требует и что предоставляет. Разработчики же на основе вариантов использования формируют задачи проектирования.

В практике инженерии требований, объектный подход предполагает использование вариантов использования в контексте выявления, как сущностей предметной области, так и системных объектов, составляющих техническую инфраструктуру приложений (управляющие компоненты, аспекты и т.п.). Таким образом, цель данной главы – дать основные понятия о требованиях, предъявляемых к программным системам, и показать различные способы представления этих требований. Изучив эту главу, вы должны:

· иметь понятие о концепциях пользовательских (С - требования) и системных требований (D – требования );

· понимать различия между функциональными и не функциональными требованиями;

· освоить методы спецификации требований;

· знать стандарты документирования требований к программному обеспечению.

 

5.1. Анализ требований

Нигде более, как на стадии выявления и сбора требований, так тесно не связаны интересы всех заинтересованных в проекте лиц с успехом проекта. К заинтересованным в проекте лицам относятся:

· заказчики, которые финансируют проект или приобретают продукт для решения каких-то бизнес – задач;

· пользователи, которые взаимодействуют напрямую или не напрямую с приложением (подкласс заказчиков);

· аналитики требований, которые пишут требования и передают их разработчикам;

· разработчики, которые создают, разворачивают и поддерживают продукт;

· тестировщики, которые определяют соответствие поведения ПО желаемому;

· технические писатели, которые отвечают за создание руководства пользователей, тренировочные материалы и справочную систему;

· менеджер по проекту, который планирует процесс и руководит командой разработчиков вплоть до успешного выпуска продукта;

· сотрудники правового отдела, которые следят, чтобы продукт не противоречил всем действующим законам и постановлениям;

· производственники, которые должны построить продукт, содержащий данное ПО;

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

Таким образом, так как требования представляют собой основу для действий и разработчиков и менеджеров проекта, все заинтересованные в проекте лица должны быть вовлечены в процесс создания документа SRS.

Как организация, отвечающая за стандарты программного обеспечения, IEEE в стандарте Glossary of Software Engineering Terminology (1990) определяет требования как [7]:

1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;

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

3. документированное представление условий или возможностей для пунктов 1 и 2

Требования к ПО состоят из следующих уровней – бизнес-требования, требования пользователей, функциональные и нефункциональные требования. Существуют также и обратные требования, которые регламентируют все то, что система не будет делать.

Уровень бизнес - требований – содержит высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. Спецификация бизнес - требований оформляется в виде документа-концепции [13], образец которого представлен в Приложении А учебника.

Таким образом, бизнес - требования записываются в форме документа об образе и границах проекта, который подготавливает основу для последующей разработки продукта. Владельцем документа об образе и границах считается тот, кто финансирует проект или несет аналогичную ответственность.

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

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

Документом об образе и границах проекта в UML служит диаграммы бизнес – вариантов использования, которые используются при моделировании бизнес – процессов для описания контекста системы и формирования основы для разработки системных диаграмм вариантов использования.

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

Уровень функциональных требований – определяет функциональность ПО, которую разработчики должны реализовать, чтобы пользователи смогли выполнять свои задачи в рамках бизнес – требований. Такие требования содержат положения с традиционным «должен» или «должна», и описывают, что разработчику необходимо реализовать.

Бизнес-правила – включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты использования, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности.

Уровень нефункциональных требований – описывает цели и атрибуты качества. Атрибуты качества представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков: легкость и простота использования; легкость перемещения; целостность, эффективность и устойчивость к сбоям; производительность, прослеживаемость; внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации.

Примерами характеристик могут быть: контроль за автосохранением и орфографией в текстовом редакторе; запись макрокоманды, он – лайновое обновление или изменение налогового кодекса; ускоренный набор телефонного номера и т.п. Характеристики могут охватывать множество вариантов использования, и для каждого из них нужно, чтобы множество функциональных требований было реализовано для выполнения пользователем его задач.

Характеристика таким образом – это набор логически связанных функциональных требований, которые обеспечивают нужды пользователя и, в то же время, удовлетворяют бизнес - целям.

Рассмотрим пример программы подготовки текстов. Для этого примера:

· бизнес - требование: «Продукт позволит пользователям исправлять орфографические ошибки в тексте эффективно»;

· характеристика – «проверка грамматики»;

· требования пользователей содержат варианты использования: «Нахождение орфографической ошибки» или «Добавление слова в общий словарь»

· атрибут качества – легкость и простота, определяются посредством слова «эффективно» в бизнес - требованиях.

Таким образом, каждое требование пользователя должно быть сопоставлено бизнес - требованию. На основе требований пользователя аналитики определяют функции, которые позволят пользователям выполнять их задачи. Разработчикам необходимы функциональные и нефункциональные требования, чтобы создавать решения с желаемой функциональностью, определенным качеством и требуемыми рабочими характеристиками, не выходя за рамки налагаемых ограничений.

Ограничения касаются выбора возможности разработки внешнего вида и структуры продукта.

Взаимосвязь уровней требований и сопутствующей документации можно изобразить следующим образом (рис. 5.1).

В течение некоторого времени проходили дебаты относительно того, кому принадлежат требования: заказчику или разработчикам. Для решения этого вопроса Эрик Дж. Брауде [6] разделяет анализ требований на два уровня. Первый уровень документирует желания и потребности заказчика и пишется на языке, понятным заказчику. Это, так называемые, требования заказчика, или С-требования (Customer requirements). Первичной аудиторией для С-требований будет сообщество заказчиков, а уже вторичной – сообщество разработчиков. Второй уровень документирует требования в специальной, структурированной форме. Эти документы называются требованиями разработчика, или D-требованиями (Design requirements). Первичной аудиторией для D-требований будет сообщество разработчиков, а уже вторичной – сообщество заказчиков.

 

 

Рис. 5.1. Взаимосвязи нескольких типов информации для требований

 

Хотя целевые аудитории для С - и D-требований различны, заказчики и разработчики должны тесно сотрудничать для создания успешных продуктов (это является принципом экстремального программирования - XP).

Каждое требование должно быть аккуратно документировано, при этом каждое требование должно:

· быть четко выражено;

· быть легко доступно;

· быть пронумеровано;

· сопровождаться подтверждающими тестами;

· предусматриваться проектом;

· быть учтено кодом;

· быть протестировано вкупе с другими требованиями;

· быть подтверждено тестированием после того, как выполнена сборка приложения.

Типичная схема процесса анализа С-требований представлена на рис. 5.2

 

Идентифицировать заказчика.

⇐ Предыдущая6789101112131415Следующая ⇒

Поделиться: