Как обеспечить качество программного обеспечения? Как обеспечить качественные производственные процессы? Как сделать так, что поменять, чтобы процессы и сам продукт имели встроенное качество?
Такими вопросами задаются практически все компании, которые занимаются производством программного обеспечения и для которых важно доставлять ценность до клиента без дефектов.
Этой статьей начинаю серию публикаций, посвященную встроенному качеству и как мы меняли процессы в нашей компании.
Что же такое качество?
Для начала давайте определимся что же такое качество? Как гарантировать качество? Как его контролировать и управлять?
Существует множество международных стандартов, таких как ISO9000, ISO9126 (был заменен ISO/IEC 25010:2011) и т.д., которые дают некоторые определения качеству и процессам.
Так, к примеру согласно ISO9000. Качество — это степень соответствия совокупности присущих характеристик объекта требованиям.
Хмм. Окей. Выглядит заумно. Как насчет программного обеспечения? На это отвечает стандарт ISO 9126.
Системы обеспечения качества и надежности продукции машиностроения
Качество программного обеспечения — это
- Способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым требованиям.
- Весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым требованиям.
- Степень, в которой система, компонент или процесс удовлетворяют требованиям или ожиданиям заказчика или пользователя.
Как видно из определений, качество и требования тесно связаны и любой объект (будь то ювелирное украшение или программное обеспечение), который считается качественным, должен удовлетворять установленным требованиям.
Согласно тому же стандарту ISO9126 качество программного обеспечения имеет внутренние и внешние характеристики. Каждая характеристика детализируется субхарактеристиками.
К внешним характеристика качества относятся:
- Функциональность (Functionality) — Набор атрибутов, которые влияют на существование набора функций и их заданных свойств. Функции — это характеристики ПО, которые удовлетворяют заявленные или подразумеваемые потребности.
- Надежность (Reliability) — Набор атрибутов, которые влияют на способность программного обеспечения поддерживать свой уровень производительности при указанных условиях в течение указанного периода времени.
- Юзабилити (Usability) — Набор атрибутов, которые влияют на усилия, необходимые для использования, и на индивидуальную оценку такого использования заявленным или подразумеваемым набором пользователей.
- Эффективность (Efficiency) — Набор атрибутов, которые влияют на взаимосвязь между уровнем производительности программного обеспечения и количеством используемых ресурсов при указанных условиях
- Портируемость (Portability) — Набор атрибутов, влияющих на возможность передачи программного обеспечения из одной среды в другую.
К внутренним качествам относятся:
Качество программного обеспечения
- Сопровождаемость (Maintainability) — Набор атрибутов, влияющих на усилия, необходимые для внесения определённых изменений.
- Тестируемость (Testability) — Набор атрибутов, влияющих на усилия, необходимые для проверки программного обеспечения после проведения какого-либо видоизменения.
Данные семь характеристик достаточны для того, чтобы программное обеспечение считалось качественным.
Но как гарантировать качество? Как контролировать и управлять? Какие процессы отвечают за это?
Но как гарантировать качество?
В целом, большинство, когда слышат слово качество, подразумевают тестирование, команду тестирования, которая сидит и весь день тестирует программное обеспечение. Но на самом деле все гораздо сложнее и интереснее.
Существует, как минимум, четырехуровневая система процессов, которые вместе могут обеспечить, гарантировать качество. Эти процессы начинают свою работу с момента контакта с заказчиком и заканчиваются. а, хотя нет, они не заканчиваются, они работают постоянно по всему потоку создания ценности для клиента.
Quality Management (QM) или управление качеством — это процесс наблюдения за всеми действиями и задачами, необходимыми для поддержания желаемого уровня качества. Управление качеством включает определение политики качества, создание и реализацию планирования и обеспечения качества (QA), а также контроль качества (QC) и улучшения качества. Управление качеством требует, чтобы все заинтересованные стороны бизнеса работали вместе надо улучшением процессов, продуктов, услуг и культуры самой компании.
Обеспечение качества (QA) — это часть управления качеством, направленная на обеспечении уверенности (гарантированности) в том, что требования к качеству будут выполнены.
Управление качеством (QC) — это рабочие методы и активности, нацеленные на выполнение требований к качеству.
Тестирование (Testing) включает в себя различные задачи и подходы к выявлению и обнаружению ошибок, дефектов в продукте.
Как видно между QA, QC и тестированием есть разница. Да, они об одном и том же — о качестве, но работают с ним с разных уровней.
Так, QA задействован в процессе верификации и позволяет получить ответ на вопрос — Создаю ли я продукт правильно? У QA ориентация на процессы и их постоянное улучшение. Поэтому QA это проактивный процесс, направленный на предотвращение дефектов путем постепенного совершенствования производственных процессов, политик и процедур. QA отвечает за разработку стандартов и методологий, аудит, обучение и т.д.
А вот QC задействован в процессе валидации и позволяет получить ответ на вопрос — Создаю ли я правильный продукт? В отличии от QA, QC ориентирован на продукт и является реактивным процессом, который направлен на эффективное выявление дефектов в программном обеспечении до релиза и отправки клиентам. QC следует стандартам и регламентам, методологиям, за которые отвечает QA.
Резюмируя, хочется отметить, чтобы обеспечить качество в ПО, надо начать с аудита производственных процессов, пересмотреть все регламенты и стандарты, которые используются и, если хочется повысить качество, начать их менять, внедрять новые методологии и подходы. Иначе, мы получим тот же самый результат. Как говорил Эйнштейн: Самая большая глупость — это делать тоже самое и надеяться на другой результат.
В следующих публикациях по качеству поговорим про гибкие подходы к обеспечению встроенного качества.
- Тестирование IT-систем
- Управление разработкой
Источник: habr.com
Разработка документации по СМК
Внедрение и использование СМК (системы менеджмента качества) является важным условием для успешного ведения любого бизнеса. Даже если предприятие не планирует сертифицировать СМК и получать подтверждающий бланк, следует самостоятельно разработать и утвердить документацию под стандарты ИСО, либо поручить это профессиональным специалистам. Точный перечень локальных актов на СМК будет зависеть от сферы деятельности и величины компании, количества и особенностей бизнес-процессов.
Разработка и внедрение СМК на предприятии
Ключевой целью внедрения и использования СМК является введение строго контроля за качеством продукции и услуг, анализ возможных рисков и разработка мер по их устранению. Внедрив систему менеджмента в соответствии с общепринятыми или специальными стандартами ГОСТ ИСО, организация получает следующие преимущества:
- возможность быстро и успешно пройти оценку соответствия по техрегламентам ТС и в системе ГОСТ, если ее схемой предусмотрен производственный контроль;
- гарантия потребителям, контрагентам и клиентам, что на производстве действует жесткая система контроля за качеством;
- повышение конкурентоспособности продукции и деловой репутации компании;
- оптимизация внутренних бизнес-процессов, снижение издержке и отказов, переход на новые технологии и современное оборудование.
Организация разработки СМК на предприятии является обязательным условием для успешного прохождения сертификации. Общераспространенным стандартом для этой процедуры является ГОСТ Р ИСО 9001-2015. На его базе разработано и утверждено множество стандартов под специальные сферы деятельности. Список документации для их внедрения и использования может отличаться, так как будут разными и возможные риски, бизнес-процессы, меры по контролю за качеством.
Без подготовки документации невозможно внедрить стандарты, обеспечить надлежащее применение и мониторинг, оценить результаты. Локальные акты, утвержденные руководством компании, будут использовать рядовые сотрудники всех звеньев. Поэтому они должны быть понятны, реализуемы на практике, соответствовать реальным бизнес-процессам и моделям управления.
Кто должен разрабатывать документацию
Процесс разработки документации СМК является сложным, так как для подготовки локальных актов нужно:
- получить, систематизировать и обобщить множество сведений о текущей деятельности;
- сформировать отчеты о качестве продукции или услуг на предыдущие периоды;
- соблюсти требованиями смежных госстандартов и технических условий под отдельные виды товаров и услуг;
- учесть требования законодательства, нормативной базы Таможенного союза.
По указанным причинам только в редких случаях разработка и внедрение СМК предприятия осуществляется самостоятельно. Оптимальным вариантом является привлечение сторонних специалистов, экспертов в сфере стандартизации и сертификации, в профильных сферах деятельности. Это гарантирует отсутствие проблем при официальной оценке соответствия по ГОСТ Р ИСО 9001-2015 или иным госстандартам, получении сертификатов на систему менеджмента.
Какие документы нужно разработать на систему менеджмента
Непосредственно в содержании ГОСТ Р ИСО 9001-2015 содержаться только общие требования к локальной документации, которые нужно учесть при разработке. Чтобы внедрить, использовать и сертифицировать систему менеджмента, нужно подготовить:
- политику и цели компании в сфере качества товаров или услуг (организация или предприниматель должны сразу озвучить, какие цели преследуют, внедряя систему менеджмента);
- руководство по качеству, т.е. непосредственно описание всех бизнес-процессов, результатов их применения, мер по контролю;
- описание структуры предприятия, т.е. всех подразделений, участков, цехов, отделов и т.д.;
- отдельные документы на службу, контролирующую качество товаров и услуг;
- инструкции, положения, регламенты, карты и иные локальные акты, обеспечивающие неизменное качество и контроль за его соответствием;
- регламенты и руководства на отдельные процедуры, в том числе на управление документацией, записями, аудитами, некачественной и бракованной продукцией, и т.д.;
- отчеты о проведенных аудитах;
- отчеты и справки за предыдущие календарные периоды – о количественных и качественных показателях продукции и услуг;
- список товарных групп и услуг со ссылкой на нормативно-техническую базу (ГОСТ и ТУ);
- материалы о проведенных проверках со стороны контрольных и надзорных органов за последние 3 года (Роспотребнадзор, МЧС, прокуратура и т.д.);
- договоры, контракты, иные материалы, подтверждающие взаимоотношения с контрагентами, поставщиками, сервисными организациями.
Все процессы, отраженные в локальных документах, должны быть взаимосвязаны, последовательны. В этом заключается суть процессного подхода по ISO. Для каждого последовательного этапа производства или обслуживания должны определяться сотрудники, ответственные за итоговый результат. Это предусматривает издание приказов, внесение изменений в должностные инструкции.
Точный список документов может отличаться. Более того, из указанного перечня не все локальные акты нужно разрабатывать заново. Например, внутренние положения и регламенты могут уже соответствовать требуемым стандартам. Их достаточно проверить или внести незначительные корректировки, утвердить руководством.
Этапы разработки стандартов СМК
Порядок разработки СМК определяется организацией или предпринимателем. Чтобы приступить к подготовке документации, на предварительном этапе нужно:
- собрать объективные данные о производственных процессах, текущей системе мониторинга за качеством;
- провести аудиты, подготовки отчеты, заключения;
- разработать и утвердить технические условия на товары, если их характеристики не подпадают под действующие ГОСТ;
- определить и зафиксировать в документах политику и цели для достижения качественных показателей.
Список процессов, применяемых при производстве или оказании услуг, их сложность и последовательность, будет отличаться для каждого конкретного предприятия. Кроме того, по мере развития бизнеса количество процессов может увеличиться, что повлияет на систему менеджмента. Поэтому владелец бизнеса должен обеспечить регулярный мониторинг за производством, своевременно вносить корректировки в менеджмент.
Дальнейшие этапы работы с документацией предусматривают следующие мероприятия:
- разграничение ответственности, компетенции и полномочий руководства, специалистов среднего звена и исполнителей, в том числе по отдельным подразделениям;
- описание всех процессов, их взаимодействия, результатов и порядка оценки;
- организация повышения квалификации персонала под требования ГОСТ;
- согласование инструкций, регламентов и положений с руководителями структурных подразделений (они будут их реализовывать на практике);
- доведение политики и цели внедрения, вновь разработанной документации до сотрудников, внесение изменений в должностные инструкции.
Для повышения качественных показателей готовой продукции или оказания услуг может потребоваться изменение производственных условий, переоборудование предприятия, внедрение новых технологий. Под все эти процессы также разрабатываются или заказываются документы, проводятся согласования на ввод в эксплуатацию и пусконаладочные работы.
Комплект локальных актов, разработанный на подготовительной стадии, передается в аккредитованный центр. Его будет проверять инспекционная комиссия, в том числе при практическом анализе производственных процессов.
Как и когда проверяют документы на систему менеджмента
Анализ документов, разработанных на предприятии, является одной из ключевых стадий сертификации. Специалисты аккредитованного центра проверят:
- соответствие локальных актов требованиям стандартов, законодательству;
- реализацию содержания документов на практике, т.е. их применение персоналом;
- возможность повышения качества и улучшения результатов управления после сертификации.
Выводы специалистов будут отражены в акте аудита. Если претензий и замечаний нет, заказчик получит сертификат со сроком действия на 1 или 3 года.
Еще больше информации о правилах, сроках и условиях подготовки документов по ИСО вы можете узнать у наших специалистов. Звоните, по всем возникшим вопросам консультации бесплатны!
Источник: spbcsm.ru
РАЗРАБОТКА ПРОГРАММЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ПРОЕКТА
Хотя программа обеспечения качества обычно проста, ее разработка требует координации и интеграции множества различных концепций и информационных элементов. А ограниченный опыт в сфере современных практических методик управления качеством проектов вынуждает быть особенно внимательными и осторожными при составлении программы.
Подготовка исходной информации. Качество программы в значительной степени опирается на качество исходной информации. В частности, значительное влияние оказывают следующие информационные элементы: •
политики и процедуры в области качества (обеспечение качества, управление им); •
описание содержания и СДР. ПРОГРАММА ОБЕСПЕЧЕНИЯ КАЧЕСТВА
Название проекта: SMP-1 Ревизия: 1 Дата: 10.05.2001 Подготовил: Боб Максвелл Лист: 2 из 3 1 2 3 4 5 6 Обозначение по СДР Элемент
ответственности Расписание май/июнь 2001 г., неделя h
С Алан Перри Ким DZM Я IN
ю 5/14 5/21 5/28 6/4 6/14 6/21 2.03 руководство по управлению проектами Легкость чтения по Флешу24 Выполнение тестов и переписывание D ЕЗО 9000 Пересмотр D D D А — РМВОК Пересмотр D — Краткость
указаний Проверка и коррекция D — Организационные политики по части написания руководств Пересмотр D А — Обозначения: D — выполнение А — утверждение
Рис. 8.2. Пример программы обеспечения качества
Способы управления качеством в организации обычно описываются в политике обеспечения качества. Определенная, документированная и поддерживаемая руководством политика представляет собой изложение принципов, убеждений и ключевых целей проектов, которые в совокупности образуют каркас, на который опираются действия по обеспечению качества в организации [5]. Этот каркас в дальнейшем детализируется до уровня процедур обеспечения качества. Политика и процедуры совместно задают направление программы.
Например, если процедуры требуют соответствия стандарту ISO 9000, программа должна такое соответствие обеспечить.
Внимательное отношение к голосу заказчика поможет не только понять его нужды, но и перевести их на четкий распознаваемый язык содержания проекта, установить шкалы для измерения и выразить их в виде стандартов качества, что является наиболее важным элементом программы. По этой причине требования программы обеспечения качества обязательно должны учитывать голос заказчика.
Содержание устанавливает качественную цель проекта и используется совместно с СДР, определяющей работы проекта, для которого составляется программа обеспечения качества. Следовательно, как констатация содержания, так и СДР в равной степени важны при подготовке программы обеспечения качества.
Выбор элемента СДР. Планирование качества выполняют, опираясь на каркас, формируемый СДР. Программа обеспечения качества создается на уровне пакетов работ СДР. Суммирование программ обеспечения качества для элемента, находящегося на более высоком уровне, означает суммирование программ обеспечения качества всех входящих в этот элемент пакетов работ.
Продолжая процесс суммирования вверх по иерархии СДР, мы получим программу обеспечения качества для всего проекта. Так, в примере на рис. 8.2 результатом будет пакет работ «Руководство по управлению проектами», для которого мы составляем программу обеспечения качества. Этот пакет работ является частью проекта по развертыванию процесса управления проектами в масштабах организации.
Установка стандартов качества. Каковы стандарты качества для пакета работ, показанного на рис. 8.2, и зачем они нужны? Для этого пакета мы определили пять стандартов. Заказчик хочет, чтобы «Руководство» и описываемый в нем процесс соответствовали международному стандарту ISO 9000 и американскому стандарту PMBOK25 Guide. Для того чтобы данное «Руководство» могли использовать проектные команды, оно должно соответствовать трем принятым в компании стандартам: •
краткости (максимум пять страниц); •
совместимости с организационными политиками в части написания руководств; •
легкости чтения по Флешу (индекс должен быть более 70 пунктов).
Эти примеры помогают ответить на ряд вопросов: зачем нужны стандарты качества, кто их устанавливает и каковы они. Хотя существует множество различных определений качества, мы считаем, что качество есть удовлетворение или превышение ожиданий заказчика (см. врезку «Каково ваше определение качества?»). Мы применили инструменты работы с голосом заказчика, идентифицировав ожидания по части конкретного пакета работ, и теперь нам необходимо измерить их и отреагировать (см. врезку «На планирование качества нужно затрачивать больше усилий» в разделе «Использование программы обеспечения качества проекта»). Таким образом, цель использования стандартов в программе обеспечения качества состоит в измерении ожиданий: чтобы выполнить пакет работ («Руководство по управлению проектами») согласно ожиданиям заказчика, нужно обеспечить его соответствие установленным стандартам качества. В силу того что качество оценивают заказчики, их необходимо вовлекать в процесс разработки и принятия стандартов.
В примере, посвященном руководству по управлению проектами, мы использовали международные, национальные и корпоративные стандарты. Первые два стандарта в силу своего повсеместного распространения стали привычными и наиболее простыми в использовании. Однако в большинстве случаев проекты вынуждены учитывать стандарты, принятые внутри компании.
В случае, когда такие стандарты носят количественный характер — например, учитывается показатель легкости чтения по Флешу, равный 70 баллам (из 100 возможных), — применять их легче. Но иногда устанавливаются стандарты качественного или перцепционного (относящегося к восприятию) характера, например насколько заказчик удовлетворен своевременностью выполнения работ. В последнем случае полезна перцепционная шкала, или шкала Ликерта, содержащая значения от 1 (Не удовлетворен) до 10 (В высшей степени удовлетворен). Учтите: чтобы сделать шкалу максимально показательной, следует четко определить значения всех остальных чисел. Тщательно разработанная шкала весьма надежна (даже в статистическом смысле) и широко используется.
Еще один важный вопрос: сколько стандартов проектная команда должна установить для пакета работ. Непреложных правил здесь нет, поэтому ответы варьируются от идеалистического «столько, сколько нужно» до прагматического «один основной стандарт».
Определение задач обеспечения качества. После того как стандарты качества установлены, нужно определить, что делать для того, чтобы соответствовать этим стандартам и выполнить пакет работ согласно ожиданиям заказчика. Вначале следует выявить задачи, которые мы должны решить, чтобы соответствовать стандарту качества. Возьмем, например, наш пакет работ «Руководство по управлению проектами». Для стандарта «Легкость чтения по Флешу более 70 баллов» задача может быть повторяющейся: по мере написа-
КАКОВО ВАШЕ ОПРЕДЕЛЕНИЕ КАЧЕСТВА?
В проектах часто заняты люди из разных функциональных отделов, имеющие различную базовую подготовку. Выполняя свои обязанности, они руководствуются соображениями, далекими от их коллег по команде. Например, такие понятия, как «продукт, цена, реклама, место», являются критически важными для представителя отдела маркетинга, но мало значат для инженера или дизайнера. Эти ролевые и языковые различия создают путаницу и порождают различные определения качества, описанных в приводимой ниже таблице.
Согласно трансцендентному определению, качество есть понятие абсолютное и повсеместно признаваемое [4]26. Следовательно, оно не может быть определено точно, но факт его наличия может быть признан, когда оно наблюдается в чем-либо (например, в часах Rolex).
Когда некто полагает, что качественное различие есть отражение некоторого количественного различия в каком-либо атрибуте продукта, он использует ориентированное на продукт определение качества. В этом смысле 833-мегагерцевый процессор имеет более высокое качество, чем 366-мегагерцевый.
Определение качества Используется
Ориентированное на продукт Заказчиками
Ориентированное на пользователя Маркетинговым отделом
Ориентированное на производство Производственным отделом
Ориентированное на ценность Отделом проектирования
Согласно определению, ориентированному на пользователя, качество определяется как пригодность к использованию либо как показатель того, насколько хорошо продукт выполняет свою функцию.
Например, оба программных пакета — Primavera и MS Project — работоспособны и применяются на практике — но различными менеджерами проектов, имеющими разные нужды и, как следствие, разные стандарты качества.
Соответствие спецификациям представляет собой ориентированное на производство определение качества, согласно которому спецификации включают как целевые значения (например, толщина детали 30 см), так и допустимые отклонения (например, 30 см + 0,01).
Качественный продукт по ориентированному на ценность определению — это продукт, который столь же ценен, сколь и конкурирующие продукты, но продается по более низкой цене. Совершенно очевидно, что с точки зрения отношения «полезность/цена» постоянные низкие цены на продукт свидетельствуют о его более высоком качестве, чем продажа по специальной цене.
Все перечисленные определения необходимы для того, чтобы отразить точки зрения кросс-функциональных членов проектных команд, а их результатом является продукт, удовлетворяющий требованиям заказчика. Однако во многих организациях эти определения все еще считаются конфликтующими, в таком случае предпочтительным становится определение, ориентированное на заказчика: качество есть удовлетворение или превышение ожиданий клиента [6-9]. Такой дефиницией при разработке программы обеспечения качества будем пользоваться и мы.
ния руководства допустимо периодически проверять его читаемость, например запуская тест в Microsoft Word и переписывая руководство, если значение оказалось ниже 70 баллов. С другой стороны, задача по обеспечению соответствия PMBOK включает в себя формирование группы экспертов для оценки степени соответствия, возможно с использованием качественного стандарта.
Распределение областей ответственности, определение расписания. Идентификация задач по обеспечению качества ставит перед нами два вопроса: кто и когда должен эти задачи выполнять (см. врезку «У нас есть группа обеспечения качества!»). Чтобы встроить в систему обеспечения качества ответственность и подотчетность, необходимо определить, кто из сотрудников и что именно будет делать для решения данной задачи (см.
пример на рис. 8.2). Здесь потребуется матрица ответственности, являющаяся частью программы обеспечения качества и включающая в себя различные типы ответственности: «Выполнение», «Утверждение» и «Необходимость консультации».
Когда обязанности будут четко определены и для каждой задачи по обеспечению качества будет установлена своя временная шкала, уравнение, лежащее в основе программы, может считаться решенным. Очевидно, что программа обеспечения качества проекта содержит матрицу ответственности и расписание (обычно в виде диаграммы Гантта).
Некоторые менеджеры считают это излишеством: ведь уже есть матрица ответственности и расписание для всего проекта — и часто спрашивают, должны ли матрица и расписание браться из программы обеспечения качества и соединяться с матрицей и расписанием проекта? Ответ на оба вопроса — нет. Если взглянуть на типичные матрицу ответственности и расписание проекта, то на них наверняка не окажется задач по обеспечению качества. О чем это говорит? О том, что мы до сих пор не рассматриваем качество как приоритетную задачу проекта и предпочитаем иметь отдельную программу обеспечения качества со своей матрицей ответственности и своим расписанием до тех пор, пока не построим иную систему оценки.
Источник: lib.sale