Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

20 Глава 1

Кадровый аспект Описание возможностей

Накопление и за-

крепление положи-

тельного опыта

• Определение форматов и средств накопления и сохранения при-

обретенного опыта (опросы, семинары, шаблоны (формы), про-

тотипы и т.п.)

• Создание библиотек активов организации по принципу «лучший

объект». Включение их в сферу управления конфигурацией.

Обеспечение доступности

Стандарты межпро-

ектного взаимодей-

ствия

• Определение стандартов (границ компетенции, знаний) по про-

цессам ЖЦ создаваемой ПС. Унификация и стандартизация

приемов работы с целью построения и поддержки базового про-

цесса программной инженерии

• Профилирование знаний для обеспечения заменяемости специа-

листов в проектах. Соблюдение принципа «глубокие знания в

узкой сфере». Определение интерфейсов (учитывая межпроект-

ные отличия)

Таблица 1.2. Роли специалистов в организационной структуре разработки

Роли на уровне

организации

Обязанности

Группа технико-

технологической

поддержки

• Изучение рынка услуг и спроса в организации относительно техни-

ки и общесистемного ПО (ОПО)

• Приобретение/установка/поддержка техники

• Приобретение/установка/поддержка ОПО

• Обучение/консультационные услуги сотрудникам

• Рекомендации по применению техники и технологий в проектах

Группа защиты

информации

• Изучение состояния дел в области защиты информации и накопле-

ние опыта (наработка активов для общего использования)

• Обеспечение защиты информации в организации

• Проверка защиты информации в организации

• Поддержка проектов в вопросах защиты информации

Группа инжене-

рии процесса

(технологиче-

ская служба)

• Определение, сопровождение и совершенствование базового про-

цесса программной инженерии. Обеспечение нормативно-

методической поддержки выполнения процессов ЖЦ. Организация

и пополнение хранилища (библиотеки) активов организации

• Помощь менеджерам проектов в адаптации базового процесса к

потребностям проектов. Подбор или изготовление форм (шаблонов)

документов для инженерии проектов

• Поддержка процесса документирования в проектах, в частности

выполнение трудоемких графических работ, оформление докумен-

тов в соответствии со стандартами оформления. Нормоконтроль и

печать документов

• Межпроектная координация в части накопления опыта и организа-

ции обучения

• Поддержка управления конфигурацией в проектах (по договоренно-

сти с руководителями проектов)

Глава 1

Роли на уровне

организации

Обязанности

Независимая

группа качества

(SQA-группа)

• Планирование и выполнение действий по контролю и гарантирова-

нию соблюдения дисциплины создания программной продукции в

проектах (организация проверок работ в контрольных точках про-

ектов, определенных календарными планами)

• Контроль документов и продуктов ПО (определенных в календар-

ных планах как результаты работ) в контрольных точках проектов

на предмет соблюдения действующих стандартов и других норма-

тивных документов, установленных в требованиях Заказчика

• Беспристрастие, отчетность непосредственно перед руководителем

организации

Независимая

группа верифи-

кации и валида-

ции

(V&V-группа)

• Выполнение функций верификации (по договоренности с группой

SQA)

• Планирование и проведение независимого квалификационного тес-

тирования интегрированных компонентов ПО или программных

продуктов с целью определения их соответствия требованиям За-

казчика

• Координирование планов работ с менеджерами проектов относи-

тельно требований к тестовой среде, сроков и порядка передачи ПО

на тестирование

• Предоставление отчетов (результатов) тестирования менеджерам

проектов для принятия мер по исправлению ПО

• Независимость от менеджеров проектов в части определения объе-

мов и методов тестирования

• Отчетность перед руководителем организации за соблюдение по-

рядка тестирования и состояние разработанных программных про-

дуктов

Группа под-

держки Заказ-

чика

• Связь с Заказчиком по вопросам автоматизации деловых процессов

• Поддержка процессов управления требованиями, обучения пользо-

вателей, сопровождения (или помощь в их выполнении на уровне

отдельных проектов)

Роли на уров-

не проекта

Обязанности

Руководитель

проекта системы

• Полная финансовая ответственность за выполнение проектных со-

глашений перед Заказчиком

• Управление разработкой составляющих создаваемой продукции –

проектов ПО, КТС, средств защиты информации (если проект пре-

дусматривает создание системы «под ключ» с поставкой всех со-

ставляющих)

• Ответственность за действия соисполнителей проекта

Системные ана-

литики

• Обследование условий и потребностей автоматизации деятельности

организации-потребителя

• Системный анализ требований потребителя и формирование кон-

цепции системы

• Контроль обоснованности принимаемых проектных решений

22 Глава 1

Роли на уров-

не проекта

Обязанности

Группа качества

проекта

• Контроль качества рабочих продуктов, произведенных процессами

ЖЦ (на соответствие стандартам, методикам и т.п.)

• Подотчетность только руководителю проекта

• Может отсутствовать, если на уровне организации действует неза-

висимая группа качества

Группа V&V

проекта

• Проверка соответствия рабочих продуктов, произведенных на опре-

деленном этапе ЖЦ, требованиям к ним, установленным на преды-

дущем этапе (например, соответствие решений в пояснительной за-

писке к проекту требованиям, установленным в техническом зада-

нии)

• Может выполнять тестирование отдельных компонентов ПО, а так-

же системное (интеграционное) тестирование ПО, произведенного

в проекте

• Подотчетна только руководителю проекта

Менеджер про-

екта ПО

• Полная ответственность за все проектные решения и действия, свя-

занные с разработкой ПО в проекте

• Подбор и контроль ресурсов проекта (относительно ОПО), а также

графика работ

• В больших или распределенных (по соисполнителям) программных

проектах может быть несколько менеджеров (по подсистемам или

уровням проекта ПО)

Проектировщики

• Принятие и документирование проектных решений по архитектуре

и функциям ПО. Согласование решений с менеджером проекта ПО

• Соблюдение стандартов качества (обеспечение достижения харак-

теристик качества)

Программисты

• Программирование или моделирование (макетирование, быстрое

прототипирование) компонентов ПО по проектным спецификациям

(постановкам задач), подготовленным проектировщиками

• Соблюдение стандартов качества при программировании (по удоб-

ству сопровождения кода, удобству применения программ и др.)

• Отладка и автономное тестирование разработанных компонентов

Группа управле-

ния конфигура-

цией

• Выполнение процесса конфигурационного управления версий ПО и

рабочих продуктов проекта ПО

Группа сопро-

вождения

• Выполнение процесса сопровождения версий ПО и рабочих про-

дуктов проекта ПО во время опытной эксплуатации и в течение ус-

тановленного периода сопровождения

• Обучение пользователей

• Выполнение процесса решения проблем

• Могут быть членами группы поддержки Заказчика

Группа проекта

ЛКС

• При разработке системы «под ключ» проектирование и монтаж

ЛКС для установки в организации потребителя

• Закупка и установка КТС и ОПО, пусконаладочные работы и т.п.

Глава 1

1.1.2. Архитектура процессов жизненного цикла

Процесс программной инженерии имеет иерархическую архитектуру, вклю-

чая множество процессов жизненного цикла (ЖЦ) программной системы.

Требования к процессам ЖЦ ПС определяет международный стандарт

ISO/IEC 12207. Нужно отметить, что в Украине принят стандарт ДСТУ 3918-99 -

аналог ISO/IEC 12207, утвержденного ISO в 1995 году [1]. Однако со времени сво-

его выхода, стандарт ISO/IEC 12207 подвергался пересмотру, и в «текущей» редак-

ции имеет расширенный состав процессов ЖЦ, сформированный с учетом потреб-

ностей других международных стандартов (таблицы 1.3 – 1.5) [2, 3].

Процессы ЖЦ распределены по трем группам, что отражает функциональную

направленность видов деятельности, которые эти процессы регламентируют:

• основные процессы;

• поддерживающие процессы;

• организационные процессы.

Основные процессы ЖЦ охватывают действия по разработке, поставке, при-

обретению, эксплуатации и сопровождению программных продуктов (таблица 1.3).

Таблица 1.3. Основные процессы ЖЦ

№ п/п Наименование процесса (подпроцесса)

1.1 Приобретение

1.1.1 Подготовка приобретения

1.1.2 Выбор поставщика

1.1.3 Мониторинг деятельности поставщика

1.1.4 Приемка потребителем

1.2 Поставка

1.2.1 Участие в тендере

1.2.2 Заключение договора

1.2.3 Выпуск продукта (релиза)

Поддержка приемки продукта

1.3 Разработка

1.3.1 Выявление требований

1.3.2 Анализ требований к системе

1.3.3 Проектирование архитектуры системы

1.3.4 Анализ требований к ПО системы

1.3.5 Проектирование ПО

1.3.6 Программирование (кодирование) ПО

1.3.7 Интеграция ПО

1.3.8 Тестирование ПО

1.3.9 Системная интеграция

1.3.10 Системное тестирование

1.3.11 Инсталляция ПО

1.4 Эксплуатация

1.4.1 Функциональное использование

1.4.2 Поддержка потребителя

1.5 Сопровождение

24 Глава 1

Поддерживающие процессы интегрируются с любыми другими процессами,

решая задачи, вспомогательные по отношению к задачам этих процессов, и обеспе-

чивая качество их решения в конкретных проектах (таблица 1.4).

Таблица 1.4. Поддерживающие процессы ЖЦ

№ п/п Наименование процесса

2.1 Документирование

2.2 Управление конфигурацией

2.3 Обеспечение гарантии качества

2.4 Верификация

2.5 Валидация

2.6 Совместный просмотр

2.7 Аудит

2.8 Управление решением проблем

2.9 Управление запросами на изменение

2.10 Обеспечение применимости продукта (поддержка пользователя)

2.11 Оценивание продукта

Организационные процессы направлены на формирование производственной

структуры, включающей множество процессов ЖЦ и персонал, а также на ее под-

держку и совершенствование (таблица 1.5).

Таблица 1.5. Организационные процессы ЖЦ

№ п/п Наименование процесса (подпроцесса)

3.1 Управление

3.1.1 Организационное строительство (формирование корпоративной политики,

целей, процессов, стандартов, этики)

3.1.2 Управление организацией

3.1.3 Управление проектом

3.1.4 Управление качеством

3.1.5 Управление риском

3.1.6 Измерение

3.2 Поддержка инфраструктуры

3.3 Совершенствование

3.3.1 Учреждение процессов

3.3.2 Оценивание процессов

3.3.3 Улучшение процессов

3.4 Обеспечение трудовыми ресурсами

3.4.1 Управление кадрами

3.4.2 Обучение

3.4.3 Управление знаниями (распространение знаний)

3.5 Управление достоянием (активами организации)

3.6 Управление программой повторного использования

3.7 Доменная инженерия

Глава 1

Как видно из таблиц, часть процессов ЖЦ (особенно процессов поддержки)

имеют непосредственное отношение к обеспечению качества программных про-

дуктов и будут подробнее представлены в последующих главах.

1.1.3. Парадигмы программирования и качество

Парадигма программирования – набор элементов понятийного аппарата,

способ их представления и концепция взаимодействия (взаимосвязи), лежащие в

основе базовых правил построения программ из сформированного множества базо-

вых конструкций.

Исторически первая парадигма программирования — императивное про-

граммирование. Методологии императивного программирования учитывают прин-

ципы последовательного пошагового изменения состояния вычислительной среды

компьютера и полного управления этими изменениями. Примеры таких методоло-

гий – модульное (процедурное) программирование, структурное программирова-

ние, а также неструктурное программирование

. К императивным относят также

объектно-ориентированное программирование, определяемое зачастую как само-

стоятельная парадигма программирования.

Другая очень «старая», хотя и до недавнего времени менее широко исполь-

зуемая парадигма программирования – декларативное программирование. В отли-

чие от императивного программирования, где программист должен четко опреде-

лить алгоритм решения задачи, в декларативном программировании четко опреде-

ляются структуры данных, цели решения или свойства решения задачи, а не спо-

соб ее решения. Примеры методологий декларативного программирования - функ-

циональное программирование (например, на языке Lisp), логическое программиро-

вание (например, на языке Prolog) и др. Декларативные языки могут быть доменно-

ориентированы (специализированы для определенного домена), как, например,

SQL (для работы с базами данных), HTML (для описания web-страниц) и др.

Каждая парадигма программирования ориентирована на определенную аппа-

ратную архитектуру и вычислительную модель и поддерживается одним или не-

сколькими языками программирования (ЯП). В то же время, один ЯП может при-

меняться для программирования во многих парадигмах, как, например, C++ ис-

пользуемый и в процедурном, и в объектно-ориентированном программировании.

Существует множество других современных парадигм программирования, в

числе которых компонентное программирование, аспектно-ориентированное про-

граммирование, порождающее программирование и другие.

Появление новой парадигмы программирования служит толчком к разработ-

ке методологий, методов и языков программирования, к созданию новых подходов

в программной инженерии в целом, и в инженерии качества, в частности.

Выбор методологий программирования, основанных на той или иной пара-

дигме программирования, определяет выбор методов верификации кода, объектов

и методов тестирования, а также измеряемых атрибутов программ и используемых

метрик.

Конечно, в этой книге невозможно ни охарактеризовать все существующие

парадигмы программирования, ни описать все особенности обеспечения качества

Языками, поддерживающими неструктурное программирование, являются Ассемб-

леры.

26 Глава 1

программ, разработанных в этих парадигмах. Тем не менее, мы посчитали нужным

дать очень краткий обзор и широко, и мало известных совсем новых парадигм и

методологий программирования (глава 2), но ограничиться при описании методов

обеспечения качества в основном традиционными методологиями императивного и

(отчасти) объектно-ориентированного программирования. Надеемся, что читатели,

«уловив» общие идеи, смогут на практике нужным образом адаптировать описан-

ные в книге подходы к качеству или обратиться к специализированным литератур-

ным источникам.

1.1.4. Инженерия процессов разработки

Современной концепцией процесса программной инженерии является по-

строение базового процесса организации (БПО), разрабатываемого, сопровож-

даемого, оцениваемого и улучшаемого подобно тому, как разрабатываются, сопро-

вождаются, оцениваются и модернизируются программные продукты [4].

БПО служит основой для определения процессов всех программных проек-

тов. Процессы на уровне проектов разрабатываются путем адаптации БПО к ха-

рактеристикам конкретного проекта.

Определение БПО - это формализованное описание состава процессов ЖЦ, из

которых должны выстраиваться процессы разработки в программных проектах, а

также взаимосвязей (порядка следования и интерфейсов) между элементами этих

процессов. Описание обеспечивает согласованность выполнения работ в организа-

ции, стабильность процессов и фундамент для их улучшения.

С каждым процессом разработки связываются:

• требования к процессу, которые указывают, «что» собой представляет

процесс (что он будет делать);

• архитектура и проект процесса, которые описывают, «как» процесс бу-

дет определен (каковы будут элементы процесса и как они будут взаимосвязаны);

• реализация описания (проекта) процесса в рамках организации или про-

граммного проекта (создание элементов процесса и установление интерфейсов);

• проверка и утверждения определения процесса;

• внедрение процесса в среду конкретного проекта.

На рисунке 1.2 представлены основные элементы описанной концептуальной

модели инженерии процессов разработки программных систем:

• базовый процесс (включая архитектуру процесса и его элементы);

• описания моделей ЖЦ, рекомендованных для использования в организа-

ции;

• руководства и критерии для адаптации БПО;

• база данных БПО;

• библиотека документации, связанной с процессом разработки.

Элементы БПО открыты для использования проектами при разработке, со-

провождении и реализации собственных процессов для проектов.

Архитектура БПО представляет собой высокоуровневое описание базового

процесса организации, касающееся приоритетов, интерфейсов, взаимозависимостей

и других взаимоотношений между элементами БПО и с другими внешними по от-

ношению к нему процессами (например, системной инженерии, инженерии аппа-

ратного обеспечения и др.).

Глава 1

Разработка базового процесса организации

База данных

процесса

организации

Библиотека

документа-

ции,

связанной с

процессом

Описания

жизнен-

ных циклов

ПС

Руководства

и критерии

по

адаптации

базового

процесса

Элементы базового процесса в организации

Описание базового процесса организации

Архитектура процесса

Описание элементов процесса

План разработки ПО проекта

Действия

Результаты и рабочие продукты ПС проекта

Внешние

требования

Системные

требования

Системные

требования,

делегирован-

ные ПС

Выбор

модели ЖЦ

ПС проекта

Разработка

процесса,

предназначенного

для проекта

Описание процесса, предназначенного для проекта

Жизненный цикл проекта

Высокоуровневая архитектура процесса инженерии ПС

(стадия 1) (стадия 2) (стадия 3) (стадия 4)

Описания элементов процесса проекта

Задачи проекта

(стадия 1) (стадия 2) (стадия 3) (стадия 4)

Рис. 1.2. Концептуальная модель инженерии процессов разработки

28 Глава 1

Элемент БПО - это составной элемент описания процесса. Каждый элемент

процесса охватывает четко определенное, ограниченное и связное множество задач.

Описания элементов процесса могут представлять собой:

• шаблоны форм, подлежащих заполнению;

• фрагменты, требующие укомплектования;

• описания, выполненные на высоком уровне абстракции и нуждающиеся в

уточнении;

• полностью сформированные описания, которые могут быть модифициро-

ваны или использованы без изменений.

Описание моделей ЖЦ, рекомендованных к использованию - это набор опи-

саний известных из литературных источников и адаптированных к нуждам органи-

зации моделей. По согласованию с заказчиком или пользователем конкретного

проекта одна из этих моделей должна быть использована в сочетании с базовым

процессом при построении процесса для проекта.

Руководства и критерии адаптации БПО призваны помочь руководителям

проектов выбрать модель ЖЦ для использования и адаптировать БПО и выбранную

модель к характеристикам конкретного проекта. Эти руководства и критерии обес-

печивают общий базис для планирования, реализации, измерения, анализа и совер-

шенствования процессов разработки ПС проектов.

База данных БПО - это БД, предназначенная для сбора и предоставления ин-

формации о процессах и полученных в ходе их выполнения рабочих продуктах, в

частности, тех, которые имеют непосредственное отношение к БПО.

Эта БД содержит или ссылается как на данные реальных измерений, так и на

информацию, необходимую для понимания этих данных и оценивания их обосно-

ванности и применимости. БД может содержать, например, оценки размера ПС,

трудоемкости и стоимости ее разработки, реальные данные о размере, трудоемко-

сти и стоимости ПС, данные о производительности, полноте охвата и эффективно-

сти проверок ПС, о числе и серьезности дефектов, обнаруженных в коде, и др.

Библиотека документации процесса создается для хранения документов

процесса, которые могут быть полезными для других действующих или будущих

проектов, особенно имеющих отношение к базовому процессу организации (это

могут быть процессы проектов, стандарты, процедуры, планы разработки, планы

измерений и материалы по процессу обучения). Использование фонда библиотеки

должно помочь снизить затраты труда на развертывание нового проекта, демонст-

рируя примеры успешно выполненных проектов, которые могут быть взяты за об-

разец.

Описание процесса предназначенного для проекта - это используемое проек-

том операционное определение процесса, изложенное в терминах стандартов по

программной инженерии, процедур, инструментов и методов. Оно разрабатывается

путем адаптации определения БПО. Описание процесса проекта создает базу для

планирования, выполнения и улучшения деятельности исполнителей проекта.

Стадии выполнения проекта отражают распределение усилий на разработку.

Они имеют регулируемый размер и представляют собой измеримое множество свя-

занных между собой задач, выполняемых проектом. Обычно стадия - это фрагмент

ЖЦ, как правило, заканчивающийся формальным обзором, предшествующим нача-

лу следующей стадии.

Глава 1

Задача (или технологическая операция) - это четко определенная единица ра-

боты в процессе, завершение которой представляет собой для руководства проек-

том видимую контрольную точку для оценки состояния проекта. С задачей связы-

вается критерий готовности (предусловие выполнения) и критерий завершения (по-

стусловие выполнения).

Рабочие продукты (РП) - это результаты деятельности или решения задач в

ходе определения, сопровождения или использования процесса, включая описания,

планы, процедуры, компьютерные программы и связанную с ними документацию,

которые предназначаются (или не предназначаются) к поставке заказчику или

пользователю. Рабочие продукты образуют вход для следующего шага процесса

или архивную информацию по проекту ПС для использования будущими проекта-

ми (например, планы, оценки, данные о реальной трудоемкости, документы требо-

ваний и др.).

Продукты ПС (или поставляемые программные продукты (ПП)) представ-

ляют собой полное множество или любой из отдельных элементов множества ком-

пьютерных программ, процедур, данных и соответствующей документации, пред-

назначенных для передачи заказчику или конечному пользователю. Все поставляе-

мые продукты являются в то же время рабочими продуктами, но не все рабочие

продукты представляют собой поставляемые продукты.

Собственно выполнению процесса в проекте предшествует построение плана

разработки ПС. Этот план в виде одного или группы документов образует мост

между процессом в проекте и конкретной реализацией этого процесса (с указанием

исполнителей и графика выполнения задач). Только сочетание точного определе-

ния процесса и плана разработки дает возможность реально выполнить процесс

программной инженерии.

1.1.5. Интеграция процессов жизненного цикла

Каждое программное приложение ПС, программный комплекс (ПК) в составе

ПО системы или отдельное программное средство проходит следующие стадии

ЖЦ независимо от выбранной модели ЖЦ.

 определение требований,

 проектирование,

 кодирование, автономное тестирование и отладка,

 интеграция (если ПО - часть системы),

 тестирование на соответствие функциональным и не функциональным

(техническим) требованиям,

 внедрение,

 сопровождение,

 списание (замена новым).

Работы на этих стадиях ЖЦ соотносятся с действиями в основных процессах

(см. табл. 1.3). Нормативной базой для их выполнения является стандарт ДСТУ

3918-99.

При построении БПО руководители организации-разработчика ПС изначаль-

но определяют состав основных процессов из числа рекомендованных стандартом

ДСТУ 3918-99, а затем поддерживающих и организационных процессов. В своих

решениях они руководствуются соображениями целесообразности включения того

или иного процесса в БПО с позиций необходимости выполнения регламентируе-