© "Инженер Мареев Интерпрайсиз"
Введение. Классификация организационных структур и технология творческой работы
Одна из шуточных иерархий развития производства (бизнеса) классифицирует организационную структуру по возрастанию "организованности" следующим образом:
Следуя этой иерархии, систему качества следует рассматривать не как некий внешний элемент, который можно "прилепить" к различным типам организации работы, а как самостоятельный уровень развития организационной структуры предприятия.
Мы говорим "система качества", а не "система управления качеством" или "система контроля качества". Это важный момент. Мы следует терминологии стандарта ISO-9000, который ввел в широкое обращение термин "система качества" и дал развернутое разъяснение, каким требованиям должна удовлетворять организационная структура предприятия, претендующего на этот уровень своего развития. Традиционно о системах качества говорят в применении к предприятиям, производящим "вещи". Предприятия же, оказывающие услуги или продающие результаты интеллектуального труда, формально тоже могут быть проанализированы в терминах стандарта ISO-9000. Термин система качества мы понимаем в следующем смысле: Система качества это совокупность организационных структур, ответственности, процедур и ресурсов, направленных на административное управление качеством.
Для того чтобы можно было говорить о построении системы качества на предприятии, разрабатывающем программное обеспечение, необходимо, как минимум, пройти этап "конвейерной" организации труда.
Разработка программ - это инженерная деятельность, поэтому применять слово конвейер можно лишь с оговорками, точно определив, что имеется в виду.
Фирма ЕМЕ создавалась в 1991 году как предприятие-разработчик заказного программного обеспечения и с тех пор продолжает работать в этой отрасли, постоянно наращивая интеллектуальный и рыночный потенциал. С самого начала работы руководство фирмы поставило перед собой задачу создать технологию разработки программ. Тогда эта задача представлялась вполне заурядной организационной проблемой, решение которой известно из литературы, описывающей работу зарубежных аналогичных фирм, а также из опыта работы советских НИИ. Сегодня, оглядываясь на пройденный путь, хорошо видно, что скопировать чужой организационный опыт практически невозможно. Создание технологии, которую сегодня мы называем "конвейер", потребовало шесть лет целенаправленных усилий. Фирма в своем развитии прошла все этапы организационной иерархии, и, по-видимому, пропустить какие-нибудь этапы едва ли было возможно. Финансовое развитие разных фирм может происходить по разному: одни могут делать "финансовый рывок" и концентрировать большие капиталы в сжатые сроки, другие накапливают "рубль к рублю" в течение десятилетий, третьи прекращают свое существование, не выдержав конкурентной борьбы. Что же касается их организационного развития, все проходят примерно один и тот же путь, также как и люди, вне зависимости от их происхождения и социального становления, развиваются от детства к юношеству и дальше - к зрелости и старости.
В данной статье не раскрываются подробно отличительные признаки различных этапов организационного развития предприятий. Мы лишь попытаемся рассказать о тех усилиях, которые фирма ЕМЕ предпринимает для достижения почти недостижимого идеала "Система Качества". Профессионалы консалтинга и реинжениринга утверждают, что число фирм во всем мире, достигших этого организационного уровня - едва ли насчитывает несколько сотен! Было бы нескромно претендовать на членство в ряду корифеев качества, таких как Sony или Тоета.
Часть 1. Конвейер - предпосылка для создания системы качества
Если анализировать историю технологического развития различных отраслей промышленности, то нетрудно увидеть одну любопытную закономерность. Всякий раз построение новой организационной структуры в технологии сопровождалось, или, что будет точнее, вызывалось каким-либо техническим нововведением или изобретением.
Построение конвейера в автомобильной промышленности последовало практически сразу же за изобретением самого автомобиля. Это факт довольно удивительный, если его сопоставлять с четырьмя-пятью сотнями лет кустарного "каретостроения", предшествующего автомобилестроению. При этом конструкция ходовой части первых автомобилей полностью заимствована из конструкции "гужевых" повозок тех дней.
Еще более занимательными сегодня представляются попытки превратить в технологию телефонию 20-30-ых годов нынешнего (еще 20-ого) столетия. "Технология" подбора девушек-телефонисток по психологическим и эргономическим тестам (с применением идей великого Фрейда!), "технология" движений рук при втыкании штекера в гнездо, толстые тома инструкций, которые "регламентировали" ответы на шутки телефонных хулиганов и прочие чудеса инженерного гения. Технология не получилась до тех пор, пока не был изобретен электромеханический шаговый искатель.
Попытки фирмы ЕМЕ превратить в технологию "традиционную" технику разработки программ в группах программистов (которую мы "с высоты" нынешнего уровня развития называем кустарной) никогда не прекращались и до 1998 года были сколь упорными, столь и безуспешными. "Ты, Иван Иваныч, будешь разрабатывать только отчеты, а ты, Петр Петрович, будешь заниматься только бухгалтерией". Попытки такого рода можно сравнить с бессмертным Крыловским: "Ты, Мишенька, садись против альта, а я, пожалуй, сяду против вторы…".
Еще одна организационная структура, которую фирма ЕМЕ прошла на пути к конвейеру называлась (отчасти в шутку) "Живительная сила". Основная идея "живительной силы" заключалась в предоставлении максимальной организационной свободы руководителю группы программистов. По существу, руководитель группы становился самостоятельным (в какой-то мере) предпринимателем. Он участвовал в переговорах, определял стоимость работ, формировал техническое задание, брал на работу программистов, начислял их и свою заработную плату и так далее. Фонд заработной платы определялся бюджетом проекта, так что руководитель мог платить себе очень большую зарплату при условии высокой эффективности работы группы. Название "живительная сила" означало, что под "живительными лучами", то есть деньгами заказчиков, будут вырастать хорошие группы и отмирать плохие, задача руководства - только осуществлять отбор. Независимость руководителя должна была обеспечить свободу его организационных решений - что лучше делать, поручать работу малому числу дорогих профессионалов или большому числу неопытных новичков, поручать один проект одному-двум программистам или делить все работы на всех членов группы и так далее.
Подобная организационная структура не нова и широко применяется в крупных корпорациях в том или ином виде. В нашем случае это "не сработало". Эксперименты по отбору хороших надо было ставить на реальных клиентах, подрывая собственное реноме фирмы в случае "плохих" руководителей. Как выяснилось, далеко не все технические руководители готовы к самостоятельной работе. Некоторые под грузом ответственности не могут принимать решений, другие жадничают и перестают платить подчиненным зарплату, третьи пускают работу на самотек…
Также как и в классических случаях из истории технологии, переход к конвейеру на фирме ЕМЕ связан с серьезным техническим нововведением (можно сказать изобретением). В 1998 году был разработан новый интерфейс системы управления базами данных. Он ориентирован на Windows-95/98/NT и называется "Трехслойный пользовательский интерфейс". Детальное описание возможностей этой конструкции не входит в задачу данной статьи, лишь одна существенная деталь будет нас интересовать. Конструкция интерфейса предлагает обширные возможности для визуального конструирования диалогов и отчетов. Эта вещь в современных базах данных вполне привычна. Особенностью же является следующее: к каждому органу диалога (полю ввода или кнопке), а также к каждой колонке или ячейке или запросу отчета, можно привязать внешнюю программу на С++. Для этого достаточно задать имя библиотеки DLL и точку входа в этой библиотеке.
Эта особенность сама по себе разрешает фундаментальное противоречие: желание объединить визуальное конструирование с применением компилируемого кода. Высокое качество программного изделия не может быть достигнуто с применением интерпретируемого (то есть не компилируемого) программного кода. С другой стороны, требования открытости, гибкости и быстроты программирования легче всего достигнуть, применяя визуальные средства конструирования систем. (Автор отдает себе отчет в спорности данного тезиса, поэтому можно рассматривать его лишь как мнение.)
Совместив, таким образом, в единой конструкции визуальное и низкоуровневое программирование, мы создали серьезную предпосылку для создания программистского конвейера. Стало возможным жестко организационно отделить конструирование систем (мы называем этот процесс "сборка системы") от разработки алгоритмов на языке программирования. "Конструкторы систем" (постановщики задач) и "прикладные программисты" (те, кто собирает и внедряет готовые проекты) вообще могут не уметь программировать в общепринятом смысле этого слова.
Очевидно, что простое разделение труда еще не конвейер. Заказные проекты характерны наличием еще одного фундаментального противоречия, которое удалось разрешить фирме ЕМЕ. Это противоречие между уникальностью изделий и их функциональной насыщенностью. Нельзя разрабатывать "с нуля" проект за проектом. Это противоречит самой сути термина "технология". "Технологичность" это "повторяемость", это "развитие и усложнение на основе точной и дешевой повторяемости". Технологичность в заказных проектах фирмы ЕМЕ обеспечивает Метапроект.
Мы уже говорили, что основную алгоритмическую нагрузку в системах ЕМЕ несут функции, которые подключаются к диалогам, отчетам и запросам. Эти функции при подключении к диалогу настраиваются на имена диалогов, органов диалогов, колонок отчетов, имена таблиц и полей базы данных. Таким образом, функция не ориентируется на определенный проект. Она работает с именами на русском языке. Эта система имен в совокупности составляет некую вербальную модель той части реального мира, который когда-либо автоматизировала фирма ЕМЕ. Функции накапливаются в библиотеках в качестве овеществленного интеллектуального потенциала фирмы. Множество всех таких функций в совокупности с обобщенной структурой банка данных и системой имен диалогов, печатных форм и запросов и называется "Метапроект".
Метапроект возник по вполне объективным причинам. Когда число проектов фирмы ЕМЕ перевалило за 50, в них накопилось большое количество интересных механизмов, коммерческих и технических решений, учетных и управленческих подсистем. Демонстрируя потенциальным клиентам различные проекты, в которых эти "изюминки" были реализованы, мы обещали реализовать эти механизмы в новых проектах. На практике же, перенос программного кода из одного проекта в другой был практически невозможен. Логические противоречия в структурах данных, расхождения в именах, в интерфейсах, приводили к тому, что перенос узлов из одного проекта в другой по стоимости был соизмерим с разработкой тех же механизмов заново.
Сегодня организационно метапроект представляет собой отдел, который называется "Группа метапроекта". Главная задача отдела - выполнять разработку новых функций (по заявкам группы прикладных программистов) так, чтобы они органично вписывались в обобщенную структуру имен, так чтобы названия, система параметров и количество функций были бы "естественны" для прикладных программистов. Так например, максимум усилий прилагается для того, чтобы число внешних имен функций (точек входа) было как можно меньше, а сложность выполняемых действий каждой функции была бы как можно выше. Это позволяет прикладному программисту подключать одну и ту же "умную" функцию в большом диапазоне приложений. Уменьшается число ошибок на этапе сборки систем, уменьшается объем знаний, которым должен обладать прикладной программист.
Часть 2. Элементы системы качества
Однако мы отклонились от основной темы - Системы качества. На рисунке показан полный производственный цикл разработки заказного программного обеспечения на фирме ЕМЕ. На каждом этапе применяются свои методы обеспечения качественной работы: качество будущего программного изделия и качество обслуживания клиентов. По большому счету здесь мы не изобрели ничего нового: формализация отношений с клиентом (подробное техническое задание и письменные заявки на доработки), кружки качества, тестирование узлов на предмет несоответствия техническому заданию и наличие ошибок, документирование технологии и написание подробных технологических инструкций. Главное, что должно быть присуще любой системе качества - это неформальность подхода. Усилия руководства должны быть направлены на то, чтобы постоянно искоренять причины будущих ошибок, а не бороться с уже имеющимися. Анализ ошибок в программах и сбоев в обслуживании должен постоянно порождать новые организационные и методические решения, которые блокировали бы аналогичные проявления в будущем. Был такой анекдот в советские времена: "Есть два вида гарантии - японская и советская, первая гарантирует, что "не сломается", а вторая - что "починим". Система качества должна постепенно подводить предприятие к "японской гарантии".
2.1 Качество маркетинга
Качество маркетинга определяется на первый взгляд очень легко - по наличию или отсутствию заказов. Однако не следует забывать, что реноме фирмы, ее точная позиция на рынке играет более важную роль, чем массированная реклама. Любая финансовая пирамида, опирающаяся на положительную обратную связь "реклама <--> сбыт" без реального качества изделия, обязательно рухнет. Немало таких проектов реализуется в настоящее время и в области информационных технологий.
Механизмы по обеспечению качества маркетинга традиционные - обучение специалистов, обмен опытом, подготовка инструкций, хорошая техническая оснащенность специалистов, проводящих презентации.
2.2 Качество конструирования систем
Конструированием систем на фирме ЕМЕ занимается отдел генерального конструктора. Конструирование систем в нашем понимании включает в себя предпроектное обследование, постановку задачи (в некотором смысле "миниконсалтинг"), предварительное и подробное техническое задание.
Работа конвейера начинается с презентации потенциальному клиенту различных проектов, которые разрабатывала фирма ЕМЕ. Это - нулевой этап конвейера.
Следующий этап - подготовка предварительного технического задания, коммерческого предложения и проекта договора. Данный этап выполняют программисты-конструкторы из отдела генерального конструктора. Это специалисты высокой квалификации, хорошо владеющие предметной областью, способные оценить в целом состояние дел на предприятии заказчика и выработать стратегию разработки и внедрения будущей системы. Для подготовки предварительного технического задания, программист-конструктор выезжает на предприятие заказчика и собирает данные для постановки задачи. Предварительное техническое задание - это небольшой по объему документ (обычно 20-30 страниц), который закладывает фундамент будущего проекта. В нем дается общее описание структуры проекта, перечень выполняемых функций, перечень основных бизнес-процессов. На основании предварительного технического задания готовится проект договора с точными сроками исполнения и стоимостью всех работ.
Следующий этап конвейера, который наступает после согласования договора и предварительного технического задания - подробное техническое задание. Его готовят также программисты-конструкторы. Подробное техническое задание представляет собой точное и формальное описание проекта. Оно содержит все диалоги и печатные формы программных модулей, подробное описание алгоритмов обработки данных и реакций на запросы операторов. Объем подробного технического задания составляет 300-500 листов. Работа по его подготовке - настоящее технологическое произведение искусств. Два конструктора в течение 3-5 недель успевают выполнить детальное обследование предприятия заказчика и подготовить столь объемный документ! Эта работа может быть выполнена в столь сжатые сроки лишь благодаря применению механизированных методов формирования документации: специальная база данных заготовок описания модулей и формальный синтез текста по заранее заготовленной программе вопросов.
Наиболее крупные проекты выполняются фирмой ЕМЕ совместно с консалтинговыми фирмами, оказывающими услуги по реинженирингу предприятий, включая полную автоматизацию. Ведущей фирмой в этой отрасли мы считаем фирму Риккон.
Элементы системы качества, реализованные на этапе конструирования:
Кружки качества собираются один раз в неделю. Кружок качества представляет собой цеховое совещание, на котором специалисты могут совместно обсудить выявленные ошибки, проанализировать сложные проблемы, передать друг другу опыт выполненных разработок. Дух кружка качества, характер обсуждения соответствуют требованиям предъявляемым к совещаниям "мозговой штурм". Именно поэтому в рамках кружков качества проводятся мозговые штурмы наиболее сложных новых конструкторских задач.
2.3 Сборка систем, качество работы прикладных программистов
Подробное техническое задание передается в группу прикладных программистов. Особенность работы конструкторов на фирме ЕМЕ заключается в том, что все рисунки диалогов и печатных форм выполняются в среде проектирования ЕМЕ-ДБ, и в готовом виде переносятся в текст технического задания. Благодаря этому, к моменту окончания конструирования у прикладных программистов имеются все заготовки программных модулей. Их работа по сборке системы заключается "лишь" в привязке диалогов и отчетов к базе данных и подключении функций из библиотек метапроекта.
Благодаря усилиям группы метапроекта объем повторно используемого программного кода в проектах фирмы ЕМЕ достигает 60-80 процентов и постепенно, с развитием метапроекта, увеличивается. Разработка новых функций метапроекта выполняется по заявкам прикладных программистов. Заявка заполняется прикладным программистом в соответствии с утвержденной формой всякий раз, когда он встречает в техническом задании такой алгоритм обработки данных, который он не может найти в базе данных метафункций.
Таким образом, происходит так называемое "вытягивание" элементов системы одним отделом из другого:
При этом происходит контроль качества идей и конструкций (формализованных в заявках) на каждом этапе передачи запроса, а затем при возврате готового узла или изделия происходит тестирование на предмет соответствия заявке и наличия ошибок.
Все узлы и проекты в целом обязательно проходят тестирование в отделе тестирования. Хорошо известно, что обычный программист в силу своей психологии не способен выполнить качественное тестирование своей собственной работы. Конвейерное разделение труда легко устраняет этот недостаток. Профессиональные тестировщики в считанные секунды выявляют типовые ошибки и путем тщательного анализа находят все дефекты алгоритмов обработки данных.
Типичное время, расходуемое на сборку и тестирование систем, составляет 2-3 месяца. Еще в процессе сборки (по прошествии 1.5-2 месяцев) начинается инсталляция отдельных модулей на предприятии заказчика. Это позволяет начать обучение и заполнение полупостоянной базы данных (справочников), так чтобы к моменту окончания сборки можно было немедленно приступить к опытной эксплуатации системы (еще 2-3 месяца). Ответственность за качество программного продукта, обучения и оперативности внесения исправлений и доработок при опытной эксплуатации лежит на группе прикладных программистов.
Одним из важнейших элементов системы качества является точно определенный формальный протокол взаимодействия программистов с сотрудниками предприятия-заказчика. Можно с уверенностью сказать, что 70 процентов проблем, возникающих при внедрении программ кустарного производства, вызваны отсутствием четко определенных отношений с клиентом.
В работе прикладных программистов применяется несколько протоколов, регламентирующих работу с клиентами:
Протокол внесения изменений в техническое задание и готовые программы.
| Название этапа | Документ | Кто подписывает? |
|---|---|---|
| Начало сборки системы | Подробное техническое задание | Руководитель проекта от заказчика и главный конструктор от ЕМЕ |
| Внедрение, обучение, опытная эксплуатация, сопровождение | Заявка на доработку программ или внесение изменений | Сотрудник и руководитель проекта от заказчика, руководитель проекта от ЕМЕ |
| Опытная эксплуатация, сопровождение (после получения заявки на новую подсистему) | Частное техническое задание (в ответ на заявку, требующую значительных объемов работ) | Руководитель проекта от ЕМЕ, руководитель проекта от заказчика |
Протокол внедрения готового проекта и начало работы.
| Название этапа | Документ | Кто подписывает? |
|---|---|---|
| Инсталляция модулей справочников, заполнение полупостоянной базы данных | Извещение о начале работ, список и объем данных, которые должны быть введены в базу данных | Руководитель проекта от ЕМЕ и руководитель проекта от заказчика, копия передается руководителю предприятия заказчика |
| Обучение сотрудников предприятия-заказчика | Расписание занятий с точным указанием тем, дат и часов, список участников | Готовит прикладной программист, подписывает руководитель проекта от заказчика (иногда руководитель предприятия) |
| Запуск системы в опытную эксплуатацию, сопровождение | Извещение о завершении работ, список рабочих мест, фамилии операторов | Руководитель проекта от ЕМЕ, руководитель проекта от заказчика |
Протокол выезда прикладного программиста к клиенту с готовым модулем.
| Название этапа | Документ | Кто подписывает? |
|---|---|---|
| Завершена сборка программного модуля системы | Заполнение паспорта модуля, передача на тестирование в отдел тестирования | Разрешение на инсталляцию ("ошибок нет") подписывает тестировщик |
| Выезд к клиенту с готовым программным модулем или подсистемой | Разрешение на выезд к клиенту | Прикладной программист, тестировщик, руководитель проекта, начальник отдела прикладных программистов |
| Работа на площадке у клиента | Справка о качестве выполненных работ | Руководитель проекта от клиента или представитель клиента, принявший работу |
Очевидно, что эти таблицы - лишь примерное описание порядка взаимодействия, который регламентируется подробными инструкциями.
Ниже приводится перечень элементов системы качества, реализованных на "прикладном" этапе конвейера:
В кружках качества прикладных программистов анализируются не только ошибки в работе. До сих пор мы обходили вопрос качества собственно программного продукта. Данный вопрос сложен. Несмотря на обилие литературы, посвященной ему, можно с уверенностью сказать, что формальная метрология качества творческой работы (каковой является и программирование) не может всерьез обсуждаться. "Хорошая программа" это: быстродействие, надежность, эргономика (почти не определяемое понятие!), сегодняшняя "мода" на интерфейс человек-машина, реализация всех современных методов визуализации данных (графики, диаграммы, интерактивные методы построения отчетов и запросов), функциональная полнота с точки зрения конкретного заказчика, гибкость по отношению к будущему развитию и масштабированию системы в целом. Можно привести тысячу параметров, которые принципиально не могут быть измерены, и для которых невозможно однозначно указать являются они "первичными" или второстепенными в данном конкретном проекте. Вместе с тем, отсутствие надежной метрологии не может служить оправданием для выпуска некачественных изделий. Именно кружки качества прикладных программистов позволяют в коллективном обсуждении увидеть дефекты и достижения. Обмен опытом и наставничество, стремление к мастерству каждого инженера, выработка духа нетерпимости к халатной работе и гордости за свой труд - вот на наш взгляд реальный механизм качества в любой творческой работе.
2.4 Качество разработки алгоритмов метафункций
Качество работы группы метапроекта уже затрагивалось частично при анализе работы других отделов. Хорошо известно главное противоречие коллективной работы программистов: программный код общий для нескольких проектов должен быть "вынесен за скобки" - собран в одном месте вне всех проектов, но в этом случае соответствующие программы должны обслуживаться особо. Их нельзя модифицировать, не произведя полного тестирования всех проектов, использующих этот код. В большинстве случаев программисты предпочитают отказаться от использования общих библиотек, лишь бы не ограничивать свободу действий. Если программистов формально принуждать работать в рамках общих библиотек, то они начинают применять обходной маневр - разрабатывают все время новые функции и помещают их в библиотеки под новыми именами. Бесконечное многообразие подобных друг другу программ плодится под разными именами, каждая для своего проекта, со своими ошибками и отсутствием документации. Библиотека превращается в свалку и постепенно умирает.
Решений у этой проблемы два:
1) Разработать интерфейс взаимодействия программных модулей друг с другом, так чтобы можно было разрабатывать и модифицировать различные части (различных) систем независимо. Интерфейс должен иметь формальное описание, что позволит оформить его в качестве стандарта. В этом случае можно обеспечить (хотя бы формально) при модификации и развитии библиотек их совместимость с предыдущими версиями стандартных интерфейсов. И, следовательно, работоспособность систем, уже использующих библиотеки.
2) Организационно построить работу так, чтобы библиотеки не мог модифицировать "кто попало". Поручить разработку библиотечных функций ограниченной группе программистов. Эта группа, работая по заявкам других программистов, была бы заинтересована в поддержании логической целостности библиотеки. В самом деле, хорошо зная ее структуру и конструкцию узлов (что невозможно сделать общим достоянием), программистам было бы "выгоднее" развивать уже имеющиеся модули, чем плодить новые. Это особенно верно в отношении объектно-ориентированного программирования, которое славится своей пригодностью к развитию, но только при одном условии - хорошем знании разработчиком всех особенностей и конструкции применяемых классов.
Два эти подхода вовсе не противоречат друг другу, их одновременное использование увеличивает преимущества обоих. Так мы и поступили при построении метапроекта.
Как мы уже говорили, естественная (то есть на русском языке) система имен обобщенной структуры данных метапроекта, вместе с именами диалогов, отчетов, запросов, органов диалогов и ячеек отчетов представляет собой единый интерфейс для взаимодействия всех программ метапроекта друг с другом и с прикладными системами. Этот интерфейс хорошо задокументированы и представляет собой корпоративный стандарт ЕМЕ.
За развитие и логическую целостность метапроекта отвечает руководитель группы метапроекта (его официальная должность на фирме ЕМЕ - главный инженер). Все изменения в старых функциях и разработка новых инициируются прикладными программистами. Взаимодействие прикладных и мета- программистов строго регламентировано. Информация по метафункциям хранится в специальной базе данных и "устное" общение между группами запрещается. Все заявки подаются только в письменном виде. Ответ по заявке - тоже только письменно. В ответе может быть только указан адрес требуемой функции в библиотеке (это может быть новая или уже имеющаяся функция, которую неопытный прикладной программист не смог найти).
Жесткая регламентация взаимоотношений между отделами заставляет программистов постоянно повышать качество документации и прозрачность структуры библиотеки, вместо того, чтобы постоянно отвечать устно на одни и те же вопросы.
Не следует думать, что развитие метапроекта это медленная и бюрократическая процедура. Обычно в разработке на фирме ЕМЕ находится от 5 до 15 проектов одновременно. Заявки на накачку библиотек из отдела прикладных проектов идут потоком - десятки заявок в день. Технология метапроекта позволяет не только легко справляться с этим потоком, но и более того, постоянно уменьшать его за счет накопления функционального разнообразия, увеличения диапазона применимости одних и тех же функций. Метапроект поистине стал овеществленным опытом прикладных разработок фирмы.
Метапроект позволил перевести экстенсивное развитие предприятия на интенсивные промышленные рельсы. Несомненно также и то, что нынешнее экстенсивное развитие самого метапроекта в ближайшее время (один-два года) потребует перехода к интенсивным методам управления сложностью, "механизации" и организационному структурированию внутри группы.
Кружки качества в метагруппе необходимы для обмена рабочей информацией между программистами, для коллективного анализа программных ошибок и качества исходных текстов, для почти постоянных мозговых штурмов. Увязка в единую логическую систему самых разнообразных (и зачастую противоречивых) требований идущих от множества проектов - задача чрезвычайно сложная.
Как и в других элементах системы качества, базис для построения качественного продукта на уровне метапроекта предоставляет СУБД ЕМЕ-ДБ. Базы данных ЕМЕ-ДБ имеют глубокую реляционную структуру, что легко достигается за счет использования механизма ссылок с прямыми физическими связями. Это означает, что связанные таблицы хранят в ссылках помимо ключа (который играет вспомогательную роль) физический номер записи в ссылаемой таблице (в ЕМЕ-ДБ термин "запись" заменен термином "строка", "таблицы" называются "записями"). Вообще ЕМЕ-ДБ классифицируется как "синхронные базы данных класса RISC". Термин "синхронные" означает наличие дублирующего банка данных на локальном диске каждой рабочей станции, термин RISC означает "сокращенный набор команд для доступа к данным и прямые реляционные связи". Эти механизмы позволяют легко строить обобщенную логически непротиворечивую структуру данных метапроекта, в которой ликвидируются ссылочные тавтологии вплоть до четвертого уровня (можно было бы вообще ликвидировать ссылочные тавтологии, но в целом ряде случаев это оказывается неоправданным с точки зрения быстродействия). Это обусловливает весьма компактное хранение данных.
На фирме ЕМЕ-ДБ применяется термин "программное ребро жесткости". Ребра жесткости - это специальные механизмы, обеспечивающие контроль целостности данных. Ядро ЕМЕ-ДБ содержит десятки ребер жесткости, гарантирующих физическую целостность данных. Универсальность структуры данных метапроекта по отношению ко всем прикладным проектам фирмы ЕМЕ позволяет строить ребра жесткости, гарантирующие логическую целостность данных. Одним из таких механизмов является так называемый "чмутинг". Это программная утилита, которая вычисляет денежные и товарные обороты и сравнивает значения текущих и начальных счетчиков (регистров) с вычисленными оборотами для всех товаров и клиентов базы данных. Чмутинг позволяет мгновенно выявлять не только логические (прикладные программные) ошибки, но также и блокирует несанкционированное "ручное" вторжение в банк данных. Разработка логических универсальных ребер жесткости - прерогатива метапроекта.
Таким образом, качество на уровне метапроекта достигается применением следующих мероприятий:
2.5 Качество ядра базы данных
Развитием ядра базы данных занимается так называемая "ядерная" группа. Тактические и стратегические планы развития ядра ЕМЕ-ДБ расписаны как минимум на два года вперед.
Качество ядерного программного кода легко подается традиционной метрологии качества программных продуктов: быстродействие и надежность, структурированность и открытость исходных текстов.
Качество системы управления базами данных определяется, прежде всего, качеством фундаментальных идей, заложенных в конструкцию. Реализация также важна, но в силу специфики, ядерные разработки имеют более широкую возможность для длительной доводки и "углубления" алгоритмической проработки узлов.
Кратко перечислим технические характеристики СУБД ЕМЕ-ДБ:
Полное перечисление заняло бы неоправдано много места, кроме того, технические характеристики, хотя и влияют на качество готовых изделий, не могут быть однозначно отнесены к элементам системы качества.
Традиционные механизмы контроля качества присутствуют в работе ядерной группы:
2.6 Отдел тестирования
Отдел тестирования - это прямые вложения в качество. Отдел тестирования цементирует работу всего конвейера. Каждый модуль каждого проекта при создании снабжается так называемым "паспортом модуля", в котором ведется подробная история разработки, тестирования, модификаций и повторного тестирования данного узла. Ни один модуль не может быть отвезен к заказчику без тестирования и без подписи тестировщика в паспорте модуля и заявке на выезд к клиенту. Никакая модификация не может быть заказана клиентом без письменной заявки, которая регистрируется в паспорте соответствующего модуля.
Ни один модуль не принимается на тестирование, если в нем "кривое" расположение органов (то есть некачественный дизайн диалогов или отчетов), если отсутствует полная справка-помощь или контекстные справки для органов диалогов.
Программисты-тестировщики, следуя подробному техническому заданию, проходят по всем описанным бизнес-процессам и выполняют все операции предусмотренные соответствующими модулями. Сверяются результаты операций с текущими значениями постоянно-хранимых регистров.
Качество работы самого отдела тестирования анализируется в кружках качества. Программисты-тестировщики обмениваются опытом поиска типичных ошибок, готовят списки часто повторяющихся ошибок для рассмотрения в кружках качества других отделов, тщательно анализируют ошибки, пропущенные при тестировании и достигшие заказчика.
Заключение. Гарантийные обязательства - вершина системы качества
Построение системы качества - это достижение совершенства: чем ближе ты подходишь к совершенству, тем более недостижимым оно видится. Это непрерывный процесс, требующий усилий, концентрации, "просветления". Фирма должна начать действовать как единое целое. Нельзя просто внедрить систему качества, можно лишь выработать систему "упражнений", при помощи которых фирма, действующая как единый организм, может самосовершенствоваться.
Благодаря внедрению системы качества на предприятии, соотношение цены и качества выпускаемых изделий повышается, так что зачастую в десятки раз превосходит конкурентов. Опыт фирмы ЕМЕ еще слишком скромен, чтобы ее организационную структуру уже сегодня можно было бы назвать "Система качества". Однако пройден значительный путь, отделяющий нас от кустарного производства, и с этого пути мы не намерены сворачивать.
Одним из показателей качества является гарантия, которую фирма разработчик дает на свои изделия. Фирма ЕМЕ при реализации проектов берет на себя следующие гарантийные обязательства: