otvety_118

91

С учетом имеющихся инструментальных средств класс TXSet может быть построен на основе класса Array из библиотеки CLASSLIB, т.е. это множество может быть интерпретировано массивом. Массив представляет собой упорядоченную совокупность однотипных элементов, в то же время данные могут принадлежать различным типам и каждому тип соответствует свой набор характеристик. Это противоречие можно преодолеть, если элементами массива TXSet будут указатели на экземпляры данных.

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

Пусть требуется обеспечить возможность использования числовых скалярных данных и массивов (векторов и прямоугольных матриц), а также данных типа строк и массива строк. Естественно определить для каждого такого типа свой класс: TDScal, TDArray, TDString, TDStringArray. В каждом из этих классов должно быть поле идентификатора данного ident, поле описания данного head и, возможно, поле flags, представляющее собой набор битов, дополняющих описание данного. Может оказаться удобным иметь и поля, содержащие количество знаков при представлении скаляра или элементов массивов (width) и количество цифр в дробной части для представления чисел (dec). Все эти данные можно объединить в классе TData, базовом для остальных классов данных. Таким образом, вместо одного класса ―данное‖, выделенного на этапе анализа, появилось пять классов. После этого следует вернуться к этапу анализа и оформить рабочие документы анализа для новых классов.

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

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

Таким образом, процесс объектно-ориентированного проектирования состоит из циклического выполнения четырех основных шагов:

-Определение классов и объектов на определенном уровне абстракции.

-Определение семантики классов.

-Определение (идентификация) связей между классами и объектами.

-Реализация классов.

На каждом повторении этого цикла уточняются описания классов и перерабатываются проектные документы.

70. Объектно-ориентированный анализ и проектирование

Целью объектно-ориентированного анализа является трансформация функциональных требований к ПО в предварительный системный проект и создание стабильной основы архитектуры системы.

Объектно-ориентированный анализ включает два вида деятельности:

архитектурный анализ;

анализ вариантов использования.

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

утверждение общих стандартов (соглашений) моделирования и документирования системы;

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

формирование набора основных абстракций предметной области (классов

анализа);

формирование начального представления архитектурных уровней. Соглашения моделирования определяют:

используемые диаграммы и элементы модели;

правила их применения;

соглашения по именованию элементов модели;

организацию модели (пакеты).

Архитектурные механизмы отражают нефункциональные требования к системе (надежность, безопасность, хранение данных в конкретной среде, интерфейсы с внешними

92

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

Идентификация основных абстракций заключается в определении набора классов системы (классов анализа) на основе описания предметной области и спецификации требований к системе (в частности, глоссария проекта).

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

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

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

промежуточный (middleware), куда входят платформо-независимые сервисы;

системный, содержащий компоненты вычислительной и сетевой инфраструктуры. Анализ вариантов использования выполняется проектировщиками и включает в себя:

идентификацию классов, участвующих в реализации потоков событий;

определение обязанностей классов;

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

унификацию классов анализа.

В потоках событий варианта использования выявляются классы трех типов:

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

объектами;

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

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

системе.

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

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

Обязанности каждого класса определяются, исходя из сообщений на диаграммах взаимодействия, и документируются в классах в виде «операций анализа». В процессе проектирования каждая «операция анализа» преобразуется в одну или более операций класса, которые в дальнейшем будут реализованы в коде системы.

При построении диаграмм взаимодействия возникают проблемы правильного распределения обязанностей между классами. Для их решения существует ряд образцов: Information Expert, Creator, Low Coupling, High Cohesion.

Атрибуты классов анализа определяются, исходя из знаний о предметной области, требований к системе, глоссария и бизнес-модели. В процессе анализа атрибуты определяются только для классов-сущностей. Связи между классами определяются в два этапа. Начальный набор связей определяется на основе анализа кооперативных диаграмм. Если два объекта обмениваются сообщениями, между ними должна быть ассоциация. На втором этапе исходя из знаний о предметной области создаются ассоциации между классами-сущностями.

Унификация классов анализа заключается в проверке выполнения следующих условий:

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

системе;

классы с одинаковым поведением, или представляющие одно и то же явление, должны объединяться;

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

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

93

71. Объектно-ориентированный подход к проектированию ПО. Объектная модель.

СУЩНОСТЬ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА Принципиальное различие между структурным и объектно-ориентированным подходом

заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. Понятие "объект" впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектноориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal. На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход "сущность-связь".

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными се элементами являются:

•абстрагирование (abstraction);

•инкапсуляция (encapsulation);

•модульность (modularity);

•иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

•типизация (typing)',

•параллелизм (concurrency)',

•устойчивость (persistence).

Абстрагирование — это выделение существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы относительно дальнейшего рассмотрения и анализа. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности его поведения от деталей их реализации. Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного проектирования.

Инкапсуляция — это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого класса, скрыты от внешней среды. Абстрагирование и инкапсуляция являются взаимодополняющими операциями: абстрагирование фокусирует внимание на внешних особенностях объекта, а инкапсуляция (или, иначе, ограничение доступа) не позволяет объектам-пользователям различать внутреннее устройство объекта.

Объектно-ориентированный подход

Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд вутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями.

Иерархия — это ранжированная или упорядоченная система абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу). Примерами иерархии классов являются простое и множественное

94

наследование (один класс использует структурную или функциональную часть соответственно одного или нескольких других классов), а иерархии объектов - агрегация.

Типизация — это ограничение, накладываемое на класс объектов и препятствующее взаимозаменяемости различных классов (или сильно сужающее ее возможность). Типизация позволяет защититься от использования объектов одного класса вместо другого или по крайней мере управлять таким использованием.

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

Устойчивость — свойство объекта существовать но времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).

72.Объектно-ориентированный подход к проектированию ПО. Виды отношений между классами

Основные понятия объектно-ориентированного подхода - объект и класс.

Объект определяется как осязаемая реальность (tangible entity) — предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины "экземпляр класса" и "объект'' являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот относительно изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность — это свойства объекта, отличающие его от всех других объектов.

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

Класс — это множество объектов, связанных общностью структуры и поведения. Любой объект является экземпляром класса. Определение классов и объектов — одна из самых сложных задач объектно-ориентированного проектирования.

…

73.Макетирование информационной системы

Практика показывает, что требования пользователей информационной системы не вполне определены, и поэтому необходимо ориентироваться на постоянные изменения требований к системе, учесть которые можно только при динамичной спецификации этих требований. Наиболее приемлемым может быть следующий подход. Требования к системе формируются не сразу, а в процессе разработки функционального макета системы. Макет системы создается на основе той минимальной информации, которую могут сообщить пользователи. После получения замечаний и их устранения, макет системы снова предъявляется пользователям. Это дает возможность конкретизировать проблемы, возникающие между разработчиками и пользователями, существенно сокращает задержку во времени между формулировкой требований и первой демонстрацией действующей системы. Это обеспечивает эффективный контроль проекта системы на всех этапах ее жизненного цикла.

Использование макета согласуется с информационно-логическим подходом к построению модели базы данных, который основывается на четком разделении концептуальной модели предметной области.(включая модель информационных потребностей пользователей) и датологической модели предметной области ( моделью обработки данных). В этом случае спецификация макета завершается разработкой концептуальной модели предметной области. После завершения макетирования принимается решение в отношении построения модели обработки данных.

74. Объектно-ориентированное тестирование

95

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

Методы тестирования структурных программ достаточно давно и хорошо проработаны ( тем не менее даже для структурных программ тестирование не является полностью закрытой темой ). Объектно-ориентированные программы неизбежно добавляют специфические проблемы к технологии тестирования. Эти проблемы определяются двумя основными аспектами [11]:

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

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

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

идля структурных. Преимущества этого подхода, выражающиеся в возможности повторного использования, приводят к необходимости более тщательного тестирования. Классы обычно создаются заранее с возможностью использования в различных задачах, а следовательно одна задача не может полностью обеспечить тестирования взаимодействия методов поведения классов.

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

Инкапсуляция создает проблему видимости данных, так как они доступны только через операции. В процессе тестирования это может создать определенные проблемы с выводом значений.

Наследование ставит вопросы о повторении тестирования наследуемых операций. Допустим операция А принадлежит базовому классу, и она протестирована. Операция В принадлежит производному классу и вызывает операцию А. Должна ли операция А тестироваться повторно?

Полиморфизм приводит к неоднозначности с вызовом операций, которая может быть разрешена только на этапе выполнения. Следовательно заранее построить и спланировать набор тестов становится просто невозможным.

Объектно-ориентированная технология привносит свои особенности в процесс тестирования систем. Формулируется несколько вопросов, которые необходимо разрешить для успешного проведения тестирования:

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

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

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

Как следует тестировать интеграцию классов и какие стратегии тестирования

применять.

Решение подобных вопросов выполняется путем разработки новых подходов и модернизации старых, специально для тестирования объектно-ориентированных систем.

75. Стандарты в области проектирования информационных систем

Существует международный стандарт, регламентирующий жизненный цикл ин формационных систем — ISO/IEC 12207.

ISO — International Organization of Standardization (международная организация по стандартизации). IEC— International Electrotechnical Commission (международная комиссия по электротехнике).

Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы.

96

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

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

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

организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).

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

…

76. Модели качества процессов конструирования

ISO/IEC определяет три связанных модели качества программного обеспечения (ISO 9126-01 Software Engineering - Product Quality, Part 1: Quality Model) – внутреннее качество, внешнее качество и качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного обеспечения (ISO 14598-98 Software Product Evaluation).

Модели качества в современном понимании строятся на управлении качеством и обеспечении качества процессов, в частности, программной инженерии. Качество процесса напрямую влияет на характеристики качества продукта, которые, в свою очередь, отражаются в восприятии качества продукта в процессе эксплуатации со стороны заказчика.

Существует два основных подхода в области качества программного обеспечения:

Европейский подход TickIT, рассмотривающий общую системы менеджмента качества ISO 9001 в приложении к программным проектам и представленный, также, в виде специальных рекомендаций ISO 90003-04.

Американский подход CMMI предоставляющий рекомендации по совершенствованию (повышению зрелости) отдельных процессов.

4.2.2CMM/CMMI

Наверное, самым именитым стандартом качества следует считать Capability Maturity Model (CMM) – модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше – основные его положения были опубликованы еще в 1986 г.

Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания ПО. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что дефакто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA).

Таблица 1. Уровни модели CMM

97

^ Название уровня	Ключевые области процесса
Начальный	Если организация находится на этом уровне, то ключевых областей
	процессов для нее не предусмотрено
Повторяющийся	Управление программными конфигурациями. Обеспечение
	качества программных продуктов. Управление контрактами
	подрядчиков. Контроль за ходом проектов. Планирование
	программных проектов. Управление требованиями
Определенный	Экспертные оценки. Координация взаимодействий проектных
	групп. Инженерия программного продукта. Комплексный
	менеджмент ПО. Программа обучения персонала. Определение
	организационного процесса. Область действия организационного
	процесса
Управляемый	Менеджмент качества ПО. Управление процессом на основе
	количественных методов
Оптимизируемый	Управление изменением процесса. Управление технологическими
	изменениями. Предотвращение дефектов

Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (табл. 2). Притом он получил новое имя – SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

Таблица 2. Развитие стандартов CMM

^ Название	Описание
стандарта

98

System Engineering	Ориентирован на вопросы системного инжиниринга – разработку
CMM (SE-CMM)	продуктов (анализ требований, проектирование систем продукта и их
	интеграция) и их производство (планирование производственных линий
	и функционирование)
Trusted CMM (T-	Предназначен для обслуживания чувствительных и закрытых
CMM)	программных систем, которые требуют гарантии высокого качества ПО
System Security	Сфокусирован на аспектах безопасности программной инженерии,
Engineering CMM	обеспечивает безопасный процесс разработки, в том числе и
(SSE-CMM)	безопасность членов команды создателей
People CMM (P-	Рассматривает вопросы развития персонала в софтверных организациях
CMM)
Software Acquisition	Охватывает вопросы приобретения программных продуктов у внешних
CMM (SA-CMM)	организаций
		Integrated Product
		Development CMM (IPD-
		CMM)

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

Однако практическое применение стандартов серии CMM показало, что они не обеспечивают безоговорочного успеха в разработке ПС. Эти стандарты не были хорошо согласованы между собой – одновременное внедрение различных модификаций CMM могло оказаться достаточно сложной задачей и приводило в недоумение специалистов организаций, которые с этим сталкивались.

Также существенная проблема CMM состоит в необходимости «выравнивания» всех процессов. Если организация пытается сертифицироваться на определенный уровень, то она должна обеспечить соответствующий уровень для всех своих процессов. Даже если специфика, методология или особенности разработки не располагают к выполнению определенных процессов, сертификация это требует.

Еще одна проблема вызвана тем положением, которое заняли стандарты CMM в современной индустрии ПС. Поскольку организация, обладающая высоким уровнем в соответствии с CMM, должна обеспечивать более высокие показатели программных продуктов по сравнению с теми, кто сертифицирован на низших уровнях, то стандарт стал применяться в качестве критерия отбора для участия в тендерах на разработку ПС или в аутсорсинговых проектах. Спрос на сертифицированные организации породил предложение по «быстрой и безболезненной сертификации».

Подобная ситуация стала возможной благодаря недостаткам процесса сертификации. Сертификации подлежит не вся организация в целом, а только определенный проект. Ничто не мешает организации создать «образцово-показательный» проект, выполняемый с учетом всех требований высоких уровней стандарта CMM, получить соответствующий уровень сертификации и заявить о том, что все продукты отвечают такому-то уровню стандарта.

99

Разрешить большинство проблем CMM призван новый стандарт SEI – Capability Maturity Model Integrated (CMMI) – Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления – классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA). В табл. 3 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

Таблица 3. Соответствие уровней CMM/CMMI

№уровня	Уровень зрелости	Уровень зрелости	^ Уровень возможностей
	CMM	многоуровневого	непрерывного представления
		представления CMMI	CMMI
0	–	–	Незавершенный
1	Начальный	Начальный	Выполнимый
2	Повторяющийся	Управляемый	Управляемый
3	Определенный	Определенный	Определенный
4	Управляемый	Управляемый количественно	Управляемый количественно
5	Оптимизируемый	Оптимизируемый	Оптимизируемый

SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, вводя новые классы, позволяющие сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO. Однако факт остается фактом: в современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.

4.2.3TickIT

TickIT – схема сертификации систем менеджмента качества ИТ–компаний на основе стандартов ISO серии 9000, предложенная группой ведущих фирм и некоммерческих организаций Великобритании, работающих в области информатики.

Стандарты ISO серии 9000 – обширная и наиболее распространенная во всем мире серия стандартов качества. Они охватывают множество отраслей современной индустрии и

100

периодически обновляются.

Изначально стандарты ISO серии 9000 слабо учитывали специфику отрасли ПО и были больше ориентированы на производственную сферу. Однако в конце 1980-х годов был выпущен первый ориентированный на области разработки ПО стандарт, получивший название ISO 9000- 3:1997. Несмотря на то, что ISO 9000-3 оперировал терминологией, которая используется при разработке ПО, и рассматривал характерные для программной индустрии вопросы, он являлся не более чем расширенным вариантом ISO 9001:1994, а потому не всегда соответствовал специфике программных проектов.

Сегодня на смену ISO 9000-3 пришел стандарт ISO/IEC 90003:2004, который, в свою очередь, является проекцией промышленного стандарта ISO 9001:2000 на программную индустрию. По сравнению с предыдущим он гораздо более приспособлен к специфике отрасли, в частности, ссылается на модели жизненного цикла программных систем и детально рассматривает вопросы, характерные для разработки ПО. Однако стандарт ISO 90003:2004 – это стандарт обеспечения качества и не может быть использован для оценки уровня зрелости и предсказания результата программного проекта. В таких случаях прибегают к стандарту ISO/IEC 15504:2004. «Информационные технологии. Оценка процессов» (в 5 частях). Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI. Его текущая версия предусматривает шесть уровней возможностей (от нулевого до пятого), которые соответствуют уровням возможностей непрерывного представления стандарта CMMI (табл. 4).

Таблица 4. Уровни CMMI (2004)

№ уровня	Название уровня возможностей	Название уровня возможностей
	стандарта ISO/IEC 15504	непрерывного представления CMMI
Незавершенный			0
ВыполнимыйНезавершенный					1
УправляемыйВыполнимый				2
ОпределенныйУправляемый					3
Управляемый количественноУстановленный					4
ОптимизируемыйПредсказуемый						5

Оптимизируемый

Следует отметить, что в целом стандарты ISO/IEC 15504 и CMMI взаимозаменяемы, в частности, для CMMI предусматривается режим сертификации, в соответствии с которым одновременно проводится и сертификация по ISO/IEC 15504.

Качество программного продукта регламентирует стандарт ISO/IEC 9126, состоящий из