Downloaded 20 times
![ХОРОШАЯ спецификация требований
Хорошая СТПО должна быть:
Правильной
Завершенной
Непротиворечивой
Модифицируемой
[ IEEE Std. 830-1998 ]
TEKAMA
Software Engineering Professional Program © 2007. 2-9](https://image.slidesharecdn.com/sep-reqm-lec2-120412105825-phpapp01/85/Sep-reqm-lec2-9-320.jpg)
![Виды прототипов
Демонстрационные прототипы
Бумажные
Электронные
Действующие прототипы
Горизонтальные
Вертикальные
Эволюционные
[К.Вигерс]
TEKAMA
Software Engineering Professional Program © 2007. 2-40](https://image.slidesharecdn.com/sep-reqm-lec2-120412105825-phpapp01/85/Sep-reqm-lec2-40-320.jpg)
Uploaded byNatalia Zhelnova
Sep reqm-lec2
Документ освещает качество спецификаций требований в разработке программного обеспечения, подчеркивая важность их полноты, однозначности и проверяемости. Он рассматривает различные методы управления изменениями требований и моделирования, включая диаграммы потоков данных и варианты использования. Также обсуждаются преимущества использования прототипов для уточнения требований и минимизации изменений в процессе разработки.
More Related Content
Sep reqm-lec2
- 1. Качество спецификации требований Хорошее представление требования. Хорошая спецификация. TEKAMA Software Engineering Professional Program © 2007. 2-1
- 2. День 2. Качествотребований День 1. Требования. Спецификация требований. День 2. Качество требований. Качество спецификаций Контроль статуса требований Моделирование требований Упреждающая разработка требований День 3. Управление изменениями TEKAMA Software Engineering Professional Program © 2007. 2-2
- 3. ХОРОШЕЕ описание требования удовлетворяет следующим критериям: Полнота Однозначность Необходимость Осуществимость Проверяемость TEKAMA Software Engineering Professional Program © 2007. 2-3
- 4. TEKAMA Software Engineering ProfessionalProgram © 2007. 2-4
- 5. Атрибуты требования Структурные атрибутыотдельного требования: Код Название Описание Источник Ранжир Связь TEKAMA Software Engineering Professional Program © 2007. 2-5
- 6. Контроль статуса «Как движетсяработа над той подсистемой, Джеки», — спросил Дейв. «Довольно хорошо, Дейв. Готово около 90%». Дейв был озадачен: «А разве пару недель назад ты не сделала примерно 90%?» Джеки ответила: «Я думала, что да, но теперь эти 90% действительно готовы» TEKAMA Software Engineering Professional Program © 2007. 2-6
- 7. Контроль статуса Proposed(Предложено) Approved (Одобрено) Implemented (Реализовано) Verified (Проверено) Deleted (Удалено) Rejected (Отклонено) TEKAMA Software Engineering Professional Program © 2007. 2-7
- 8. Контроль статуса TEKAMA Software Engineering Professional Program © 2007. 2-8
- 9. ХОРОШАЯ спецификация требований Хорошая СТПО должна быть: Правильной Завершенной Непротиворечивой Модифицируемой [ IEEE Std. 830-1998 ] TEKAMA Software Engineering Professional Program © 2007. 2-9
- 10. Правильная СТПО включает все требования, которые должны быть реализованы в ПО TEKAMA Software Engineering Professional Program © 2007. 2-10
- 11. Завершенная СТПО Представляет собой оформленный документ, с названием, обозначением, номером редакции, датами выпуска и утверждения. Должна быть снабжена оглавлением и иметь корректные ссылки. Не должна содержать мест, которые нужно доопределять. TEKAMA Software Engineering Professional Program © 2007. 2-11
- 12. Непротиворечивая СТПО Однитребования не должны противоречить другим. По всему документу: одни и те же понятия, сущности и функции должны обозначаться одним и тем же термином. одни и те же характеристики объектов должны иметь одно значение. TEKAMA Software Engineering Professional Program © 2007. 2-12
- 13. Модифицируемая СТПО Позволяетпо возможности просто вносить изменения в требования за счет: логичной структуры оглавления, предметного указателя и точных перекрестных ссылок представления одного требования в одном месте стабильной идентификации требований TEKAMA Software Engineering Professional Program © 2007. 2-13
- 14. Вопросы? TEKAMA Software Engineering Professional Program © 2007. 2-14
- 15. Реальность сурова Реальность -это разница между тем, что доставляет нам удовольствие, и тем, чем мы вынуждены довольствоваться. Габриель Лауб, журналист и писатель TEKAMA Software Engineering Professional Program © 2007. 2-15
- 16. TEKAMA Software Engineering ProfessionalProgram © 2007. 2-16
- 17. Спасение утопающих … TEKAMA Software Engineering Professional Program © 2007. 2-17
- 18. Упражнение «Анализ требований» Входе выполнения упражнения предлагается: изучить предлагаемую спецификацию сделать замечания по ее содержанию и структуре подготовить контекстную диаграмму сформировать словарь данных TEKAMA Software Engineering Professional Program © 2007. 2-18
- 19. МОДЕЛИРОВАНИЕ ТРЕБОВАНИЙ Виды моделей. Диаграммы потоков данных. Диаграммы «сущность-связь» Другие модели TEKAMA Software Engineering Professional Program © 2007.
- 20. Виды моделей Представление требованийс помощью графических, табличных или формальных текстовых нотаций, таких как: диаграммы потоков данных (DFD) диаграммы "сущность-связь" (ERD) диаграммы вариантов использования (Use case) диаграммы состояний (STD) диаграммы классов карты диалогов диаграммы взаимодействия ..... TEKAMA Software Engineering Professional Program © 2007. 2-20
- 21. TEKAMA Software Engineering ProfessionalProgram © 2007. 2-21
- 22. Диаграмма потоков данных(DFD) Данные клиента Параметры продукции Нормативы Менеджер Рассчитать Технолог Бланк заказ Справочники расчета Расчет Утвердить Работы Бланк заказа заказ Материалы Паспорт Заказ заказа Расчеты Оформить Заказы Заказ документы TEKAMA Software Engineering Professional Program © 2007. 2-22
- 23. Правила чтения DFD Процесс Хранилище Поток Агент TEKAMA Software Engineering Professional Program © 2007. 2-23
- 24. Диаграмма «сущность-связь» (ERD) TEKAMA Software Engineering Professional Program © 2007. 2-24
- 25. Правила чтения ERD Контактное лицо 1:1 представление 1:1 1:1 0:M Договор Клиент Агент 1:M 0:M 0:M 0:1 1:1 0:1 0:M 1:1 Запрос Заказ расчет 1:1 1:1 прием 0:M 0:M Менеджер оформление TEKAMA Software Engineering Professional Program © 2007. 2-25
- 26. Структура БД (сравнитьс ERD) Должность Контактное лицо Категория клиента Памятное событие Договор Клиент Источник рекламы Агент Причина отказа Запрос Заказ Событие запроса Оригинал Менеджер TEKAMA Software Engineering Professional Program © 2007. 2-26
- 27. Плюсы и минусыдиаграмм +++ --- Строгость Неполнота информации Наглядность Необходимость обучения Нужны инструменты Трудоемкость создания Дублирование информации TEKAMA Software Engineering Professional Program © 2007. 2-27
- 28. Подход на основевариантов использования (use case) Вариант использования описывает набор взаимодействий системы и внешнего действующего лица. Действующим лицом может быть человек, другая программная система или аппаратное устройство. Понятие «вариант использования» возникло в ООП, но может использоваться и в других проектах. Почему? Варианты использования изменяют подход разработки требований: вместо того, «что должна делать система» на подход «что должны делать пользователи». Диаграммы вариантов использования создают высокоуровневое представление требований пользователей. TEKAMA Software Engineering Professional Program © 2007. 2-28
- 29. Преимущества вариантов использования Помогает аналитикам и разработчикам понять как деятельность пользователей, так и предметную область. Позволяет обнаружить неточности и неясности требований на раннем этапе. Предотвращает появление «функций-сирот», которые никогда не используются, хотя и были реализованы. Помогают задать приоритеты требований. Если проследить варианты использования до уровня функциональных требований, то при изменении бизнес-процессов легче управлять каскадными изменениями. Выявляют важные объекты предметной области и их взаимоотношения. TEKAMA Software Engineering Professional Program © 2007. 2-29
- 30. Основы вариантов использования К важным элементам варианта использования относятся: Уникальный идентификатор Имя, явно описывающее задачу пользователя в формате «глагол + объект», например, «вставить файл» Краткое текстовое описание на обычном языке. Список предварительных условий, которые должны быть выполнены, прежде чем сможет начаться вариант использования. Выходные условия, описывающие состояние системы после успешного завершения варианта использования. Пронумерованный список действий, описывающий последовательность этапов взаимодействия пользователя и системы. TEKAMA Software Engineering Professional Program © 2007. 2-30
- 31. Определение вариантов использования AlistairCockburn, «Writing Effective Use Cases» Один вариант использования – одна цель одного актора (пользователя, компьютера) Цель: отдельная от других достигается немедленно имеет ценность для актора Типичное время достижения цели – от 2 до 20 минут, если актор – пользователь (меньше, если компьютер) TEKAMA Software Engineering Professional Program © 2007. 2-31
- 32. Вариант использования Графическое представление Перевод со счета на счет «Включает» Сохраняет информацию об остатке на счете Обновление остатка на счете Bank Teller Банковский служащий База данных Проверяет баланс счета «Расширяет» Снимает наличные Клиент Диаграмма UML Банкомат TEKAMA Software Engineering Professional Program © 2007. 2-32
- 33. Вариант использования Другое графическоепредставление Обычный ход выполнения Предварительные условия Этап 1 Альтернативный ход выполнения Условние Этап 2a Этап 2 Этап 2b Этап 3 Этап 2c Выходные условия Диаграмма деятельности (Activity Diagram) KW135 TEKAMA Software Engineering Professional Program © 2007. 2-33
- 34. От вариантов использованияк функциональным требованиям Варианты использования не являются функциональными требованиями Они описывают поведение систем с точки зрения пользователя. В них не отражается множество важных для разработки деталей. Три возможных способа документирования функциональных требований, связанных с вариантами использования: Только варианты использования Включает все необходимые функциональные требования в описание каждого варианта использования. Варианты использования и спецификация требований ПО Необходимо только установить прослеживаемость между вариантами использования и функциональными требованиями спецификации требований ПО. Только спецификация требований ПО Необходимо определить копию функциональных требований. TEKAMA Software Engineering Professional Program © 2007. 2-34
- 35. Варианты использования: ловушки применения Слишком много вариантов использования Крайне сложные варианты использования Включение интерфейса пользователя в варианты использования Включение определения данных в варианты использования Варианты использования, которые не могут понять пользователи Новые бизнес процессы Чрезмерное использование отношений «расширяет» и «включает» TEKAMA Software Engineering Professional Program © 2007. 2-35
- 36. Вопросы? TEKAMA Software Engineering Professional Program © 2007. 2-36
- 37. Прототипирование Использование прототипов. Упреждающая разработка документации TEKAMA Software Engineering Professional Program © 2007.
- 38. Использование прототипа Прототип -представительская или действующая модель реализации требований пользователей, позволяющая: уточнить требования быстро получить обратную связь выявить скрытые требования что, в итоге, сокращает объем изменений требований в ходе проекта. TEKAMA Software Engineering Professional Program © 2007. 2-38
- 39. TEKAMA Software Engineering ProfessionalProgram © 2007. 2-39
- 40. Виды прототипов Демонстрационные прототипы Бумажные Электронные Действующие прототипы Горизонтальные Вертикальные Эволюционные [К.Вигерс] TEKAMA Software Engineering Professional Program © 2007. 2-40
- 41. TEKAMA Software Engineering ProfessionalProgram © 2007. 2-41
- 42. Традиционный подход кразработке СОЦИАЛЬНАЯ СРЕДА Использование Выявление Заимствование ПО требований терминологии Спецификация Руководство требований пользователя Описание Создание Программное обеспечение Идея - D.Ross TEKAMA Software Engineering Professional Program © 2007. 2-42
- 43. Упреждающая разработка документации СОЦИАЛЬНАЯ СРЕДА Выявление Использование требований и ПО проектирование Коррекция взаимодействия Образ руководства Руководство пользователя пользователя Создание Уточнение Программное обеспечение Идея - D.Ross TEKAMA Software Engineering Professional Program © 2007. 2-43
- 44. TEKAMA Software Engineering ProfessionalProgram © 2007. 2-44
- 45. Преимущества метода Ненужно придумывать структуру документа Простой критерий полноты требований Нет соблазна навязывать программисту проектные решения Повышение качества ПО за счет того, что: аналитик смотрит на ПО «глазами» пользователя пользователю проще оценить создаваемое ПО и дать более качественную обратную связь Быстрое создание пользовательской документации TEKAMA Software Engineering Professional Program © 2007. 2-45
- 46. Вопросы? TEKAMA Software Engineering Professional Program © 2007. 2-46
- 47. Проверка требований Процессы Контрольные списки вопросов TEKAMA Software Engineering Professional Program © 2007.
- 48. Еще раз, ХОРОШЕЕописание требования удовлетворяет следующим критериям: Полнота Однозначность Необходимость Осуществимость Проверяемость TEKAMA Software Engineering Professional Program © 2007. 2-48
- 49. Проверка требований Спецификация Список требований Планирование замечаний Ознакомление Подготовка Обсуждение Инспекция Завершение TEKAMA Software Engineering Professional Program © 2007. 2-49
- 50. Польза от проверкиправильности требований Как компонент разработки требований, проверка правильности обеспечивает, что: Спецификация требований к ПО правильно описывает системные характеристики и возможности, которые отвечают потребностям пользователей Требования к ПО правильно отражают бизнес-правила, системные требования, и др. Требования полны и высококачественны Все представления требований согласованы друг с другом Требования обеспечивают хорошую основу для проектирования и реализации. TEKAMA Software Engineering Professional Program © 2007. 2-50
- 51. Рецензирование требований Двеосновные категории Неформальные рецензии (сбор соответствующих неструктурированных отзывов) Проверка коллегой Коллективная проверка Критическая проверка Формальные рецензии (сбор отзывов в соответствии с хорошо регламентированным процессом) Экспертиза TEKAMA Software Engineering Professional Program © 2007. 2-51
- 52. Контрольные списки вопросов Вопросы,связанные с корректностью: Конфликтуют ли одни требования с другими? Имеются ли повторы требований? Написаны ли требования ясно, точно и недвусмысленно? Можно ли проверить выполнение каждого требования? He выходит какое-либо требование за границы проекта? Нет ли в требованиях содержательных, языковых ошибок? Можно ли реализовать все требования в наших условиях? Все ли сообщения об ошибках уникальны и выразительны? ….. TEKAMA Software Engineering Professional Program © 2007. 2-52
- 53. TEKAMA Software Engineering ProfessionalProgram © 2007. 2-53
- 54. Домашнее задание Результирующая спецификациядолжны включать: назначение продукта; категории пользователей; контекстную диаграмму продукта; требования к свойствам и ограничениям; детальное описание функций ПО; словарь данных. TEKAMA Software Engineering Professional Program © 2007. 2-54
- 55. День 2. Обзор Качество спецификаций Контроль статуса требований Моделирование требований Использование прототипа Упреждающая разработка требований TEKAMA Software Engineering Professional Program © 2007. 2-55
Editor's Notes
- #4 Каждая требование описывается в СТПО отдельным фрагментом текста. При описании функций, они дробятся до такой степени, что с точки зрения пользователя каждая элементарная функция не предполагает выполнения более простых функций. Хорошее описание требования отвечает следующим критериям: Полнота. Требование содержит всю необходимую информацию для разработки связанной с ним функциональности. В него включается вся информация о функции, известная на момент описания. Причины неполноты описания следует явно объявлять. ЛОВУШКА. Основной ошибкой при описании функций является неполное перечисление входных и выходных данных (чаще всего не включаются данные, хранящиеся в БД).
- #5 Однозначность . Требование должно быть внутренне не противоречиво и читатели должны понимать его одинаково. Требования следует выражать просто, кратко и точно, используя известные термины. Обычно базовые знания читателей СТПО различаются. Поэтому в ее состав нужно включить раздел с определением понятий прикладной области, используемых при определении требований. Пример, неоднозначного требования. "Период обновления экрана должен быть не менее 20 сек." Необходимость . Требование должно отражать возможность ПО, действительно необходимую пользователям, или вытекающую из других требований. Осуществимость . Включаемое в СТПО требование должно быть выполнимым при заданных ограничениях операционной среды. Наличие этого свойства проверяется в процессе анализа осуществимости разработчиком. Проверяемость . Проверяемость требования означает, что существует конечный и разумный по стоимости процесс ручной или машинной проверки того, что ПО удовлетворяет этому требованию. Каждое требование (особенно не функциональное) должно содержать достаточно информации для однозначной проверки его реализации. Иначе, факт реализации будет основываться на мнении, а не на анализе, что приведет к проблемам при сдаче готового ПО.
- #6 Для эффективного управления требованиями и их изменениями, описание требования должно включать следующую информацию: Код - уникальный идентификатор, сохраняемый за требованием на всем жизненном цикле ПО. При удалении требования его код не присваивается никакому другому. Маркированные списки и номера заголовков редактора текстов не годятся, так как они автоматически меняются при добавлении и удалении требований. Название - краткое уникальное название требования для содержательного упоминания из других мест СТПО и других документов. Описание - содержание требования (текст, возможно с ссылками на диаграмму или другое формализованное описание). Источник - источник, требования: имя человека, название документа, на основании которого требование возникло. Ранжир - каждому требованию желательно присваивать числовую или качественную оценку его важности и стабильности («обязательное», «важное», «необязательное», «стабильное» «возможно изменится»). Это дисциплинирует заказчиков в выборе требований, а разработчикам позволяет правильно распределять усилия в ходе проекта. Связь - ссылка на исходное требование, если оно имеется.
- #7 Иногда разработчики ПО слишком оптимистичны , когда сообщают об окончании задачи . Часто они выдают сами себе кредит , считая выполненными те задачи , к которым они приступили , но еще не закончили . Они могут сделать первоначально определенную работу на 90%, а затем столкнуться с непредвиденными трудностями . Тенденция переоценивать выполнение работе приводит к ситуации , типичной для всех проектов по разработке ПО или крупных задач , когда в течение долгого времени сообщается , что выполнено 90% объемов . Контроль статуса каждого функционального требования на протяжении всей разработки позволяет более точно оценивать готовность проекта . Ожидание же «выполнения задач» означает только повторы . Например , вы планируете реализовать в следующей версии только часть варианта использования , оставив полную реализацию до будущих версий . В этом случае вы будете отлеживать состояние тех функциональных требований , которые запланированы для ближайшей версии , поскольку этот набор требований должен быть выполнен на 100% до выпуска продукта . Ловушка Существует старая шутка , что на первую половину проекта по разработке тратится 90% ресурсов , а на остальную половину - оставшиеся 90% ресурсов . Чересчур оптимистичная оценка и попустительское отношение к контролю статуса - верный путь к перерасходам в проекте . В таблице далее перечислено несколько возможных состояний требований . ( Альтернативная схема показана в Caputo, 1998.) Некоторые специалисты добавляют состояние Designed (Разработано ) ( если элементы дизайна , в которых отражены функциональные требования , созданы и проверены ) и Delivered (Выпущено ) ( ПО отдано в руки пользователей , как для бета - тестирования ). Полезно отслеживать требования , от которых вы отказались , и причины этого , потому что отвергнутые требования имеют обыкновение «всплывать» в ходе разработки . Статус Rejected (Отклонено ) позволяет оставить предложенное требование доступным для будущего использования , не создавая беспорядка в наборе утвержденных требований для определенного выпуска .
- #8 Распределение требований по нескольким категориям состояния имеет больший смысл , чем попытка контролировать процент завершения каждого требования или всей базовой версии . Определите , кто может изменить состояние требования , и обновляйте статус , только когда удовлетворены определенные условия перехода . Изменение состояния также ведет к обновлению данных о трассируемости требований , когда указывается , в каких элементах дизайна , кода и тестирования отражено требование Proposed (Предложено ) Требование запрошено авторизированным источником Approved (Одобрено ) Требование проанализировано , его влияние на проект про - ; считано , и оно было размещено в базовой версии определенной версии . Ключевые заинтересованные в проекте лица согласились с этим требованием , а разработчики ПО обязались реализовать его Implemented (Реализовано ) Код , реализующий требование , разработан , написан и протестирован . Требование отслежено до соответствующих элементов дизайна и кода Verified (Проверено ) Корректное функционирование реализованного требования подтверждено в соответствующем продукте . Требование отслежено до соответствующих вариантов тестирования . Теперь требование считается завершенным Deleted (Удалено ) Утвержденное требование удалено из базовой версии . Опишите причины удаления и назовите того , кто принял это решение Rejected (Отклонено ) Требование предложено , но не запланировано для реализации ни в одной будущих версий . Опишите причины отклонения требования и назовите того , кто принял это решение
- #10 СТПО представляет собой целостный текстовый документ определенного содержания и структуры. Основная часть этого документа излагается на естественном языке, который может дополняться фрагментами на формализованных и формальных языках. ХОРОШУЮ спецификацию отличает единый технический стиль изложения, краткость и точность выражений, полнота информации, использование пользовательской терминологии, отсутствие компьютерного слэнга. Хорошей аналогией для СТПО является текст программы. Отличие состоит в том, что текст программы управляет компьютером, а текст СТПО – разработчиками. Для проверки правильности программа должна выполняться на компьютере, а для проверки правильности СТПО – она должна проверяться участниками разработки и заказчиками. Нет рецептов для подготовки хорошего текста СТПО, но есть некоторые общие принципы и рекомендации, а также опыт работы. На следующих слайдах представлены свойства, относящиеся ко всему документу в целом.
- #11 Правильная спецификация включает все требования, которым должен удовлетворять продукт, которые на текущий момент времени могут быть выявлены. Для обеспечения полноты спецификации она должна быть проверена всеми заинтересованными лицами и сопоставлена с документами, накладывающими ограничения на разрабатываемый продукт. Ответственность за полноту требований заказной разработки разделяют заказчик (или тот, кто выполняет его роль) и разработчики, а в случае рыночной разработки – маркетолог (или тот, кто выполняет его роль) и разработчики. Правильная спецификация не включает те требования, которые относятся к далекой перспективе развития продукта, а должна включать только подлежащие реализации требования (возможно относящиеся к запланированной последовательности версий продукта).
- #12 СТПО должна быть оформлена как законченный документ с названием, обозначением, номером редакции и датами выпуска и утверждения. Такой документ должен быть снабжен оглавлением, и иметь корректные перекрестные ссылки как внутри документа, так и к другим документам. В завершенном документе должны быть минимизированы места, которые требуют дополнительных исследований и с оставшимися неразрешенными вопросами. Если таковые имеются, то они должны быть явно выделены (на западе используют метку TBD - " to be determinad "). Только правильная и завершенная СТПО позволяет правильно выбрать архитектуру разрабатываемого ПО и спланировать работы по проекту. Если разработка начинается на основе неполных, случайно отобранных требований, невозможно определить их приоритетность и правильно спланировать проект. При этом, возникает большой риск неадекватного выбора архитектуры и инструментов разработки, а также риск того, что проект будет протекать в условиях большого потока изменений требований с постоянным увеличением стоимости и сроков разработки.
- #13 Каждое требование в спецификации должно быть согласовано с другими, и не противоречить родительским или соседним требованиям. Для одних и тех же понятий, сущностей и функций в разных местах СТПО должны использоваться одни и те же термины. И один и тот же термин не должен использоваться для обозначения разных понятий, сущностей и функций. Использование синонимов затрудняет понимание документа. По всему документу одни и те же характеристики объектов (например, объемы данных) должны иметь одни и те же значения.
- #14 Документ СТПО должен быть организован так, чтобы его можно было легко изменять, сохранялась история изменений и легко определялось текущее состояние требований. Это предполагает использование уникальной и стабильной идентификация требований, минимальное дублирование информации и корректную идентификацию редакций СТПО. СТПО меняется в процессе разработки вследствие изменения требований в окружающей ПО системе, увеличения степени понимания того, что нужно, детализации требований, обнаружения в СТПО пропусков, дефектов, неточностей. Модификация неизбежна. Главное при этом, чтобы существовал формализованный процесс идентификации, контроля, прослеживания, одобрения изменений требований и доведение их до всех разработчиков.
- #16 СТПО, которая отвечает всем рассмотренным ранее требованиям, представляет собой некоторый идеал, который трудно достижим в условиях реальной современной разработки, когда заказчик требует получения ПО в кратчайшие сроки. В реальности, качество требований, которые доходят до программистов, "оставляет желать лучшего". Как правило, они неполны и излагаются поверхностно, часто в виде перечня основных возможностей продукта. Обычно детализация таких требований происходит параллельно с разработкой программ. Уточнение требований в лучшем случае согласуется с заказчиком или пользователями, а в худшем - многие решения принимаются самими разработчиками из их собственных представлений о том, что нужно пользователям. При этом требования явно не фиксируются, а сразу воплощаются в коды программ. При этом «крайними», как правило, оказываются программисты, так как представление о том, что должна делать программа является исключительно мнением заказчика после его знакомства с готовым продуктом.
- #17 В такой ситуации времени на исправление неправильно принятых решений остается мало и проект прекращается либо переходит в затяжную стадию с бесконечными разборками в том, кто виноват и кто должен оплачивать доработку и модификацию разработанного ПО.
- #19 В качестве упражнения предлагается выполнить анализ готовой спецификации и подготовить «Список замечаний», «Контекстную диаграмму» и «Словарь данных» для небольшого приложения. Цель данного упражнения состоит в том, чтобы на практике закрепить полученные представления о хорошей спецификации требований и получить практические навыки в построении контекстной диаграммы и формировании словаря данных.
- #20 Требования обычно записываются в виде текста на естественном языке. Однако, в настоящее время широко используются различного рода графические способы их представления, называемые моделями. Моделирование требований заключается в их представлении в графической форме с помощью определенных правил записи (нотаций). Использование моделей позволяет добиваться более точных и согласованных требований, чем в случае чисто текстового представления. Это особенно важно для критичных к безопасности и надежности систем.
- #21 Требования обычно записываются в виде текст на естественном языке. Однако, в настоящее время широко используются различного рода графические способы представления требований, которые называются моделями. Под моделированием требований понимается их визуальное представление с использованием графических формализованных правил записи (нотаций). Использование моделей позволяет добиваться более точных и согласованных требований, чем в случае чисто текстового представления. Это особенно важно для критичных к безопасности и надежности систем. Перечень примеров таких нотаций представлен на слайде. Эти и другие диаграммы (наиболее полный их набор определен в языке UML) дают более наглядное представление о поведении систем и помогают анализировать требования на полноту, точность и непротиворечивость.
- #22 ЛОВУШКА1 . Модели можно использовать как для анализа существующих систем и определения требований к создаваемым системам (концепция), так и для проектирования ПО. При этом часто анализ требований подменяется проектированием, а требования к ПО - проектными решениями Языки диаграмм способствуют этому, используя одни и те же или похожие системы обозначений. Модели вещь хорошая, но трудоемкая. Их применение может потребовать обучения, накопления навыков. Кроме того, для создания моделей обычно используется специализированное ПО, т.н. CASE средства ( computer-a sisted software engineering). Они позволяют "рисовать" диаграммы, “поддерживают” определенную нотацию и "знают" правила моделирования, помогая выявлять несоответствия, противоречия и неполноту информации. Рекомендуется создавать диаграммы для наиболее сложных мест в системе. ЛОВУШКА2 . По своему стилю диаграммы навязывают лаконичность в обозначениях их элементов. Они не позволяют передавать многие тонкости используемых понятий. При этом возникает риск не однозначного понимания реальной сути действий и данных. Поэтому, их можно использовать только как иллюстрации, дополняющие развернутые описания на естественном языке, а не как их замена. В задачи Курса не входит обучение методикам формирования различных моделей, правилам их представления и инструментам, помогающим это делать. Но некоторые наиболее важные типы моделей мы рассмотрим.
- #23 Диаграмма потоков данных (Data Flow Diagram, DFD) определяет функции (процессы), данные (материалы) в системе и связь функций по потокам данных. Кроме этого, на этой диаграмме показываются хранилища данных и связи системы с внешним миром. При моделировании сложных систем используется прием функциональной декомпозиции, при которой сложные функции раскладываются на более простые по уровням детализации. Верхний уровень модели DFD по сути является контекстной диаграммой системы, представляющей систему как один процесс.
- #24 Диаграмма потоков данных строится из следующих элементов: Процесс - представляет действие, преобразующее поток входных данных в поток выходных. Действие может выполняться человеком, подразделением, устройством или компьютером. Для DFD неважно кто или что его выполняет. Каждый процесс должен иметь хотя бы один входной и выходной поток данных. Процесс обычно обозначают глаголом с дополнением. Агент - элемент системы, который является источником или приемником потока данных. Для ПО агент всегда представляет элемент окружения. Агента обычно обозначают существительным с дополнением. Хранилище - место хранения экземпляров данных или материалов (файл, БД, шкаф, папка). Хранилище обычно обозначают существительным с дополнением. Поток - представляет входные и выходные данные или материалы для процессов, агентов, и хранилищ. Это трасса, по которой движутся элементы данных. Поток обычно обозначают существительным с дополнением. Все элементы такой диаграммы должны быть поименованы. При этом важно правильно выбирать имена элементов, согласуя их с текстовым описанием и обеспечивая легкость чтения диаграммы. ЛОВУШКА. DFD нельзя путать с блок-схемой. В отличие от блок-схем процессы могут выполняться параллельно, стрелки (потоки) показывают движение данных, а не последовательность действий (управление).
- #25 Диаграмма "сущность-связь" (entity-relationship diagram,ERD) отображает связи между объектами реального мира (сущностями), которые в ПО представляются данными. Эта диаграмма помогает структурировать, анализировать и понимать информационную составляющую системы. При определении требований сущности ERD представляют типы физических объектов: категорий людей, сырья, продукции, машин, приборов, сооружений, печатные или электронные документы. Простота ERD позволяет для их "рисования" использовать не только специализированные средства (эта выполнена с помощью CASE средства Design/IDEF) , но и офисные программы типа Word или PowerPoint. ЛОВУШКА . Не следует путать ERD-модель существующей или проектируемой системы с ERD, представляющей логическую или физическую структуру базы данных программного продукта. При определении требований ERD -отражает существенные для бизнеса свойства объектов реального мира. Эти свойства нужно искать в прикладной области, а не в компьютере. В литературе можно найти массу вариантов, отличающихся содержанием ERD и нотацией. При этом важнейшим аспектом является наличие понятных и однозначных правил чтения диаграмм.
- #26 Представленная на этом слайде диаграмма выполнена c помощью PowerPoint. На ней: Прямоугольник представляет тип объекта, именуемого предельно кратко (1-3 слова) существительным, возможно, с дополнением. Соединение показывает наличие взаимосвязи объектов двух типов. Соединение (без стрелок, с одной или двумя стрелками) показывает количественную характеристику связи, определяемую бизнес-правилами прикладной области. Эту характеристику можно уточнить, указав одну или две метки показывающих обязательно ли два объекта должны быть связаны и максимальное число связанных объектов (обычно это M - "много"). На некоторых диаграммах соединения именуются, но придумать имя часто бывает непросто. Связь между объектами всегда двусторонняя и нужно два имени (например, «запрос поступивший от клиента», «клиент сделавший запрос»). Хорошим стилем является отглагольное существительное (например, «поступление»). Именовать связь не обязательно, так как обычно суть ее понятна из диаграммы. Читается такая диаграмма так: "Клиент может сделать один или несколько запросов", "Запрос всегда связан с одним клиентом", "Клиента обязательно представляет одно и только одно контактное лицо" и т.п. РЕКОМЕНДАЦИЯ. Перед изучением любой представленной Вам диаграммы уточните сначала смысл обозначений и правила чтения.
- #27 Часто вместо ERD, отражающей сущности реального мира, создается ERD, представляющая структуру (логическую или физическую) базы данных. Первая используется для анализа требований, а вторая – для проектирования ПО. Различие довольно тонкое, но оно есть. В первой сущности представляют реальные физические объекты, а во второй – элементы разрабатываемого ПО: таблицы, списки и т.п., которые не обязательно соответствуют реальным объектам. Включение на этапе определения требований в ERD структур данных, не представляющих физические объекты, загромождают ее, затрудняют анализ требований и провоцируют преждевременное принятие проектных решений.
- #28 Для создания моделей обычно используется специализированное ПО, т.н. CASE средства (computer-a sisted software engineering). Они позволяют "рисовать" диаграммы, “поддерживают” определенную нотацию и "знают" правила моделирования, помогая выявлять несоответствия, противоречия и неполноту информации Модели вещь хорошая, но трудоемкая. Их применение требует обучения и накопления навыков использования. Поэтому рекомендуется создавать диаграммы только для наиболее сложных мест в системе. Модели можно использовать как для анализа существующих систем, определения требований к создаваемым системам так и для проектирования ПО. ЛОВУШКА1 . При использовании моделей часто анализ требований подменяется проектированием, а требования к ПО - проектными решениями Языки диаграмм способствуют этому, используя одни и те же или похожие системы обозначений. По своему стилю диаграммы навязывают лаконичность в представлении информации, Информация на диаграммах представляется краткими обозначениями их элементов, которые не позволяют передавать многие тонкости используемых понятий. При этом возникает риск не однозначного понимания реальной сути действий и данных. С другой стороны, перегруженные текстом диаграммы плохо читаются и теряется эффект от их использования. ЛОВУШКА2 . Часто возникает желание при определении требований обойтись одними диаграммами. При этом большой объем информации остается «за кадром». Поэтому, диаграмм лучше использовать только как средство анализа или в качестве иллюстраций, дополняющих развернутые описания требований на естественном языке. Но в этом случае они начинают дублировать информацию и затрудняют модификацию требований.
- #39 Основной проблемой определения требований является их выявление и согласование с пользователем. Фраза пользователя «Я не знаю, как описать мои потребности, но узнаю, когда увижу программу» означает, что для понимания того, что должно делать ПО, нужно его сначала сделать и услышать другую фразу «Нет, это не то! Это нужно переделать!». Многие не могут описать свои потребности, не имея перед собой чего-то осязаемого в качестве образца (критиковать легче, чем создавать). Для решения этой проблемы иногда используется прототип (prototype) – представительская или действующая модель реализации требований пользователей, создаваемая с целью выявления или проверки требований. Работа с прототипом стимулирует мышление пользователей в процессе уточнения требований. Прототип полезен для выявления и устранения двусмысленных и неполных требований и дает людям, не обладающие техническими знаниями, конкретное понимание продукта.
- #40 Прототипы решают следующие основные задачи: - прояснить формулировку требований к части ПО, вызывающей затруднения в понимании. - исследовать альтернативные варианты реализации взаимодействия пользователей, - показать, насколько осуществимы требования; ЛОВУШКА1 . Работа с прототипом может отвлечь внимание пользователей от сути функциональности в сторону косметических вопросов или проблем качества прототипа. ЛОВУШКА2. Иногда пользователи не склонны критиковать действующий прототип, в который вложено много труда. Разработчики также могут сопротивляться существенным изменениям тщательно выполненного электронного прототипа. Основным недостатком прототипов является то, что их дорого разрабатывать. Однако, если они исключат реализацию ложных требований, их стоимость может быть оправдана.
- #41 Прототипы могут представлять собой действующие или статические модели с детальным образом экрана или его эскизом. К.Вигерс различает следующие виды прототипов: Горизонтальный прототип - реализует некоторые особенности интерфейса пользователя. Он позволяет пользователю увидеть или ощутить поведение ПО в некоторых ситуациях и понять, насколько такое ПО подойдет для выполнения его работы. Это обычно одноразовые программы, которые пренебрегают устойчивостью, надежностью, производительностью. ЛОВУШКА . Не усложняйте прототип больше, чем это нужно для целей его создания. Не поддавайтесь искушению или давлению пользователей добавлять в прототип новые функции. Вертикальный прототип - реализует полную функциональность отдельной части ПО. Он демонстрирует осуществимость предполагаемого подхода к архитектуре, оптимальность алгоритма, правильность схемы БД, проверяет важные временные требования. Обычно он становится частью конечного продукта.
- #42 Эволюционный прототип - создается на прочном архитектурном «фундаменте» с целью постепенного расширения продукта по мере прояснения требований. Здесь с самого начала пишется качественный код. Он подходит для легко расширяемых приложений (информационные системы, Интернет-приложения). Какими бы совершенными ни были инструменты для создания действующих прототипов, наброски экранов на бумаге или в электронном виде делать все равно быстрее, дешевле и технологичней. Это ускоряет цикл взаимодействия с пользователем, что является ключевым фактором успеха при разработке требований Наброски экранов можно делать, не сильно заботясь о внешнем виде. На таком прототипе можно объяснить пользователю, как он будет работать с конкретным экраном. Нажатие кнопок моделируется показом следующих образов экранов и проверяет реакцию пользователя.
- #43 Традиционный подход к разработке ПО заключается в предварительном (до начала проектирования и кодирования программ) выявлении потребностей пользователей и фиксации их в форме некоторого структурированного документа - СТПО. Структура и содержание этого текстового документа обычно определяться некоторым стандартом (например, ГОСТ 19.201 или. IEEE Std . 830). Другой формой представления требований являются различного рода модели ( DFD , ERD и т.п.). Модели представляют собой более формализованные структуры, которые могут дополнять текстовое описание требований. Документы с определением требований являются основой для решения следующих задач: (1) согласования требований с заказчиком ПО (2) разработки рабочих продуктов, в процессе создания ПО (3) проверки того, что разработанное ПО соответствует определенным требованиям. Одним из основных правил при подготовке таких документов является высокая фрагментация функциональных требований на элементарные функции, что облегчает их реализацию, тестирование, изменение и контроль процесса разработки. Но есть и недостатки. Один недостаток состоит в том, что для понимания требований пользователь должен научиться понимать формализованные описания, которые, может быть легко читаются специалистами по информационным технологиям, но затрудняют получение пользователем представление о своей будущей работе с разрабатываемым ПО. Это затрудняется решение задачи (1) и снижает эффективность получения обратной связи от заказчика. Другой недостаток состоит в том, что разработчик требований должен предварительно изучить соответствующие стандарты и языки спецификации (это десятки, иногда сотни страниц), а в случае моделирования требований освоить и соответствующие методы и инструменты.
- #44 В 1978 году в ходе изучения проблемы определения требований и на основе накопленного опыта в небольшом коллективе коллег из Института повышения квалификации возникла «оригинальная» идея: фиксировать требования и «подавать» их пользователю в привычной для него форме «Руководства пользователя» (РП). Этот метод получил название «Упреждающая разработка документации» и был опубликован в трудах I всесоюзной конференции по технологии программирования в г. Киеве. в 1 С тех пор этот метод был многократно опробован и оправдал себя в большом числе проектов разного масштаба от индивидуальной разработки до проектов с участием десятков разработчиков. Метод описывается предельно кратко: «До начала разработки программы подготовь руководство по ее использованию». Речь идет о документе (образе РП), из которого пользователю должно быть ясно, как использовать разрабатываемую программу.
- #45 Конечно, это должно быть не описание возможностей, а подробная инструкция по работе с программой. Особенности и принципы создания такого образа РП следующие - уделить повышенное внимание описанию основных понятий. - дать эскизы всех экранов (в рамках возможностей MS Word ) и описать функции и данные с привязкой к этим экранам. - описать все входные данные и реакции системы. - описать на языке пользователя алгоритмы обработки его прикладных данных - представить эскизы отчетов То, что многие считают прерогативой программиста и отдают ему на откуп, на самом деле является особенностью прикладной области и представляет полезную информацию для пользователя: - название и назначение областей экрана - форматы данных и диапазоны допустимых значений - описание того, что делает компьютер после ввода информации с т.з. пользователя В терминах современного представления о требованиях этот метод представляет собой «полное бумажное прототипирование» продукта. Этот метод не исключает применения известных методов выявления, анализа и моделирования требований на ранней стадии. Во многом этот метод подкрепляется идеями Алана Купера о проектировании взаимодействия (см. его замечательную книгу «Психбольница в руках пациентов»)
- #46 Такой метод определения требований: - исключает необходимость придумывания структуры СТПО. Порядок изложения должен быть таким, чтобы максимально облегчить освоение программы. Примеров хороших чужих спецификаций увидеть практически невозможно, а примеров хороших Руководств пользователя много. - критерии полноты требований в форме образа РП интуитивно понятны - формату РП чуждо описание внутренностей программы, он сосредотачивает автора на описании границы продукта. - изложение в форме РП стимулирует более качественные и простые решения. Если что-то сложно объяснить (пользователю), то это означает, что решение выбрано неудачно. - затраты на подготовку образа РП многократно окупаются на разработке документации Образ РП полностью покрывает описание категорий функциональных требований и словарь данных. Однако в РП нет места для фиксации бизнес требований, проектных ограничений, требованиям к качеству ПО. Они должны быть представлены в других материалах.
- #49 Каждая требование описывается в СТПО отдельным фрагментом текста. При описании функций, они дробятся до такой степени, что с точки зрения пользователя каждая элементарная функция не предполагает выполнения более простых функций. Хорошее описание требования отвечает следующим критериям: Полнота. Требование содержит всю необходимую информацию для разработки связанной с ним функциональности. В него включается вся информация о функции, известная на момент описания. Причины неполноты описания следует явно объявлять. ЛОВУШКА. Основной ошибкой при описании функций является неполное перечисление входных и выходных данных (чаще всего не включаются данные, хранящиеся в БД).
- #50 СТПО является предметом для выполнения процедуры проверки и утверждения требований. Цель утверждения - получить уверенность в том, что разработчик понял требования, что они определяют ПО, нужное заказчику, что СТПО соответствует стандартам компании и отвечает имеющимся критериям качества. Следует явно запланировать одну или серию процедур утверждения СТПО, для выявления и разрешения имеющихся проблем. Утвержденная СТПО является основой для выделения ресурсов, планирования, разработки и приемки готового ПО. Для проверки СТПО можно применить одну из известных формализованных процедур типа Инспекций и Рассмотрений (inspection, reviews). Подробно эти процедуры изложены, например, в IEEE Std. 1028-1997, Standard for Software Reviews, 1998 . Проверка назначаться после подготовки базовой версии СТПО, или на любой другой стадии процесса. Для проверки СТПО назначается группа проверяющих, в задачу которых входит выявление в ней ошибок, неясностей и отклонений от стандартов. Подбор группы очень важен. При создании ПО на заказ (customer-driven project ) в группе должен быть по меньшей мере один представитель заказчика. Эффективность проверки можно повысить используя контрольные списки вопросов о том, что следует проверять в СТПО.
- #51 The Benefits of Requirements Validation As the forth component in requirements development, validation ensures that: The SRS correctly describes system characteristics and capabilities that meet users needs Software requirements are correctly derived from business rules, system requirements and/or other sources Requirements are complete and of high quality All requirements representations are consistent with one another There is an adequate basis for proceeding with design and implementation
- #52 Reviewing Requirements Two main categories Informal reviews (collecting unstructured ad-hoc feedback) A peer deskcheck A passaround A walkthrough Formal reviews (collecting feedback following a well defined process) Inspections
- #53 Контрольные списки вопросов готовятся обычно отдельно для каждого типа документов с требованиями. С помощью таких списков привлекается внимание проверяющих к часто возникающим проблемам. Примеры вопросов в контрольном списке для проверки СТПО приведен на слайде. Длинный контрольный список запомнить невозможно. Поэтому, он готовится сообразно с нуждами вашей компании, в соответствии с тем, какие проблемы в ваших требованиях повторяются чаще всего. Таких списков в организации может быть несколько. Вот другие примеры контрольных вопросов по разным аспектам СТПО. Организация и завершенность Корректны ли все ли ссылки? Описаны ли все требования на одном уровне детализации? Указан ли приоритет реализации каждого требования? Определены ли все внешние интерфейсы ПО? Определены ли все алгоритмы для функциональных требований? Включены ли все известные потребности клиента или системы?
- #54 Помечены ли места (знак «TBD»), которые требуют уточнения? Определено ли поведение системы для всех ошибочных условий? Атрибуты качества Все ли требования к производительности сформулированы конкретно? Возможность отслеживания Каждое ли требование идентифицировано уникально? Указан ли источник каждого требования? Особые проблемы Не являются ли некоторые требования проектными решениями? Заданы ли ограничения для функций критичных к времени выполнения? Рассмотрены ли все проблемы, связанные с интернационализацией?
- #55 Для того, чтобы закрепить изложенный материал, предлагается выполнить домашнее задание по подготовки хорошей спецификации. В качестве исходной информации предлагается перечень возможностей, которыми должно обладать разрабатываемое ПО. В качестве предмета разработки выступает сквозной для учебной программы SEP проект, для которого в качестве разработчиков выступают студенты. Ваша задача - подготовить на основе перечисленных возможностей СТПО. Цель проекта интуитивно довольно понятна и, чтобы не тратить время на взаимодействие с реальным заказчиком (его впрочем все равно нет), Вам предлагается взять на себя и роль заказчика и роль разработчика требований. При этом, выбор функциональности и свойств продукта является второстепенным. Цель домашнего задания - подготовить формально хорошую спецификацию, не углубляясь в вопросы зачем такой продукт и как он будет использоваться. Если объем работы окажется большим, то его следует регулировать исключением возможностей. Важно при этом, чтобы СТПО удовлетворяла рассмотренным свойствам хорошей спецификации.