sep reqm-lec1

Software Engineering Professional Program © 2007.

T E K A M A

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

Курс читает: Наталья Желнова

TEKAMA

1-1

T E K A M ASoftware Engineering Professional Program © 2007.

Структура курса

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

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

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

1-2


Краткое содержание

Что такое требования к ПО

Какова их роль в разработке ПО

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

Как работать с требованиями, когда они изменяются

А также:

Практические занятия

Рекомендации по работе с требованиями

1-3


День 1. Требования.

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

Определение.

Границы продукта vs проекта.

Проблемы определения требования.

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

Структура документа (IEEE Std 830).

Требования в XP-программировании.

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

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

1-4


Фазы разработки программного обеспечения

Идея

Анализ

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

Программирование

Тестирование

Внедрение

Поддержка

1-5


CMMI

Разработана в 1991 году Институтом программной

инженерии Университета Карнеги-Меллона (Software

Engineering Institute, SEI)

Внедрение СММ/CMMI позволяет улучшить структуру и

качество процессов

Отвечает на вопрос «Что?», но не «Как?»

1-6


Место требований в программной инженерии• Software requirements

• Software design

• Software construction

• Software testing

• Software maintenance

• Software configuration management

• Software engineering management

• Software engineering process

• Software engineering tools and methods

• Software quality [SWEBOK]

1-7


CMMI. Process AreasMaturity Level 2: Managed

Requirements Management

Project Planning

Project Monitoring and Control

Supplier Agreement Management

Measurement and Analysis

Process and Product Quality Assurance

Configuration Management

Maturity Level 3: Defined

Requirements Development

Technical Solution

Product Integration

Verification

Validation

Organizational Process Focus

Organizational Process Definition

Organizational Training

Integrated Project Management for IPPD

Risk Management

Integrated Teaming

Integrated Supplier Management

Decision Analysis and Resolution

Organizational Environment for Integration

Maturity Level 4: Quantitatively Managed

Organizational Process Performance

Quantitative Project Management

Maturity Level 5: Optimizing

Organizational Innovation and Deployment

Causal Analysis and Resolution

1-8


CMMI. Эффективное управление требованиями

Для эффективного управления требованиями CMMI

рекомендует:

Достичь понимания требований

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

Управлять изменениями к требованиям

Установить и поддерживать двустороннюю

прослеживаемость требований

Идентифицировать любые несоответствия между

требованиями и проводимыми в проекте работами

1-9


Связь с другими курсами

Определение требованийРассматриваются процессы выявления, анализа,

спецификации и согласования требований.

Управление ожиданиями заинтересованных

сторонРассматриваются вопросы эффективного взаимодействия

с заказчиками в процессе разработки

1-10


Вопросы? Пожелания?

1-11


T E K A M A

Базовые понятия

Категории требований.

Границы системы и ПО.

Образ продукта и граница проекта

1-12


О чем речь ?

ТРЕБОВАНИЕ-

свойство, которое должно быть проявлено в ПО или системе для решения некоторой

проблемы реального мира.

[SWEEBOK]

1-13


Функциональные требования (примеры)

«Программа должна сохранять расчеты всех заказов на

изготовление продукции»;

«Программа должна осуществлять поиск клиента по

фрагменту названия или телефону»;

«Список заказов должен сортироваться по убыванию

времени оформления»;

.........

1-14


Требования к интерфейсу (примеры)

Имя пользователя должно быть на всех экранах

расчета заказа;

Программа должна получать данные о клиентах из

системы CRM;

Программа должна отсылать Email с расчетом

стоимости заказа;

. . . . . . . . . . . .

1-15


Требования к качеству (примеры)

Время реакции на все запросы не более 3 сек.

Для установки ПО не требуется особая квалификация

(ПО должно инсталлироваться пользователем без

участия системного администратора).

Время восстановления системы при сбое не превышает

5 мин.

. . . . . . . . . . . .

1-16


Ограничения (примеры)

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

соответствии с требованиями ЦБ.

В качестве сервера БД используется Oracle 9.

Документацию оформлять по ГОСТ19.106-78.

. . . . . . . . . . . .

1-17


Потребности пользователей (примеры)

ПО должно обеспечивать ведение списка клиентов.

При расчете стоимости заказа программа должна

учитывать скидки категорий клиента.

Расчет стоимости заказа выполнять по формуле ...

. . . . . . . . . . . .

1-18


Бизнес цели (пример)

Увеличить число принятых заказов на 30%.

Снизить простои оборудования на 10%.

Повысить соотношение запросов к заказам до 0.3.

. . . . . . . . . . . .

1-19


Категории потребностей Бизнес цели Зачем создается ПО?

Потребности пользователей Какие свои задачи смогут решать

пользователи с помощью ПО?

Ограничения Законы, положения, стандарты, …

которым должно удовлетворять ПО.

Требования к качеству: Производительность, мобильность,

совместимость, простота …

Требования к интерфейсу Требования к экранным формам,

форматам и протоколам обмена

данными.

Функциональные требования Какие функции должно выполнять

ПО?

1-20


Граница продукта

Создаваемоепрограммное обеспечение

Пользователи

Компьютерноеоборудование Внешняя база данных

Производственное оборудование

ДругоеПО


1-21


Граница проекта

Команда разработчиков

Требования и проектные документы

Аналитики

Пользователи

Менеджеры

Заказчики

1-22


Граница продукта (product vision)

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

целей и задающие направление разработке.

Граница проекта (project scope)

Определяет объем требований к ПО и условия их реализации, в рамках

конкретного проекта по разработке очередной версии.

Граница продукта vs. Граница проекта


Версия 1.0 Версия 1.1 Версия 1.2 . . .

1-23


Роль требований в разработке

основа соглашения между заказчиком и разработчиком

основа планирования проекта (сроки, стоимость,

ресурсы) и контроля его продвижения

основной источник информации для разработчиков в

процессе конструирования

основа для оценки результатов разработки

основа одинакового понимания задачи и разделения

труда между различными категориями разработчиков

1-24


Виды ПО с точки зрения требований

Требования детерминированы (интерфейс между готовым ПО,

существующими устройствами …)

Требования формальны (управление техническими системами,

математические модели …)

Требования придумываются (игры, инновации)

Основные требования известны (операционные системы,

редакторы текстов…)

Требования выявляются (ERP, офисные системы, …)

1-25


Вопросы?

1-26


T E K A M A

Проблема определения требований

Влияние требований на проект.

Важность требований в разработке.

1-27


В чем проблема?

не делают того, что нужно пользователю

не удобны в использовании

трудно осваиваются

постоянно изменяются

иногда просто выбрасываются

Программисты способны решать практически любые поставленные

задачи обработки информации на компьютере. Почему получаются

программы, которые:

1-28


Причины провалов

1-29


Факторы успеха

1-30


Нет проблем !

?1-31


Понимание

1-32


Есть проблемы!

Основные проблемы, связанные с

определением требований это: их отсутствие в начале разработки

их изменение в ходе разработки

1-33


Важность требований

«Самая сложная часть разработки ПО – точно

решить, что же строить. Это самая трудная

концептуальная работа, способная сильно испортить

результат, если она выполнена плохо, и которую

наиболее трудно исправлять»

Фредерик Брукс «No silver Bullet: Essence and Accidents of Software Engineering», 1987

1-34


Цена ошибок в требованиях

Отн

осит

ельн

ая с

тоим

ость

ис

пра

влен

ия

ошиб

ок

в тр

еб

ован

иях

20

40

60

80

100

Требования ИспользованиеПроект Кодирование ТестированиеФазы разработки [Карл Видгерс]

1-35

Evgenia Vladimirskaya

Похоже, это "Количество выявляемых ошибок"? Или стоимость исправления ошибок?


Характерный взгляд на процесс разработки

1-36


Вопросы?

1-37


T E K A M A

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

Роль спецификации в проекте.

Содержание спецификации.

Структура спецификации

1-38


Фиксация требований

Если этого нет на бумаге,

значит этого не существует

Любимая аксиома Алана Купера

(из книги «Психбольница в руках пациентов»)

1-39


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

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

( СТПО )

БизнесПользователиСистемаОграничения

Управление проектомПроектированиеПрограммированиеТестирование..............Подрядчик

Заказчик

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

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

1-40


Риски отсутствия спецификации

Риск разного понимания требований разными

участниками разработки;

Опасность сделать ПО, не отвечающее

потребностям заказчика или покупателя;

Риск неоплаты усилий разработчиков;

Неправильная оценка трудоемкости и сроков;

Незащищенность проекта от смены разработчиков.

1-41


Содержание спецификации

Функциональность- Какие функции должно выполнять ПО?

Интерфейсы- Как ПО взаимодействует с другими элементами

системы?

Свойства- Какие требования к производительности,

мобильности, ... ?

Ограничения- Какие нужно использовать стандарты, языки, ресурсы ...?[ IEEE Std 830-1998 ]

1-42


Функциональные требования

В СТПО каждое описание функции детально описывает:

входные и выходные данные

(название, тип, формат, диапазон)

преобразование входных данных в выходные (неформальное описание, формулы, логические

выражения, алгоритмы, таблицы решений)

необходимые проверки входных данных

реакции на ненормальные ситуации

1-43


Интерфейсы

Как ПО взаимодействует с окружением:

Интерфейсы пользователя

Интерфейсы с оборудованием

Интерфейсы с другим ПО

Коммуникационные интерфейсы

1-44


Описание интерфейсов

Описании интерфейсов может включать следующую

информацию:

Имя интерфейса и его назначение

Форматы данных и команд, экранов

Диапазон значений, точность, единицы измерения

Протоколы обмена

Временные характеристики

1-45


Свойства

Это общие требования к ПО, влияющие на проектныерешения, относящиеся к его:

надежности

доступности

безопасности

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

мобильности

сопровождаемости

1-46

Evgenia Vladimirskaya

Надежность - и поддержание целостности БД. А причем тут БД?


Ограничения

Ограничения – это условия, которые ограничивают

выбор решений при разработке: Законодательные акты

Отраслевые и другие стандарты

Используемое оборудование и ПО

Языки программирования и инструменты

1-47


Не является предметом СТПО (1)

Проектная информация о внутренней структуре ПО:

разбиение ПО на модули

распределение функций по модулям

описание потоков информации между модулями

структура проектируемой БД

детали дизайна экранного интерфейса

детали реализации

средства разработки

1-48


Не является предметом СТПО (2)

Информация об организации проекта: стоимость проекта

график поставки продукта

методы разработки ПО

порядок отчетности и

гарантии качества

порядок приемки

1-49


Структура документа (IEEE Std 830)Спецификация требований к ПО

Оглавление

1. Введение* Цель * Сфера * Определения * Обозначения

* Сокращения * Ссылки * Обзор

2. Общее описание* Место продукта * Функции продукта * Пользователи

* Ограничения * Предположения и зависимости

3. Детальные требования

Приложения

Индекс

1-50


Принципы структурирования

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

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

классам объектов

возможностям для пользователей

воздействиям

результатам

иерархии функций

1-51


Структуризация по пользователям3. Детальные требования 3.1 Требования внешнего интерфейса 3.2 Функциональные требования 3.2.1 Класс пользователя 1 3.2.1.1 Функциональное требование 1.1

....3.2.1.n Функциональное требование 1.n

.... 3.2.m Класс пользователя m

3.2.m.1 Функциональное требование m.1....3.2.m.n Функциональное требование m.n

3.3 Требования к производительности 3.4 Ограничения проектирования

1-52


Структуризация по функциям3. Детальные требования 3.1 Требования внешнего интерфейса 3.1.1 Интерфейсы пользователей 3.1.2 Интерфейсы с оборудованием 3.1.3 Интерфейсы с ПО 3.1.4 Коммуникационные интерфейсы 3.2 Функциональные требования 3.2.1 Информационные потоки 3.2.1.1 Описание группы функций (Связь функций через потоки данных) ….. 3.2.2 Описания функций 3.2.2.1 Функция 1 Входные и выходные данные, Алгоритм …... 3.2.3 Структуры данных 3.2.3.1 Структура 1 (Тип записи, Поля) ......

1-53


Техническое задание (ГОСТ 19.201-78. ЕСПД)Введение

Основания для разработки

Назначение

Требования к программе или программному изделию:

- требования к функциональным характеристикам

- требования к надежности и устойчивому функционированию.

- условия эксплуатации.

- требования к составу и параметрам технических средств

- требования к информационной и программной совместимости

- требования к маркировке и упаковке

требования к транспортированию и хранению.

Требования к программной документации

Технико-экономические показатели

Стадии и этапы разработки

Порядок контроля и приемки

1-54


ГОСТ 19.201 vs. IEEE Std. 830

В техническом задании, в отличии от

спецификации требований: программа – это материальный объект

упор на структуру документа

дается один вариант структуры документа

нет критериев качества требований

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

1-55


Вопросы?

1-56


T E K A M A

Представление информации

Характеристика пользователей.

Контекстная диаграмма.

Словарь данных

Требования в ХР программировании

1-57


Характеристика пользователей

Описание каждой категории пользователей включает:

Название категории

Цели и задачи пользователей

Опыт и имеющиеся навыки

Потребности а обработке информации

Права доступа к информации

Рейтинг важности категории

1-58


Контекстная диаграмма (пример)

Система«Полиграф»

Менеджер

БухгалтерТехнолог

Система«1С»

Интернет

Ксерокс

Клиентыи заказы

Расчетыи отчеты

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

Заказы

Показателиэксплуатации

Данные об оплате

Финансовыеотчеты

Платежи

Расчеты дляклиентов

1-59


Словарь данных (пример)

– физическое или юридическое лицо делающее Запрос на производство печатной продукции. Может заключать Договор на длительный срок. Может быть неизвестное лицо, для которого нужно рассчитать Заказ. Пример Карточки клиента см. в Приложении 1.

Клиент

+ Название - имя или название клиента [Текст(30)]+ Дата - дата регистрации клиента [Дата (дд.мм.гг)]+ Категория - категория клиента [ обычн.|VIP| новый | ...]+ Адрес - адрес клиента [Адрес]+ (Email) - адрес электронной почты [Текст(30)]+ Контакт (1:N) - список Контактных лиц [Контактное лицо]+ Договор (1:N) - список Договоров [Договор]

– почтовый адрес контрагента (Клиент, Подрядчик).Адрес

+ Индекс - почтовый индекс [Целое(6)]+ Улица - название улицы (справ. БТИ) [Текст(20)] + Дом - номер дома, корпуса, строения [Текст(10)]

1-60


Формат словаря данных

– физическое или юридическое лицо делающее Запрос на производство печатной продукции.

Клиент

+ Название - имя или название клиента [Текст(30)]+ Дата - дата регистрации клиента [Дата (дд.мм.гг)]+ Категория - категория клиента [ обычн. | VIP |...]+ Адрес - адрес клиента [Адрес]+ (Email) - адрес электронной почты [Текст(30)]+ Контакт (1:N) - список контактных лиц [Контактное лицо]+ Договор (1:N) - список договоров [Договор]

Обозначение сущности

Описание сущности

Ссылка на сущность

Обозначениеатрибута

Названиеатрибута

Необязательный атрибут

Повторяемость значения атрибута

Простой тип данных, его формат или список допустимых значений

Ссылки на сущности

1-61


Требования в ХР-программировании

Требования определяются при «Концептуализации

системы» на протяжении всего жизненного цикла

Используется прием «Метафор» - аналогий того, на что

похоже или не похоже будет ПО

Выбор требований осуществляет заказчике, входящий

в состав команды разработчиков

1-62


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

214 Отображение 2 отсканированной единицы товара

После сканирования упаковки вверху терминала появляется краткое описание товара и его цена.

Номер историиТрудоемкость

в пунктах.1пункт=1чел/неделя

На обратной стороне – описание приемочного теста

1-63


Иерархия требований в ХР

ПредставлениеЦели и назначение создаваемого ПО

История История История

Задача

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

Набор проекта

Стек

Цели

Стек Стек

Задачи и тесты для реализации историй

1-64


Вопросы?

1-65


1 День. Обзор

Определение. Место в разработке.

Границы продукта vs проекта.

Проблемы определения требования.

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

Структура документа (IEEE Std 830).

Требования в XP-программировании.

1-66

sep reqm-lec1

Technology