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

1. Управление требованиями и изменениями Курс читает: Наталья Желнова TEKAMA 1-

2. Структура курса День 1. Требования. Спецификация требований. День 2. Качество требований. День 3. Управление изменениями 1-

3. Краткое содержание Что такое требования к ПО Какова их роль в разработке ПО Спецификация требований Как работать с требованиями , когда они изменяются А также: Практические занятия Рекомендации по работе с требованиями 1-

4. День 1. Требования. День 1. Требования. Спецификация требований. Определение. Границы продукта vs проекта. Проблемы определения требования. Спецификация требований. Структура документа ( IEEE Std 830) . Требования в XP- программировании. День 2. Качество требований. День 3. Управление изменениями 1-

5. Фазы разработки программного обеспечения Идея Анализ Проектирование Программирование Тестирование Внедрение Поддержка 1-

6. CMMI Разработана в 1991 году Институтом программной инженерии Университета Карнеги-Меллона (Software Engineering Institute, SEI) Внедрение СММ/CMMI позволяет улучшить структуру и качество процессов Отвечает на вопрос «Что?», но не «Как?» 1-

7. Место требований в программной инженерии 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-

8. CMMI. Process Areas 1- Maturity 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

9. CMMI . Эффективное управление требованиями Для эффективного управления требованиями CMMI рекомендует: Достичь понимания требований Получить обязательства по выполнению требований Управлять изменениями к требованиям Установить и поддерживать двустороннюю прослеживаемость требований Идентифицировать любые несоответствия между требованиями и проводимыми в проекте работами 1-

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

11. Вопросы? Пожелания? ? ! ? ! 1-

12. Базовые понятия Категории требований. Границы системы и ПО. Образ продукта и граница проекта 1-

13. О чем речь ? ТРЕБОВАНИЕ - свойство , которое должно быть проявлено в ПО или системе для решения некоторой проблемы реального мира. [SWEEBOK] 1-

14. Функциональные требования (примеры) «Программа должна сохранять расчеты всех заказов на изготовление продукции»; «Программа должна осуществлять поиск клиента по фрагменту названия или телефону»; « Список заказов должен сортироваться по убыванию времени оформления»; ......... 1-

15. Требования к интерфейсу (примеры) Имя пользователя должно быть на всех экранах расчета заказа; Программа должна получать данные о клиентах из системы CRM ; Программа должна отсылать Email с расчетом стоимости заказа; . . . . . . . . . . . . 1-

16. Требования к качеству (примеры) Время реакции на все запросы не более 3 сек. Для установки ПО не требуется особая квалификация (ПО должно инсталлироваться пользователем без участия системного администратора). Время восстановления системы при сбое не превышает 5 мин. . . . . . . . . . . . . 1-

17. Ограничения (примеры) Платежные поручения должны печататься в соответствии с требованиями ЦБ. В качестве сервера БД используется Oracle 9 . Документацию оформлять по ГОСТ19.106-78. . . . . . . . . . . . . 1-

18. Потребности пользователей (примеры) ПО должно обеспечивать ведение списка клиентов. При расчете стоимости заказа программа должна учитывать скидки категорий клиента. Расчет стоимости заказа выполнять по формуле ... . . . . . . . . . . . . 1-

19. Бизнес цели (пример) Увеличить число принятых заказов на 30%. Снизить простои оборудования на 10%. Повысить соотношение запросов к заказам до 0.3. . . . . . . . . . . . . 1-

20. Категории потребностей Бизнес цели Зачем создается ПО? Потребности пользователей Какие свои задачи смогут решать пользователи с помощью ПО? Ограничения З аконы, положения, стандарты, … которым должно удовлетворять ПО. Требования к качеству: Производительность, мобильность, совместимость, простота … Требования к интерфейсу Т ребования к экранным формам, форматам и протоколам обмена данными. Функциональные требования Какие функции должно выполнять ПО? 1-

21. Граница продукта Создаваемое программное обеспечение Пользователи Компьютерное оборудование Внешняя база данных Производственное оборудование Другое ПО Граница продукта 1-

22. Граница проекта Команда разработчиков Требования и проектные документы Аналитики Пользователи Менеджеры Заказчики 1-

23. Граница продукта ( product vision ) Определяет требования к ПО, обеспечивающие достижение бизнес целей и задающие направление разработке. Граница проекта ( project scope) Определяет объем требований к ПО и условия их реализации, в рамках конкретного проекта по разработке очередной версии. Граница продукта vs. Граница проекта Граница продукта Версия 1.0 Версия 1.1 Версия 1.2 . . . 1-

24. Роль требований в разработке основа соглашения между заказчиком и разработчиком основа планирования проекта (сроки, стоимость, ресурсы) и контроля его продвижения основной источник информации для разработчиков в процессе конструирования основа для оценки результатов разработки основа одинакового понимания задачи и разделения труда между различными категориями разработчиков 1-

25. Виды ПО с точки зрения требований Требования детерминированы (интерфейс между готовым ПО, существующими устройствами … ) Требования формальны (управление техническими системами, математические модели …) Требования придумываются (игры, инновации) Основные требования известны (операционные системы, редакторы текстов…) Требования выявляются ( ERP, офисные системы, …) 1-

26. Вопросы? ? ! ? ! 1-

27. Проблема определения требований Влияние требований на проект. Важность требований в разработке. 1-

28. В чем проблема? не делают того, что нужно пользователю не удобны в использовании трудно осваиваются постоянно изменяются иногда просто выбрасываются Программисты способны решать практически любые поставленные задачи обработки информации на компьютере. Почему получаются программы, которые: 1-

29. Причины провалов 1-

30. Факторы успеха 1-

31. Нет проблем ! ? Когда можно построить дом? 1-

32. Понимание 1-

33. Есть проблемы! Основные проблемы, связанные с определением требований это: их отсутствие в начале разработки их изменение в ходе разработки 1-

34. Важность требований «Самая сложная часть разработки ПО – точно решить, что же строить. Это самая трудная концептуальная работа, способная сильно испортить результат, если она выполнена плохо, и которую наиболее трудно исправлять» Фредерик Брукс « No silver Bullet: Essence and Accidents of Software Engineering », 198 7 1-

35. Цена ошибок в требованиях Относительная стоимость исправления ошибок в требованиях 20 40 60 80 100 Требования Использование Проект Кодирование Тестирование Фазы разработки [ Карл Видгерс ] 1-

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

37. Вопросы? ? ! ? ! 1-

38. Спецификация требований Роль спецификации в проекте. Содержание спецификации. Структура спецификации 1-

39. Фиксация требований Если этого нет на бумаге, значит этого не существует Любимая аксиома Алана Купера (из книги «Психбольница в руках пациентов») 1-

40. Роль спецификации требований Спецификация требований. ( СТПО ) Бизнес Пользователи Система Ограничения Управление проектом Проектирование Программирование Тестирование .............. Подрядчик Заказчик Разработка требований Использование требований 1-

41. Риски отсутствия спецификации Риск разного понимания требований разными участниками разработки; Опасность сделать ПО, не отвечающее потребностям заказчика или покупателя; Риск неоплаты усилий разработчиков; Неправильная оценка трудоемкости и сроков; Незащищенность проекта от смены разработчиков. 1-

42. Содержание спецификации Функциональность - Какие функции должно выполнять ПО? Интерфейсы - Как ПО взаимодействует с другими элементами системы? Свойства - Какие требования к производительности, мобильности, ... ? Ограничения - Какие нужно использовать стандарты, языки, ресурсы ...? [ IEEE Std 830-1998 ] 1-

43. Функциональные требования В СТПО каждое описание функции детально описывает: входные и выходные данные (название, тип, формат, диапазон) преобразование входных данных в выходные (неформальное описание, формулы, логические выражения, алгоритмы, таблицы решений) необходимые проверки входных данных реакции на ненормальные ситуации 1-

44. Интерфейсы Как ПО взаимодействует с окружением: Интерфейсы пользователя Интерфейсы с оборудованием Интерфейсы с другим ПО Коммуникационные интерфейсы 1-

45. Описание интерфейсов Описании интерфейсов может включать следующую информацию: Имя интерфейса и его назначение Форматы данных и команд, экранов Диапазон значений, точность, единицы измерения Протоколы обмена Временные характеристики 1-

46. Свойства Это общие требования к ПО, влияющие на проектные решения, относящиеся к его: надежности доступности безопасности производительности мобильности сопровождаемости 1-

47. Ограничения Ограничения – это условия, которые ограничивают выбор решений при разработке: Законодательные акты Отраслевые и другие стандарты Используемое оборудование и ПО Языки программирования и инструменты 1-

48. Не является предметом СТПО (1) Проектная информация о внутренней структуре ПО: разбиение ПО на модули распределение функций по модулям описание потоков информации между модулями структура проектируемой БД детали дизайна экранного интерфейса детали реализации средства разработки 1-

49. Не является предметом СТПО (2) Информация об организации проекта: с тоимост ь проекта г рафик поставки продукта м етод ы разработки ПО п оряд о к отчетности и г аранти и качества порядок приемки 1-

50. Структура документа ( IEEE Std 830) Спецификация требований к ПО Оглавление 1. Введение * Цель * Сфера * Определения * Обозначения * Сокращения * Ссылки * Обзор 2. Общее описание * Место продукта * Функции продукта * Пользователи * Ограничения * Предположения и зависимости 3. Детальные требования Приложения Индекс 1-

51. Принципы структурирования Группировать описание функций в разделы можно по: р ежим ам использования к атегориям пользователей классам о бъект ов в озможност ям для пользователей воздействиям результатам и ерархии функций 1-

52. Структуризация по пользователям 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-

53. Структуризация по функциям 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-

54. Техническое задание ( ГОСТ 19.201-78. ЕСПД ) Введение Основания для разработки Назначение Требования к программе или программному изделию: - требования к функциональным характеристикам - требования к надежности и устойчивому функционированию. - условия эксплуатации. - требования к составу и параметрам технических средств - требования к информационной и программной совместимости - требования к маркировке и упаковке требования к транспортированию и хранению. Требования к программной документации Технико-экономические показатели Стадии и этапы разработки Порядок контроля и приемки 1-

55. ГОСТ 19.201 vs. IEEE Std. 830 В техническом задании, в отличии от спецификации требований: программа – это материальный объект упор на структуру документа дается один вариант структуры документа нет критериев качества требований предлагается включать требования к проекту 1-

56. Вопросы? ? ! ? ! 1-

57. Представление информации Характеристика пользователей. Контекстная диаграмма. Словарь данных Требования в ХР программировании 1-

58. Характеристика пользователей Описание каждой категории пользователей включает: Название категории Цели и задачи пользователей Опыт и имеющиеся навыки Потребности а обработке информации Права доступа к информации Рейтинг важности категории 1-

59. Контекстная диаграмма (пример) Система «Полиграф» Менеджер Бухгалтер Технолог Система «1С» Интернет Ксерокс Клиенты и заказы Расчеты и отчеты Материалы и работы Заказы Показатели эксплуатации Данные об оплате Финансовые отчеты Платежи Расчеты для клиентов 1-

60. Словарь данных (пример) – физическое или юридическое лицо делающее Запрос на производство печатной продукции. Может заключать Договор на длительный срок. Может быть неизвестное лицо, для которого нужно рассчитать Заказ . Пример Карточки клиента см. в Приложении 1. Клиент + Название - имя или название клиента [ Текст(30) ] + Дата - дата регистрации клиента [ Дата (дд.мм.гг) ] + Категория - категория клиента [ обычн. |VIP| новый | ...] + Адрес - адрес клиента [ Адрес ] + (Email) - адрес электронной почты [ Текст(30) ] + Контакт (1: N ) - список Контактных лиц [ Контактное лицо ] + Договор (1: N) - список Договоров [ Договор ] – почтовый адрес контрагента ( Клиент , Подрядчик ). Адрес + Индекс - почтовый индекс [ Целое(6) ] + Улица - название улицы (справ. БТИ) [ Текст(20) ] + Дом - номер дома, корпуса, строения [ Текст(10) ] 1-

61. Формат словаря данных – физическое или юридическое лицо делающее Запрос на производство печатной продукции. Клиент + Название - имя или название клиента [ Текст(30) ] + Дата - дата регистрации клиента [ Дата (дд.мм.гг) ] + Категория - категория клиента [ обычн. | VIP |...] + Адрес - адрес клиента [ Адрес ] + (Email) - адрес электронной почты [ Текст(30) ] + Контакт (1: N ) - список контактных лиц [ Контактное лицо ] + Договор (1: N) - список договоров [ Договор ] Обозначение сущности Описание сущности Ссылка на сущность Обозначение атрибута Названиеатрибута Необязательный атрибут Повторяемость значения атрибута Простой тип данных, его формат или список допустимых значений Ссылки на сущности 1-

62. Требования в ХР-программировании Требования определяются при «Концептуализации системы» на протяжении всего жизненного цикла Используется прием «Метафор» - аналогий того, на что похоже или не похоже будет ПО Выбор требований осуществляет заказчике, входящий в состав команды разработчиков 1-

63. История пользователя 214 Отображение 2 отсканированной единицы товара После сканирования упаковки вверху терминала появляется краткое описание товара и его цена. Номер истории Трудоемкость в пунктах. 1пункт=1чел/неделя На обратной стороне – описание приемочного теста 1-

64. Иерархия требований в ХР Представление Цели и назначение создаваемого ПО История История История Задача Представление о системе Набор проекта Стек Цели Стек Стек Задачи и тесты для реализации историй 1-

65. Вопросы? ? ! ? ! 1-

66. 1 День. Обзор Определение. Место в разработке. Границы продукта vs проекта. Проблемы определения требования. Спецификация требований. Структура документа ( IEEE Std 830) . Требования в XP- программировании. 1-