- •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.6.2.2Программная библиотека
Программная библиотека – контролируемая коллекция программных приложений и связанной с ними документации, предназначенная для использования в процессе разработки, эксплуатации и сопровождения программного обеспечения (см. IEEE 610.12-90). В качестве <элемента> программной библиотеки, также, может рассматриваться инструментарий, используемый в работах по выпуску программного обеспечения и передаче его в эксплуатацию (например, инсталляции). На практике могут использоваться различные типы библиотек, каждая из которых соответствует определенному уровню зрелости элементов программного обеспечения. Например, “рабочая библиотека” (working library) может поддерживать работы по кодированию, “библиотека поддержки проекта” (project support library) может поддерживать тестирование, “мастер-библиотека” (master library) может использоваться для завершенных продуктов (например, как вся совокупность средств, используемых для разработки и/или выпуска продукта). С каждой библиотекой ассоциирован соответствующий уровень контроля конфигурационного управления, также ассоциированный с базовой линией и уровнем полномочий по внесению изменений. Безопасность (в терминах контроля доступа и средств резервного копирования) является одним из ключевых аспектов управления библиотеками. SWEBOK отмечает, что существуют различные модели программных библиотек, а также приводит соответствующие первоисточники по этой теме.
Используемые для каждой библиотеки инструменты должны поддерживать контроль SCM, необходимый для данной библиотеки, как в терминах управления элементами конфигурации (SCI), так и с точки зрения контроля доступа к библиотеке. На уровне рабочей библиотеки – это средства управления кодом, обслуживающие разработчиков, специалистов по сопровождению и SCM-процесс/инструментарий (например, среда разработки должна обеспечивать интеграцию с SCM-системой). В данном контексте, рабочая библиотека фокусируется на управлении версиями программных элементов (к которым, безусловно, относится не только код, но и запросы на изменения, включая сообщения об обнаруженных дефектах, и т.п.) в многопользовательской среде. На более высоком уровне контроля, доступ ограничен сильнее и SCM (процесс и/или система) является основным пользователем <библиотеки> (например, для осуществления автоматической сборки продукта по расписанию).
Все эти библиотеки также являются важным источником информации для количественной оценки работ, их результата и прогресса <в развитии программных элементов>.
2.6.3Контроль программных конфигураций
Контроль программных конфигураций касается вопросов управления изменениями в течение жизненного цикла программного обеспечения. Он включает процесс определения того, какие именно изменения должны быть сделаны, какие полномочия необходимы для утверждения определенных <типов> изменений, в чем состоит поддержка реализации этих изменений, а также концепцию формального утверждения отклонений от проектных требований, также как и отказа от внесения изменений. Получаемая в результате этого информация полезна для количественной оценки потока изменений, нарушения целостности <системы> и аспектов “переработки” в проекте (в большинстве случаев, по времени, стоимости и усилиям - трудозатратам).