ЭТО СЛАДКОЕ СЛОВО "КАЧЕСТВО"

2000 г

ЭТО СЛАДКОЕ СЛОВО "КАЧЕСТВО"

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

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

Разработчики программного обеспечения также охвачены лихорадкой качества. Хотя абсолютно все авторы и начинают свои публикации со слов: "Всем известно, что качество программного обеспечения не поддается точному определению и измерению"¹, тем не менее, задача поставлена и требует решения. Что удается с трудом.

В этой связи любопытна публикация [1] английских исследователей М. Тэйлор и Дж. ДаКоста. Они провели анализ проблемы качества КИС (Корпоративной Информационной Системы) на одном конкретном примере. Внедрили на небольшую фирму своего человека в качестве консультанта, который наблюдал за ходом создания информационной системы. Главный вывод статьи: "на средних и малых предприятиях при разработке и внедрении КИС возникают те же проблемы с качеством, что и на больших, поэтому требуется применение методологии "Гибких Систем". Это не очень интересно. Интереснее перечень проблем, с которыми столкнулись английские товарищи:

Программисты и коммерсанты говорят и мыслят разными категориями, поэтому им трудно найти общий язык.
Имея опыт работы на старой программе, сотрудники фирмы-заказчика "напридумывали" такое количество новых идей, что система под их тяжестью едва могла шевелиться, при этом многие из этих идей остались невостребованными.
Заказы принимались "на слух", многие из них так никогда и не были записаны.
Техническое задание не было подготовлено в полном объеме.
"Вечные" проблемы с внедрением (даже не будем цитировать, так это все банально - ошибки, разногласия по поводу ТЗ, нежелание операторов учиться…).
Как результат: "снижение доверия к разработчику, которое усугубилось неприятным фактом, когда вместо того, чтобы изменить настройки принтера, разработчик выставил счет за ремонт материнской платы принтера на 250 фунтов стерлингов".
Чаша терпения была переполнена, когда заказчик придумал будто "оператор на складе должен иметь возможность работать на нескольких экранах одновременно". Программисты сказали "нет проблем", а система стала перегружаться, так что начала "подвисать иногда", не мало не много - несколько раз в день.

На этом примере видны все основные места "некачественности":

Низкое качество конструирования.
Отсутствие системного подхода при планировании КИС (П1)
Плохое обслуживание при внедрении и сопровождении.
Низкое качество программного обеспечения.

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

На схеме рис.1 обозначены современные тенденции Систем Качества в области КИС и ПО.

Рис 1. Современная модель качества КИС и ПО.

1. Анализ качества ИС и качества ПО порознь

Как справедливо отметил Л. Хелленс в [4], фирмы, разрабатывающие и внедряющие КИС, должны отдавать себе отчет в том, что они предоставляют услуги, а не производят товар. Разработка программ - это, конечно, производство, но это лишь малая часть работы по созданию КИС. Если мы посмотрим список проблем "английских товарищей" (П1), то увидим, что лишь одна из четырех проблем относится к производству программного обеспечения.

То же самое мы видим и при анализе качества ИС при присуждении премий фирмам за хорошее качество изделий.

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

Dening Prize - Япония (Ассоциация Японских Ученых и Инженеров), 1981;
Malcolm Bridge National Quality Award - Северная Америка, 1987;
European Quality Award - 1988, Европа (учредители - 14 ведущих Европейских фирм).
Российская премия за качество - 1996 год.

Например, при анализе изделий, выдвинутых на премию Malcolm Bridge, учитываются 20 критериев с общей суммой баллов 1000, из них лишь 250 баллов приходятся на технические аспекты качества.

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

2. Кому все это нужно?

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

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

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

3. Разное качество с разных точек зрения

Китченхам и Пфлегер справедливо замечают в [2], что фирмы, предоставляющие услуги по созданию КИС "увеличивают стоимость фирм-заказчиков" и именно на это увеличение стоимости должны быть направлены их усилия.

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

Поэтому главный критерий качества КИС - ее способность повысить коммерческую эффективность всей фирмы. Это - критерий качества с точки зрения руководителя фирмы.

"Повысить общую эффективность фирмы" - это высказывание для ученого в тиши кабинета, не ведающего, что он говорит. "Общая эффективность фирмы" для самой фирмы - это все, это жизнь, конкуренция, надежды, мечты, идеи, кризисы, удачи, провалы.… Сама фирма это ведь не здание, не конкретные люди, не станки и товары… Фирма это и есть сгусток информации: знания в инструкциях, знания в головах и руках сотрудников, структура отношений внутри фирмы и с внешним миром, технология, история развития и текущий опыт. С этой точки зрения КИС может быть эффективна на всех участках работы, более того, в современном мире она и есть неотъемлемая часть фирмы. Она позволяет анализировать работу всей фирмы и отдельных частей, она может оптимально планировать производство и ресурсы, она может учитывать рабочее время и управлять работой людей. Эффективность фирмы - это и ее система качества. Современные системы качества составляют часть КИС. Что ограничивает полет мысли IT-директора при планировании КИС? Только бюджет!

Фирмы не появляются "вдруг", они живут долгой жизнью, развиваются и вместе с ними должны развиваться и КИС. Это означает, что надо иметь поставщика услуг КИС и ПО надежного как верный партнер. Это означает, также, что за развитие КИС (как и за все остальное) надо платить.

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

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

Стандарт ИСО-9126 [7] рекомендует анализировать также и точку зрения разработчика. Правда, несколько расплывчато (п. 5.2.2 "Поскольку разработчики ответственны за производимое программное обеспечение, которое должно удовлетворять требованиям качества, они заинтересованы в качестве промежуточного программного продукта, также как и в качестве конечного продукта").

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

Можно строить и другие структуры критериев и параметров качества. Вот, например, какую структуру характеристик качества предлагает стандарт ИСО-9126 [7] (да и то, в качестве нормативного приложения, как пример, оговариваясь, что фирмы могут применять совершенно другие наборы характеристик, лишь бы они удовлетворяли общим требованиям стандарта):

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

4. Как рождается качество

Один из героев Р. Уоррена говорит: "Добро не приходит с небес и не существует вечно на земле. Человек создает Добро походя, изо дня в день своими руками, из ничего, из дерьма. Также как Господь сотворил человека из глины, не имея под рукой другого подходящего материала". Эта мысль, положенная в основу теории познания (только по отношению к знаниям, а не к Добру), применяется И. Нонакой и Х. Такойчи [5] для описания процесса создания качества японскими корпорациями. В основе процесса "спираль познания" (рис 2.).

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

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

Применяя данную концепцию к процессу создания Систем Качества в отрасли разработки КИС, финские ученые И. Тервонен и П. Керола [6] предложили спираль развития системы качества (и технологии разработки) КИС в целом. В несколько вольной и расширенной трактовке автора она изображена на рис. 3. Из рисунка следует, что в процессе работы, индивидуальные ощущения специалистов "что такое хорошо и что такое плохо в смысле качества КИС" должно стать достоянием всей фирмы. В виде документов, образцовых программ, технологии и базы знаний (если таковая существует на фирме) эти ощущения становятся "знаниями" и позволяют поднять общую культуру работы (процесс адаптации знаний или "впитывания культуры"). В свою очередь новый уровень мышления и новая технология позволяют увидеть и обобщить новые интуитивные ощущения качества на еще более высоком уровне. Круг замыкается, спираль системы качества раскручивается.

Таким образом, мы приходим к основному методу оценки Системы Качества. Это "Метод оценки зрелости фирмы-разработчика". Действительно, у нас нет (и, скорее всего не будет) метрологии качества КИС, у нас нет реальных методов оценки качества ПО, нет также и методов оценки качества процесса конструирования, разработки и внедрения. Что же остается? Разработать методы оценки опыта развития фирмы. Чем отличается "дурак" от "умного"? Тем, что умный уже был раньше дураком, а дурак умным - еще нет.

Рис 2 Спираль создания и накопления знаний

Рис 3. Спираль развития системы качества КИС

5. Аттестат зрелости

Стандарт ИСО-9126 [7] гласит (раздел В.1- "Основы"): "Есть два подхода, которым можно следовать, чтобы гарантировать качество продукта, первый заключается в том, чтобы убедиться в процессе разработки, и другой в том, чтобы оценить качество конечного продукта. Обе дороги важны…"

Если учесть тот факт, что надежных способов проверить "качество конечного продукта" в нашем случае нет, кроме, естественно, способа "попробовать", то получается, что для выбора поставщика КИС и ПО надо "зрить в корень", смотреть, как давно он работает и как он работает.

Совет довольно банальный. Примерно так всегда действуют толковые руководители: съездят, посмотрят на фирму, с людьми поговорят, сразу и видно "who is who". Но не такова наука. Американские доктора КИС ([8] и [9]) "точно знают" среднестатистическую, врачебно-одобренную модель "правильной" фирмы. Произведя анкетирование, можно легко определить степень заболевания фирмы "по несоответствию анализов норме" (как бы она хорошо себя не чувствовала), а затем медикаментозными средствами довести ее до нормы здоровья (даже если она при этом умрет).

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

Сарказм автора можно понять. Это - неверие Буратино в то, что очаг может быть настоящим, а не нарисованным на холсте. Недавно ему (автору, а не Буратино) предлагали по очень сходной цене членство в Академии наук (почему бы и не стать академиком за какие-то двести баксов?). Не Российской Академии, а маленькой такой частной академии. А сертификаты Системы Качества выдают "совершенно независимые и абсолютно объективные" аудиторские фирмы. Ну да.

6. Как выбрать поставщика КИС и ПО?

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

Зрелость означает, что фирма должна в своем развитии дойти до разделения труда. КИС и ПО должны производится отдельно. Производство ПО должно выполнятся по конвейерной схеме с глубоким разделением труда, что требует применения специальных СУБД. Должны существовать документально зафиксированные и реально демонстрируемые Системы Качества - одна для конструирования и внедрения КИС, другая - для производства ПО. Обязательно должна существовать собственная корпоративная информационная система, в рамках которой должна быть построена база знаний фирмы. Зрелость, прежде всего, означает, что фирма должна была сделать хотя бы несколько витков по "спирали познания качества". Знания должны оформляться документально в базе знаний и адаптироваться в головах и руках специалистов.

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

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

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

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

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

7. От слов - к делу (продолжение следует!)

Читатели практического склада ума наверняка разочарованы - опять "вода" без примеров реализации. Но в этот раз обмана не будет! Связавшись с автором статьи, Вы сможете на реальном примере одной московской фирмы увидеть, как можно построить конвейер разработки ПО, как можно автоматизировать подготовку ТЗ большого объема, какие СУБД могут обеспечить пожизненную гарантию целостности данных, как устроены и накапливаются корпоративные базы знаний качества. Будучи ограниченными объемом статьи, мы не рассказали также о формальных методах оценки сложности программных модулей и статистической обработке данных об ошибках (метрология качества ПО все-таки зарождается!).

Литература:

M.J. Taylor, J.L. DaCosta, "Soft Issues in IS Projects: Lessons from an SME Case Study". Systems Research and Behavioral Science, vol. 16, No. 3, May-June 1999.
B. Kitchenham, S. Pfleeger, "Software quality: the elusive target", IEEE Software 13 (1), 1996.
ИСО 9000-3: ИСО 9001 Общее руководство качеством и стандарты по обеспечению качества, часть 3: Руководящие указания по применению ИСО 9001 при разработке, поставке и обслуживанию программного обеспечения. Международная организация стандартов, Женева, 1991.
L.A. Hellens, "Information systems Quality versus Software Quality - A discussion from a managerial, an organizational and an engineering viewpoint", Information and Software technology, vol. 39, No12. (1998)
I. Nonaka, H. Takeuchi, "The Knowledge-Creating Company - How Japanese Companies Create the Dynamics of Innovation", Oxford University Press, Oxford, 1995.
I. Tervonen, P. Kerola, "Towards deeper co-understanding of software quality", Information and Software Technology, vol. 39, No 14-15 (1999).
ИСО/МЭК 9126 Информационные технологии. Оценка продукции программного обеспечения. Характеристики качества и инструкции по их применению. Международная организация стандартов, Женева, 1991.
M.C. Paulk, B. Curtis, M.B. Chissis, C.V. Weber, "Capability maturity model, version 1.1", IEEE Software 10 (4), 1993.
W.S. Humphrey, "CMM: Capability Maturity Model - A method for Assessing the Software Engineering Capability of Contractors", Carnegie Mellon University, Software Engineering Institute, 1996.

1. Кстати и знаменитый стандарт ИСО 9000-3 [3] делает реверанс в эту сторону: п. 6. 4. 1 "…В настоящее время не существует общепринятых критериев качества программного обеспечения..."