66906

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

Лекция

Информатика, кибернетика и программирование

Назначение методологии СММ/CMMI – системы и модели оценки зрелости – состоит в предоставлении необходимых общих рекомендаций и инструкций предприятиям, производящим ПС, по выбору стратегии совершенствования качества процессов и продуктов, путем анализа степени их производственной зрелости и оценивания факторов...

Русский

2014-09-01

257.5 KB

18 чел.

PAGE  10

Лекция 3. Модели и процессы управления проектами                программных средств

3.1. Управление проектами  программных средств в системе СMMI

        Назначение методологии СММ/CMMIсистемы и модели оценки зрелости – состоит в предоставлении необходимых общих рекомендаций и инструкций предприятиям, производящим ПС, по выбору стратегии совершенствования качества процессов и продуктов,  путем анализа степени их  производственной зрелости и оценивания факторов, в наибольшей степени влияющих на качество ЖЦ ПС, а также посредством выделения процессов, требующих модернизации.  Для достижения устойчивых результатов программной инженерии в процессе развития  технологии и организации управления  жизненным циклом ПС в стандарте ISO 15504:1-9 рекомендуется использовать эволюционный путь, который позволяет совершенствовать и постепенно повышать качество процессов и продуктов, вскрывать  преимущества и недостатки предприятия. В методологии СММ выделены пять уровней зрелости,  раскрываемые в этом стандарте де-факто (рис.3.1). Виды деятельности для высоких уровней зрелости в соответствии с СММ, в стандарте делятся на базовые и общие. Базовые виды деятельности являются обязательными и сгруппированы в пять категорий: контрактная; инженерная;  управленческая; вспомогательная; организационная.  Уровни  зрелости характеризуются степенью формализации, адекватностью измерения и документирования процессов и продуктов ЖЦ ПС, широтой применения стандартов и инструментальных средств автоматизации работ, наличием и полнотой реализации функций системой обеспечения качества технологических процессов и их результатов.

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

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

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

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

          Уровень 4 Предсказуемый – количественное управление. Для реализации проектов крупных, особенно сложных ПС, в жестко ограниченные сроки и с высоким гарантированным качеством, необходимы активные меры для предотвращения и выявления дефектов и ошибок на всех этапах ЖЦ ПС. Управление должно обеспечивать выполнение процессов в соответствии с текущими требованиями к характеристикам качества компонентов и ПС в целом. На этом уровне, должна применяться система детального поэтапного оценивания характеристик качества, как технологических процессов ЖЦ, так и самого создаваемого программного продукта и его компонентов. Должны разрабатываться и применяться методики количественной оценки реализации процессов и их качества. Одновременно с повышением сложности и требований к качеству ПС, следует совершенствовать управление проектами за счет сокращения текущих корректировок и исправлений дефектов при выполнении процессов. Результаты процессов становятся предсказуемыми по срокам и качеству в связи с тем, что они измеряются в ходе их выполнения и реализуются в рамках заданных ресурсных ограничений.

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

   В 2003 году американский Институт программной инженерии (SEI)  опубликовал новую комплексную модель CMMI, уточняющую и совершенствующую предшествовавшие модели CMM, а также частично учитывающую основные требования существующих международных стандартов в области менеджмента программных средств.  Внедрение этой модели акцентировано на улучшении процессов управления проектами ПС, обеспечении их высокого качества и конкурентоспособности, с основной целью –  сделать процессы проектов управляемыми, а результаты – предсказуемыми. Значительное внимание в CMMI уделяется процессам разработки и учету итераций при изменении требований заказчиков,  их прослеживанию к функциям, компонентам, тестам и документам проекта. Концепцию, определяющую функциональную пригодность  и качество продукта, рекомендуется сопровождать проверками возможных сценариев событий при его применении.

  В последнее время появилась информация о  модернизации американским Институтом программной инженерии SEI версии CMMI-SE/SW/IPPD, V1.1 на основе накопленного опыта и отзывов предприятий. Предполагается выпустить в 2006 году новую, существенно модернизированную, версию модели CMMI-V1.2, после чего постепенно должно прекратиться применение версии 1.1. До конца 2007 года должен проводиться переход пользователей на версию  CMMI-V1.2, а в дальнейшем она станет обязательной для формализованной оценки качества (сертификации) технологии предприятий в области программной инженерии. При этом срок действия сертификата будет ограничен тремя годами. К этим изменениям следует готовиться после официальной публикации Институтом SEI версии 1.2.

          Два варианта модели CMMI – 1.1 созданы для обеспечения непрерывного оценивания комплекса процессов в определенной области создания программных средств или для поэтапного оценивания и совершенствования зрелости предприятия, а также для организации ЖЦ комплексов программ в целом. Модели  CMMI представляют помощь специалистам при организации технологии и совершенствовании их продуктов, а также для упорядочения и обслуживания процессов разработки и сопровождения ПС. Концепция этих моделей покрывает управление и оценивание зрелости сложных систем,  инженерии программных средств, а также процессов cоздания интегрированных программных продуктов и совершенствования их разработки. Компоненты непрерывной и поэтапной  моделей в значительной степени подобны, могут выбираться и применяться в разном составе и последовательности использования в зависимости от свойств и характеристик конкретных проектов.

        Варианты описания моделей построены по единой схеме, которая содержит общие разделы:

предисловие;

1. введение;

2. модель компонентов;

3. терминология;

4. содержание уровней и главные компоненты каждого варианта модели (разработка целей и процедур);

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

* менеджмент процессов;

* менеджмент – управление проектом;

* инжиниринг (технология);

* поддержка;

6 раздел – использование модели CMMI – краткие рекомендации для пользователей по применению модели и обучению; отмечается совмес-тимость и соответствие процессов модели, с регламентированными процессами предыдущей модели CMM  в части 2 и 3 стандарта ISO 15504.

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

     Первый вариант (непрерывной) модели отражает документ: Capability Maturity Model Integration (CMMI) for Systems Engineering / Software Engineering / Integrated Product and Process Development, Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD, V1.1, Continuous) – Интегрированная модель оценивания зрелости инженерии систем / программной инженерии / интегрированных продуктов и процессов разработки – непрерывное  представление. В этой модели  седьмой раздел составляют процессы:

  •  менеджмент процессов:

* содержание организационных процессов;

* определение организационных процессов;

* организация обучения;

* организация преобразования (изменений) процессов;

* организация инноваций и расширений;

  •  управление проектом:

* планирование проекта;

* мониторинг и контроль процессов проекта;

* управление соглашениями с поставщиками;

* интегрированное управление процессами и продуктами проекта;

* управление рисками;

* интеграция команды разработчиков;

* интегрированное управление поставщиками;

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

  •  инженерия (технология):

* управление требованиями;

* разработка требований;

* технические решения;

* интеграция продукта;

* верификация;

* валидация (аттестация, утверждение);

  •  поддержка:

*управление конфигурацией;

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

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

* анализ и принятие решений на изменения;

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

* анализ причин и разрешение проблем (устранение дефектов).

    В пяти приложениях приводятся:

А – состав использованных литературных источников и документов, в котором, однако,  не упоминаются стандарты ISO;

В – сокращения;

С – глоссарий на основе терминологии ISO, применяемой только в четырех  стандартах ISO 9000, ISO 12207,  ISO 15504:1-9, ISO 15288;

D – описания требований и предложений для формирования компонентов модели по уровням зрелости;

Е – список участников разработки CMMI – проекта.

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

     Планирование проекта в этой, также как и во второй модели включает:   

  •  оценку возможного размера – масштаба программного продукта;
  •  оценку сложности функций и характеристик проекта ПС;
  •  определение модели и этапов жизненного цикла комплекса программ;
  •  технико-экономическое обоснование проекта – определение стоимости, трудоемкости и длительности ЖЦ ПС;
  •  разработка поэтапного графика работ и бюджета проекта;
  •  анализ, идентификация и оценка проектных рисков;
  •  планирование и управление документированием процессов и продуктов в ЖЦ проекта ПС;
  •  планирование и распределение технических и людских ресурсов по этапам ЖЦ ПС;
  •  планирование обеспечения знаний и квалификации коллектива специалистов для реализации проекта;
  •  обобщение и анализ совокупности планов проекта ПС;
  •  согласование работ и ресурсов по этапам ЖЦ разработчиком с заказчиком проекта ПС;
  •  документирование плана работ и утверждение его менеджером разработчиков проекта.

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

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

      Управление требованиями в обеих моделях включает:

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

       Второй вариант CMMI представлен документом: Capability Maturity Model Integration for Systems Engineering / Software Engineering / Integrated Product and Process Development, Version 1.1, Staged Representation (CMMI-SE/SW/IPPD, V1.1, Staged) – Интегрированная модель оценивания зрелости инженерии сложных систем / программной инженерии / интегрированных продуктов и процессов разработки – поэтапное представление. Модель базируется на сохранении концепции пяти уровней зрелости CMM. Состав процессов практически повторяет приведенный выше для первого варианта модели, в несколько иной последовательности и с относительно небольшими дополнениями. Первый уровень отличается значительной неопределенностью состава и содержания процессов в различных относительно простых проектах,  поэтому он в документе не описан и не комментируется. Поэтому при  уточнении и детализации содержания процессов в поэтапном варианте CMMI рекомендуется  ограничиваться четырьмя (2-й – 5-й) основными уровнями:

второй уровень – формализует базовое управление проектами:

* управление требованиями;

* планирование проекта;

* мониторинг и контроль проекта;

* управление соглашениями с поставщиками;

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

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

* управление конфигурацией;

третий уровень – содержит стандартизацию  основных процессов:  

* разработка требований;  

* технические решения;

* интеграция продукта;

* верификация;

* валидация (аттестация);

* содержание организационных процессов;

* определение организационных процессов;

* организация обучения;

* интегрированное управление процессами и продуктами проекта;

* управление рисками;

* интеграция команды разработчиков;

* интегрированное управление поставщиками;  

* анализ и разрешение проблем  (устранение дефектов);

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

четвертый уровень – определяет количественное управление:

* организация представления качества процессов;

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

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

       * анализ причин дефектов, совершенствование качества и управления процессами и продуктами.

     Приложения во втором варианте модели подобны по составу, приведенным выше приложениям для первой модели. Рекомендуется на каждом более высоком уровне зрелости применять все процессы предыдущих нижних уровней. В обоих вариантах модели каждый, выделенный выше базовый процесс, комментируется подробными рекомендациями для его практической реализации, которые содержат унифицированные по структуре описания объемом около 20 – 30 страниц:

общие цели процесса, которые должны быть достигнуты;

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

специфические цели процесса;

менеджмент процесса;

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

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

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

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

анализ и валидация (утверждение) результатов реализации процесса;

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

    Эти рекомендации по объему, содержанию и полноте описаний базовых процессов подобны ряду стандартов профиля ЖЦ ПС. Упорядочение и оценка полноты используемых процессов в соответствии с уровнями зрелости, позволяет устанавливать производственный потенциал предприятий – разработчиков программных продуктов по прогнозируемому качеству процессов и результатов их деятельности и готовности к сертификации на соответствие определенному уровню зрелости модели CMMI – 1.1.  

      Особое внимание в моделях CMMI  уделяется процессам менеджмента проекта ПС. Эти требования и процессы моделей практически соответствуют,  регламентированным и детализированным рекомендациям в стандартах ISO 9001:2000,  ISO 12207 и в основных компонентах профиля стандартов жизненного цикла сложных ПС. Требованиям к процессам в функциональных разделах  4 – 8 стандартов ISO 9001, ISO 9004, ISO 90003 может быть сопоставлен адекватный по содержанию ряд разделов в моделях CMMI – рис. 3.2.  Общность процессов и требований состоит в подобии: состава, терминологии, структуры, перечня основных рекомендуемых процессов управления, планирования, учета доступных ресурсов, реализации процессов программной инженерии, оценивания и организации специалистов.       

       С точки зрения поддержки и регламентирования полного жизненного цикла крупных проектов программных средств к недостаткам моделей CMMI относительно профиля существующих стандартов ISO можно отнести следующие:

  •  не все процессы предусмотрены в составе процессов моделей CMMI – 1.1, которые развиваются и детально комментируются для их реализации в стандартах ISO 9004:2000 и ISO 90003:2004, а также в профиле стандартов ISO;
  •  не отражены особенности системной инженерии и международные стандарты,  регламентирующие процессы жизненного цикла сложных систем ISO 15288:2002 и ISO 19760:2003;
  •  при анализе процессов обеспечения качества используется ряд традиционных характеристик систем и программных продуктов, которые применяются в сложных проектах, однако не описаны и не комментируются базовые международные стандарты, систематизирующие и регламентирующие качество программных средств  ISO 9126:1-4,  ISO 14598:1-6,  ISO 15939;  
  •  отсутствуют описания характеристик и конкретных процессов обеспечения информационной и функциональной безопасности программных продуктов и ссылки на многочисленные стандарты в этой области;
  •  не отражены регламентированные интерфейсы Открытых систем на взаимодействие программных компонентов, а также с операционной и внешней средой,  в соответствии со стандартами  ISO 9945:1-4;
  •  документирование процессов и продуктов ЖЦ ПС комментируется только, по мере их реализации, и  не представлены   обобщенные требования к  технологической и эксплуатационной документации на программный продукт в соответствии со стандартами  ISO 9294,  ISO 15910,  ISO 18019.

      Для определения, представленных выше уровней зрелости процессов обеспечения жизненного цикла ПС,  разработан и первоначально утвержден в 1998 году  обширный технический отчет ISO 15504 – Оценка и аттестация зрелости процессов создания и сопровождения ПС и систем,  состоящий из девяти частей и множества приложений.  В нем изложена модель зрелости CMM и восемь базовых принципов программной инженерии на основе стандарта ISO 9000:2000 (см. лекцию 1). Затем в ISO этот документ претерпел коренную переработку, сокращение, упрощение структуры и содержания,  при полном сохранении целей и концепции, и утвержден как стандарт в составе пяти частей (см. Приложение 1).  Стандарт ISO 15504:1-5:2003-2006 регламентирует оценку и аттестацию зрелости процессов создания, сопровождения и совершенствования программных средств и систем, выполняемых предприятиями:

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

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

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

    Аттестация в стандарте рассматривается в двух аспектах: для усовершенствования процессов ЖЦ ПС и систем конкретного предприятия, и для определения соответствия  декларированной зрелости процессов обеспечения проекта или предприятия, реальным используемым процессам. Это отражено в следующих пяти частях стандарта ISO 15504:1-5:2003-2006.

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

     Часть  2  – Выполнение (производство) аттестации – включает детальные требования к проведению процессов аттестации, как основы для  совершенствования и определения уровня зрелости технологических процессов обеспечения ЖЦ ПС и систем.  Документ определяет процессы выполнения аттестации, модели рекомендуемых процессов аттестации и верификации процессов, с тем, чтобы они были объективными, содержательными и репрезентативными.

    Часть 3 – Руководство по производству аттестации – содержит обзор технологии выполнения процессов аттестации зрелости, и интерпретации реализации требований. В нем отражено: исполнение аттестации; измерительные средства для определения процессов зрелости; выбор и применение средств аттестации; оценка компетентности аттестаторов;  верификация соответствия аттестации декларированным требованиям.  Средства аттестации могут использоваться предприятиями при планировании, менеджменте, мониторинге, контроле и усовершенствовании программных продуктов и систем, при их приобретении, разработке, применении и сопровождении.

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

    Часть 5 – Образец модели процессов аттестации на соответствие требованиям, представленным в части 2. Обширный документ (162 стр.) содержит примеры практического применения предыдущих частей стандарта для организации, оценивания и совершенствования аттестации зрелости процессов жизненного цикла для различных областей использования, проектов программных средств и предприятий.

     При  практической реализации проектов и обеспечении жизненного цикла сложных ПС разработчикам и поставщикам может быть трудно определить, и выделить для применения преимущества моделей  CMMI. В зависимости от традиций предприятия и особенностей крупного проекта ПС зачастую  целесообразно использовать как основной полный профиль стандартов ISO, а для оценивания заказчиками уровня зрелости менеджмента, организационного и технологического обеспечения проектов ПС применять конкретные рекомендации CMMI. Эти рекомендации могут эффективно использоваться при сертификации  качества процессов на предприятиях, обеспечивающих ЖЦ ПС, как альтернатива или наряду с сертификацией по комплексу стандартов менеджмента ISO 9000, в зависимости от особенностей проекта и требований заявителя на сертификацию программного продукта или технологии обеспечения его жизненного цикла.

      3.2.  Стандарты менеджмента (административного управления)                   качеством систем     

      

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

  •  ISO 9000:2000 – представляет  введение в системы управления  качеством продукции и услуг и словарь качества;
  •  ISO 9001:2000 – устанавливает  детальные требования для систем управления качеством, достаточные в случае необходимости продемонстрировать способность предприятия, обеспечить соответствие качества продукции и услуг требованиям заказчика;
  •  ISO 9004:2000 – содержит  руководство по внедрению и применению широко развитой системы управления качеством, чтобы достичь постоянного улучшения деловой деятельности и результатов предприятия.

Стандарты серии ISO 9000:2000 применяют процессный подход в административном управлении системами  качества предприятий, а также рассматривают способы быстрого выявления и реализации возможностей для их улучшения. Процессная модель подчеркивает тот факт, что заказчики и другие заинтересованные стороны играют значительную роль в процессе установления исходных требований. После этого по отношению ко всем процессам, необходимым для создания необходимой продукции, применяется управление процессами и проводится проверка “выходов”. Измерение степени удовлетворенности заказчика и других заинтересованных сторон используется в качестве обратной связи для оценки и признания того, что требования заказчика были выполнены полностью.

В стандарте ISO 9004 детализированы руководящие указания и рекомендации по применению системы менеджмента качества, которые изложены в том же порядке, как требования в ISO 9001.  Оба стандарта ссылаются на ISO 9000,  который объясняет используемую терминологию и определения. Структура основных требований и рекомендаций в этих стандартах сведена к четырем объединенным крупным процессам (рис. 3.2):

  •  обязанности и ответственность администрации управления качеством (раздел 5);
  •  административное управление ресурсами (раздел 6);
  •  процессы жизненного цикла продукции и управления ее качеством (раздел 7);
  •  измерения, анализ и совершенствование продукции (раздел 8).

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

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

      Для освоения и облегчения применения стандартов в редакции 2000-го года, в приложении к  ISO 9001:2000 приведены таблицы, отражающие взаимное соответствие требований этого стандарта и требований ISO 9001:1994. Таблицы могут использоваться при необходимости подтверждения в настоящее время сертификатов качества, полученных ранее на основании применения стандартов в редакции 1994-го года.  Это позволяет сохранять и практически использовать всю технологическую документацию и рабочие инструкции, базирующиеся на стандартах качества 1994-го года, дополняя их только этими таблицами соответствия требований.

Стандарт ISO 9001:2000 – Система  менеджмента (административного управления) качества. Требования  – является базой для Руководства по их реализации в стандарте  ISO 9004:2000 и кратко изложены ниже (см. рис. 3.2).    

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

       Высшее руководство предприятия – разработчика должно продемонстрировать свои обязательства заказчику относительно:

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

  Требования заказчика – высшее  руководство должно обеспечить, что:

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

Высшее руководство должно разработать политику в области качества и обеспечить уверенность в том, что она:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Организация должна создать процесс идентификации требований заказчика:

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

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

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

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

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

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

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

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

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

    На соответствующих этапах должен проводиться систематический анализ проекта для: оценки возможности выполнения требований к качеству; идентификации проблем – дефектов и выработки предложений по разработке решений для их устранения.  В состав участников анализа проекта должны включаться представители служб, связанных с анализируемым этапом проектирования. Должна быть спланирована и выполнена проверка проекта и/или разработки, обеспечивающая уверенность в том, что выходные данные соответствуют входным требованиям.

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

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

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

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

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

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

     Меры по утверждению процессов должны быть направлены на: аттестацию процессов до их использования; аттестацию оборудования и/или персонала.

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

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

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

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

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

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

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

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

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

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

        Стандарт ISO 90003:2004 – Рекомендации по применению стандарта ISO 9001:2000 для программных средств – предназначены для регламентирования менеджмента при приобретении, поставке, разработке, применении, сопровождении сложных программных средств и при их обслуживании.  Стандарт не содержит ограничений и изменений базовых требований  ISO 9001:2000 и предлагается при установлении соответствия требованиям комплексов программ:

  •  как части коммерческого контракта с другими организациями;
  •  при представлении полезного продукта для рынка;
  •  для использования при поддержке процессов организации проектов ПС;
  •  для учета при встраивании программных средств в комплексы аппаратуры;
  •  при организации сервиса программных продуктов.

    Полное или частичное применение стандарта ISO 90003 целесообразно в различных ситуациях, с учетом технологии, модели жизненного цикла, процессов разработки, последовательности действий и организационной структуры предприятия. Его рекомендуется применять как поддержку процессов программной инженерии в ISO 9001:2000,  совместно со стандартами ISO 12207, ISO 15504, ISO 9126, ISO 14598,  ISO 15939.

       Первые четыре раздела практически повторяют содержание аналогичных разделов в ISO 9001:2000. Структура стандарта ISO 90003:2004 привязана к разделам и требованиям в ISO 9001:2000, которые цитируются в начале каждого раздела. Пятый раздел определяет ответственность руководства: общие обязанности руководства управления проектом; политику в области обеспечения качества продукции; планирование управления проектом; ответственность и полномочия специалистов; анализ проектирования со стороны руководства. Формулировки в ISO 90003 повторяют содержание основного стандарта с очень небольшими комментариями.

       В шестом разделе – менеджмент ресурсов, более полно комментируются особенности управления ресурсами в области программной инженерии. Внимание акцентируется: на проблемах обеспечения ограниченными вычислительными ресурсами инфраструктуры проектов; на компетентности, квалификации и подготовке специалистов; на управлении производственной средой. При этом неоднократны подробные ссылки на требования стандартов ISO 12207, ISO 15504, ISO 9126, ISO 14598 (см. Приложение 1).  

       Наиболее обширным и специфическим, практически полностью ориентированным на программные продукты, является седьмой раздел стандарта. В нем изложено планирование и управление процессами и качеством жизненного цикла программных средств с попутными ссылками на рекомендации перечисленных выше стандартов. Рекомендации проектирования и разработки имеют традиционную структуру жизненного цикла ПС: входные и выходные данные процессов; анализ требований; верификация и валидация результатов; управление изменениями и сопровождение; мониторинг и измерение результатов. При этом формулировки и цитаты разделов ISO 9001 отходят на второй план. Небольшой восьмой раздел посвящен измерениям, анализу и совершенствованию процессов и результатов управления проектами программных продуктов и почти не связан с требованиями ISO 9001.

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

        Практически все перечисленные процессы и требования стандартов в данном разделе,  конкретизированы в очень подробных рекомендациях процессов (около 500 страниц – седьмой раздел) трех выделенных выше уровней модели CMMI (см. п. 3.1). Они соответствуют,  регламентированным и детализированным рекомендациям в стандартах ISO 9001:2000,  ISO 12207 и основных компонентах профиля стандартов жизненного цикла сложных ПС (см. лекцию 2). Требованиям в функциональных разделах 4 – 8 стандарта ISO 9001 могут быть сопоставлены подобные по содержанию разделы в поэтапной модели CMMI. Общность процессов и требований состоит в подобии: терминологии, структуры, рекомендуемых процессов управления, планирования, учета доступных ресурсов, реализации процессов, оценивания и организации специалистов. Процессы, которые развиваются и детально комментируются процессами их реализации в стандартах ISO 9004:2000 и ISO 90003:2004, а также в представленном выше профиле, включающем около пятидесяти стандартов ISO (см. Приложение 1), однако не всегда предусмотрены в рекомендациях и ссылках CMMI.

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

При подготовке системы качества предприятия, целесообразно учитывать и использовать совокупность рекомендаций ряда стандартов, поддерживающих и детализирующих базовые стандарты серии ISO 9000, в которую входят – ISO 10005, ISO 10006, ISO 10013, ISO 10011.  

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

 В стандарте ISO 10013:1995 – Руководящие указания по разработке руководств по качеству – изложены рекомендации по подготовке конкретного Руководства по качеству, адаптированного к определенным потребностям предприятия и пользователей. Созданное в результате Руководство должно отражать документированные процедуры системы качества конкретного предприятия или проекта в соответствии с общими требованиями стандартов серии ISO 9000. В этом документе должны быть изложены: цели конкретной системы качества проекта или предприятия; документированные процедуры этой системы; организация процессов утверждения, изменения и применения данного Руководства. В стандарте предложена подробная типовая структура и рекомендуемое содержание разделов такого документа.  

         В стандарте  ISO 10005:1995 – Административное управление качеством.  Руководящие указания по Программе качества –  представлены  конкретные рекомендации по структуре и содержанию разделов в Программе обеспечения качества продукции, в соответствии с базовыми требованиями стандарта ISO 9001,  а также примеры документального оформления таких Программ.  Для эффективного применения его следует адаптировать к характеристикам объектов и среды применения конкретного предприятия или проекта. Прежде всего, необходимо оставить в рабочей версии этого стандарта разделы и положения, которые целесообразно непосредственно использовать для обеспечения качества конкретных изделий. Адаптация стандарта для конкретных предприятий или проектов может выполняться путем сокращения и конкретизации некоторых положений. После этого Программа качества должна быть сформирована и оформлена как самостоятельный регламентирующий документ, согласована с заказчиком, утверждена руководством предприятия и доведена до сведения всех участников проекта для практического применения. При сертификации системы качества предприятия должно проверяться наличие и практическое использование всех положений утвержденной рабочей версии Программы качества.

         Группа  стандартов  ISO 10011:1-3:1990 – Руководящие положения по проверке систем качества – определяет основные требования к процессам и специалистам по оценке систем качества предприятия на соответствие стандартам серии ISO 9000. В них изложены основные принципы, критерии и методики, а также руководящие положения для разработки, планирования и ведения документации при проверке систем качества предприятия. Определены обязанности и ответственность независимых инспекторов по проверке системы качества, требования к ним, порядок и критерии оценки и выбора инспекторов, их аттестации и условия выдачи свидетельств для допуска к инспектированию. Для независимой и объективной оценки системы качества предприятия или проекта рекомендуется проводить специальный отбор испытателей – инспекторов по сертификации. В соответствии со стандартом ISO 10011-2 кандидаты в инспекторы по проверке систем качества должны продемонстрировать способность четко и быстро выражать концепции и идеи в устной и письменной форме. Они должны пройти обучение, дающее им знания и квалификацию, необходимые для проведения испытаний и управления проверками систем качества.

3.3. Стандарты открытых систем, регламентирующие структуру и                            интерфейсы  программных средств

        Рядом зарубежных организаций и промышленных фирм под руководством IEEE с 1990 года ведется активная разработка последовательных  версий стандартов интерфейсов открытых систем POSIX (Portable operating system interfaces). Выполнена большая работа по пересмотру, расширению и реорганизации около двадцати базовых спецификаций POSIX 1990 - 1998 года IEEE 1003.  Улучшена систематизация и структура стандартов, усовершенствовано удобство их применения пользователями. В результате подготовлен комплексный проект фундаментального международного стандарта из четырех крупных частей ISO 9945:1-4:2003 (IEEE 1003.1 – 2003),  объемом свыше трех тысяч страниц.  Настоящий стандарт совместная разработка IEEE и The Open Group, он является одновременно стандартом IEEE, стандартом ISO и стандартом Open Group Technical.

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

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

       При формировании концепции стандартов POSIX  были поставлены  следующие задачи:

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

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

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

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

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

     Новую версию международных стандартов POSIX составляют аннотированные ниже четыре части стандартов ISO 9945:1-4:2003 – ИТ. Интерфейсы переносимых операционных систем. Ч.1. Базовые определения. Ч.2. Системные интерфейсы. Ч.3. Команды управления и сервисные программы. Ч 4. Обоснование.

     Стандарт ISO 9945-1:2003 содержит основные концептуальные определения и подробные пояснения методов реализации интерфейсов для обеспечения мобильности компонентов и комплексов программ, общее для всех томов оглавление стандарта, в том числе сервисные соглашения и определения заголовков языка Си. В большом разделе  концепция изложены: базовые директории; файловая иерархия; сетевое взаимодействие; измерение времени и синхронизация; процессы повторного использования компонентов; политика очередей и применение семафоров. Далее выделены разделы:

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

       Стандарт ISO 9945-2:2003   Системные интерфейсы –  уточняет и детализирует: концепцию переносимости и принципы её обеспечения путем унификации интерфейсов прикладных программ с операционными  системами, функции обслуживания, ориентированные на язык программирования Си, функциональные вопросы, в том числе мобильность, обработка ошибок, и устранение ошибок.  Он содержит три крупных раздела:

  •  введение;
  •  содержание основной информации;
  •  системные интерфейсы.

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

      Языково-ориентированные услуги  и интерфейсы для языка Си в  стандарте состоят из двух частей: ядра взаимодействующего с ядром  операционной системы на языке Си и расширения для взаимодействия с прикладными программами,  реализованными на различных языках.  Первоначальная, жесткая ориентация  стандартов POSIX на ОС UNIX  в последующем изменилась и расширилась на любые операционные среды, обеспечивающие реализацию концепции открытых систем. Отмечается целесообразность применения для взаимодействия с внешней средой  концепции  и  совокупности стандартов, являющихся развитием базовой эталонной  модели  взаимосвязи открытых систем (ВОС)  ISO 7498.

       В третьей части стандарта  ISO  9945-3:2003 – Основные   команды управления и сервисные программы (Shell and utilities) – изложено конкретное представление команд операционной системы и утилит,  обеспечивающих унифицированное взаимодействие с мобильными прикладными  программами, определения для стандартного источника кодового уровня интерфейса командного интерпретатора ("shell") и стандартные утилиты для прикладных программ. Стандарт содержит четыре раздела:

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

       Цель этой части стандарта конкретизировать интерфейсы прикладных программ на уровне команд,  для интерпретатора командного языка, и полный набор сервисных программ – утилит. Он специфицирует интерфейсы операционных систем на уровне программных  текстов и кодов. Стандартизированный командный язык  Shell – средство для подготовки небольших мобильных процедур и их быстрой интерактивной отладки. В развитой среде,  возможно объединять команды в цепочки с фильтрацией промежуточных результатов. Каждая утилита содержит: описание структуры; применение; операнды; входные файлы; окружение. Факультативные утилиты расширяют возможности для пользователей мобильных приложений по связи с внешним окружением. В терминах языка Си (стандарт ISO 9899:1990) описаны языково-независимые услуги интерфейсов для переносимых приложений и связи  с внешним  окружением  при представлении интерфейсов приложений на различных языках высокого уровня. Команды и  утилиты  содержат конкретные механизмы на уровне операторов для выполнения операций:  сравнения, вывода на печать и на экран файлов,  редактирования файлов, вычисления выражений, сортировки данных, определения очередности исполнения сигналов и доступа  к  информации  о среде.  Можно выделить:

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

     Четвертая часть стандарта ISO  9945-4:2003 – Обоснование – содержит группу из пяти крупных приложений:

  •  обоснование базовых определений – приложение А;
  •  обоснование системных интерфейсов – приложение В;
  •  обоснование команд управления и сервисных программ-утилит – приложение С;
  •  рассмотрение переносимости – приложение D;
  •  рассмотрение субпрофилей – приложение Е.

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

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

      В стандарте ISO 14252:1996  Руководство по POSIX окружению открытых систем (OSE) – изложена идеология и  модель  создания мобильных программных средств,  которое детализирует для пользователей модель комплекса стандартов POSIX, а также взаимодействующих  с ними стандартов де-юре, де-факто и спецификаций, необходимых для создания переносимых приложений. Модель отражает принципы построения интерфейсов прикладных программ с платформой операционной системой, через которую  осуществляется  взаимодействие с компонентами внешнего окружения. Считается, что прикладные программы непосредственно не взаимодействуют с внешним окружением,  а связаны с ним только через операционную систему. Разработка приложений предполагается в кросс-режиме, то есть платформа разработки – инструментальная может не совпадать с платформой исполнения (применения) программ (объектной – целевой). Результат компиляции программы на инструментальной платформе  может быть перенесен для исполнения на целевую платформу.

    Определяющими являются два интерфейса между тремя базовыми компонентами: между  прикладными  программами  и платформой    операционной  системой (API) и между платформой и внешним окружением (EEI).  Определены  общие  функции услуги платформы  для  этих взаимодействий. Внешнее окружение включает компоненты человеко-машинного взаимодействия с пользователями, компоненты информационного взаимодействия с внешними устройствами ЭВМ и с компонентами, обеспечивающими коммуникацию с внешней средой. Эти интерфейсы  и  услуги  более детально формализованы соответствующими стандартами POSIX.

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

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

      Стандарт  ISO 13210:1998  Методы тестирования для оценки  соответствия стандартам POSIX  содержит общую методологию  тестирования  для  проверки  соответствия интерфейсов прикладных программ стандартам POSIX.  Представлены принципы  формирования  наборов  тестов  и предлагается методика развития системы тестов для контроля создаваемых  приложений  на соответствие ISO 9945.  В методе тестирования выделены: подготовка тестов; процедуры  тестирования; оформление  документов, удостоверяющих  соответствие  стандартам. Определены  и  кратко представлены три основных уровня сложности тестирования:  исчерпывающий;  достаточно полный; оценочный – для установления общих характеристик качества.  Подчеркивается, что предлагаемые методы не  гарантируют абсолютное соответствие стандартам,  так как исчерпывающее тестирование невозможно по техническим и экономическим причинам. Приводятся рекомендации по:

  •  классификации тестовых сценариев и утверждений;
  •  подготовке описаний  детерминированных  тестов и тестов для проверки структурных конструкций;
  •  кодированию и  представлению  результатов  тестирования  во взаимосвязи с исходными тестами;
  •  формированию удостоверения о соответствии интерфейсов прикладных программ стандартам POSIX.

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

       

 

      


 

А также другие работы, которые могут Вас заинтересовать

4584. Знайомство з системою комп’ютерної математики - математичною матричною лабораторією MATLAB 232.5 KB
  Знайомство з системою комп’ютерної математики - математичною матричною лабораторією MATLAB. Мета роботи: Ознайомитися з основними елементами і складовими частинами системи комп’ютерної математики MatLab® і її робочим і програмним середовищ...
4585. Планування модельних експериментів. Стратегічне планування модельного експерименту 101 KB
  Планування модельних експериментів. Стратегічне планування модельного експерименту. Мета роботи: Ознайомитися з методами стратегічного планування імітаційних експериментів. Планування модельних експериментів Припустимо, три юні натураліст...
4586. Методи управління модельним часом: моделювання з постійним кроком і по особливих станах 101 KB
  Методи управління модельним часом: моделювання з постійним кроком і по особливих станах. Мета роботи: Вивчити методи управління модельним часом. Ознайомитися і програмно реалізувати алгоритми управління модельним часом з постійним кроком і по особли...
4587. Субтрактивне змішування кольорів. Диск Максвелла 38.52 KB
  Субтрактивне змішування кольорів. Диск Максвелла. Виконання роботи. Визначення координат ахроматичної точки. Підібрали такі розміри зовнішніх секторів з кольорами Cyan, Magenta, Yellow, що їх суміш дала ахроматичний колір. Отримали наступні коорд...
4588. Розрахунок припусків на механічну обробку оптичних деталей 47 KB
  Розрахунок припусків на механічну обробку оптичних деталей Мета роботи: Ознайомити студентів з методикою розрахунків припусків на розміри оптичних поверхонь деталей при їх обробці в оптичному виробництві. Завдання 1. Ознайомитись з видами припусків ...
4589. Інсталювання та налагодження мережевих компонент однорангової мережі Windows 9x. 103 KB
  Інсталювання та налагодження мережевих компонент однорангової мережі Windows 9x, Робота в одноранговій мережі. Керування доступом на рівні ресурсів. Використання спільних каталогів та мережевого принтера. Методичні вказівки з курсу Операційні ...
4590. Повышение эффективности разработки Приобского месторождения за счет оптимального подбора параметров работы электропогружных установок 3.05 MB
  Погруженные центробежные насосы (УЭЦН) в настоящее время являются одним из основных средств механизированной эксплуатации нефтяных скважин. На их долю приходится более 53% добываемой в России нефти и более 63% извлекаемой из скважин жидкости...
4591. Уточнения должностных функций, выполняемых менеджером по обучению персонала на предприятии ООО Техно-регион 183.99 KB
  Введение Развитие персонала является важнейшим условием успешного функционирования любой организации. Это особенно справедливо в современных условиях, когда ускорение научно-технического прогресса значительно убыстряет процесс устаревания профессион...
4592. Диссертация магистранта, аспиранта, докторанта 3.27 MB
  Настоящее пособие дает представление о специфике и месте диссертации магистранта, аспиранта и докторанта в системе научного исследования. В нем выделены этапы исследования, для каждого из которых разработаны ментальные карты, чем пособие выгодно отл...