Руководство по качество для it компании

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

Среди всех стандартов в области разработки программного
обеспечения, используемых в настоящее время в мире, наиболее популярными
моделями являются: ISO 9001, TickIT, SEI SW-CMM. В наших статях вы найдете
не только ссылки на широко применяемые стандарты, связанные с ними
рекомендательные стандарты, статьи и обзоры по ним, но и познакомитесь
вкратце с их общими положениями.

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

Стандарты ISO
серии 9000

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

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

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

Стандарт TickIT

Достаточно широкую известность получил британский стандарт
TickIT. Этот отраслевой стандарт регламентирует требования к системе
качества для организаций разработчиков программного обеспечения и
базируется на модели ISO 9001:94. В отличие от модели ISO 9001, которая
регламентирует «что необходимо сделать», разработчики данного стандарта
попытались ответить на вопрос «как» можно выполнить требования,
определенные в ISO 9001. TickIT объединяет в себе модель ISO 9001 с
набором рекомендательных стандартов ISO 12207 и ISO 9000-3.

Стандарты SEI SW-CMM

Очень интересный подход к улучшению внутренних процессов
разработки программного обеспечения определен в модели SEI SW-CMM. В
основу данной модели (также как и в основу стандартов ISO серии 9000)
положена теория TQM. Теория TQM основывается на постепенном улучшении
внутренних производственных процессов за счет множества небольших
внедряемых в компании улучшений. Однако, модели ISO и CMM несколько
различаются в своих подходах к построению самосовершенствующихся систем
управления качеством и улучшению производственных процессов.

В отличие от модели ISO, где для того, чтобы соответствовать
требованиям, необходимо продемонстрировать 100%-ное соответствие модели (и
только оно позволяет компании самосовершенствоваться), в модели SEI SW-CMM
предусмотрен поэтапный подход к построению системы совершенствования
процессов. Для достижения этой цели разработчики стандарта СММ определили
пять уровней, которые должна пройти организация для того, чтобы достичь
основной цели — повышения эффективности функционирования процессов
компании и, как следствие, улучшения качества результатов производственных
процессов и разрабатываемого программного обеспечения.

Стандарты по Project Management

Одним из важных моментов, который необходимо иметь в виду при
внедрении каких-либо стандартов (ISO 9000, SEI SW-CMM, TickIT, Spice ISO
15504 и т.п.), связан с тем, что структура производства компаний,
разрабатывающих программное обеспечение, связана со спецификой продукта.
Каждый продукт, разрабатываемый IT-компанией, уникален. И для его
разработки, как правило, используется проектный тип организации
производства, который тесно связан с матричной структурой управления
проектами.

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

176 комитет ISO разработал рекомендательный стандарт ISO
10006 «Менеджмент качества. Руководство качеством при управлении
проектами», который определяет основные подходы к управлению проектами и
определяет его место в модели обеспечения качеством. Авторы стандартов ISO
серии 9000 определяют процесс управления проектами как часть системы
менеджмента качества. С другой стороны, возможен и противоположный взгляд
(которого придерживаются оппоненты стандартов ISO серии 9000), согласно
которому менеджмент качества является одной из составной частей системы
управления проектами.

Управление проектами является скелетом производства в
организациях разработчиков программного обеспечения. Поэтому
неудивительно, что для приведения в соответствие системы управления
качеством производства к требованиям модели ISO 9001 и к требованиям
модели улучшения процессов производства SEI SW-CMM использование
стандартов и признанных в мире технологий по управлению проектами является
краеугольным камнем развития внутренних технологий в IT-компаниях.

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

Рис.1. Система стандартов для IT-индустрии

Также на сайте:
Формирование системы менеджмента качества вуза
«Мягкое» внедрение изменений в организации

2022/10/25 12:30:59

Как сделать обеспечение качества ПО приоритетом в каждом ИТ-проекте компании

Для создания надёжного ИТ-продукта команде разработчиков программных продуктов необходимы знания и опыт инженеров по обеспечению качества. Денис Кульчавый, заместитель генерального директора и ведущий технический эксперт в QA-компании «Точка качества», дал несколько рекомендаций по внедрению высокой культуры тестирования и обеспечения качества в процесс разработки ПО.

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

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

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

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

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

Кто входит в команду обеспечения качества ПО

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

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

• Разработчики пишут код, на основе которого создаётся программный продукт. Они активно работают над улучшением кода и дальнейшим повышением качества вместе с ведущим разработчиком.
• Ведущий разработчик ПО взаимодействует с менеджером по обеспечению качества, чтобы ИТ-решения соответствовали заданным стандартам и требованиям.
• Менеджер по обеспечению качества сотрудничает с инженерами по части контроля выполнения задач в соответствии с планом тестирования, чтобы, в конечном итоге, получить продукт, отвечающий требованиям заказчика.
• Менеджер курирует проект в целом и контролирует внедрение стандартов обеспечения качества на каждом этапе жизненного цикла разработки.

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

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

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

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

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

Как сформировать культуру обеспечения качества ПО

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

• Нанимайте людей, которые ценят обеспечение высокого качества в разработке ПО и привержены ему.
• Не сваливайте заботу об обеспечении качества целиком на плечи команды разработчиков. Внедряйте культуру на всех этапах разработки продуктов. И создайте, наконец, отдел по обеспечению качества ПО.
• Отдавайте приоритет качеству и устанавливайте реалистичные ожидания в отношении сроков реализации проекта.
• Обучите команду обеспечению качества ПО и донесите до всех участников важность таких её техник, как проверка кода, автоматизированное тестирование, CI/CD и т.д. Убедитесь, что исходный код выпущен только после того, как он прошёл автоматические тесты.
• Внедряйте автоматизацию тестирования везде, где это возможно и рационально. Правильно внедрённая автоматизация повысит качество и сэкономит вам время и деньги.
• Чаще поощряйте и благодарите сотрудников за следование принципам обеспечения качества.
• Регулярно измеряйте и контролируйте показатели качества, такие как качество продукта, качество в процессе работы и качество обслуживания. Это нужно для выявления потенциальных зон роста и отслеживания уровня культуры.

Помните, что от вашей культуры качества зависит удовлетворённость и лояльность заказчика.

Вывод

Внедрение культуры обеспечения качества требует значительных вложений в обучение людей и настройку бизнес-процессов. Руководители ИТ-команд должны сами (или с помощью внешних экспертов) установить критерии качества ПО и проконтролировать, чтобы все члены команды понимали их и стремились им соответствовать Это довольно трудоёмкий процесс, который может повлиять на сроки поставки решений. Но без культуры качества могут возникнуть более серьёзные проблемы, чем непопадание в сроки: ошибки в продукте, неудовлетворённость заказчика или вовсе отказ от ваших услуг.

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

Разработка и развитие системы менеджмента качества на примере ГК АйТи ООО ‘Дататех’

Оглавление

Введение

1. Постановка задачи

2. Предпроектное обследование организации

2.1 Общая характеристика организации

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

3. Проектирование СМК

3.1 Разработка целей в области качества

3.2 Описание основных и вспомогательных процессов

3.3 Разработка документации СМК

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

Заключение

Список используемой литературы

Введение

Система менеджмента качества (СМК) — это система для
руководства и управления организацией применительно к установленным
государственным стандартам качества. ISO 9000 — одна из моделей СМК.

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

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

Поставщики IТ-систем и услуг тоже вынуждены разворачивать
работу по получению сертификата ISO 9000, и здесь перед ними встают проблемы,
вызванные спецификой IT-компаний.

— IT-компании работают преимущественно в проектной форме. Каждый
проект уникален, следовательно, и ни о каком конвейере речи идти не может.

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

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

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

Причины, по которым IT-компаниям стоит внедрять, сертифицировать и
развивать СМК:

— на сегодняшний день IT-сфера, как и многие
другие виды бизнеса, ориентирована на международные отношения, причем речь идет
не только о реализации своих услуг или продукции за пределами страны, а также о
привлечении иностранных инвестиций в проекты. В Европе же, наличие
сертифицированной СМК — признак хорошего тона и показатель серьёзного отношения
к бизнесу.

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

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

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

1. Постановка
задачи

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

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

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

2.
Предпроектное обследование организации

2.1 Общая
характеристика организации

Группа компаний (ГК) АйТи — многопрофильный ИТ-холдинг,
предоставляющий весь спектр услуг и решений для создания, модернизации и
сопровождения корпоративных информационных систем. ООО «Дататех» —
Уральский инженерно-производственный центр ГК АйТи.

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

·        разработка, внедрение и сопровождение ПО

·        технической поддержка информационных
систем

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

В ноябре 2014 года «АйТи Капитал» успешно прошел
ресертификационный аудит на соответствие СМК требованиям международного
стандарта ISO 9001: 2008. Аудит подтвердил, что действующая система менеджмента
качества «АйТи Капитал» эффективно функционирует и соответствует всем
требованиям международного стандарта ISO 9001: 2008. Сертификационный аудит
системы менеджмента качества проведён крупнейшим независимым органом — Бюро
Веритас Сертификейшн (Bureau Veritas Certification).

Преимущества при внедрении СМК на предприятии
<#»878948.files/image001.gif»>

Рисунок 1 — организационная структура ООО «Дататех»

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

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

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

Группа разработки разрабатывает новое ПО, сопровождает и
совершенствует разработанное ранее ПО.

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

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

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

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

В частности, отдел тестирования содержит следующие должности:

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

Тест аналитик (Test analyst) — несет ответственность за
формирование тестовых спецификаций, и анализ итогов тестирования.

Тест разработчик (Test developer) — несет ответственность за
разработку автоматизированных тестов, предусмотренных в плане тестирования,
установку и сопровождение инфраструктуры тестирования, создание стенда для
проведения тестирования в соответствии с планом тестирования.

Исполнитель тестов (Test operator) — несет ответственность за
фактическое исполнение тестов и документирование выявленных дефектов.

Построение диаграмм IDEF0 по тестированию ПО

На рис.2 показана контекстная диаграмма «Тестирование
ПО» в нотации IDEF0.

Входные данные:

·        Запрос на выделение ресурсов для
тестирования

·        Проектная документация

·        Тестовый план

·        Распределенные между тестировщиками
задания

·        Новая версия продукта

·        Результат тестирования

·        Обобщенный отчет о результатах
тестирования.

Выходные:

·        Назначенные специалисты

·        Рекомендации по корректированию
документации

·        Утвержденный план

·        Тестовый сценарий

·        Тест-кейсы

·        Дефекты

·        Отчет о результате тестирования

Механизмы исполнения:

·        Ресурс-менеджер, тестировщик, аналитики,
разработчик, внедренец.

Управляющий механизм:

·        Техническая документация

·        Требования заказчика

Рис. 2 — контекстная диаграмма «Тестирование ПО» IDEF0

Процесс «Тестирование ПО» разбивается на 6
процессов (рис. 4).

) Инициирование

) Планирование

) разработка тестов

) Выполнение тестов

Данный этап следует декомпозировать (см. рис. 3):

Рис.3 — диаграмма декомпозиции процесса «Выполнение
тестов»

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

) Анализ результатов и написание отчетов

) Завершение

Рис. 4 — Основные процессы тестирования ПО

Построение диаграммы Исикавы для тестирования ПО

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

В данной работе проблемой является «Неэффективное тестирование».

На рис. 5 показана диаграмма Исикавы с основными категориями
причин.

Первой причиной является «Заказчик» (рис. 6), то
есть заказчик может некорректно сформулировать требования.

Вторая причина — «Аналитик», (рис. 7) то есть
аналитик может неверно составить спецификацию из-за непонимания требований
Заказчика.

Третья причина — «Разработчик», (рис. который
может допустить ошибки при кодировании, вообще, они неизбежны, идеального кода
не бывает.

Четвертая причина — «Тестировщик» (рис. 9), от
которого зависит результат тестирования.

Рис. 5 — Диаграмма Исикавы с основными категориями причин

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

Рис. 6 — Детализация причины «Заказчик»

Рис. 7 — Детализация причины «Аналитик»

Рис. 8 — Детализация причины «Разработчик»

Рис. 9 — Детализация причины «Тестировщик»

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

Построение стратегической карты

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

·        Цели должны быть измеримыми;

·        На достижение целей можно влиять;

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

Главная цель — «Увеличение прибыли». Стратегическая
карта содержит такие разделы как: «Финансы», «Клиенты»,
«Внутренние бизнес-процессы», «Персонал». На рис. 10
показана стратегическая карта ООО «Дататех.

Рис. 10 — стратегическая карта

3.3
Разработка документации СМК

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

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

предъявлять перечень четких требований к персоналу;

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

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

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

способствовать эффективным изменениям руководства (Система
качества не может быть жесткой; изменения должны вноситься в нее без
затруднений).

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

облегчать мониторинг и проведение проверок системы.

В разделе 4.1 стандарта ISO 9001: 2008 говорится о
том, что «Организация должна установить, документально оформить, внедрить,
поддерживать и постоянно улучшать систему менеджмента качества в соответствии с
требованиями настоящего международного стандарта».

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

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

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

 

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

Одним из вариантов повышения качества тестирования ПО
является автоматизирование тестирования.

Автоматизированное тестирование программного
обеспечения (Software Automation Testing) — это процесс верификации
программного обеспечения, при котором основные функции и шаги теста, такие как
запуск, инициализация, выполнение, анализ и выдача результата, выполняются
автоматически при помощи инструментов для автоматизированного тестирования.

Тест Скрипт (Test Script) — это набор инструкций, для
автоматической проверки определенной части программного обеспечения.

Преимущества автоматизации тестирования:

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

·              Быстрое выполнение —
автоматизированному скрипту не нужно сверяться с инструкциями и документациями,
это сильно экономит время выполнения.

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

·              Выполнение без
вмешательства — во время выполнения тестов инженер-тестировщик может заниматься
другими полезными делами, или тесты могут выполняться в нерабочее время (этот
метод предпочтительнее, так как нагрузка на локальные сети ночью снижена).

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

Заключение

В ходе выполнения курсовой работы была проанализирована организация
ООО «Дататех», а именно её СМК, организационная модель, цели,
основные проблемы и причины их возникновения. В результате анализа даны
рекомендации по улучшения качества отдела тестирования.

Список
используемой литературы

Книги:

.
Национальный стандарт РФ ГОСТ Р ИСО 9001-2008.

.
«Системы, методы и инструменты менеджмента качества», Халикова Е. А.

.
«Тестирование программного обеспечения. Фундаментальные концепции
менеджмента бизнес-приложений, Сэм Канер, Джек Фолк, Енг Нгуен

.
«Как тестируют в Google», Дж. Уиттакер, Дж. Арбон, Дж. Кароло.

Сайты:

1.
<http://www.it.ru/>

.
<http://datateh.ru/>

.
<http://software-testing.ru/>

.
<http://testingworld.ru/>

.
<http://supersales.ru/>

.
<http://www.it-capital.ru/>

1. Понятие,
   процессы и принципы управления качеством
   IT-проекта
   

2. Система
   измерения качества IT-проекта:
   метрики качества.

3. Управление
   качеством ПО на стадиях жизненного
   цикла

4. Стандарты
   и модели качества программного
   обеспечения: Capability
   Maturity
   Model
   (CMM)
   и ISO/IEC
   15504 (SPICE).
   

=1=

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

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

1. планиро­вание
   качества,

2. процесс
   обеспечения качества (выполнение
   плановых работ по качеству)

3. процесс
   контроля качества.

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

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

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

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

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

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

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

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

Обеспечение
качества проекта связано с:

1. Качеством
   создаваемого продукта.

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

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

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

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

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

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

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

3:
вовлечение персонала.
«Люди составляют сущность предприятия
на всех уровнях, и их полноценное участие
в деятельности способствует применению
их способностей на благо целей
предприятия».

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

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

6:
постоянное усовершенствование.
«Непрерывное усовершенствование
процессов и повышение качества продукции
должно быть постоянной стратегической
целью предприятия и его специалистов».

7:
подход к принятию решений основанный
на фактах.
«Эффективные решения должны базироваться
на анализе только реальных данных и
достоверной информации».

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

=2=

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

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

Рис.
— Система
измерения качества

Определение
требований к качеству начинается с
перечисления внешних характеристик
качества, отражающих требования к
IT-проекту.
Далее выбираются внешние измеримые
свойства (внешние атрибуты) IT-проекта,
связанные с ними метрики и приемлемые
диапазоны изменения значений (мер).

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

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

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

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

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

2. количественные
   — применимы для измерения надежности
   и эффективности сложных комплексов
   программ;

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

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

Табл.
— Характеристики качества программного
обеспечения

1. Функциональные возможности1 — способность ПО реализовать установленные или предполагаемые потребности пользователей
Пригодность для применения по назначению	Наличие и соответствие набора функций конкретным задачам
Правильность/корректность реализации требований2	Способность программного обеспечения обеспечивать правильность (или соответствие) результатов
Способность к взаимодействию с компонентами и средой3	Способность ПО взаимодействовать с конкретными системами
Согласованность	Способность ПО придерживаться соответствующих стандартов или соглашений, или подробных рекомендаций
Защищенность/безопасность функционирования	Способность ПО предотвращать несанкционированный доступ (случайный или преднамеренный) к программам и данным
2. Надежность4 — способность программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени
Стабильность/уровень завершенности	Характеризуется частотой отказов, вызванных наличием ошибок в ПО
Устойчивость к ошибке	Способность ПО поддерживать определенный уровень качества функционирования в случаях программных ошибок
Восстанавливаемость после проявления дефектов5	Способность ПО восстанавливать уровень качества функционирования и данные, непосредственно поврежденные в случае отказа. Характеризуется необходимыми для этого затратами усилий и времени
3. Практичность6 — характеризуется объемом работ, требуемых для использования программного обеспечения определенным или предполагаемым кругом пользователей
Понятность функций и документации	Характеризует усилия пользователя по пониманию общей логической концепции ПО и его применимости
Изучаемость процессов функционирования и применения	Характеризует усилия пользователя по обучению применению ПО (например, оперативному управлению, вводу, выводу)
Простота использования	Характеризует усилия пользователя по эксплуатации и оперативному управлению ПО
4. Эффективность 7 — определяется соотношением между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях
Временная эффективность реализации комплекса программ	Характеризуется временем отклика и скоростью выполнения функций
Используемость вычислительных ресурсов	Характеризуется объемом используемых ресурсов и продолжительностью использования ПО при выполнении функции
5. Сопровождаемость8 — характеризует объем работ, требуемых для проведения конкретных изменений
Анализируемость	Характеризует усилия, необходимые для диагностики недостатков или случаев отказов или определения составных частей для модернизации
Изменяемость компонентов и комплекса программ	Характеризует усилия, необходимые для модификации, устранения отказа или для изменения условий эксплуатации
Устойчивость	Характеризует риск от непредвиденных эффектов модификации
Тестируемость изменений при сопровождении	Характеризует усилия, необходимые для проверки модифицированного программного обеспечения
6. Мобильность9 — способность программного обеспечения быть перенесенным из одного окружения в другое
Адаптируемость к изменениям среды	Характеризует удобство адаптации ПО к различным конкретным условиям эксплуатации, без применения других действий или способов, кроме тех, что предназначены для этого в рассматриваемом программном обеспечении
Простота установки /внедрения/ инсталляции после переноса	Характеризует усилия, необходимые для внедрения программного обеспечения в конкретное окружение
Соответствие	Способность программного обеспечения подчиняться стандартам или соглашениям, относящимся к мобильности
Взаимозаменяемость компонентов при корректировке комплекса программ10	Характеризует простоту и трудоемкость применения данного ПО вместо другого конкретного программного средства в среде этого средства

=3=

Стандарт
ISO/IEC 9126 предлагает варьировать взгляды
на качество продукта по стадиям ЖЦ
следующим образом:

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

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

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

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

5. качество
   поставляемого продукта
   – это качество готового к поставке
   продукта, как правило, протестированного
   в моделируемой среде на моделируемых
   данных.

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

=4=

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

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

• Capability
  Maturity Model (CMM)

• ISO/IEC
  15504 (SPICE).

Capability
Maturity Model
(1991 год, американский
институт программной инженерии SEI при
университете Карнеги-Меллон)

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

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

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

Рис.
—
Пять
уровней зрелости в модели CMM.

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

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

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

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

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

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

При
сертификации проводится оценка
соответствия всех ключевых областей
по 10-балльной шкале. Для успешной
квалификации данной ключевой области
необходимо набрать не менее 6 баллов.
Оценка ключевой области производится
по следующим показателям:

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

2. Насколько
   широко данная область применяется в
   организации (например, оценке в 4 балла
   соответствует фрагментарное применение).

3. Успешность
   использования данной области на практике
   (например, оценке в 0 баллов соответствует
   полное отсутствие какого-либо эффекта,
   а оценка в 8 баллов выставляется при
   наличии систематического и измеримого
   положительного результата практически
   во всей организации).

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

К
сожалению, использование CMM затрудняют
следующие проблемы:

• стандарт
  CMM является собственностью Software
  Engineering
  Institute
  и не является общедоступным (в частности,
  дальнейшая разработка стандарта ведется
  самим институтом, без заметного влияния
  остальной части программистского
  сообщества);

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

• стандарт
  ориентирован на применение в относительно
  крупных компаниях.

ISO/IEC
15504 (SPICE) (1991 год, Международная
организация по стандартизации инициировала
работу по созданию единого стандарта
оценки программных процессов)

Стандарт
получил имя SPICE
(сокращение
от Software
Process Improvement and Capability Etermination,
определение возможностей и улучшение
процесса создания программного
обеспечения). Официально стандарт
называется ISO/IEC 15504:
Information Technology — Software Process Assessment
и на данный момент существует в качестве
рабочей версии, последний выпуск которой
состоялся в мае 1998 года.

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

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

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

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

3. Улучшение
   процесса. После
   этого весь цикл работ начинается
   сначала.

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

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

И
CMM, и SPICE на сегодняшний день представляют
наиболее развитые модели качества,
прошедшие применение на практике. Они
я являются серьезной альтернативой для
ISO 9000-9004. Соответствие стандарту — не
только свидетельство достижения
некоторого уровня качества, но и способ
реального улучшения существующих в
организации процессов разработки ПО.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #