Книга: Программное обеспечение и его разработка

Планирование развития

Как же проектировать систему, учитывая ее возможное развитие, заранее зная, что требования к ней могут измениться? Надо руководствоваться по крайней мере девятью следующими принципами:

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

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

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

4. Нам следует использовать табличные методы управления логикой работы программы. Изменяя строку таблицы, вы меняете алгоритм. Мы использовали этот метод в системе диспетчерского контроля авиалиний. Структура авиалиний определялась таблицами, что избавляло нас от необходимости изменять алгоритмы программ, работавших в разных центрах (всего был 21 центр). Таким образом, у нас была одна программа и 21 таблица для 21 центра.

5. Необходимо устанавливать стандарты программирования и настаивать на их выполнении. Стандарты не пользуются популярностью, но необходимы.

6. Следует организовать строгий и детальный контроль. Мы затронем этот вопрос в разделе, посвященном руководству проектом.

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

8. Для обеспечения сопровождения программ нужно заранее планировать сохранение средств тестирования и разработки.

9. Все это необходимо предусмотреть при составлении бюджета.

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

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

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

Но, что еще хуже, на начальном этапе проектирования игнорировалась необходимость делать программы «понимаемыми»! Это приводит к тому, что лишь небольшое число людей, часто работающих на самом нижнем уровне, понимают, что делается в конкретных программах, — и вот им то и приходится принимать ответственные решения.

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