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

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

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

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

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

Хотя глава NSA чувствовал, что им известно, как нужно производить приобретение систем, первым документом, изданным комитетом, был документ под названием «Политика приобретения систем». Лишь затем удалось заняться программным обеспечением!

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

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

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

Зачем заострять внимание на этом очевидном факте? Уинстон Черчилль определял фанатика как человека, который не изменяет своего решения и не переводит разговор на другую тему. Нам же постоянно приходится сталкиваться с «программистами-фанатиками», которые считают, что важнее программного обеспечения нет ничего на свете. Этим фанатикам нельзя доверять руководство системами или проектами, поскольку у них искаженное представление об окружающем мире и извращенное суждение о программном обеспечении, системе и результате.

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

Две роли программного обеспечения

Очевидная роль программного обеспечения — заставить работать аппаратуру! Но давайте заглянем поглубже. Этим роль программного обеспечения не ограничивается. Оно

еще должно быть легко модифицируемым.

Никто без серьезных оснований не станет ломать антенну радиолокатора или новый спутник (ценой около 50 млн. долларов). Однако руководители различных систем с легкостью идут на изменения в программном обеспечении! Они должны даже заранее планировать эти изменения. Такая роль была уготована программному обеспечению с самого его возникновения. Изучение истории этого вопроса возвращает нас к понятию запоминаемой программы.

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

Почему проблема программного обеспечения еще не полностью решена?

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

1. Сложность. Внутренняя сложность автоматизируемого процесса, т. е. научная сложность (лунное притяжение и т. д.), или логическая сложность (число ветвей в программе может достичь значения 10³⁰⁰⁰), или и та и другая вместе.

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

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

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

5. Управление взаимодействием с пользователем с помощью программного обеспечения. Создаваемое для такого взаимодействия программное обеспечение должно выполнять следующее: