© "Инженер Мареев Интерпрайсиз"
В 31-м номере, в статье "Это сладкое слово "качество" мы обсуждали системы качества для фирм, конструирующих КИС и разрабатывающих ПО. Мы обещали вернуться к этой теме и на конкретном примере рассказать, как можно накапливать коллективные знания на такой фирме. Однако, представители фирм-заказчиков как в вопросах, присланных по электронной почте, так и во время наших презентаций всегда "сворачивают" на свои проблемы: "А как ваша система качества превращается в нашу систему качества?" (в рамках реализованной в конце концов КИС). Их можно понять, редко кого интересует "сам процесс", все-таки западная цивилизация больше ориентирована на конечный результат. Поэтому мы решили рассказать не только о конвейерном процессе производства заказных информационных систем, но и о том как они "приживляются" к телу фирмы-заказчика в качестве, если не мозга, то уж нервной системы - точно.
Для тех, кто не обладает временем, достаточным для чтения большого материала, сформулируем логическую последовательность выводов, раскрываемых в данной статье (стрелочка означает слово "следовательно"):
Злые языки говорят, что "программист это не профессия - это диагноз". Что мы можем ответить? Ведь артиста каждый может обидеть...
Поточное производство произведений искусства - вещь в наше время совершенно обыденная. Глубокое разделение труда применяется в производстве популярной музыки. Одни пишут стихи, другие придумывают мелодию, третьи делают аранжировку, затем - исполнение, запись, сбыт ("раскрутка"). Однако, простое разделение труда - это еще не конвейер. Важнейший элемент конвейерного производства - иерархическое разделение труда. Понять, что такое "иерархия разделения труда", легко на примере декомпозиции конструкции компьютерных систем: одни совершенствуют технологические процессы микроэлектроники, другие разрабатывают транзисторы и так далее до операционной системы и прикладных программ. Интерфейсы на уровне плат позволяют организовать разделение труда, а технологические интерфейсы позволяют организовать иерархию разделения труда.
Технологией разработки заказных программных систем фирма ЕМЕ "увлекается" уже, без малого, десять лет. Технология по-настоящему сформировалась лишь после изобретения принципиально нового подхода в конструировании ПО: "Трехслойный пользовательский интерфейс и Метапроект" (два года назад). Этот подход позволил полностью отделить друг от друга процесс визуального конструирования диалогов и отчетов (и сборки системы) от процесса разработки алгоритмов на языке программирования. "Чистые" алгоритмы (отвязанные от конкретных проектов) существуют в среде интерфейса-стандарта "Метапроект" и позволяют накапливать овеществленный опыт разработок фирмы. Такое накопление создало предпосылку для построения системы качества разработки КИС и ПО.
Декомпозиция производства заказной КИС, применяемая на фирме ЕМЕ, изображена на рис 1. На этом рисунке представлена организационная структура предприятия. Легко прослеживается основная петля конвейера - рис. 2. Она не включает программистов в привычном значении этого слова (разрабатывающих программы на алгоритмическом языке). Постановку задачи выполняют консультанты. Разработку ТЗ - конструкторы. Сборку и внедрение системы - прикладные программисты, работающие только с визуальными средствами конструирования диалогов, отчетов, рабочих мест и бизнес-процессов (в среде ЕМЕ-ДБ). Особая роль в системе качества отводится отделу тестирования, которое выполняется как на уровне отдельных модулей, так и систем в целом.
Такое разделение труда уже очень эффективно и создает предпосылки для построения системы качества. Но такого разделения труда не достаточно для "борьбы" со сложностью крупных проектов. Для этого требуется не просто разделение труда, а иерархия разделения труда, которая в разработке программного обеспечения достигается в технологии "Метапроект" - уникальном ноу-хау фирмы ЕМЕ.
Технология - это интерфейсы и стандарты. Точно описанные интерфейсы (стыки) между блоками сложного изделия позволяют конструировать и развивать эти блоки независимо друг от друга. Интерфейсы бывают "горизонтальные" - для сочленения блоков на одном уровне иерархии, и "вертикальные" - для сборки более сложных блоков из простых.
Интерфейсы и стандарты - это скелет технологии, без которого сложная конструкция осыпается как песок.
Специалистам фирмы ЕМЕ удалось разработать и внедрить единый корпоративный стандарт-интерфейс, имеющий многоуровневую структуру и выполняющий как "вертикальные" так и "горизонтальные" связывающие функции. Этот стандарт называется "Метапроект".
В основе метапроекта лежит система имен (на русском языке). Имена полей и таблиц в структуре данных, имена диалогов и полей (органов) диалогов, имена отчетов, ячеек и колонок отчетов кодируются на естественном языке и в совокупности составляют некоторую вербальную модель внешнего мира, который когда-либо автоматизировался фирмой ЕМЕ. Модель структурируется как в системном плане (рис. 3), так и по отношению к прикладной области (рис. 4).
Стандарт метапроекта довольно обширен - около десяти тысяч категорий, объединенных в древовидные структуры и дополненные перекрестными связями. Перекрестные связи - это традиционные реляции в структуре БД, а также ссылки диалогов и отчетов на структуру данных, друг на друга, на общие "браузеры" таблиц и тому подобное.
Стандарт постоянно развивается. Коль скоро фирма ЕМЕ занимается только заказными проектами, то каждый новый проект содержит уникальные узлы и механизмы, находящие свое отражение в новых структурах данных и системах диалогов и отчетов.
Главная особенность стандарта - его логическая целостность, непротиворечивость и оптимальность по отношению к логическим и ссылочным тавтологиям. За этим следят специалисты "метагруппы" (группы метапроекта). Все новые разработки планирует группа генерального конструктора при разработке подробного технического задания на основе схемы автоматизированных бизнес-процессов фирмы-заказчика. Объем подробного технического задания обычно составляет 500-1000 страниц. Время подготовки - один-два месяца.
Новые идеи очередного проекта в виде заявок на модификацию стандарта метапроекта передаются в группу главного инженера (руководителя группы метапроекта). Специалисты метагруппы тщательно анализируют новые программные механизмы и увязывают их структуру данных с имеющейся схемой метапроекта.
Однако, как мы уже говорили, стандарт-интерфейс сам по себе - это только скелет будущих систем. Для того чтобы КИС приобрела реальные очертания, модельная структура должна "обрасти" конкретными диалогами, отчетами, браузерами, алгоритмами обработки. Здесь мы подходим вплотную к решению задачи иерархического разделения труда. Для этой цели на фирме ЕМЕ реализована технология "Трехслойный пользовательский интерфейс".
Фирма ЕМЕ, как большинство западных фирм, специализирующихся на производстве заказного ПО, практически не использует программы, разработанные третьими фирмами (операционная система - не в счет). СУБД ЕМЕ-ДБ развивается более 15 лет и классифицируется как "Синхронные базы данных класса RISC". Это высоконадежная база данных с сокращенным набором команд манипуляции данными, с дублированием части банка данных на всех рабочих станциях и прямыми реляционными связями. К конструкции СУБД ЕМЕ-ДБ мы вернемся в следующих публикациях, здесь скажем лишь, что базы данных этого класса используются в системах управления воздушным движением стран НАТО. Надежность конструкции СУБД позволяет фирме ЕМЕ давать десятилетнюю (практически пожизненную) гарантию на целостность банка данных и работоспособность системы (без архивного резервирования данных!).
Термин "Трехслойный пользовательский интерфейс" обозначает средства визуального конструирования и все механизмы, отвечающие за интерфейс человек-машина.
"Три слоя" - это три уровня настроек прикладной части системы. Настройки общие для всей системы, настройки отдельных механизмов и настройки отдельных диалогов и отчетов. Настройки вводятся в метапроект по мере разработки новых проектов. Они позволяют отключать опции и режимы работы, ненужные для данного конкретного проекта или рабочего места.
Главная особенность трехслойного интерфейса, для чего он собственно и конструировался, это возможность подключать внешние функции к диалогам, отдельным органам диалогов, к отчетам и колонкам (ячейкам) отчетов. С этой целью все визуальные редакторы снабжены специальными ячейками, в которых прикладной программист может указать имя библиотеки DLL и точку входа (все точки входа собираются в базе данных с подробной документацией и древовидной классификацией).
Внешние функции представляют собой "чистые" (без собственных диалогов) алгоритмы, разработанные на языке C++ (они называются "метафункции"). Алгоритмы представляют собой типичные "черные ящики", входы и выходы которых - категории из перечня стандарта Метапроект. Это позволяет точно документировать функции алгоритмов, лишь ссылаясь на категории стандарта, прикладное логическое значение которых считается известным. Алгоритмы бывают очень простыми и применимыми к любому органу (например, программа запрещающая оставлять данное поле незаполненным) и очень сложными (например, класс объектов "документ", который применяется для всех видов товарных и платежных документов). Механизм передачи управления метафункциям - событийно-ориентированный. Управляющие сигналы рассылает ядро СУБД. Получив сообщение "инициализация диалога или отчета", метафункция анализирует окружение (систему имен) к которому она подключена, в зависимости от реального контекста и значений внешних параметров настраивает свои режимы работы. Метафункции - "умные", они помогают прикладному программисту точно задать параметры и диагностируют ошибки "привязки".
Задача формирования и развития метапроекта отнюдь не проста. Разработчик заказных систем не замыкается на узкой специализации проектов.
Например, среди разработок ЕМЕ традиционные системы автоматизации коммерческих предприятий (склад, торговля, "упаковочное" или "отверточное" производство, бухгалтерия), модули анализа эффективности и полноценные механизмы "ситуационной комнаты", крупномасштабные системы автоматизации агропромышленного комплекса с применением геоинформационных технологий, полная автоматизация производства с оптимизацией процессов класса MRP-II, логистика гигантских складов и транспортных перевозок, автоматизация крупной элитной библиотеки и сотни других проектов.
Логическая целостность метапроекта, оптимальное объединение функций в классы, точный баланс между количеством параметров функций и числом программных точек входа, все это требует приложения специальных усилий.
Наградой является увеличение процента повторно используемого кода (который уже сейчас составляет 60-80 процентов и в будущем может быть доведен до 90-95!) и, соответственно, снижение стоимости и сокращение сроков разработок.
Интересно то, что "чистые" (без диалогов) алгоритмы метапроекта, манипулирующие только именами стандарта, постепенно, с годами, формируются в гигантскую информационную систему, которая функционально "умеет все" - и торговать, и производством управлять, и "хлеб сеять"… Метапроект вместе со стандартом создает серьезные предпосылки для открытия опыта разработок в виртуальной публичной технологии "Открытые исходные тексты". Это еще только планы на будущее, хотя эксперимент уже проводится на нескольких фирмах-заказчиках, пожелавших поручить развитие готовой системы собственным IT-отделам.
Несмотря на "молодость" технологии, уже сегодня по стоимости проектов и срокам исполнения заказные разработки фирмы ЕМЕ успешно конкурируют с аналогичными тиражируемыми системами КИС. С каждым новым проектом эти характеристики улучшаются.
Почему реорганизация предприятий никогда не дает ожидаемых эффектов, а во многих случаях (Сергей Ильдеменов называет цифру 50% в статье "Реинжениринг - ключ к успеху", PC-WEEK No 31) заканчивается провалом? Все дело в том, что фирма, если ее рассматривать как формальную систему, существует в головах и опыте работы конкретных людей, в их связях и отношениях друг с другом, с внешним миром. Фирма может менять направление работы, переезжать в другой офис, даже изменять название - все эти элементы могут оказать лишь малое влияние на суть системы. Если же поменять персонал (или хотя бы все "ключевые" фигуры, которые по должности - не обязательно старшие), то фирма изменится качественно - она разрушится, потеряв свой главный составляющий элемент - корпоративное знание. Отсюда и проблемы с реинженирингом: нельзя волевым решением приобрести коллективное знание. Это ничуть не легче чем приобрести индивидуальное знание. Попробуйте приказать себе: "С завтрашнего утра владение английским языком обязательно!". То, что накапливается годами, не дадут ни консультанты, ни "экспресс методы".
Необходимым условием эффективного развития предприятия являются два условия: способность "видеть себя со стороны" и наличие условий для раскрутки спирали знаний системы качества. Оба эти условия выполняются если добиться одной простой вещи:
Это означает, что если раскрутка спирали системы качества - процесс непрерывный, то и информационная система должна развиваться. При этом не отставая от развития предприятия, а опережая его - помогая быстро внедрять новые идеи. КИС должна постоянно дополняться организационными идеями в виде новых программных модулей.
Например, вводим кружки качества и тут же в системе фиксируем расписание и краткие протоколы занятий. Обнаруживаем большое количество дефектов в производстве - вводим партионный и поэкземплярный учет и точно фиксируем, кто и когда выполнил конкретную производственную операцию. Разбор каждого дефектного случая с поиском виновного позволяет "отточить" технологию. Статистические выборки и анализ допусков - расписание, ответственные и обработка должны быть в системе. Нужна дисциплина труда - компьютер решает и эту задачу. Завышенная дебиторская задолженность подрывает бюджет - вводим анализ структуры дебиторской задолженности с детализацией по отдельным менеджерам и торговым представителям. Придумываем "самопополняющиеся" должностные инструкции, так чтобы провинившиеся в некачественной работе дописывали бы себе новые правила - это можно реализовать только в компьютере. Система качества требует "перенести" корпоративные знания из базы данных в головы сотрудников - начинаем работу фирмы с поголовной сдачи блицэкзамена по программируемым карточкам (как в ГАИ).
Мы уже говорили, что система качества, как форма коллективного знания, не возникает вдруг. Она развивается вместе с предприятием, впитывая новые идеи, пробуя разные подходы. Это означает, что КИС нельзя купить, ее можно вырастить на своем предприятии. Вырастить с помощью надежного партнера - фирмой, изготавливающей программы на заказ.
Мероприятия, условно называемые Система Качества, из-за их масштабности не могут быть подробно описаны в журнальной публикации - их можно только перечислить. Кроме того, они постоянно развиваются и множатся. Довольно подробно система качества описана на web-сервере фирмы ЕМЕ (www.eme.ru).
В основе системы качества лежит собственная КИС фирмы ЕМЕ. Она постоянно пополняется новыми модулями и имеет некоторые черты базы знаний: позволяет вводить абстрактные взаимосвязанные классифицированные категории. В качестве таких категорий в системе накапливаются должностные и технологические инструкции, база данных метафункций, элементы технических заданий на модули и подсистемы, пользовательская документация, типичные ошибки, протоколы работы кружков качества и мозговых штурмов.
Одним из элементов системы качества является детально разработанная процедура взаимодействия с клиентом. Так например, любые, даже самые малые изменения в системе проходят согласование в группе генерального конструктора и, при необходимости, выносятся на обсуждение в группу метапроекта. После этого готовится частное техническое задание, которое подтверждается представителем заказчика. Изменение вносится в систему и выполняется тестирование всех затронутых узлов. Только после этого новые модули могут быть установлены на фирме заказчика. Процедура регламентирована и по времени - обычно она занимает от двух до пяти дней (если не связана с разработкой новых сложных модулей).
Результаты тестирования (подробные описания и классификация ошибок с указанием "автора" и причины) также накапливаются в базе данных. Диаграммы распределения ошибок по проектам, отделам, модулям, программистам анализируются на кружках качества и мозговых штурмах. Для устранения причин ошибок в ядро базы данных и в метапроект постоянно добавляются блокирующие и предупреждающие механизмы (если это возможно). Такая "механическая" борьба с ошибками - самое эффективное средство и представляет собой, без сомнения, самый лучший способ накапливать коллективное знание.
Разговаривать о системе качества можно бесконечно. К тому же, интереснее беседовать очно. Консалтинговая фирма Риккон (www.rikkon.ru), давний партнер фирмы ЕМЕ проводит регулярные семинары, посвященные проблемам реинжениринга, стратегии построения КИС и систем качества. Присылайте Ваши вопросы (по электронной почте). Автор с удовольствием ответит на все письма, а наиболее общие вопросы будут вынесены на семинары, куда и приглашаются все желающие.
Связаться с автором можно по электронной почте eme@eme.ru
Связаться с фирмой Риккон можно по электронной почте rikkon@dol.ru
Рис 1. Схема конвейера разработки ПО
Рис. 2. Основная петля конвейера
Рис.3 Системная структура стандарта метапроекта
Рис. 4 Прикладная структура метапроекта