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

Давайте посмотрим, какие характеристики существуют в фазе использования.

1. Каждая программа выполняет некоторую функцию, например, она может составлять платежную ведомость.

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

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

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

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

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

6. Каждая программа должна сохранять работоспособность. Некоторые из них перезапустить легко, другие сложнее. И опять эта характеристика является объектом тщательного проектирования.

Теперь рассмотрим характеристики фазы разработки.

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

8 Каждая программа создается некоторым числом программистов, работающих в течение некоторого времени (чел. — мес.).

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

10. Для создания каждой программы необходимы денежные средства.

Теперь обратимся к характеристикам фазы сопровождения.

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

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

Теперь попытаемся представить все эти характеристики программ на диаграмме, иллюстрирующей жизненный цикл программы (см. рис. 5.1).

Заметьте, что четыре аспекта разработки относятся также и к продолжающейся разработке!

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

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

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

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

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

Молотки делают из металла. Мы делаем их и используем. Ремонт им не нужен, но пользуемся мы ими неоднократно.

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

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

Мы обратились к этим трем примерам постольку, поскольку они дают нам повод поговорить о качестве программного обеспечения Качество зубочисток необходимо только при их использовании. Для программ типа «зубочисток» нам не приходится заботиться о компоновке — до тех пор пока они работают на нас, — нам не нужно думать об их документировании, раз мы собираемся использовать их только однажды, а затем выбросить.

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

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

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

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

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

Это наиболее интересное утверждение; давайте обсудим его подробнее.

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