Программное обеспечение и его разработка - [89]
Как же проектировать систему, учитывая ее возможное развитие, заранее зная, что требования к ней могут измениться? Надо руководствоваться по крайней мере девятью следующими принципами:
1, Мы должны проектировать наши программы так, что бы они обладали максимально возможной модульностью. Даже в том случае, если это приведет к росту выполняемой рабочей программы и затяжке сроков разработки.
2. Модули следует группировать так, чтобы взаимодействие между ними было минимальным.
3. Нам следует применять методику упрятывания информации даже в тех случаях, когда она приводит к увеличению размеров программы. Это даст нам возможность при внесении исправлений уменьшить количество изменяемых модулей. Упрятывание информации есть результат высокой связности.
4. Нам следует использовать табличные методы управления логикой работы программы. Изменяя строку таблицы, вы меняете алгоритм. Мы использовали этот метод в системе диспетчерского контроля авиалиний. Структура авиалиний определялась таблицами, что избавляло нас от необходимости изменять алгоритмы программ, работавших в разных центрах (всего был 21 центр). Таким образом, у нас была одна программа и 21 таблица для 21 центра.
5. Необходимо устанавливать стандарты программирования и настаивать на их выполнении. Стандарты не пользуются популярностью, но необходимы.
6. Следует организовать строгий и детальный контроль. Мы затронем этот вопрос в разделе, посвященном руководству проектом.
7. Нам нужно заранее планировать прикрепление основных членов группы к работам по разработке последующих вариантов и версий.
8. Для обеспечения сопровождения программ нужно заранее планировать сохранение средств тестирования и разработки.
9. Все это необходимо предусмотреть при составлении бюджета.
Плачевные последствия недостатка капиталовложений, призванных способствовать развитию системы, не всегда сразу бросаются в глаза; иногда они совершенно замаскированы. Конечно, причиненные неприятности видны всем, но причины их не ясны.
Например, нам нужно добавить к некоторой продукции, предназначенной для продажи, новые функции, которые могут повысить ее конкурентоспособность. Все эти функции можно реализовать только программными средствами, и именно программными средствами их и надо реализовывать. По предварительной оценке, исправление программ можно провести за год. «Год!!» — следует реакция. — «Это безумие». Но меньше чем за год управиться не удается.
Причина заключается в том, что исправляемые программы по своей структуре напоминают бетонный блок! На начальном этапе создания программного обеспечения не было сделано ничего, что способствовало бы в дальнейшем облегчению модификации программ.
Но, что еще хуже, на начальном этапе проектирования игнорировалась необходимость делать программы «понимаемыми»! Это приводит к тому, что лишь небольшое число людей, часто работающих на самом нижнем уровне, понимают, что делается в конкретных программах, — и вот им то и приходится принимать ответственные решения.
Число программистов не просто сохраняется на низком уровне, оно уменьшается, это вызвано тем, что при малейшей вашей невнимательности ваших программистов переманивают другие. Нехватка программистов одновременно и тяжела и страшна. Нехватка разработчиков программного обеспечения еще страшнее, причем положение с ними постоянно ухудшается. Типичный ход работ над проектом напоминает приведенную на рис. 6.12 диаграмму. Сплошная линия обозначает планируемое число занятых в проекте. Точечная линия обозначает фактическую занятость. Дефицит на стадии А восполняется дополнительными затратами на стадии В.
Рис. 6.12. Подключение людей.
Рис. 6.13. Распределение людских ресурсов при разработке программного обеспечения.
Разработчики постоянно утверждают, что дефицит, возникающий на стадии А, будет преодолен «уже в следующем месяце», но сделать этого не удается почти никогда.
Как мы уже видели, более точная модель того, что происходит в крупных проектах, соответствует диаграмме на рис. 6.13.
Из всего вышеизложенного можно сделать вывод, что необходимо планировать развитие разработки и построения такой системы, которая сможет с течением времени претерпевать изменения, однако об этом часто забывают.
А ведь если этого не делать, нам придется латать и связывать систему из кусков, наша система получится хрупкой, и пользователи могут начать ее игнорировать.
Первое, что нужно сделать при разработке системы, которая будет подвержена длительному развитию, это позаботиться об удержании на месте группы разработчиков.
Вероятно, именно в этом заключается наиболее значительное отличие систем запуска человека в космос (NASA) и диспетчерского контроля авиалиний (FAA) от огромного множества других больших систем. И NASA, и FAA планировали и финансировали сохранность группы разработки на период до 10 лет! Обе организации понимали, что их системы будут развиваться в течение столь длительного времени.
Диаграмма занятости, приведенная на рис. 5.6, не подходит для систем такого рода; в больших системах после их сдачи
