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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Назад] [Методичка] [Вперед]