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

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

48 Глава 1

СММ предлагает критерии, позволяющие оценить зрелость организаций-

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

для улучшения процессов разработки и сопровождения ПС, а также государствен-

ными и коммерческими организациями-заказчиками для оценки рисков заключения

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

исполнителями.

Предложенный SEI подход к достижению и оцениванию зрелости не предпо-

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

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

разработку высококачественных продуктов.

В отличие от стандарта ISO/IEC TR 15504, СММ допускает оценку зрелости

не в виде профиля мощности процессов ЖЦ по совокупности атрибутов (векторная

оценка), а интегральную численную оценку (скаляр) уровня зрелости организации

– от 2 до 5.

Подробно модель СММ, а также ее модификации рассматриваются в главе

12.

1.2.6. Управление качеством и внедрение системы качества

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

управлением качеством на количественной основе.

Управление качеством ПС - целенаправленная систематическая деятельность

по планированию, учету, контролю и регулированию качества ПС в ходе ее разра-

ботки.

Способность непрерывно управлять происходящими процессами в условиях

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

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

детельство высокой зрелости организации.

В соответствии с моделью СММ, чем выше уровень управления и шире

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

ПС. Например, принадлежность ко второму уровню зрелости по модели СММ ха-

рактеризуется наличием, как минимум, таких ключевых направлений – «управле-

ние требованиями», «управление работами соисполнителей» и «управление конфи-

гурацией», а также присутствием отдельных элементов управления – «планирова-

ние проекта», «гарантирование (контроль) качества (SQA)» и «мониторинг (учет и

контроль) проекта». По мере создания и организационного оформления процессов

ЖЦ и применения инженерного подхода к разработке у организации-разработчика

появляется возможность дополнить деятельность по управлению элементом регу-

лирования и сделать ее полноценной. Такая возможность объясняется прозрачно-

стью (просматриваемостью насквозь) процессов и измеримостью как процессов,

так и продуктов ПС. Так, на третьем уровне модели СММ, планирование и монито-

ринг проекта перерастают в «интегрированное управление проектом», а затем в

«управление процессами» (на четвертом уровне СММ) и «управление изменения-

ми» (на пятом уровне СММ).

То же можно сказать и о качестве ПС, управляемость которой повышается от

уровня к уровню – от SQA (на втором уровне СММ) к улучшению качества за счет

осуществления инженерии процессов (на третьем уровне СММ) и, наконец, к

управлению качеством ПС (на четвертом уровне СММ).

Глава 1 49

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

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

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

Основополагающими стандартами в области качества продукции являются

стандарты ISO серии 9000. Эти стандарты рекомендуют каждой разрабатывающей

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

ства.

Система качества ПС по определению стандарта ДСТУ 2844 - это совокуп-

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

сов, направленных на реализацию управления качеством ПС. Действующая в орга-

низации-разработчике ПС система качества обеспечивает решение задач контроля,

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

кое качество программных продуктов. Вопросы построения и сертификации систе-

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

1.3. Концепция инженерии качества

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

процесс инкорпорации в ПС на каждой стадии ЖЦ определенных свойств, характе-

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

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

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

Процесс инженерии качества должен гарантировать что:

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

зователей, менеджеров и разработчиков ПС;

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

измерены количественно или верифицированы;

• процессы ЖЦ содержат процедуры, ориентированные на выявление тре-

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

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

тифицированы и соблюдаются;

• разработчики ПС понимают цели качества и выполняют встраивание в

программные продукты свойств, обеспечивающих внутреннее, внешнее и эксплуа-

тационное качество;

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

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

функции, связанные с контролем, оцениванием и прогнозированием качества;

• результаты измерений, оценивания и прогнозирования качества исполь-

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

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

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

ние ПС с целью проверки согласованности с требованиями качества.

Нужно отметить, что стандарт ISO/IEC 12207 не выделяет инженерию каче-

ства в виде отдельного поддерживающего или организационного процесса ЖЦ.

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

чества касаются следующие:

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

50 Глава 1

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

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

• процесс гарантирования качества;

• процессы V&V;

• процесс анализа требований к ПС;

• процесс измерения;

• процесс усовершенствования процессов ЖЦ.

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

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

ектах (рисунок 1.6).

Совершен-

ствование

процессов

Управление

проектом

Анализ

требований

Рис. 1.6. Интеграция процессов ЖЦ в концепции инженерии качества

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

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

организацией для совершенствования базовых процессов ЖЦ.

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

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

кости проекта.

Управление качеством опирается на процессы SQA и V&V.

Процесс SQA взаимодействует с процессом анализа требований к ПС для

своевременного контроля за изменением требований.

Связь между процессами отражается в иерархии планов выполнения процес-

сов (например, в плане управления проектом используется ссылка на план качества,

в плане качества – на план управления риском и план V&V и т. д.).

Таким образом, основные положения концепции инженерии качества

можно сформулировать следующим образом:

1. Процессо-ориентированная программная инженерия. Интеграция про-

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

ные функции, связанные с обеспечением качества.

2. Целе-ориентированная программа измерения. Цели качества установлены

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

Глава 1 51

3. Измерение – ключевое звено цикла управления проектом и совершенство-

вания процессов ЖЦ.

4. Совершенствование процессов ЖЦ в организации - в контексте дости-

жения целей качества и повышения эффективности управления проектом.

Литература к главе 1

1. ДСТУ 3918-99. Інформаційні технології. Процеси життєвого циклу програмного забез-

печення.

2. ISO/IEC 12207:1995 / Amd.1:2002 Information technology – Software life cycle processes.

3. ISO/IEC 12207:1995 / Amd.2:2004 Information technology – Software life cycle processes.

4. Модель оценки технологической зрелости организаций-разработчиков ПО / Андон

Ф.И., Суслов В.Ю., Коротун Т.М., Коваль Г.И., Слабоспицкая О.А. // Проблемы про-

граммирования. - 1998. - № 4. - С. 46 - 57.

5. A guide to the Project Management Body of Knowledge // PMBOK GUIDE. Third Edition

(http://www.pmi.org/emeaelink/pmiE-link10-04.pdf).

6. ДСТУ 2844-94. Програмні засоби ЕОМ. Забезпечення якості. Терміни та визначення.

7. ISO/IEC 9126-1:2001 Software engineering - Product quality -Part 1: Quality model.

8. Парадигма качества программного обеспечения / Ф.И. Андон, В.Ю. Суслов, Т.М. Коро-

тун, Г.И. Коваль // Проблемы программирования. - 1999. - № 2. - С. 51 - 62.

9. ISO/IEC 12207:1995. Information technologies. Software life cycle processes. // ISO/IEC. -

1995. – 61 p.

10. Коротун Т.М. Верификация и валидация ППО автоматизированных систем организа-

ционного управления //Сб. материалов конференции. УкрПРОГ’98, 2-4 сентября 1998 г.

-Киев. - 1998. - С. 362 - 367.

11. Коротун Т.М., Лаврищева Е.М. Построение процесса тестирования информационных

систем //Проблемы программирования. –2002. - № 1 – 2. –С. 272 – 281.

12. Коваль Г.І. Байєсівські мережі як засіб оцінювання та прогнозування якості ПЗ // Про-

блемы программирования. –2005. - № 2. –С. 15 – 23.

13. Коваль Г.И. Методы определения размера ПО // Проблемы программирования. -1999. -

№ 1. -С. 63 - 71.

14. Визначення витрат на створення ПЗ АС / Андон П.І.,Суслов В.Ю., Коротун Т.М., Ко-

валь Г.І. // Проблемы программирования. - 1998. – № 3 -С. 23 - 34.

15. Управление риском проектов ПО / Андон Ф.И., Суслов В.Ю., Коротун Т.М., Коваль

Г.И. // Проблемы программирования. - 1999. – № 1 -С. 53 - 62.

16. ДСТУ ISO/IEC TR 15504-7:2002. Інформаційні технології – Оцінювання процесів жит-

тєвого циклу програмних засобів - Частина 7: Настанови з удосконалення процесу.

17. ДСТУ ISO/IEC TR 15504-2:2002.Інформаційні технології – Оцінювання процесів життє-

вого циклу програмних засобів - Частина 2: Еталонна модель процесів та потужності

процесу.

Глава 2. ИНЖЕНЕРИЯ КАЧЕСТВА. ЯДРО

ПРОФЕССИОНАЛЬНЫХ ЗНАНИЙ

Для того чтобы своевременно учитывать факторы, влияющие на качество, и

действительно управлять качеством выпускаемой продукции в ходе ЖЦ, необхо-

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

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

Знания разработчиков ПС отличаются большим разнообразием, но, как пра-

вило, не полны, не согласованы и разнородны, специализированы в отдельных

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

отраслевыми бизнес-системами. И, что самое важное, эти знания в процессе инже-

нерной деятельности постепенно уточняются, видоизменяются и пополняются.

В последнее десятилетие ведущие зарубежные профессиональные объедине-

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

профессиональных знаний (Body of Knowledge – BOK), составляющих предмет

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

продукции. Ими подготовлены два Руководства (Guide), соответственно Guide for

SWEBOK и Guide for PMBOK, содержащие разделы и тематические рубрики, опре-

деляющие ядро знаний в указанных областях

Однако в области качества ПС подобное ядро знаний не имеет четких конту-

ров и документально не оформлено как таковое.

В этой главе мы даем краткую характеристику программной инженерии как

дисциплины, предлагаем обзор основных положений SWEBOK и PMBOK и пред-

ставляем наше видение элементов ядра знаний в области качества.

2.1. Программная инженерия – дисциплина и специальность

Термин программная инженерия прочно вошел в жизнь в начале 70-х годов с

выходом в свет первого профессионального журнала в этой области - Transactions

on Software Engineering (Труды по программной инженерии).

Программная инженерия – область компьютерных наук, изучающая вопро-

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

тельности коллективов разработчиков программного обеспечения. Это инженерная

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

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

использования вплоть до снятия с эксплуатации.

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

ПО и производительности труда коллективов проектов путем применения передо-

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

методов эволюции ПО; методов верификации и тестирования ПО; интегрирован-

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

тами; методов оценки качества продуктов, производительности труда и стоимости

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

постоянного совершенствования.

Мы используем понятие «ядро» (в смысле «основная часть» знаний по предмету), а

не «свод» (в смысле набор «упорядоченных текстов» по предмету), как, например, у

С.Орлика в работе [1].

Глава 2 53

Возникновение и высокие темпы развития программной инженерии предо-

пределены несколькими важными факторами:

• накоплением значительного объема знаний в области практического соз-

дания ПО, нуждающихся в систематизации;

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

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

ПО, не обеспеченных рекомендациями по эффективному применению;

• высоким уровнем обнаружения дефектов в ПО несмотря на использова-

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

• не эффективной организацией труда коллективов разработчиков ПО (ме-

неджеров, проектировщиков, программистов, тестировщиков, технологов и др.);

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

тификации и систематизированному ведению (в библиотеках, хранилищах и др.);

• применением реинженерии существующих компонентов как средства их

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

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

момента:

1) программная инженерия – это инженерная дисциплина, суть которой со-

стоит в том, что инженеры (будь то программисты, тестировщики и т.п.) применя-

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

ПО, руководствуясь конкретными стандартами, правилами и методиками. Про-

граммная инженерия «предоставляет» всю необходимую информацию для выбора

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

практических задач программирования ПО на инженерной основе, хотя и не ис-

ключает и творческий, неформальный подход к созданию ПО;

2) программная инженерия охватывает множество аспектов создания ПО,

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

рования) такими процессами, как управление проектом, конфигурацией, качеством

ПО и др., включая оценку результатов труда и затраченных ресурсов. К ключевым

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

планирование и сопровождение. Первый из них (планирование) предполагает ана-

лиз целей и задач разработки, возможностей ее реализации и необходимых для это-

го ресурсов, а второй (сопровождение) - устранение найденных недостатков в сис-

теме и реализацию изменений, обусловленных эволюцией ПО, среды и деятельно-

сти пользователей. Один из метров программной инженерии М.Джексон определил

золотое правило программирования: всякая только что законченная программная

система сразу требует изменений [2].

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

ботку ПО близкой по своей сущности к инженерной деятельности, как она опре-

делена в толковом словаре:

1) инженерия есть применение научных результатов, что позволяет получать

пользу от свойств материалов и источников энергии;

2) инженерия есть деятельность по созданию машин для предоставления по-

лезных услуг.

В программной инженерии, инженеры – это специалисты, выполняющие

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

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

54 Глава 2

вычислительных и программных систем. Знание компьютерной науки необходимо

специалистам в области ПО так же, как знание физики – инженерам-

электронщикам. Если для решения конкретных задач программирования не суще-

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

ния, накопленные ими в процессе конкретных разработок ПО, а также свой опыт

применения соответствующих инструментально-программных средств. Кроме того,

инженеры работают в жестких условиях заключенных контрактов и выполняют

задачи с учетом их ограничений.

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

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

зы. Ф.Брукс считает, что «ученый строит, чтобы научиться, инженер учится, чтобы

строить».

Хотя разработку ПО можно по праву считать инженерной деятельностью, она

имеет важные отличия от традиционной «технической» инженерии:

• традиционные «ветви» инженерии имеют высокую степень специализа-

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

применениях (например, операционные системы, трансляторы);

• объекты традиционной инженерии хорошо определены и манипуляции с

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

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

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

• отдельные готовые решения и изделия в традиционной инженерии клас-

сифицированы и каталогизированы, а в программной инженерии каждое новое ре-

шение и разработка некоторого элемента ПО - это новая проблема, для которой до-

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

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

Приведенные отличия требуют значительных усилий для их нивелирования и

превращения программной инженерии в инженерную специальность.

Мировая компьютерная общественность признала целесообразность и свое-

временность таких усилий. Подтверждением этого является создание ядра

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

родных профессиональных объединений в области информатики. Их главная цель -

проведение работ по преобразованию программной инженерии в специальность,

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

признания в мировом сообществе специалистов.

Сложившаяся практика специализации профессиональной деятельности по-

зволяет считать профессию «зрелой», если для нее существуют:

– система начального обучения специальности;

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

для его практической деятельности;

– лицензирование специалистов, организованное под управлением соответст-

вующих государственных органов;

– системы профессионального повышения квалификации персонала и отсле-

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

циалисты могли выжить в условиях интенсивного развития специальности;

– этический кодекс специалистов;

– профессиональное объединение.

Глава 2 55

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

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

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

ных с информатикой. Сформированы профессиональные организации и объедине-

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

созданием руководства SWEBOK [3], приняли этический Кодекс специалистов по

программной инженерии [4], разработали руководства для обучения программной

инженерии [5–7], а также создали программу обучения Computing Curricula (СС)

2001 [8]. Кроме того, в США работает комитет по сертификации учебных заведе-

ний Computing Accreditation Commission of the Accreditation Board for Engineering

and Technology [6]. Программная инженерия как дисциплина тесно связана со

смежными дисциплинами: компьютерные науки; математика; менеджмент; когни-

тивные науки; управление проектом; телекоммуникации и сети; электротехниче-

ская инженерия и другие инженерные дисциплины.

Таким образом, можно сделать вывод о том, что содержание новой инженер-

ной дисциплины «программная инженерия» сформировано и общепризнано в ми-

ровой практике программирования.

2.2. Ядро знаний по программной инженерии (SWEBOK)

2.2.1. Структура руководства по SWEBOK

В начале 90-х годов мировое компьютерное сообщество пришло к необходи-

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

ных наук и информатики и зафиксировать их в виде ядер знаний.

Для создания ядра знаний по программной инженерии в 1993 году совмест-

ными усилиями ACM (Association for Computing Machinery) и компьютерного со-

общества института инженеров по электронике и электротехнике IEEE (Computer

Society) был образован объединенный координационный комитет по программной

инженерии SWECC (Software Engineering Coordinating Committee). В него вошли

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

Основная задача SWECC - определение множества критериев и норм профес-

сиональной практики программной инженерии, которые могли бы послужить осно-

вой для принятия практических решений при разработке ПО, сертификации про-

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

цесса.

В рамках комитета SWECC были организованы специализированные группы

по следующим направлениям исследований:

1. Определение необходимого ядра знаний и рекомендуемых практических

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

2. Определение норм профессиональной этики и стандартов по программной

инженерии.

3. Определение Программ обучения студентов ВУЗов по специальности.

Руководство по SWEBOK (2004 года) стало результатом работы по первому

направлению [3]. В 1998 был завершен Кодекс этики (как результат работы по вто-

рому направлению) [4], а 2004 году – опубликованы новые рекомендации по подго-

товке программ обучения дисциплине «программная инженерия», разработанные

совместными усилиями IEEE и ACM [5].

56 Глава 2

Ядро знаний SWEBOK составляют знания из десяти различных Областей

знаний, а именно:

1. Программные требования

2. Проектирование (дизайн) ПО

3. Конструирование ПО

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

5. Сопровождение ПО

6. Управление конфигурацией ПО

7. Управление инженерией ПО

8. Процесс инженерии ПО

9. Инструменты и методы инженерии ПО

10. Качество ПО

Каждой Области знаний в руководстве посвящена отдельная глава, структу-

рированная по разделам и рубрикам. Главы завершаются объемными списками ли-

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

щий Ядро знаний. Ее изучение рекомендовано для овладения знаниями в соответ-

ствующей области знаний.

Структура SWEBOK приведена на рисунке 2.1, а разделы областей знаний –

на рисунке 2.2. Особенность руководства по SWEBOK – матричное представление

(пересечение) разделов/подразделов и ссылок на литературу, обеспечивающее бы-

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

ний.

Ядро знаний

Область знаний

Введение

Подраздел

области знаний

Раздел области

знаний

Матрица

"разделы : ссылки"

Список основной

литературы по

Области знаний

Список

стандартов

Рис. 2.1. Структура SWEBOK

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

стику SWEBOK. Мы ограничимся аннотированным изложением основных положе-

ний по каждой из 10 областей знаний и порекомендуем читателям обратиться к

доступным литературным источникам [3, 9-14].