Руководства по качеству информационная технология - Большая энциклопедия инструкций и руководств

ГОСТ Р ИСО/МЭК 9126-93

Группа П85

ОКСТУ 4002

Дата введения 1994-07-01

1 ПОДГОТОВЛЕН И ВНЕСЕН Техническим комитетом по стандартизации (TK 22) «Информационная технология»

2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 28.12.93 N 267

Стандарт подготовлен на основе применения аутентичного текста международного стандарта ИСО/МЭК 9126-91 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению»

3 ВВЕДЕН ВПЕРВЫЕ

1 ОБЛАСТЬ ПРИМЕНЕНИЯ

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

Настоящий стандарт не определяет подхарактеристики (комплексные показатели) и показатели, а также методы измерения, ранжирования и оценки. Данный стандарт придерживается определения качества по ИСО 8402.

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

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

Эти характеристики могут применяться к любому виду программного обеспечения, включая программы ЭВМ и данные, входящие в программно-технические средства (встроенные программы).

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

2 НОРМАТИВНЫЕ ССЫЛКИ

В настоящем стандарте использованы ссылки на следующие стандарты:

ИСО/МЭК 2382-20-90 «Информационная технология. Словарь. Часть 20: Разработка системы».

ИСО 8402-86 «Качество. Словарь».

Примечание — До прямого применения данных международных стандартов в качестве Государственных стандартов Российской Федерации они могут быть получены по запросам из ВНИИКИ Госстандарта России.

3 ОПРЕДЕЛЕНИЯ

В настоящем стандарте применяются следующие термины.

3.1 Оценка (assessment) — действие по применению конкретного задокументированного критерия оценки к конкретному программному модулю, пакету или продукции с целью обусловленной приемки или выпуска программного модуля, пакета или продукции.

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

Примечание — Примеры признаков включают длину маршрута, модульность, структуру программы и комментарии.

3.3 Программно-аппаратные средства (firmware) — технические средства, содержащие компьютерную программу и данные, которые не могут изменяться средствами пользователя. Компьютерная программа и данные, входящие в программно-аппаратные средства, классифицируются как программное обеспечение; схемы, содержащие компьютерную программу и данные, классифицируются как технические средства.

3.4 Уровень качества функционирования (level of performance) — степень, в которой удовлетворяются потребности, представленные конкретным набором значений для характеристик качества.

3.5 Измерение (measurement) — действие по применению показателя качества программного обеспечения к конкретной программной продукции.

3.6 Качество (quality) — весь объем признаков и характеристик продукции или услуги, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ИСО 8402).

Примечание — В сфере контракта потребности определены, тогда как в других сферах предполагаемые потребности должны быть установлены и определены (ИСО 8402, примечание 1).

3.7 Ранжирование (рейтинг) (rating) — действие по отнесению измеренного значения к соответствующему уровню ранжирования. Используется для определения уровня ранжирования программного обеспечения по конкретной характеристике качества.

Уровень ранжирования (rating level) — диапазон значений в масштабе, позволяющем классифицировать (ранжировать) программное обеспечение в соответствии с установленными или предполагаемыми потребностями. Соответствующие уровни ранжирования могут быть связаны с различными представлениями о качестве, то есть для пользователей, руководителей или разработчиков. Данные уровни называются уровнями ранжирования.

Примечание — Данные уровни ранжирования отличны от «классов», определенных ИСО 8402.

3.9 Программное обеспечение (software) — программы, процедуры, правила и любая соответствующая документация, относящиеся к работе вычислительной системы.

3.10 Программная продукция (sofwarе product) — программный объект, предназначенный для поставки пользователю.

3.11 Качество программного обеспечения (software quality) — весь объем признаков и характеристик программной продукции, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.

3.12 Критерии оценки качества программного обеспечения (software quality assessment criteria) — набор определенных и задокументированных правил и условий, которые используются для решения о приемлемости общего качества конкретной программной продукции. Качество представляется набором установленных уровней, связанных с программной продукцией.

3.13 Характеристики качества программного обеспечения (software quality characteristics) — набор свойств (атрибутов) программной продукции, по которым се качество описывается и оценивается. Характеристики качества программного обеспечения могут быть уточнены на множестве уровней комплексных показателей (подхарактеристик).

3.14 Метрика качества программного обеспечения (software quality metric) — количественный масштаб и метод, которые могут быть использованы для определения значения признака, принятого для конкретной программной продукции.

4. ХАРАКТЕРИСТИКИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

4.1 Функциональные возможности (Functionality)

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

Примечания

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

2 В данной характеристике для установленных и предполагаемых потребностей учитывают примечание к определению качества (см. 3.6).

4.2 Надежность (Reliability)

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

Примечания

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

2 В определении ИСО 8402 «надежность» — «способность элемента выполнять требуемую функцию». В настоящем стандарте функциональная возможность является только одной из характеристик качества программного обеспечения. Поэтому определение надежности расширено до «сохранения своего уровня качества функционирования» вместо «выполнения требуемой функции» (см. также 3.4).

4.3 Практичность (Usability)

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

Примечания

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

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

4.4 Эффективность (Efficiences)

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

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

4.5 Сопровождаемость (Maintainability)

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

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

4.6 Мобильность (Portability)

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

Примечание — Окружающая обстановка может включать организационное, техническое или программное окружение.

5 РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ХАРАКТЕРИСТИК КАЧЕСТВА

5.1 Применяемость

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

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

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

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

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

— оценивание программного обеспечения перед приемкой.

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

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

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

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

Важность каждой характеристики качества также меняется в зависимости от принятых точек зрения.

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

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

5.2.1 Представление пользователя

Определение качества по ИСО 8402 отражает представление пользователя так же, как и характеристики, определенные в настоящем стандарте.

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

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

— Имеются ли требуемые функции в программном обеспечении?

— Насколько надежно программное обеспечение?

— Насколько эффективно программное обеспечение?

— Является ли программное обеспечение удобным для использования?

— Насколько просто переносится программное обеспечение в другую среду?

5.2.2 Представление разработчика

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

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

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

5.2.3 Представление руководителя

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

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

5.3 Модель процесса оценивания

Схема 1 отражает основные этапы, требуемые для оценивания качества программного обеспечения, начиная с характеристик качества, определенных в настоящем стандарте. Ряд детальных процедур, таких как анализ и проверка метрик, на схеме 1 не показаны.

Схема 1 — Модель процесса оценивания

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

5.3.1 Установление требований к качеству

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

5.3.2 Подготовка к оцениванию

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

5.3.2.1 Выбор метрик (показателей) качества

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

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

5.3.2.2 Определение уровней ранжирования

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

Схема 2 — Измеренное значение и установленный уровень

5.3.2.3 Определение критерия оценки

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

5.3.3 Процедура оценивания

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

5.3.3.1 Измерение

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

5.3.3.2 Ранжирование

На этапе ранжирования устанавливается уровень ранжирования для измеренного значения (см. схему 2).

5.3.3.3 Оценка

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

ПРИЛОЖЕНИЕ А (рекомендуемое). КОМПЛЕКСНЫЕ ПОКАЗАТЕЛИ (подхарактеристики) КАЧЕСТВА

ПРИЛОЖЕНИЕ А
(рекомендуемое)

A.1 Введение

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

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

А.2 Определение комплексных показателей качества

А.2.1 Функциональные возможности (Functionality)

А.2.1.1 Пригодность (Suitability)

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

Примечание — Примерами соответствия является состав функций, ориентированных на задачу, из входящих в него подфункций и объемы таблиц.

A.2.1.2 Правильность (Accuracy)

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

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

А.2.1.3 Способность к взаимодействию (Interoperability)

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

Примечание — Способность к взаимодействию используется вместо совместимости для того, чтобы избежать возможной путаницы с взаимозаменяемостью (см. А. 2.6.4).

А.2.1.4 Согласованность (Compliance)

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

А.2.1.5 Защищенность (Security)

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

А.2.2 Надежность (Reliability)

А.2.2.1 Стабильность (Maturity)

Атрибуты программного обеспечения, относящиеся к частоте отказов при ошибках в программном обеспечении.

А.2.2.2 Устойчивость к ошибке (Fault tolerance)

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

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

А.2.2.3 Восстанавливаемость (Recoverability)

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

А.2.3 Практичность (Usability)

А.2.3.1 Понятность (Understandability)

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

А.2.3.2 Обучаемость (Learnability)

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

А.2.3.3 Простота использования (Opеrability)

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

А.2.4 Эффективность (Efficiency)

А.2.4.1 Характер изменения во времени (Time behavior)

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

А.2.4.2 Характер изменения ресурсов (Resource behavior)

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

А.2.5 Сопровождаемость (Maintainability)

А.2.5.1 Анализируемость (Analysability)

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

А.2.5.2 Изменяемость (Changeability)

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

А.2.5.3 Устойчивость (Stability)

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

А.2.5.4 Тестируемость (Testability)

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

Примечание — Значения этой подхарактеристики могут быть изменены рассматриваемыми модификациями.

А.2.6 Мобильность (Portability)

А.2.6.1 Адаптируемость (Adaptability)

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

А.2.6.2 Простота внедрения (Installability)

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

А.2.6.3 Соответствие (Conformance)

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

A.2.6.4 Взаимозаменяемость (Replaceabilily)

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

Примечания

1 Взаимозаменяемость используется вместо совместимости для того, чтобы избежать возможной путаницы со способностью к взаимодействию (см. А.2.1.3).

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

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

Источник

ЕВРАЗИИСКИИ СОВЕТ ПО СТАНДАРТИЗАЦИИ, МЕТРОЛОГИИ И СЕРТИФИКАЦИИ (ЕАСС)

EURO-ASIAN COUNCIL FOR STANDARDIZATION, METROLOGY AND CERTIFICATION (EASC)

ГОСТ

МЕЖГОСУДАРСТВЕННЫЙ

СТАНДАРТ

ИСО/МЭК 9126-2001

Информационная технология

ОЦЕНКА ПРОГРАММНОЙ ПРОДУКЦИИ

Характеристики качества и руководства по их применению

(ISO/IEC 9126:1991, ЮТ)

Издание официальное

Минск

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

Предисловие

Евразийский Совет по стандартизации, метрологии и сертификации (ЕАСС) представляет собой региональное объединение национальных органов по стандартизации государств, входящих в содружество Независимых Государств. В дальнейшем возможно вступление в ЕАСС национальных органов по стандартизации других государств.

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0-92 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-97 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила, рекомендации по межгосударственной стандартизации. Порядок разработки, принятия, обновления и отмены».

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

1 ПОДГОТОВЛЕН Межгосударственным техническим комитетом по стандартизации МТК 22 «Информационные технологии».

2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии Российской Федерации

3 ПРИНЯТ Евразийским Советом по стандартизации, метрологии и сертификации (протокол № 20 от 2 ноября 2001 г.)

За принятие проголосовали:

Краткое наименование страны по МК(ИС0 3166) 004-97	Код страны по МК(ИС0 3166) 004-97	Сокращенное наименование национального органа по стандартизации
Армения	AM	Минторгэкономразвития
Беларусь	BY	Госстандарт Республики Беларусь
Казахстан	KZ	Госстандарт Республики Казахстан
Кыргызстан	KG	Кыргызстандарт
Молдова	MD	Молдова-Стандарт
Российская Федерация	RU	Госстандарт России
Таджикистан	TJ	Таджикстандарт

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 9126:1991 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению» (ISO/IEC 9126:1991 «Information technology. Software product evaluation. Quality characteristics and guidelines for their use»)

Степень соответствия — идентичен (IDT).

Настоящий стандарт идентичен ГОСТ Р ИСО/МЭК 9126-93

5 ВВЕДЕН ВПЕРВЫЕ

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

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

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

А.2.2.3 Восстанавливаемость (Recoverability)

А.2.3 Практичность (Usability)

А.2.3.1 Понятность (Understandability)

А.2.3.2 Обучаемость (Learnability)

А.2.3.3 Простота использования (Operability)

А.2.4 Эффективность (Efficiency)

А.2.4.1 Характер изменения во времени (Time behavior)

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

А.2.4.2 Характер изменения ресурсов (Resource behavior)

А.2.5 Сопровождаемость (Maintainability)

А.2.5.1 Анализируемость (Analusability)

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

А.2.5.2 Изменяемость (Changeability)

А.2.5.3 Устойчивость (Stability)

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

А.2.5.4 Тестируемость (Testability)

Примечание — Значения этой подхаракгеристики могут быть изменены рассматриваемыми модификациями.

А.2.6 Мобильность (Portability)

А.2.6.1 Адаптируемость (Adaptability)

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

А.2.6.2 Простота внедрения (Installability)

А.2.6.3 Соответствие (Conformance)

ГОСТ ИСО/МЭК 9126—2001

А.2.6.4 Взаимозаменяемость (Replaceability)

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

Примечания

1 Взаимозаменяемость используется вместо совместимости для того, чтобы избежать возможной путаницы со способностью к взаимодействию (А.2.1.3).

УДК 681.3.06:006.83:06.354 МКС 35.080 П85

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

ГОСТ ИСО/МЭК 9126—2001

Содержание

1 Область применения…………………………………………………………………………………………………….. 1

2 Нормативные ссылки…………………………………………………………………………………………………….. 1

3 Определения………………………………………………………………………………………………………………… 1

4 Характеристики качества программного обеспечения…………………………………………………….. 2

4.1 Функциональные возможности (Functionality)……………………………………………………………….. 2

4.2 Надежность (Reliability)……………………………………………………………………………………………….. 3

4.3 Практичность (Usability)………………………………………………………………………………………………. 3

4.4 Эффективность (Efficiences)……………………………………………………………………………………….. 3

4.5 Сопровождаемость (Maintainability)……………………………………………………………………………… 3

4.6 Мобильность (Portability)…………………………………………………………………………………………….. 3

5 Руководство по применению характеристик качества……………………………………………………… 3

5.1 Применяемость………………………………………………………………………………………………………….. 3

5.2 Представления о качестве программного обеспечения………………………………………………… 4

5.3 Модель процесса оценивания…………………………………………………………………………………….. 5

Приложение А Комплексные показатели (подхарактеристики) качества…………………………….. 7

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Информационная технология ОЦЕНКА ПРОГРАММНОЙ ПРОДУКЦИИ ХАРАКТЕРИСТИКИ КАЧЕСТВА И РУКОВОДСТВА ПО ИХ ПРИМЕНЕНИЮ

Information technology SOFTWARE PRODUCT EVALUATION QUALITY CHARACTERISTICS AND GUIDELINES FOR THEIR USE

Дата введения

1 Область применения

Настоящий стандарт не определяет подхарактеристики (комплексные показатели) и показатели,, а также методы измерения, ранжирования и оценки. Данный стандарт придерживается определения качества по ИСО 8402.

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

2 Нормативные ссылки

В настоящем стандарте использованы ссылки на следующие стандарты:

ИСО/МЭК 2382-20:1990 Информационная технология. Словарь. Часть 20. Разработка системы. Двуязычное издание

ИСО 8402:1994 Управление качеством и обеспечение качества. Словарь

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

3 Определения

В настоящем стандарте применяются следующие термины с соответствующими определениями.

Примечание — Примеры признаков включают длину маршрута, модульность, структуру программы и

комментарии.

Издание официальное

3.8 Уровень ранжирования (rating level) — диапазон значений в масштабе, позволяющем классифицировать (ранжировать) программное обеспечение в соответствии с установленными или предполагаемыми потребностями. Соответствующие уровни ранжирования могут быть связаны с различными представлениями о качестве, то есть для пользователей, руководителей или разработчиков. Данные уровни называются уровнями ранжирования.

Примечание-Данные уровни ранжирования отличны от «классов», определенных ИСО 8402.

3.9 Программное обеспечение (software) — программы, процедуры, правила и любая соответствующая документация, относящаяся к работе вычислительной системы.

3.10 Программная продукция (software product) — программный объект, предназначенный для поставки пользователю.

3.12 Критерий оценки качества программного обеспечения (software quality assessment criteria) — набор определенных и задокументированных правил и условий, которые используются для решения и приемлемости общего качества конкретной программной продукции. Качество представляется набором установленных уровней, связанных с программной продукцией.

3.13 Характеристики качества программного обеспечения (software quality characteristics) -набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается. Характеристики качества программного обеспечения могут быть уточнены на множестве уровней комплексных показателей (подхарактеристик).

4 Характеристики качества программного обеспечения

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

4.1 Функциональные возможности (Functionality)

Примечания

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

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

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

определению качества (3.6).

ГОСТ ИСО/МЭК 9126—2001

4.2 Надежность (Reliability)

4.3 Практичность (Usability)

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

4.4 Эффективность (Efficiences)

4.5 Сопровождаемость (Maintainability)

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

4.6 Мобильность (Portability)

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

Примечание — Окружающая обстановка может включать организационное, техническое или программное окружение.

5 Руководство по применению характеристик качества

5.1 Применяемость

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

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

— оценивание программного обеспечения перед его приемкой.

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

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

Важность каждой характеристики качества также меняется в зависимости от принятых точек зрения.

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

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

5.2.1 Представление пользователя

Определение качества по ИСО 8402 отражает представление пользователя так же как и характеристики, определенные в настоящем стандарте.

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

— Имеются ли требуемые функции в программном обеспечении?

— Насколько надежно программное обеспечение?

— Насколько эффективно программное обеспечение?

— Является ли программное обеспечение удобным для использования?

— Насколько просто переносится программное обеспечение в другую среду?

5.2.2 Представление разработчика

5.2.3 Представление руководителя

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

ГОСТ ИСО/МЭК 9126—2001

5.3 Модель процесса оценивания

Установленные или

предпологаемые

потребности

неприемлемый)

Схема 1 — Модель процесса оценивания

5.3.1 Установление требований к качеству

5.3.2 Подготовка к оцениванию

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

5.3.2.1 Выбор метрик (показателей) качества

5.3.2.2 Определение уровней ранжирования

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

Отличный

Измеренные-

^Хо^ш^<\^{УСТаНОВЛеННЬ}‘^Й

///// /\ уровень

Низкий

Уровни ранжирования

Схема 2 — Измеренное значение и установленный уровень

5.3.2.3 Определение критерия оценки

5.3.3 Процедура оценивания

5.3.3.1 Измерение

5.3.3.2 Ранжирование

На этапе ранжирования устанавливается уровень ранжирования для измеренного значения (схема 2).

5.3.3.3 Оценка

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

ГОСТ ИСО/МЭК 9126—2001

Приложение А

(рекомендуемое)

Комплексные показатели (подхаракгеристики) качества А.1 Введение

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

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

А.2 Определение комплексных показателей качества

А.2.1 Функциональные возможности (Functionality)

А.2.1.1 Пригодность (Suitability)

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

А.2.1.2 Правильность (Accuracy)

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

А.2.1.3 Способность к взаимодействию (Interoperability)

Примечание — Способность к взаимодействию используется вместо совместимости для того, чтобы избежать возможной путаницы с взаимозаменяемостью (А.2.6.4).

А.2.1.4 Согласованность (Compliance)

А.2.1.5 Защищенность (Security)

А.2.2 Надежность (Reliability)

А.2.2.1 Стабильность (Maturity)

Атрибуты программного обеспечения, относящиеся к частоте отказов при ошибках в программном обеспечении.

А.2.2.2 Устойчивость к ошибке (Fault tolerance)

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

7

Источник

Текст ГОСТ Р ИСО/МЭК 25001-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Планирование и управление

ГОСТ Р ИСО/МЭК 25001-2017

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

Системная и программная инженерия

ТРЕБОВАНИЯ И ОЦЕНКА КАЧЕСТВА СИСТЕМ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (SQuaRE)

Планирование и управление

Information technology. Systems and software engineering. Systems and software Quality Requirements and Evaluation (SQuaRE). Planning and management

ОКС 35.080

Дата введения 2018-01-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 февраля 2017 г. N 69-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 25001:2014* «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Планирование и управление» (ISO/IEC 25001:2014 «Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Planning and management», IDT).
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . — .

ИСО/МЭК 25001 разработан подкомитетом ПК 7 «Системная и программная инженерия» совместного технического комитета СТК 1 «Информационные технологии» Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

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

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Декабрь 2018 г.

7 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Это издание отменяет и заменяет первое издание ИСО/МЭК 25001:2007, которое было переструктурировано и пересмотрено.

Настоящий стандарт является составной частью серии международных стандартов SQuaRE, которая состоит из следующих разделов:

— ИСО/МЭК 2500n, раздел управления качеством;

— ИСО/МЭК 2501n, раздел моделей качества;

— ИСО/МЭК 2502n, раздел измерения качества;

— ИСО/МЭК 2503n, раздел требований к качеству;

— ИСО/МЭК 2504n, раздел оценки качества.

Стандарты с ИСО/МЭК 25050 по ИСО/МЭК 25099 зарезервированы для использования при расширении серии стандартов SQuaRE.

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

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

Настоящий стандарт предназначен для применения в сочетании с другими стандартами серии SQuaRE. Серия стандартов SQuaRE ИСО/МЭК 25000 замещает серии стандартов ИСО/МЭК 9126 и ИСО/МЭК 14598. Настоящий стандарт соответствует техническим процессам по ИСО/МЭК 15288 и ИСО/МЭК 12207 в части определения и анализа требований к качеству.

На рисунке 1 (см. ИСО/МЭК 25000) показана организация семейства стандартов серии SQuaRE, далее называемых разделами.

Рисунок 1 — Организация серии международных стандартов SQuaRE

Серия стандартов SQuaRE состоит из следующих разделов стандартов:

— ИСО/МЭК 2500n — раздел «Управление качеством». Международные стандарты, входящие в этот раздел, определяют общие модели, термины и определения, используемые далее во всех других международных стандартах серии SQuaRE. В разделе также представлены требования и методические материалы, касающиеся поддерживающих функций, отвечающих за управление требованиями и оценкой продукции;

— ИСО/МЭК 2501n — раздел «Модель качества». Международные стандарты, входящие в этот раздел, представляют детализированные модели качества систем и программной продукции, качества при использовании и качества данных. Кроме того, приведено практическое руководство по использованию модели качества;

— ИСО/МЭК 2502n — раздел «Измерение качества». Международные стандарты, входящие в этот раздел, включают в себя эталонную модель измерения качества программной продукции, математические определения показателей качества и практическое руководство по их использованию. В этом разделе приведены показатели внутреннего и внешнего качества программного обеспечения и показатели качества при использовании. Кроме того, в разделе определены и представлены элементы показателей качества (ЭПК), формирующие основу для вышеперечисленных показателей;

— ИСО/МЭК 2503n — раздел «Требования к качеству». Международные стандарты, входящие в этот раздел, определяют требования к качеству на основе моделей и показателей качества. Такие требования к качеству могут быть использованы в процессе формирования требований к качеству программного обеспечения до начала разработки или как входные данные для процесса оценки;

— ИСО/МЭК 2504n — раздел «Оценка качества». Международные стандарты, входящие в этот раздел, представляют требования, рекомендации и методические материалы для оценки программной продукции, выполняемой как оценщиками, так и заказчиками или разработчиками. Кроме того, раздел обеспечивает поддержку документирования измерения как модуля оценки;

— ИСО/МЭК 25050-25099 — раздел расширения SQuaRE. Международные стандарты этого раздела в настоящее время включают в себя требования к международным стандартам и техническим отчетам по качеству систем и программной продукции в специальных областях приложения или для дополнения одного или более стандартов серии SQuaRE.

1 Область применения

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

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

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

Пользователи настоящего стандарта являются ответственными:

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

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

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

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

— функции гарантий качества.

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

2 Соответствие

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

3 Нормативные ссылки

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

ISO/IEC 25000:2014, Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE [Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Руководство по SQuaRE]

ISO/IEC 25010:2011, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models [Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения]

ISO/IEC 25020:2007, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Measurement reference model and guide [Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Эталонная модель и руководство по измерениям]

ISO/IEC 25021:2012, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality measure elements [Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Элементы показателя качества]

ISO/IEC 25022, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Measurement of quality in use [Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Измерения качества при использовании]

ISO/IEC 25023, Systems and software engineering: Systems and software Quality Requirements and Evaluation (SQuaRE) — Measurement of system and software product quality [Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Измерения качества системы и программной продукции]

ISO/IEC 25024, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Measurement of data quality [Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Измерения качества данных]

ISO/IEC 25030:2007, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements [Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Требования к качеству]

ISO/IEC 25040:2011, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation process [Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки]

ISO/IEC 25041:2012, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation guide for developers, acquirers and independent evaluators [Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Руководство по оценке для разработчиков, приобретающей стороны и независимых оценщиков]

ISO/IEC 25045:2010, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation module for recoverability [Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости]

ISO/IEC 25051, Software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing [Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Требования к качеству готовой программной продукции и инструкции по тестированию]

ISO/IEC 15288:2008*, Systems and software engineering — System life cycle processes [Системная и программная инженерия. Процессы жизненного цикла систем]
________________
* Заменен на ISO/IEC/IEEE 15288:2015.

ISO/IEC 12207:2008**, Systems and software engineering — Software life cycle processes [Системная и программная инженерия. Процессы жизненного цикла программных средств]
________________
** Заменен на ISO/IEC/IEEE 12207:2017.

4 Термины и определения

В настоящем стандарте применены термины и определения по ИСО/МЭК 25000, а также следующие термины с соответствующими определениями:

4.1 оценка, оценивание, оценка (evaluation): Систематическое определение степени, с которой определенный объект удовлетворяет установленным критериям.

4.2 действия по оценке (evaluation activity): Оценка систем или программной продукции на соответствие целевым значениям определенных и применяемых характеристик качества, выполняемая с использованием прикладных методов и методик.

4.3 группа оценки (evaluation group): Организация, ответственная за задание требований к качеству систем и программного обеспечения, а также за реализацию и управление действиями по оценке качества систем и программного обеспечения путем обеспечения технологий, инструментариев, опыта и управленческих навыков.

Примечание — Требования к качеству программного обеспечения могут быть заданы заявителем для проведения оценки, в то время как группе оценки следует верифицировать наличие и количественные значения требований к качеству программного обеспечения.

4.4 технология оценки (технология, используемая для оценки) [evaluation technology (technology used for evaluation)]: Методики, процессы, инструментарии, показатели и соответствующая техническая информация, используемые для оценки.

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

4.5 методики, техника (techniques): Методы и навыки, требуемые для выполнения определенной деятельности.

5 Понятия для управления оценкой

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

Таблица 1 — Действия по оценке систем и программного обеспечения


Разрабатываемые системы или программное обеспечение	Приобретаемые системы или программное обеспечение
Действия по разработке	Действия по оценке	Действия по приобретению	Действия по оценке
Производимое зависит от выбранного жизненного цикла (см. ИСО/МЭК 15288 и ИСО/МЭК 12207), т.е. от спецификаций системных требований и спецификаций проекта систем	Оценка заданного «производимого» (выходных результатов проекта), т.е. анализ проекта системы	Закупка существующих систем или готовой программной продукции	Оценка приобретаемой продукции с использованием применимых международных стандартов или технических отчетов из множества стандартов серий ИСО/МЭК 25000

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

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

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

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

— разработка критериев для установления контрольных точек для оценки;

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

— распространение результатов действий группы оценки в пределах организации;

— приобретение соответствующей технической информации;

— приобретение технологий оценки;

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

— оценка эффективности и качества разработки и приобретения систем и программного обеспечения;

— помощь в передаче технологий.

Примечание — Группа оценки может быть внешней или внутренней относительно организации, оценивающей системы или программное обеспечение.

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

6.1 Общее

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

Для задания требований должны быть использованы ИСО/МЭК 25010 и ИСО/МЭК 25030, для выполнения оценки — ИСО/МЭК 25040, ИСО/МЭК 25041 и ИСО/МЭК 25045 (когда это применимо), для выполнения процессов задания требований, измерения и оценки качества — ИСО/МЭК 25010 и стандарты ИСО/МЭК 25020-ИСО/МЭК 25024.

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

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

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

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

— задание оценки;

— проектирование оценки;

— выполнение оценки;

— анализ результатов.

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

— соответствие международным, национальным или внутренним стандартам (если применимо);

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

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

6.2 Действия на уровне организации

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

6.2.1 Управление средой организации

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

— разрабатывать планы оценки качества систем и/или программного обеспечения и процедуры, которые совместимы со стратегией и политикой организации в области качества;

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

— определять значения целевых показателей для оценки качества;

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

Примечание — Вышеупомянутые требования основаны на процессах управления качеством и организационного обеспечения проекта по ИСО/МЭК 15288 и ИСО/МЭК 12207.

6.2.2 Управление ресурсами

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

— определять и обеспечивать поддержку инфраструктуры ресурсов, необходимых для задания требований к качеству системы и/или программного обеспечения и выполнения проекта по оценке;

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

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

6.2.3 Планирование использования и усовершенствования задания требований к качеству и технологии оценки качества

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

План должен включать следующее:

а) подготовку политики:

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

b) определение целей организации:

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

c) определение используемой технологии оценки:

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

d) назначение ответственностей за управление заданием требований к качеству и управление процессом оценки:

— должна быть определена четко установленная ответственность для введения, сопровождения и непрерывного усовершенствования процессов задания требований и оценки качества;

e) определение дальнейших усовершенствований:

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

6.2.4 Реализация технологии оценки

Организация должна:

— определить требования для приобретения или разработки технологии оценки;

— оценить пригодность технологии оценки качества;

— определить процесс для принятия и применения приобретенной технологии оценки.

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

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

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

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

a) подготовка к передаче технологии.

С целью передачи технологии организация должна учесть следующее:

— обязательная подготовка программ обучения поддержки;

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

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

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

Примечание — Некоторую часть специализированной программы обучения следует посвятить целям, действиям, расписаниям, задачам и обязанностям в плане оценки качества по проекту;

b) осуществление передачи технологии.

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

c) оценка передачи технологии.

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

— оценка эффектов введенной технологии для всех проектов,

— оценка степени и распространения технологии в пределах организации.

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

6.2.6 Оценка технологии для задания требований и оценки качества

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

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

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

— решение вопросов пригодности и достоверности измерений, критериев оценки и используемых методов;

— анализ эффективности задания требований к качеству;

— анализ эффективности всеобъемлющей оценки качества систем и/или программного обеспечения;

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

— решение вопросов пригодности уровней оценки.

6.2.7 Управление опытом

Должна быть определена ответственность за эффективное применение технологии оценки в пределах организации. Ответственность предусматривает сопровождение результатов оценки и поддержание накопленного опыта. Это следует использовать для улучшения качества и совершенствования технологии оценки.

Усовершенствования могут быть достигнуты путем модификации собственных (определенных для компании) стандартов, таких как:

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

— выбору показателей;

— определению уровня оценки;

— критериям оценки.

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

— периодические связанные с технологией анализы;

— объединение соответствующим образом новых и существующих стандартов;

— интеграция новых и существующих показателей;

— обратная связь при пересмотрах новых и существующих стандартов;

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

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

6.3 Действия на уровне управления проектом

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

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

— утвержденный бюджет;

— соответствующие ресурсы;

— поддерживающие инструментарии, стандарты и процедуры;

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

6.3.1 Поддержка планирования оценки

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

При подготовке такого плана необходимо рассмотреть:

a) цель и использование плана.

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

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

b) аттестацию плана.

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

— способы достижения установленных целей,

— способы и методы количественной оценки достижения этих целей,

— определение способов поддержки процесса оценки,

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

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

— определение соответствующих целей по качеству.

Примечание — Цели по качеству могут быть ориентированы на продукцию, процесс или даже на соответствующий размер,

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

— определение того, как данные должны быть собраны, проконтролированы и использованы;

с) содержание плана.

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

Цели, отражаемые в плане, должны быть дополнены:

— соответствующими характеристиками качества продукции,

— принятыми стандартами,

— методами,

— навыками персонала,

— поддержкой управления проектом и инструментариями.

Образец проектного плана оценки качества представлен в приложении А.

6.4 Анализ и использование результатов оценки

В конце каждого проекта по оценке качества группа оценки должна собрать результаты оценки. Эти результаты должны быть проанализированы и определены способы дальнейшего эффективного их использования. Для этого следует учесть:

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

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

— определение соответствующих методов интерпретации данных;

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

— соответствующее обучение, если оно требуется.

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

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

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

Приложение А (справочное). Образец проектного плана оценки качества

Приложение А
(справочное)

Следующий образец проектного плана оценки качества представляет собой пример документа, который следует использовать группе оценки при подготовке и выполнении проекта по оценке. Если подготовка проекта по оценке требует более специального подхода (например, применения специального процесса оценки), пользователи настоящего стандарта могут обратиться к следующим частям серии стандартов SQuaRE:

— ИСО/МЭК 25040:2011 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки»;

— ИСО/МЭК 25041 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Руководство по оценке для разработчиков, приобретающей стороны и независимых оценщиков»;

— ИСО/МЭК 25045:2010 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости»;

— ИСО/МЭК 25030:2007 «Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Требования к качеству»;

— ИСО/МЭК 25020:2007 «Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Эталонная модель и руководство по измерениям»;

— ИСО/МЭК 25021:2012 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Элементы показателя качества»;

— ИСО/МЭК 25022 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Измерения качества при использовании»;

— ИСО/МЭК 25023 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Измерения качества системы и программной продукции»;

— ИСО/МЭК 25024 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Измерения качества данных».

А.1 Раздел 1. Введение

Следует описать:

— цель плана;

— кому план предназначен;

— предполагаемое использование плана.

А.2 Раздел 2. Задачи оценки

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

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

В этом разделе следует отразить положения по характеристикам качества, вытекающим из задания требований к качеству системы и программного обеспечения и поддерживающим задачи по подразделу А.2 (например, по ИСО/МЭК 25010).

Примечание — Деятельность по заданию требований к качеству должна быть учтена в разделах 6 и 9; однако сам процесс остается вне области проектного плана оценки качества и требует отдельных усилий.

Установленные цели по качеству могут быть ориентированы как на продукцию, так и на процесс. Цель плана состоит лишь в обращении к целям по качеству продукции.

А.4 Раздел 4. Перечень приоритетов

В этом разделе следует расставить приоритеты для вышеупомянутых характеристик и дать обоснование этому.

А.5 Раздел 5. Задачи по качеству

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

А.6 Раздел 6. Определение ответственностей

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

А.7 Раздел 7. Проектирование оценки

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

В разделе следует указать, на каком этапе разработки периодически повторяются эти измерения, какой процесс оценки должен быть применен (по ИСО/МЭК 25041), как часто измерения следует повторять, какие методы или инструментарии использовать для сбора и анализа данных, и какие действия следует предпринимать, если имеют место расхождения по установленным целевым значениям.

А.8 Раздел 8. Использование и анализ данных

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

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

А.9 Раздел 9. Планирование и выполнение оценки

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

А.10 Раздел 10. Отчетность

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

А.11 Раздел 11. Другие требования

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

a) применяемые методы и методики.

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

b) поддерживающие инструментарии.

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

c) соответствующие стандарты и руководства.

Приводят ссылки на применяемые стандарты и поддерживающие руководства. Описывают их использование и извлечение пользы относительно требований к качеству систем и программной продукции и процессов оценки (например, по ИСО/МЭК 25000; ИСО 9001; ИСО/МЭК 90003);

d) оценка поставщиков.

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

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

Приложение ДА (справочное). Сведения о соответствии ссылочных международных стандартов национальным стандартам

Приложение ДА
(справочное)

Таблица ДА.1


Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ISO/IEC 25000:2014	—	*
ISO/IEC 25010:2011	IDT	ГОСТ Р ИСО/МЭК 25010-2015 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов»
ISO/IEC 25020:2007	—	*
ISO/IEC 25021:2012	IDT	ГОСТ Р ИСО/МЭК 25021-2014 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Элементы показателя качества»
ISO/IEC 25022	—	*
ISO/IEC 25023	—	*
ISO/IEC 25024	—	*
ISO/IEC 25030:2007	—	*
ISO/IEC 25040:2011	IDT	ГОСТ Р ИСО/МЭК 25040-2014 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки»
ISO/IEC 25041:2012	IDT	ГОСТ Р ИСО/МЭК 25041-2014 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Руководство по оценке для разработчиков, приобретателей и независимых оценщиков»
ISO/IEC 25045:2010	IDT	ГОСТ Р ИСО/МЭК 25045-2015 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости»
ISO/IEC 25051	IDT	ГОСТ Р ИСО/МЭК 25051-2017 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию»
ISO/IEC 15288:2008	—	*
ISO/IEC 12207:2008	IDT	ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»
* Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта.
Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: — IDT — идентичные стандарты.

Библиография


[1]	ISO/IEC 9126-1:2001 Software Engineering — Product quality — Part 1: Quality model
[2]	ISO/IEC TR 9126-2:2003 Software engineering — Product quality — Part 2: External metrics
[3]	ISO/IEC TR 9126-3:2003 Software engineering — Product quality — Part 3: Internal metrics
[4]	ISO/IEC TR 9126-4:2004 Software engineering — Product quality — Part 4: Quality in use metrics
[5]	ISO/IEC 14598-1:1999 Information Technology — Software product evaluation — Part 1: General overview
[6]	ISO/IEC 14598-2:2000 Software Engineering — Product evaluation — Part 2: Planning and management
[7]	ISO/IEC 14598-3:2000 Software Engineering — Product evaluation — Part 3: Process for developers
[8]	ISO/IEC 14598-4:1999 Software Engineering — Product evaluation — Part 4: Process for acquirers
[9]	ISO/IEC 14598-5:1998 Information technology — Software product evaluation — Part 5: Process for evaluators
[10]	ISO/IEC 14598-6:2001 Software engineering — Product evaluation — Part 6: Documentation of evaluation module


УДК 006.034:006.354:004.05:004.054	ОКС 35.080

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

Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2019

Источник

Наношкин Александр Геннадьевич¹, Макашов Павел Леонидович²
¹Магнитогорский Государственный Технический Университет им. Г.И. Носова, г. Магнитогорск, студент группы ФИПИб-12
²ЗАО Консом СКС, г. Магнитогорск, руководитель проектов

Аннотация
В статье рассматриваются методы управления качеством при планировании и реализации проекта на основе стандарта ISO 10006 управления качеством проектов в области ИТ. А также концепция управления качеством в ИТ-проекте.

Nanoshkin Alexander¹, Pavel Leonidovich Makashov²
¹Nosov Magnitogorsk State Technical University, Magnitogorsk, student group FIPIb — 12
²ZAO Conseil SCS, Magnitogorsk, Project Manager

Abstract
The article discusses methods of quality management in the planning and implementation of the project on the basis of ISO 10006 quality management projects in the it field. As well as the concept of quality management in the it project.

Библиографическая ссылка на статью:
Наношкин А.Г., Макашов П.Л. Управление качеством ИТ-проекта // Современные научные исследования и инновации. 2015. № 10 [Электронный ресурс]. URL: https://web.snauka.ru/issues/2015/10/57965 (дата обращения: 05.09.2023).

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

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

Стандарт ISO10006 имеет название “Менеджмент качества. Руководство качеством при управлении проектами”. Основные принципы управления качеством по стандартам серии ISO 10006:1997:

ориентация деятельности Компании на клиента;
ответственность руководства за создание благоприятной среды в отношении качества и непрерывное совершенствование СМК;
восприятие проекта как совокупность запланированных и взаимоувязанных процессов;
фокусировка внимания на качестве продуктов и услуг как на необходимом условии соответствия целям проекта;
отображение всех направлений деятельности в виде процессов;
структурный обобщенный подход к проекту.

Основой для процессного подхода управления проектами в соответствии со стандартом ISO 10006:1997 служат процессы определения стратегии, процессы управления коммуникациями в проекте, процессы управляющие реализацией проекта, которые включают управление предметной областью, управление материально-техническим снабжением, управление сроками, управление затратами, управление ресурсами, менеджмент персонала, управление информацией, управление рисками.

Мониторинг и управление качеством осуществляется на протяжении всего жизненного цикла проекта. На рисунке 1 представлены стадии управления качеством проекта.

Стадия “Концепция”. На данной стадии формулируется стратегия и направление действий для эффективного управления качеством. “Концепция” имеет следующие разделы:

Политика и стратегия качества;
Общие требования и принципы обеспечения качества;
Стандартизация;
Разработка параметров обеспечения качества;
Требования к системе управления качеством.

Стадия планирования. На стадии планирования определяются жесткие рамки соответствующие стандартам. Идентификация и пути реализации этих стандартов также включены в стадию планирования. Стадия планирования включает в себя базовые задачи, такие как:

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

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

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

Стадия контроля. Контроль качества состоит в сопоставлении результата проекта и стандартов качества, а также в выявлении причин нарушения сопоставления определенным ранее требованиям качества.

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

Сравнение фактических результатов проекта с требованиями.
Анализ прогресса качества в проекте на протяжении его жизненного цикла.
Создание перечня с отклонениями.
Действия коррекционного характера.
Протоколирование изменений изменений.

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

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

Рисунок 2 – взаимосвязь процессов управления качеством проекта

Планирование качества — процесс определения того, какие из стандартов качества относятся к данному проекту и как их удовлетворить[1].

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

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

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

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

Факторы внешней среды предприятия — правила, стандарты и предписания, свойственные определенным областям приложения[1].

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

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

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

Планирование качества: инструменты и методы

Главное назначение инструментов планирования качества – «научить» процессы управления проектом предсказуемости. Базовые методы планирования качества представлены ниже.

Анализ выгод и затрат [2]. Цель метода – выдержать необходимое соотношение между доходами и затратами в проекте. Обеспечение качества проекта, несомненно, приводит к дополнительным расходам, поэтому для каждого предложенного метода обеспечения качества необходимо анализировать коэффициент рентабельности. На рисунке 3 представлен выбор оптимальной пропорции затрат на профилактику дефектов и устранение дефектов [3].

Рисунок 3 – соотношение затрат и выгод в обеспечении качества

Стоимость качества — совокупная стоимость всех действий, которые требуется совершить для обспечения качества на должном уровне в соответствии с требованиями, поставленными в IT- проекте.

Планирование качества: выходы

План управления качеством — описание того, каким образом команда управления проектом будет осуществлять политику исполняющей организации в области качества[6].

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

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

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

Процесс обеспечения качества

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

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

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

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

План улучшения процесса.

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

Контрольные списки качества (метрики качества). Контрольный список – бланк или анкета с инструкциями для ревизора качества. Пункты в этом бланке должны быть хорошо конкретизированы, излишков быть не должно, иначе контрольный список потеряет востребованность в работе.

Результаты контроля качества. Данные о результатах контроля отправляются организации для проверки соответствия требованиям. Форма представления результатов контроля качества приведена в качестве примера на таблице 1

Таблица 1 — пример представления результатов контроля качества[11].

№ отклонения	Дата выявления	Название работы	Описание отклонения	Статус отклонения	Предпринятые действия
1.3.11	14.07.14	Разработка интерфейса АИС	Цвет фона формы не соответствует стандарту.	серьезное — отклонение необходимо устранить, чтобы качество проекта соответствовало заданному уровню.	в работе — отклонение передано в рассмотрение в процедуре управления проблемами, ответ ожидается

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

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

Аудит качества — независимая экспертиза направленная на выявление несоответствий операций определенным процессам и процедурам проекта, с целью обнаружения малоэффективных и экономически не оправданного поведения, правил, процессов и процедур, которые используются в проекте. Аудиторские проверки качества могут совершаться в определенные этапы проекта, и/или в связи со значимыми событиями в проекте. Так же могут проводиться и внеплановые проверки по запросу заказчиков, спонсоров и руководства. Проверки осуществляются на основе требований нормативной документации системы менеджмента качества (требование ISO 10006) и системы управления проектами (PMBOK). Примерная схема внутреннего аудита качества:

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

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

Процесс обеспечения качества: выходы

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

Активы организационного процесса (обновления). Обновленные стандарты качества проекта служат основой для дальнейшего продолжения процесса контроля качества.

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

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

Контроль качества — процесс, основные задачи которого заключаются в оценке промежуточных исходов проекта, определении соответствий этих промежуточных результатов стандарту, а также нахождение пути решения несоответствий. На всем жизненном этапе проекта должно проводиться управление качеством. На основе статистического анализа и теории вероятности осуществляется оценка контроля качества [6].

Процесс контроля качества: входы

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

Результаты оценки качества.

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

Активы организационного процесса.

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

Результаты поставки.

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

Для осуществления контроля качества используют следующие методы и средства:

Диаграмма причинно-следственных связей позволяет увидеть «узкие места», которые влияют на качество продукта/процесса. Другое название данной диаграммы – диаграмма Исикавы, или по-другому «рыбья кость», она показывает взаимосвязь факторов работы и проблем[9] .

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

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

Статистические выборки — это часть контролируемой продукции, позволяющей сделать вывод обо всей продукции данного вида в проекте. Правильно сделанная выборка часто помогает снизить затраты на контроль качества[7].

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

Тестирование проводится по одному взятому процессу, а так же по целой совокупности процессов. Разработка сценариев необходима для проведения тестирования. Сводная таблица сценариев тестирования служит для осуществления контроля качества создаваемой информационной системы.

Выходы процесса контроля качества

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

Базовый план по качеству (обновления).

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

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

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

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

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

Утвержденные результаты поставки — последствия, которые определяются при установлении соответствия результатов поставки определенным требованиям. Результатом процесса контроля качества являются утвержденные результаты поставки.

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

Рассмотренный стандарт ISO-10006 «Менеджмент качества. Руководство качеством при управлении проектами» в области управления качеством является отправной точкой для начала управления качеством в ИТ-проекте.

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

Библиографический список

Руководство к своду знаний по управлению проектами (Руководство PMBOK). 3-е издание.
Милошевич Драган З, Набор инструментов для управления проектами М.: Академия АйТи, ДМК Пресс, 2006
Ньюэлл Майкл В, Управление проектами для профессионалов. Руководство по подготовке к сдаче сертификационного экзамена. 3-е издание М.: КУДИЦ-ОБРАЗ, 2006
ГОСТ Р ИСО 10006 «Системы менеджмента качества. Руководство по менеджменту качества при проектировании». [Электронный ресурс]. URL: http://ohranatruda.ru/ot_biblio/normativ/data_normativ/46/46262/index.php (дата обращения: 20.03.2015).
Леднов А.В., Макашов П.Л., Волщуков Ю.Н. Информационная модель системы сквозной маркировки продукции металлургического предприятия//Сталь.-2014.-№4.С119-123.
Макашова В.Н., Миронова А.А. Применение Информационных Технологий как инструмента минимизации рисков инвестиционных проектов в сфере автоматизации промышленных предприятий// Инновационный Вестник Регион. -2013.- № 4.2. С. 55-60.
Макашова В.Н., Трейбач Е.Л., Чусавитина Г.Н. Методика оценки ИТ-стартапа//Теплотехника и информатика в образовании, науке и производстве: сб. докладов IV Всероссийской научно-практической конференции студентов, аспирантов и молодых учёных (TИМ’2015) с международным участием, посвящённой 95-летию основания кафедры и университета (Екатеринбург, 26–27 марта 2015 г.). – Екатеринбург: УрФУ, 2015. –С.319-323
Ошурков В.А., Макашова В.Н. Механизмы оптимизации управления программой ИТ-проектов // Сборник научных трудов SWORLD. – N 1. – С.66-72.
Ошурков В.А., Макашова В.Н. Методы минимизации ресурсных рисков в проектах разработки программных продуктов // Современные научные исследования и инновации. 2014. № 10 [Электронный ресурс]. URL: http://web.snauka.ru/issues/2014/10/37111 (дата обращения: 28.02.2015).
Ошурков В.А., Макашова В.Н. Управление ресурсными рисками в проектах по разработке программного обеспечения // Экономика и социум. 2014. № 3(12) [Электронный ресурс]. URL: http://iupr.ru/domains_data/files/sborniki_jurnal/Zhurnal%20_3(12)%202014%202nov.pdf (дата обращения: 28.02.2015).
Макашова В.Н., Старков А.Н., Чусавитина Г.Н. Информационные системы и технологии [Текст]: практикум. – Магнитогорск, 2011.- 188 с.
Чусавитина Г.Н., Макашова В.Н. Использование информационных технологий в управлении проектами. -Магнитогорск: МаГУ, 2011. -216 с.
Ильин В, Руководство качеством проектов. Практический опыт. СПб.: Вершина, 2006

Количество просмотров публикации: Please wait

Все статьи автора «Наношкин Александр Геннадьевич»

Источник

Евгений Якушевский

Создание системы менеджмента качества (СМК),
соответствующей требованиям стандарта ИСО 9000-2000, — прекрасная возможность
для предприятия повысить уровень менеджмента и привести его в соответствие с
мировой практикой. Сертификат в таком случае становится лишь дополнительным
подтверждением способности предприятия гарантированно поставлять продукцию и
услуги высокого качества заказчикам.

Разработанная
в соответствии со стандартом ИСО серии 9000, СМК основана на структурированном
наборе документов, который регламентирует основные аспекты производственной и
управленческой деятельности предприятия.

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

При разработке СМК целесообразно выделять следующие
основные задачи:

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

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

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

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

Концептуальной основой ИСО 9000-2000 является то, что
организация создает, обеспечивает и улучшает качество продукции, организуя и
управляя своими процессами, которые должны подвергаться анализу и постоянному
улучшению. Все процессы компании образуют систему, которую надо ясно
представлять при принятии любых управленческих решений. То есть главными
принципами современных стандартов являются «процессный» и «системный» подходы к
управлению.

Возможность реализации этих принципов обеспечивает
применение современных технологий управления и прежде всего троично-матричного
анализа. Данные технологии опираются на построение и поддержание в актуальном
состоянии электронной модели управления персоналом компании. Концепция
информационной поддержки менеджмента качества исходит из того, что модель
управления, заложенная в стандарты ИСО 9000, может быть реализована различными
программными средствами, с помощью которых осуществляются принципы эффективной
организации.

В соответствии с ними, прежде всего, необходимо обеспечить:

● формирование
стройной системы показателей, которые «настраивают» работников на стратегию;

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

● единое
информационное пространство с быстрым доступом к данным;

● накопление
и мониторинг информации о персонале — главном ресурсе компании.

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

Применение для построения СМК современных информационных
технологий позволяет компании достаточно быстро перейти к процессному
управлению. Такая система включает в себя четыре основных программных модуля
(системы):

● моделирования
и организации управления;

● планирования
деятельности во времени и контроля исполнения работ;

● организационных
коммуникаций;

● управления
данными о персонале.

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

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

Постановка СМК с применением технологий троично-матричного
анализа начинается с описания существующей деятельности предприятия («как есть»)
в формате стандартной организационно-функциональной модели. Наличие такого
точного модельного описания позволит:

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

● во-вторых,
сопоставить деятельность предприятия с требованиями, содержащимися в стандарте
ИСО 9001-2000, — это фактически формализует результаты диагностики (входного
аудита) и позволит определить те аспекты деятельности, на которых следует
сосредоточиться при постановке системы.

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

● представить
деятельность предприятия в виде модели взаимосвязанных процессов;

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

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

● и,
наконец, создать документацию СМК, позволяющую выполнять установленную
деятельность.

Использование технологий системы управления персоналом
предприятия позволяет перейти к реализации подхода «Менеджмент модели» вместо «Менеджмента
документов». Основная идея состоит в создании системы документов с помощью
бизнес-модели предприятия. При документировании деятельности (а это является
также одним из основных требований стандартов менеджмента качества ИСО 9000)
современным решением является поддержка не системы взаимосвязанных документов,
а системы взаимосвязанных информационных моделей предприятия, которые и будут
порождать требуемые документы! Кроме того, благодаря технологии создания документов
из единой системы моделей они не будут противоречить друг другу.

К другому
классу систем управления документацией относятся системы электронного
документооборота EDM (Electronic Data Management). На них обычно возлагаются
функции идентификации статуса, хранения документов, управления ими на пути
прохождения от одного пользователя — должностного лица к другому с возможностью
контроля за их перемещением и фиксацией всех изменений и сопровождающих
резолюций. Важность этих задач для СМК непосредственно следует из требований
стандарта.

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

● поддержка
процессов разработки и мониторинга организационно-распорядительных документов
(ОРД) управления предприятием (в том числе документов системы менеджмента
качества);

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

Такой способ хранения документов СМК не только
обеспечивает их в актуализированном состоянии и делает доступными для
сотрудников, но и позволяет выполнить требование ИСО 9001-2000, касающееся
внутреннего обмена информацией. Согласно ему «высшее руководство должно
обеспечить, чтобы в организации были разработаны соответствующие процессы
обмена информацией между различными уровнями, подразделениями и сотрудниками по
вопросам процессов системы менеджмента качества и их эффективности».
Доказательством соответствия организации этим требованиям может быть полученное
из модели компании описание процесса информационного взаимодействия,
базирующееся либо на простом (бумажном) документообороте и правилах субординации
при обмене информацией, либо на современной информационно-технологической
платформе с применением компьютерных технологий.

Главным
документом, фиксирующим полученную управленческую систему, является «Руководство
по качеству» (РК). (Для простоты изложения предположим, что заявления о
политике и целях в области качества также входят в состав этого документа).

Существуют два основных подхода к структуре и форме РК
(ИСО 10013):

● отражение
структуры стандарта, содержащего требования к системе качества;

● отражение
характера деятельности организации.

Первый
подход нацелен, главным образом, на создание формальной системы,
ориентированной на представление СМК сертифицирующим органам.

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

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

Качество это
стратегическое решение. Для того чтобы оно серьезно воспринималось всеми
членами организации, высшее руководство должно определить и опубликовать «Политику
предприятия в области качества». Это облегчит как внедрение СМК, так и процесс
сертификации, поскольку при аудите значительное внимание уделяется опросам
сотрудников — полезно, чтобы они не только знали политику, но и как-то
участвовали в ее формулировании.

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

Описание процессов и создание эффективно действующей
системы менеджмента качества — дело дорогое. Но это не потери фирмы. Это
инвестиции, связанные с улучшением функционирования компании, которые
многократно оправдаются в будущем!

Источник

1 ОБЛАСТЬ ПРИМЕНЕНИЯ

2 НОРМАТИВНЫЕ ССЫЛКИ

3 ОПРЕДЕЛЕНИЯ

4. ХАРАКТЕРИСТИКИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5 РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ХАРАКТЕРИСТИК КАЧЕСТВА

Схема 1 — Модель процесса оценивания

Схема 2 — Измеренное значение и установленный уровень

ПРИЛОЖЕНИЕ А (рекомендуемое). КОМПЛЕКСНЫЕ ПОКАЗАТЕЛИ (подхарактеристики) КАЧЕСТВА

ОЦЕНКА ПРОГРАММНОЙ ПРОДУКЦИИ

Предисловие

ГОСТ ИСО/МЭК 9126—2001

А.2.6.4 Взаимозаменяемость (Replaceability)

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

1 Область применения

2 Нормативные ссылки

3 Определения

4 Характеристики качества программного обеспечения

ГОСТ ИСО/МЭК 9126—2001

5 Руководство по применению характеристик качества

5.1 Применяемость

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

ГОСТ ИСО/МЭК 9126—2001

Приложение А

(рекомендуемое)

Комплексные показатели (подхаракгеристики) качества А.1 Введение

А.2 Определение комплексных показателей качества

7

Предисловие

Введение

1 Область применения

2 Соответствие

3 Нормативные ссылки

4 Термины и определения

5 Понятия для управления оценкой

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

6.1 Общее

6.2 Действия на уровне организации

6.3 Действия на уровне управления проектом

6.4 Анализ и использование результатов оценки

Приложение А (справочное). Образец проектного плана оценки качества

Приложение ДА (справочное). Сведения о соответствии ссылочных международных стандартов национальным стандартам

Библиография

А вот и еще интересные новости по теме: