- •Введение
- •Практическая работа №1. Тема: технология программирования. Основные понятия и подходы.
- •1.1. Назначение технологии программирования
- •1.2. История развития технологии программирования
- •1.2.1. Дореволюционный период
- •1.2.2. «Революция в программировании»
- •1.2.3. Послереволюционный период
- •1.3. Типы программных проектов
- •1.4. Составные части технологии программирования
- •1.5. Проект, продукт, процесс и персонал
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме.
- •Практическая работа №2. Тема: приемы обеспечения технологичности программных продуктов.
- •2.1. Циклический характер разработки
- •2.2. Основные понятия технологии программирования
- •2.2.1. Процессы и модели
- •2.2.2. Фазы и витки
- •2.2.3. Вехи и артефакты
- •2.2.4. Заинтересованные лица и работники
- •2.3. Выявление и анализ требований
- •2.3.1. Требования к программному обеспечению
- •2.3.2. Схема разработки требований
- •2.3.3. Управление требованиями
- •2.4. Архитектурное и детальное проектирование
- •2.4.1. Архитектурное проектирование
- •2.4.2. Детальное проектирование
- •2.5. Реализация и кодирование
- •2.6. Тестирование и верификация
- •2.6.1. Процесс контроля качества
- •2.6.2. Методы «белого ящика» и «черного ящика»
- •2.6.3. Инспектирование и обзоры
- •2.6.4. Цели тестирования
- •2.6.5. Верификация, валидация и системное тестирование
- •2.7. Сопровождение и продолжающаяся разработка
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме.
- •Практическая работа №3. Тема: определение требований к программному обеспечению и исходных данных для его проектирования. Модели процесса разработки.
- •3.1. Водопадные и конвейерные модели
- •3.2. Спиральные и инкрементные модели
- •3.4. Конструирование модели процесса
- •3.4.1. Выявление требований к процессу
- •3.4.2. Используемые фазы, вехи и артефакты
- •3.4.2.1. Фаза «Анализ»
- •3.4.2.2. Фаза «Проектирование»
- •3.4.2.3. Фаза «Реализация»
- •3.4.2.4. Фаза «Стабилизация»
- •3.4.2.5. Фаза «Внедрение»
- •3.4.3. Выбор архитектуры процесса.
- •3.4.3.1. Типы проектов
- •3.4.3.2. Модель процесса сверх легкого проекта
- •3.4.3.3. Модель процесса легкого проекта
- •3.4.3.4. Модель процесса тяжелого проекта
- •3.4.3.5. Модель процесса сверх тяжелого проекта
- •3.4.3.6. Занятость исполнителей
- •3.4.4. Порядок проведения типового проекта
- •3.4.4.1. Этап 1. Подготовка к проекту
- •3.4.4.2. Сбор и анализ предварительной информации
- •3.4.4.3. Формирование бригады проекта
- •3.4.4.4. Подготовка исходных документов
- •3.4.4.5. Этап 2. Работа над проектом
- •3.4.4.6. Процедура выполнения фазы проекта
- •3.4.4.7. Подготовка результирующих материалов вех
- •3.4.4.8. Этап 3. Завершение проекта
- •3.4.4.9. Архивирование результатов работы
- •3.4.4.10. Подведение итогов проекта
- •3.4.5. Документированные процедуры
- •3.4.5.3. Проверка качества материалов
- •3.4.6. Выводы
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме
- •Практическая работа №4. Тема: анализ требований и определение спецификаций программного обеспечения при структурном подходе.
- •4.1. Спецификации программного обеспечения при структурном подходе
- •4.2. Определение понятий и видов требований
- •Виды требований
- •4.1.2. Анализ и сбор требований
- •4.1.3. Инженерия требований по
- •4.2. Трассирование требований
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме
4.2. Определение понятий и видов требований
Одна из проблем индустрии программного обеспечения — это отсутствие общепринятых определений терминов, которыми пользуются для описания: требований пользователя, требований к ПО, функциональных требований, системных требований, технологических требований, требований к продукту и бизнес-требований. В разных источниках понятия требований определяются, исходя из разных условий и взглядов на то, что по ним создается. Назовем ряд определений в проблематике требований [2,3].
Требования — это «нечто такое, что приводит к выбору дизайна системы".
Требования – это свойства, которыми должен обладать продукт, чтобы представлять какую-то ценность для пользователей.
Требования – это спецификация того, что должно быть реализовано. В них охарактеризовано описание поведения системы, ее свойства и атрибуты. Они могут быть ограничены процессом разработки системы.
Согласно международного глоссария по терминологии требования включают описание:
1) условий или возможностей, необходимых пользователю для решения поставленных проблем или достижения целей;
2) условий или возможностей, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворить стандартам, спецификациям или другим формальным документам;
3) документированное представление условий или возможностей проектирования системы.
Виды требований
Требования к продукту охватывают требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры).Термин пользователи относится ко всем заинтересованным лицам в создании системы.
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Каждая система имеет свои нефункциональные требования.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик».
Системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы или вся система. Из требований для всей системы главными являются функциональные требования к ПО.
Функциональные требования включают описание требований в видам и типам реализуемых функций и документируются в спецификации требований к ПО (software requirements specification, SRS), где описано и ожидаемое поведение системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и его функциями. В дополнение к функциональным требованиям спецификация содержит нефункциональные требования (защита данных, адаптивность, изменчивость и др.), где описаны цели и атрибуты качества.
Атрибуты качества (quality attributes) представляют собой дополнительное описание функций программного продукта, выраженных через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков бизнес–системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей и отдел маркетинга. Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Они не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения на выполнение конкретных вариантов использования или на функции системы, подчиняющимся соответствующим правилам. Бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности.