Знак качества программному продукту

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

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

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

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

Общие формулировки по руководству качеством и стандарты их обеспечения даны в спецификации ISO 9000, состоящей из трех частей:

• ISO 9000-1: Руководящие указания по выбору и применению;
• ISO 9000-2: Общие руководящие указания по применению стандартов ISO 9001, 9002, 9003;
• ISO 9000-3: Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения.

Собственно, третья часть стандарта ISO 9000 и будет нас интересовать.

Многие западные компании, причем не только производители товаров, но и поставщики услуг - медицинские центры, финансовые институты - стремятся сегодня пройти сертификацию на соответствие одному из стандартов ISO 9001-9003. Организаций, которые специализируются на разработке программного обеспечения, среди них пока немного, но и здесь наблюдается явная тенденция роста. Тем более знаменательно, что такие компании появляются теперь и в России, например, летом 1998 г. компания Аргуссофт получила международный сертификат на соответствие стандарту ISO 9000-3.

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

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

ISO 9000-3 - система качества для ПО

Стандарт ISO 9000-3 включает в себя все положения общего стандарта ISO 9001, а также необходимые дополнения к ним, относящиеся к разработке, поставке и обслуживанию ПО. ISO 9001 устанавливает требования к системе качества поставщика и позволяет оценивать его возможности по проектированию и поставке продукции, соответствующей этим требованиям. Требования стандарта направлены в первую очередь на то, чтобы удовлетворить запросы пользователя, предупредив появление каких-либо несоответствий продукции на всех стадиях ее жизненного цикла - от проектирования до обслуживания.

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

• продукт - результат действий или процессов;
• программный продукт - набор компьютерных программ, процедур и, возможно, связанных с ними документов и данных;
• элемент программного обеспечения (software item) - любая идентифицируемая часть программного продукта;
• основание (baseline) - формально утвержденная версия элемента конфигурации, зафиксированная в определенный момент времени в процессе жизненного цикла элемента конфигурации;
• разработка (development) - процесс жизненного цикла программного продукта, охватывающий анализ требований, проектирование, кодирование, интеграцию, тестирование, установку и поддержку;
• модель жизненного цикла (life cycle model) - базовая модель, включающая процессы, действия и задачи, вовлеченные в разработку, функционирование и сопровождение программного продукта и хватывающие весь жизненный цикл системы от определения требований до завершения использования;
• этап (phase) - определенный сегмент работы;
• регрессионное тестирование (regression testing) - тестирование, позволяющее убедиться в том, что изменения, внесенные с целью исправления обнаруженных ошибок, не породили новых;
• репликация (replication) - копирование программного продукта с одного носителя на другой.

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

Основные разделы стандарта

Ответственность руководства

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

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

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

Система качества

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

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

Анализ контракта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление документацией и данными

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

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

Закупки

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

Идентификация и прослеживаемость продукции

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

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

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

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

Управление процессами

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

Контроль и испытания

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

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

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

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

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

Управление несоответствующей продукцией

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

Корректирующие и предупреждающие действия

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

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

Погрузочно-разгрузочные работы, хранение, упаковка, консервация и поставка

Этот раздел стандарта ISO 9000-3 конкретизирует специфику возможных повреждений программного продукта, средства хранения, методы упаковки, консервации и поставки ПО.

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

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

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

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

Управление регистрацией данных о качестве

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

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

Внутренний аудит качества

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

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

Подготовка кадров

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

Обслуживание

Что касается программного обеспечения, то обслуживание здесь понимается как сопровождение системы (maintanance) и поддержка заказчиков (customer support). Поддержка заказчиков обсуждается в стандарте ISO 9000-2.

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

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

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

Литература