Книга: Технологии программирования

7.2.5. Рекомендации по организации процесса разработки схемы иерархии

Как правило, составление внешних, затем внутренних функциональных описаний и далее структуры программы осуществляет группа от двух до семи квалифицированных программистов — системных аналитиков.

Отдельные варианты структуры программы разрабатываются до достижения возможности их сравнения. При этом используются следующие документы:

• описание алгоритма (функционирования) программы или методов решения задачи вместе с описанием данных;

• схема иерархии модулей программы с расшифровкой обозначений и функций модулей;

• паспорта модулей.

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

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

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

Самое главное в схеме иерархии — минимизация усилий по сборке и тестированию программы. При использовании заглушек можно хорошо тестировать сопряжения модулей, но не сами модули. Тестирование самих модулей потребует изощренных сложных заглушек и астрономического количества тестов. Выход — до интеграции модулей тестировать модули с использованием ведущих программ. Также рекомендуется осуществлять реализацию с некоторым нарушением принципа "сверху — вниз". Рекомендуется сначала с соблюдением принципа "сверху — вниз" реализовать ветвь схемы иерархии, отвечающей за ввод информации с проверкой ее корректности, заглушив ветви расчетов и вывода на самом верхнем уровне. Далее реализуется ветвь вывода информации и в последнюю очередь — ветвь расчетов (функционирования программы). Если функций программы много, то можно сначала реализовать модули выбора функций, заглушив модули самих функций, и далее реализовывать ветвь каждой функции последовательно с соблюдением принципа "сверху — вниз".

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

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

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

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

Существует очень много автоматизированных систем по формированию декомпозиции схем иерархии, например HIPO, SADT, R-TRAN.

Оглавление книги