Письменные лекции по дисциплине «Разработка и анализ требований»

Письменные лекции по дисциплине «Разработка и анализ требований»

Лекция 1. Основы работы с требованиями к ПО 1.1. Что такое требования 1.2. Классификация программного обеспечения

1.3. Разработка требований в модели жизненного цикла ПО 1.4. Участники разработки требований

1.4.1. Аналитик требований

1.5. Типы требований

1.6. Этапы сбора и анализа требований с точки зрения RUP 1.7. Процесс разработки требований 1.7. Разработка концепции продукта

1.8. Сбор бизнес-требований для продукта 1.9. Исходные стимулы 1.10. Цели продукта и критерии успеха

1.11. Определение целевого сегмента рынка

1.12. Определение потребностей клиентов

1.13. Обзор конкурентов 1.13.1. Пример списка возможностей конкурентов

1.14. Документ о концепции и границах проекта 1.14.1. Положение о концепции

1.15. Бизнес-риски

1.16. Ограничения проекта и их выявление

1.17. Профили заинтересованных лиц 1.18. Пример бизнес-требований разных групп пользователей 1.19. Приоритеты проекта

Лекция 2. Методы выявления требований к ПО 2.1. Сбор требований пользователей 2.2. Определение классов пользователей

2.3. Характеристики классов пользователей 2.4. Представление системных событий и реакции на них

2.5. CRC-карточки

2.5.1. Пример CRC-карточки 2.6. Прототипы (макеты) ПО

2.7. Представление требований пользователя на основе варианта использования

2.8. Процессы обработки данных варианта использования

2.9. Нефункциональные требования

2.10. Уточнение нефункциональных требований

2.11. Стандарты практичности (usability)

2.12. Бизнес-правила 2.12.1. Примеры бизнес-правил

Лекция 3. Анализ и моделирование требований к ПО 3.1. Атрибуты качества требований 3.2. Статус требования 3.3. Полный набор требований ПО

3.4. Представление вводов и выводов ПО

3.5. Полнота нефункциональных требований

3.6. Пример трассировки требований.

3.6.1. Дочерние требования

3.7. Дерево требований 3.8. Обоснованность требований: матрица зависимости требований

3.9. Корректность и непротиворечивость

3.10. Проверяемость требований 3.10.1. Оценки разработчиков возможности проверки требований

3.11. Определение приоритетов 3.12. Определение приоритета по полезности (ценности) функции

Лекция 4. Средства анализа требований к ПО. Основы UML 4.1. Стандарты языка UML

4.2. Назначение и элементы UML

4.3. Диаграммы UML (UML 2.5)

4.4. Структурные диаграммы (Structure Diagrams)

4.5. Диаграммы поведения (Behavior Diagrams)

4.6. Диаграммы взаимодействия (Interaction Diagrams)

4.7. Структурные предметы UML

4.8. Предметы поведения UML

4.9. Отношения UML

4.10. Диаграмма Use Case

4.11. Диаграмма Use Case (2)

4.12. Диаграмма (видов) деятельности

4.13. Элементы диаграммы деятельности

4.14. Управляющие узлы

4.15. Объектные узлы

4.16. Исполняемые узлы

4.17. Дуги диаграммы деятельности

4.18. Роли на диаграмме деятельности

4.19. Пример диаграммы деятельности

4.20. Диаграмма состояний

4.21. Диаграмма классов

4.22. Диаграмма объектов: обозначения

4.23. Диаграмма объектов: пример

4.24. Диаграмма компонентов

4.25. Диаграмма компонентов UML 1.4 4.26. Диаграмма компонентов (UML 2.0) 4.27. Интерфейс на диаграмме компонентов

4.28. Интерфейс на диаграмме компонентов (2)

4.29. Диаграмма развертывания

4.30. Диаграмма последовательности

4.31. Диаграмма взаимодействия (кооперации, collaboration) 4.32. Диаграмма последовательности (2)

4.33. Диаграмма обзора взаимодействия

4.34. Диаграмма синхронизации

4.35. Диаграмма пакетов

Лекция 5. Анализ требований на основе моделирования бизнес-процессов 5.1. Моделирование бизнес-процессов 5.2. Процесс разработки требований

5.3. Процессы обработки данных варианта использования

5.4. Категории бизнес-процессов

5.5. Методики моделирования бизнес-процессов 5.6. Программное обеспечение для моделирования бизнес-процессов

5.7. Построение модели бизнес-процесса на основе вариантов использования

5.8. Пример построения спецификации требований

5.9. Заинтересованные лица

5.10. Эксперты

5.11. Словарь (глоссарий)

5.12. Бизнес-процессы

5.13. Бизнес-правила

5.14. Диаграмма прецедентов

5.14.1. Прецедент «Обновление данных перед началом приемной кампании»

5.15. Диаграмма развертывания системы «Абитуриент» 5.16. Список классов 5.17. Диаграмма классов

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

5.19. Класс Личное дело

Лекция 6. Методы структурного анализа требований к ПО 6.1. Средства структурного анализа

6.2. Методология SADT

6.2.1. Элемент SADT

6.2.2. Пример элемента SADT

6.2.3. Уровни диаграммы SADT 6.2.4. Связь блоков в SADT

6.3. Семейство диаграмм IDEF

6.3.1. Стандартизация методик моделирования в Российской Федерации

6.3.2. Диаграмма IDEF3

6.4. Диаграммы потоков данных DFD 6.4.1. DFD в нотации Йодана

6.4.2. Функциональная декомпозиция в DFD 6.4.3. DFD в нотации Гейна-Сарсона

6.4. Диаграмма «Сущность-связь» ERD 6.4.1. ERD в нотации Чена

6.4.2. ERD в нотации Баркера

6.4.3. Схемы по стандарту ГОСТ 19.701-90 6.4.4. Прочие стандарты

6.5. Диаграммы состояний и переходов STD

6.5.1. Обозначения STD

Лекция 7. Документирование требований к ПО 7.1. Управление требованиями 7.2. Процесс документирования требований

7.2.1. Верификация и валидация 7.2.2. Спецификация требований к ПО

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

7.4. Техническое задание (Информационные технологии ГОСТ

34.602-87)

7.5. Разработка требований к ПО встроенных систем 7.5.1. Системные требования для встроенного ПО 7.5.2. Классификация отказных ситуаций 7.5.3. Документирование требований к встроенному ПО 7.5.4. Спецификация системы/подсистемы

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

7.7. Спецификация требований к интерфейсам 7.8. Работа с требованиями в проектах гибкой разработки

Лекция 8. Управление требованиями к ПО 8.1. Управление требованиями

8.1.1. Причины изменений требований

8.1.2. Причины изменений требований 8.1.3. Хранение требований в системе управления требованиями 8.1.4. Статус требования 8.1.5. Прохождение запроса об изменении

8.1.6. Матрица отслеживания связей требований 8.1.7. Результаты анализа изменения требований 8.1.8. Атрибуты запроса на изменение

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

8.2.1. Сравнительная характеристика систем управления требованиями

8.2.2. Redmine

8.2.3. Сравнение систем управления требованиями

Лекция 1. Основы работы с требованиями к ПО

1.1.Что такое требования

Требования — requirements.

●Это свойства ПО, приносящие пользу клиенту.

●Это свойство ПО, позволяющее удовлетворить требования контракта, стандарта, спецификации или иной формальной документации.

●Это свойства ПО, определяющие его взаимодействие со своим окружением.

●Это характеристики ПО, отличающие его от аналогов.

1.2.Классификация программного обеспечения

По назначению:

—Системное ПО.

—Прикладное ПО.

—Инструментальное ПО.

—Встроенное ПО — содержимое энергонезависимой памяти

выделяет это как отдельный вид ПО, так как имеет свои специфические свойства).

Если брать с точки зрения рынка, то различаются подходы разработки ПО:

—Внешний клиент (продукт на заказ). Требования полностью определяет клиент, который заказывает.

—Компания-разработчик ПО (для открытого рынка). Разрабатывает компания для рынка, важен аналог конкурентов, так как если конкурент разработает лучше ПО, то компания понесет убытки.

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

1.3. Разработка требований в модели жизненного цикла ПО

Водопадная модель по Уинстону Ройсу Эта модель обязана своим появлением У. Ройсу (1970 г.). Модель

имеет и другое название – водопад (waterfall). Особенность модели – переход на следующую ступень осуществляется только после того, как

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

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

Преимущества каскадной модели:

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

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

Каскадный подход хорошо зарекомендовал себя при построении ПС,

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

Недостатки каскадной модели:

—выявление и устранение ошибок производится только на стадии тестирования, которое может существенно растянуться;

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

—цикл основан на точной формулировке исходных требований к ПС, реально в начале проекта требования заказчика определены лишь частично;

—результаты работ доступны заказчику только по завершении проекта.

Место требований в водопадной модели ЖЦ. Современная водопадная модель, в которой создание концепции вынесено на первое место. Сбор и анализ требований происходит только после того, как определены основные цели и задачи ПП.

Место требований в спиральной модели ЖЦ. Тут снова создание концепции на первом месте, а затем идут итерации, один этап заменяет другой. Основная идея спиральной модели заключается в том, что на этапах анализа и проектирования реализуемость технических решений и

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

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

1.4.Участники разработки требований

●Заказчики или инвесторы — те, кто платит деньги;

●Пользователи (подкласс заказчиков);

●Аналитики требований — самый главный человек, который балансирует требования разработчика и заказчика. Лучше брать со стороны заказчика, так как программисты могут не владеть предметной областью;

●Разработчики;

●Тестировщики;