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

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

84 Глава 2

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

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

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

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

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

• развитие команды проекта – повышение квалификации членов команды

проекта и укрепление взаимодействия между ними с целью повышения эффектив-

ности исполнения проекта;

• управление командой проекта – контроль за эффективностью работы ко-

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

менений, направленных на повышение эффективности исполнения проекта.

Область знаний Управление коммуникациями проекта охватывает сле-

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

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

проектной информации:

• планирование коммуникаций – определение потребностей участников

проекта в коммуникации и информации;

• распространение информации — своевременное предоставление инфор-

мации участникам проекта;

• отчетность по исполнению - сбор и распространение информации о вы-

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

таты прогнозирования;

•

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

удовлетворения требований участников проекта и решения возникающих проблем.

Область знаний Управление рисками проекта охватывает процессы, отно-

сящиеся к планированию управления рисками, их идентификации и анализу, реаги-

рованию на риски, мониторингу и управлению рисками проекта. Цель управления

рисками проекта - повышение вероятности возникновения и степени влияния пози-

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

тивных для проекта событий. Процессы управления рисками проекта следующие:

• планирование управления рисками – определение и выполнение операций

по управлению рисками проекта (в соответствии с выбранным подходом);

• идентификация рисков – определения рисков, способных повлиять на

проект, и документирование их характеристик;

• качественный анализ рисков – расположение рисков по приоритетам для

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

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

• количественный анализ рисков – количественный анализ потенциального

влияния идентифицированных рисков на общие цели проекта;

• планирование реагирования на риски – разработка возможных вариантов

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

угроз для достижения целей проекта;

• мониторинг и управление рисками – отслеживание идентифицированных

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

планов реагирования на риски и оценка их эффективности на протяжении жизнен-

ного цикла проекта.

Глава 2 85

Область знаний Управление поставками проекта охватывает процессы за-

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

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

зрения: продавца и покупателя. Согласно условиям контракта организация может

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

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

• планирование закупок и приобретений – определение того, что необхо-

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

• планирование контрактов – оформление в документальном виде требова-

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

определение потенциальных продавцов;

• запрос информации у продавцов – получение информации, предложений

или заявок (в зависимости от поставки) от продавцов;

• выбор продавцов – анализ предложений, отбор потенциальных продавцов

и обсуждение условий контракта с продавцом;

• администрирование контрактов – управление контрактом и взаимоотно-

шениями между покупателем и продавцом; анализ и документирование текущей и

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

действий и обеспечения основы для будущих отношений с продавцом; управление

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

трактными взаимоотношениями со сторонним покупателем проекта;

• закрытие контракта — завершение каждого контракта, включая урегули-

рование всех открытых вопросов, и закрытие каждого контракта, относящегося к

проекту или фазе проекта.

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

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

меняться самостоятельно. Рабочей группой по стандартам WG7 комитета ISO/IEC

JTC1/SC7 предложено модифицировать стандарт ISO/IEC TR 16326:1999 «Guide for

the application of ISO/IEC 12207 to project management» (Руководство по примене-

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

нимость положений PMBOK в программной инженерии [18].

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

SWEBOK и PMBOK

Разработка Руководства к SWEBOK преследовала цели способствовать фор-

мированию согласованного видения дисциплины в международном масштабе; оп-

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

линам - информатике, управлению проектами, математике; охарактеризовать со-

держание дисциплины; обеспечить доступ к «кладезю» знаний по предмету путем

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

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

В работе над Руководством к SWEBOK и отдельным областям знаний при-

нимали участие сотни авторов и рецензентов из 42 стран и это не могло не сказать-

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

ных глав, так и «насквозь» по главам. Так, термин «качество» встречается в руко-

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

86 Глава 2

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

ниях, например, «измерения качества», «качество измерений» и т.п.

Собственно проблематика качества ПО выделена в самостоятельную область

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

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

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

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

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

качества.

Глава 2.Требования к ПО

2. Процесс требований

2.4. Качество процесса и улучшение

Глава 3. Проектирование ПО

4. Анализ и оценивание качества проекта

4.1. Атрибуты качества

4.2. Приемы анализа и оценивания качества

Глава 4. Конструирование ПО

3. Практические соображения

3.5. Качество конструкции

Глава 6. Сопровождение ПО

3. Процесс сопровождения

3.2. Деятельность по сопровождению

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

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

2. Планирование проекта ПО

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

Глава 9. Процесс программной инженерии

4. Измерение процесса и продукта

4.1. Измерение процесса

4.1.3. Измерение качества

4.2. Качество результатов измерений

Глава 10. Инструменты и методы программной инженерии

1. Инструменты программной инженерии

1.9. Инструменты качества ПО

Глава 12. Качество ПО

1. Основы качества ПО

1.2. Ценность (значимость) и стоимость качества

1.3. Модели и характеристики качества

1.3.1. Качество процесса программной инженерии

1.3.2. Качество продукта ПО

1.4. Улучшение качества

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

2.1. Гарантия качества ПО

3. Практические соображения

3.1. Требования к качеству ПО

3.3. Приемы управления качеством ПО

3.4. Измерение качества ПО

Рис. 2.4. Отражение аспектов качества в SWEBOK

Глава 2 87

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

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

В SWEBOK вопросы управления проектами рассматриваются в области знаний

«Управление инженерией ПО», причем таким основополагающим проблемам, как

управление стоимостью (затратами) и продолжительностью проекта, а также управ-

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

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

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

ний PMBOK.

Действительно в PMBOK, особенно в текущей версии 2004-го года, все вопросы

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

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

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

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

ния, которые она (методология) предлагает разработчикам ПО.

Поэтому информация в PMBOK, касающаяся упомянутых аспектов управления,

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

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

Анализ SWEBOK и PMBOK, а также программ обучения инженеров по каче-

ству и надежности ПО (software quality and reliability engineers) за рубежом показы-

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

SWEBOK и PMBOK (безусловно, с привлечением элементов системного анализа,

теории вероятности, математической статистики, теории прогнозирования и изме-

рений).

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

рисунке 2.5.

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

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

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

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

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

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

2.5. Парадигмы и стили программирования

2.5.1. Классификация парадигм и стилей программирования

В Руководстве по подготовке учебных программ по программной инженерии

говорится [5]: «общее заблуждение по поводу программной инженерии состоит в

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

ванная на процесс разработки как таковой … В этом контексте, компетентность

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

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

ти программирования…». Однако, только «благодаря фундаменту программирова-

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

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

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

и инженерии качества.

88 Глава 2

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

Управление интеграцией проекта

Управление содержанием проекта

Упр. продолжительностью

Упр. стоимостью

Упр. качеством

Упр. трудовыми ресурсами

Упр. коммуникацией

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

Упр. закупками / поставками

PMBOK

SWEBOK

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

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

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

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

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

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

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

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

Качество ПО

Процесс инженерии требований

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

Анализ требований

Спецификация требований

Проверка требований

Ядро знаний в области качества

Контроль и гарантирование качества (SQA)

Определение требований к качеству

Планирование качества

Процессы ЖЦ ПС и модели ЖЦ

Концепции качества ПС

Стандарты, методы, инструменты качества

Измерение и прогнозирование качества ПС

Модели и метрики качества

Прогнозирование размера ПС

Прогнозирование затрат на разработку ПС

Верификация и валидация ПС (V&V)

Инспекции и другие методы V&V

Тестирование и испытания ПС

Парадигмы измерений

Прогнозирование дефектов в ПС

Оценивание качества ПС

Оценивание качества программных продуктов

Оценивание мощности процессов ЖЦ ПС

Модели зрелости организаций-разработчиков

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

Совершенствование процессов ЖЦ ПС

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

Система качества ПС и сертификация

Процессы и методы проверки в ЖЦ ПС

Сертификация по стандартам ISO 9000

Структура и архитектура

Анализ и оценка качества проекта

Нотации проектирования

Стратегии и методы

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

Приемы тестирования

Метрики тестирования

Процесс тестирования

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

Процесс сопровождения

Приемы сопровождения

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

Идентификация конфигурации

Контроль, учет состояния

Управление выпуском и поставка ПО

Аудит конфигурации

Инициирование и рамки проекта

Планирование проекта

Выполнение проекта

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

Закрытие проекта

Измерения в инженерии ПО

Реализация и изменение процесса

Определение процесса

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

Измерения процесса и продукта

Инструменты инженерии ПО

Методы инженерии ПО

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

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

Рис. 2.5. Связь ядра знаний в области качества ПС с SWEBOK и PMBOK

Глава 2 89

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

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

лемых или не приемлемых для определенных парадигм.

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

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

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

ментов измерения свойств ПС, а также методов оценки размера и сложности, клас-

сификации дефектов и построения таксономии рисков отказа ПС.

Существуют разные подходы к классификации парадигм, например:

– парадигмы прикладного (систематического) и теоретического програм-

мирования [19];

– парадигмы основные (Императивного, Функционального, Алгебраическо-

го и Логического программирования) и высшие (по уровню) (Параллельного, Объ-

ектно-ориентированного, Агентного программирования) [20];

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

рующее программирование и др. [21];

– парадигмы, отличающиеся способом декомпозиции задачи (Императив-

ного, Декларативного, Объектно-ориентированного, Сценарного программирова-

ния, Программирования в ограничениях) [22];

– парадигмы (стили), отличающиеся глубиной и общностью проработки

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

(Машинно-ориентированное, Системное, Логическое, Трансформационное, Высо-

копроизводительное /параллельное программирование) [19] и другие.

Текущая версия упомянутого Руководства 2004-го года рекомендует вклю-

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

мирования (курс CS1011 «Programming fundamentals»), объектно-

ориентированного программирования (курс CS102I «The Object-Oriented

Paradigm»), а также событийного программирования (event-based programming).

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

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

ненных языков программирования. Именно на эти стили программирования в ос-

новном и ориентируется инженерия качества на современном уровне ее развития.

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

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

вующих парадигмах программирования.

В работе [23] выделены, как основные, парадигмы процедурного, функцио-

нального, алгебраического и логического программирования, различающиеся спо-

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

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

лектуальных программных композиций.

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

вующих парадигм. Часть из них схематически представлена на рисунке 2.6 и рас-

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

заны в блоках пунктирным контуром.

90 Глава 2

Императивное Декларативное

Неструктурное

Процедурное

Структурное

Объектно-

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

Функциональное

Логическое

В ограничениях

Доменно-

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

(HTML, SQL)

Основанное на

классах (Smalltalk,

C++, Delphi)

Основанное на

прототипах

(Java Script)

Основанное на

посылке сообщений

(messa-passing)

Прикладное программирование

Аспектно

(контекстно-)

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

Компонентно-

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

Генерирующее

Инсерционное

Алгебраическое

Экспликативное

Композиционное

Доказательное

Модульное

Сборочное

Агентное

Параллельное

Управляемое

событиями

Обобщенное

программирование

(generic) в разных

парадигмах

Визуальное (visual)

Управляемое

потоком данных

(dataflow)

Метапрограмми-

рование по шаблону

(meta-programming)

Основанное на

правилах (rule-based)

Распределенное

(distributed)

Концептно-

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

(concept-oriented)

Сценарное

программирование

Автоматное

программирование

Рефлективное

(reflective)

Сервисно-

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

программирование

Теоретическое

программирование

Новое поколение

парадигм

Таблично-

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

(table-oriented)

Субъектно-

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

(subject-oriented)

Рис. 2.6. Основные парадигмы и стили программирования

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

Императивное программирование основано на машине Тьюринга-Поста - аб-

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

рукций (команд) программы, которая, таким образом, переходит из одного состоя-

ния в другое. Существует понятие «текущего шага исполнения» и «текущего со-

стояния», которое меняется с течением времени.

Поскольку практически все современные компьютеры ориентированы на по-

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

ет в эффективности реализации прикладных задач, для которых очень важна ско-

рость исполнения (решения).

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

це 2.3.

Глава 2 91

Таблица 2.3. Стили императивного программирования

Стиль Описание Примечания

Неструк-

турное

програм-

мирова-

ние

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

ным непрерывным блоком. Переходы

к нужным секциям программы выпол-

няются с помощью условных операто-

ров и операторов перехода (обычно,

goto или jump) без ограничений.

Примеры языков: языки скриптов

(bat-файлы), Fortran, Basic, Ас-

семблеры

Проблемы обеспечения качества:

образование «спагетти-кода»,

сложность верификации кода.

Проце-

дурное

програм-

мирова-

ние

Иногда используется как синоним им-

перативного программирования (со-

стояние процедуры определяется зна-

чением множества ее переменных в

определенный момент времени). Бази-

руется на концепции вызова процедур

(подпрограмм, функций, методов).

Любая процедура может быть вызвана

в любой точке в ходе выполнения про-

граммы.

Примеры языков: Algol, Ada, Basic,

C, Cobol, Fortran, Pascal, PL/1, Mat-

lab, многопарадигменные языки.

Проблемы обеспечения качества:

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

вание кода (без дублирования),

улучшается прослеживаемость

кода и сопровождаемость про-

грамм. Есть методы оценки слож-

ности программ (глава 5).

Модуль-

ное и

сбороч-

ное про-

грамми-

рование

[24, 25]

Модульная организация кода при про-

цедурном программировании. Строго

определенные механизмы ввода-

вывода данных – через аргументы (на

входе) и возвращаемые значения (на

выходе) процедуры. Определение сфе-

ры действия переменных. Возмож-

ность автономной реализации и хране-

ния кода (в библиотеках модулей), а

также сборки программ из модулей.

Примеры языков: языки импера-

тивного и объектно-ориенти-

рованного программирования.

Проблемы обеспечения качества:

облегчается тестирование и по-

вторное использование кода; до-

пускается распределенная разра-

ботка программ (разработка авто-

номных модулей отдельными про-

граммистами).

Струк-

турное

програм-

мирова-

ние

Направление процедурного програм-

мирования, особенности которого –

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

разделения на секции (блоки) одного

из видов: последовательность, ветвле-

ние, цикл. Базовые конструкции могут

быть вложены друг в друга произволь-

ным образом, но никаких других

средств управления последовательно-

стью выполнения операций нет.

Ограничение - сокращение (запрет)

использования goto; одна точка входа

в секцию (блок), но несколько воз-

можных точек выхода.

Часто ассоциируется с разработкой

«сверху-вниз».

Структурирование данных. Использо-

вание абстрактных типов данных.

Примеры языков: во все современ-

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

граммирования введены элементы

и ограничения структурирования,

например, Pascal, Ada, Fortran, Co-

bol, Basic, С.

Проблемы обеспечения качества:

структурирование снижает слож-

ность программы, облегчает ее

верификацию и внесение измене-

ний, локализация обработки ис-

ключительных ситуаций в отдель-

ных блоках облегчает отладку и

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

Разработка с использованием «за-

глушек» облегчает тестирование и

локализацию дефектов.

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

Стили программирования, обычно связываемые с итеративной парадигмой,

основываются на концепции организации «внутреннего» потока управления вы-

92 Глава 2

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

Однако, существует множество задач, решаемых в реальном времени (в медицине,

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

рактивном режиме, ожидающих, принимающих и обрабатывающих команды и на-

боры данных извне. Для эффективной реализации таких задач используются стили

событийно-управляемого (или событийного) программирования, основанные на

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

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

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

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

файла в каталоге, щелчок на кнопке мыши, наступление заданного момента време-

ни или другое), и запускается функция-триггер для обработки очередного события.

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

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

возможному событию.

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

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

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

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

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

Событийное программирование (event-oriented, event-based или event-driven

programming) – наиболее распространенная современная парадигма прикладного

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

разработки программ (в частности, Windows).

Особенности инженерии качества программ, разработанных с применением

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

ванных на операционных (сценарных) профилях программ (глава 7), а также мето-

дов прогнозирования размера, основанных на подходе FPA (глава 8).

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

сованное (параллельное) программирование.

Согласованное программирование и параллельные вычисления. Естествен-

ный резерв повышения производительности компьютеров — распараллеливание

потока команд или потока данных. Распараллеливание данных подразумевает при-

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

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

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

Достаточно быстро были разработаны супер-ЭВМ, имеющие «векторную»

или «матричную» архитектуру процессоров (транспьютеров), автономных, но спо-

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

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

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

ры [26, 27].

Может быть обеспечен параллелизм на двух уровнях: параллелизм уровня

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

чение или процессы вычислительной модели) или структурных (последовательных

или параллельных). Когда процесс выполняет инструкцию «Принять значение (из

канала)», он входит в состояние ожидания, пока канал пуст. Как только в канале

Глава 2 93

появляется значение, процесс его считывает и продолжает работу. В системе па-

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

Активное внедрение новых аппаратных архитектур потребовало смены пара-

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

согласованному программированию (concurrent programming), в частности, парал-

лельному программированию (parallel programming или параллельным вычислениям

- parallel computing), связанному с параллельными потоками, порождением и обра-

боткой асинхронных событий и др.

Согласованное (параллельное) программирование - это программирование в

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

(нескольких процессоров или многоядерного процессора).

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

языки, как, например, язык высокого уровня Occam (неразрывно связанный с

транспьютерами), а также современные библиотеки и системы параллельного про-

граммирования PVM, LAM, CHMP и др. Три основных подхода к реализации этих

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

базируется на концепции обмена сообщениями, второй — на использовании разде-

ляемой памяти, третий опирается на стандарт POSIX и объединяет оба подхода.

Наиболее известной реализацией первого подхода является спецификация

MPI (Message Passing Interface) для языков C и Fortran, а второго подхода - специ-

фикация OpenMP для Fortran, C, C++. OpenMP — это набор специальных директив

компилятору (pragma), а также библиотечных функций и переменных среды. Ком-

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

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

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

Поддержка спецификации OpenMP обеспечена во всех компиляторах Intel, начиная

с шестой версии, в Microsoft C и C++, начиная с Visual Studio 2005, а также в GCC.

В третьем подходе используется спецификация POSIX (Portable Operating System

interface for unIX), введенная как международный стандарт ISO/IEC 9945-1:1990. В

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

общениями (аналогично MPI) или разделяемой памяти (как в OpenMP). Естествен-

но, в POSIX допустима и любая комбинация этих методов.

В работе [26] отмечается, что многоядерные процессоры – это единственное

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

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

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

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

дальнейшего наращивания размеров кэш-памяти процессоров остался лишь не-

большой зазор для развития. Как следствие, старый добрый мир остался в про-

шлом… Ведущий эксперт корпорации Microsoft Херб Саттер в статье «Программ-

ное обеспечение и революция согласования» (ACM QUEUE, September 2005) назы-

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

распространение объектно-ориентированного программирования в начале 90-х го-

дов. Тогда причиной перемен стало усложнение программных систем, нынешняя

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

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