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

Рис. 5.4. Диаграмма распределения людских ресурсов по данным 1970 г.

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

Рис. 5.5. Диаграмма распределения людских ресурсов (по данным 1975 г)

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

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

Эти ошибочные диаграммы укомплектования персоналом очень живучи. Диаграмма, изображенная на рис. 5.6, появилась в ведущем журнале отрасли в 1979 г.

Рис. 5.6. Распределение людских ресурсов для программ типов I и II.

Рис. 5.7. Распределение людских ресурсов при разработке программного обеспечения.

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

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

Еще раз взгляните на модель, использованную нами в отделении федеральных систем фирмы IBM в начале 70-х гг. (рис. 5.5). Процесс проектирования, как мы уже видели, отражен вполне удовлетворительно, но совершенно неправильно представлена роль тестирования. Показано, что тестирование начинается только вместе с кодированием.

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

«Большой взрыв» и эволюция

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

Для программ типов III, IV и V дело осложняется тем, что разработчик не вполне понимает все требования. Когда пользователь получает первую версию системы, он говорит: «Ага, посмотрим, что с этим можно сделать», после чего возникает целый поток новых требований! Никто не в силах предугадать, каким образом пользователь будет в действительности применять даваемый ему новый инструмент. Та скорость, с которой разработчик ответит второй версией системы на новые требования, зависит от огромного множества различных обстоятельств, среди которых немаловажную роль играет то, насколько разработчик может контролировать пользователя, иными словами, что же мы создаем — программу как продукцию или программное обеспечение проекта.

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

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

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