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

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

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

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

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

Определение требований

Проектирование

Написание команд программы

Компоновка

Тестирование

Документирование

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

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

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

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

Тестирование, или, как его сейчас часто называют, верификация, — это весьма важный и сложный род деятельности.

Как мы уже знаем, документация особенно важна на этапе продолжающейся разработки.

Давая поэтапный список процессов как это сделано на рис. 5.2, мы должны понимать, что реально он никогда не бывает таким простым и понятным.

Очевидно, что только простейшие задачи проходят все шаги без каких-либо итераций, т. е. постоянных возвратов на более ранние этапы процесса. При проектировании кто-то может обнаружить, что следование какому-нибудь требованию может привести к двукратному увеличению стоимости разработки подсистемы. Разработчик должен пересмотреть и переоценить требования. Этот процесс продолжается непрерывно. Группе проектировщиков передается новая информация, проект должен быть пересмотрен. (См. рис. 5.3.)

В конце 60-х гг. в Гейтсбурге в отделении фирмы IBM мы создали специальный курс лекций под названием КУПП — курс управления программным проектом. Этот курс был предназначен для того, чтобы молодые руководители работ лучше понимали, на что обращать особое внимание, как привести проект к оптимальному результату (см. рис. 5.4.). Материал мало менялся с годами, я здесь привожу две диаграммы распределения людских ресурсов, использовавшихся на протяжении 5 лет.

Рис. 5.4 был в конце концов признан неправильным. Для больших проектов проектирование не кончается никогда. Диаграмма была изменена таким образом, чтобы отразить продолжающееся в течение всего этапа разработки проектирование (см. рис. 5.5).

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