19.08.2016, 15:37:31
Войти Зарегистрироваться
Авторизация на сайте

Ваш логин:

Ваш пароль:

Забыли пароль?

Навигация
Новости
Архив новостей
Реклама
Календарь событий
Right Left

Главная Новости

Электронная шкала качества

Опубликовано: 24.08.2018

видео Электронная шкала качества

Механические и электронные штангенциркули, какой лучше, обзор

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


Настройка выходной громкости трека под современные стандарты RMS

Директору каждого предприятия рано или поздно приходится сталкиваться с вопросами автоматизации бизнес-процессов. В какую из информационно-технологических компаний обратиться? Среди предлагаемых проектов автоматизации сориентироваться непросто. Есть проверенные западные решения, надежность которых подтверждается инвестированными в них средствами. Но и стоят такие "игрушки" недешево. Есть и отечественные, на базе российских программных продуктов. И тут нелишне было бы знать: а какими, собственно, критериями качества, руководствуются разработчики программного обеспечения (ПО) в своем весьма специфическом и далеко непрозрачном для заказчика производстве?


Обзор тестера воды Xiaomi Mi TDS Pen (определение качества, жесткости воды)

Оборонная инициатива. По легенде, собралась как-то NASA оснастить военный спутник новым компьютером. Да и задумалась: кому заказать разработку уникальной операционной системы? Вопрос оказался непростым. Ведь даже лидера софтверной индустрии - компанию Microsoft пришлось сразу отвергнуть. На миллион знаков исходного кода его систем, которые в той или иной степени удовлетворяют гражданских пользователей, обязательно приходилась хотя бы - одна ошибка. Какие могли быть гарантии, что и заказное программное обеспечение для космоса не забарахлит? Итак, гарантии... Обратились к международным стандартам качества. Но и те софтверные компании (разработчики ПО),- где все, казалось, было схвачено с ISO 9000, не могли убедительно доказать, что смогут создать эксклюзивный продукт. Так каким же должен быть стандарт на штучную высокотехнологичную качественную работу? И, говорят, пришел тут на помощь NASA и американскому министерству обороны американский же Институт программной инженерии (SEI), предложив "модель зрелости технологических процессов" - СММ (Capability Maturity Model). Следуя этой модели, предприятие должно доказать, что его продукция не просто будет удовлетворять требованиям абстрактного заказчика, она будет еще и идеально подходить конкретной группе клиентов. Так, если заказчик сам находится, скажем, на четвертом уровне СММ, то и поставщика ему следует искать на той же ступеньке, в редком случае - на одну ниже.В конечном счете, именно модель СММ, еще даже не будучи признана как международная система стандартов качества, помогла оснастить американскую космическую отрасль только ей необходимым ПО. С этого в начале 90-х и началось глобальное распространение СММ. Но легенда легендой, а реально проблема состояла в сложности управления большими проектами. Во многих компаниях американской софтверной индустрии они выполнялись со значительным опозданием, с превышением запланированного бюджета. В сентябре 1987 года SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также вопросник для компаний, цель которого была выявить те подразделения и процессы, в которых необходимо произвести улучшения. Однако, большинство компаний отнеслось к вопроснику как к готовой модели, в следствие чего через четыре года он и на самом деле был преобразован в модель Capability Maturity Model for Software (CMM). В результате в 1992 году увидел свет стандарт CMM Version 1.1, который и по сей день активно используется.

Лестница зрелости. Российских специалистов в области СММ единицы. Найти их непросто. И тут обязательно надо выразить благодарность неформальному сайту по вопросам менеджмента качества http://www.iso9000.ok.ru/ , благодаря которому удалось-таки разыскать излишне скромных московских специалистов, сертифицированных самим SEI. Таковыми оказались Алексей Григорьев, Наталья Сапрыкина и Андрей Абарыков из московской компании Adjast Media QM Consulting . Алексею Григорьеву причины интереса отечественных программистов к СММ понятны: прежде всего, это производство ПО по зарубежным заказам, требования к продукту, выдвигаемые западными потребителями. Если же брать софтверную индустрию в целом, не только отечественную, то и сами разработчики ПО, и их руководство зачастую очень хорошо знают свои постоянные проблемы, но не могут прийти к единому мнению о том, какие изменения необходимы компании в первую очередь. Без выработки единой стратегии проведения улучшений руководство не может найти взаимопонимания со своими сотрудниками относительно наиболее приоритетных задач по улучшению. Для достижения максимального результата от усилий, потраченных на улучшение процессов, необходимо иметь поэтапную стратегию развития, которая позволит улучшать зрелость процессов разработки постепенно, эволюционным путем. Такое, постоянное улучшение процессов базируется на постепенном взращивании культуры компании, а не на проведении революционных инноваций. В СММ представлена схема такого постепенного улучшения, разделенная по 5 уровням зрелости процессов. Эти 5 уровней представляют собой шкалу для оценки уровня зрелости процессов разработки ПО в компании и для измерения их параметров.Вот основные характеристики каждого уровня (Данные компании Adjast Media QM Consulting):

Initial - Процесс разработки носит хаотический характер. Определены лишь немногие из процессов и успех проектов зависит от конкретных исполнителей. Repeatable - Установлены основные процессы управления проектами: отслеживание затрат, графика работ и функциональности. Упорядочены некоторые процессы, необходимые для того, чтобы повторить предыдущие достижения на аналогичных проектах либо проектах с аналогичными приложениями. Defined - Процессы разработки ПО и управления проектами описаны и внедрены в единую систему процессов компании. Во всех проектах используется стандартный для организации процесс разработки и поддержки ПО, адаптированный под конкретный проект. Managed - Собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных. Optimizing - Постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий.

Требования СММ, по сравнению с ISO, весьма жесткие. Если в Европе в среднем 2-3 аудитора работают на предприятии неделю, чтобы определить его соответствие стандартам ISO, то в Штатах проверку на соответствие нормам СММ проводит, как правило, бригада аудиторов от 10 до 50 человек, которые в течение нескольких месяцев, по свидетельствам очевидцев, ставят предприятие на уши. В силу столь жестких требований лишь единицы ведущих hi-tech-компаний достигли к настоящему времени высшего уровня по градации СММ. Впрочем, сложность борьбы за восхождение по новой лестнице качества ничуть не убавила интереса к американской модели со стороны европейских высокотехнологичных предприятий, что, в свою очередь, заставило всерьез присмотреться к модели СММ и Международную организацию по стандартизации ISO.

Грядет ли "война" стандартов? Стандартов качества - море. И до сих пор никто не думал всерьез, что они могут мешать друг другу, не уживаться. Но вот в ISO на базе концепции СММ был разработан новый стандарт ISO/IEC TR 15504-СММ, в простонародье SPICE (SPICE - "Software Process Improvement and Capability determination"). Это даже и не стандарт в полном смысле слова, а так называемый technical report, пробный шар. Обычная практика ISO в деле распространения своих новых продуктов. Теоретически самые придирчивые заказчики вполне могут потребовать от подрядчика сертификат на соответствие стандартам ISO 15504, то есть получить избыточную оценку системы менеджмента качества, независимо от того, к какой отрасли относится предприятие. Самой же ISO стандарты серии 15504, основанные на требованиях СММ, пока трактуются как стандарты для создания софтвера. Тем не менее, в Госстандарте небезучастны к СПАЙСу и уже подымают вопрос обязательного ранжирования предприятий ВПК по уровням, очень похожим на уровни СММ, а уж по европейской или американской модели,- посмотрим. Заметьте, речь идет уже о применении стандарта не только для информационно-технологических компаний, а для высокотехнологичных вообще. Это серьезно. Не ровен час, нормой для выхода на международный рынок для предприятий "оборонки" станет уже не ISO 9000, а новый стандарт ISO/IEC TR 15504-СММ. Специалисты из Adjast Media QM Consulting уверяют, что СММ не конкурент стандартам ISO. Они по определению не могут быть конкурентами.

- Более того, продвигаться к СММ лучше всего через ISO,- советует Наталья Сапрыкина .- Об этом мы пишем в статье "Через ISO - к зрелости по СММ". Ее можно прочитать на нашем сайте.

- Между ISO 9000 и СММ нет конкуренции,- поддерживает коллегу Алексей Григорьев .- Это как бег на 100 и на 1000 метров. Научился бежать короткую дистанцию - легче будет на длинной. А СММ на самом деле очень непростая дистанция. Например, вопреки расхожему мнению, что де индийские офшорные софтверные компании (разработчики ПО, выполняющие западные заказы) сплошь сертифицируются по СММ, Индийская ассоциация офшорного программирования приводит следующие данные: 74 процента индийских софтверных компаний сертифицированы по стандартам ISO 9000, и только 24 процента - по СММ. Более того, все эти компании, соответствующие той или иной ступени СММ, обладают сертификатом ISO. И только три компании в Индии, которые достигли пятого уровня СММ, не нуждаются в сертификате на соответствие ISO серии 9000. Иными словами, неважно есть у тебя СММ или нет,- ISO, в любом случае, необходимо для захвата большего количества контрактных ситуаций. Интересно, а как смотрят на взаимоотношения ISO 9000 и СММ в других информационно-технологических компаниях?

Директор по качеству компании LUXOFT Семен Мильман :

- Все зависит от того, какие цели и задачи ставит перед собой компания, в каком направлении и с кем она работает. Каждая из этих моделей имеет право на существование. Основное различие состоит в том, что стандарт ISO является международным и универсальным по своему характеру. Что касается CMM - это модель качества, не имеющая как такового статуса стандарта. К тому же CMM носит более локальный и узкоспециальный характер. Это локальная, американская модель качества процессов разработки программных продуктов. Сложно сказать, является ли это преимуществом или недостатком. В любом случае, каждая компания решает сама, какому стандарту или модели следовать, в зависимости от целей. С нашей точки зрения, каждая из систем хороша по-своему, и мы стараемся взять лучшее от каждой из них. Сертификация системы качества - это внутренняя потребность, а не обязательная процедура. Поэтому и выбор модели качества определяется потребностями компании. Не секрет, что требования CMM более жесткие, чем требования, предъявляемые стандартом ISO. Поэтому, на наш взгляд при промышленном производстве ПО под заказ построение производственных процессов в соответствии с моделью CMM, возможно, более эффективно. А еще лучше, когда обе системы дополняют друг друга. Если компания работает с американскими заказчиками, то, возможно, ей следует получить сертификат CMM, если на европейском рынке - она может ограничиться ISO. В нашем случае, построение системы качества по модели CMM вызвано стремлением к совершенствованию производственных процессов.

Директор центра разработки программного обеспечения компании "Оптима" Александр Антонов :

- Кто в России проявляет интерес к СММ? Компании, поизводящие ПО. И, как правило, производящие ПО на экспорт. Стандарту СММ западные потребители ПО больше доверяют, чем стандартам ISO. При получении сертификата по СММ проверяется больше специфических факторов. Поэтому, на мой взгляд, ISO - стандарт общий. СММ - прикладной. Кроме того, СММ реально помогает изменить процесс разработки софта (ПО). Мы это по себе знаем. Но ведь мы начинали с ISO 9000. А теперь я вижу, что проще развиваться в соответствии с требованиями СММ, когда у тебя уже есть ISO 9000. Какие-то процедуры уже описаны, персонал адекватно воспринимает требования СММ. Есть негласное правило: если у тебя сертифицирована система менеджмента качества на соответствие ISO 9001, ты уже можешь претендовать на второй уровень по СММ. Правда, никаких взаимозачетов. Что ж, будем считать ISO 9000 точкой отсчета, дополнительной, но в большинстве случаев необходимой ступенькой перед лестницей СММ. Но вот между новой американской и новой европейской системой "измерения качества", между собственно СММ и его производной ISO/IEC TR 15504-CMM тут, на мой взгляд, конкуренция вполне обозначилась. По некоторым данным, Великобритания и Австралия уже поспешили объявить ISO/IEC TR 15504-CMM национальным стандартом. Российские приверженцы СПАЙСа считают, что будь он и у нас утвержден в качестве национального стандарта, предприятиям было бы легче продвигаться к сертификации по СММ. "Да, пусть он не будет котироваться в США, но утвердив такой национальный стандарт,- считают они,- мы создадим прецедент, и возможно, подтолкнем международную организацию ISO к утверждению стандартов серии 15504, причем с учетом наших разработок в этом направлении". Почему бы и нет, в самом деле? Почему мы всегда вынуждены пользоваться уже готовыми решениями ISO когда и у нас есть свой взгляд на принципы менеджмента качества? А он точно есть, и это знают за рубежом, но не всегда считаются, когда заказывают разработку ПО. Ведь так дешевле. Не берусь предсказать, как именно, но есть предчувствие, что в зависимости от того, какой стандарт победит: СПАЙС или основной СММ; в каких масштабах: российских или европейских,- будет складываться в целом и судьба офшорного программирования. И уж что совершенно точно: в зависимости от этого будет поделен рынок консалтинговых услуг в области менеджмента качества. Рынок, который уже десять лет существует в России, но в силу не очевидной осязаемости производящихся на нем интеллектуальных продуктов (методик, курсов, лекций, семинаров) до сих пор остается неизмеренным.

Также на сайте:

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

Принятие решений, основанных на фактах

Подготовлено при поддержке:
rss