
- •2. Процесс работы с требованиями. Модель процесса определения требований. Участники процессов. Управление и поддержка процессов. Качество и улучшение процессов.
- •2.1 Модель процесса определения требований:
- •2.2 Участники процессов (Process Actors)
- •2.3 Управление и поддержка процессов (Process Support and Management)
- •2.4 Качество и улучшение процессов (Process Quality and Improvement)
- •3. Извлечение требований. Источники требований. Техники извлечения требований
- •3.1 Источники требований (Requirement Sources)
- •3.2 Техники извлечения требований (Elicitation Techniques)
- •4. Анализ требований. Классификация требований. Концептуальное моделирование. Архитектурное проектирование и распределение требований.
- •4.1 Классификация требований (Requirements Classification)
- •4.2 Концептуальное моделирование (Conceptual Modeling)
- •4.3 Архитектурное проектирование и распределение требований (Architectural Design and Requirements Allocation)
- •5. Спецификация требований. Определение системы. Спецификация системных требований. Спецификация программных требований.
- •5.1 Определение системы (System Definition Document)
- •5.2 Спецификация системных требований (System Requirements Specification)
- •5.3 Спецификация программных требований (Software Requirements Specification - srs)
- •6. Проверка требований. Обзор требований. Прототипирование. Утверждение модели. Приемочные тесты.
- •6.1 Обзор требований (Requirements Review)
- •6.2 Прототипирование (Prototyping)
- •6.3 Утверждение модели (Model Validation)
- •6.4 Приемочные тесты (Acceptance Tests)
- •7. Практические соображения. Итеративная природа процесса работы с требованиями. Управление изменениями. Атрибуты требований. Трассировка требований. Измерение требований.
- •7.1 Итеративная природа процесса работы с требованиями (Iterative Nature of the Requirements Process)
- •7.2 Управление изменениями (Change Management)
- •7.3 Атрибуты требований (Requirements Attributes)
- •7.4 Трассировка требований (Requirements Tracing)
- •7.5 Измерение требований (Measuring Requirements)
- •8. Основы проектирования. Общие концепции проектирования. Контекст проектирования. Процесс проектирования. Техники применения.
- •1.1 Общие концепции проектирования (General Design Concepts)
- •1.2 Контекст проектирования (Context of Software Design)
- •1.3 Процесс проектирования (Software Design Process)
- •1.4 Техники применения (Enabling Techniques)
- •2.1 Параллелизм (Concurrency)
- •2.2 Контроль и обработка событий (Control and Handling of Events)
- •2.3 Распределение компонентов (Distribution of Components)
- •2.4 Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости (Errors and Exception Handling and Fault Tolerance)
- •2.5 Взаимодействие и представление (Interaction and Presentation)
- •2.6 Сохраняемость данных (Data Persistence)
- •10. Структура и архитектура программного обеспечения. Архитектурные структуры и точки зрения. Архитектурные стили. Шаблоны проектирования. Семейства программ и фреймворков.
- •3.1 Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints)
- •3.2 Архитектурные стили (Architectural Styles)
- •3.3 Шаблоны проектирования (Design Patterns)
- •3.4 Семейства программ и фреймворков (Families of Programs and Frameworks)
- •11. Анализ качества и оценка программного дизайна. Атрибуты качества. Анализ качества и техники оценки. Измерения
- •4.1 Атрибуты качества (Quality Attributes)
- •4.2 Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques)
- •4.3 Измерения (Measures)
- •12. Нотации проектирования. Структурные описания, статический взгляд. Поведенческие описания, динамический взгляд.
- •5.1 Структурные описания, статический взгляд (Structural Descriptions, static view)
- •5.2 Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view)
- •6.1 Общие стратегии (General Strategies)
- •6.2 Функционально-ориентированное или структурное проектирование (Function-Oriented – Structured Design)
- •6.3 Объектно-ориентированное проектирование (Object-Oriented Design)
- •6.4 Проектирование на основе структур данных (Data-Structure-Centered Design)
- •6.5 Компонентное проектирование (Component-Based Design)
- •6.6 Другие методы (Other Methods)
- •14. Основы конструирования. Минимизация сложности. Ожидание изменений. Конструирование с возможностью проверки. Стандарты в конструировании.
- •1.1 Минимизация сложности (Minimizing Complexity)
- •1.2 Ожидание изменений (Anticipating Changes)
- •1.3 Конструирование с возможностью проверки (Constructing for Verification)
- •1.4 Стандарты в конструировании (Standards in Constructing)
- •15. Управление конструированием. Модели конструирования. Планирование конструирования. Измерения в конструировании.
- •2.1 Модели конструирования (Construction Models)
- •2.2 Планирование конструирования (Construction Planning)
- •2.3 Измерения в конструировании (Construction Measurement)
- •16. Практические соображения. Проектирование в конструировании. Языки конструирования. Кодирование. Тестирование в конструировании. Повторное использование. Качество конструирования. Интеграция.
- •3.1 Проектирование в конструировании (Construction Design)
- •3.2 Языки конструирования (Construction Languages)
- •3.3 Кодирование (Coding)
- •3.4 Тестирование в конструировании (Construction Testing)
- •3.5 Повторное использование (Reuse)
- •3.6 Качество конструирования (Construction Quality)
- •3.7 Интеграция (Integration)
- •17. Основы тестирования. Терминология тестирования. Ключевые вопросы. Связь тестирования с другой деятельностью.
- •1.1 Терминология тестирования (Testing-Related Terminology)
- •1.2 Ключевые вопросы (Key Issues)
- •1.3 Связь тестирования с другой деятельностью (Relationships of testing with other activities)
- •18. Уровни тестирования. Над чем производятся тесты. Цели тестирования.
- •2.1 Над чем производятся тесты (The target of the test)
- •2.2 Цели тестирования (Objectivies of Testing)
- •3.1 Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuition and experience)
- •3.2 Техники, базирующиеся на спецификации (Specification-based techniques)
- •3.3 Техники, ориентированные на код (Code-based techniques)
- •3.4 Тестирование, ориентированное на дефекты (Fault-based techniques)
- •3.5 Техники, базирующиеся на условиях использования (Usage-based techniques)
- •3.6 Техники, базирующиеся на природе приложения (Techniques based on the nature of the application)
- •3.7 Выбор и комбинация различных техник (Selecting and combining techniques)
- •20. Измерение результатов тестирования. Оценка программ в процессе тестирования. Оценка выполненных тестов.
- •4.1 Оценка программ в процессе тестирования (Evaluation of the program under test, ieee 982.1-98)
- •4.2 Оценка выполненных тестов (Evaluation of the tests performed)
- •21. Процесс тестирования. Практические соображения. Тестовые работы.
- •5.1 Практические соображения (Practical considerations)
- •5.2 Тестовые работы (Test Activities)
- •1.1 Определения и терминология (Definitions and Terminology)
- •1.2 Природа сопровождения (Nature of Maintenance)
- •1.3 Потребность в сопровождении (Need for Maintenance)
- •1.4 Приоритет стоимости сопровождения (Majority of Maintenance Costs)
- •1.5 Эволюция программного обеспечения (Evolution of Software)
- •1.6 Категории сопровождения (Categories of Maintenance)
- •23. Ключевые вопросы сопровождения программного обеспечения. Технические вопросы. Управленческие вопросы. Оценка стоимости сопровождения. Измерения в сопровождении программного обеспечения.
- •2.1 Технические вопросы (Technical Issues)
- •2.2 Управленческие вопросы (Management Issues)
- •2.3 Оценка стоимости сопровождения (Maintenance Cost Estimation)
- •2.4 Измерения в сопровождении программного обеспечения (Software Maintenance Measurement)
- •24. Процесс сопровождения. Процессы сопровождения. Работы по сопровождению.
- •3.1 Процессы сопровождения (Maintenance Processes)
- •3.2 Работы по сопровождению (Maintenance Activities)
- •25. Техники сопровождения. Понимание программных систем. Реинжиниринг. Обратный инжиниринг.
- •4.1 Понимание программных систем (Program Comprehension)
- •4.2 Реинжиниринг* (Reengineering)
- •4.3 Обратный инжиниринг* (Reverse engineering)
- •26. Управление scm-процессом. Организационный контекст scm. Ограничения и правила scm. Планирование в scm. План конфигурационного управления. Контроль выполнения scm-процесса.
- •1.1 Организационный контекст scm (Organizational Context for scm)
- •1.2 Ограничения и правила scm (Constraints and Guidance for the scm Process)
- •1.3 Планирование в scm (Planning for scm)
- •1.4 План конфигурационного управления (scm Plan)
- •1.5 Контроль выполнения scm-процесса (Surveillance of Software Configuration Management)
- •27. Идентификация программных конфигураций. Идентификация элементов, требующих контроля. Программная библиотека.
- •2.1 Идентификация элементов, требующих контроля (Identifying Items to Be Controlled)
- •2.2 Программная библиотека (Software Library)
- •28. Контроль программных конфигураций. Предложение, оценка и утверждение изменений. Реализация изменений. Отклонения и отказ от изменений.
- •3.1 Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving Software Changes)
- •3.2 Реализация изменений (Implementing Software Changes)
- •3.3 Отклонения и отказ от изменений (Deviations and Waivers)
- •29. Учет статусов конфигураций. Информация о статусе конфигураций. Отчетность по статусу конфигураций.
- •4.1 Информация о статусе конфигураций (Software Configuration Status Information)
- •4.2 Отчетность по статусу конфигураций (Software Configuration Status Reporting)
- •30. Аудит конфигураций. Функциональный аудит программных конфигураций. Физический аудит программных конфигураций. Внутренние аудиты базовых линий.
- •5.1 Функциональный аудит программных конфигураций (Software Functional Configuration Audit)
- •5.2 Физический аудит программных конфигураций (Software Physical Configuration Audit)
- •5.3 Внутренние аудиты базовых линий (In-process Audits of Software Baseline)
- •31. Управление выпуском и поставкой. Сборка программного обеспечения. Управление выпуском программного обеспечения.
- •6.1 Сборка программного обеспечения (Software Building)
- •6.2 Управление выпуском программного обеспечения (Software Release Management)
- •1.1 Определение и обсуждение требований (Determination and Negotiation of Requirements)
- •1.2 Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. (Feasibility Analysis. Technical, Operational, Financial, Social/Political.)
- •1.3 Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements)
- •2.1 Планирование процесса (Process Planning)
- •2.2 Определение результатов (Determine Deliverables)
- •2.3 Оценка усилий, расписания и стоимостных ожиданий (Efforts,Schedule and Cost Estimation)
- •2.4 Распределение ресурсов (Resource Allocation)
- •2.5 Управление рисками (Risk Management)
- •2.6 Управление качеством (Quality Management)
- •2.7 Управление планом проекта (Plan Management)
- •34. Выполнение программного проекта. Реализация планов. Управление контрактами с поставщиками. Реализация процесса по ведению измерений. Процесс мониторинга. Процесс контроля. Ведение отчетности.
- •3.2 Управление контрактами с поставщиками (Supplier Contract Management)
- •3.3 Реализация процесса по ведению измерений (Implementation of Measurement Process)
- •3.4 Процесс мониторинга (Monitor Process)
- •3.5 Процесс контроля (Control Process)
- •3.6 Ведение отчетности (Reporting)
- •35. Обзор и оценка. Определение удовлетворения требованиям. Оценка продуктивности и результативности.
- •4.1 Определение удовлетворения требованиям (Determining Satisfaction of Requirements)
- •4.2 Оценка продуктивности/результативности (Reviewing and Evaluation Performance)
- •36. Закрытие. Определение критериев закрытия проекта. Работы по закрытию проекта.
- •5.2 Работы по закрытию проекта (Closure Activities)
- •37. Измерения в программной инженерии. Установление и поддержка процесса ведения измерений. Планирование процесса измерений. Выполнение процесса измерений. Оценка измерений.
- •6.1 Установление и поддержка процесса ведения измерений (Establish and Sustain Measurement Commitment)
- •6.2 Планирование процесса измерений (Plan the Measurement Process)
- •6.3 Выполнение процесса измерений (Perform the Measurement Process)
- •6.4 Оценка измерений (Evaluate Measurement)
- •38. Реализация и изменение процесса. Инфраструктура процесса. Цикл управления программным процессом. Модели реализации и изменения процесса. Практические соображения.
- •1.1 Инфраструктура процесса (Process Infrastructure)
- •1.2 Цикл управления программным процессом (Software Process Management Cycle)
- •1.3 Модели реализации и изменения процесса (Models for Process Implementation and Change)
- •1.4 Практические соображения (Practical Considerations)
- •39. Определение процесса. Модели жизненного цикла программного обеспечения. Процессы жизненного цикла программного обеспечения. Нотации определения процесса. Адаптация процесса. Автоматизация.
- •2.1 Модели жизненного цикла программного обеспечения (Software Life Cycle Models)
- •2.2 Процессы жизненного цикла программного обеспечения (Software Life Cycle Processes)
- •2.3 Нотации определения процесса (Notations for Process Definitions)
- •2.4 Адаптация процесса (Process Adaptation)
- •2.5 Автоматизация (Automation)
- •40. Оценка процесса. Модели оценки процесса. Методы оценки процесса.
- •3.1 Модели оценки процесса (Process Assessment Models)
- •3.2 Методы оценки процесса (Process Assessment Methods)
- •4.1 Измерения в отношении процессов (Process Measurement)
- •4.2* Измерения в отношении программных продуктов (Software Product Measurement)
- •4.3 Качество результатов измерений (Quality Of Measurement Results)
- •4.4 Информационные модели (Software Information Models)
- •4.5 Техники количественной оценки процессов (Process Measurement Techniques)
- •1.1 Инструменты работы с требованиями (Software Requirements Tools)
- •1.2 Инструменты проектирования (Software Design Tools)
- •1.3 Инструменты конструирования (Software Construction Tools)
- •1.4 Инструменты тестирования (Software Testing Tools)
- •1.5 Инструменты сопровождения (Software Maintenance Tools)
- •1.6 Инструменты конфигурационного управления (Software Configuration Management Tools)
- •1.7 Инструменты управления инженерной деятельностью (Software Engineering Management Tools)
- •1.8 Инструменты поддержки процессов (Software Engineering Process Tools)
- •1.9 Инструменты обеспечения качества (Software Quality Tools)
- •1.10 Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues)
- •43. Методы программной инженерии. Эвристические методы. Формальные методы. Методы прототипирования.
- •2.1 Эвристические методы (Heuristic Methods)
- •2.2 Формальные методы (Formal Methods)
- •2.3 Методы прототипирования (Prototyping Methods)
- •44. Основы качества программного обеспечения. Культура и этика программной инженерии. Значение и стоимость качества. Модели и характеристики качества. Повышение качества.
- •1.1 Культура и этика программной инженерии (Software Engineering Culture and Ethics)
- •1.2 Значение и стоимость качества (Value and Costs of Quality)
- •1.3 Модели и характеристики качества (Models and Quality Characteristics)
- •1.4 Повышение качества (Quality Improvement)
- •45. Процессы управления качеством программного обеспечения. Подтверждение качества программного обеспечения. Проверка (верификация) и аттестация. Оценка (обзор) и аудит.
- •2.1 Подтверждение качества программного обеспечения (Software Quality Assurance, sqa)
- •2.2 Проверка (верификация) и аттестация (Verification and Validation, V&V)
- •2.3 Оценка (обзор) и аудит (Review and Audits)
- •3.1 Требования к качеству программного обеспечения (Software Quality Requirements)
- •3.2 Характеристика дефектов (Defect Characterization)
- •3.3 Техники управления качеством программного обеспечения (Software Quality Management Techniques)
- •3.4 Количественная оценка качества программного обеспечения (Software Quality Measurement)
- •Организация стандарта и архитектура жизненного цикла
- •Основные процессы жизненного цикла (5) Приобретение (5.1)
- •Поставка (5.2)
- •Разработка (5.3)
- •Эксплуатация (5.4)
- •Сопровождение (5.5)
- •Адаптация стандарта
- •48. Модели жизненного цикла. Каскадная (водопадная) модель. Итеративная и инкрементальная модель - эволюционный подход. Спиральная модель.
- •Каскадная (водопадная) модель
- •Итеративная и инкрементальная модель – эволюционный подход
- •Спиральная модель
- •49. Привести пример реализации ответа на каждый вопрос из перечня вопросов к экзамену по дисциплине “Программная инженерия” на конкретном программном продукте экономической направленности.
4.3 Архитектурное проектирование и распределение требований (Architectural Design and Requirements Allocation)
Считается, что создание архитектуры программных решений является обязательным элементов успешности таких проектов. Архитектурное проектирование перекрывается с программным и системным дизайном (проектированием) и иллюстрирует насколько сложно провести четкую грань между различными аспектами проектирования. Данная тема работы с программными требованиями тесно связана с секцией “Структура и архитектура программного обеспечения” (Software Structure and Architecture) области знаний “Проектирование программного обеспечения” (Software Design). Во многих случаях, инженеры действуют как архитекторы, потому как процессы анализа и выработки требований зависят от программных компонент, создаваемых для решения поставленных заданными требованиями задач, призванных, в конечном счете, добиться реализации поставленных перед проектом целей.
Архитектурное проектирование очень близко к концептуальному моделированию. Непосредственное отображение бизнес-сущностей реального мира на программные компоненты не является обязательным. Во многом поэтому и существует такое разделение между моделированием и проектированием. В принципе, можно говорить о том, что деятельность по моделированию в большей степени касается того, ”что” надо сделать, а архитектура - “как” это будет реализовано.
Существует ряд стандартов и общепринятых практик, связанных с архитектурным проектированием. Среди них наиболее популярны:
Стандарт IEEE 1471-2000 “Recommended Practice for Architectural Description of Software Intensive Systems”
Модель Захмана – Zachman Framework (www.zifa.com)
TOGAF – The Open Group Architecture Framework (www.opengroup.org/architecture/)
Важно заметить, что ни в коем случае не надо путать архитектурные рекомендации (Architectural Guidelines) с практиками и стандартами архитектурного проектирования. Одни (например, Federal Enterprise Architecture Framework FEAF) дают рекомендации по конкретным архитектурно-технологическим решениям. Другие концентрируются именно на том, чему стоит уделить внимание при создании архитектуры, как ее описать и детализировать, и что из себя представляет архитектура, как таковая (например, ISO 15704 Industrial Automation Systems – Requirements for Enterprise-Reference Architectures and Methodologies).
5. Спецификация требований. Определение системы. Спецификация системных требований. Спецификация программных требований.
На инженерном жаргоне, да и в терминологии ряда методологий, устоялся термин “software requirements specification” (SRS) – спецификация программных требований. Для сложных систем, на самом деле, существует целый комплекс спецификаций, документов, которые являются результатом сбора и анализа требований, их моделирования и архитектурного проектирования. Эти документы систематически анализируются, в них вносятся изменения, они пересматриваются и утверждаются. Чаще всего, для описания комплексных проектов (в части требований) используется три основных документа (спецификации):
Определение системы (system definition)
Системные требования (system requirements)
Программные требования (software requirements)
5.1 Определение системы (System Definition Document)
Данный документ, часто называемый как “спецификация пользовательских требований” (user requirements specification) или “концепция” (concept <of operations>), описывает системные требования. Содержание документа определяет высокоуровневые требования, часто – стратегические цели, для достижения которых создается программная система. Принципиальным моментом является то, что такой документ описывает требования к системе с точки зрения области применения - “домена”. Соответственно, изложение требований в нем ведется в терминах прикладной области. Документ описывает системные требования вместе с необходимой информацией о бизнес-процессах, операционном окружении с точки зрения бизнес-процедур и организационных и других регламентов. Примером стандарта для создания и структурирования такого документа является IEEE 1362 “Concept of Operations Document”.