Читать интересную книгу Программное обеспечение и его разработка - Фокс Джозеф М.

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

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

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

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

Неверная интерпретация содержимого базы данных. В начале 1977 года я допустил публикацию одной статьи в журнале IBM System Journal, написанную Уолстоном и Феликсом с условием, что будет опубликована только часть данных и что будет ясно указано, что приводимый анализ является предварительным. И тем не менее статью часто цитируют, как будто это окончательный отчет, и это цитирование не всегда верно.

В статье утверждалось следующее[37]:

Данные были собраны по шестидесяти завершенным разработкам программного обеспечения. Использовалось двадцать восемь разных языков программирования. 28 языков для 66 различных вычислительных машин. Размеры программ изменялись в диапазоне от 4000 строк исходного текста до 467 000.

Рабочие программы в статье не рассматриваются; сведения касаются только исходных программ. В статье приводится список 29 переменных из 69 представленных в отчетах, отбирались переменные, в наибольшей степени влияющие на производительность труда. В статье полностью игнорировались взаимодействия между этими 29 переменными. Там говорилось, что «анализ переменных проводился независимо друг от друга, возможность корреляции переменных и эффекты этого взаимодействия во внимание не принимались». Таблица 3, приведенная в статье, имела такую первую строчку:

Медиана 50 % Квартили 25–75 % Строки исходной программы за один человеко-месяц 274 150–440

Теперь мне хочется дать свои комментарии по поводу этой статьи. Рассмотрено менее одного завершенного проекта в расчете на одну вычислительную машину. Каждый из рассмотренных языков применялся в 2.1 проекте. Различия в масштабах были даже большими, чем от 4000 до 467 000 строк. Космические проекты Хьюстона были разделены на несколько «программ», каждая из которых имела отдельный отчет. Но работать по отдельности они не могли.

В одной таблице были сведены средние (медианные) значения отношения числа строк к человеко-месяцам; таблица, показывавшая 29 наиболее важных переменных, содержала именно средние значения. В табл. 3, приведенной выше, отбрасывались верхние и нижние 25 % значений. Все это делало данные гораздо более регулярно выглядящими, чем это есть на самом деле. Цифры, собранные на стр.291 в графе оценок производительности, показывают невероятно широкий диапазон производительности, это осталось для нас непонятным.

В статье не рассматриваются рабочие программы. Но именно они являются результатом работы, а не исходные программы. В базе данных есть сведения по рабочим программам. Игнорировать рабочие программы, значит также игнорировать коэффициент повышения производительности, вносимый языками высокого уровня. Язык программирования не вошел в 29 наиболее важных факторов. Но так дело обстоит только в статье, а не в реальной жизни. Кстати говоря, среди того, что особенно поразило нас после того, как мы впервые просмотрели базу данных, была доля программных проектов, в которых все еще использовались ассемблеры. Таких было более 50 %.

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

В статье говорится, что никакие взаимовлияния переменных не рассматриваются. Но ведь очевидно, что такое взаимодействие существует!

В статье предполагается, если не прямо утверждается, что фактором, влияющим на производительность в наибольшей степени, является «сложность взаимодействия с заказчиком». Таблица содержит строку с таким заголовком и некоторые числа; никаких комментариев в тексте нет. Известно, что учитывались отчеты, поступившие с разных концов света. База данных составлялась в Гейтсбурге, шт. Мэриленд, — крупнейшие разработки проводились в Хьюстоне, шт. Техас; Атлантик-Сити, шт. Нью-Джерси; Лос-Анджелесе, шт. Калифорния; а также в Моррис-Плейне, шт. Нью-Джерси. Мы решили, что оценить фактор взаимодействия с заказчиком иначе, как заявив, что он выше «нормальной сложности», невозможно. Нам не удавалось сравнить мнения руководителей из Техаса с мнением руководства в Лос-Анджелесе или в Сайгоне, или в Токио. Их мнения были чересчур личными.

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

Я видел три документа — книгу, авторский экземпляр и статью, в которых данная статья цитировалась неверно! В этих документах утверждалось, что «фирма IBM говорит то-то и то-то». IBM никогда этого не говорила.

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

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

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

Хорошей базы данных, из которой можно было бы извлекать достоверные сведения, в настоящее время не существует. Данные, имеющиеся в нашем распоряжении, поразительнейшим образом отличаются по уровню достигнутой производительности труда, а почему это так, мы не понимаем. Уровни производительности труда в рамках одной и той же работы могут доходить от 100 °СТП за человеко-месяц до 6 °СТП за человеко-месяц. Мы до сих пор не понимаем причины таких расхождений.

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

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