Система качества (управление качеством производства ПО)

Предыдущая часть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме