Удлинение сроков разработки ПО чревато удорожанием конечного продукта а не выявленные в ходе тестирования
Работа добавлена на сайт samzan.net:
Рынок программных средств
Технологии оценки качества программных продуктов
В современном мире разработка ПО превратилась в одну из самых дорогостоящих индустрий и любые узкие места в технологическом процессе его создания могут привести к нежелательным результатам. Удлинение сроков разработки ПО чревато удорожанием конечного продукта, а не выявленные в ходе тестирования ошибки приводят как минимум к снижению его производительности. Примитивные ошибки, невнятные сообщения и неряшливый интерфейс раздражают пользователей, которые в итоге выбирают более качественный продукт конкурента, а фирма рискует потерять не только клиентов, но и свою долю рынка. Итак, качество ПО приобретает первостепенное значение. Но как оценить это самое качество и в чем его измерить? Можно ли создать "добротный" программный продукт, пользуясь убогими инструментальными средствами? Ответам на поставленные вопросы, а также описанию инструментария, позволяющего оценивать качество ПО, и посвящена данная статья.
Количественная оценка качества ПО
Сравнивать качество программных продуктов "на пальцах" не слишком удобно, поэтому целесообразность применения количественных методов оценки качества (метрик) очевидна. Дитер Ромбах (Dieter Rombach), сотрудник американской организации Software Engineering Laboratory (SEL), в 1991 г. на парижской конференции по вопросам компьютерных вычислений Euromantics заявил: "Мы больше не должны задаваться вопросом, нужны ли компьютерные метрики. Проблема заключается в том, как их строить". Подобный подход исповедует и Международная организация по стандартизации - ISO (стандарт ISO 9000-3, раздел 6.4). История программных метрик насчитывает четверть века, а началась она с того момента, когда стоимость коммерческих продуктов стала расти и потребовались научные методы создания стандартов и анализа процессов разработки ПО. Программирование из искусства постепенно превращалось в инженерную дисциплину.
Введение строгих количественных метрик в программирование должно было способствовать решению ряда практических задач: - предсказывать вероятное число ошибок в системе с самого начала проектирования; - на основе анализа фазы проектирования системы предсказывать уровень сложности последующего сопровождения; - на основе анализа исходного кода программ прогнозировать уровень сложности процессов тестирования и процент остающихся ошибок; - по оценкам сложности фазы проектирования системы определять конечный размер кода; - определять корреляцию отдельных характеристик программного кода с качеством готовой системы; - контролировать стадии развития проекта; - анализировать явные и скрытые дефекты; - на основе экспериментального сравнения выявлять лучшие методы и технологии.
По мере роста актуальности программных метрик на рынке стали появляться различные "измерительные" программы. Одни из них исследовали характеристики проектов и ПО комплексно, другие ориентировались на вполне конкретные цели: анализ исходного кода, размеров и структуры отдельных модулей и т. д.
Например, известная программа Metricate производства Software Productivity Centre зондирует практически все аспекты деятельности софтверных компаний: эффективность технологических процессов, качество программного кода, уровень управления проектами, стоимость выполнения различных этапов, производительность получаемой системы, продуктивность труда разработчиков и качество готовых изделий. Несмотря на многочисленные исследования программных метрик (по данной тематике опубликовано около 5 тыс. статей), в этой области по-прежнему остается много нерешенных вопросов. Во-первых, технология измерения качества еще не достигла зрелости. Во-вторых, отсутствуют единые стандарты на метрики. Самый популярный стандарт, относящийся к производству надежного ПО (Standard Dictionary of Measures to Product Reliable Software института IEEE), так и не стал общепринятым. В результате каждый поставщик "измерительной" системы предлагает свои собственные способы оценки качества и соответственно метрики. На сегодняшний день известно более тысячи видов метрик. Тем не менее теория и практика программных метрик продолжают развиваться и есть надежда, что консенсус в этой области все же будет достигнут.
Три источника и три составные части процесса создания качественного ПО
Можно сказать, что технология создания программы держится на трех китах. Во-первых, это люди - разработчики программ, во-вторых, процессы, в виде которых организован выпуск ПО, и, наконец, технологии, в соответствии с которыми реализуются эти процессы. Ясно, что качество цепочки определяется качеством составляющих звеньев, но не в последнюю очередь и организационными мерами. Даже очень талантливые специалисты нуждаются в организованной инфраструктуре, без которой невозможна коллективная работа. При слабой организации процессов современная технология используется неэффективно, а погоня за новейшими достижениями без совершенствования производственных процессов способна только ухудшить состояние дел в компании.
Очевидно, что качество получаемого ПО зависит от квалификации разработчиков, состав которых неоднороден в силу ярко выраженной специализации. В каждом крупном проекте есть аналитики, которые ставят задачи, системные программисты, подготавливающие инструментарий для программистов прикладных, группа тестирования ПО, технические писатели и специалисты по установке и сопровождению готовых систем. Профессиональные производители программных продуктов давно уже смогли убедиться, что самый верный способ улучшить программы - это усовершенствовать процессы их создания. За последние десять лет разработано (и реализовано) множество концепций совершенствования указанных процессов. Все они, хотя и носили разные названия, преследовали общую цель. Например, американский Software Engineering Institute (SEI) предложил концепцию "Улучшение процессов создания ПО" (Software Process Improvement, SPI), которая опиралась на статистические методы контроля технологических процессов, разработанные в Японии в конце 30-х годов. Позднее появились и другие концепции: "Сквозной контроль качества" (Total Quality Management, TQM), "Реинжиниринг деловых процессов" (Business Process Reengineering, BPR), предполагающий модернизацию базовых бизнес-процессов организации, "Постепенное совершенствование деловых процессов" (Business Process Improvement, BPI).
В основе всех этих концепций лежит общее понимание жизненного цикла ПО как совокупности фаз, которые проходит программный продукт в процессе своего развития (рис. 1).Это:
- выработка исходных требований к ПО со стороны пользователя;
- формулирование общих требований к ПО со стороны разработчика (системные требования);
- проектирование архитектуры;
- детальная реализация ПО;
- инсталляция ПО в организации заказчика;
- эксплуатация.
Фазы могут перекрываться по времени, а некоторые процессы вестись параллельно. Условно говоря, третья версия программы может находиться на этапе проектирования, тогда как вторая - на стадии инсталляции. Для поддержания жизненного цикла ПО фирмы-разработчики организуют свою деятельность по нескольким ключевым направлениям: - управление проектом (планирование, распределение ресурсов, контроль исполнения и сроков);
- тестирование (проверка соответствия качества готового продукта исходным требованиям и проверка функционирования);
- конфигурационный менеджмент (поддержка версий, редакций, вариантов ПО на уровне исходного кода, дистрибутивов, документации);
- сопровождение (установка продукта, обучение пользователей, устранение ошибок, развитие функциональных возможностей, поставка upgrade-версий, техническая поддержка).
Возникает вопрос: в какой степени "кухня" производителя, которая вроде бы остается его личным делом, может затрагивать интересы потенциальных покупателей?
Достижение зрелости
Пользователю важно знать, насколько качественно проработаны производственные процессы в той фирме, продукцию которой он намерен приобрести.
Для определения общего уровня развития технологических процессов в программных организациях уже упоминавшийся SEI и Университет Карнеги - Меллона разработали специальную систему оценки зрелости технологических процессов в организациях, специализирующихся на выпуске ПО (см. врезку "Модель оценки зрелости..."). Предложенная ими модель Capability Maturity Model (CMM) основана на так называемых уровнях зрелости (maturity levels). Всего их пять, и каждый из них характеризует определенную степень качества выпускаемых изделий. Таким образом, чем выше уровень зрелости компании, тем выше ее статус и авторитет в компьютерных кругах и в глазах пользователей (рис. 2).
Уровень 1.
Начальный (initial).
Обычно с этого уровня начинает свою деятельность большинство организаций. На данном этапе процесс разработки носит неструктурированный и случайный характер. Коммерческий успех, если и сопутствует проекту, определяется скорее выдающимися способностями какого-нибудь талантливого разработчика или менеджера, нежели организационной инфраструктурой компании. В организации отсутствует стабильная среда разработки и сопровождения. Сроки выпуска продуктов, как правило, не выдерживаются. В кризисной ситуации фирма "забывает" о предварительно составленных планах и все силы бросает на кодирование и тестирование программы. По оценкам SEI, в настоящее время около 75% софтверных фирм пребывают на начальном уровне.
Уровень 2.
Повторяемый (repeatable).
Успешная реализация проектов становится возможной благодаря жесткому управлению, планированию и контролю. Акцент в данном случае делается на выработку исходных требований, методы оценки и конфигурационный менеджмент. Разработка новых проектов ведется на основе ранее накопленного опыта и в соответствии с определенными стандартами на разработку ПО. Данный уровень могут обеспечить около 15% организаций. Как показывает практика, переход с первого уровня на второй наиболее сложен, поскольку требует комплексного внедрения основных технологических процедур.
Уровень 3.
Фиксированный (defined).
Процессы, относящиеся к сфере управления и инженерной деятельности, полностью документированы, стандартизованы и интегрированы в единый технологический поток, контролируемый управляющим персоналом. Этот уровень в состоянии поддерживать 8% софтверных компаний. Уровень 4.
Управляемый (managed).
Организации пытаются оценить качество процессов и готового продукта количественно. Для контроля над процессами используются количественные показатели (метрики). Все процессы предсказуемы и укладываются в заранее определенные рамки. Данного уровня достигло около 1,5% организаций.
Уровень 5.
Оптимизируемый (optimizable).
Компании стремятся улучшить свою работу, руководствуясь количественными критериями качества. Имеются средства локализации узких мест в производственных процессах. Основная цель - выпуск бездефектных продуктов, в которых все ошибки устранены еще на стадии внутреннего тестирования.
Менеджеры, наблюдая за деталями процесса разработки "сверху", имеют возможность выявить потенциальные проблемы проекта на ранних стадиях его реализации и принять соответствующие корректирующие меры. Поскольку все процессы проекта получают количественное измерение, любые оценки и прогнозы становятся более реалистичными, а сам процесс разработки - предсказуемым.
Только 0,5% компаний могут поддерживать столь высокий уровень технологической зрелости.
Чтобы помочь потенциальным сторонникам методологии CMM разобраться в тонкостях модели, фирма Process Focus Software (Тампа, шт. Флорида) предлагает программу CMM Live, представляющую собой своеобразный электронный справочник, самоучитель и эксперт-советник по технологиям CMM. С его помощью пользователи смогут легко разобраться в терминологии CMM, оценить собственный уровень по шкале CMM и понять, что надо делать для повышения своего статуса.
Аналогичные цели преследует и пакет SoftGuide от Software Productivity Centre, ориентированный на разработчиков ПО, которые стремятся улучшить качество своих процессов. SoftGuide задает множество вопросов и по полученным ответам судит о состоянии дел в тестируемой организации. После идентификации существующих проблем для их решения предлагаются конкретные меры. Процедура выполняется в четыре этапа: диагностика проблем, расстановка приоритетов в их решении, составление подготовительного плана и выработка плана конкретных действий. Другие модели качества CMM и стандарты ISO способствовали появлению аналогичных моделей и стандартов качества в некоторых развитых странах. По мнению их авторов, предложенные варианты в большей мере отвечают внутренним требованиям конкретных стран.
В настоящее время Германский национальный исследовательский центр по информационным технологиям (GMD) завершает работу над проектом SCOPE*PROCEPT, охватывающим информационные модели процессов создания ПО, включая методы оценки качества на основе метрик. Уже сейчас модель SCOPE*PROCEPT опробована в 20 крупных промышленных проектах и внесена на обсуждение в ISO.
В состав SCOPE*PROCEPT входит несколько компонентов, соответствующих различным сторонам деятельности по созданию программ:
- специфицирование процессов программирования и тестирования (ProcePT). Данный компонент предназначен для выработки спецификаций и тестирования используемых в проектах технологических процессов. Разработка процессов ведется по нисходящей схеме (рис. 3), начиная с уровня общей модели процесса. Далее путем итерационных уточнений автоматически создается комплект необходимых документов: разнообразные справочники по проекту, описания типов деятельности, перечни продуктов, которые будут выпущены в ходе работы над проектом, соответствующие диаграммы и схемы;
- инжиниринг моделей качества (Model Y7). Суть его в определении модели качества для данного проекта с использованием методов оценки качества; подразумевает встраивание этой модели в существующие технологические и бизнес-процессы;
- измерение характеристик (метрик) ПО (SMV). Можно представить в виде своеобразного испытательного стенда, на котором проводятся количественные исследования характеристик программ; - интегрированная среда для измерения характеристик компиляторов (CISM);
- моделирование процессов производства ПО (SPM). Данный компонент предназначен для оценки качества процессов разработки, причем на основе количественных показателей.
Модель Trillium, созданная в 1994 г. фирмами Bell Canada, Nothern Telecom и Bell-Nothern Research, предлагает еще один способ оценки процессов выпуска продуктов в телекоммуникационной и информационной областях и охватывает все аспекты жизненного цикла ПО. Хотя в ее основе и лежит уже рассмотренная Capability Maturity Model, эти модели существенно отличаются друг от друга. Помимо CMM, Trillium опирается на ряд других регламентирующих документов и стандартов: ISO 9001 и ISO 9000-3, стандарты Bellcore TR-NWT, значительную часть стандартов Malcolm Baldrige National Quality Award, стандарты IEEE и IEC.
Моделью Trillium охвачены следующие виды деятельности:
- управление качеством (Quality Management);
- проектирование бизнес-процессов (Business Process Engineering);
- оценка технологической зрелости (Technological Maturity Assessment);
- создание сред разработки (Development Environment);
- системное проектирование (System Engineering);
- ко-инжиниринг (Co-Engineering);
- совместное проектирование (Concurrent Engineering); - надежное проектирование (Reliable Engineering); - поддержка клиентов/партнерство (Customer Support/Partnership). Интересен и способ классификации уровней зрелости в модели Trillium: в его основе лежит фактор риска. Существует пять уровней зрелости.
Уровень 1.
Характеризуется хаотичностью. Качество продуктов низкое, сроки завершения проектов нарушаются. Риск высокий.
Уровень 2.
Повторяемый и ориентированный на процессы. Успех проектов обусловлен внедрением систем управления проектами, планирования и менеджмента. Особое внимание уделяется выработке исходных требований, конфигурационному менеджменту и оценке качества готовых систем. Риск средний.
Уровень 3.
Определенный и ориентированный на процессы. Все производственные процессы определены (т. е. зафиксированы) и используются в масштабе всей компании, хотя "подкрутка" отдельных процессов в целях успешного выполнения проектов допускается. Процессы полностью контролируются и постоянно совершенствуются. Стандарты ISO 9001 внедрены в части обучения персонала и внутреннего аудита. Риск невысокий.
Уровень 4.
Управляемый и интегрированный. Основным средством повышения качества процессов становятся анализ и инструментальные системы. Функции отслеживания изменений и профилактики ошибок встраиваются в процессы. Активно используются CASE-средства. Риск довольно небольшой.
Уровень 5.
Полностью интегрированный. Широко применяются формализованные методологии. Для хранения истории разработки применяется репозиторий. Риск минимальный.
Технологии
Чтобы достичь очередного уровня зрелости, организация должна освоить регламентированный, например, моделью CMM набор технологических приемов или видов деятельности. С этой целью был создан и продолжает совершенствоваться специфический класс инструментальных программ, позволяющих автоматизировать процессы разработки ПО. Все пакеты данной категории весьма специализированны. Одни из них поддерживают несколько типов деятельности, другие только один. Рамки данного обзора не позволяют описать все аспекты технологии разработки, соответствующие приведенным уровням зрелости (табл. 1), и подробно проанализировать все виды поддерживающего их инструментального ПО. Мы рассмотрим лишь важнейшие процессы и проиллюстрируем их наиболее известными инструментальными пакетами.
Методология
Программы приобретают высокое качество не столько в результате комплексного тестирования конечного продукта, сколько в процессе его разработки. Если методология создания ПО такова, что ошибки "вылавливаются" на регулярной основе и на всех стадиях выполнения проекта, то на выходе "программного конвейера" предстает продукт, в котором практически нет ошибок. Корпорация IBM предлагает методологию создания сложных программных комплексов, получившую название Cleanroom Software Engineering. Она ориентирована на профессионалов, желающих усовершенствовать свои методы разработки ПО, и охватывает такие стороны программистской практики, как реализация модели CMM, планирование и управление проектами, собственно разработку программ (выработка спецификаций, проектирование, кодирование), профилактику ошибок, тестирование и сопровождение. Cleanroom - это совокупность административно-технологических процессов, позволяющих коллективам разработчиков планировать, измерять, специфицировать, проектировать, кодировать, тестировать и сертифицировать программные продукты. Методология Cleanroom построена на трех концепциях: модульном принципе специфицирования и проектирования, математическом доказательстве правильности применяемых алгоритмов и использовании статистики по результатам тестирования как основы для оценки надежности программ (сертификации).
Метод пошаговой детализации
С административной точки зрения методология Cleanroom представляется в виде цикла пошаговой детализации проекта, когда конечная функциональность системы достигается итерационно. На каждом этапе реализуется определенный уровень функциональных возможностей, который тестируется и сертифицируется автономно. Такой способ разработки имеет несколько плюсов. С одной стороны, разработчики (и заказчик!) видят, как система растет и развивается, а с другой - возникают хорошие предпосылки для улучшения не только самого продукта, но и процессов его производства - ведь на каждом этапе программисты анализируют источники возникновения ошибок и стараются их устранить. На этапе формирования архитектуры будущей системы процедуры тестирования проводятся более тщательно, что позволяет локализовать ошибки на ранних стадиях.
Степень детализации проекта, т. е. число шагов, необходимое для достижения заданной функциональности, зависит от ряда факторов, а ее соблюдение является, видимо, важнейшей задачей, которую приходится решать руководителям проекта.
Поскольку длительность и другие параметры каждого этапа могут корректироваться в ходе работы над проектом, любые изменения в исходных требованиях удается учесть с минимальными затратами.
Выработка спецификаций
Спецификации Cleanroom дают полное и точное описание функций системы. Выработка спецификаций способствует более глубокому пониманию требований, предъявляемых к конечному продукту, и его функций, а сами спецификации служат основой для тестирования, сертификации и дальнейшего развития системы. Согласно методологии Cleanroom системы строятся по модульному принципу. При этом различают три категории модулей: модуль типа "черный ящик" (black box), модуль-описатель (state box) и "прозрачный" модуль (clear box), которые отражают суть технологии пошаговой детализации. "Черный ящик" представляет собой спецификацию всей системы или ее части с точки зрения внешнего "пользователя" (им может быть обычный пользователь либо объект системы). "Пользователь" воздействует на "черный ящик", который определенным образом откликается (реагирует) на эти воздействия. Цель введения спецификаций "черного ящика" в том и заключается, чтобы описать корректное поведение системы во всех вероятных ситуациях.
Проектирование и верификация
Процесс проектирования в методологии Cleanroom сводится к формальному описанию функций, необходимых для реализации поведения "черного ящика", т. е. к созданию модуля-описателя. Данный процесс напоминает проектирование объектов в объектном программировании, когда данные и функции (методы) инкапсулируются в единой сущности. "Прозрачный" модуль - это программная реализация функций модуля-описателя. При написании программ должны использоваться только базовые конструкции из технологии структурного программирования (блоки, ветвления, циклы). Процесс программирования может приводить к рождению новых "черных ящиков", модулей-описателей и т. д. Качество программного кода (соответствие работы программы заложенным спецификациям) проверяется в ходе верификации.
Тестирование надежности
Инструментом автоматизированного тестирования и оценки надежности ПО в методологии Cleanroom служит среда Cleanroom Certification Assistant, в основе которой лежит идея использования статистических результатов тестирования для подсчета надежности ПО математическими методами. Специальный компонент Statistical Test Generation Facility (STGF) имеет собственный язык описания тестовых данных, позволяющий запрограммировать сценарий тестирования - характер распределения данных, моменты возникновения критических событий и т. д. В результате STGF генерирует код на языке C, который после компиляции и запуска подает на вход тестируемой программы пробные данные. Второй компонент - Cleanroom Certification Model - фиксирует результаты тестирования в виде показателей MTTF (Mean Time To Failure - среднее время наработки на отказ), которые и используются для вычисления метрик надежности.
Однажды сгенерированная программа тестирования может использоваться повторно в целях сравнения надежности и производительности разных версий разрабатываемого ПО.
Другая известная программа производства IBM - Workstation Interactive Test Tool - в сочетании с STGF позволяет создавать самотестирующиеся приложения.
Практические результаты
Практика использования методологии Cleanroom в проектах, выполненных специалистами IBM (табл. 2), выявила снижение числа ошибок и дефектов в конечном коде в два - десять раз. Независимость методологии Cleanroom от конкретного типа аппаратных и программных платформ делает ее пригодной для разработки различного ПО - от распределенных приложений в среде клиент/сервер до ассемблерных программ. Многие известные организации, такие как AT&T, Chase Manhattan, Reuters, Merrill Linch, использовали Cleanroom в своих проектах и также добились заметных успехов в части уменьшения числа ошибок, повышения производительности труда и снижения стоимости разработок.
Управление проектами
Создание качественного ПО предполагает оперативный контроль за ходом работы над проектом, удобство взаимодействия членов коллектива разработчиков между собой и эффективное распределение временных и человеческих ресурсов.
Система ProcessWeaver компании Cap Gemini Innovation позволяет автоматизировать процесс разработки с использованием терминов взаимозависимых заданий и совокупности входных/выходных данных, необходимых для реализации конкретного задания. Перед началом работы руководитель проекта дает описание технологических процессов, которые приняты в данной компании, определяет информационные потоки и утверждает списки разработчиков (компонент Method and Activity). ProcessWeaver организует деятельность бригады разработчиков в виде потока заданий. Руководитель проекта строит схему проекта в виде последовательности выполняемых заданий с указанием исполнителей и входных/выходных данных для каждого задания. Кроме того, составляется план-график работ.
Посредством утилиты Agenda все участники проекта могут просмотреть перечень своих заданий. Каждое задание ассоциируется с рабочим контекстом - описанием типа деятельности, необходимой входной информации, получаемыми результатами и используемыми инструментальными средствами (например, в виде текстового редактора, CASE-средств, компиляторов). Когда задание завершено, его результаты по цепочке передаются следующему исполнителю. По общей схеме проекта всегда можно проанализировать его текущее состояние: какие задания уже выполнены, а какие - нет.
ProcessWeaver имеет интерфейс ко многим другим пакетам управления проектами - StP, Teamwork, Logiscope и Microsoft Project. Microsoft Project (MS-Project) - еще одно средство управления проектами, в котором акцент сделан на проблеме управления ресурсами. Рабочее поле MS-Project состоит из трех областей. В первой выводятся списки заданий и подзаданий с указанием временных рамок их выполнения и задействованных исполнителей. Во второй области даны временные диаграммы процессов с отметками критических сроков. Наконец, в третьем окне собрана информация о текущей загрузке ресурсов. В отличие от ProcessWeaver продукт MS-Project оперирует статической информацией. Чтобы скорректировать временной график, исходные данные приходится вводить вручную.
Однако пакеты ProcessWeaver и MS-Project удачно дополняют друг друга: первый воспринимает файлы MS-Project и на их основе способен построить "скелет" потока заданий. В свою очередь, MS-Project может прочесть "живую" информацию о состоянии заданий проекта и скорректировать свои диаграммы автоматически, без ручного ввода. Также полезным продуктом в руках менеджера проекта может стать программа AMItool, созданная в European Laboratory for Particle Physics (CERN) и позволяющая с помощью метрики AMI (Application of Metrics in Industry) дать количественную оценку состояния компании, а также предлагающая план улучшения технологических процессов. Сначала программа задает оператору ряд вопросов (их список составлен SEI), оценивает степень зрелости процессов по шкале CMM и представляет результаты оценки в виде Kiviat-графа, ветви которого соответствуют различным технологическим процессам (сопровождение, обучение, техническая поддержка и т. д.) и имеют пять уровней CMM. По результатам тестирования составляется список наиболее приоритетных целей, например совершенствование обучения персонала или организация контроля ошибок, который затем трансформируется в дерево целей и план действий. Важная проблема, которую приходится решать во время работы над проектами, - это обмен информацией. Особой остроты она достигает, когда участники проектов территориально разобщены. Очевидно, что самое простое ее решение лежит на поверхности и называется электронной почтой, однако, если в дискуссии одновременно участвуют более двух человек, такой метод неудобен. В подобной ситуации рекомендуется использовать систему WIT (World Wide Web Interactive Talk), позволяющую организовать дискуссию с множеством участников по сети Internet. Основным элементом системы WIT является "Дискуссионное окно" (Discussion Area), соответствующее предметной области, в рамках которой ведется обсуждение. Внутри дискуссионного окна имеется набор "Тем" (Topics), связанных с определенными аспектами данной дискуссии. Участники дискуссии выражают свою точку зрения в виде "Предложений" (Proposals), которые передаются в WIT в форме сообщений. Основное преимущество WIT перед обычным обменом сообщениями через телеконференции заключается в том, что информация в этой системе хорошо структурирована. В окне Proposals сразу видно, какие вопросы обсуждаются, кто с кем согласен или не согласен. Кроме того, есть уверенность, что посланное в WIT сообщение не пропадет, а станет частью информационной структуры, относящейся к теме дискуссии. Аналогичные проблемы решает и коммерческий пакет Lotus Notes в сетях на базе платформ Unix, PC и Macintosh. На всех стадиях работы над проектом рождаются многочисленные документы (исходные требования, системные спецификации, исходные тексты программ, инструкции по эксплуатации и пр.), созданные различными специалистами. В крупных распределенных проектах, в которых задействованы большие коллективы разработчиков, а ПО и сопроводительная документация создаются в разных местах, проблема эффективного использования информационных материалов только обостряется. Для ее решения была создана LIGHT (Life cycle Global HyperText - глобальная гипертекстовая система для поддержки жизненного цикла ПО), которая, как и WIT, опирается на технологию WWW.
Все зарегистрированные в системе документы (графические материалы, исходные тексты программ, спецификации и др.) отображаются на навигационной карте (navigation map). После указания мышью пиктограммы документа последний открывается и выводится список прочих документов, связанных с исходным перекрестными ссылками. На рис. 4 представлен принцип действия системы LIGHT. Исходные документы сначала просматриваются специальными программами-сканерами, которые формируют LIGHT-словари всевозможных гипертекстовых ссылок между источниками и приемниками. После заполнения словарей в дело вступает LIGHT-генератор, преобразующий исходные документы в HTML-страницы, извлекая необходимую навигационную информацию из словарей и конфигурационного файла. Доступ к Web-страницам из Web-броузера осуществляется посредством запросов к диспетчерской программе LIGHT Solver, которая на выходе формирует физический URL-указатель.
Верификация и тестирование
Под верификацией ПО понимают проверку готового продукта или его промежуточных версий (как это принято, например, в технологии Cleanroom Software Engineering) на соответствие исходным требованиям. При этом подразумевается не только тестирование самой программы, но и аудит проекта, пользовательской и технической документации и т. д. На рынке существует множество продуктов, позволяющих автоматизировать процесс верификации. Среди них Purify, TestCenter, Logiscope и др. Пакет Logiscope компании Verilog - это семейство инструментальных программ (TestChecker, CodeChecker, RuleChecker, ImpactChecker и Viewer), объединенных общей целью: помочь пользователям улучшить качество и провести всестороннее тестирование создаваемого ПО. В основе продукта лежит идея анализа исходного кода. Его последняя версия способна обрабатывать тексты программ, написанные более чем на 80 языках, включая C, C++, Pascal, Cobol, Fortran, PL1, ADA и даже языки ассемблера Intel и Motorola. Результаты анализа представляются в виде числовых показателей (метрик, которых существует более 50 типов), позволяющих судить о качестве исходного кода программ. Компонент TestChecker наблюдает за поведением тестируемой программы в ходе ее исполнения и в процессе своей работы строит деревья вызовов, профили выполнения, отмечает невызываемые функции и неисполняемые процедуры. Logiscope поддерживает функцию обратного проектирования, c помощью которой можно восстановить структуру программы по объектному коду, что полезно для понимания логики ее работы и характера используемых данных. Специально для профессиональных программистов на языках C и С++ предназначена программа TestCenter компании CenterLine. Из статистических данных следует, что при обычном тестировании проверяется "исполнимость" только 40 - 50% общего кода программ. Объясняется это тем, что при традиционном, "ручном", тестировании невозможно проверить работу программы со всеми возможными комбинациями исходных данных или смоделировать редко встречающиеся ошибки типа нехватки памяти (out of memory). При таких процедурах тестирования трудно говорить о высоком качестве готовых программ. Пакет TestCenter позволяет организовать глобальное тестирование ПО на промышленном уровне, а само тестирование сделать естественной частью процесса разработки за счет его непосредственной интеграции с другими известными инструментальными оболочками (SPARCworks, SoftBench, ObjectCenter и ObjectCode).
В процессе отладки/тестирования программ TestCenter показывает строки исходного кода, не исполняемые во время проведения теста, неинициализированные участки памяти, память, которая резервировалась, но не использовалась, использовалась, но не освобождалась, случаи неверного применения операторов malloc/free и др. Имитатор ошибок (Error Simulator) может генерировать редко встречающиеся и трудно отлаживаемые ошибки типа disk full (нет места на диске) или упомянутой out of memory, а имитатор API (Simulator API) - интерфейсные ошибки, например неправильный порядок аргументов при вызове функций или некорректный код возврата. При использовании TestCenter не возникает необходимости в перекомпиляции программ, а для работы Error Simulator не понадобится даже исходного кода тестируемой программы. Компания Pure Software (Саннивейл, шт. Калифорния), ведущий производитель автоматизированных инструментальных средств создания качественного ПО (ASQ, Automated Software Quality), предлагает разработчикам Windows-приложений на языке C++ систему Purify, которая позволяет выявлять разнообразные ошибки программ, включая ошибки исполнения (run-time errors) и "утечки" памяти. Особенностью пакета является использование специально разработанной и запатентованной технологии OCI (Object Code Insertion), в соответствии с которой Purify вставляет в объектный код тестируемой программы вспомогательные объекты (перед и после операторов "load" и "store"), что позволяет детально контролировать доступ к памяти и выявлять такие ошибки, как использование неинициализированных переменных, некорректные операции malloc/free, выходы за границы массивов, неправильная работа с указателями, стековые ошибки. При обнаружении ошибки Purify загружает отладчик, чтобы программист по горячим следам мог ее отыскать. Кстати, Purify поддерживает практически все известные текстовые редакторы и отладчики.
Еще одна характерная особенность продукта - способность исследовать код не только собственно приложения, но и библиотек третьих фирм, динамически подключаемых библиотек, а кроме того, ассемблерный код и код системных вызовов.
Работа над ошибками может вестись либо в интерактивном, либо в пакетном режиме, когда вся диагностика сохраняется в виде отчетов. При этом Purify информирует оператора о возможных последствиях обнаруженной ошибки: проявятся они немедленно или в дальнейшем. Программа полностью поддерживает технологию OLE на уровне клиентов и серверов, что позволяет разрабатывать и отлаживать сложные многокомпонентные системы. Наконец, Purify поддерживает многопоточные и мультипроцессорные приложения, а также программы, исполняемые на компьютерах с несколькими процессорами.
Конфигурационный менеджмент
Цель конфигурационного менеджмента - обеспечить управление версиями ПО. Это означает, что для каждой версии должны отдельно храниться исходные тексты программ и исполнимые коды, комплекты документации, тестовые данные и результаты тестирования, списки обнаруженных ошибок и файлы с исправлениями (patch), посредством которых корректируются ошибки в исполнимых модулях программ и осуществляется переход к новым версиям. Очевидно, конфигурационный менеджмент особенно важен при работе над крупными системами с большим числом разработчиков и множеством инсталляций.
Пожалуй, самым известным производителем инструментария в области конфигурационного менеджмента является компания Intersolv, выпускающая семейство хорошо интегрированных между собой продуктов (PVCS Version Manager, PVCS Tracker, PVCS Notify, PVCS Configuration Builder, PVCS Reporter, PVCS Production Gateway, PVCS Developer's Toolkit, PVCS Version Manager Interface for Visual Basic). "Глава" семейства - PVCS Version Manager - обладает следующим необходимым набором характеристик, позволяющим автоматизировать управление сложными проектами, в которых задействовано большое число разработчиков: - развитым графическим интерфейсом (поддержка функции буксировки при добавлении файлов в проект, триггеров, запускающих специальные функции при наступлении определенных событий, и др.); - удобными средствами работы с архивными файлами проектов; - поддержкой длинных имен файлов, принятых в Unix, HPFS и NTFS; - расширенными функциями защиты (предоставление прав доступа к ресурсам проекта для индивидуальных пользователей или групп). Другим мощным средством контроля версий исходных текстов программ является пакет Microsoft Visual SourceSafe. Подобно большинству продуктов этого класса SourceSafe поддерживает функции хранения и организации исходного кода, обеспечивает взаимодействие между разработчиками, отслеживает различия между версиями файлов. В то же время, в отличие от программ-аналогов, SourceSafe выполняет свои функции с точки зрения управления проектом, освобождая разработчиков от необходимости отслеживать связи между файлами. К числу наиболее полезных свойств этого пакета можно отнести: - поддержку различных типов файлов (текст, графика, аудио, видео, двоичные и др.); - возможность использования файлов в разделяемом режиме на нескольких платформах (Windows 95, Windows 3.1, Windows NT Workstation и Unix); - средства совместной работы с файлами; - возможность повторного использования кода в нескольких проектах; - иерархическую организацию файлов проекта; - отслеживание изменений для каждой версии файла (при этом физически хранится только последняя версия); - управление правами доступа пользователей к файлам проекта; - встроенный генератор отчетов; - возможность отката версий.
Компания Hewlett-Packard разработала собственную программу конфигурационного менеджмента SoftBench CM, ориентированную на рабочие группы, в том числе имеющие территориально удаленных сотрудников. Система реализована в архитектуре клиент/сервер и обеспечивает доступ к удаленным и локальным серверам. Кроме того, SoftBench допускает совместное использование одних и тех же файлов из различных ЛС. К основным функциям продукта относятся поддержка текстовых и двоичных файлов, расширенная система нумерации версий, входной/выходной контроль, сжатие данных, мониторинг истории редактирования файлов, параллельная работа с файлами, внутренний аудит. Пакет SoftBench CM совместим с другими инструментальными средствами, выпускаемыми Hewlett-Packard, - SoftEdit, SoftBuild, SoftStatic и Development Manager.
Особое место в конфигурационном менеджменте занимает процесс перехода с одной версии ПО на другую. Если размеры программных продуктов достигают нескольких десятков мегабайт, то поставка клиентам upgrade-версий превращается в проблему, которую, впрочем, довольно просто решить с помощью пакета .RTPatch Professional компании PocketSoft. Алгоритм его работы прост: после сравнения двух файлов выявленные расхождения фиксируются в относительно небольшом файле исправлений (patch). Далее, используя этот файл и специальную утилиту, можно из старого файла получить новый. Именно таким образом и происходит установка upgrade-версий у клиента, которому достаточно выслать не целиком новую версию системы, а только patch-файл. В табл. 3 приведены реальные данные о соотношении размеров готовых систем и соответствующих файлов исправлений.
Технология, предложенная PocketSoft, многим пришлась по душе: ее сторонниками стали более четырех тысяч компаний, в том числе Microsoft, Borland, IBM, Novell, Symantec, Autodesk, Software AG и др. Мы рассмотрели основные, хотя и далеко не все, технологические процессы и поддерживающие их инструментальные средства. Что касается оставшихся процессов, то вопрос с их автоматизацией также успешно решен. На рынке программных средств сегодня имеется широкий спектр программ, предназначенных для автоматизации всевозможных видов деятельности, будь то высокоуровневое проектирование бизнес-процессов или автоматизированное создание пользовательской документации. Как говорится, было бы желание автоматизировать. Итак, качество программного обеспечения, технологическая зрелость компании и стандарты должны быть поставлены разработчиком во главу угла. Но стоит ли игра свеч и нужно ли вообще стремиться к очередной ступени совершенства? По данным SEI, практические результаты свидетельствуют о реальном экономическом эффекте от проведения мероприятий по усовершенствованию процессов разработки программного обеспечения. Например, затраты в размере 1500 ЭКЮ в год на одного инженера-программиста оборачиваются увеличением производительности его труда на 10 - 70%. По мнению всех участников конкурса Baldrige Award, любые инвестиции в качество оборачиваются многократной выгодой как для отдельных компаний, так и для компьютерной индустрии в целом. Стандарты ISO Как все начиналось В 1947 г. в Лондоне представители 25 стран решили создать международную организацию, основной задачей которой стала бы координация разработок и унификация международных стандартов. Новая организация получила название International Organization for Standardization (ISO). В настоящее время ее членами являются около 100 стран. Бросается в глаза несоответствие полного наименования организации и используемой аббревиатуры. "ISO" - это греческий префикс, означающий "равный". В нашем контексте "ISO" можно перевести как "стандарты, равные для всех". Главной причиной рождения стандартов ISO явилось желание инициаторов создания этой организации устранить технические барьеры в торговле, которые возникли вследствие того, что в разных странах для одних и тех же технологий и товаров действовали разнородные стандарты. Сегодня стандартами "перекрыты" многие технологические отрасли - от программирования и телекоммуникаций до банковской и финансовой сферы. По мнению экспертов, в ближайшие годы стандарты ISO по-прежнему будут распространяться ударными темпами, что обусловлено целым рядом факторов: - бурным прогрессом в области интеграции мировой торговли и промышленности, взаимопроникновением рынков. С технологической точки зрения свободная конкуренция немыслима без четко сформулированных, понятных и общепринятых стандартов. Появился расхожий штамп: "Стандарты - язык торговли". В современных условиях ни один рынок не может обойтись без компонентов, производимых на других рынках, а цифровая обработка данных требуется повсеместно; - глобальным распространением компьютерных коммуникационных средств. Вычислительная индустрия - яркий пример технологии, существование которой абсолютно немыслимо без общепринятых стандартов. Полная совместимость открытых систем способствует развитию здоровой конкуренции среди производителей; - потребностью в наличии общих стандартов в процессе становления новейших технологий. На ранних этапах их развития возникает необходимость в стандартизации терминологии и способах представления и хранения количественной информации. Кто входит в состав организации и разрабатывает стандарты По уставу членом ISO может стать "самая авторитетная в стране организация, занимающаяся выработкой стандартов". Таким образом, интересы какой-либо страны в ISO может представлять только одна организация. Помимо основных членов, в ISO входят так называемые члены-корреспонденты (как правило, ими становятся относительно крупные "стандартообразующие" организации отдельных стран, однако еще недостаточно мощные, чтобы распространить свое влияние на стандартизацию технологий по всей стране). Члены-корреспонденты не принимают активного участия в разработке международных стандартов, но имеют полный доступ к интересующей их информации. Наконец, есть еще и члены-подписчики - они представлены организациями развивающихся стран. Выполнение технической работы в ISO возложено на 2700 технических комитетов, подкомитетов и рабочих групп, в состав которых входят представители правительственных, промышленных и научно-исследовательских кругов (на сегодняшний день - около 500 организаций). Каждая организация - член ISO - имеет право включить своего представителя в любой комитет, если она особо заинтересована в деятельности последнего.
Работу комитетов курируют крупнейшие организации - члены ISO: AFNOR, ANSI, BSI, CSBTS, DIN, SIS и др. Принятие стандарта возможно только после достижения консенсуса между квалифицированным большинством членов комитета.
Центральный секретариат ISO, штаб-квартира которого находится в Женеве, публикует исходные версии стандартов, подготовленные комитетами, и рассылает их членам ISO для ознакомления и голосования. Регулярно издаваемый бюллетень "ISO Momento" содержит подробную информацию о структуре и деятельности всех технических комитетов. Круг интересов ISO Сфера деятельности ISO не ограничивается какой-либо конкретной технологической областью. Организацию интересует все и вся, за исключением электротехники и электроники (эти направления контролирует International Electrotechnical Commission - IEC). Работы в области информационных технологий ведутся ISO и IEC (Рабочий комитет JTC 1) совместно.
Как разрабатываются стандарты Новые стандарты рождаются в соответствии с тремя принципами. Во-первых, они являются результатом консенсуса всех заинтересованных сторон - производителей, поставщиков, потребителей, профессиональных разработчиков, правительственных и исследовательских организаций. Во-вторых, стандарты имеют действительно мировое распространение и удовлетворяют как производителей, так и потребителей. В-третьих, появление новых стандартов диктуется исключительно требованиями свободного рынка, а не чьей-то злой или доброй волей. Если рынок созрел для нового стандарта, то такой стандарт появляется. Процесс создания нового стандарта включает три этапа. Обычно инициатива его разработки исходит от производителей, которые доводят базовые предложения стандарта до своего представителя в ISO. Если эта организация признает целесообразность появления нового стандарта, то соответствующая рабочая группа определяет техническую область, на которую предполагаемый стандарт будет распространяться. На втором этапе идет выработка технических спецификаций, в ходе которой представители различных стран стремятся к достижению консенсуса. На заключительном этапе первая версия стандарта утверждается (за стандарт должно проголосовать 75% кворума) и публикуется. С этого момента стандарт становится официальным (ISO International Standard). По мере совершенствования технологий, появления новых материалов, методов обработки, повышения требований к качеству и надежности изделий возникает необходимость в пересмотре стандартов. В ISO существует правило: все стандарты должны пересматриваться не реже одного раза в пять лет. Сегодня "перу" ISO принадлежит 9300 различных стандартов, описание которых занимает 170700 страниц текста на английском языке. Как подготовиться к сертификации ISO 9000 Для прохождения процедуры сертификации в ISO организации должны представить комплект документации, оформленной стандартным способом (Quality System Documentation). Задача эта сложная, и, чтобы упростить ее, можно воспользоваться программой ISOplus, выпускаемой Software Productivity Center. Это комплект более чем из 100 файлов, представленных в формате Word и выполняющих роль шаблонов документов, процедур, анкет и руководств, которые пригодятся в ходе подготовки к сертификации. В разработке шаблонов принимала участие европейская консалтинговая фирма Compita, специализирующаяся в области сертификации ISO и внедрившая стандарты Международной организации по стандартизации в 30 крупных компаниях.
ISOplus выполняет также и роль экспертной системы, которая посредством наводящих вопросов и советов помогает каждой конкретной компании заполнить необходимые документы. Некоторые стандарты ISO ISO 9000-1 (1994 г.) Управление качеством и гарантии качества. Часть 1. Руководство по выбору и использованию. ISO 9000-2 (1993 г.) Управление качеством и гарантии качества. Часть 2. Общее руководство по применению стандартов ISO 9001, ISO 9002 и ISO 9003.
ISO 9000-3 (1991 г.) Управление качеством и гарантии качества. Часть 3. Руководство по применению стандарта ISO 9001 при разработке, установке и сопровождении ПО.
ISO 9000-4 (1993 г.) Управление качеством и гарантии качества. Часть 4. Руководство по управлению надежностью программ. ISO 9001 (1994 г.) Системная модель качества для процессов проектирования, разработки, производства, установки и обслуживания. ISO 9002 (1994 г.) Системная модель качества для процессов проверки качества проектирования, установки и обслуживания. ISO 9003 (1993 г.) Системная модель качества для процессов проверки качества при окончательном тестировании. ISO 10011-1 (1990 г.) Руководство по аудиту качества систем. Часть 1. Аудит.
ISO 10011-2 (1991 г.) Руководство по аудиту качества систем. Часть 2. Квалификационные требования, предъявляемые к аудиторам качества. ISO 10011-3 (1991 г.) Руководство по аудиту качества систем. Часть 3. Менеджмент программ аудирования. ISO 10012-1 (1992 г.) Требования по качеству, предъявляемые к измерительной аппаратуре. Часть 1. ISO 10013. Руководство по созданию качественной документации. ISO/TR 13425. Руководство по выбору статистических методов, используемых при разработке стандартов и спецификаций. ISO 8402 (1994 г.) Управление качеством и гарантии качества. Словарь терминов.
По материалам International Organization for Standardization Модель оценки зрелости технологических процессов в программных компаниях В 1982 г. Министерство обороны США образовало комиссию, основной задачей которой стало исследование проблем, возникающих при разработке программных продуктов в организациях министерства. В результате деятельности комиссии в декабре 1984 г. был создан Институт инженеров-разработчиков программного обеспечения (Software Engineering Institute, SEI) на базе Университета Карнеги - Меллона. В 1986 г. SEI и корпорация Mitre под руководством Уоттса Хамфри (Watts Humphrey) приступили к разработке критериев оценки зрелости технологических процессов - CMM (Capability Maturity Model). Далее события развивались в следующем порядке: 1987 г. SEI публикует: - краткое описание структуры CMM; - методы оценки процессов разработки ПО; - методы оценки зрелости процессов производства ПО; - анкету для выявления степени зрелости процессов. 1991 г. Выпуск версии CMM v1.0 1992 г. Выпуск версии CMM v1.1 1997 г. Намечен выпуск очередной версии CMM Стандарт Baldrige Award Объединение международных рынков, повышение требований к качеству и жесткая конкуренция привели к появлению двух параллельных стандартов качества - ISO 9000, более распространенного в Европе, и Malcolm Baldrige National Quality Award (кратко Baldrige Award), весьма популярного в США. При этом многие (ошибочно!) полагают, что оба стандарта содержат примерно одни и те же требования, затрагивают одни и те же критерии качества и, следовательно, почти эквивалентны. Короче, компании могут выбирать любой из них на свой вкус. В действительности между двумя упомянутыми концепциями существует принципиальная разница в ориентации, целях и внутреннем содержании (по мнению экспертов, ISO 9000 перекрывает менее 10% критериев, вошедших в Baldrige Award).
Главная цель Baldrige Award - научить организации создавать конкурентоспособные продукты. Основная цель ISO 9000 - заставить их жестко следовать описаниям технологических процессов, которые они сами же и составляют. Регистрация в ISO свидетельствует о том, что компания поддерживает "документированную практику". Однако качество конечного продукта, требования рынка и технологический уровень самих производственных процессов оказываются вне интересов ISO. Со своей стороны, Baldrige Award ориентирована на виды деятельности, способствующие повышению конкурентоспособности компаний и предусматривающие для достижения этого различные способы: за счет обращения лицом к рынку и клиентам, нацеленности на конечный результат, постоянного совершенствования деловых процессов, тесной привязки к общей стратегии бизнеса, интеграции процессов на основе анализа, повышения квалификации персонала, расширения информационных связей. При создании Baldrige Award преследовались три основные цели: - донести до промышленных кругов важность идеи постоянного совершенствования качества технологических процессов; - стимулировать компании к внедрению систем управления качеством; - сделать всеобщим достоянием информацию о любых новых стратегиях и методиках, способствующих повышению качества. Каждый год Baldrige Award проводит награждение компаний, добившихся выдающихся успехов в области качества. Оценка строится по 28 критериям, разбитым на семь категорий: 1. Лидерство на рынке. 2. Информация и анализ. 3. Стратегия планирования качества. 4. Управление персоналом. 5. Управление качеством. 6. Достигнутые качественные результаты. 7. Мнения клиентов.
Существующие различия между ISO 9000 и Baldrige Award не означают, что одна система исключает другую. Наоборот, многие ведущие американские компании успешно их сочетают.
Премии Baldrige Award за 1995 г. Начиная с 1988 г. в США ежегодно проводится вручение премии Baldrige Quality Award в области качества. За это время участие в конкурсе приняло около 600 претендентов, а премии получили 22 компании из самых различных областей промышленности. В 1995 г. в число участников вошло 18 крупных промышленных компаний, 10 сервисных фирм и 19 представителей малого бизнеса. Керт Рейманн (Curt Reimann), директор Baldrige National Quality Program при Национальном американском институте науки и техники (NIST), сообщил, что в текущем году в программе задействовано около 2500 экспертов (для сравнения: в 1988 г. их было 100 человек), что свидетельствует о высоком интересе к проблеме качества. В течение весны - лета независимые эксперты проведут тщательную экспертизу всех 47 работ. После изучения документальных материалов (в сентябре) эксперты разъедутся по "местам", где смогут убедиться в реальном существовании декларированных конкурсантами успехов. Ниже приводится список победителей Baldrige Award прошлых лет. 1994 - AT&T Consumer Communications Services (сервис) - GTE Directories (сервис) - Wainwright Industries (малый бизнес) 1993 - Eastman Chemical (производство) - Ames Rubber (малый бизнес) 1992 - AT&T Network Systems Group/Transmission Systems Business Unit (производство) - Texas Instruments Defense Systems & Electronics Group (производство) - AT&T Universal Card Services (сервис) - The Ritz-Carlton Hotel (сервис) - Granite Rock (малый бизнес) 1991 - Solectron (производство) - Zytec (производство) - Marlow Industries (малый бизнес) 1990 - Cadillac Motor Car Division (производство) - IBM Rochester (производство) - Federal Express (сервис) - Wallace (малый бизнес) 1989 - Milliken & Co. (производство) - Xerox Business Products and Systems (производство) 1988 - Motorola (производство) - Westinghouse Electric Commercial Nuclear Fuel Division (производство) - Globe Metallurgical (малый бизнес) ISO 9000 - стандарт качества, а гарантирует ли он качество? По данным опроса, проведенного журналом "Quality Systems Update", для 80% компаний-респондентов соответствие продукции стандартам ISO 9000 является главным критерием выбора поставщика. Причина этого, вероятно, в том, что покупателю приятно сознавать, что каждый винтик, разъем или микросхема только что купленной вещи изготовлены по одной и той же отлаженной и стабильной технологии, а правдивость слов производителя гарантируется независимой аудиторской фирмой. Сертификация - довольно дорогое удовольствие. В среднем одна процедура стоит 245,2 тыс. дол., не считая затрат на последующие перерегистрации. К примеру, фирма Hewlett-Packard, имея около 20 сертифицируемых площадок, тратит на эти цели от 1,4 до 2 млн дол. ежегодно. Возможно, для корпорации с годовым оборотом 31 млрд дол. это и не так много, но для начинающих компаний подобная сумма - непреодолимый барьер. Тем не менее сертифицированные компании нередко требуют соответствующего статуса и от своих поставщиков, число которых, например в автомобильной промышленности, может измеряться многими тысячами. Однако по иронии судьбы стандарты качества ISO 9000 имеют весьма косвенное отношение к качеству готовых изделий. Группа стандартов (ISO 9001 - 9003) охватывает все этапы процесса разработки - от проектирования изделия до конечной стадии его тестирования, но сами по себе стандарты ISO не определяют критериев качества готовых изделий, а требуют лишь, чтобы все процессы их производства были задокументированы. На практике это выглядит так. Компания, решившая поддержать стандарты ISO 9000, документально описывает каждый технологический процесс, а некая аудиторская фирма проверяет, насколько реальные процессы соответствуют составленным описаниям. Для поддержания статуса "сертифицированности" компании должны регулярно проходить аудиторскую проверку. Поскольку стандарты ISO - не самое эффективное средство в борьбе за качество, компании редко проходят сертификацию ISO ради этой цели. Основная причина их заинтересованности в тесных контактах с ISO заключается в том, что этого требуют пользователи. Да, пользователи очень хотят, чтобы их поставщик прошел сертификацию на соответствие стандартам ISO!
И все-таки при всех недостатках стандартов ISO 9000, их популярность растет. В США число сертифицированных компаний только за один 1994 г. почти удвоилось (с 2709 до 5108). В Европе количество таких фирм превышает 40 тыс.
2. КОНСТИТУЦИОННОЕ ПРАВО
3. Маленькая ночная серенада
4. Ukraine Geographical Position
5. Буржуазная социология на исходе XX века Критика новейших тенденций
6. Введение 3 Отчетность субъектов предпринимательства 5.html
7. Гражданское право1
8. рефератІ Характеристика джерела Приклад оформлення
9. Виникнення і розвиток феодалізму виявляються перш за все у формуванні та зростанні феодального землевол
10. Правила проведения десмургии.html
11. реферату- Етапи розвитку українознавстваРозділ- Українознавство Етапи розвитку українознавства План
12. тематика Программное содержание- узнавание и называние цифр до 5 отсчитывание предметов знание геометриче
13. КОНТРОЛЬНАЯ ПО КРИМИНОЛОГИИ Содержание Введение
14. Тема- Технология создания Webстраниц в Microsoft Front Pge
15. МОРДОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ им1
16. Латинский язык 1 семестр bsente egr~to consilium.
17. III тыс до н э Она вызывает особый интерес благодаря возникновению своеобразных и знаменитых памяток культ
18. Экономическая оценка ущерба из-за производственного травматизма и профессиональной заболеваемости
19. Контрольная работа- Построение базы данных боксерской организации
20. RELIGION RULE религия по умолчанию The Englishmen is probbly the lest religious people on Erth