Становление элементов промышленной технологии программирования в проекте создания оптимизирующего транслятора альфа-6 (1968-1972 годы)

Т. C. Васючкова

Проект по разработке оптимизирующего транслятора с языка АЛЬФА-6 на ЭВМ БЭСМ-6 был начат в январе 1968 г. Как позже признавались его руководители — акад. А.П. Ершов, д.ф.-м.н. И.В. Поттосин, Г.И. Кожухин — это была довольно авантюрная идея: сделать транслятор силами студентов механико-математического факультета Новосибирского государственного университета. Задача сложная и объемная — конечный объем системы составил 150 000 строк. Стартовый опыт студентов в программировании почти нулевой. В качестве образца использовался уже существующий транслятор АЛЬФА. Однако результат оказался успешным. Созданный транслятор эксплуатировался в ряде организаций для решения научных и прикладных задач. Одним из основных его потребителей стал Институт Атомной Энергии им. И.В. Курчатова (Москва).

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

1. При согласовании рабочих вопросов возникло сразу несколько проблем. Во-первых, десять исполнителей совершенно нерационально использовали время на бесчисленные споры, обсуждения, заседания. В необходимости обсуждений сомнений не было. Но каждый выходил на заседания со своими проблемами и ждал их немедленного решения. Результативность таких собраний была невысокой. И первый урок менеджмента, полученный нами, был тот, что заседания надо тщательно готовить и приходить на них с конкретными вариантами решений. Во-вторых, локальные договоренности между двумя-тремя участниками проекта не всегда своевременно доводились до остальных исполнителей. Это могло приводить к ситуации, когда член команды, считавший, что он успешно продвигается вперед, вынужденно переделывал работу. В-третьих, решения по текущим проблемам часто оформлялись на бумаге в виде черновых записок, хранились рассредоточено и могли затеряться. Мы довольно быстро отреагировали на эти трудности. Решили, что всю текущую документацию надо хранить централизованно и поддерживать в актуальном состоянии. А инструментом единой коммуникативной среды сделали некое подобие «бортового журнала», назвав его «Книга жалоб и предложений». Это была амбарная книга, в которую каждый мог занести в письменном виде все проблемы, новые идеи, объявления об изменениях, заявки на общие заседания и прочее. Каждый член команды в обязательном порядке ежедневно читал эту книгу и учитывал ее при планировании своей работы. Координатором проекта был один из студентов. Он отвечал за организацию решения проблем, внесенных в «Книгу жалоб и предложений», определял сроки и график работ, готовил рабочие заседания, контролировал исполнение работ. Такая единая среда общения участников проекта была организована в «бумажном виде», а не в электронном — ведь персональных компьютеров еще не было! Она оказалась очень удобной и полезной — помогала оперативно решать вопросы, позволяла видеть прогресс работ и болевые точки, давала общую картину проекта на сегодняшний день. В современных технологиях разработки программ есть разные средства и инструменты, которые уже в электронном виде поддерживают идею централизованной коммуникативной среды участников программного проекта.
2. По предложению руководителей проекта была определена отдельная ролевая функция разработки единых стандартов представления информации, которой обмениваются блоки транслятора. В терминах нынешних технологий это называется — внутренние интерфейсы программной системы. В технологическом аспекте важным уроком для нас стало то, что создание внутренних интерфейсов должно предшествовать реализации отдельных частей системы. Сейчас это звучит совсем тривиально, но в те времена мы на собственных синяках и шишках хорошо усвоили, что отсутствие полной договоренности о внешних связях может повлечь многократные переделки твоей работы.
3. В рамках проекта была создана независимая служба тестирования. Ее задачами стали разработка и развитие единой системы тестов, а также разработка системы автоматизации тестирования. К тому времени как раз вышли классические работы Г. Майерса по надежности и тестированию программ, идеи которых мы использовали в своем проекте. На собственных трудностях и ошибках мы поняли, что
   1. тестирование автором своей части программы является лишь начальным, «черновым» этапом перед систематической проверкой программы;
   2. тестирование — самостоятельная дисциплина со своими методами, стратегиями, инструментами;
   3. принципиально, что служба тестирования независима, так как тестовик — это враг программы (по Майерсу). Автор программы, составляя тесты, подсознательно пытается доказать, что у него все правильно. Тестовик же находится на иной психологической позиции: он хочет показать, что программа неправильна и составляет другие, «разрушительные» тесты;
   4. все перечисленное актуально для серьезных коллективных проектов. Создавая небольшую программу, автор сам исполняет роль тестовика.
4. К 1971 г. транслятор АЛЬФА-6 успешно использовался в нескольких организациях. От Института Атомной Энергии им. Курчатова поступило пожелание: дополнить транслятор новыми возможностями — развитым текстовым редактором, архивной подсистемой, хорошим отладчиком, диалоговой подсистемой запуска заданий. Теперь это называется «оболочкой транслятора». К тому времени примерно половина исполнителей ушла из проекта, защитив диплом и окончив НГУ. Оставшиеся готовились к завершению работ и передавали систему службе сопровождения.

А. П. Ершов выступил с предложением создать оболочку транслятора в очень короткий срок (3 месяца), используя новую идею Х. Миллза ролевого разделения работ в проекте. Первоначально автор назвал этот подход методом хирургической бригады, сейчас его чаще называют методом главного программиста. Традиционный подход нами уже был использован — транслятор делился на подзадачи, и каждый исполнитель полностью отвечал за свою подзадачу, выполняя роли проектировщика, кодировщика, тестовика. В новом методе работ все было непривычно и интересно — любая подзадача решалась целой бригадой, каждый член которой выполнял только отдельную функцию (роль) или несколько ролей. Четверо участников проекта с большим энтузиазмом решили на практике испытать метод Миллза — образовали бригаду и разделили между собой 10 ролей.

Завершив работу за 3 месяца (объем 28000 строк), мы оценили высокую пользу от разделения труда в программном проекте. Средняя производительность труда при разработке транслятора традиционным методом составила 5000 строк/чел-год, а при разработке оболочки транслятора методом Миллза составила 28000 строк/чел-год. Конечно, было бы неправильно сравнивать эти данные напрямую — ведь за 3 года существенно выросла наша квалификация, да и задачи различаются сложностью. Но по нашимобсуждениям и впечатлениям метод Миллза может увеличить производительность труда программиста в 2–3 раза, если удачно выбрана кандидатура главного программиста.

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

Удивительно, что результативность разделения труда в программировании нам удалось увидеть в рамках одного проекта АЛЬФА-6. На первой стадии работ эффективным стало выделение ролей координатора, тестовика, разработчика внутренних интерфейсов. На второй стадии проекта мы увидели, что выгодно специализировать в качестве ролей все функции разработчиков.

В заключение интересно отметить, что время проекта АЛЬФА-6 пришлось на знаменитый «кризис программирования» в 70-х гг. Тогда резко подешевевшие компьютеры были востребованы для решения не только вычислительных задач. Спрос общества на компьютерную автоматизацию деятельности в самых разных сферах резко возрос, а профессиональные программисты обнаружили, что их собственный труд автоматизирован минимально, что разработка программ не может быть названа промышленной деятельностью.

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

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

Основные публикации по проекту

1. Кожухина С.К., Козловский С.Э. Входной язык АЛЬФА-6 / Под ред. И.В.Поттосина. — Новосибирск, ВЦ СО АН СССР, 1976. — 109 с.
2. Аникеева И.Н., Буда А.О., Васючкова T.C., Кожухина C.K., Козловский C.Э., Шелехов В. И. Руководство к пользованию системой автоматизации программирования АЛЬФА-6 / Под ред. А. П. Ершова. — М.: Наука, 1979. — 351 с.

ПЕРСОНАЛИИ

Руководители проекта АЛЬФА-6: А.П. Ершов, Г.И. Кожухин, И.В. Поттосин.

Исполнители: И.Н. Аникеева, С.Ф. Богданова, A . O . Буда, Т.С. Васючкова, В. Грибачевская, А. A . Грановский, А. A . Ерофеев, Л. Жукова, С. K . Кожухина, С.Э. Козловский, В. Коростелева, К. Макаров, Е. Мельникова, Н. A . Сизова, Т.И. Шведова, В.И. Шелехов, Т. Янчук.

Следующая статья сборника

Из сборника "Новосибирская школа программирования. Перекличка времен". Новосибирск, 2004 г.
Перепечатываются с разрешения редакции.