CC BY
146
Ив62006
Л.С. Чистяков
| HIPO-технология разработки больших программных комплексов
Вопросы повышения надежности при создании программных продуктов сохраняют свою актуальность независимо от развития средств разработки программного обеспечения. В основу предлагаемой автором методики положен принцип взаимосвязи процесса разработки алгоритма и информационной структуры данных с организацией коллектива разработчиков. Идеи автора были использованы им при создании автоматизированной системы «ОРДЕР» (учет и распределение жилой площади). Излагаемый подход инвариантен относительно языковых и инструментальных средств создания программных продуктов.
Процесс разработки больших программных комплексов переносит проблемы разработки из сферы собственно разработки программ в сферу организации взаимодействия самих разработчиков. Если сложность разработки конкретной программы, выполняемой одним программистом, связана с созданием информационной структуры данных и разработкой алгоритма вычислений с учетом этой структуры, то сложность разработки нескольких программ разными программистами заключается уже в согласованности всего объема данных, используемых разработчиками, и в организации совместной согласованной работы разных программ, обрабатывающих эти данные. При этом на первое место выдвигается не столько сложность алгоритмической обработки данных, сколько сложность функционально-алгоритмической структуры самих данных. Если в первом случае сложность обработки списочных и древовидных структур данных носит математический характер, то сложность коллективного программирования связана с созданием структуры данных и согласованной организации в коллективе разработчиков. При этом на первое место выдвигается алгоритмический процесс организации проектирования всего программного комплекса. Организация разработки резко усложняется при увеличении
числа отдельных программных модулей и числа разработчиков. Организация разработки может быть:
• распределенной,
• иерархической,
• смешанной.
Если при распределенной организации процесса разработки сложность возрастает нелинейно, то при иерархической организации рост сложности носит линейный, т.е. управляемый характер. В первом случае надежность работы всего программного комплекса достигается только путем кропотливой отладки. Во втором случае сама организация программного процесса гарантирует высокое качество результата. Смешанный характер организации разработки наименее управляемый, так как осложняется конфликтами между четкой иерархической организацией и нечеткой распределенной. Материал данной статьи основан на личном опыте автора, идеи которого были использованы им в начале 1970-х годов (одновременно с созданием HIPO-технологии фирмой IBM) при разработке автоматизированной системы «ОРДЕР» (учет и распределение жилой площади). Эта система, главным конструктором и разработчиком которой является ав-
0102010201025301
Ивб 2006
тор данной статьи, была создана в ВГПТИ ЦСУ СССР, и после внедрения в Москве должна была стать стандартной для страны в целом. Общий объем системы «ОРДЕР» — более 140 тысяч операторов алгоритмического языка нижнего уровня. В статье представлено описание алгоритма инструментальной поддержки предложенной автором технологии, частично реализованного программой SPAD1 в 1981 году.
Несмотря на развитие средств разработки программного обеспечения, вопросы, рассматриваемые в статье, сохраняют свою актуальность и в настоящее время. Излагаемый подход инвариантен относительно языковых и инструментальных средств создания программных продуктов.
1. Обсуждение темы
Вопрос о правильности и надежности программ для ЭВМ — всегда насущная проблема. Независимо от выбранного языка программирования тексты программ современных систем реализуются десятками тысяч операторов. Общее число знаков таких текстов исчисляется уже сотнями тысяч. Ошибка хотя бы в одном знаке ведет к тому, что функционирование системы будет нарушено. В этой дискретности содержится основное отличие программных комплексов от самих ЭВМ, их реализующих, и тем более от релейно-механических устройств, на детали которых существуют допуски. Найдем математическое ожидание числа ошибок п, попавших в систему, состоящую из L=100 000 знаков, т.е. в программу, содержащую около 10 тысяч операторов языка высокого уровня.
Будем считать вероятность p ошибиться в каждом знаке при написании программы, удовлетворяющей неравенству
10~3 < p < 1,
где нижняя граница выбрана по аналогии с нормативами, действующими для набора текста. Естественно считать процесс написания каждого знака независимым событием. Тогда оценка искомого математического
ожидания будет проходить в условиях схемы Бернулли. При этом исключаются ошибки, которые могут появиться в связи с плохим знанием разработчиком выбранного им языка программирования или из-за неправильно организованного алгоритма, что привело бы к увеличению искомой вероятности. Тогда для математического ожидания получим
M( n) = L ■ p = 100.
Следует подчеркнуть, что здесь имеются в виду ошибки смысловые, а не те, которые могут быть обнаружены транслятором. Сто таких ошибок делают программу полностью неработоспособной, а выявление их трудоемко. Что же дает квалифицированному программисту и особенно системщику уверенность в качестве своего продукта?
Значительная часть программистов при ответе на этот вопрос ссылается на то, что программа была отлажена на контрольных примерах и принята заказчиком на тестовом варианте. Тем не менее, подавляющее большинство программных комплексов на этапе промышленной эксплуатации начинает давать сбои, и требуется значительное время (сравнимое со временем разработки всего комплекса), чтобы исправить ошибки. Постараемся разобраться подробнее в применяемых методах отладки программ.
2. Обзор применяемых методов отладки программ
2.1. Отладка программ на контрольных примерах
Пусть написанная программа PR имеет в древовидной интерпретации ветвления, которые дают N выходов на останов. Полная уверенность в правильности программ может быть тогда и только тогда, когда контрольный пример К тоже имеет на выходе N значений для N вариантов входа.
Мы говорим, что PR правильна, если она имеет те же значения выходов, что и для соответствующих вариантов входа, т. е. в некотором смысле
PR - K = 0.
Л.С. Чистяков
Модифицированная HIPO-технолоrия разработки больших программных комплексов
Ивб 2006
Выход 1
Выход 2
Выход 3
Рис. 1. Блок-схема части реальной программы
Следует отметить, что на практике программы никогда не бывают чисто древовидными, тогда как контрольный пример должен иметь чисто древовидную структуру.
Это приводит к тому, что работа по созданию контрольного примера не только сравнима по трудоемкости с работой по напи- Превратим ее в иерархическую (рис. 2) Вход
санию программы, но намного ее превосходит.
Приведем следующий пример. На рис. 1 изображена блок-схема части реальной программы.
В приведенной блок-схеме 5 выходов.
Выход 10
Выход 7
Рис. 2. Иерархическая блок-схема
Выход 8
Выход 9
Нвб 2006
Теперь блок-схема имеет уже 10 выходов. На практике полные контрольные примеры не составляются. Если неполный контрольный пример по объему близок к программе, то вероятность внесения в него того же числа ошибок такая же, как и для программы. Процесс отладки программы превращается при этом в бесконечное попеременное блуждание по тексту РR и К, причем часто отлаживается не программа в соответствии с контрольным примером, а наоборот. Применение в чистом виде только этого метода отладки приводит к увеличению числа ошибок в процессе внесения изменений в текст программы. Для маленьких программ, с небольшим числом выходов, такой метод отладки оказывается приемлемым. Если учесть важность такого рода программ для разработчика, то отношение времени написания программы к времени отладки как один к пяти представляется допустимым.
2.2. Отладка программ с использованием дублирования процессов вычисления
Этот метод отладки может быть использован в трех различных вариантах:
• дублирование написания одних и тех же программ разными исполнителями;
• использование для отладки объективно существующих в программном комплексе дублирующих вычислительных процессов;
• разработка специальных отлаживающих программ, имитирующих дублирование вычислительных процессов в основных программах.
Если применение первого и второго вариантов отладки очевидно, так как основано на том, что совпадение ошибок в одинаковых ветвях программы почти исключено, то третий вариант отладки следует рассмотреть более подробно. Он является универсализацией первого и второго вариантов и сводится к решению следующих задач:
• составление списка трудных процедур в основных программах;
• параметризация процедур для каждой программы или ветви;
• составление языка запроса на работу нужной последовательности процедур с необходимым набором параметров;
• составление программ для каждой процедуры и их отладка с использованием контрольных примеров (п. 2.1).
Использование этого метода отладки может привести к попытке удачно составлять основные программы, подгоняя их под заранее намеченные процедуры, выделение которых потом не составит труда. Такая подгонка составляет суть чисто программистского подхода, но она может привести к значительному искажению задачи. Ортодоксальное использование этого способа, состоящего из этапов, продемонстрированных схемой (рис. 3), достаточно трудо-
Рис. 3. Схема подгонки программ под заранее намеченные процедуры
Л.С. Чистяков
Модифицированная HIPO-технолоrия разработки больших программных комплексов
И962006
емко, но все же оно более экономно, чем первые два варианта.
Все три варианта отладки, перечисленные выше, используют дублирование процессов вычисления и являются консервативными, так как любые изменения, связанные с переосмыслением проблемы, моделируемой программным комплексом,приводят к переделке отлаживающих программ.
2.3. Отладка с использованием иерархических функциональных связей в массивах информации, перерабатываемых программным комплексом
Пусть комплекс реализует переработку п массивов информации
Щ : 1 < 1 < п}.
Некоторые из них {М1к : к < п} являются исходными, а остальные — промежуточными или выходными. Тогда
Мр = f (М,}), где р > к,, < к, р + , = п.
Функция f множества исходных массивов может быть представлена как суперпозиция других функций, каждая из которых отображает исходный или промежуточный массив в промежуточный или выходной. Рассмотрим пример, иллюстрирующий информационную зависимость массивов (рис. 4).
М1, М2, М3 — исходные массивы;
М4 = ф1 (М1; М2);
М5 = Ф2 (М-ь М3);
М6 = фз (М2; М3);
М7 = ф4 (М4; М5; Мб) = f (М-; М2; М3), где f =
= ф4(ф1; Ф2; фз).
При этих условиях написание программ должно быть упорядочено во времени в соответствии со списком:
• программа ввода для формирования М1,
• программа ввода для формирования М2,
• программа ввода для формирования М3,
• программа формирования М4,
• программа формирования М5,
• программа формирования М6,
• программа формирования М7.
В этом случае отладка проводится на контрольных примерах, составляемых только для М1, М2 и М3. Входы для остальных программ не вычисляются вручную, а берутся как выходы из уже отлаженных, предыдущих в списке программ. Резкое сокращение ручных вычислительных работ в этом методе отладки может обесцениться при непроцедурном подходе к программированию. При этом большая степень дублирования процедур вызовет громоздкую организацию всего программного комплекса, что, в свою очередь, потребует дополнительной оптимизации программ и проведения отладок.
В силу вышеназванных свойств данный метод является далеко не бесспорным и в каждом конкретном случае требует оценки его эффективности.
Ф1
м, м4
%
ф2
м2 м5
X Фз
м3 ^—г Мв
Рис. 4. Пример информационной зависимости массивов
Ивб 2006
2.4. Отладка программы
с использованием отладки алгоритма
Здесь программой называется алгоритм, записанный на машинно-ориентированном языке. Данный метод сводится в основном к отладке алгоритма и добросовестному составлению программы в соответствии с алгоритмом и является, по существу, ручной трансляцией с языка блок-схем на машинно-ориентированный язык.
Методика состоит из:
• сохранения в программе меток алгоритма (где метка есть номер/имя блока, на который имеется ссылка, или идентификатор процедуры);
• преобразования алгоритма в программу только за счет детализации блоков алгоритма;
• принципа «неэкономии» переменных, благодаря которому все новые переменные, вводимые в процессе детализации, должны иметь разные имена;
• строго древовидной детализации каждого блока алгоритма.
При необходимости сегментации программы процесс программирования прекращается и вносятся соответствующие изменения в алгоритм. Проверка правильности составления алгоритма проводится при соблюдении следующих условий:
• описание блок-схемы должно содержать перечень решаемых задач и алгоритмические идеи их реализации, структуры, размеры и имена всех полей данных основных массивов;
• каждая решаемая задача должна быть снабжена списком (или интервалом значений) номеров блоков, реализующих эту задачу;
• должен быть составлен перечень блоков, общих для разных задач.
Контроль алгоритма заключается в следующем:
• каждый блок должен быть продолжаем до выхода на останов;
• все вспомогательные переменные и массивы должны быть описаны;
• все индексы во всех вложенных циклах должны быть различны;
• общая сумма длин полей в оперативной памяти, отведенных для одновременной эксплуатации, не должна превышать отводимой программе памяти;
• каждая последовательность действий, реализуемая алгоритмом, должна иметь конечный выход на останов (отсутствие «зацикливания»).
Приведенный обзор некоторых основных методов отладки больших программных комплексов показывает, что почти все они трудоемки и обладают невысокой эффективностью. Тем не менее, многие программные комплексы, выполненные опытными специалистами, успешно функционируют. Анализ реальных способов отладки приводит к выводу, что в подобных случаях ведущим является здравый смысл и правильная организация работ по программированию.
3. О коллективах разработчиков и модифицированной HIPO-технологии
3.1. Управление процессом программирования
Большие системы почти всегда разрабатываются коллективно. Число разработчиков при создании каждой такой системы варьируется от 5 до 100 человек и больше (хотя коллективы, численность которых превышает 30 человек, трудно назвать управляемыми). Количество разработчиков в фирмах-монополистах исчисляется сотнями и даже тысячами человек. Управляемость таких коллективов достигается внесением иерархии в их структуру.
В этих коллективах всегда существует некоторая иерархия, хотя бы по должностям, отражающая уровень квалификации того или иного разработчика. Основная идея данного раздела статьи заключается
Л.С. Чистяков
Модифицированная HIPO-технолоrия разработки больших программных комплексов
И962006
в том, чтобы не программы «заставлять» работать надежно, а «заставлять» коллектив разработчиков писать надежные программы. Для этого необходимо правильно организовать работу и упростить технологический процесс создания программы. При этом взгляд на программирование как на единый процесс поэтапного алгоритмирования является наиболее естественным.
3.2. Технические требования к модифицированной HIPO-технологии
3.2.1. Общее положение
При разработке программных средств можно выделить два типа работ. Во-первых, создание систем взаимосвязанных программных частей (блоков, модулей). Во-вторых, разработка отдельных программных модулей. Для каждого типа работ в отдельности опишем технические требования к процессу алгоритмирования, программирования, отладки и описания готовых программ, придерживаясь следующих руководящих принципов:
• должна быть определена документация, с которой начинается работа («ВХОД»);
• должна быть определена документация, сопровождающая все этапы работ («ОБРАБОТКА»);
• необходимо представить материалы, документирующие законченную работу («ВЫХОД»);
• названная документация и процесс ее создания должны подчиняться принципам Н1РО-технологии.
3.2.2. Разработка системы
При разработке системы основой становится алгоритм, являющийся табличным представлением структуры перерабатываемой информации и граф-схемой, описывающей процессы переработки.
На каждом этапе документирования необходимо отражать:
• структуру внешней документации на входе и на выходе;
• структуру внутренней документации в оперативной памяти машины и на внешних носителях информации.
Граф-схемы алгоритмов должны быть составлены в соответствии с требованиями, предъявленными ГОСТ 19.003-80 к блок-схемам программ и алгоритмов. Иерархический процесс разработки приводит к иерархии описаний, которые выполняются в соответствии с основным правилом декомпозиции Н1РО-документации.
3.2.3. Основное правило
На рис. 5 представлен процесс разработки программ, а на рис. 6 — процесс сопровождения документацией.
^ — описание документации
Рис. 6. Процесс сопровождения документацией
Таким образом, каждая детализация блока порождает описание, а описание предыдущего уровня переходит в описание описаний. Логическая структура архива документов с т уровнями детализации и п документами на последнем уровне описывается матрицей А (т,п):
Ивб 2006
f 0 0 . 0 0 0 0 0 0 0 0 0 0 1 ^
0 0 . 0 0 1 0 0 0 1 0 0 1 X
A = 0 0 . 1 1 X 1 1 1 X 1 1 X X
V1 1 . 1 X X 1 X X X 1 X X X J
Здесь 1 соответствует документам, описывающим программные блоки, а X — это описания, вызванные детализацией блоков.
Любой шаг детализации приводит к увеличению числа строк на единицу, а числа столбцов — на число новых блоков и их описаний. При этом нули переходят в единицы, единицы либо остаются на месте, либо переходят в X, а X переходит в X. Создание HIPO-архива сводится к составлению описаний программных блоков, каталогов-описаний этапов детализации и матричной организации связей между документами архива.
Документы, соответствующие единицам в логической матрице A, отражают описания входов в блок, алгоритма переработки и выходов из блока. Каждый документ должен иметь логическое имя (i, j), определяющее его место в матрице A. Документы, соответствующие X, содержат описания структур групп документов, образующих детализацию соответствующего уровня, и для каждой строки в точности отражают исходное иерархическое дерево процесса детализации. Уровни детализации видны из групп совпадающих между собой столбцов, причем число нулей в столбце дает глубину детализации. При такой технологии расположение папок с HIPO-документацией может быть произвольным.
Заполнение схемы HIPO в разделах «ВВОД», «ОБРАБОТКА», «ВЫВОД» приводит при большом объеме связей к паутине отрезков, лишающей схему задуманной наглядности. Исправить это положение можно за счет перехода к табличному представлению.
Рассмотрим пример перехода от схемы HIPO к табличному представлению.
В разделе ввода используются данные, хранящиеся на трех устройствах ввода.
В разделе вывода используются оперативный архив в ОЗУ, признак ошибки синтаксиса в ОЗУ, признак ошибки семантики в ОЗУ, промежуточный архив, сообщение пользователю, архив. Блоки обработки в соответствии со схемой HIPO будут взаимосвязаны следующим образом (рис. 7).
Та же схема, заданная в табличной форме, будет иметь вид, представленный в табл. 1. Вместо нулей можно оставлять пробелы.
Несмотря на то что кажущаяся наглядность первого представления в табличной интерпретации пропала, нетрудно видеть, что любая попытка разобраться в связях таблицы полностью восстанавливает наглядность и имеет дополнительную формальную строгость, отсутствующую в первом представлении. При разработке документации, описывающей программные блоки системы, следует выполнять следующие требования:
• все имена полей данных, массивов, файлов, мнемонические имена устройств ввода должны сохраняться на всех этапах детализации сквозным образом;
• все имена программ должны сохраняться, а в случае декомпозиции имен, вызванной детализацией, должен быть представлен полный перечень имен подпрограмм;
• разработка структуры информации и программной сегментации системы должна быть осуществлена на физическом уровне и отражена в HIPO-документации;
• должны быть определены все основные программные сегменты, составлен каталог их имен и примерных объемов.
3.2.4. Разработка отдельных модулей
Главными документами на «ВХОДЕ» при разработке программного модуля являются либо блок-схема алгоритма модуля и описания, либо схема HIPO.
Перечислим основные этапы разработки модуля:
• разработка детальной (на уровне выбранного языка программирования) блок-схемы программы;
Л.С. Чистяков
Модифицированная HIPO-технология разработки больших программных комплексов
НвВ 2006
Рис. 7. Взаимосвязь блоков обработки в соответствии со схемой HIPO
Таблица 1
Табличная форма взаимосвязи блоков обработки в соответствии со схемой HIPO
ввод 1 Ввод ввод 2 ввод 3 Обработка вывод 1 вывод 2 Вывод вывод вывод 3 4 вывод 5 вывод 6
0 0 Запись информации в оперативную память 0 0 0 0 0
0 0 0 Контроль синтаксиса записи 0 0 0
0 0 Семантический контроль записи 0 0 0
0 0 0 Занесение записи в промежуточный архив на диске 0 0 0 0
0 0 0 Сообщение пользователю о занесении в архив 0 0 0 0 0
0 0 Сортировка информации в промежуточном архиве 0 0 0 0 0
0 0 0 Запись информации в архив 0 0 0 0 0
Ивб 2006
• написание текста программы строго в соответствии с блок-схемой;
• ввод и попытка трансляции исходного текста;
• исправление ошибок, мешающих трансляции;
• трансляция программы (исходный текст на диске) и получение окончательного листинга;
• сборка;
• составление документации об областях диска, хранящих исходный текст, объектный модуль, данные контрольного тестового примера;
• прогонка программы на контрольных и тестовых примерах.
На всех приведенных этапах необходимо выполнять следующие требования:
• все поименованные блоки в блок-схеме алгоритма должны быть также поименованы метками программы;
• до этапа написания текста программы должна быть подготовлена схема-опись всех блоков в том порядке, в котором они будут отражены в тексте — линеаризация блок-схемы (табл. 2);
• все внутренние метки текста должны быть мнемонически связаны с той меткой блок-схемы, которую они декомпозируют;
• нарушения структурной декомпозиции блок-схемы алгоритма при переходе к детальной блок-схеме программы должны компенсироваться соответствующими описаниями;
• листинг необходимо иметь в двух экземплярах.
Процесс линеаризации блок-схемы алгоритма может быть удобным образом отражен в таблице, которую полезно использовать и до этапа алгоритмирования.
Приведем следующий пример. Пусть дана двумерная блок-схема (рис. 8).
Нумерация блоков дана произвольно, и натуральные числа есть имена блоков, а не порядковые их номера. Процесс напи-
сания программы по данной блок-схеме алгоритма, т.е. превращение последнего в машинно-ориентированный алгоритм, начинается с линеаризации.
В графе «Нет» указывается номер блока перехода из логического блока по «Нет» (для каждой строки). Все логические блоки расположены по одному в строке. Точки в строке указывают на то, что после соседнего с точкой блока следуют блоки, уже отображенные в таблице выше.
Данную блок-схему можно линеаризовать и по-другому. Это приведет к тому, что в таблице некоторые строки поменяются местами.
Таблица 2
Табличное представление линеаризации машинно-ориентированного алгоритма
Номер строки Номера последовательно идущих блоков Нет
1 В —
2 1 (логический блок) 2
3 8 10 15 —
4 18 (логический блок) 19
5 25 Е —
6 2 3 —
7 4 (логический блок) 5
8 9 —
9 11 (логический блок) 12
10 22 2 со 2 т —
11 19 20 —
12 21 (логический блок) 13
13 22 • —
14 5 —
15 6 (логический блок) 7
16 13 (логический блок) 14
17 16 • 4 2 7 —
18 12 16 • —
19 14 17 • —
20 7 —
21 4 •
Л.С. Чистяков
Модифицированная HIPO-технолоrия разработки больших программных комплексов
Ивб 2006
7
т .. Тнет
Рис. 8. Пример двумерной блок-схемы
3.3. Согласование иерархической структуры коллектива разработчиков с иерархической HIPO-технологией разработки
Основная идея данного раздела заключается в том, чтобы распараллелить работы в соответствии с уровнями квалификации разработчиков. При этом административная структура коллектива разработчиков оказывается самонастраивающейся. Пусть иерархическая структура коллектива, соответствующая уровням квалификации, описана изначально древовидным графом G административных связей.
Пусть далее число уровней в нем Ыу, а число узлов, равное числу разработчиков, есть Np. Поставим в соответствие графу б(Му, Np) список в допустимых сложностей работ в соответствии с уровнями, т. е.
в( ^) ^ в = ( Я в2 в^).
Наименование должности можно отождествить с именем некоторой сложности в,, и наоборот. В процессе Н1РО-технологи-ческой разработки степень сложности модулей не обязательно понижается, так как в укрупненной блок-схеме может присутствовать блок, детальная разработка которого оказывается достаточно сложной. Для каждой появившейся работы А в документации, содержащей техническое задание на ее выполнение, указывается сложность в(А), устанавливаемая экспертно руководителем работ или некоторым техническим советом, состоящим из самих разработчиков. При этом оказывается, что
в,- < в( А) < в,,
где 1 < , < Nу -1.
Ивб 2006
В противном случае необходимо отказаться от проведения работ силами этого коллектива. После такой оценки полагается S(A) = S(+1. При этом i +1 определяет уровень административной иерархической структуры коллектива разработчиков, из числа свободных сотрудников которого выбирается исполнитель. Ему передается вся HIPO-документация на работу A с оценкой ее сложности, которая и определяет срок выполнения работы. При этом иерархическая структура HIPO и административная структура оказываются согласованными.
3.4. Уменьшение времени простоя разработчиков, ожидающих техническое задание на работу
Предыдущий метод организации работ может быть улучшен за счет следующего уплотнения. Если в уровне i +1 все разработчики оказались занятыми к моменту готовности технического задания на работу A, то можно перейти к уровню j (i +1 >j > 1). Тогда квалификация разработчиков уровня j окажется выше требуемой, что не может ухудшить результат выполняемой работы.
В этом случае разработчик может оказаться занятым менее квалифицированной работой к тому времени, когда поступит работа, соответствующая его квалификации, что задержит ее выполнение. Но общее время простоя будет уменьшено.
Не в любом производственном коллективе с иерархической структурой возможна передача работы на более высокий уровень, так как следует учитывать специализацию. Но в коллективах разработчиков программных комплексов это возможно, так как алгоритмист обязан уметь программировать, а программист может выполнять операторскую работу. Постановщиками задач должны быть программисты высокой квалификации. Будем исходить из того требования, что каждый элемент административной структуры должен быть хотя бы один раз задействован, а, следовательно, число уровней U административного графа G и HIPO-технологического графа H должно удовлетворять соотношению
и(Н) > и(О)
при условии, что первый элемент графа О всегда будет задействован. Кроме того, число узлов Я(О) графа О и число узлов Я(Н) графа Н должны быть связаны соотношением
Я( Н) > Я(О).
Выведенные соотношения являются необходимыми, но не достаточными для того, чтобы все разработчики оказались занятыми. Из приведенных рассуждений ясно, что в процессе оптимизации алгоритма согласования структур О и Н основными являются два критерия:
• минимизация времени разработки,
• повышение степени занятости коллектива разработчиков.
При этом второй критерий требует следующего уточнения. Так как разработчики разнятся по уровням квалификации, то стремление повысить степень занятости сотрудников низких уровней квалификации будем считать разумным. Незанятость в непосредственном производственном процессе сотрудников высших уровней может быть использована для выполнения ими функций технологического контроля над работой низших уровней. В процессе взаимодействия двух структур Н и О, в результате которого О овеществляет Н, есть два существенных события:
• появление нового технического задания, порождающего дальнейшую детализацию работы;
• завершение работ по выданному техническому заданию одним из исполнителей и освобождение его для новой работы.
4. Инструментальная поддержка
Идеи, высказанные в п. 3.3 и 3.4, частично реализованы программой вРА01. На вход программы поступает заказ пользователя. Пользователь может заказать один из четырех видов работ, каждый из которых реализуется отдельной подпрограммой:
Л.С. Чистяков
Модифицированная HIPO-технология разработки больших программных комплексов
НвВ 2006
• формирование списка исполнителей;
• формирование очереди работ;
• внесение в список исполнителей и в очередь работ информации о передаче конкретной работы конкретному исполнителю;
• печать состояния списка исполнителей и очереди работ в табличной форме, а также печать сведений о динамике процесса выполнения работ коллективом разработчиков.
После ввода заказа программа проводит его синтаксический и семантический контроль и вызывает необходимую подпрограмму обработки заказа. Если в результате работы вызванной подпрограммы в список исполнителей или в очередь исходящих работ были внесены какие-либо изменения (т. е. освободился или появился новый разработчик, или появилась новая работа), вызывается подпрограмма, которая осуществляет автоматический выбор исполнителя. Для каждой работы из очереди, не имеющей исполнителя, в списке исполнителей выбирается первый свободный разработчик со специализацией и квалификацией, соответствующими данной работе. Соответствие заключается в том, что:
• либо специализация разработчика совпадает со специализацией работы, либо разработчик имеет универсальную подготовку;
• квалификация разработчика такая, какая требуется для выполнения данной работы.
Если подходящего разработчика нет, поиск ведется среди исполнителей более высокой квалификации. При этом более квалифицированный разработчик получает работу только в том случае, если среди исполнителей есть еще свободные разработчики такой же квалификации.
При нахождении нужного разработчика вносятся изменения в список исполнителей и в очередь работ, и начинается обработка следующей в очереди работы. Если нужный исполнитель не подобран, подпрограмма
переходит к следующей работе. Дойдя до конца очереди, подпрограмма автоматического подбора исполнителя возвращает управление программе SPAD1. На этом завершается цикл работы с одним заказом, и подпрограмма переходит к анализу следующего заказа. Если поступает новый заказ, цикл повторяется заново. В случае отсутствия нового заказа работа программы заканчивается.
В заключение следует отметить, что изложенная в статье методика полностью авторская, ссылка на нее обязательна. Приведенный список литературы не является источником данных идей и носит сопроводительный характер. Развитие методики возможно, прежде всего, при разработке систем управления большими производственными и административными структурами, а также операционных систем и систем управления распределенными базами данных.
Список литературы
1. Криницкий Н.А. Равносильные преобразования алгоритмов и программирование. М.: Советское радио, 1970.
2. Ершов А. П. Теория программирования и вычислительные системы. М.: Знание, 1972.
3. Кериевски Д. Рефакторинг с использованием шаблонов. М.: Вильямс, 2006.
4. Дастин Э., Рэшка Дж., Пол Д. Автоматизированное тестирование программного обеспечения. М.: Лори, 2003.
5. Касперски К. Техника отладки программ без исходных текстов. СПб.: БХВ-Петербург, 2005.
6. Винниченко И. Автоматизация процессов тестирования. СПб.: Питер, 2005.
7. Тамре Л. Введение в тестирование программного обеспечения. М.: Вильямс, 2003.
8. Смит Б. Методы и алгоритмы вычислений на строках. М.: Вильямс, 2006.
9. Эндрюс Г. Основы многопоточного, параллельного и распределенного программирования. М.: Вильямс, 2003.
10. Ройс У. Управление проектами по созданию программного обеспечения. М.: Лори, 2002.
