О сертификации российской компании, производящей программное обеспечение

Введение

Ядро компании "ЛАНИТ-ТЕРКОМ" формировалось с 1971 года, когда в лабораторию системного программирования НИИ математики и механики Ленинградского университета были распределены выпускники математико-механического факультета ЛГУ. В течение двадцати лет сложился успешно работающий коллектив. В начале 1980-х годов коллектив лаборатории начал заниматься не только исследовательскими, но и производственными задачами - совместно с ЛНПО "Красная Заря" было выполнено несколько проектов по разработке специализированного программного обеспечения для телефонных станций. Однако в 1991 году стало ясно, что необходимы новые организационные и производственные формы, чтобы успеть за реалиями наступающей постсоветской эпохи - в результате было создано малое государственное предприятие "ТЕРКОМ". В 1998 году образована компания "ЛАНИТ-ТЕРКОМ", являющаяся в настоящее время частью московского холдинга "ЛАНИТ". Обе компании работают в одной области производства сложного программного обеспечения широкого профиля и управляются одними теми же менеджерами, поэтому в дальнейшем будем считать их одной компанией.

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

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

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

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

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

Любая развивающаяся компания рано или поздно поднимается до такого уровня, когда она осознаёт необходимость сертификации - добровольной, если она занимает на рынке программного продукта неплохие позиции и желает ещё более укрепить их, или "добровольно-принудительной", если у неё есть перспективы получить хороший госзаказ. В предлагаемой статье обсуждаются возможные пути подготовки программистской компании к сертификации и к совершенствованию жизненно важных процессов деятельности компании. Статья организована следующим образом: в 1-ом разделе обсуждаются различия между процессом производства ПО и другими производственными процессами, во 2-ом формулируются наши требования к "идеальному процессу", в 3-ем приводится сравнение нескольких широко применяемых международных стандартов и наше понимание сути улучшения процесса разработки ПО, 4-й раздел описывает проблемы, с которыми мы при этом вплотную столкнулись. В заключении суммируется наш опыт и приводятся некоторые рекомендации.

1. Разработка программного обеспечения: искусство или производство?

Первая проблема, с которой приходится сталкиваться при попытке стандартизировать процесс разработки ПО, это интеллектуальная природа процесса. Несмотря на то, что программирование более или менее формализуется применением стандартных языков программирования и структурированием данных, сам процесс до сих пор является более искусством, чем ремеслом [McConnell, 2001]. Одну и ту же программу разные разработчики напишут по-разному, но очень немногие из полученных вариантов будут совершенными. Недаром капитальный труд в этой области назван "Искусство программирования" [Knuth, 1998]. Компьютерная программа является материальным объектом, но она строится на абстрактных идеях и состоит из сложнейших виртуальных конструкций. Это в корне отличает ее от физических объектов, с которыми имеет дело обычное производство, и поэтому невозможно создать качественное ПО, не решив ряд типичных проблем:

• команда разработчиков, как правило, состоит из творческих личностей и часто бывает очень трудно привести их к "общему знаменателю";
• каждый программный продукт неизбежно содержит ошибки, отражающие квалификацию и индивидуальный стиль разработчика; разнообразие и нестандартность ошибок сильно усложняет процесс достижения стандартных целей в области качества;
• каждый успешный проект по-своему уникален и индивидуален, он подобен мозаике со сложным рисунком, и поэтому очень трудно выделить из него некий базовый процесс-клише, который можно было применить в дальнейших разработках;
• по сходной причине трудно поставить производство сложного и уникального ПО на поток, так как часто для его разработки требуется создание сопутствующего специфического программного "инструментария" [Оносовский, Терехов, 2000];
• одна из специфических проблем программирования состоит в том, что его продуктивность растет очень медленно, если растет вообще - по некоторым оценкам средний программист способен создать 10-50 строк операторов в день. Кроме того, эти оценки должны быть уменьшены для больших систем, так как увеличенная нагрузка требует увеличения затрат (в относительных единицах) [Jones, 1986]. Это обстоятельство резко отделяет программирование от другого вида деятельности, где поточное производство радикально уменьшает цену единицы продукта. По существу, вся экономика строится на этом далеко не новом принципе - но только не производство программного обеспечения!

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

2. Поиск идеального процесса

Для начала мы попытались понять и сформулировать наши требования к "идеальному процессу" разработки ПО, который послужил бы моделью для нашей компании. Существующие международные стандарты (ISO 12207 и СММ) представляют такие модели, одна из них показана на рис.1 [Paulk et al., 1995].

Это не более чем общее представление процессов и требований заказчика для некоторой условной компании. В любой компании, которая успешно производит продукт и продает его на рынке, можно выделить набор процессов, в наибольшей степени соответствующий выбранной стандартной модели. Мы выделили такую композицию в деятельности департамента нашей компании, несколько лет работающего по заказам американской фирмы, и взяли её за основу. Базовые процессы в департаменте уже установились, были выделены, идентифицированы и в большой степени документированы [Оносовский, Терехов, 2000].

Рис.1. Модель идеального процесса в соответствии со стандартом СММ

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

Компьютерная программа

Программный продукт

Концептуальное проектирование

Спецификация системных требований

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

Архитектурное (логическое) проектирование

Построение базовых алгоритмов

Разработка стандартов на программирование

Кодирование программ

Тестирование кодов

Поблочное и функциональное тестирование

Системная интеграция программного обеспечения

Интеграционные и эксплуатационные тесты

Документирование программного продукта

Сопровождение программного продукта

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

3. Выбор "собственного" стандарта

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

• ISO 9000 (2000);
• MSF (Microsoft Solutions Framework);
• SLCP (ISO/IEC 12207: Software Life Cycle Processes);
• CMM (Capability Maturity Model);
• SPICE (ISO/IEC TR 15504-CMM: Software Process Improvement Capabilities and dEter-mination).

Для начала мы исследовали возможность формализации процессов, используя модель ISO 9001 [ISO 9000-1-94, 1996]. Стандарт хорошо известен и широко применяется в европейских странах в самых разнообразных сферах деятельности, наличие у компании сертификата ISO является хорошей рекомендацией. Принципы соответствия деятельности предприятия моделям этого стандарта и правила сертификации неоднократно излагались в информационных документах International Organization for Standardization (ISO). С другой стороны, применение семейства стандартов ISO 9000 для построения системы качества компании, производящей ПО, редко приводит к желаемым результатам. Причин тому несколько. Стандарт излишне формализован, жестко структурирован и требует скрупулезного создания документационного потока, оставляя в стороне процессную суть деятельности предприятия. Он чаще всего делает временнoй "срез" процессов, фиксирует "status quo" ситуации, существующей на момент аудита, и с некоторого момента наработанная громоздкая документированная система может стать тормозом для дальнейшего совершенствования процессов. Кроме того, ISO 9001 не содержит специализированных требований для процессов разработки программного обеспечения, так как этот стандарт с самого начала предназначался для широкого спектра производства продуктов, услуг, систем. Такая "гибкость" делает ISO 9001 мало пригодным для построения систем качества при разработке ПО (см. п. 1).

В этом смысле гораздо более подходящим является стандарт ISO12207 в, котором описается модель жизненного цикла программного продукта [ISO/IEC 12207,1995], однако и ему присущи общие недостатки ISO 9001: он слишком формален и скуден и не охватывает того богатства разнообразных процессов, которое характерно для производства современного ПО. В сущности, не совсем понятно, как применять этот стандарт, если компания производит программные продукты широкого профиля - от ПО для цифровых АТС до систем реального времени, от трансляторов до реинжиниринга устаревших программ.

Следующим на очереди был MSF, который не раз позитивно применялся в нашей компании при выполнении краткосрочных аутсорсинговых проектов. Оказалось, что он методически очень удобен для организации процесса в небольших, раздельно работающих группах, так как в нём есть эффективные процедуры для организации планирования, разработки, тестирования и внедрения программного продукта [Wilson et al., 1999]. Мы не применяли MSF в полном объеме, но в этом и не было необходимости - дело в том, что MSF не является стандартом в полном смысле слова; скорее это набор "наилучших практик", рекомендуемых для использования. Это и недостаток, так как не позволяет судить о безупречности MSF, как модели стандарта. К тому же практически невозможно описать все процессы, охватывающие сферу деятельности компании, только средствами MSF, так как в нем совершенно нет инструментов для координации деятельности между независимыми департаментами в крупной компании. Таким образом, опыт работы с MSF показал, что его лучше всего использовать как промежуточную ступень на пути к применению более полного и адекватного стандарта. Использование MSF для совершенствования процессов в небольшой компании или в отдельных департаментах крупной является здравой идеей, однако на стадии распространения знаний и интеграции процессов волей неволей придется переходить к более общим стандартам, обеспечивающим качество работы всей компании в целом.

Наиболее полно указанные выше недостатки учтены в международных стандартах СММ и родственных с ним CMMI и SPICE [Paulk et al., 1995; ISO/IEC TR 15504-CMM, 1998]. Они созданы специально для индустрии программного обеспечения и содержат различные методики для описания процессов как разработки ПО, так и вспомогательных и организационных процессов. Отметим, что СММ все-таки требует соответствия некоторому фиксированному набору процессов, однако CMMI и SPICE предоставляют самые общие шаблоны и методики, которые могут быть использованы для программных процессов любого типа. Эти стандарты хороши не только для идентификации, описания и сопровождения текущих процессов - они отлично подходят для постоянного их улучшения. Кроме этого, основное назначение стандарта СММ состоит не столько в задании модели соответствия, сколько в оценке зрелости компании в целом, т.е. оценки способности компании на определенном уровне выполнять требования заказчика. В стандартах CMMI и SPICE введена уже двухкоординатная размерность: оценивается не только зрелость компании, но и зрелость отдельных процессов. Таким образом, по этим стандартам можно сертифицировать наиболее "продвинутые" процессы. Так, например, компания в целом может быть сертифицирована по 2-ому уровню, а некоторые процессы в ней - по 3-ему или даже 4-ому.

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

1. Первично выявлять, организовывать, идентифицировать, сопровождать процессы, т.е. создавать "процессный костяк", и на их основе разрабатывать устойчивые процедуры лучше всего в отделах и департаментах компании, выполняющих самостоятельные проекты, на основе требований MSF.
2. Документировать идентифицированные процессы и строить первоначальную структуру системы качества предприятия следует в соответствии с ISO 9001 (2000). Это позволит заложить хорошую основу для совершенствования процессов, развития системы качества и сертификации по ISO 9001. Реальный срок подготовки сертификации составляет 1.5 - 2 года при относительно невысоких затратах.
3. Дальнейшее улучшение и сопровождение процессов на следующем этапе логично производить на базе CMM и SPICE, специально предназначенных для программной индустрии. Отметим, однако, что на предыдущем шаге следует заранее определить принципы документирования процессов и сразу привести их в соответствие с требованиями CMM и SPICE, чтобы впоследствии не переписывать документацию ещё раз. К счастью, в большинстве случаев это возможно, так как ключевые области одних стандартов более или менее соответствуют друг другу [Paulk, 1995a]. При подготовке к сертификации по этим стандартам необходимо учитывать, что затраты на этой стадии будут в несколько раз выше, чем на предыдущей. Это объясняется недостаточной распространенностью CMM и высокой стоимостью независимого международного аудита.

Идея использовать несколько базовых стандартов для улучшения программных процессов не нова. Например, похожий, но несколько более простой путь рассматривался в работе Андреса и др. [Andres et al., 1997]. Мы уверены, что предложенный нами путь является вполне осуществимым, минимизирует риски и затраты на сертификацию процессов и компании в целом и, что самое главное, позволяет достичь реальных целей в сфере качества и обеспечить долгосрочные выгоды компании.

4. Проблемы внедрения и реализации

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

Когда мы анализировали деятельность департаментов компании с целью выбрать наиболее совершенный процесс, оказалось, что и "самый лучший процесс" был в достаточной степени неадекватен модели, задаваемой стандартами. Например, наш процесс обеспечения качества (Quality Assurance) разработки программ первоначально сводился к простому функциональному тестированию. Тестирование проводилось в несколько этапов, процесс был тщательно разработан, выявленные ошибки анализировали, классифицировали, включали в базы данных, наиболее типичные случаи документировали. Позже процесс был дополнен некоторыми другими идеями, такими как ежедневная сборка программы и регрессионные тесты [Оносовский, Терехов, 2000]. Однако такое чисто техническое тестирование, естественно, не решает всех проблем качества программного продукта. Часть "хороших практик", типичных для более зрелых компаний [Paulk et al., 1995] -architectural reviews, peer reviews, code inspections или prototyping - всё ещё находятся вне структуры наших текущих процессов, хотя мы, конечно, знаем, что существуют различные этапы тестирования, которые должны дополнять друг друга. Это видно, например, из данных таблицы 1, взятой из работы Джонса [Jones, 1986], где приводится процентное соотношение количества ошибок, которые можно выявить и удалить (исправить) на различных этапах разработки и тестирования ПО.

Этап разработки и тестирования ПО	Нижняя граница	Вероятная граница	Верхняя граница
Формализованное (процедурное) обследование проекта	35%	55%	75%
Неформальное обсуждение проекта в группах разработчиков	30%	40%	60%
Персональная проверка проектной документации	15%	35%	70%
Формализованные инспекции кода	30%	60%	70%
Моделирование и прототипирование	35%	65%	80%
Тестирование кода разработчиком	20%	40%	60%
Поблочное тестирование программ	10%	25%	50%
Функциональное тестирование	20%	35%	55%
Интеграционное тестирование системы	25%	45%	60%
Эксплуатационное тестирование с использованием реальных данных	35%	50%	65%
Совокупный эффект полного тестирования	93%	99%	99%

Из приведенных данных видно, что хорошего результата можно достичь простым внедрением необходимых, но не использованных до сих пор методик и процессов - это часто приводится как иллюстрация реального пути улучшения качества [Boehm et al., 2001]. Но оказалось, что выявить и идентифицировать проблему, наметить пути её решения - не самое трудное. Куда труднее реализовать найденный и потенциально полезный путь. Не только команды разработчиков, но часто, к нашему удивлению, и заказчики активно сопротивляются большинству изменений в существующих и обкатанных процессах ("от добра добра не ищут!"). В нашем случае - до того, как заработала программа совершенствования качества, - в повседневную практику вошли только те изменения, которые были жестко сформулированы самим заказчиком в виде пунктов технического задания, обязательных для выполнения.

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

Этот тезис можно продемонстрировать на примере нашей компании. В 1993 году ТЕРКОМ начал работать по контрактам с двумя большими зарубежными компаниями - SEER Technologies (США) and Italtel (Италия). Заказчики хотели решить некоторые сложные задачи, с которые они не могли справиться сами из-за отсутствия требуемых знаний или вследствие желания уменьшить финансовые затраты. ТЕРКОМ благополучно справился с начальными этапами работ, получил долгосрочные контракты и возможность совершенствовать свою систему качества в сотрудничестве с указанными компаниями.

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

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

Одной из важнейших составляющих процесса постоянного улучшения качества является накопление и использование данных по успешным проектам и разработка собственных метрик [ISO/IEC TR 15504-CMM. М., 2001]. Реально управлять можно лишь тем, что можно измерить, проанализировать и изменить. Разработка понятных и объективных метрик является ключевым моментом формирования инструментов управления процессом. До введения программы улучшения качества мы вынуждены были полагаться на мнения и опыт разработчиков. Но часто бывает так, что желания исполнителей противоречат деловым интересам компании. Трудно было ввести в нашу практику ежедневную сборку и тестирование готовых блоков, еженедельные отчеты, стандартизацию отдельных процедур, выработку метрик, использование статистики и пр. Люди активно сопротивлялись даже в тех случаях, когда это реально и наглядно улучшало процесс. Тем не менее, мы начали работу с одного, наиболее "продвинутого" процесса и методично продолжаем в настоящее время, разрабатывая оптимальные метрики и статистические критерии оценки надежности процессов.

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

Такое коллективное "отрицание" есть явный признак низкой корпоративной культуры многих российских компаний, всё ещё не готовой к дружескому восприятию основных целей и путей в области качества. Частично это можно списать, как в нашем случае, на патриархальный академический дух, который ещё не выветрился из университетских выпускников, или на недостаток специального образования, но общая причина, видимо, в наших российских корнях. Здесь уместно привести слова русского философа А.И.Ильина: "Русская душа до сих пор не поняла и не осмыслила, какой соблазн и какую отраву она впитала в себя вместе с идеей бескачественного обилия и объёма… В глубине души русского человека живёт смутная, но твёрдая уверенность, что качество ему не нужно, что это - "заморская выдумка"; что при нашем обилии и при нашей даровитости мы без учения и без старания, без умения и без навыка "по-своему справимся" и даже ещё лучше выйдет"…[Ильин, 1928].

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

5. Заключение

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

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

Литература

1. [McConnell, 2001]. S. McConnell "Art, Science and Engineering"// IEEE Software, Vol. 17, No. 2, March 2000, р. 9-11.
2. [Knuth, 1998]. D. Knuth "The Art of Computer Programming", Volumes 1-3, Addison-Wesley, 1998.
3. [Оносовский, Терехов, 2000]. В.В.Оносовский, A.Н.Терехов "Организация работ в проекте Rescue Ware"// В сб. "Автоматизированный реинжиниринг программ", СПб, 2000. Изд-во С-Петерб. ун-та, с. 43-63.
4. [Jones, 1986]. C. Jones "Programming Productivity", New York, McGraw-Hill, 1986.
5. [Paulk et al., 1995]. M. C. Paulk, C. V. Weber, B. Curtis, M. B. Chrissis et al. "The Capability Maturity Model: Guidelines for Improving the Software Process", Addison-Wesley, 1995.
6. [ISO 9000-1-94, 1996]. Международный стандарт ISO 9000-1-94. Часть 3: Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения. М., 1996, ИПК изд-во стандартов.
7. [ISO/IEC 12207,1995]. Information Technology. Software Life Cycle Processes. ISO/IEC 12207,1995.
8. [Wilson et al., 1999]. Scott F. Wilson, Bruce Maples, Tim Landgrave. Analyzing Requirements and Defining Solution Architectures// Microsoft Press, 1999.
9. [ISO/IEC TR 15504-CMM, 1998]. Software Process Improvement Capabilities and dEtermination (SPICE). ISO/IEC TR 15504-CMM, 1998.
10. [Paulk, 1995a]. M. C. Paulk "How ISO 9001 Compares with the CMM"// IEEE Software, January 1995. P. 74-83.
11. [Andres et al., 1997]. A. Andres, P. Ferrer, P. A. Gutierrez, G. Satriani "ISO 9000 Certification as a Business Driver: the SPICE Road", 2nd International Conference on ISO 9000 and TQM, April 1997
12. [Boehm et al., 2001]. B. Boehm, V. R. Basili "Software Defect Reduction Top 10 List"// Computer, January 2001. P. 135-137
13. [ISO/IEC TR 15504-CMM. М., 2001]. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем. ISO/IEC TR 15504-CMM. М., "Книга и бизнес", 2001.
14. [Ильин, 1928]. А.И.Ильин. Спасение в качестве// Русский колокол. 1928, № 4, с.3-7.

Аннотация

Abstract

Данные об авторах

Рекомендовать страницу	Обсудить материал	Написать редактору
Распечатать страницу		Дата публикации: 28.01.2002