© "Инженер Мареев Интерпрайсиз"
Качество информационных систем относится к области искусства, если речь идет об отдельном специалисте, и к области культуры производства, в применении к фирме. В этой статье мы расскажем о современных идеях в науке "Системы качества в производстве КИС".
Весь промышленный мир сходит с ума по качеству. Японское экономическое чудо, похоже, нашло свое выражение в простой формуле: "Система качества". Сложилась целая отрасль со своей наукой, своими авторитетами, "всемирно известными" методами, международными и национальными премиями, стандартами.
Разработчики программного обеспечения также охвачены лихорадкой качества. Хотя абсолютно все авторы и начинают свои публикации со слов: "Всем известно, что качество программного обеспечения не поддается точному определению и измерению"1, тем не менее, задача поставлена и требует решения. Что удается с трудом.
В этой связи любопытна публикация [1] английских исследователей М. Тэйлор и Дж. ДаКоста. Они провели анализ проблемы качества КИС (Корпоративной Информационной Системы) на одном конкретном примере. Внедрили на небольшую фирму своего человека в качестве консультанта, который наблюдал за ходом создания информационной системы. Главный вывод статьи: "на средних и малых предприятиях при разработке и внедрении КИС возникают те же проблемы с качеством, что и на больших, поэтому требуется применение методологии "Гибких Систем". Это не очень интересно. Интереснее перечень проблем, с которыми столкнулись английские товарищи:
На этом примере видны все основные места "некачественности":
При этом английские ученые даже не поднимают вопрос о принципиальной примитивности изделия, которое может быть произведено таким образом (а это и будет главным пунктом "некачественности", после того, как программа, наконец, заработает). Простой опрос мнений операторов и менеджеров об их видении будущей системы пригоден лишь для конструирования базовой версии изделия, предназначенной для автоматизации учета, но не автоматизации коммерческой или производственной деятельности. Без этого можно говорить лишь о качестве программ, но не о качестве информационной системы в целом. В такой постановке проблема решалась 10 лет назад. Сегодня, говоря о КИС - корпоративных информационных системах - мы заходим гораздо дальше: КИС должна повышать общую организационную эффективность фирмы и быть частью ее системы качества.
На схеме рис.1 обозначены современные тенденции Систем Качества в области КИС и ПО.
Рис 1. Современная модель качества КИС и ПО.
Как справедливо отметил Л. Хелленс в [4], фирмы, разрабатывающие и внедряющие КИС, должны отдавать себе отчет в том, что они предоставляют услуги, а не производят товар. Разработка программ - это, конечно, производство, но это лишь малая часть работы по созданию КИС. Если мы посмотрим список проблем "английских товарищей" (П1), то увидим, что лишь одна из четырех проблем относится к производству программного обеспечения.
То же самое мы видим и при анализе качества ИС при присуждении премий фирмам за хорошее качество изделий.
Кстати, международные и национальные премии за качество - прекрасный пример того, как надо организовывать конкурсы между фирмами. Любопытно, как даты учреждения премий отражают историю развития систем качества в разных странах:
Например, при анализе изделий, выдвинутых на премию Malcolm Bridge, учитываются 20 критериев с общей суммой баллов 1000, из них лишь 250 баллов приходятся на технические аспекты качества.
Объединяя работу по созданию КИС и ПО в одно целое, фирма разработчик зачастую слишком сосредотачивается на программах, забывая о системе. Отклонившись от правильного курса в самом начале - при конструировании, программисты не слишком заботятся о внедрении, того что "уже нехорошо". В результате проект проваливается.
Под словом "все" подразумевается данная статья, в частности, и вся суета вокруг систем качества, в общем.
Если отбросить общие фразы, "это нужно людям для хорошей жизни", а "фирмам для выживания", то останется следующее: знание современных идей по системам качества позволяет заказчику найти грамотного поставщика, а поставщику убедить заказчика в своей способности хорошо выполнить поставленную задачу. Примерно так формулируется и цель стандарта ИСО-9000.
Данная статья решает вполне практическую задачу: она призвана дать потенциальному заказчику ИС "установку" - на что надо обращать внимание при выборе поставщика услуг КИС, разработчика программного обеспечения и при подготовке соответствующих контрактов.
Китченхам и Пфлегер справедливо замечают в [2], что фирмы, предоставляющие услуги по созданию КИС "увеличивают стоимость фирм-заказчиков" и именно на это увеличение стоимости должны быть направлены их усилия.
Для запада эта фраза наполнена вполне прагматичным смыслом. Повышение коммерческой эффективности фирмы повышает дивиденды инвесторов по акциям, дивиденды повышают биржевую стоимость акций, общая стоимость акций и есть стоимость фирмы.
Поэтому главный критерий качества КИС - ее способность повысить коммерческую эффективность всей фирмы. Это - критерий качества с точки зрения руководителя фирмы.
"Повысить общую эффективность фирмы" - это высказывание для ученого в тиши кабинета, не ведающего, что он говорит. "Общая эффективность фирмы" для самой фирмы - это все, это жизнь, конкуренция, надежды, мечты, идеи, кризисы, удачи, провалы.… Сама фирма это ведь не здание, не конкретные люди, не станки и товары… Фирма это и есть сгусток информации: знания в инструкциях, знания в головах и руках сотрудников, структура отношений внутри фирмы и с внешним миром, технология, история развития и текущий опыт. С этой точки зрения КИС может быть эффективна на всех участках работы, более того, в современном мире она и есть неотъемлемая часть фирмы. Она позволяет анализировать работу всей фирмы и отдельных частей, она может оптимально планировать производство и ресурсы, она может учитывать рабочее время и управлять работой людей. Эффективность фирмы - это и ее система качества. Современные системы качества составляют часть КИС. Что ограничивает полет мысли IT-директора при планировании КИС? Только бюджет!
Фирмы не появляются "вдруг", они живут долгой жизнью, развиваются и вместе с ними должны развиваться и КИС. Это означает, что надо иметь поставщика услуг КИС и ПО надежного как верный партнер. Это означает, также, что за развитие КИС (как и за все остальное) надо платить.
Быть или не быть - вопрос для КИС, увы, первостепенный. Слишком большое количество проектов (как за рубежом, так и у нас) следовало бы признать провальными. Проекты терпят фиаско, как правило, на стадии внедрения. Так как не выдерживают критики со стороны пользователей: "Медленно работает, часто сбоит, в неудобной форме представляет данные, не предоставляет всех нужных данных, слишком сложна, слишком проста, "я-и-так-устаю-за-целый-день,-чтобы-еще-с-вашей-дурацкой-программой-возиться!".
Это критерии качества с точки зрения пользователя. Сюда входит общее качество офисной работы, полнота информации, точность данных, устойчивость программ и данных по отношению к пользовательским ошибкам и сбоям аппаратуры.
Стандарт ИСО-9126 [7] рекомендует анализировать также и точку зрения разработчика. Правда, несколько расплывчато (п. 5.2.2 "Поскольку разработчики ответственны за производимое программное обеспечение, которое должно удовлетворять требованиям качества, они заинтересованы в качестве промежуточного программного продукта, также как и в качестве конечного продукта").
Критерии качества с точки зрения разработчика: техническое качество работы (быстродействие, надежность), пригодность к сопровождению и развитию, устойчивость - полностью относятся к компетенции системы качества ПО.
Можно строить и другие структуры критериев и параметров качества. Вот, например, какую структуру характеристик качества предлагает стандарт ИСО-9126 [7] (да и то, в качестве нормативного приложения, как пример, оговариваясь, что фирмы могут применять совершенно другие наборы характеристик, лишь бы они удовлетворяли общим требованиям стандарта):
Как мы видим, несмотря на то, что стандарт претендует на полноту анализа, то есть, рассматривает качество всего изделия КИС, предлагаемый авторами стандарта пример характеристик, по сути, затрагивает лишь качество ПО. От 91-ого года большего ждать и не приходится.
Один из героев Р. Уоррена говорит: "Добро не приходит с небес и не существует вечно на земле. Человек создает Добро походя, изо дня в день своими руками, из ничего, из дерьма. Также как Господь сотворил человека из глины, не имея под рукой другого подходящего материала". Эта мысль, положенная в основу теории познания (только по отношению к знаниям, а не к Добру), применяется И. Нонакой и Х. Такойчи [5] для описания процесса создания качества японскими корпорациями. В основе процесса "спираль познания" (рис 2.).
По рисунку довольно легко понять ход мыслей японских ученых. Знание возникает на основе практического опыта в форме интуитивных ощущений и может накапливаться лишь посредством коллективной работы многих:
Применяя данную концепцию к процессу создания Систем Качества в отрасли разработки КИС, финские ученые И. Тервонен и П. Керола [6] предложили спираль развития системы качества (и технологии разработки) КИС в целом. В несколько вольной и расширенной трактовке автора она изображена на рис. 3. Из рисунка следует, что в процессе работы, индивидуальные ощущения специалистов "что такое хорошо и что такое плохо в смысле качества КИС" должно стать достоянием всей фирмы. В виде документов, образцовых программ, технологии и базы знаний (если таковая существует на фирме) эти ощущения становятся "знаниями" и позволяют поднять общую культуру работы (процесс адаптации знаний или "впитывания культуры"). В свою очередь новый уровень мышления и новая технология позволяют увидеть и обобщить новые интуитивные ощущения качества на еще более высоком уровне. Круг замыкается, спираль системы качества раскручивается.
Таким образом, мы приходим к основному методу оценки Системы Качества. Это "Метод оценки зрелости фирмы-разработчика". Действительно, у нас нет (и, скорее всего не будет) метрологии качества КИС, у нас нет реальных методов оценки качества ПО, нет также и методов оценки качества процесса конструирования, разработки и внедрения. Что же остается? Разработать методы оценки опыта развития фирмы. Чем отличается "дурак" от "умного"? Тем, что умный уже был раньше дураком, а дурак умным - еще нет.
Рис 2 Спираль создания и накопления знаний
Рис 3. Спираль развития системы качества КИС
Стандарт ИСО-9126 [7] гласит (раздел В.1- "Основы"): "Есть два подхода, которым можно следовать, чтобы гарантировать качество продукта, первый заключается в том, чтобы убедиться в процессе разработки, и другой в том, чтобы оценить качество конечного продукта. Обе дороги важны…"
Если учесть тот факт, что надежных способов проверить "качество конечного продукта" в нашем случае нет, кроме, естественно, способа "попробовать", то получается, что для выбора поставщика КИС и ПО надо "зрить в корень", смотреть, как давно он работает и как он работает.
Совет довольно банальный. Примерно так всегда действуют толковые руководители: съездят, посмотрят на фирму, с людьми поговорят, сразу и видно "who is who". Но не такова наука. Американские доктора КИС ([8] и [9]) "точно знают" среднестатистическую, врачебно-одобренную модель "правильной" фирмы. Произведя анкетирование, можно легко определить степень заболевания фирмы "по несоответствию анализов норме" (как бы она хорошо себя не чувствовала), а затем медикаментозными средствами довести ее до нормы здоровья (даже если она при этом умрет).
Как бы там ни было, сертификация систем качества идет полным ходом. В области информационных услуг процент обсертифицированности еще отстает от других отраслей, но скоро, по-видимому, при проведении переговоров с фирмой-разработчиком КИС, наравне с гос. лицензией можно будет спрашивать и наличие сертификата качества.
Сарказм автора можно понять. Это - неверие Буратино в то, что очаг может быть настоящим, а не нарисованным на холсте. Недавно ему (автору, а не Буратино) предлагали по очень сходной цене членство в Академии наук (почему бы и не стать академиком за какие-то двести баксов?). Не Российской Академии, а маленькой такой частной академии. А сертификаты Системы Качества выдают "совершенно независимые и абсолютно объективные" аудиторские фирмы. Ну да.
Он должен быть зрелым, финансово самостоятельным, надежным, иметь голову на плечах (уметь мыслить системно) и быть внимательным к клиенту. Внешний блеск не важен, на это часто попадаются невинные клиенты и долго потом раскаиваются. Но самое главное, что у него должно быть - это ремесло в руках.
Зрелость означает, что фирма должна в своем развитии дойти до разделения труда. КИС и ПО должны производится отдельно. Производство ПО должно выполнятся по конвейерной схеме с глубоким разделением труда, что требует применения специальных СУБД. Должны существовать документально зафиксированные и реально демонстрируемые Системы Качества - одна для конструирования и внедрения КИС, другая - для производства ПО. Обязательно должна существовать собственная корпоративная информационная система, в рамках которой должна быть построена база знаний фирмы. Зрелость, прежде всего, означает, что фирма должна была сделать хотя бы несколько витков по "спирали познания качества". Знания должны оформляться документально в базе знаний и адаптироваться в головах и руках специалистов.
Финансовая самостоятельность означает, что фирма-разработчик должна являться юридическим лицом с изрядной историей существования, должна обладать собственным мощным производством и не должна быть "группой товарищей" или "франчайзи", обладающей "правом делать настройки".
Надежность означает, что фирма должна давать на свою продукцию очень убедительную гарантию и обладать историей, подтверждающей способность выполнить гарантийные обязательства.
Умение мыслить системно означает, что должен быть отдел, занимающийся только конструированием КИС. Концепции КИС должны содержать идеи по реинженирингу организационных структур клиента. Техническое задание должно утверждаться клиентом до начала разработки. Техническое задание должно исчерпывающим образом отражать все старые и вновь вводимые бизнес-процессы, рабочие места, диалоги и отчетные формы, графики работ, внедрения и обучения. Объем хорошего технического задания - 700-2000 страниц.
Быть внимательным означает, что должна быть внедрена точная технология работы с клиентом: прием заявок, диспетчеризация, должны нормироваться формы переписки, сроки ответов и подготовки технических заданий на изменения (это не шутка, "просто исправить" программу всегда означает "сломать что-нибудь другое"), сроки доработок и их внедрения.
Ремесло в руках означает все вышесказанное, плюс хорошую научную школу, положенную в основу как базовых элементов системы, так и предметных областей приложения.
Читатели практического склада ума наверняка разочарованы - опять "вода" без примеров реализации. Но в этот раз обмана не будет! Связавшись с автором статьи, Вы сможете на реальном примере одной московской фирмы увидеть, как можно построить конвейер разработки ПО, как можно автоматизировать подготовку ТЗ большого объема, какие СУБД могут обеспечить пожизненную гарантию целостности данных, как устроены и накапливаются корпоративные базы знаний качества. Будучи ограниченными объемом статьи, мы не рассказали также о формальных методах оценки сложности программных модулей и статистической обработке данных об ошибках (метрология качества ПО все-таки зарождается!).
1. Кстати и знаменитый стандарт ИСО 9000-3 [3] делает реверанс в эту сторону: п. 6. 4. 1 "…В настоящее время не существует общепринятых критериев качества программного обеспечения..."