Советская система производства

Система свойства, конвейерное создание заказного программного обеспечения

СИСТЕМА Свойства
Конвейерное создание заказного программного обеспечения

© "Инженер Мареев Интерпрайсиз"

Введение. Систематизация организационных структур и разработка творческой работы
Часть 1. Сборочный поток - предпосылка для сотворения системы свойства
Часть 2. Элементы системы свойства
2.1 Качество маркетинга
2.2 Качество конструирования систем
2.3 Сборка систем, качество работы прикладных программистов
2.4 Качество разработки алгоритмов метафункций
2.5 Качество ядра базы данных
2.6 Отдел тестирования
Заключение. Гарантийные обязательства - верхушка системы свойства

Введение. Систематизация организационных структур и разработка творческой работы

Одна из шуточных иерархий развития производства (бизнеса) систематизирует организационную структуру по возрастанию "организованности" последующим образом:

• Тусовка
• Артель
• Мануфактура
• Сборочный поток
• Система свойства

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

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

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

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

Компания ЕМЕ создавалась в 1991 году как предприятие-разработчик заказного программного обеспечения и с того времени продолжает работать в этой отрасли, повсевременно наращивая умственный и рыночный потенциал. С самого начала работы управление компании поставило впереди себя задачку сделать технологию разработки программ. Тогда эта задачка представлялась полностью неиндивидуальной организационной неувязкой, решение которой понятно из литературы, описывающей работу забугорных подобных компаний, также из опыта работы русских НИИ. Сейчас, оглядываясь на пройденный путь, отлично видно, что скопировать чужой организационный опыт фактически нереально. Создание технологии, которую сейчас мы называем "сборочный поток", потребовало 6 лет целенаправленных усилий. Компания в собственном развитии прошла все этапы организационной иерархии, и, по-видимому, пропустить какие-нибудь этапы чуть ли было может быть. Финансовое развитие различных компаний может происходить по различному: одни могут делать "денежный рывок" и концентрировать огромные капиталы в сжатые сроки, другие копят "рубль к рублю" в течение десятилетий, третьи прекращают свое существование, не выдержав конкурентноспособной борьбы. Что все-таки касается их организационного развития, все проходят приблизительно один и тот же путь, также как и люди, вне зависимости от их происхождения и общественного становления, развиваются от юношества к юношеству и далее - к зрелости и старости.

В данной статье не раскрываются тщательно отличительные признаки разных шагов организационного развития компаний. Мы только попытаемся поведать о тех усилиях, которые компания ЕМЕ решает для заслуги практически недосягаемого эталона "Система Свойства". Мастера консалтинга и реинжениринга говорят, что число компаний в мире, достигших этого организационного уровня - чуть ли насчитывает несколько сотен! Было бы нескромно претендовать на членство в ряду корифеев свойства, таких как Sony либо Тоета.

Часть 1. Сборочный поток - предпосылка для сотворения системы свойства

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

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

Еще больше занятными сейчас представляются пробы перевоплотить в технологию телефонию 20-30-ых годов сегодняшнего (еще 20-ого) столетия. "Разработка" подбора девушек-телефонисток по психическим и эргономическим тестам (с применением мыслях величавого Фрейда!), "разработка" движений рук при втыкании штекера в гнездо, толстые тома инструкций, которые "регламентировали" ответы на шуточки телефонных хулиганов и остальные чудеса инженерного гения. Разработка не вышла до того времени, пока не был придуман электромеханический шаговый искатель.

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

Еще одна организационная структура, которую компания ЕМЕ прошла на пути к сборочному потоку называлась (частично в шуточку) "Животворная сила". Основная мысль "животворной силы" заключалась в предоставлении наибольшей организационной свободы руководителю группы программистов. По существу, управляющий группы становился самостоятельным (в некий мере) бизнесменом. Он участвовал в переговорах, определял цена работ, сформировывал техническое задание, брал на работу программистов, начислял их и свою зарплату и т.д.. Фонд зарплаты определялся бюджетом проекта, так что управляющий мог платить для себя очень огромную заработную плату при условии высочайшей эффективности работы группы. Заглавие "животворная сила" означало, что под "животворными лучами", другими словами средствами заказчиков, будут вырастать отличные группы и отмирать нехорошие, задачка управления - только производить отбор. Независимость управляющего должна была обеспечить свободу его организационных решений - что лучше делать, поручать работу малому числу дорогих экспертов либо большенному числу неопытных новичков, поручать один проект одному-двум программерам либо разделять все работы на всех членов группы и т.д..

Схожая организационная структура не нова и обширно применяется в больших корпорациях в том либо ином виде. В нашем случае это "не сработало". Опыты по отбору добротных было надо ставить на реальных клиентах, подрывая собственное реноме компании в случае "нехороших" управляющих. Как выяснилось, далековато не все технические руководители готовы к самостоятельной работе. Некие под грузом ответственности не могут принимать решений, другие скупятся и перестают платить подчиненным заработную плату, третьи пускают работу на самотек…

Также как и в традиционных случаях из истории технологии, переход к сборочному потоку на фирме ЕМЕ связан с суровым техническим нововведением (можно сказать изобретением). В 1998 году был разработан новый интерфейс системы управления базами данных. Он нацелен на Windows-95/98/NT и именуется "Трехслойный пользовательский интерфейс". Детализированное описание способностей этой конструкции не заходит в задачку данной статьи, только одна значимая деталь будет нас заинтересовывать. Конструкция интерфейса предлагает необъятные способности для зрительного конструирования диалогов и отчетов. Эта вещь в современных базах данных полностью привычна. Особенностью же является последующее: к каждому органу диалога (полю ввода либо кнопке), также к каждой колонке либо ячейке либо запросу отчета, можно привязать внешнюю программку на С++. Для этого довольно задать имя библиотеки DLL и точку входа в этой библиотеке.

Эта особенность сама по для себя разрешает базовое противоречие: желание соединить зрительное конструирование с применением компилируемого кода. Высочайшее качество программного изделия не может быть достигнуто с применением интерпретируемого (другими словами не компилируемого) программного кода. С другой стороны, требования открытости, гибкости и быстроты программирования легче всего добиться, применяя зрительные средства конструирования систем. (Создатель дает для себя отчет в спорности данного тезиса, потому можно рассматривать его только как мировоззрение.)

Совместив, таким макаром, в единой конструкции зрительное и низкоуровневое программирование, мы сделали суровую предпосылку для сотворения программистского сборочного потока. Стало вероятным агрессивно организационно отделить конструирование систем (мы называем этот процесс "сборка системы") от разработки алгоритмов на языке программирования. "Конструкторы систем" (постановщики задач) и "прикладные программеры" (те, кто собирает и вводит готовые проекты) вообщем могут не уметь программировать в принятом смысле этого слова.

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

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

Метапроект появился по полностью беспристрастным причинам. Когда число проектов компании ЕМЕ перевалило за 50, в их накопилось огромное количество увлекательных устройств, коммерческих и технических решений, учетных и управленческих подсистем. Показывая возможным клиентам разные проекты, в каких эти "изюминки" были реализованы, мы обещали воплотить эти механизмы в новых проектах. На практике же, перенос программного кода из 1-го проекта в другой был фактически неосуществим. Логические противоречия в структурах данных, расхождения в именах, в интерфейсах, приводили к тому, что перенос узлов из 1-го проекта в другой по цены был соизмерим с разработкой тех же устройств поновой.

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

Часть 2. Элементы системы свойства

Но мы отклонились от основной темы - Системы свойства. На рисунке показан полный производственный цикл разработки заказного программного обеспечения на фирме ЕМЕ. На каждом шаге используются свои способы обеспечения высококачественной работы: качество грядущего программного изделия и качество обслуживания клиентов. По сути тут мы не изобрели ничего нового: формализация отношений с клиентом (подробное техническое задание и письменные заявки на доработки), кружки свойства, тестирование узлов на предмет несоответствия техническому заданию и наличие ошибок, документирование технологии и написание подробных технологических инструкций. Главное, что должно быть присуще хоть какой системе свойства - это неформальность подхода. Усилия управления должны быть ориентированы на то, чтоб повсевременно искоренять предпосылки будущих ошибок, а не биться с уже имеющимися. Анализ ошибок в программках и сбоев в обслуживании должен повсевременно порождать новые организационные и методические решения, которые блокировали бы подобные проявления в дальнейшем. Был таковой смешной рассказ в русские времена: "Есть два вида гарантии - японская и русская, 1-ая гарантирует, что "не сломается", а 2-ая - что "починим". Система свойства должна равномерно подводить предприятие к "японской гарантии".

2.1 Качество маркетинга

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

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

2.2 Качество конструирования систем

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

Работа сборочного потока начинается с презентации возможному клиенту разных проектов, которые разрабатывала компания ЕМЕ. Это - нулевой шаг сборочного потока.

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

Последующий шаг сборочного потока, который наступает после согласования контракта и подготовительного технического задания - подробное техническое задание. Его готовят также программисты-конструкторы. Подробное техническое задание представляет собой четкое и формальное описание проекта. Оно содержит все диалоги и печатные формы программных модулей, подробное описание алгоритмов обработки данных и реакций на запросы операторов. Объем подробного технического задания составляет 300-500 листов. Работа по его подготовке - истинное технологическое произведение искусств. Два конструктора в течение 3-5 недель успевают выполнить детализированное обследование предприятия заказчика и приготовить настолько большой документ! Эта работа может быть выполнена в настолько сжатые сроки только благодаря применению механизированных способов формирования документации: особая база данных заготовок описания модулей и формальный синтез текста по заблаговременно заготовленной программке вопросов.

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

Элементы системы свойства, реализованные на шаге конструирования:

• Отдел генерального конструктора занимается только стратегическим планированием разработки и внедрения
• Подробное техническое задание содержит описание всех частей проекта прямо до полей ввода и колонок отчетов, имеет объем 300-500 страничек, готовится компанией ЕМЕ, подписывается заказчиком
• Совместная работа с консалтинговыми фирмами по мере надобности реинжениринга предприятия заказчика
• Входной контроль подробного технического задания прикладными программерами (на последующем шаге сборочного потока), выявление ошибок на шаге сборки системы и анализ ошибок на кружках свойства

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

2.3 Сборка систем, качество работы прикладных программистов

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

Благодаря усилиям группы метапроекта объем повторно применяемого программного кода в проектах компании ЕМЕ добивается 60-80 процентов и равномерно, с развитием метапроекта, возрастает. Разработка новых функций метапроекта производится по заявкам прикладных программистов. Заявка заполняется прикладным программером в согласовании с утвержденной формой каждый раз, когда он встречает в техническом задании таковой метод обработки данных, который он не может отыскать в базе данных метафункций.

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

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

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

Обычное время, используемое на сборку и тестирование систем, составляет 2-3 месяца. Еще в процессе сборки (по прошествии 1.5-2 месяцев) начинается установка отдельных модулей на предприятии заказчика. Это позволяет начать обучение и наполнение полупостоянной базы данных (справочников), так чтоб к моменту окончания сборки можно было немедля приступить к опытнейшей эксплуатации системы (еще 2-3 месяца). Ответственность за качество программного продукта, обучения и оперативности внесения исправлений и доработок при опытнейшей эксплуатации лежит на группе прикладных программистов.

Одним из важных составляющих системы свойства является точно определенный формальный протокол взаимодействия программистов с сотрудниками предприятия-заказчика. Можно с уверенностью сказать, что 70 процентов заморочек, возникающих при внедрении программ кустарного производства, вызваны отсутствием верно определенных отношений с клиентом.

В работе прикладных программистов применяется несколько протоколов, регламентирующих работу с клиентами:

Протокол внесения конфигураций в техническое задание и готовые программки.

Заглавие шагаДокументКто подписывает?
Начало сборки системыПодробное техническое заданиеУправляющий проекта от заказчика и главный конструктор от ЕМЕ
Внедрение, обучение, опытнейшая эксплуатация, сопровождениеЗаявка на доработку программ либо внесение конфигурацийСотрудник и управляющий проекта от заказчика, управляющий проекта от ЕМЕ
Опытнейшая эксплуатация, сопровождение (после получения заявки на новейшую подсистему)Личное техническое задание (в ответ на заявку, требующую значимых объемов работ)Управляющий проекта от ЕМЕ, управляющий проекта от заказчика

Протокол внедрения готового проекта и начало работы.

Заглавие шагаДокументКто подписывает?
Установка модулей справочников, наполнение полупостоянной базы данныхУведомление о начале работ, перечень и объем данных, которые должны быть введены в базу данныхУправляющий проекта от ЕМЕ и управляющий проекта от заказчика, копия передается руководителю предприятия заказчика
Обучение служащих предприятия-заказчикаРасписание занятий с четким указанием тем, дат и часов, перечень участниковГотовит прикладной программер, подписывает управляющий проекта от заказчика (время от времени управляющий предприятия)
Пуск системы в опытную эксплуатацию, сопровождениеУведомление о окончании работ, перечень рабочих мест, фамилии операторовУправляющий проекта от ЕМЕ, управляющий проекта от заказчика

Протокол выезда прикладного программера к клиенту с готовым модулем.

Заглавие шагаДокументКто подписывает?
Завершена сборка программного модуля системыНаполнение паспорта модуля, передача на тестирование в отдел тестированияРазрешение на установку ("ошибок нет") подписывает тестировщик
Выезд к клиенту с готовым программным модулем либо подсистемойРазрешение на выезд к клиентуПрикладной программер, тестировщик, управляющий проекта, начальник отдела прикладных программистов
Работа на площадке у клиентаСправка о качестве выполненных работУправляющий проекта от клиента либо представитель клиента, принявший работу

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

Ниже приводится список частей системы свойства, реализованных на "прикладном" шаге сборочного потока:

• Входной контроль свойства конструкции по подробному техническому заданию
• Узенькая специализация прикладных программистов - они не разрабатывают программ в обыкновенном смысле этого слова
• Сокращение сроков разработки за счет внедрения готовых метафункций
• Уменьшение числа ошибок в готовых системах за счет внедрения метафункций, прошедших обкатку в прошлых проектах
• Тестирование всех узлов и проектов в целом в отделе тестирования
• Четкие формальные протоколы отношений с клиентами и с другими отделами снутри ЕМЕ - существенное понижение воздействия людского фактора
• Полный отказ от модификации систем и программирования на площадке заказчика, исключение случаев установки неоттестированных программ
• Кружки свойства: анализ ошибок в работе, разбор обстоятельств нарушений инструкций, исследование текста инструкций, мозговые штурмы организационных заморочек, дополнение и развитие технологических инструкций и протоколов

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

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

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

Решений у этой препядствия два:

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5 Качество ядра базы данных

Развитием ядра базы данных занимается так именуемая "ядерная" группа. Тактические и стратегические планы развития ядра ЕМЕ-ДБ расписаны как минимум на два года вперед.

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

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

Коротко перечислим технические свойства СУБД ЕМЕ-ДБ:

• База данных класса RISC: благодаря наличию устройств "Виртуальная память", "Виртуально открытый файл", "Разделение файлов полей", "Прямые физические ссылки", "Повсевременно хранимые сортировочные цепочки", "Цепочки прямых отношений один-много" работа с данными не просит от программера познания названий файлов, внедрения операций открытия и загрузки в память баз данных, оптимизации сортировок и поиска.
• Система коллективной работы в сети "Синхронные базы данных" обеспечивает предельное быстродействие при чтении данных, отсутствие блокирования сервера при долговременной обработке данных
• Синхронизация дублей базы данных на рабочих станциях и огромное количество устройств обеспечивающих контроль целостности банка данных и транзакций позволяют дать бессрочную гарантию (10 лет) на физическую и логическую целостность данных
• Уникальная разработка асинхронной работы удаленных филиалов, разработки конторы ЕМЕ, которая именуется "Гребенчатая схема консолидации данных", позволяет с данной периодичностью (1 раз в час либо в день) обмениваться переменами удаленным филиалам. 10-летняя гарантия на целостность банка данных распространяется на многофилиальные банки данных.
• "Трехслойный пользовательский интерфейс" - разработка зрительного конструирования диалогов, отчетов и запросов с возможностью подключать наружные функции на С++. Позволяет скооперировать визуальную простоту разработки с предельными чертами по быстродействию и многофункциональным способностям компилируемого программного кода. Возможность вынести на уровень пользовательских опций характеристики, управляющие работой отдельных модулей (2-ой слой интерфейса) и проекта в целом (3-ий слой интерфейса).
• Быстродействующая терминальная станция для удаленного конкретного доступа к банку данных.

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

Классические механизмы контроля свойства находятся в работе ядерной группы:

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

2.6 Отдел тестирования

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

Ни один модуль не принимается на тестирование, если в нем "искривленное" размещение органов (другими словами плохой дизайн диалогов либо отчетов), если отсутствует полная справка-помощь либо контекстные справки для органов диалогов.

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

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

Заключение. Гарантийные обязательства - верхушка системы свойства

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

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

Одним из характеристик свойства является гарантия, которую компания разработчик дает на свои изделия. Компания ЕМЕ при реализации проектов берет на себя последующие гарантийные обязательства:

• Реализация проектов "под ключ", в цена контракта всегда включено внедрение, обучение персонала заказчика, сопровождение, гарантия.
• Гарантийное сервис проекта с выездом к заказчику в течение 1-го года. В сервис включены доработки проекта, такие как модификация диалогов, отчетов, алгоритмов и структуры данных. Доработки позволяют гарантировать четкое соответствие проекта требованиям клиента, даже в случае, если на шаге подготовки технического задания не все детали были учтены.
• 10 лет гарантии на физическую и логическую целостность данных. Эта гарантия получается из-за наличия ребер жесткости в ядре базы данных и в метапроекте. Гарантия реализуется последующим образом: при появлении заморочек с пуском программки, при наличии сообщений об обнаружении ошибок в программке либо данных, при очевидном логическом нарушении целостности банка данных, программеры конторы ЕМЕ выезжают к заказчику в течение 2-ух часов и безвозмездно избавляют все недостатки.