
- •1 Основы программной инженерии 6
- •2 Процессы жизненного цикла программного средства 33
- •3 Инструменты и методы программной инженерии 184
- •4 Качество и эффективность в программной инженерии 193
- •Введение
- •1Основы программной инженерии
- •1.1Кризисы программирования и возникновение программной инженерии
- •1.2Программная инженерия и сущность инженерного подхода к созданию программного обеспечения
- •1.3Системная инженерия программного обеспечения
- •1.4Управление жизненным циклом программных средств
- •1.4.1Понятие жизненного цикла
- •1.4.2Масштабы программных средств
- •1.4.3Классификация процессов жизненного цикла по исо/мэк 12207
- •1.4.4Стадии разработки программных средств по еспд
- •1.4.5Типичная схема управления процессом создания программного обеспечения
- •1.5Модели жизненного цикла
- •1.5.1Каскадная (водопадная) модель
- •1.5.2Итеративная и инкрементальная модель – эволюционный подход
- •1.5.3Спиральная модель
- •2Процессы жизненного цикла программного средства
- •2.1Управление требованиями к программному обеспечению
- •2.1.1Программные требования
- •2.1.1.1Пирамида требований
- •2.1.1.2Характеристики программных требований
- •2.1.2Процесс управления требованиями
- •2.1.3Извлечение требований
- •2.1.4Анализ программных требований
- •2.1.5Документирование требований
- •2.1.6Проверка требований (верификация и аттестация)
- •2.1.7Измерение программных требований
- •2.2Проектирование программных средств
- •2.2.1Принципы проектирования
- •2.2.2Структура и архитектура программного обеспечения
- •2.2.2.1Архитектурные структуры и точки зрения
- •2.2.2.2Архитектурные стили
- •2.2.2.3Шаблоны проектирования
- •2.2.2.4Семейства программ и фреймворков
- •2.2.3Анализ качества и оценка программного дизайна
- •2.2.3.1Атрибуты качества
- •2.2.3.2Анализ качества и техники оценки
- •2.2.3.3Измерения
- •2.2.4Нотации проектирования
- •2.2.4.1Структурные описания
- •2.2.4.2Поведенческие (динамические) описания
- •2.2.5Подходы и методы проектирования программного обеспечения
- •2.2.5.1Общие подходы
- •2.3Использование uml в программной инженерии
- •2.3.1Основные компоненты uml
- •2.3.2Диаграмма вариантов использования
- •2.3.3Диаграмма классов
- •2.3.4Диаграмма состояний
- •2.3.5Диаграмма деятельности
- •2.3.6Диаграмма последовательности
- •2.3.7Диаграмма кооперации
- •2.3.8Диаграмма компонентов
- •2.3.9Диаграмма развертывания
- •2.4Тестирование программного обеспечения
- •2.4.1Основы тестирования
- •2.4.2Уровни тестирования
- •2.4.2.1Над чем производятся тесты
- •2.4.2.2Цели тестирования
- •2.4.3Техники тестирования
- •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)
- •4.1 Оценка программ в процессе тестирования (Evaluation of the program under test, ieee 982.1-98)
- •2.4.4.2Оценка выполненных тестов
- •2.4.5Процесс тестирования
- •2.4.5.1Практические соображения
- •2.4.5.2Тестовые работы
- •2.5Сопровождение программного обеспечения
- •2.5.1Основы сопровождения программного обеспечения
- •2.5.1.1Определения и терминология
- •2.5.1.2Природа сопровождения
- •2.5.1.3Потребность в сопровождении
- •2.5.1.4Приоритет стоимости сопровождения
- •2.5.1.5Эволюция программного обеспечения
- •2.5.1.6Категории сопровождения
- •2.5.2Ключевые вопросы сопровождения программного обеспечения
- •2.5.2.1Технические вопросы
- •2.5.2.2Оценка стоимости сопровождения
- •2.5.2.3Измерения в сопровождении программного обеспечения
- •2.5.3Процесс сопровождения
- •2.5.3.1Процессы сопровождения
- •2.5.3.2Работы по сопровождению
- •2.5.4Техники сопровождения
- •2.5.4.1Понимание программных систем
- •2.5.4.2Реинжиниринг
- •2.5.4.3Обратный инжиниринг
- •2.6Конфигурационное управление
- •2.6.1Управление конфигурационным процессом
- •2.6.1.1Организационный контекст управления конфигурацией по
- •2.6.1.2Ограничения и правила управления конфигурацией по
- •2.6.1.3Планирование при управлении конфигурацией по
- •2.6.1.4План конфигурационного управления
- •2.6.1.5Контроль выполнения процесса управления конфигурацией по
- •2.6.2Идентификация программных конфигураций
- •2.6.2.1Идентификация элементов, требующих контроля
- •2.6.2.2Программная библиотека
- •2.6.3Контроль программных конфигураций
- •2.6.3.1Предложение, оценка и утверждение изменений
- •2.6.3.2Реализация изменений
- •2.6.3.3Отклонения и отказ от изменений
- •2.6.4Учет статусов конфигураций
- •2.6.4.1Информация о статусе конфигураций
- •2.6.4.2Отчетность по статусу конфигураций
- •2.6.5Аудит конфигураций
- •2.6.5.1Функциональный аудит программных конфигураций
- •2.6.5.2Физический аудит программных конфигураций
- •2.6.5.3Внутренние аудиты базовых линий
- •2.6.6Управление выпуском и поставкой
- •2.6.6.1Сборка программного обеспечения
- •2.6.6.2Управление выпуском программного обеспечения
- •3Инструменты и методы программной инженерии
- •3.1Инструменты
- •3.1.1Инструменты работы с требованиями
- •3.1.2Инструменты проектирования и конструирования
- •3.1.3Инструменты тестирования
- •3.1.4Инструменты сопровождения
- •3.1.5Инструменты конфигурационного управления
- •3.1.6Инструменты управления инженерной деятельностью
- •3.1.7Инструменты поддержки процессов
- •3.1.8Инструменты обеспечения качества
- •3.2Методы
- •3.2.1Эвристические методы
- •3.2.2Формальные методы
- •3.2.3Методы прототипирования
- •4Качество и эффективность в программной инженерии
- •4.1Обеспечение качества программного обеспечения
- •4.1.1Качество программного продукта
- •4.1.2Культура и этика программной инженерии
- •4.1.3Значение и стоимость качества
- •4.1.4Повышение качества пс с использованием процессного подхода
- •4.1.5Показатели качества программных средств
- •4.1.6Количественная оценка качества программного обеспечения
- •4.2Модели качества процессов конструирования
- •4.2.1Качество процессов
- •4.2.4Прочие подходы
- •4.3Процессы управления качеством программного обеспечения
- •4.3.1Подтверждение качества программного обеспечения
- •4.3.2Проверка (верификация) и аттестация
- •4.3.3Оценка и аудит
- •4.3.4Характеристика дефектов
- •4.3.5Методы управления качеством программного обеспечения
- •4.4Стандартизация качества программного обеспечения
- •4.4.1Стандарты в сфере программной инженерии
- •4.4.2Стандартизация программных продуктов в еспд
- •4.4.3Виды стандартных программных документов
- •4.4.4Действующие международные стандарты в сфере разработки программных средств и информационных технологий
- •4.5Документирование программных средств
- •4.6Сертификация программных средств
- •4.6.1Правовые акты по сертификации программных продуктов
- •4.6.2Сертификация пс
- •4.6.3Перечень объектов, подлежащих сертификации и их характеристики
- •Заключение Библиография
2.5.2.2Оценка стоимости сопровождения
Как уже отмечалось, инженеры должны понимать разницу в различных категориях сопровождения. Это, в большой степени, необходимо для оценки соответствующих затрат. С точки зрения планирования, как составной части проектной и управленческой деятельности, оценка стоимости является важным аспектом деятельности по сопровождению программного обеспечения.
2.3.1 Оценка стоимости (Cost Estimation)
При обсуждении анализа влияния (см. 2.1.3 Impact Analysis) говорилось о том, что такой анализ помогает в оценке стоимости работ по сопровождению. На эти затраты оказывает влияние множество технических и других факторов. ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance)определяет, что “существует два наиболее популярных метода оценки стоимости сопровождения – параметрическая модель и использование опыта”. Чаще всего, оба этих подхода комбинируются для повышения точности оценки.
2.3.2 Параметрические модели (Parametric models)
SWEBOK приводит ряд источников, подробно рассматривающих вопросы оценки стоимости сопровождения и, в частности, параметрические модели. Для использования таких моделей используются данные предыдущих проектов. Наравне с историческими данными используется метод функциональных точек (см. стандарт IEEE 14143.1-00).
2.3.3 Опыт (Experience)
Среди тех подходов, которые позволяют повысить точность оценок, полученных при использовании параметрических моделей – применение опыта (в форме экспертного мнения, например, при использовании техники оценки “Delphi”, название которой происходит от “делфийского оракула”), аналогий, а также структуры декомпозиции работ. Наилучшие результаты получаются в случае сочетания эмпирических методов с имеющимся опытом. Получаемые данные используются как результат программы измерения аспектов сопровождения.
2.5.2.3Измерения в сопровождении программного обеспечения
Формы и данные измерений в процессе сопровождения могут объединяться в единую программу корпоративную программу количественных оценок, проводимых в отношении программного обеспечения. Многие организации используют популярный и практичный подход для измерений, базирующийся на оценке количества проблем и статуса их решений (issue-driven measurement). Идеи этого подхода систематизированы в проекте Practical Software and Systems Measurement (PSM). Существуют общие (для всего жизненного цикла) метрики и, соответственно, их категории, в частности, определяемые Институтом Программной Инженерии университета Карнеги-Меллон (Software Engineering Institute, Carnegie-Mellon University – SEI CMU): размер, усилия, расписание и качество. Применение этих метрик является хорошей отправной точкой для оценки работ со стороны организации, отвечающей за сопровождение.
Более детальное обсуждение вопросов измерений в отношении продуктов и процессов представлено в области знаний “Процесс программной инженерии (Software Engineering Process). В свою очередь, вопросы организации программы измерений относятся к области знаний “Управление программной инженерией” (Software Engineering Management).
2.4.1 Специализированные метрики (Specific Measures)
Существуют различные методы внутренней оценки продуктивности (benchmarking) персонала сопровождения для сравнения работы различных групп сопровождения. Организация, ведущая сопровождение, должна определить метрики, по которым будут оцениваться соответствующие работы. Стандарты IEEE 1219 (Standard for Software Maintenance) и ISO/IEC 9126-01 (Software Engineering – Product Quality – Part 1: Quality Model, 2001 г.) предлагают специализированные метрики, ориентированные именно на вопросы сопровождения и соответствующие программы.
Ниже представлены типичные метрики оценки работ по сопровождению, соответствующих распространенной классификации эксплуатационных характеристик программного обеспечения:
Анализируемость (Analyzability): оценка (в первую очередь, дополнительных) усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для идентификации тех фрагментов программной системы, которые должны быть модифицированы.
Изменяемость (Changeability): оценка усилий, необходимых для проведения заданных модификаций.
Стабильность (Stability): оценка случаев непредусмотренного поведения системы, включая ситуации, обнаруженные в процессе тестирования.
Тестируемость (Testability): оценка усилий персонала сопровождения и пользователей по тестированию модифицированного программного обеспечения.