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

Фокс Джозеф М.

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

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

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

Приведенное ниже множество «стандартов» (табл. 6.6) установлено для крупных программных разработок. У каждого правила могут быть свои исключения, но

в целом его следует принимать за основу в начале работ. Введены ли они в действие? Опубликованы и им уже начали следовать? Понятны ли они? Изменялись ли? Кем?

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

Таблица 6.6. Методы производства программного обеспечения

1. Программы операционной системы	Стандартное разделение программного обеспечение
2. Программы системы управления базой данных
3. Программное обеспечение системы связи
4. Программы ввода/вывода
5. Программы работы с дисплеями
6. Программы информационной системы
7. Использование управления конфигурацией
8. Обеспечение необходимого качества
9. Документация, описывающая функцию программы по подпрограммам
10. Диаграммы, отображающие взаимоотношения оборудования и программ, с обозначением внутренних и внешних потоков данных
11. Языки высокого уровня
12. Использование анализа и оценок необходимых ресурсов (ЦП, память)
13. Использование структурного программирования
14. Размеры модулей небольшие; функциональное разграничение ярко выраженное, обязательное упрятывание информации
15. Список ограничений, возникших при проектировании, и принципов построения проекта
16. Частый сквозной контроль
17. Использование библиотекарей
18. Внесение исправлений в рабочие и исходные программы
19. Использование средств автоматизации сопровождения
20. Проектирование высокой производительности системы
а) функциональной: доля удовлетворенных требований
б) технической: точность, методология, проверка алгоритмов
в) операционной: восстанавливаемость после сбоев
г) удовлетворение временных ограничений на производительность

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

Ничто не дается бесплатно — средства на стандартизацию тратятся с первых же шагов

Из-за того что мы настойчиво придерживаемся стандартов, фаза разработки программного обеспечения может потребовать больше времени и будет стоить немного (а может быть, и значительно) дороже. На фазе использования могут произойти подобные вещи. Мы будем вынуждены тратить время на выполнение дополнительных команд, вставленных нами в программу для обеспечения модульности и лучшей читаемости. Нам потребуется несколько больше памяти. Зачем нам это все надо? Для фазы продолжающейся разработки. В этой фазе мы сэкономим столько, что оправдаем все расходы на предыдущих двух.

Склонность к фантазированию

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

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

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

Репутацию фирмы-производителя нельзя считать мерой надежности. Сколько пользователей пострадало, когда фирма IBM испортила первую версию системы ОС/360? Системы реального времени для модели 67? Программное обеспечение для Series 1?

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

Часто самое высшее руководство бывает склонно к самым диким фантазиям. А представители другой крайности — технический персонал, программисты, отказываются применять новые методы на практике. Но программистов надо ограничивать именно в их собственной области деятельности! В противном случае, они, подобно детям, играющим в кубики, начнут с увлечением строить очаровательные, запутанные, закрученные и неразборчивые конструкции. Они будут писать вложенные циклы на трех страницах!

Цикл, размером в три страницы, это логический кошмар. Это еще более сложное образование, чем Литота — двойное или множественное отрицание, как в предложении Гарольда Ласки: «Я до конца не уверен в том, будет ли правдой утверждение, что Мильтон, который прежде не казался не похожим на Шелли семнадцатого века, не стал, в противовес опыту даже более горьких лет, более близким основателю иезуитской секты, которая вряд ли способствовала развитию в нем терпимости» [43] .

43

David Hackett Fischer, Historians Fallacves — Towards Logic of Historical Thought (New York: Harper & Row, Publischers INC., 1970).

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

Сопротивление нововведениям

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

Обычно сама идея введения стандартов на программное обеспечение отвергается руководителем разработки программного обеспечения. Отказ от стандартов обычно сопровождается такими высказываниями: «Я уже делал нечто подобное», или «Мы не нуждаемся в подобных накладных расходах». Такой начальник просто отстал от жизни. Дело здесь осложняется тем, что он все же остается руководителем! Теми или иными средствами он выполняет свою работу. Он стал боссом, лидером, добился успеха, а эти новые методы очень странны, они таят в себе опасность. Они могут лишить его действия некоторой таинственности, которой они раньше обладали. Очень вероятно, что благодаря этим новым методам ему с новой силой придется вести конкурентную борьбу за руководящую должность.

«Высокое начальство» мало что знает о всех этих новшествах. Даже если есть выбор, он предпочитает соглашаться с руководителем, ретроградом или сторонником новых идей! И может статься, что применение новейшей технологии будет отложено до лучших времен.

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