- •Введение
- •Содержание
- •1.1 Анализ и характеристика областей знаний swebok
- •1.1.1. Требования к по (Software Requirements)
- •1.1.2. Проектирование по (Software design)
- •1.1.3. Конструирование по (Software Construction)
- •1.1.4. Тестирование по (Software Testing)
- •1.1.5. Сопровождение по (Software maintenance)
- •1.1.6. Управление конфигурацией по
- •1.1.7. Управление инженерией по
- •1.1.8. Процесс инженерии по (Software Engineering Process)
- •1.1.9. Методы и инструменты инженерии по
- •1.1.10. Качество по (Software Quality)
- •1.2. Жизненный цикл пс, связь с ядром знаний swebok
- •Контрольные вопросы и задания
- •Лекция 2: Модели жизненного цикла для разработки программных систем Содержание
- •2.1. Процессы жц стандарта iso/iec 12207
- •2.2. Типы моделей жц
- •2.2.1. Каскадная модель жц
- •2.2.2. Инкрементная модель жц
- •2.2.3. Спиральная модель
- •2.2.5. Стандартизация модели жц
- •2.3. Сопоставление жц стандарта iso/iec 12207 и областей swebok
- •2.3.1. Характеристика процессов стандарта iso/iec 12207
- •2.3.2. Характеристика областей знаний swebok
- •Контрольные вопросы и задания
- •Лекция 3: Методы определения требований в программной инженерии Содержание
- •3.1. Общие подходы к определению требований
- •3.1.1. Классификация требований
- •3.1.2. Анализ и сбор требований
- •3.1.3. Инженерия требований
- •3.1.4. Фиксация требований
- •3.1.5. Трассировка требований
- •Сложность программного обеспечения
- •1.8.1. Каскадная (водопадная) модель
- •1.8.2. Итеративная и инкрементальная модель
- •1.8.3. Спиральная модель Боэма
- •1.9.1. Методология Rational Unified Process (rup)
- •2. Проектирование (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •1.9.2. Экстремальное программирование
- •Живое планирование (planning game)
- •Программирование парами (pair programming)
- •Включение заказчика в команду (on-site customer)
- •Использование кода как средства коммуникации
- •Открытое рабочее пространство (open workspace)
- •Изменение правил по необходимости (just rules)
1.1.8. Процесс инженерии по (Software Engineering Process)
В некотором смысле это метауровень, который связан с определением, реализацией, оценкой, измерением, управлением изменениями и совершенствованием самого процесса. Однако такой процесс не является единственно правильным способом выполнения задач программной инженерии. На самом деле стандарты о процессах (ГОСТ 12207) говорят о том, что процессов много, например основной процесс разработки (Development Process), процесс управления конфигурацией (Configuration Management Process) и т.п.
Для оценивания и совершенствования процессов программной инженерии используется модель зрелости (Capability Maturity Models - CMM), эту концепцию разработал институт программной инженерии SEI (Software Engineering Institute) США. Модель описывает существенные атрибуты, которыми должен обладать процесс, находящийся на определенном уровне зрелости, а также указывает практические приемы обеспечения уровня абстракции без ограничений на способы реализации процесса в конкретном проекте. Разновидностями этой модели являются: СMM - SW (software) для оценки ПО, CMMI - вариант СММ для учета потребностей крупных государственных структур США, Bootstrap - вариант СММ для малых и средних коммерческих компаний, ISO - 15504 (Software Process Improvement and Capability - SPICE), ISO 9000-3 как приложение к общей модели качества ISO 9001 и др.
Концепция зрелости процесса ПО основывается на интеграции концепции процесса ПО (software process), широты возможностей процесса ПО (software process capability), результативности процесса ПО (software process performance) и зрелости процесса ПО (software process maturity). Процесс ПО в модели СММ - это множество деятельностей (activities), методов (methods), практических приемов и процедур (practices), используемых при разработке ПО и связанных с ним продуктов (например, планов проекта, проектных документов, кода, тестов, руководства пользователя и др.).
Зрелость процесса - это степень его четкости определения, управления, измерения, контроля.
СММ предоставляет шаблон для улучшения процесса в виде пяти уровней зрелости, которые создают основу непрерывного улучшения процесса. Эти пять уровней зрелости определяют шкалу упорядочения для измерения зрелости процесса ПО организации и оценивании возможностей этого процесса. Уровень зрелости - это определенные средства для достижения зрелого процесса, а именно, множество целей процесса, которые, в случае их достижения, стабилизируют процесс в проектной организации.
Область знаний "Процесс программной инженерии (Software Engineering Process)" состоит из следующих разделов:
концепции процесса инженерии ПО (Software Engineering Process Concepts),
инфраструктура процесса (Process Infrastructure),
определение процесса (Process Definition),
оценки процесса (Process Assessments),
количественный анализ процесса (Qualitative Process Analysis),
выполнение и изменение процесса (Process Implementation and Change).
Концепции процесса инженерии ПО - задачи и действия, которые связаны с управлением, реализацией, оценкой, изменениями и совершенствованием процесса и/или ПО. Цель управления процессом - это создание инфраструктуры процесса, выделение необходимых ресурсов, планирование реализации и изменения процесса в целях внедрения его в практику и, наконец, оценка преимущества от его внедрения при реальной практике проектирования конкретного проекта.
Инфраструктура проекта - это его ресурсы (человеческие, технические, информационные и программные), стандарты, службы управления качеством и риском, а также форма организации производства проектов: бригада, экспериментальная фабрика (Experimental Factory), линейка программных продуктов (Framework for Product Line Practice) и др. Она также включает управление и коммуникации в коллективе, инженерные методы организации и производства программного продукта. Главная задача инфраструктуры - совершенствование процесса с учетом опыта разработки ПО.
Определение процесса основывается на: типах процессов и моделей (водопадная, спиральная, итерационная и др.); моделях ЖЦ процессов и средств, стандартах ЖЦ ПО ISO/IEC 12207 и 15504, IEEE std. 1074-91 и 1219-92; а также методах и нотациях задания процессов и автоматизированных средствах их поддержки. Основной целью процесса является повышение качества получаемого продукта, улучшение различных аспектов программной инженерии, автоматизация процессов и др.
Оценка процесса проводится с использованием соответствующих моделей и методов оценки. Например, оценка потенциальной способности специалиста к выполнению соответствующей работы. SWEBOK обращает внимание на процедуру оценки потенциальной возможности заключения контракта на разработку, организации разработки ПС на основе модели оценки зрелости (СММ) и процессов, согласно которым проводится разработка ПО.
Оценки относятся также и к техническим работам в сфере программной инженерии, к управлению персоналом и качеству ПО. Для этого проводятся экспериментальные исследования среды, наблюдение за выполнением процесса, сбор информации, моделирование, классификация полученных ошибок и дефектов, а также статический анализ недостатков процесса в сравнении с существующими стандартами (например, ГОСТ 12207) и потенциальных аспектов совершенствования процесса.
Качественный анализ процесса состоит в идентификации и поиске слабых мест в процессе создания ПО до начала его функционирования. Рассматривается две техники анализа: обзор данных и сравнение процесса с основными положениями стандарта ISO/IEC 12207; сбор данных о качестве процессов; анализ главных причин отказов в функционировании ПО, откат назад от точки возникновения отклонения до точки нормальной работы ПО для выяснения причин изменения процесса. На качество результатов проекта и процесса влияют применяемые инструменты и опыт специалистов.
Выполнение и изменение процесса. Существует ряд фундаментальных аспектов измерений в программной инженерии, лежащих в основе детальных измерений процесса. Оценка совершенствования процессов проводится для установления количественных характеристик процесса и продуктов. После процесса развертывания ПО, выполняются вычисления функций и инспекция результатов выполнения. Результаты процесса могут касаться оценки качества продукта, продуктивности, трудозатрат и др. Если результаты не удовлетворяют пользователя ПО, то проводится анализ и принятие решений о необходимости изменения или усовершенствования процесса, организационной структуры проекта и некоторых инструментов управления измерениями.
