Номенклатура показателей качества 5 страница

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

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

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

· для организации и координации этой деятельности специалистов-разработчиков необходимы квалифицированные менеджеры проектов;

· в проектах сложных ПС и БД с множеством различных функциональных компонентов участвуют специалисты разной квалификации и специализации, от которых требуется высокая ответственность за качество результатов деятельности;

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

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

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

· заказчики определяют и несут ответственность за финансирование, требования к функциям и качеству программного продукта и за доступные ресурсы для обеспечения его ЖЦ;

· разработчики отвечают и гарантируют выполнение требований заказчиков в ЖЦ программного продукта с учетом выделенных ресурсов;

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

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

Основная цель современных технологий поддержки ЖЦ ПС состоит в обеспечении экономической, технической и социальной эффективности всего ЖЦ комплексов программ для ЭВМ в различных проблемно-ориентированных областях.

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

2.4. Методическая основа технологии жизненного цикла программных средств

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

· процессов разработки программ,

· их структурного построения,

· интерфейсов с операционной и внешней средой.

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

Методология обеспечения качества ПС поддержана рядом методических документов и инструментальных средств, а также формализована группой международных стандартов. Концептуальные и организационные основы административного управления ЖЦ и качеством ПС определены в восьми базовых принципах, которые декларированы в стандартах ИСО 9000:2000 (см. п.1.5.1) и ISO 15504:1–9:1998 и составляют основу технологических процессов в этих стандартах:

· ориентация предприятия–разработчика на потребителя–заказчика;

· лидерство–руководство;

· вовлечение персонала;

· процессный подход;

· системный подход к административному управлению;

· постоянное усовершенствование;

· подход к принятию решений, основанный на фактах;

· взаимовыгодные отношения с поставщиками.

Каждый из этих принципов рекомендуется применять при:

· формулировке политики и стратегии обеспечения всего ЖЦ ПС;

· выборе целей проекта и плановых характеристик качества ПС;

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

· управлении ресурсами и специалистами предприятия для обеспечения ЖЦ ПС и его качества.

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

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

· предотвращать дефекты проектирования за счет систем обеспечения качества, эффективных технологий и инструментальных средств автоматизации всего ЖЦ комплексов программ и БД;

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

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

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

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

Основными целями, упорядочивания, регламентирования процессов и применения стандартов в ЖЦ ПС являются:

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

· повышение качества разрабатываемых и/или применяемых компонентов и ПС в целом при их приобретении, разработке, сопровождении и эксплуатации;

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

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

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

Методы и процессы регламентирования ЖЦ ПС обеспечивают:

· расширение и совершенствование функций систем и компонентов с сохранением их целостности и первичных затрат;

· систематическое повышение качества функционирования комплексов программ и БД в различной внешней среде;

· улучшение технико-экономических характеристик применения систем и программных продуктов;

· совершенствование технологий обеспечения ЖЦ сложных систем и комплексов программ.

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

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

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

· необходимо обеспечивать эффективное использование ресурсов в ЖЦ системы и минимизировать интегральные затраты на обработку данных в типовых режимах ее функционирования;

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

· для обеспечения перспективы развития ЖЦ системы и комплекса программ целесообразно предусматривать возможность интеграции гетерогенных вычислительных компонентов и возможность переноса ПС и БД на различные аппаратные и операционные платформы на основе концепции и стандартов открытых систем;

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

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

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

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

2.6. Структура профилей стандартов жизненного цикла программных средств

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

· процессы ЖЦ систем на основе стандартов ISO 9000 и ISO 15288;

· аппаратную и операционную среду сложных систем определенных классов;

· внешнюю и пользовательскую среду функционирования и применения систем;

·

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

Рис.2.1. Основные общесистемные стандарты ЖЦ ПС

 

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

· процессы ЖЦ ПС и БД на основе стандарта ISO/IEC 12207, а также Руководства по применению этого базового стандарта;

· административное управление качеством ПС и основных компонентов;

· интерфейсы переносимых открытых систем и компонентов;

· оценивание характеристик качества ПС и информации БД;

· верификацию и тестирование программных компонентов, комплексов и информации БД;

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

· сопровождение и управление конфигурацией ПС и информацией БД;

· документирование ПС и информации БД.

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

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

· визуализацию информации для пользователей и обеспечения ЖЦ ПС;

· защиту информационных ресурсов от несанкционированных вмешательств и криптографии;

· телекоммуникацию и взаимодействие с внешней средой.

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

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

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

Рис.2.2. Профили стандартов ЖЦ ПС

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

2.7.1. Стандарт ISO/IEC 12207

Разрешением проблем стандартизации ЖЦ ПО явилась разработка и принятие в 1995г. стандарта ISO/IEC 12207 – Information Technology – Software Life Cycle Processes. В 2000г. он был принят как «ГОСТ 12207. Процессы жизненного цикла программных средств», который предназначен не только для разработчиков, но и для заказчиков, пользователей, всех заинтересованных лиц. Основными результатами стандарта ISO/IEC 12207 являются:

· введение единой терминологии по разработке и применению ПО;

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

· описание организации ЖЦ и его структуры (процессов);

· выделение процесса адаптации стандарта для построения конкретных моделей ЖЦ.

В стандарте ISO/IEC 12207 дается ряд определений.

Программный продукт (software product) – набор машинных программ, процедур и, возможно, связанных с ними документации и данных.

Жизненный цикл программного продукта (software life cycle) – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации

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

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

Структура процессов ЖЦ ПО согласно стандарта ISO/IEC 12207 представлена в табл.2.1.

 

Таблица 2.1

Группы процессов ЖЦ ПО

Основные	Вспомогательные	Организационные
Заказа	Документирования	Управления
Поставки	Управления конфигурацией	Создания инфраструктуры
Разработки	Обеспечения качества: · верификации, · аттестации, · совместного анализа, · аудита	Усовершенствования
Эксплуатации	Обучения
Сопровождения
Решения проблем
Процесс адаптации

 

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

К числу основных относятся процессы:

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

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

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

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

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

Вспомогательными процессами являются:

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

· Управления конфигурацией. Определяет работы по управлению конфигурацией.

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

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

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

· Совместного анализа. Определяет работы по оценке состояния и результатов какой–либо работы. Данный процесс может использоваться двумя любыми сторонами, когда одна из сторон (проверяющая) проверяет другую сторону (проверяемую) на совместном совещании.

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

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

Организационные процессы жизненного цикла:

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

· Создания инфраструктуры. Определяет основные работы по созданию основной структуры процесса жизненного цикла.

· Усовершенствования. Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.

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

2.7.2. Стандарт ISO 15504

Стандарт ISO/IEC 12207 разрабатывался 9 лет и достаточно быстро устарел. В 1998г. выходит новый стандарт ISO/IEC TR 15504: Information Technology – Software Process Assessment (Оценка процессов разработки ПО). В этом документе рассматриваются вопросы аттестации, определения зрелости и усовершенствования процессов ЖЦ ПО. Один из разделов документа содержит новую классификацию процессов ЖЦ, являющуюся развитием стандарта ISO/IEC 12207.

Связь со стандартом ISO/IEC 12207 состоит в том, что все процессы стандарта ISO 15504 принадлежат к одному из следующих типов:

· базовый – процесс из ISO/IEC 12207;

· расширенный – расширение процесса из ISO/IEC 12207;

· новый – процесс, не описанный в ISO/IEC 12207;

· составляющий – часть процесса из ISO/IEC 12207;

· расширенный составляющий – расширенная часть процесса из ISO/IEC 12207.

Классификация процессов приведена в табл.2.2. В соответствии с новой классификацией в трех группах процессов вводятся пять категорий процессов.

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

 

Таблица 2.2

Классификация процессов ЖЦ ПО

Тип процесса	Процесс, подпроцесс
Категория CUS: Потребитель–поставщик
Базовый	CUS.1 Приобретения
Составляющий	CUS.1.1 Подготовки приобретения
CUS.1.2 Выбора поставщика
CUS.1.3 Мониторинга поставщика
CUS.1.4 Приемки
Базовый	CUS.2 Поставки
Новый	CUS.3 Процесс выявления требований
Расширенный	CUS.4 Эксплуатации
Расширенный составляющий	CUS.4.1 Процесс эксплуатационного использования
CUS.4.2 Процесс поддержки потребителя
Категория ENG: Инженерные процессы
Базовый	ENG.1 Процесс разработки
Составляющий	ENG.1.1 Процесс анализа требований и разработки системы
ENG.1.2 Процесс анализа требований к программным средствам
ENG.1.3 Процесс проектирования программных средств
ENG.1.4 Процесс конструирования программных средств
ENG.1.5 Процесс интеграции программных средств
ENG.1.6 Процесс тестирования программных средств
ENG.1.7 Процесс интеграции и тестирования системы
Базовый	ENG.2 Процесс сопровождения системы и программных средств
Категория SUP: Вспомогательные процессы
Расширенный	SUP.1 Процесс документирования
Базовый	SUP.2 Процесс управления конфигурацией
SUP.3 Процесс обеспечения качества
SUP.4 Процесс верификации
SUP.5 Процесс проверки соответствия
SUP.6 Процесс совместных проверок
SUP.7 Процесс аудита
SUP.8 Процесс разрешения проблем
Категория MAN: Управленческие процессы
Базовый	MAN.1 Процесс административного управления
Новый	MAN.2 Процесс управления проектами
MAN.3 Процесс управления качеством
MAN.4 Процесс управления рисками
Категория ORG: Организационные процессы
Новый	ORG.1 Процесс организационных установок
Базовый	ORG.2 Процесс усовершенствования
Составляющий	ORG.2.1 Процесс создания процессов
ORG.2.2 Процесс аттестации процессов
ORG.2.3 Процесс усовершенствования процессов
Расширенный	ORG.3 Процесс административного управления кадрами
Базовый	ORG.4 Процесс создания инфраструктуры
Новый	ORG.5 Процесс измерения
ORG.6 Процесс повторного использования

 

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

Категория SUP: Вспомогательные процессы состоит из процессов, которыми могут пользоваться любые другие процессы (включая другие вспомогательные процессы) в различные моменты ЖЦ ПС.

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

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

· создают инфраструктуру организации;

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

· делают это общедоступным в рамках всей организации;

· создают базу для постоянного совершенствования во всей организации.

2.8. Модель жизненного цикла программного продукта

2.8.1. Схема модели

Модель ЖЦ ПО описывает набор фаз (этапов, стадий) проекта по созданию ПО, в которых выполняются отдельные процессы, разбитые на операции и задачи. Приведем определения этих понятий.

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

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

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

В этих определениях существенным является следующее:

· состав, количество и порядок выполнения фаз определяется особенностью проекта;

· каждая фаза завершается получением одного из основных результатов, в то время как процесс или задача – просто значимого результата

Для схемы модели ЖЦ ПО (рис.2.3) характерно следующее:

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

2. Результат выполнения каждой фазы является входом следующей фазы и фазы должны выполняться в определенной моделью ЖЦ последовательности.

Рис.2.3. Схема модели ЖЦ ПО

 

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

В стандарте ISO/IEC 12207 модель жизненного цикла (life cycle model) определяется как структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования. При этом, конкретные модели определяются особенностью задач, ограничениями на ресурсы, опытом разработчиков и т.д..