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

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

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

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

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

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

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

«Социология»? Ну конечно, ведь поддержание на высоком уровне количества занятых людей в течение многих лет ведет к таким затратам, что проект может быть отвергнут. Поэтому и выбирают график вида большого взрыва. Для небольших приложений типов I и II такая схема привлечения персонала работает вполне удовлетворительно. В других условиях использование большого взрыва — это чистейшей воды афера, причем совершенно бессмысленная! (См. рис. 5.8.)

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

Для начала обратимся к конечному результату — что представляет собой программа из миллиона команд? Никто никогда такой программы не видел. Если мы напишем на бумаге миллион строк по 4 команды на 1 см, мы получим рулон бумаги длиной в 250 000 см. Это составляет 2,5 км. бумаги.

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

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

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

Оглавление книги