Sep reqm-lec2

Software Engineering Professional Program © 2007.

T E K A M A

Качество спецификации требований

Хорошее представление требования.

Хорошая спецификация.

2-1


T E K A M A

День 2. Качество требований

День 1. Требования. Спецификация требований.

День 2. Качество требований.

Качество спецификаций

Контроль статуса требований

Моделирование требований

Упреждающая разработка требований

День 3. Управление изменениями

2-2


T E K A M A

ХОРОШЕЕ описание требования

Полнота

Однозначность

Необходимость

Осуществимость

Проверяемость

удовлетворяет следующим критериям:

2-3


T E K A M A2-4


T E K A M A

Атрибуты требования

Структурные атрибуты отдельного требования:

Код

Название

Описание

Источник

Ранжир

Связь

2-5


T E K A M A

Контроль статуса

«Как движется работа над той подсистемой,

Джеки», — спросил Дейв.

«Довольно хорошо, Дейв. Готово около 90%». Дейв

был озадачен: «А разве пару недель назад ты не

сделала примерно 90%?»

Джеки ответила: «Я думала, что да, но теперь эти

90% действительно готовы»

2-6


T E K A M A


Proposed (Предложено)

Approved (Одобрено)

Implemented (Реализовано)

Verified (Проверено)

Deleted (Удалено)

Rejected (Отклонено)

2-7


T E K A M A


2-8


T E K A M A

ХОРОШАЯ спецификация требований

Хорошая СТПО должна быть:

Правильной

Завершенной

Непротиворечивой

Модифицируемой

[ IEEE Std. 830-1998 ]

2-9


T E K A M A

Правильная СТПО

включает все требования, которые должны быть реализованы в ПО

2-10


T E K A M A

Завершенная СТПО

Представляет собой оформленный

документ, с названием, обозначением,

номером редакции, датами выпуска и

утверждения.

Должна быть снабжена оглавлением и

иметь корректные ссылки.

Не должна содержать мест, которые нужно

доопределять.

2-11


T E K A M A

Непротиворечивая СТПО

Одни требования не должны противоречить другим. По всему документу:

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

одни и те же характеристики объектов должны иметь одно значение.

2-12


T E K A M A

Модифицируемая СТПО

логичной структуры

оглавления, предметного указателя и точных

перекрестных ссылок

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

стабильной идентификации требований

Позволяет по возможности просто вносить

изменения в требования за счет:

2-13


T E K A M A

Вопросы?

2-14


T E K A M A

Реальность сурова

Реальность - это разница между тем, что

доставляет

нам удовольствие, и тем, чем мы вынуждены

довольствоваться.Габриель Лауб, журналист и

писатель

2-15


T E K A M A2-16


T E K A M A

Спасение утопающих …

2-17


T E K A M A

Упражнение «Анализ требований»

В ходе выполнения упражнения предлагается: изучить предлагаемую спецификацию

сделать замечания по ее содержанию и

структуре

подготовить контекстную диаграмму

сформировать словарь данных

2-18


T E K A M A

МОДЕЛИРОВАНИЕ ТРЕБОВАНИЙ

Виды моделей.

Диаграммы потоков данных.

Диаграммы «сущность-связь»

Другие модели


T E K A M A

Виды моделей

Представление требований с помощью графических,

табличных или формальных текстовых нотаций, таких как: диаграммы потоков данных (DFD)

диаграммы "сущность-связь" (ERD)

диаграммы вариантов использования (Use case)

диаграммы состояний (STD)

диаграммы классов

карты диалогов

диаграммы взаимодействия

.....

2-20


T E K A M A2-21


T E K A M A

Диаграмма потоков данных (DFD)

Рассчитатьзаказ

Утвердитьзаказ

Оформитьдокументы

РасчетыЗаказы

Данные клиентаПараметры продукции

Расчет

Заказ

Нормативы

РаботыМатериалы

Справочники

Паспортзаказа

Заказ

Бланкрасчета

Бланк заказа

Технолог

Менеджер

2-22


T E K A M A

Правила чтения DFD

Процесс

Агент

Хранилище

Поток

2-23


T E K A M A

Диаграмма «сущность-связь» (ERD)

2-24


T E K A M A

Правила чтения ERD

Договор

Заказ

Менеджер

Запрос

Агент

Контактное лицо

Клиент

0:M

0:1

0:1

1:1

1:1

0:M

1:1

0:M

0:M

1:M 0:M

1:1

1:1

1:1

0:M 1:1

представление

расчет

оформление

прием

2-25


T E K A M A

Структура БД (сравнить с ERD)

Договор

Заказ

Менеджер

Запрос

Агент

Контактное лицо

Клиент

Должность

Источник рекламы

Категория клиента Памятное событие

Причина отказа

Событие запроса Оригинал

2-26


T E K A M A

Плюсы и минусы диаграмм

- - - Неполнота информации

Необходимость обучения

Нужны инструменты

Трудоемкость создания

Дублирование информации

+ + + Строгость

Наглядность

2-27


T E K A M A

Подход на основе вариантов использования (use case)

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

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

Понятие «вариант использования» возникло в ООП, но может использоваться и в других проектах. Почему?

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

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

2-28


T E K A M A

Преимущества вариантов использования

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

Позволяет обнаружить неточности и неясности требований на раннем этапе.

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

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

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

Выявляют важные объекты предметной области и их взаимоотношения.

2-29


T E K A M A

Основы вариантов использования

К важным элементам варианта использования относятся: Уникальный идентификатор Имя, явно описывающее задачу пользователя в формате «глагол +

объект», например, «вставить файл» Краткое текстовое описание на обычном языке. Список предварительных условий, которые должны быть

выполнены, прежде чем сможет начаться вариант использования. Выходные условия, описывающие состояние системы после

успешного завершения варианта использования. Пронумерованный список действий, описывающий

последовательность этапов взаимодействия пользователя и системы.

2-30


T E K A M A

Определение вариантов использованияAlistair Cockburn, «Writing Effective Use Cases»

Один вариант использования – одна цель одного актора (пользователя, компьютера)

Цель: отдельная от других достигается немедленно имеет ценность для актора

Типичное время достижения цели – от 2 до 20 минут, если актор – пользователь (меньше, если компьютер)

2-31


T E K A M A

Вариант использованияГрафическое представление

Диаграмма UMLБанкомат

«Расширяет»

Сохраняет информациюоб остатке на счете

Проверяет баланссчета

Переводсо счета на счет

Обновление остаткана счете

Снимает наличные

Клиент

База данныхBank Teller

«Включает»

Банковский служащий

2-32


T E K A M A

Вариант использованияДругое графическое представление

Выходные условия

Обычный ход выполнения

Диаграмма деятельности (Activity Diagram) KW135

Этап 1

Этап 2

Этап 3 Этап 2c

Этап 2b

Этап 2aУсловние

Предварительные условия

Альтернативный ход выполнения

2-33


T E K A M A

От вариантов использования к функциональным требованиям

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

Три возможных способа документирования функциональных требований, связанных с вариантами использования: Только варианты использования

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

Варианты использования и спецификация требований ПО Необходимо только установить прослеживаемость между вариантами

использования и функциональными требованиями спецификации требований ПО.

Только спецификация требований ПО Необходимо определить копию функциональных требований.

2-34


T E K A M A

Варианты использования: ловушки применения

Слишком много вариантов использования

Крайне сложные варианты использования

Включение интерфейса пользователя в варианты использования

Включение определения данных в варианты использования

Варианты использования, которые не могут понять пользователи

Новые бизнес процессы

Чрезмерное использование отношений «расширяет» и «включает»

2-35


T E K A M A

Вопросы?

2-36


T E K A M A

Прототипирование

Использование прототипов.

Упреждающая разработка документации


T E K A M A

Использование прототипа

Прототип - представительская или действующая модель

реализации требований пользователей, позволяющая:

уточнить требования

быстро получить обратную связь

выявить скрытые требования

что, в итоге, сокращает объем изменений требований

в ходе проекта.

2-38


T E K A M A2-39


T E K A M A

Виды прототипов

Демонстрационные прототипы Бумажные

Электронные

Действующие прототипы Горизонтальные

Вертикальные

Эволюционные

[К.Вигерс]

2-40


T E K A M A2-41


T E K A M A

Традиционный подход к разработке

Спецификация требований

Руководство пользователя

Программное обеспечение

Создание

ИспользованиеПО

Описание

Выявление требований

СОЦИАЛЬНАЯ СРЕДА

Идея - D.Ross

Заимствованиетерминологии

2-42


T E K A M A

Упреждающая разработка документации

Образ руководства пользователя

Руководство пользователя

Программное обеспечение

Создание

ИспользованиеПО

Уточнение

Выявление требований и

проектирование взаимодействия

СОЦИАЛЬНАЯ СРЕДА

Идея - D.Ross

Коррекция

2-43


T E K A M A2-44


T E K A M A

Преимущества метода

Не нужно придумывать структуру документа

Простой критерий полноты требований

Нет соблазна навязывать программисту проектные

решения

Повышение качества ПО за счет того, что: аналитик смотрит на ПО «глазами» пользователя

пользователю проще оценить создаваемое ПО и дать более

качественную обратную связь

Быстрое создание пользовательской документации

2-45


T E K A M A

Вопросы?

2-46


T E K A M A

Проверка требований

Процессы

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


T E K A M A

Еще раз, ХОРОШЕЕ описание требования

Полнота

Однозначность

Необходимость

Осуществимость

Проверяемость

удовлетворяет следующим критериям:

2-48


T E K A M A

Проверка требований

Планирование

Ознакомление

Подготовка

Обсуждение

Завершение

Спецификациятребований

Списокзамечаний

Инспекция

2-49


T E K A M A

Польза от проверки правильности требований

Как компонент разработки требований, проверка

правильности обеспечивает, что:

Спецификация требований к ПО правильно описывает

системные характеристики и возможности, которые отвечают

потребностям пользователей

Требования к ПО правильно отражают бизнес-правила,

системные требования, и др.

Требования полны и высококачественны

Все представления требований согласованы друг с другом

Требования обеспечивают хорошую основу для

проектирования и реализации.

2-50


T E K A M A

Рецензирование требований

Две основные категории Неформальные рецензии (сбор соответствующих

неструктурированных отзывов) Проверка коллегой Коллективная проверка Критическая проверка

Формальные рецензии (сбор отзывов в соответствии с хорошо регламентированным процессом) Экспертиза

2-51


T E K A M A

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

Вопросы, связанные с корректностью:

Конфликтуют ли одни требования с другими?

Имеются ли повторы требований?

Написаны ли требования ясно, точно и недвусмысленно?

Можно ли проверить выполнение каждого требования?

He выходит какое-либо требование за границы проекта?

Нет ли в требованиях содержательных, языковых ошибок?

Можно ли реализовать все требования в наших условиях?

Все ли сообщения об ошибках уникальны и выразительны?

…..

2-52


T E K A M A2-53


T E K A M A

Домашнее задание

Результирующая спецификация должны включать:

назначение продукта;

категории пользователей;

контекстную диаграмму продукта;

требования к свойствам и ограничениям;

детальное описание функций ПО;

словарь данных.

2-54


T E K A M A

День 2. Обзор

Качество спецификаций

Контроль статуса требований

Моделирование требований

Использование прототипа

Упреждающая разработка требований

2-55

Date post:	05-Dec-2014
Category:	Career
Upload:	natalia-zhelnova
View:	763 times
Download:	1 times

Sep reqm-lec2

Career