2.4 Качество разработки алгоритмов метафункций


Качество работы группы метапроекта уже затрагивалось частично при анализе работы других отделов. Хорошо известно главное противоречие коллективной работы программистов: программный код общий для нескольких проектов должен быть “вынесен за скобки” - собран в одном месте вне всех проектов, но в этом случае соответствующие программы должны обслуживаться особо. Их нельзя модифицировать, не произведя полного тестирования всех проектов, использующих этот код. В большинстве случаев программисты предпочитают отказаться от использования общих библиотек, лишь бы не ограничивать свободу действий. Если программистов формально принуждать работать в рамках общих библиотек, то они начинают применять обходной маневр – разрабатывают все время новые функции и помещают их в библиотеки под новыми именами. Бесконечное многообразие подобных друг другу программ плодится под разными именами, каждая для своего проекта, со своими ошибками и отсутствием документации. Библиотека превращается в свалку и постепенно умирает.

Решений у этой проблемы два:

1. Разработать интерфейс взаимодействия программных модулей друг с другом, так чтобы можно было разрабатывать и модифицировать различные части (различных) систем независимо. Интерфейс должен иметь формальное описание, что позволит оформить его в качестве стандарта. В этом случае можно обеспечить (хотя бы формально) при модификации и развитии библиотек их совместимость с предыдущими версиями стандартных интерфейсов. И, следовательно, работоспособность систем, уже использующих библиотеки.

2. Организационно построить работу так, чтобы библиотеки не мог модифицировать “кто попало”. Поручить разработку библиотечных функций ограниченной группе программистов. Эта группа, работая по заявкам других программистов, была бы заинтересована в поддержании логической целостности библиотеки. В самом деле, хорошо зная ее структуру и конструкцию узлов (что невозможно сделать общим достоянием), программистам было бы “выгоднее” развивать уже имеющиеся модули, чем плодить новые. Это особенно верно в отношении объектно-ориентированного программирования, которое славится своей пригодностью к развитию, но только при одном условии – хорошем знании разработчиком всех особенностей и конструкции применяемых классов.

Два эти подхода вовсе не противоречат друг другу, их одновременное использование увеличивает преимущества обоих. Так мы и поступили при построении метапроекта.

Как мы уже говорили, естественная (то есть на русском языке) система имен обобщенной структуры данных метапроекта, вместе с именами диалогов, отчетов, запросов, органов диалогов и ячеек отчетов представляет собой единый интерфейс для взаимодействия всех программ метапроекта друг с другом и с прикладными системами. Этот интерфейс хорошо задокументированы и представляет собой корпоративный стандарт ЕМЕ.

За развитие и логическую целостность метапроекта отвечает руководитель группы метапроекта (его официальная должность на фирме ЕМЕ – главный инженер). Все изменения в старых функциях и разработка новых инициируются прикладными программистами. Взаимодействие прикладных и мета- программистов строго регламентировано. Информация по метафункциям хранится в специальной базе данных и “устное” общение между группами запрещается. Все заявки подаются только в письменном виде. Ответ по заявке – тоже только письменно. В ответе может быть только указан адрес требуемой функции в библиотеке (это может быть новая или уже имеющаяся функция, которую неопытный прикладной программист не смог найти).

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

Не следует думать, что развитие метапроекта это медленная и бюрократическая процедура. Обычно в разработке на фирме ЕМЕ находится от 5 до 15 проектов одновременно. Заявки на накачку библиотек из отдела прикладных проектов идут потоком – десятки заявок в день. Технология метапроекта позволяет не только легко справляться с этим потоком, но и более того, постоянно уменьшать его за счет накопления функционального разнообразия, увеличения диапазона применимости одних и тех же функций. Метапроект поистине стал овеществленным опытом прикладных разработок фирмы.

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

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

Как и в других элементах системы качества, базис для построения качественного продукта на уровне метапроекта предоставляет СУБД ЕМЕ-ДБ. Базы данных ЕМЕ-ДБ имеют глубокую реляционную структуру, что легко достигается за счет использования механизма ссылок с прямыми физическими связями. Это означает, что связанные таблицы хранят в ссылках помимо ключа (который играет вспомогательную роль) физический номер записи в ссылаемой таблице (в ЕМЕ-ДБ термин “запись” заменен термином “строка”, “таблицы” называются “записями”). Вообще ЕМЕ-ДБ классифицируется как “синхронные базы данных класса RISC”. Термин “синхронные” означает наличие дублирующего банка данных на локальном диске каждой рабочей станции, термин RISC означает “усеченный набор команд для доступа к данным и прямые реляционные связи”. Эти механизмы позволяют легко строить обобщенную логически непротиворечивую структуру данных метапроекта, в которой ликвидируются ссылочные тавтологии вплоть до четвертого уровня (можно было бы вообще ликвидировать ссылочные тавтологии, но в целом ряде случаев это оказывается неоправданным с точки зрения быстродействия). Это обусловливает весьма компактное хранение данных.

На фирме ЕМЕ-ДБ применяется термин “программное ребро жесткости”. Ребра жесткости – это специальные механизмы, обеспечивающие контроль целостности данных. Ядро ЕМЕ-ДБ содержит десятки ребер жесткости, гарантирующих физическую целостность данных. Универсальность структуры данных метапроекта по отношению ко всем прикладным проектам фирмы ЕМЕ позволяет строить ребра жесткости, гарантирующие логическую целостность данных. Одним из таких механизмов является так называемый “чмутинг”. Это программная утилита, которая вычисляет денежные и товарные обороты и сравнивает значения текущих и начальных счетчиков (регистров) с вычисленными оборотами для всех товаров и клиентов базы данных. Чмутинг позволяет мгновенно выявлять не только логические (прикладные программные) ошибки, но также и блокирует несанкционированное “ручное” вторжение в банк данных. Разработка логических универсальных ребер жесткости – прерогатива метапроекта.

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

  • Концентрация управления библиотеками в одной группе
  • Ответственность руководителя метапроекта за все составляющие качества
  • Жесткая регламентация взаимоотношений между отделами, искоренение “изустной” технологи работы
  • Входной контроль качества заявок от прикладных программистов, двойное тестирование новых метафункций (первое тестирование выполняют прикладные программисты, второе – отдел тестирования в составе проекта)
  • Построение вербальной модели автоматизируемого внешнего мира в терминах имен структуры данных, имен диалогов, отчетов и проч. Стандартизация этой модели в качестве единого межмодульного программного интерфейса
  • Логические универсальные ребра жесткости
  • Кружки качества

Смотрите также…