А.Н. Терехов

Технология программирования

Учебное пособие

5-е издание (электронное)

Интернет-Университет
Информационных Технологий
www.intuit.ru

Ай Пи Ар Медиа

Москва

2024

УДК 004
ББК 32.97

Терехов, А.Н.
Технология программирования : учебное пособие / А.Н. Терехов. — 5-е изд. (эл.) —
Москва : Национальный Открытый Университет «ИНТУИТ» : Ай Пи Ар Медиа, 2024. —
148 с. — Текст : электронный.

ISBN 978-5-4497-3349-8
В учебном пособии в достаточно популярной форме излагаются основные аспекты
жизненного цикла создания и сопровождения программных продуктов, организации
коллективов программистов, сведения о стандартах качества. Как пример наиболее трудной,
по мнению автора, задачи в этой области рассматриваются вопросы создания встроенных
систем реального времени.
Предназначено для студентов, обучающихся по направлению подготовки
«Математическое обеспечение и администрирование информационных систем».

Учебное электронное издание
Технический редактор А.А. Балакирева
Обложка С.С. Сизиумова, Я.А. Кирсанов

Подписано к использованию 16.07.2024.

© ООО «ИНТУИТ.РУ», 2005–2017
© Терехов А. Н., 2005–2017
© Оформление электронного издания.
ООО Компания «Ай Пи Ар Медиа», 2024

Предисловие
Основу д а н н о й книги составляет курс л е к ц и й , который вот уже м н о ­
го лет я читаю на отделении и н ф о р м а т и к и математико-механического
факультета СПбГУ. Технология п р о м ы ш л е н н о г о программирования —
не совсем обычная тема для мат-меха, сама постановка такого курса была
вызвана несколькими причинами:
• было замечено, что многие выпускники н е могут сразу приступить к
производительной работе, н е понимают необходимости жесткого
планирования и н е менее жесткой отчетности, н е чувствуют особен­
ностей работы в команде, н е знают, что такое бюджет и т.д.
• преподаватели университета часто н е имеют опыта р а б о т ы в про¬
мышленности, поэтому учат студентов на академическом уровне,
«по книжкам»;
• наконец, первые ж е столкновения с п р о м ы ш л е н н ы м и задачами по¬
казали, что п р о м ы ш л е н н ы е технологии требуют совершенно иных
приемов программирования, других инструментальных средств и
организационных методик. И м е н н о по этим п р и ч и н а м возникла но¬
вая наука — software engineering (программная инженерия), сильно
отличающаяся от ставшей уже традиционной computer science.
Так получилось, что с 1980 года я стал работать с в о е н н ы м и органи­
зациями Ленинграда. Первоначально это была настоящая «принудилов­
ка», похожая на столь ж е обязательную в те времена «картошку». Только
через несколько лет я понял, что судьба преподнесла м н е подарок, дав
возможность поработать с н о в ы м и людьми, задачами, с совершенно не¬
о б ы ч н ы м и для университетов требованиями и технологиями. В то время
я возглавлял лабораторию системного программирования Н И И М М ЛГУ,
в которой работало около 15 человек. Нашему коллективу пришлось при¬
нять вызов и заняться исследованиями и разработками в новой для себя
области. М ы успешно р е ш и л и множество важных государственных задач,
разработали и внедрили п р о м ы ш л е н н ы е технологии, воспитали большое
количество специалистов. Надеюсь, после этих слов н и у кого н е возник¬
нет вопрос, почему университетский профессор читает л е к ц и и и пишет
книгу о п р о м ы ш л е н н о м программировании.

Благодарности
Прежде всего я хочу поблагодарить уже ушедших из ж и з н и капитана
I ранга, доктора технических наук, профессора Владимира Петровича
Морозова и академика Андрея Петровича Ершова. В.П. Морозов был
первым, кто пришел в н а ш коллектив с задачами п р о м ы ш л е н н о г о про¬
граммирования, очень во многих случаях о н опередил свое время. Такие
его идеи как контроль за ходом разработки, графическая схема ситуаций,
динамическая группа и др. в начале 1980-х годов было трудно оценить.
Я счастлив, что в отличие от многих коллег, сумел разглядеть за «ко¬
мандирским голосом» зерна будущих технологий.
А.П. Ершов вообще был м о и м «крестным отцом». Ч е м - т о я ему п о ­
нравился, во всяком случае, много лет о н предлагал м н е интересные зада¬
чи, вел со м н о й увлекательные л и ч н ы е беседы, вовлекал во многие свои
н а ч и н а н и я , например, школьную информатику. О н был председателем
Рабочей группы по Алголу 68, а я был его замом. 4-5 раз в год м ы собира¬
лись в разных городах СССР, общались на самые р а з н ы е темы, часто да¬
лекие от Алгола 68. Каждое собрание кончалось традиционной индейкой
— А.П. Е р ш о в был самым активным участником и этого события. Когда
передо м н о й встала зловещая, к а к м н е тогда казалось, перспектива рабо­
ты с в о е н н ы м и , первым, к кому я обратился за советом, был А.П. Ершов.
О н поддержал меня, назвал нескольких известных ученых, которые были
генералами и адмиралами, чего я , конечно, не знал. Более того, позднее
он п р и н я л участие в наших работах.
Я благодарен всем участникам нашего, сильно разросшегося, колле­
ктива. П р о м ы ш л е н н а я технология — дело коллективное, в одиночку тут
ничего не сделать.
Благодарю В.И. Кияева за материалы л е к ц и й по качеству П О , моего
коллегу из С Ш А Лена Эрлиха, который как-то раз прочел м о и м студен­
там замечательную л е к ц и ю по CASE-технологиям. Всегда интересен
взгляд на известные вещи с другой стороны.
Н о больше всего я благодарен своим детям — Андрею Терехову (мл.)
и К а р и н е Тереховой, которые когда-то были м о и м и учениками, а теперь
уже много лет являются м о и м и главными критиками, рецензентами и со¬
ветчиками.

4

Об а в т о р е
Терехов Андрей Николаевич
Родился 3 сентября 1949 года. В 1971 г. с отличием окончил Ленин¬
градский государственный университет по специальности «Математиче¬
ское обеспечение ЭВМ».
Начиная с 1971 года прошел путь от младшего научного сотрудника
до заведующего лабораторией системного программирования ВЦ ЛГУ. В
1984 году организовал совместный комплексный отдел Минобразования
Р С Ф С Р и М и н п р о м с в я з и СССР, на базе которого был создан Н И И «Звез­
да» Л Н П О «Красная заря». В этом Н И И А.Н. Терехов был назначен заме­
стителем директора (по совместительству). В 1991 году основал и возгла¬
вил Г П «Терком». В 1996 году возглавил созданную и м кафедру системно¬
го программирования СПбГУ. С момента создания в 1998 году ЗАО «Ланит-Терком» — генеральный директор к о м п а н и и . В 2002 году организовал
и возглавил Н И И и н ф о р м а ц и о н н ы х технологий СПбГУ. В сентябре 2004
года избран председателем правления ассоциации разработчиков п р о ­
граммного обеспечения РУССОФТ, созданной на базе консорциума
Ф О Р Т - Р О С С и ассоциации РУССОФТ.
Доктор физико-математических наук, профессор, академик Между¬
н а р о д н о й академии и н ф о р м а т и з а ц и и . Ч л е н A C M и I E E E Computer
Society.
Женат, отец д в о и х детей. Д о ч ь К а р и н а о к о н ч и л а с о т л и ч и е м
математико-механический факультет С П б Г У и аспирантуру Оксфорд¬
ского университета, там ж е защитила докторскую диссертацию. В насто¬
я щ е е время — менеджер высокого уровня в к о м п а н и и Nokia. С ы н закон¬
чил с отличием математико-механический факультет СПбГУ, кандидат
физ.-мат. наук, менеджер п о связям с университетами России в к о м п а н и и
Microsoft (Москва).
Хобби — баскетбол, водный туризм.

5

Содержание
Часть I. Общие вопросы технологии программирования

9

1. П о н я т и е технологии программирования

9

2. Ж и з н е н н ы й цикл программы

14

3. Постановка задачи. Оценка осуществимости

17

4. П л а н и р о в а н и е

20

5. Управление

26

6. Тестирование, обеспечение качества

30

7. Групповая разработка, управление версиями

35

8. Психология программирования

38

9. Организация коллектива разработчиков

41

10. Организация коллектива разработчиков в к о м п а н и и Microsoft. . . . 44
11. Документирование

49

12. Сопровождение

51

13. Р е и н ж и н и р и н г

53

14. Управление качеством

56

15. Стандарты ISO

63

16. Capability Maturity Model for Software (Модель SEI S W - C M M ) . . . . 67
17. CASE-технологии

73

Часть II. Технология программирования
встроенных систем реального времени

80

1. П о н я т и е встроенной системы реального времени

80

2. Инструментальная и целевая Э В М

82

3. К о м п л е к с вычислительных средств

84

4. Параллельные процессы

89

5. Работа с временными интервалами

93

6. Организация вычислительного процесса

95

7. Технология R T S T

99

8. Технология R E A L

106

Литература

110

6

Приложения: интервью, статьи, доклады, об авторе

113

К а к готовить системных программистов

114

Индустриальная программа подготовки IT-кадров на базе
кафедры системного программирования С П б Г У

134

Наукоград и технопарки в Петергофе

139

Н а ц и о н а л ь н ы е черты производства П О

142

Говорят коллеги: Игорь Агамирзян

145

Говорят коллеги: Валентин Макаров

147

7

8

Понятие технологии программирования

Часть I. Общие вопросы технологии
программирования
1 . Понятие т е х н о л о г и и п р о г р а м м и р о в а н и я
Технология — это набор правил, методик и инструментов, позволя­
ю щ и х наладить производственный процесс выпуска какого-либо продукта
[1]. Разумеется, это определение нельзя назвать п о л н ы м . Надо у п о м я ­
нуть процессы п л а н и р о в а н и я , измерения, о ц е н к и качества, ответствен­
ность исполнителя и многое другое. Н о в м о ю задачу н е входит н а п и с а ­
н и е статьи для э н ц и к л о п е д и и на слово «технология» — я дал какое-то
представление о его значении и для начала разговора этого вполне хва­
тит. Подчеркну только еще раз производственный характер п о н я т и я
«технология». Почему-то и м е н н о слово «производство» сильно раздра­
жает моих коллег-математиков, з а н и м а ю щ и х с я п р о г р а м м и р о в а н и е м .
«Ты бы еще технологию создания романа «Война и мир» создал». Неда¬
р о м ж е известный специалист Дональд Кнут назвал свой з н а м е н и т ы й
м н о г о т о м н ы й труд «Искусство программирования». Н а к о н е ц , мне уда­
лось выяснить отношение к этому понятию самого Д. Кнута. Несколько
лет назад н а ш университет присвоил этому н е с о м н е н н о блистательному
ученому звание почетного доктора. П о такому случаю н а ш д е к а н собрал
для встречи с Д. Кнутом десять-двенадцать руководителей лабораторий и
заведующих кафедрами, и м е ю щ и х о т н о ш е н и е к программированию. Де¬
ло было летом, Д. Кнут был с ж е н о й , переводчица поминутно смотрела
на часы, н а п о м и н а я , что гостям пора «на фонтаны», сам почетный д о к ­
тор откровенно дремал, словом, это было скучнейшее мероприятие. Я
р е ш и л пошутить, чтобы как-то развеять унылую атмосферу. И когда п о ­
д о ш л а моя очередь выступать, я вместо тридцатисекундного перечисле­
н и я заслуг нашего коллектива сказал, что л и ч н о м н е профессор Кнут д о ­
ставил много неприятностей. Тот аж подскочил: «Я же в первый раз вас
вижу!» Тут я объяснил, что много лет занимаюсь п р о м ы ш л е н н о й техно­
логией программирования, а многие коллеги, включая и тех, кто сидит
сейчас за этим столом, ссылаясь на его книгу, не признают это наукой,
и м е ю щ е й о т н о ш е н и е к математике. П р о ф е с с о р очень разволновался,
п р и н я л м о ю шутку вполне всерьез и пожаловался, что все это происхо­
дило и с н и м : «Вы знаете, что я много лет занимался созданием и продви­
ж е н и е м на р ы н о к издательской системы T E X ? Это что — не производст­
во? Могу я на старости лет написать к н и ж к у с теоремами?»
В общем, я получил огромный заряд положительных э м о ц и й .
9

Курс

Технология программирования

Разумеется, я п о н и м а ю , что Д. Кнут известен скорее своими теоре¬
тическими работами, а T E X — это скорее от безысходности, о н задумал
его после выпуска первого тома «Искусства программирования», поража­
ясь скудости р ы н к а инструментальных средств для набора математиче­
ских текстов, прервался на несколько лет для реализации T E X и только
потом продолжил свой титанический труд. Для него п р о м ы ш л е н н о е про¬
граммирование — скорее бравада, что вот, мол, м ы все можем, но все рав¬
но приятно получить поддержку от такого знаменитого ученого.
Мое первое столкновение с промышленностью состоялось в 1980-м
году. К тому времени я уже несколько лет руководил лабораторией с и с ­
темного программирования, занимались м ы самыми трудными пробле¬
мами, часто и м е ю щ и м и весьма отдаленное о т н о ш е н и е к практике, но нас
это нисколько не беспокоило. «Мат-мех — лучше всех» — в глубине души
я и сейчас в этом уверен. Так вот, в декабре 1980-го года меня пригласили
в кабинет ректора ЛГУ, там было человек двадцать в военной ф о р м е и
несколько партийных деятелей во главе с начальником оборонного отде­
ла Обкома К П С С . М н е было сказано, что оборонная промышленность
столкнулась с массой проблем при создании программного обеспечения
( П О ) систем оборонного назначения, поэтому р е ш е н о , что ЛГУ в лице
нашей лаборатории должен помочь. Моего согласия никто не спрашивал,
да в те времена этого и не требовалось. Так я начал работать с Л Н П О
«Красная Заря», «Импульс», «Морфизприбор», «Ленинец», «Аврора»,
«Гранит» — ведущими предприятиями Ленинграда, работающими в инте¬
ресах различных родов войск и ведомств. С большинством этих предпри¬
я т и й м ы работаем до сих пор.
Нас использовали как «пожарную команду». М н о г о лет сотрудники
названных и других предприятий разрабатывали П О для важных заказов,
когда же все сроки (и деньги!) истекали, приглашали нас, чтобы м ы наве¬
ли порядок. Нельзя сказать, что до этого м ы ж и л и в башне из слоновой
кости. У нас были договора с Н И Ц Э В Т по созданию транслятора с я з ы к а
Алгол 68[2] для только что созданного (мы говорили «создранного») се­
мейства Е С Э В М , так что м ы одними из первых освоили новую операци­
онную систему OS/360. Пользуясь открытостью университета, к н а м все
время приходили какие-то люди (в том числе и военные) с просьбой н а й ­
ти ошибку в программе. Н е было случая, чтобы м ы искали ошибку боль¬
ш е двух дней.
Н о все это не идет н и в какое сравнение с трудностями нашего п о ­
н и м а н и я проблем реальной промышленности. Одно дело, когда у тебя
в подчинении пятнадцать человек в университетской лаборатории, кото­
рых никогда не надо подгонять, сомневаться в их способностях, когда ца­
рит дух соревнования (не только между собой), когда все понимают друг
друга с полуслова. Совсем другое дело — триста человек с совершенно
10

Понятие технологии программирования

р а з н ы м и способностями и образованием, я в н о отсиживающие свои во¬
семь часов, работающие в кодах (буквально с инженерного пульта Э В М ) ,
причем все это погружено в атмосферу секретности. М н е никогда не за¬
быть, к а к одна ж е н щ и н а целый час объясняла м н е схему распределения
памяти, которую она вычитала у одного японского автора. С большим
трудом удалось выяснить, что она имеет в виду стек. Другой программист
запомнился м н е тем, что для возврата из процедуры использовал регистр
Р7, хотя остальные триста человек для этой цели п р и м е н я л и Р10. О н еще
доказывал, что и м е н н о он прав, так как Р7 — индексный регистр, поэто­
му передача управления по его содержимому выполняется на целую м и к ­
росекунду быстрее. М н е так и не удалось объяснить ему важность соблю­
дения соглашения о связях.
П е р в ы м и из военных организаций к н а м обратились сотрудники
Л Н П О «Красная Заря» с просьбой помочь в программировании ш и р о к о ­
го класса задач управления и связи, в частности, в создании ф у н к ц и о ­
нального программного обеспечения ( Ф П О ) телефонных станций, упра­
вляемых специализированными Э В М ( С Э В М ) . Несколько лет ушло на
изучение предметной области, пробные реализации и р е ш е н и е организа¬
ц и о н н ы х вопросов. У сотрудников ЛГУ был исходный п р и н ц и п важности
использования алгоритмических я з ы к о в высокого уровня (АЯВУ), осно¬
в а н н ы й на опыте предыдущей работы. Однако начинать пришлось совсем
не с этого, а с п о в ы ш е н и я общей культуры программирования разработ¬
чиков Ф П О . Дело в том, что в области встроенного Ф П О реального вре¬
м е н и традиционно используются С Э В М с нестандартной архитектурой,
ориентированной на заданную предметную область (правда, н е я с н о ,
в чем должна выражаться такая ориентация: например, если Э В М хорошо
выполняет какие-то специальные операции, но плохо — условные пере­
ходы и вызовы процедур, которые встречаются гораздо чаще, м о ж н о ли
считать, что данная Э В М соответствует предметной области?). Нестан­
дартность архитектуры и малая тиражность таких С Э В М приводят к от­
сутствию достаточно развитых о п е р а ц и о н н ы х систем, трансляторов,
средств отладки и других, ставших уже п р и в ы ч н ы м и , инструментов про¬
граммирования. Поэтому м ы столкнулись с работой на перфокартах и
непосредственно за пультом С Э В М «на тумблерах».
М ы пытались воспользоваться известными в то время технологиями,
однако оказалось, что, например, Р-технология [3] не имеет никаких
средств настройки на С Э В М , а предлагаемые в ней графический стиль про­
граммирования и программа-организатор с ручным вводом мало помогают
в решении задач реального времени; технология РУЗА позволяет автомати¬
зированным образом (но с большими доработками) построить кросс-ас¬
семблер нужной ЭВМ и интерпретатор ее системы команд, а также осущест­
вить некоторую регламентацию работы (например, стандартизовать имена
11

Курс

Технология программирования

объектов). Р-технология была отвергнута практически сразу (за неимением
конкретных программных средств на заданных нам СЭВМ), РУЗА в течение
полугода была настроена на одну С Э В М , однако полностью учесть все осо¬
бенности С Э В М так и не удалось; кроме того, параметрически настраивае­
мые кросс-ассемблер и интерпретатор замедляют работу в 5-7 раз.
М ы р е ш и л и , что из-за таких простых программ, как ассемблер,
не стоит «городить огород», и за короткое время реализовали новые
кросс-ассемблер и интерпретатор, которые вместе с текстовым докумен¬
татором и некоторыми сервисными программами составили основу пер¬
вой внедренной н а м и в производство (1984 год) технологической систе­
м ы , интенсивно использовавшейся сотнями разработчиков Ф П О . Разу­
меется, м ы отчетливо понимали ограниченность возможностей такой
технологии, но ее популярность имела свои п р и ч и н ы :
• п р и м е н е н и е вместо С Э В М ш и р о к о доступной ЕС Э В М с м н о г о ­
пользовательской О С и ш и р о к и м и сервисными возможностями;
• работа одновременно многих пользователей за терминалами, а не с
перфокартами;
• богатые отладочные возможности интерпретатора С Э В М , недости¬
ж и м ы е непосредственно на С Э В М ;
• впервые осознанная разработчиками Ф П О ценность документации
на м а ш и н н о м носителе, легкость ее о ф о р м л е н и я , исправления и т и ­
ражирования;
• практически неограниченные возможности развития технологии,
удивительно быстро схваченные разработчиками Ф П О , в результате
чего практически ежемесячно появлялись новые идеи и предложе­
н и я , большинство из которых было быстро реализовано.
На протяжении всей совместной работы сотрудников ЛГУ и «Крас­
ной Зари» имело место противостояние двух п о з и ц и й относительно п о ­
нятия технологии программирования. Сотрудники ЛГУ, в основном, под¬
разумевали под н и м ш и р о к о е использование инструментальных средств,
а сотрудники «Красной Зари» настаивали на том, что технология — это,
прежде всего, набор формальных методик и регламентирующих средств,
позволяющих, в частности, на каждом этапе провести экспертизу, архива¬
ц и ю и измерение объема и качества проделанной работы. Такой подход
вызывал постоянное раздражение профессиональных программистов.
Разумеется, м ы п о н и м а л и , что работа без четких сроков и ответст­
венности перед соисполнителями возможна только исследовательская
и экспериментальная, да и то в ограниченных объемах, но работа по кон¬
кретным заказам в п р о м ы ш л е н н о с т и дала массу новых впечатлений и им¬
пульсов для изучения. Н а п р и м е р , уход исполнителя в самом разгаре ра­
бот. Оказалось, что в п р о м ы ш л е н н о с т и это довольно частое я в л е н и е (от­
сюда необходимость архивации и других средств отчуждения результатов
12

Понятие технологии программирования

работы от исполнителя); в коллективе из нескольких сот человек всегда
есть люди, попросту не ж е л а ю щ и е работать, и хотя м ы понимаем, что
оценка работы программиста в байтах весьма сомнительна, это не отме¬
няет необходимости учета индивидуально в ы п о л н е н н о й работы (измере¬
ние). Даже такое «приземленное» соображение, к а к разделение ответст¬
венности за п р и н я т ы е р е ш е н и я и о ш и б к и , также нельзя сбрасывать со
счетов (отсюда строгое документирование).
Особенно много разночтений вызывала необходимость оформления
постановки задачи по стандартным правилам. Дело в том, что аккуратное
оформление требует усилий, причем не только технического порядка,
а программисту кажется, что, имея в руках такой м о щ н ы й инструмент,
как АЯВУ, легче сразу выразить свое п о н и м а н и е задачи в программе, а
не в каких-то таблицах и диаграммах. Н о непосредственное программи¬
рование лишает программиста обратной связи с функционалистом (по­
становщиком задачи) и уж тем более — с заказчиком. Большинство слож­
ных систем невозможно сдать в эксплуатацию из-за огромного количест­
ва сравнительно мелких замечаний, вызванных разночтениями и н е я с н о ­
стями в постановке задачи.
М ы настаивали на том, что, занимаясь вопросами документирова­
н и я , ценообразования, способами регламентирования и контроля за хо­
дом работ, нельзя забывать, что о с н о в н ы м результатом п р и м е н е н и я тех­
нологии является программа, действующая в заданной вычислительной
среде, хорошо отлаженная и документированная, доступная для п о н и м а ­
н и я и развития в процессе сопровождения («нам нужны не приборы
в п р и н ц и п е , а приборы в корпусе»).
Только после двух-трех лет работы в п р о м ы ш л е н н о с т и м ы осознали,
что нельзя все сводить к программному инструментарию. Поначалу м ы с
гневом отказывались от требований начальства детально документиро¬
вать, кто, что и за какой период написал, но оказалось, что в большом
коллективе всегда находятся милые в о б щ е н и и , всеми л ю б и м ы е органи­
заторы всевозможных мероприятий, которые вообще ничего не делают
по работе. Первую сдачу проекта для Управления правительственной свя­
зи К Г Б я завалил, так как буквально перед самой сдачей кто-то стащил
одну (!) перфокарту, а эти товарищи всегда начинали с чистой м а ш и н ы
и полной перетрансляции. Вредителя так и не н а ш л и , зато я получил хо¬
р о ш и й урок. М ы быстро реализовали контрольно-учетные программы,
архивы с контролируемым доступом, многоуровневые системы сбора вер¬
сий П О и тому подобные «шпионские штучки». Так я впервые осознал
разницу между «программированием для себя» и «программированием
для хозяина», о которой так красочно рассказывал академик А. П.Ершов.
В более поздних публикациях эту разницу стали выражать более к а н ­
целярским стилем — просто программа и программный продукт.
13

Курс

Технология программирования

2. Ж и з н е н н ы й ц и к л п р о г р а м м ы
Итак, м ы знаем, что программный продукт является результатом
некоего производственного процесса. Этот процесс нужно спланировать,
оценить ресурсы, для чего, в свою очередь, требуются более или менее
точные с п е ц и ф и к а ц и и , что ж е необходимо заказчику. Затем продукт надо
спроектировать в виде системы, состоящей из многих компонентов, о п и ­
сать ф у н к ц и и этих компонентов и их связи между собой, после чего ком¬
п о н е н т ы нужно запрограммировать, автономно отладить, собрать вместе,
провести комплексную отладку, подготовить документацию на систему,
обучить пользователей, провести опытную эксплуатацию и организовать
сопровождение системы на весь период ее эксплуатации.
Разумеется, это л и ш ь приблизительная схема, которая может варьи­
роваться в ш и р о к и х пределах, н о , тем не менее, она дает представление
о том, что такое «жизненный цикл программы» ( Ж Ц П ) [4]. Почему
«цикл»? Потому что редко разработка развивается столь п р я м о л и н е й н о ,
хотя одну из первых моделей Ж Ц П действительно назвали «водопадная»,
подчеркивая тот факт, что к предыдущей фазе проектирования вернуться
невозможно. Действуя по этой модели, коллектив последовательно разра¬
батывает проект — от исходной к о н ц е п ц и и до комплексного тестирова¬
ния. Модель требует определить о п о р н ы е точки, в которых будет о ц е н и ­
ваться сделанное и решаться вопрос о том, м о ж н о ли двигаться дальше.
Такой подход хорош для проектов, в которых требования легко формули­
руются с самого начала, но не годится для сложных, когда требования м о ­
гут неоднократно меняться. К р о м е того, водопадная модель вынуждает
готовить огромную массу документации и требует единообразной проце¬
дуры о ц е н к и результатов на каждом этапе. Эти две особенности часто
приводят к синдрому «аналитического паралича», н а п р я ж е н н ы м о т н о ш е ­
н и я м между разработчиками, заказчиками и пользователями.
В реальной ж и з н и , конечно ж е , чисто водопадная модель не п р и м е ­
няется. Появляются новые требования заказчиков, изменяется аппарату­
ра, находятся такие о ш и б к и , которые невозможно исправить, не затронув
результаты предыдущих ф а з и т.д. Развитие системы — это и м е н н о ц и к л и ­
ческое повторение практически всех фаз, п о с т о я н н ы й возврат к предыду­
щ и м фазам. Если не принять специальных мер (что, собственно, и я в л я ­
ется предметом технологии программирования), процесс может стать
бесконечным.
Одной из первых практически полезных моделей Ж Ц П стала модель
создания прототипов. С самого начала разработчики пытаются выделить
основные, существенные требования заказчика и реализовать только их
в виде работающего прототипа системы. Этот прототип демонстрируется
заказчику. Часто бывает, что заказчик в ужасе кричит, что его неправиль14

Жизненный цикл программы

но п о н я л и , он хотел совсем другого, зато теперь он хоть может внятно
сформулировать свои требования, глядя на работу прототипа. Ц и к л раз­
работки и показа прототипа повторяется несколько раз, пока заказчик не
скажет: «Да, это, кажется, то, что м н е нужно». Только после этого дораба­
тываются куски, в ы б р о ш е н н ы е в начале разработки, подготавливается
документация, короче, делаются многие вещи, на которые время было бы
потрачено зря, если бы их делали для самого первого, неудачного прото¬
типа.
Для небольших систем, особенно для тех, в которых велик процент
интерактивных (взаимодействующих с пользователем) компонентов, та¬
кая модель работает, хотя каждый раз, когда я про нее рассказываю, м н е
вспоминается анекдот. Празднуется золотая свадьба. Набежали журнали­
сты, спрашивают: «Как ж е так, все семьи разваливаются, а вы прожили
пятьдесят лет?» Глава семьи отвечает: «Как только м ы поженились, сразу
договорились, что все важные ж и з н е н н ы е проблемы р е ш а ю я , а жена
не спорит, а остальные — решает жена, а я в них не лез. Так и прожили».
Журналисты не унимаются: «А что такое — важные проблемы? Ну, н а п р и ­
мер, назовите проблему, которую Вы решали в последнее время». Глава
семьи отвечает: «Ну к а к ж е , как ж е , недельки две назад я долго р а з м ы ш ­
лял, вернется Далай-Лама в Тибет или нет».
В этом анекдоте, как всегда, отображена вся правда ж и з н и . На моей
памяти много случаев, когда важные аспекты просто упускались при раз¬
работке прототипа, из-за чего позже все приходилось переделывать заново.
Некоторым обобщением модели создания прототипов является с п и ­
ральная модель, в которой разработка приложения выглядит как серия
последовательных итераций. На первых этапах уточняются спецификации
продукта, на последующих — добавляются новые возможности и функ¬
ц и и . Цель этой модели — по о к о н ч а н и и каждой итерации осуществить за¬
ново оценку рисков продолжения работ. Программисты часто увлекают­
ся технической сутью выполняемого проекта и не видят общей картины,
особенно в части производственных затрат. Н а м все кажется, что вот еще
немного, еще чуть-чуть, и все проблемы будут р е ш е н ы , но «асфальтовая
топь» (по выражению Ф. Брукса[5]) засасывает нас, не давая шансов д о с ­
тичь твердых осязаемых результатов. Один мой з н а к о м ы й бизнесмен
представил эту проблему так: «Вот ты затратил 100 000 долларов, но зада¬
чу пока не р е ш и л . Нужно сто р а з подумать, что лучше — истратить еще
столько ж е , чтобы успешно завершить проект, или через год снова ока¬
заться перед тем ж е выбором, но тогда уже с риском потерять не 100 000,
а 200 000 долларов?»
В силу своей итеративной природы спиральная модель допускает
корректировки по ходу работы, что способствует улучшению продукта.
П р и большом числе итераций разработка по этой модели нуждается в глу15

Курс

Технология программирования

бокой автоматизации всех процессов, иначе она становится неэффектив¬
ной. На практике у заказчиков и пользователей иногда возникает ощуще¬
н и е нестабильности продукта, так как о н и не успевают уследить за слиш¬
ком быстрыми и з м е н е н и я м и в нем.
Один очень важный вывод м ы можем сделать даже при таком на¬
чальном знакомстве с понятием Ж Ц П . Собственно программирование
не является единственным занятием коллектива, занятого п р о м ы ш л е н ­
н ы м и разработками. Более того, оно не является даже главным, наиболее
трудоемким делом. М н о г и е исследования отдают на фазу программиро­
вания не более 15-20% времени, затраченного на разработку (сопровож­
дение вообще бесконечно). Может быть, эти ц и ф р ы заставят вас заду­
маться о важности и других аспектов образования — от умения найти и
обосновать э ф ф е к т и в н ы й алгоритм до искусства владения родным язы¬
ком, как устным, так и письменным.

16

Постановка задачи. Оценка осуществимости

3. П о с т а н о в к а з а д а ч и .
Оценка осуществимости
Обычно заказчик выдает две-три страницы текста задания и сразу же
просит оценить время исполнения заказа и его стоимость. Надо быть су­
м а с ш е д ш и м , чтобы на это согласиться. Нередки случаи, когда целые к о л ­
лективы ошибаются в пять-десять раз и попадают в кабалу или теряют
профессиональную репутацию. Ч т о б ы избежать такой ситуации, нужно
предложить заказчику оформить начальный договор на две-четыре неде¬
ли с тем чтобы два-три системных аналитика разобрались в задаче, с по¬
м о щ ь ю каких-то инструментальных средств выполнили д е к о м п о з и ц и ю
системы на к о м п о н е н т ы , прикинули возможные объемы этих к о м п о н е н ­
тов и, соответственно, время их реализации. Такая начальная стадия
Ж Ц П называется «оценкой осуществимости».
М о ж н о , конечно, выполнить эту работу за свой счет (и многие круп¬
н ы е предприятия так и делают), н о , во-первых, о т н о ш е н и е к внутренним
разработкам — более с п о к о й н о е , а, во-вторых, оплаченный договор га¬
рантирует серьезность намерений обеих сторон. К сожалению, часто бы¬
вает, что недобросовестные заказчики пользуются таким приемом, чтобы
бесплатно получить идеи разработки или просто выполнить экспертизу
оценок своих специалистов без всякого намерения передать разработку
на сторону.
Постановка задачи — наиболее творческая часть Ж Ц П , которая под¬
нимает почти ф и л о с о ф с к и е проблемы.
Требуется описать поведение разрабатываемой системы. Эта система
получает какие-то сигналы из ее окружения, поэтому надо описать пове­
дение окружения, но окружение само зависит и изменяется под влияни¬
ем системы, ее сигналов, особенно аварийных.
Разрешают это противоречие, постепенно уточняя поведение как си­
стемы, так и ее окружения. Для действительно важных систем заказчик
требует разработки имитационных моделей системы и окружения, не усту­
пающих по сложности и детальности самой системе. Была у меня однажды
трагикомическая ситуация, когда военные заказчики потребовали модель
системы, точно соответствующую реальной жизни. Н и к а к и е мои объясне­
н и я про сущность моделирования не помогали. Кончилось тем, что я ска­
зал: «Хорошо, я сделаю такую модель, но саму систему делать
не буду. Зачем? Ведь модель и так все делает». Это произвело на них впечат­
ление. Хотя, конечно, стремиться к более точным моделям нужно всегда.
Несколько слов о д е к о м п о з и ц и и системы. Я не устаю удивляться,
насколько точнее оценка сложности системы, которая является суммой
оценок ее компонентов, полученных в результате д е к о м п о з и ц и и , чем
17

Курс

Технология программирования

первоначальная оценка системы в целом. Ведь делают эти о ц е н к и одни
и те ж е системные аналитики, наверняка у них уже было примерное пред¬
ставление о системе и ее компонентах, когда о н и давали первоначальную
оценку. И тем н е менее, эти ж е мысли, положенные на бумагу, особенно с
п о м о щ ь ю каких-то средств формализации, приводят к совершенно дру¬
гому результату.
Однако, формализация формализации рознь. Тридцать лет назад бы¬
товало м н е н и е , что м о ж н о и нужно каждую задачу формально специфи¬
цировать с п о м о щ ь ю логики предикатов чтобы м о ж н о было доказать кор¬
ректность ее р е ш е н и я [6]. Д л я каждой программы P нужно задать преду­
словие A, описывающее состояние среды (в частности, переменных п р о ­
граммы) перед исполнением программы, и постусловие S, описывающее
состояние после завершения ее исполнения:
A {P} S
Очевидно, что A и S — несопоставимы, поскольку описывают состо­
я н и е в разные моменты времени. М о ж н о «протянуть» предусловие A через
текст программы, изменяя его соответственно каждому проходимому
оператору, при этом логическая формула предусловия фантастически б ы ­
стро растет, например, после условного предложения будет д и з ъ ю н к ц и я
двух вариантов, описывающих текущие предусловия после веток then
и e l s e — м ы ж е н е знаем, какая и м е н н о ветка будет исполняться. Обозна­
ч и м результат протягивания через A ' . Тогда остается доказать истинность
и м п л и к а ц и и A ' =>S, и программа корректна! М ы тоже потратили несколь­
ко лет, работая в этом направлении, н а п р и м е р , Н . Ф. Ф о м и н ы х в 1976-м
году защитил под м о и м руководством дипломную работу, реализовав
«протягиватель» для Алгола 68. Все эти предусловия и постусловия были
очень громоздкими — много больше, чем текст программы и затраты на
их создание — тоже.
Собственно доказательством теорем м ы н е занимались, опираясь на
тот факт, что у нас в Ленинграде активно работала одна из лучших в мире
группа математиков Т Р Э П Л О (теоретические разработки эвристического
поиска логического обоснования). М ы пригласили к н а м в лабораторию
системного программирования одного из самых активных ее членов
Ю р и я Маслова — автора наиболее популярного в то время обратного м е ­
тода выводимости [7] — выступить у нас на семинаре. Слушали его целый
день, и к вечеру я осмелился спросить, когда ж е Э В М будет доказывать
не учебные, а настоящие теоремы? Ответ был о ш е л о м л я ю щ и м . С л о ж н ы е ,
но короткие — уже сейчас, д л и н н ы е — никогда. Н а ш практический инте¬
рес к этой теме иссяк. Позже это направление трансформировалось в д о ­
казательство корректности преобразования одной программы в другую,
18

Постановка задачи. Оценка осуществимости

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

19

Курс

Технология программирования

4. Планирование
Результатом фазы оценки осуществимости являются детальная специ­
ф и к а ц и я , план работы и оценка стоимости. Наиболее традиционной ф о р ­
мой плана можно считать сетевой график, который представляется в виде
ориентированного графа с двумя выделенными вершинами — начало и к о ­
нец работы. Вершинами графа являются события, соответствующие пун­
ктам плана, а ребрами — работы. События д о л ж н ы выражаться глаголами
совершенного вида: «тексты программ переданы в базу данных исходни¬
ков», «все тесты пропущены», «группа о ц е н к и качества дала положитель¬
ное заключение» и т.д., но уж никак не «выполняется прогон тестов». Ребра
нагружаются оценками длительности работ, например, в днях или неделях.
Сетевой график — очень удобный инструмент: во-первых, на нем
четко видна зависимость работ друг от друга, во-вторых, на основе сете­
вого графика м о ж н о вычислить длительность всей работы, в-третьих,
пользуясь результатами этих расчетов, м о ж н о попытаться оптимизиро¬
вать длительность и затраты на работу.
Длительность вычисляется следующим образом. Суммируем д л и ­
тельности работ по всем возможным путям в графе. Тот путь от начала
к концу, который является самым д л и н н ы м , объявляется критическим,
потому что задержка любой работы, лежащей на этом пути, приводит к
задержке всей работы в целом. П о н я т н о , что критических путей (с одина¬
ковой длительностью) может быть несколько.
Рассмотрим пример.
Здесь приводится классическая задача планирования: нормально ра­
ботающая, полностью загруженная к о м п а н и я получила заказ, от которо­
го по р а з н ы м п р и ч и н а м невозможно отказаться. Перечислим названия
событий, т.е. узлов в графе:
1 — начало работы;
2 — коллектив сформирован, рабочие места подготовлены;
3 — проектирование завершено;
4 — программирование завершено;
5 — комплексная отладка завершена;
6 — оборудование закуплено;
7 — группа технических писателей получила описание проекта и необхо¬
д и м ы е п о я с н е н и я от проектировщиков;
8 — то ж е для П О , разработка проектной документации завершена;
9 — группа технических писателей получила всю необходимую инфор¬
мацию об интерфейсах с пользователем, разработка программной
документации завершена;
10 — группа оценки качества (Quality Assurance — QA) разработала тесты;
11 — группа Q A оценила проект положительно;
20

Планирование

Начало работы

$24
разработка
набора
тестов

разработка
проектной
докумен¬
тации

оценка
проекта

18
разработка
программ- 12
ной доку- '
ментации

автономное
тестирова-

2 QA

^14
1 сдача заказа
1

^15
Конец работы

21

Курс

Технология программирования

12 — группа QA завершила автономное тестирование;
13 — группа Q A завершила комплексное тестирование, получила всю до¬
кументацию и действующий вариант системы;
14 — проверка качества (проблемам качества будет посвящена отдельная
лекция) завершена;
15 — конец работы (конечно, это н е к о н е ц , будет е щ е сопровождение, н о
пример-то надо закончить).
Под каждым ребром графа записана планируемая длительность с о ­
ответствующей работы (в неделях). Е щ е раз повторю, что это только п р и ­
мер, прошу н е придираться к техническим деталям, в частности, разуме­
ется, каждая передача (3-7, 3-10 и т.д.) н е может длиться более одногодвух дней, н о н е хотелось возиться с дробями.
Критическими путями являются пути 1-6-2-3-4-5-9-13-14-15 и 1-6¬
2-3-4-5-12-13-14-15, т.е. вся работа н е может быть выполнена быстрее,
чем за двадцать одну неделю. П о н я т н о , что с точки зрения оптимальной
загрузки коллектива было бы лучше, чтобы все пути в графе от начала к
концу имели примерно одинаковую длительность с тем чтобы как-то
уменьшить длину критического пути. Н а п р и м е р , есть соблазн заставить
группу Q A проводить даже начальное тестирование, уменьшив нагрузку
на программистов, работа которых находится на критическом пути. Н о
тогда очень трудно определить границы ответственности, программисты
начинают выдавать откровенную халтуру и в результате сроки даже удли¬
няются. В реальных проектах, где работ очень много, все-таки удается пу­
тем перераспределения работ улучшать сетевой график, п о крайней мере,
к этому стремятся все руководители.
Е щ е несколько замечаний п о данному примеру. Я в н о неудачно спла­
н и р о в а н ы работы между событиями 1, 2, 6. Коллектив сформирован за
одну неделю, а рабочие места еще н е готовы. Группа технических писате¬
лей начинает работать на шесть недель позже проектировщиков, а группа
QA имеет трехнедельный перерыв перед завершением проектирования и т.д.
Эти проблемы действительно трудны, каждая к о м п а н и я решает их
по-своему, например, очевидным решением является использование о д ­
ной и той ж е группы Q A или технических писателей для нескольких групп
разработчиков.
Е щ е одной популярной ф о р м о й графического представления плана
работ является диаграмма Ганта (Gantt). Диаграмма Ганта представляет
собой прямоугольник: слева направо равномерно отсчитываются п е р и о ­
д ы времени (недели, м е с я ц ы ) , сверху вниз перечисляются работы, п р и ­
чем каждая работа представляется в виде отрезка, начало и конец которо­
го размещаются в соответствующем периоде.
Для сравнения с сетевым графиком нарисуем диаграмму Ганта для
того ж е примера:
22

Планирование

Курс

Технология программирования

1-Н

гч
о
гч
о\

••

1-Н

90
1-Н

с-

1-Н

чо
1-Н

•г,

•

1-Н

•
•

1-Н

1-Н

1
1

гч
1-Н
1-Н
1-Н

о

1-Н

о\
90
гчо

•

•г,

•

гч

Неделя

1-Н

Работы

Ъ в
св w 3

22 о
Я о ч
На §
CD CD 3

£ я Ё
°
й
а, с >>
со О W
cs & о О
Рч В Ч

я

о
о Я

И

sэ

о

м
н £
н
cs а
О И ft
03 со

s

to

а с

ч

ей О

>

CS

cs И
° ^
cs а

&о

О

Рч С Ч

и

ю

со
CS CS

24

Ч

&8

G &

CD

О

И
О
С
CS

,

« й
4
н
и
н
н
ьч
а
н
нн
н
^нн н
2 OS

CD

CD

« в
%«

S8
% % ° Е в
к & о&
CD
С в а
Я С
о
Оо O N о
С

CS

Планирование

Если в сетевом графике особенно наглядно видны зависимости ра­
бот друг от друга, (например, работа 12-13 может начаться только после
завершения работ 5-12 и 11-12), то в диаграмме Ганта основной упор де­
лается на то, что происходит в каждую конкретную неделю, например,
видно, что группа Q A имеет перерыв в работе в 2 недели между работами
11-12 (автономное тестирование) и 12-13 (комплексное тестирование).
И м е н н о поэтому «большие начальники» предпочитают диаграммы Ганта:
в к о н ц е каждой недели проводишь вертикальную л и н и ю и сразу видишь,
к а к и е работы велись, что должно кончиться, а что начаться. Должен п р и ­
знаться, что я и сам нашел пару о ш и б о к в расчетах по сетевому графику,
пока строил диаграмму Ганта для этого примера. Тем самым я еще раз убе­
дился, что диаграмма Ганта нагляднее сетевого графика, или в том, что я
уже большой начальник, а не технический специалист. Технические ме¬
неджеры предпочитают сетевые графики, так как и м важнее и н ф о р м а ц и я
о том, что от чего зависит, да и пересчитывать критические пути и м при¬
ходится практически каждую неделю.
На диаграмме Ганта принято над каждым отрезком работы указы¬
вать, сколько сотрудников принимает участие в этой работе (в сетевом
графике это возможно, но не очень удобно, поскольку надо указывать
еще и длительность работы). Опять-таки, начальники любят смотреть,
сколько сотрудников занято в каждой неделе, что легко увидеть как раз на
диаграмме Ганта.

25

Курс

Технология программированияя

5. У п р а в л е н и е
На самом деле управление[8] почти неотделимо от планирования.
вы спланировали работу, приступили к ее и с п о л н е н и ю . Каждую неделю
вы собираете еженедельные отчеты от руководителей групп и оцениваете
состояние каждой работы по сравнению с сетевым графиком. Если все
в порядке — м о ж н о плевать в потолок и ждать конца следующей недели.
К сожалению, так бывает очень редко. Допустим, какая-то работа затяну¬
лась. Если она не на критическом пути — ничего страшного. Нужно про¬
вести воспитательную работу, дать дополнительный срок (причем надо
следить, чтобы от этого увеличения не возник новый критический путь!),
продумать какие-то меры, чтобы не допустить повторения подобных с и ­
туаций. Если ж е проваленная работа лежит на критическом пути, необхо­
д и м о перепланирование, причем основной проблемой является невоз­
можность (чаще всего) сдвига сроков завершения. М ы только что (при
планировании) занимались оптимизацией сетевого графика, прошло все¬
го несколько недель — и вот м ы снова занимаемся тем ж е самым.
Д а ж е сама по себе задача определения задержки в ы п о л н е н и я ка­
к о й - т о работы является весьма нетривиальной. Л ю д и имеют о б ы к н о в е ­
н и е выдавать ж е л а е м о е за действительное, а уж менеджеры — и подавно.
К а ж д ы й думает, что в о з н и к ш у ю небольшую задержку о н обязательно
ликвидирует в б л и ж а й ш и е д н и , поэтому м о ж н о и не сообщать о н е й н а ­
чальнику. К р о м е того, хотя п р и составлении плана делалось все в о з м о ж ­
н о е , чтобы сформулировать все с о б ы т и я м а к с и м а л ь н о т о ч н ы м образом,
всегда есть лазейка, чтобы представить недоделанную работу завершен¬
н о й . Тут многое зависит от психологического климата в коллективе, от
уровня д о в е р и я , установившегося между руководителями и п о д ч и н е н ными.
Не меньшее значение имеет и уровень технической оснащенности:
одно дело, когда решение принимается только на основании устного сооб­
щения, и совсем другое — когда все результаты работы (не только програм­
мы, но и схемы, алгоритмы, описания и т.д.) собираются в едином репозитории, когда имеется возможность
выполнения различных формаль¬
сроки
ных проверок, когда руководитель
может просмотреть результаты
в их р а з в и т и и , о ц е н и т ь работу
не только группы в целом, но и ка¬
ждого ее участника.
работы /—
Графически проблему управ¬
(люди, деньги,
л е н и я м о ж н о представить в виде
компьютеры и т.п.)
треугольника:

л

'

26

\ „

Управление

В этом треугольнике каждая вершина зависит от двух других. Н а п р и ­
мер, если работы не укладываются в сроки, м о ж н о попытаться догово­
риться с заказчиком об их удлинении (очевидно, что стоимость работ так­
ж е возрастет). Если сроки сдвинуть нельзя, необходимо договариваться с
заказчиками об уменьшении объема работ (т.е. выкинуть какие-то функ¬
ц и и из с п е ц и ф и к а ц и и ) , либо привлекать дополнительные ресурсы. К т о то из классиков сказал: «Добавлять людей в горящий коллектив — это все
равно что заливать пожар керосином» — ведь новых людей нужно ввести
в курс дела, отвлекая на это основных разработчиков, но даже после это­
го вряд ли удастся ускорить работу, так как увеличивается количество и н ­
терфейсов и согласований между участниками. В тех случаях, когда сро­
ки сорваны, ресурсы исчерпаны, а важная работа не выполнена, легче эту
работу заново спланировать и поручить другому коллективу.
Опытные руководители проектов отчетливо понимают эти пробле¬
м ы и р е ш а ю т их, в первую очередь, за счет квалифицированного проекти¬
р о в а н и я , учета возможных рисков, обеспечения возможности регулярно­
го о б щ е н и я между разработчиками, выделения максимально независи¬
мых компонентов (которые могут быть переданы дополнительным разра¬
ботчикам), за счет скрытых ресурсов, о которых разработчики даже не по¬
дозревают. Н а п р и м е р , ш и р о к о распространена практика, когда руково¬
дитель договаривается с заказчиком об одних сроках, а разработчикам со¬
общает другие, более сжатые сроки.
Неплохо иметь «пожарную команду» из двух-трех высококлассных
специалистов, которые в промежутках между «пожарами» занимаются
исследованиями или развитием инструментальных средств.
Некоторые авторы предлагают в случае выхода из графика приме¬
нять «метод пряника», т.е. предлагать разработчикам дополнительные
деньги за сверхурочную работу, н о , может быть, это не очень верно. Т.е.
такая мера может сработать раз или два, но потом разработчики интуи­
тивно (а, может быть, и не совсем интуитивно) начинают затягивать ра­
боты, ожидая дополнительных подачек. Сидит такой имитатор деятель­
ности, месяц бьет баклуши, но за два-три д н я до сдачи начинает работать
ночами и утром в день сдачи с воспаленными глазами сдает руководите¬
л ю действующую программу, но не прошедшую через регулярную проце­
дуру QA, не проверенную в комплексе с другими программами и т.д.
Жертвенность на работе — это, в первую очередь, п р и з н а к непрофес¬
сионализма.
Так как ж е все-таки управлять программистским коллективом? Д о ­
бавлять людей нельзя, сулить премии нельзя, давить своим авторитетом
на подчиненных нельзя, а что ж е можно? Хотелось бы получить ответ от
каких-то известных в этой области специалистов, причем не на уровне
общих рассуждений, а в виде конкретных рекомендаций и методик, и н а 27

Курс

Технология программирования

че и вправду системное программирование сильно смахивает на искусст¬
во, а не на п р о м ы ш л е н н у ю дисциплину.
М н о г и е годы для нас таким авторитетом является Ф. Брукс, который
руководил отделением программирования I B M (несколько тысяч чело­
век) в шестидесятые годы, как раз тогда, когда создавалась знаменитая се­
р и я IBM/360. П о к и н у в I B M , Ф. Брукс стал профессором университета
Чапел-Хилл в Северной К а р о л и н е и написал ставшую бестселлером к н и ­
гу «Как проектируются и создаются программные комплексы. М и ф и ч е ­
ский человеко-месяц. Очерки по системному программированию». Эта
книга в 1979 году была переведена на русский я з ы к и издана в издательст­
ве «Мир». За несколько лет до этого по С С С Р ходил «левый» перевод этой
ж е книги, в ы п о л н е н н ы й (и, кстати, гораздо лучше, чем о ф и ц и а л ь н ы й )
академиком А.П. Ершовым. Через 20 лет в ы ш л о юбилейное переиздание
книги[5], дополненное поздними статьями Ф. Брукса и подробным ана¬
лизом, какие идеи, высказанные 20 лет назад, сохранили свою силу, а ка¬
кие оказались о ш и б о ч н ы м и . К р о м е несомненного дара системного про¬
граммиста и огромного опыта руководства большими коллективами Ф.
Брукс обладает я р к и м литературным талантом — многие ф р а з ы из книги
стали общеизвестными лозунгами программистов. В декабре 2000 года
м н е удалось побеседовать с н и м прямо на его рабочем месте, и личная
встреча только усилила мои впечатления об этом замечательном ученом.
Так вот, читая эту книгу, м о ж н о обнаружить массу полезных и краси¬
во изложенных советов, как организовать коллектив, какие бывают вари¬
анты жизненного цикла П О , какую документацию и насколько подробно
надо готовить, и еще множество интересных вещей. Н о конкретных сове¬
тов, что делать, когда гром уже грянул, когда работа, лежащая на крити¬
ческом пути, не выполнена в срок, вы не найдете.
Основная идея состоит в том, что при правильной организации, с
хорошо подготовленным коллективом м о ж н о уменьшить вероятность
срывов, предугадать их на возможно более р а н н и х сроках, но если это все
ж е случилось — только л и ч н ы й опыт и интуиция руководителя помогут
выбраться из этой ситуации с н а и м е н ь ш и м и потерями. Одна из более
поздних статей Ф. Брукса «No silver bullet» как раз и посвящена обоснова¬
н и ю того факта, что нет волшебного простого средства, с п о м о щ ь ю кото¬
рого м о ж н о легко р е ш и т ь проблемы разработки П О и, в частности, проб¬
лемы управления.
Н о ведь люди работают, сроки горят, значит, какие-то выходы из
этой ситуации есть. Я спросил Лена Эрлиха, нашего американского за¬
казчика, к а к поступают американские менеджеры в ситуации, когда зава¬
ливается критически важная работа. Ответ был прост, к а к выстрел. П о д к ­
лючаются 1-2 м о щ н ы х специалиста,проводятся совещания по ходу работ
— каждый день, а если мало, то дважды в день, обязательно в присутствии
28

Управление

высшего руководства. Те ф у н к ц и и , о ш и б к и в которых исправить трудно,
безжалостно выкидываются. Главное, чтобы в срок заработала основная
масса ф у н к ц и й — тогда есть ш а н с ы договориться с заказчиком о д о п о л н и ­
тельном времени для завершения работы, если ж е к нужному времени по¬
казать нечего, скандал неминуем.
В общем-то, ситуация классическая: ученые говорят, что «добавлять
людей в горящий коллектив — это все равно что заливать пожар кероси­
ном», а практики добавляют, ужесточают контроль и часто побеждают.
«Ученый думает, что знает, но у него не совпадает, у практика все совпа¬
дает, но почему — никто не знает».
Чтобы не завершать параграф на такой грустной ноте, приведу пере¬
чень возможных корректирующих действий менеджера из внутренних
правил одной крупной западной ф и р м ы :
• перераспределите работы, лежащие на критическом пути, так, чтобы
они исполнялись более о п ы т н ы м и членами коллектива;
• увеличьте к о м а н д у и с п о л н и т е л е й в р е м е н н ы м и с о т р у д н и к а м и
(а не кадровыми);
• перераспределите исполнителей в нескольких командах (не только в
«горящей»);
• упростите требования к работе;
• не отвлекайте команду, постарайтесь не прерывать их работу;
• организуйте дополнительное техническое обучение;
• если возможно, используйте средства автоматизации разработки;
• организуйте сверхурочную работу, возможно, многосменную;
• перепланируйте всю работу, уменьшив число работ на критическом
пути (особенно проверьте зависимости одних работ от других).
К а к видите, все на уровне здравого смысла, н и к а к о й «серебряной
пули», но здесь следует привести мою любимую фразу: «На свете есть
множество общеизвестных, но не общепринятых истин». Если н е получа­
ется руководить программным проектом, то почему бы не попробовать
работать по правилам?

29

Курс

Технология программирования

6. Т е с т и р о в а н и е ,
обеспечение качества
Для начала вспомним три а к с и о м ы одного из самых первых совет­
ских программистов с несколько необычной фамилией Шура-Бура.
Аксиома 1. В каждой программе есть ошибка.
Аксиома 2. Если в программе нет ошибок, значит, в исходном алго¬
р и т м е есть ошибка.
Аксиома 3. Если н и в программе, н и в алгоритме о ш и б о к нет, то та­
кая программа никому не нужна.
П р и всей шутливости этих аксиом в них отражена суровая правда
жизни.
Исходные идеи тестирования абсолютно п о н я т н ы [9].
Вы написали программу, хотите убедиться в правильности ее работы,
поэтому пропускаете один или несколько тестов и смотрите, что получи¬
лось. П о н я т н о , что тесты д о л ж н ы быть простыми настолько, чтобы мож¬
но было предсказать правильный ответ, иначе как в ы определите, пра¬
вильно ли программа сработала?
А что делать со сложными тестами и, вообще, сколько тестов нужно
пропустить? Ответ очевиден — бесконечно много, поэтому с п о м о щ ь ю те¬
ста м о ж н о доказать наличие о ш и б о к (если тест был достаточно «зуба¬
стым»), но нельзя доказать их отсутствие.
Бесконечность тестов определяется наличием циклов, рекурсии,
разнообразием значений данных. Ситуация обычна для нашей специаль­
ности. Теоретическая невозможность не снимает с нас ответственности за
п о и с к практических способов проверки — пусть не полных, но дающих
какую-то степень уверенности. Итак, что ж е м о ж н о сделать?
Е щ е 30 лет назад был популярен критерий полноты тестирования,
при котором набор тестов гарантировал, что по каждому ребру графа уп¬
равления программы исполнение программы хотя бы один раз пройдет.
Такой набор тестов м о ж н о создать, часто даже автоматически.
Ч т о б ы проверить ц и к л , нужно создать тест, гарантирующий прохож¬
дение цикла 0, 1 и 2 раза. 0 — вдруг условие входа в ц и к л сразу было лож¬
н ы м , 1 — нормальное прохождение, 2 — не столь очевидно. Возможно,
в к о н ц е цикла есть присваивание переменной, которая в начале цикла
только читается. П о н я т н о , что однократный проход по циклу не даст воз­
можности проверки важного и весьма вероятного варианта.
И з л о ж е н н ы е критерии носят только эвристический характер, но
весьма полезны. Таким образом, м ы видим, что программирование и тес¬
тирование — совершенно разные т и п ы деятельности, требующие разных
исполнителей.
30

Тестирование, обеспечение качества

Программирование — это конструктивный созидательный процесс,
который требует высокой к в а л и ф и к а ц и и и определенного оптимизма
(см. аксиомы Ш у р ы - Б у р ы ) .
Тестирование — деструктивный процесс, который требует высокой
дотошности, подозрительности, пессимистичности, н о , вообще говоря,
не требует высокой к в а л и ф и к а ц и и . Пусть не обижаются на меня настоя¬
щ и е системные программисты, которые создают инструментальные сред¬
ства автоматизации тестирования, я говорю об обычных тестерах. В каж­
дом коллективе есть люди с неуживчивым характером, л ю б я щ и е п о к р и ­
тиковать коллег по работе. Ц е н ы им не будет в группе тестирования.
Е щ е раз повторим, что тестирование нужно вовсе не для того, чтобы
показать, что программа работает правильно — это невозможно. Тестиро¬
вание — это процесс исполнения программы с целью нахождения о ш и ­
бок. Х о р о ш и й тест — это тест, на котором с большой вероятностью о ш и б ­
ка найдется.
Теперь приведем несколько организационных и технологических
соображений относительно тестирования.
Тестирование (не считая начальных отладочных тестов) не должно
проводиться самими авторами программы. Наблюдается определенная
«замыленность» взгляда автора на программу, поэтому он и тесты будет
готовить на те варианты, которые предусмотрел в программе.
Должна быть конкуренция между программистами и тестировщикам и , нужен дух соревнования: «Я все равно тебя поймаю» против «Врешь,
не поймаешь».
Необходимо уметь оценивать вероятность и примерное количество
оставшихся ошибок. Например, известен метод оценки количества рыб в пру­
ду. Ловят, скажем, 100 рыбок, помечают их и выпускают обратно в пруд.
Затем снова ловят 100 рыбок. Если почти все они мечены, значит, в пруду
п р и м е р н о 100 р ы б о к и есть, если ж е меченых попалось мало, то р ы б , ско¬
рее всего, больше, причем в той же п р о п о р ц и и , какова доля непомечен­
ных из 100 вновь пойманных. Во многих фирмах применяют тот же п р и ­
ем: специальные люди вставляют некоторое количество разнообразных
о ш и б о к в программы и возвращают их на доработку авторам с требовани¬
ем обнаружить ровно столько ж е ошибок. П о тому, какая часть найден­
ных о ш и б о к относится к специально вставленным, а какая — к вновь н а й ­
д е н н ы м о ш и б к а м , м о ж н о судить о числе оставшихся ошибок. Е щ е п р о щ е
— поручить тестирование одной и той же программы двум группам тестир о в щ и к о в и оценить процент ошибок, найденных обеими группами.
Д о л ж н о проверяться не только нормальное поведение программы,
но и поведение в случае неправильных входных данных и других ошибоч¬
ных ситуаций на предмет устойчивости программы, осмысленности сооб¬
щ е н и й об ошибках и т.д.
31

Курс

Технология программирования

Всегда должен быть четко оговорен конечный результат тестирования.
В идеале е щ е д о начала работ или н а одной из ранних стадий (работа 2-10
из нашего примера) должен быть создан и согласован с заказчиком набор
тестов, успешный пропуск которых свидетельствует об успешном оконча¬
н и и работы в целом. К сожалению, н а практике такое встречается редко,
поэтому сдача проекта — это всегда, скажем так, ш у м н ы й процесс.
Различают тестирование п о типам:
• ч е р н ы й я щ и к (без просмотра исходного текста);
• белый я щ и к (с изучением исходного текста);
и п о объему:
• маленький тест, типа печати «hello, world», чтобы понять, есть л и во¬
обще о чем говорить;
• получасовое тестирование (американцы говорят «Тест н а одну сига­
рету»), обычно проверяют по одному тесту на каждую ф у н к ц и ю про¬
граммы перед серьезным тестированием;
• модульное тестирование;
• комплексное тестирование.
Особого у п о м и н а н и я заслуживают тестирование граничных значе¬
н и й входных данных, тесты н а максимальный объем счета, проверка
предположений об ошибках («Я бы сделал ошибку здесь»).
Иногда применяется перекрестное чтение особо ответственных уча¬
стков программы, когда одна группа разработчиков читает программы
другой группы ( г ш р е й ю п peer review). В С Ш А очень популярны Bugs fes­
tivals, когда незадолго перед выпуском системы ф и р м а платит определен¬
ную сумму за каждую найденную ошибку. С п и с о к таких приемов м о ж н о
расширить, н о вряд ли их м о ж н о считать общеупотребительными.
В зрелых программистских компаниях для каждого проекта ведется
своя база данных ошибок, в которую вносится:
• кто нашел ошибку, дата;
• описание о ш и б к и ;
• модуль, в котором ошибка обнаружилась (возможно, это наведенная
ошибка, может быть, она вызвана о ш и б к о й в совсем другом модуле);
• версия продукта;
• статус о ш и б к и :
open: найдена
fixed: исправлена
can t reproduce: невозможно воспроизвести
by design: ошибка проектировщиков
wont fix: это н е ошибка (тестеру показалось)
postponed: сейчас исправить трудно, исправим в следующей версии
regression: исправленная о ш и б к а появилась вновь
• Важность (severity) о ш и б к и :
32

Тестирование, обеспечение качества

crash: все падает, полная потеря данных
major problem: падает частично, частичная потеря данных
minor problem: что-то н е то, н о д а н н ы е н е теряются
trivial: сейчас н е стоит исправлять
• Приоритет о ш и б к и :
highest: невозможно поставить продукт с такой о ш и б к о й , н е можем
перейти к следующей версии
high: поставить н е можем, н о можем перейти к следующей версии
medium: можем и исправим
low: косметические улучшения — оставим на следующую версию.
О с о б е н н о заметна ц е н н о с т ь базы д а н н ы х о ш и б о к д л я больших
и длительных проектов. Е с л и и д е н т и ф и к а т о р о д н о й о ш и б к и встречает­
с я д е с я т к и р а з в р а з л и ч н ы х письмах, н е д е л ь н ы х отчетах — это в е р н ы й
п р и з н а к того, ч т о требуется вмешательство руководства. Все р у к о в о д и ­
тели р а з н ы х р а н г о в з н а ю т н а п а м я т ь з а п и с и и з э т о й базы д а н н ы х о т е ­
к у щ и х о ш и б к а х с в ы с ш е й важностью и п р и о р и т е т о м . П о з а в е р ш е н и и
каждого п р о е к т а база д а н н ы х о ш и б о к в н и м а т е л ь н о анализируется. Ин¬
тересно р а с п р е д е л е н и е о ш и б о к п о тому, кто их с о в е р ш и л , п о в р е м е н и
и с п р а в л е н и я , кто ч а щ е о ш и б к и находит и т.д. Е с л и в одну неделю раз¬
р а б о т ч и к 1 сделал 10 о ш и б о к , а р а з р а б о т ч и к 2 — только 2, это е щ е н и о
ч е м н е говорит. Н о если ж е за весь п е р и о д р а з р а б о т к и р а з р а б о т ч и к 1
сделал 100 о ш и б о к , а р а з р а б о т ч и к 2 — только 10, т о п о э т и м ц и ф р а м
м о ж н о уже судить об их к в а л и ф и к а ц и и . М о ж н о т а к ж е о ц е н и в а т ь ц е л ы е
группы и л и , с к а ж е м , качество п р о е к т и р о в а н и я , а м о ж н о сделать к а к и е то в ы в о д ы п о м о щ н о с т и и н а д е ж н о с т и используемых инструменталь¬
н ы х средств.
На основе изучения записей в базе данных о ш и б о к руководство про¬
ектом принимает р е ш е н и е о возможности выпуска продукта, например,
продукт нельзя выпускать, если есть хотя бы одна ошибка с важностью
«crash» или с приоритетом <<highest/high>>. Возможна и такая стратегия,
когда продукт выпустить обязательно надо, н о времени на исправление
основных о ш и б о к нет (нужно помнить, что даже небольшие исправления
могут повлечь за собой новые о ш и б к и ) , тогда из продукта просто удаляют
часть ф у н к ц и й , в которых есть о ш и б к и .
М ы говорили о тестировании, только отдавая дань многолетней тра­
д и ц и и . Н а самом деле, любая зрелая программистская к о м п а н и я имеет
большую независимую группу о ц е н к и качества П О (Quality Assurance или
просто QA), ф у н к ц и и которой намного шире, ч е м просто тестирование.
Для каждого продукта проверяется:
• полнота и корректность документации;
• корректность процедур установки и запуска;
• эргономичность использования;
33

Курс

Технология программирования

• полнота тестирования.
Q A должна играть роль придирчивого пользователя, но внутри к о м ­
пании. В С Ш А разработчики и Q A сидят в разных концах коридора,
не поощряется даже неформальное общение. В западных компаниях д о ­
вольно существенную часть зарплаты (примерно 20-30%) составляет бо¬
нус, выплачиваемый в к о н ц е проекта и только в случае его успешного за¬
вершения. Так вот, если Q A найдет с л и ш к о м много о ш и б о к разработчи­
ков, те остаются без бонуса, но если Q A п р и н я л разработку, а затем поль­
зователи начнут жаловаться, то Q A остается без бонуса, хотя жалобы свя¬
заны с о ш и б к а м и разработчиков. Таким искусственным разделением от¬
ветственности и н е п о о щ р е н и е м дружеских о т н о ш е н и й между разработ¬
ч и к а м и и Q A владельцы к о м п а н и й пытаются застраховаться от неудачи на
р ы н к е . В С Ш А говорят, что каждому продукту дается только одна п о п ы т ­
ка выхода на рынок. Если пользователям по разным п р и ч и н а м продукт не
понравился, репутация теряется навсегда. Поэтому о ш и б к и так дорого
стоят.

34

Групповая разработка, управление версиями

7. Групповая р а з р а б о т к а ,
управление версиями
Один из департаментов нашего коллектива разрабатывает П О теле¬
ф о н н ы х станций, которое включает в себя следующие компоненты:
• О С реального времени;
• драйверы телефонного оборудования;
• функциональное П О ;
• программы рабочих мест операторов ( Р М О ) ;
• БД конкретного экземпляра АТС.
Каждый компонент разрабатывается отдельным коллективом разра­
ботчиков, но все компоненты тесно связаны друг с другом. Более того, каж¬
д ы й компонент (кроме, пожалуй, драйверов) состоит из большого числа
модулей, разрабатываемых разными специалистами. Таким образом, налицо
проблема взаимодействия большого количества разработчиков, каждый
из которых может находиться в своей фазе разработки, может внести
в свою программу такие изменения, которые не позволят другому разра­
ботчику отлаживать его программу и т.д. К сожалению, и в нашем коллек­
тиве, в котором слово «технология» царит уже более 20 лет, нередки слу­
чаи, когда при выезде на объект БД не соответствует Ф П О или версия
Р М О уже устарела. Н а ш а техническая вооруженность позволяет быстро
справляться с этими трудностями, но свести проблемы к нулю м о ж н о
л и ш ь жесткими о р г а н и з а ц и о н н ы м и мерами, прежде всего, требуется
преодолеть многие советские п р и в ы ч к и и особенности нашего мента¬
литета.
Е щ е 20 лет назад у нас в коллективе сложилась трехуровневая систе­
ма версий, которая в том или и н о м виде актуальна до сих пор. Разработ¬
ч и к действует в своем файловом пространстве (раньше м ы говорили «би¬
блиотека разработчика»), делает там, что хочет, и н и с кем ничего не сог¬
ласовывает. Когда группа разработчиков решает, что какие-то модули от¬
лажены (или когда их руководитель решает, что ждать больше нельзя,
сроки поджимают), исходные тексты модулей передаются в библиотеку
тестирования. Система или какой-то ее компонент проверяется на всех
существующих тестах, причем библиотека тестирования остается ф и к с и ­
рованной, все н а й д е н н ы е о ш и б к и заносятся в базу данных о ш и б о к и и с ­
правляются в библиотеках разработчиков. Когда все тесты пропущены,
библиотека тестирования вместе со списком найденных о ш и б о к копиру­
ется в библиотеку предъявления, а библиотека тестирования готова
к приему новой версии из библиотек разработчиков.
Подчеркнем еще раз, что в библиотеку предъявления перенос осу­
ществляется сразу ж е , когда пропущены все тесты, а вот перенос в библи35

Курс

Технология программирования

отеку тестирования — только по мере готовности группы разработчиков
выдать новую версию системы.
В ч е м ж е состоит роль библиотеки предъявления? Дело в том, что
большие системы создаются большими коллективами с иерархической
системой подчинения (позже м ы увидим, что это н е всегда так). У руко­
водителя любой группы есть начальник, а у самого большого начальника
есть заказчик, словом, твой начальник всегда может потребовать у тебя
версию для комплексирования системы на его уровне. Так вот, лучше от¬
дать ему пусть немного устаревшую версию, н о с известным списком
о ш и б о к (пусть на следующем уровне часть тестов, где используются о ш и ­
бочные ф у н к ц и и , пока н е гоняют), чем более новую, «с пылу, с жару», н о
с непредсказуемым поведением. Итак, библиотека предъявления ждет
своего часа, когда начальник ее затребует, а может и так случиться, что б и ­
блиотека предъявления успеет несколько раз обновиться, пока ею заинте­
ресуются.
Описанная в ы ш е трехуровневая система версий является с л и ш к о м
крупноблочной. В современных технологиях используются специальные
инструментальные средства, позволяющие фиксировать каждое измене­
н и е и откатываться к нужной точке, например, Visual Source Safe или
PVCS. Обычно такие системы версионирования устанавливаются на сер¬
вере, разработчики играют роль клиентов (тем самым автоматически ре¬
шаются технические проблемы, например, разрешение к о н ф л и к т о в п р и
одновременном обращении, вопросы back-up и др.), а система предоста­
вляет следующие методы:
Check-out: взять текст на исправление;
Check-in: вернуть обратно;
Undo check-in: отмена всех изменений, сделанных во время послед¬
ней сессии;
Get latest version: берется один файл или ф а й л ы целого проекта в том
состоянии, в котором их застал последний check-in.
Последняя версия обычно хранится отдельно.
Само собой разумеется, что в системе версионирования м о ж н о хра¬
нить исходные тексты программ, двоичные файлы, документацию и т.п.
Насколько хорошо у нас поставлена система версионного контроля,
как-то раз я убедился лично. Однажды поздно вечером я зашел за своей
ж е н о й , которая также работает на нашем предприятии, и говорю: «Пош¬
ли домой, устал д о смерти, больше н е могу работать». Она мне: «Пока
check-in н е сделаю, уйти н е могу, иначе меня завтра ждут большие н е п р и ­
ятности». Это меня позабавило — я ж е генеральный директор, какие м о ­
гут быть неприятности, если я сам о чем-то прошу? Она м н е с п о к о й н о
объясняет, что в д а н н о м случае н и к а к о й роли н е играет, кто я и кто она.
Каждую ночь у нас идет автоматическая сборка разрабатываемого проду36

Групповая разработка, управление версиями

кта, затем автоматическое тестирование. Сборка начинается с перетранс­
л я ц и и абсолютно всех модулей (чтобы исходные тексты не разошлись с
объектными модулями). Если в текстах есть формальные о ш и б к и , транс­
л я ц и я завершится с аварийным кодом возврата, сборка выполняться не
будет, а утром как виноватые исполнители, так и их руководители получат
автоматически сгенерированные сообщения с исчерпывающим объясне¬
н и е м ситуации. Это какой-то страшный бездушный молох, м а ш и н а , в ко¬
торую даже генеральный директор влезть не может.
В результате м н е пришлось прождать больше часа, пока все фор¬
мальности не были выполнены.

37

Курс

Технология программирования

8. П с и х о л о г и я п р о г р а м м и р о в а н и я
В первый раз я столкнулся со специалистами по инженерной психоло­
гии в 1968 году. Н а мат-мехе была установлена польская Э В М O D R A 1204
с хорошей операционной системой и достаточно полной реализацией
Алгола 60. Н а этой Э В М м ы впервые получили возможность посимволь­
ного ввода/вывода и н ф о р м а ц и и , используя телетайп или перфоленту.
Д о этого м ы могли работать только с целой колодой перфокарт или с ц е ­
лой перфолентой. М ы реализовали один из первых в С С С Р (и уж точно —
первый в нашем университете) диалоговый корректор текстов (программа
dico [10]). Г.С. Цейтин придумал идею и показал примеры основных опе­
раций, я написал на Алголе 60 почти все программы, а С.Н. Баранов под­
готовил хорошую документацию. Программа быстро стала популярной,
после чего Александр Марьяненко (сотрудник института комплексных со­
циальных исследований) попросил разрешения провести некоторые п с и ­
хологические исследования проблем диалогового редактора. М ы , разуме­
ется, согласились, хотя совершенно не верили, что это принесет пользу.
К а к оказалось — зря не верили. Симпатичная дипломница А. Марьяненко
провела 2-3 месяца, наблюдая за нашей работой. Она была тихой и неза­
метной, м ы ее присутствия практически не ощущали. Зато после этого она
выдала целый ряд наблюдений и рекомендаций, оказавшихся очень ц е н ­
ными. Например, она заметила, что некоторые часто встречающиеся вместе
команды кодируются символами в разных регистрах, из-за чего оператор
вынужден чаще нажимать на клавиши, а некоторые команды были назва¬
н ы неудачно, что провоцировало пользователей на ошибки. Н о больше
всего м ы удивились, когда она заметила, что отладка модуля размером
в одну страницу может быть не на проценты, а в разы проще отладки мо¬
дуля размером в одну страницу и еще 4-5 строк на другой странице.
Оказалось, что это связано с принципами организации человеческой па­
мяти. Есть сверхоперативная память, связанная, в основном, со зрением. Эта
память имеет очень быстрый доступ, но очень мала — 7-9 позиций. (Говорят,
что у профессиональных программистов эта память имеет 20-25 позиций.)
Существенно больше оперативная память, в которой и происходит
вся основная мыслительная деятельность, н о д а н н ы е в н е й н е могут хра­
ниться долго. Н а к о н е ц , самая большая — долговременная память. Ч е л о ­
веку непросто заложить туда д а н н ы е , н о хранятся о н и долго.
С устройством памяти связан п р и н ц и п «центрального» (в отличие от
«периферического») зрения. Человек хорошо воспринимает какую-то
точку и то, что ее окружает.
Если при отладке программы автор должен обозревать больше, ч е м
одну небольшую страницу текста, о н н е может п о л н о ц е н н о воспринять
программу. «Листать вредно».
38

Технология REAL

Е щ е один важный п р и н ц и п инженерной психологии также связан с
устройством человеческой памяти — п р и н ц и п возможно раннего обнару­
ж е н и я ошибок. Если программист написал программу и тут ж е заметил
ошибку, то ее исправить сравнительно просто. Если ж е ему сообщают о
найденной о ш и б к е через полгода, ее исправление превращается в проб­
лему. И м е н н о по этой п р и ч и н е м ы являемся сторонниками статических
АЯВУ (в которых транслятор в каждой точке программы «знает» виды об­
рабатываемых значений), а не динамических, в которых т и п ы данных о п ­
ределяются во время счета. В динамических языках простое несовпадение
типов может обнаружиться и через полгода, когда сложится «нужное рас¬
положение звезд на небе». Словом, в инженерную психологию как в нау¬
ку м ы поверили. Поэтому, когда тот ж е А. М а р ь я н е н к о несколькими го¬
дами позже предложил провести психологическое обследование нашей
лаборатории системного программирования, м ы согласились. Поводом
послужил тот факт, что в этот момент я оказался самым молодым руково­
дителем лаборатории ЛГУ, и психологам было интересно исследовать вза­
и м о о т н о ш е н и я молодого руководителя с его старшими коллегами.
Н а м раздали анкеты со множеством странных вопросов типа: «Как
ты думаешь, что скажет о тебе такой-то сотрудник?». Содержание каждой
анкеты не раскрывалось (таковы правила социологических опросов), но
суммарные результаты, полученные, кстати, на Э В М (!) нам были пред¬
ставлены. Результаты были интересные, содержательные, многие реко¬
мендации м ы использовали. Н о один факт меня просто поразил. А. М а р ь ­
я н е н к о предсказал мне, что два сотрудника не более чем через полгода ла¬
бораторию покинут. К а к ж е так? Я ж е их учил, играл с н и м и в баскетбол,
м ы вместе решали трудные задачи, никогда н и одного плохого слова я от
них не слышал. Я тогда промолчал
о предсказании: если это ошибка,
то зачем травмировать хороших
Самореализация,
людей, а если правда, то что тут
самооценка
поделаешь. Через полгода о н и уш¬
Как тебя
ли с громким скандалом, написав
оценивают
другие
бумагу, в которой обвинили меня
во всех смертных грехах. Я был по¬
Социальные
трясен, но не их уходом, а сбыв­
потребности
ш и м с я предсказанием.
Безопасность
Я стал читать к н и г и по пси¬
хологии, это оказалось не так ин¬
Физиологические
тересно для математика, но к а к и е потребности
то п р и н ц и п ы я запомнил.
Многое в поведении людей
объясняет пирамида Маслоу [11]:

м
Ш

39

Курс

Технология программирования

Диаграмма Маслоу носит совершенно тривиальный характер — если
человеку нечего есть и негде жить, то что ему до высоких материй? Н о со¬
вокупное п о н и м а н и е человеческих потребностей и их выстроенная пос¬
ледовательность очень важны. В каком-то смысле каждый программист
проходит весь путь от простого зарабатывания денег до п о н и м а н и я того,
как важно быть членом команды, п р и з н а н и я товарищей, достижения вы¬
сокой самооценки.
Любой человек принадлежит к одному из трех типов:
Лидер. Человек, который стремится управлять другими людьми,
проектами, для которого нестерпимо быть просто «винтиком» в сложном
механизме. И з лидеров выходят политические деятели, менеджеры раз­
ного уровня, для них, прежде всего, важен л и ч н ы й успех.
Технарь. Человек, который получает настоящее удовольствие от са­
мого процесса поиска р е ш е н и я , например, программирования, которому
по большому счету наплевать, что есть начальники и подчиненные, что о
нем не пишут газеты и т.д. Главное — р е ш и т ь задачу.
Общительный. Эти люди разносят и н ф о р м а ц и ю , популяризуют ре­
зультаты других людей. Психологи говорят, что 60% ж е н щ и н относятся
и м е н н о к этой категории.
З н а н и е этих категорий очень важно для менеджеров программист¬
ских коллективов. Если собрать коллектив из одних лидеров, то будет по¬
стоянная борьба за власть, даже самые лучшие идеи не будут доведены до
реализации, да и обмена идеями, скорее всего, не будет.
Команда из одних технарей не будет соблюдать бюджет и сроки, ка¬
ж д ы й будет сидеть в своем углу и решать ту задачу, которая ему больше
нравится, а не ту, р е ш е н и е которой необходимо в д а н н ы й момент. Для
мат-меха это очень типичная ситуация.
Н а к о н е ц , в коллективе, состоящем преимущественно из общитель­
ных людей, будут самые веселые праздники, туда всегда будет приятно
зайти, но работа спориться не будет. И такие коллективы я встречал неод¬
нократно.
П о н я т н о , что хороший коллектив должен включать удачное сочета¬
н и е лидеров, технарей и людей, ориентированных на общение. К а к
говорится, «мамы разные нужны, м а м ы всякие важны».

40

Организация коллектива разработчиков

9. О р г а н и з а ц и я к о л л е к т и в а р а з р а б о т ч и к о в
П о м н и т е историю из Библии о Вавилонской башне? Адам и Ева вку¬
сили запретный плод, в результате чего люди стали быстро размножаться,
и говорили о н и , очевидно, на одном языке. Дела у людей ш л и хорошо,
но возгордились они сверх всякой меры и чтобы доказать Богу, что они
его не боятся, решили построить башню до самого неба. Бог с н и м и разо­
брался очень быстро — взял и смешал разные я з ы к и , люди потеряли воз­
можность общаться, а, значит, управляемость, в результате а м б и ц и о з н ы й
проект так и не был завершен.
Проблема интерфейсов — главная проблема в организации коллек­
тива. Если есть n сотрудников, то имеется Cn = n * ( n - 1 ) / 2 парных ин¬
терфейсов, а ведь иногда надо обсудить проблему и втроем, и вчетвером.
Таким образом, с ростом коллектива быстро растет количество интерфей¬
сов внутри него, при каждом взаимодействии могут возникнуть споры,
н е п о н и м а н и е , разночтение и другие к о н ф л и к т ы . К а к ж е с этим бороться?
П о н я т н о , что ставить перед собой задачу абсолютного р е ш е н и я этой
проблемы не стоит, но какие—то пути решения я покажу. А уж дальше
м о ж н о надеяться только на л и ч н ы й опыт руководства коллективами.
Основная идея состоит в построении иерархии подчиненности. Есть
руководитель темы или отдела, у него в подчинении несколько руководи¬
телей групп, у каждого руководителя группы в подчинении несколько
специалистов. Разумеется, уровней иерархии может быть и 2, и 3, и 4,
но все-таки не 15 и не 20. Каждый руководитель должен сформулировать
задачу своим п о д ч и н е н н ы м так, чтобы минимизировать интерфейсы ме¬
жду н и м и , т.е. максимально локализовать р е ш а е м ы е ими задачи. Это
не всегда возможно, не у всех руководителей получается, но так и разли­
чаются руководители и их команды.
В незапамятные времена многие верили в закон Конвея: «Каждая
система структурно подобна коллективу, ее разработавшему». В 1976 году
м н е пришлось довольно долго беседовать с руководителем разработки
трансляторов с я з ы к а ПЛ1 для IBM/360 по ф а м и л и и Маркс. Родился о н
в тот же год, что и я , закончил университет тогда же, когда и я , занимался
очень похожей работой (в то время я был одним из руководителей разра­
ботки транслятора с я з ы к а Алгол 68), в общем, нам было интересно побе­
седовать. Я его спросил: «Почему P L 1 / F имеет 51 просмотр, когда с Алго­
лом 68 м ы справляемся за 6?». Он отвечает: «А что тут понимать, у меня
в подчинении был 51 программист. К тому времени, когда м ы начали р е ализовывать оптимизирующий транслятор с П Л 1 , у меня было 100 чело­
век, поэтому P L 1 / opt имеет 100 просмотров». Я и тогда понимал, что это
глупо. Между каждой парой просмотров нужно организовывать файл
на промежуточном я з ы к е ; один просмотр — пишет, другой — читает, д о 2

41

Курс

Технология программирования

бавьте разные упаковки и распаковки, другие служебные действия — и вы
поймете, почему трансляторы с ПЛ1 работали так медленно.
Н о не все так просто в этом мире. М ы делали транслятор чуть ли
не 10 лет, а они «слепили» свой транслятор за два года. Тот ж е Маркс п о ­
завидовал мне, что у нас есть такая замечательная возможность занимать­
ся любимой наукой, не торопясь, исследовать разные варианты, приду­
мывать новые методы, публиковать монографии и т.д. C понятием р ы н к а
П О в те годы м ы были совершенно не знакомы, да и сейчас, через 30 лет,
далеко не все н а ш и программисты понимают законы р ы н к а : как важно
первым выдать на р ы н о к пусть не самый лучший, но работающий про¬
дукт, соответствующий определенным потребностям рынка. Таким обра­
зом, если вы проектируете систему в соответствии с законом Конвея и
при этом вам легче уложиться в сроки и средства, значит, так и нужно, а
всякие и з ы с к и оставьте университетским «яйцеголовым» (так в Америке
обзывают нас и н а ш и х коллег из университетов всего мира).
Со временем закон Конвея, который был сформулирован его авто¬
р о м только в качестве шутки, был обобщен до довольно конструктивного
метода — матричного. К чему подталкивает закон Конвея? Каждый спе­
циалист выполняет только свой небольшой кусок работы, но делает это
всегда, для всех заказов такого ж е типа, набивает руку, почти не думает,
совершает мало о ш и б о к , т.е. процесс превращается в производственный.
Итак, пусть у нас есть n специалистов и m однотипных заказов.
Строим матрицу из n строк и m столбцов. Элемент в i - о й строке из j -ого
столбца обозначает работу i - о г о специалиста для j -ого заказа. Н а п р и м е р ,
один специалист хорошо делает синтаксические анализаторы, другой —
оптимизаторы, третий — генераторы и т.д., а однотипные заказы — это
трансляторы с разных я з ы к о в для разных платформ. Тем самым каждый
специалист подчинен двум руководителям — административному (он же
принадлежит какой-то группе, отделу) и руководителю проекта, в кото¬
р о м о н принимает участие в д а н н ы й момент.
У матричного метода есть свои плюсы и минусы. С одной стороны,
узкая специализация по конкретной теме позволяет надежнее п л а н и р о ­
вать сроки, добиться той самой повторяемости результатов, которой тре­
бует С М М уровня 2. С другой стороны, нарушен п р и н ц и п единоначалия
(как когда-то в Красной Армии были командиры и комиссары, причем с
одинаковыми правами и ответственностью; ж и з н ь быстро доказала не¬
правильность такого р е ш е н и я ) . Часто возникает ситуация, когда руково­
дителю проекта нужен какой-то к о н к р е т н ы й специалист, а начальник от­
дела загрузил его работой для другого заказа.
Есть и еще один недостаток матричного метода, не столь очевидный.
К о н е ч н о , занимаясь годами одним и тем ж е , специалист оттачивает свое
мастерство, но в целом он ограничен, не расширяет свой кругозор и т.п.
42

Организация коллектива разработчиков

«Специалист подобен флюсу — полнота его односторонняя». Предполо­
ж и м , некий сотрудник института много лет успешно занимался темой Х,
а по прошествии какого-то времени тема Х перестала быть актуальной
(такое в нашей науке бывает очень часто). И что он будет делать?
У Брукса описана совершенно другая модель организации коллекти¬
ва — бригада главного хирурга. С л о ж н ы е операции всегда делает один че¬
ловек — главный хирург, но ему помогает целая бригада — кто-то делает
надрезы, а потом зашивает, кто-то подает инструменты, следит за показа­
н и я м и приборов и т.д. П р и м е р н о такой ж е схемой воспользовались
М и л л з и его коллеги для разработки и н ф о р м а ц и о н н о й системы газеты
« Н ь ю - Й о р к Таймс».
Все программы, документацию, основные тесты пишет один чело¬
век — главный программист. У него есть заместитель, который участвует в
проектировании, обсуждениях, критикует р е ш е н и я главного программи¬
ста, но н и за что не отвечает. В случае болезни или по какой-то другой
важной п р и ч и н е заместитель может заменить главного программиста.
В бригаде есть тестер, секретарь, библиотекарь, продюсер с вполне по¬
н я т н ы м и ф у н к ц и я м и . Возможно подключение еще каких-то узких спе­
циалистов. Оказалось, что такая бригада может работать в 3-5 раз быстрее
традиционных команд программистов, поскольку не нужно тратить вре¬
мя на согласование деталей интерфейсов с другими программистами, и з ­
делие получается цельным и «элегантным», в ы п о л н е н н ы м в одном стиле.
Главный программист выбирается из числа наиболее опытных и высоко­
квалифицированных, он может себе позволить сосредоточиться на о с ­
новной задаче и не тратить время на всякие «бытовые» ф у н к ц и и , которы­
ми полна наша повседневная ж и з н ь .
Эта модель организации коллектива не нашла широкого примене¬
ния. Во-первых, ее трудно масштабировать. Сколько строк исходного к о ­
да может написать один программист? Ну, 50 тысяч, ну, скажем, 100. А ес¬
ли нужно м и л л и о н строк? Тогда все проблемы интерфейсов возвращают¬
ся, да еще на более сложном уровне, поскольку двум главным программи­
стам договориться гораздо труднее, чем двум рядовым. Во-вторых (или
все-таки во-первых?), где вы найдете множество программистов, готовых
безропотно подчиняться главному программисту? Н а ш а специальность
подразумевает наличие твердого характера, творческого начала, гордости
за свое детище.

43

Курс

Технология программирования

10. О р г а н и з а ц и я к о л л е к т и в а
разработчиков в компании Microsoft
Относиться к к о м п а н и и Microsoft м о ж н о по-разному — с л и ш к о м аг¬
р е с с и в н ы , чрезмерное стремление к монополизму, программы огромны
и н е э ф ф е к т и в н ы , документация часто непонятна и, опять-таки, очень
объемна. Тем не менее, абсолютное большинство пользователей работает
и м е н н о на продуктах этой к о м п а н и и , Microsoft поддерживает универси¬
теты по всему миру, да и со своим бесконечным П О успешно справляет­
ся. Поэтому в лекциях по технологии программирования м ы не можем
пропустить опыт Microsoft в этой области[12].
Служба Microsoft Consulting Services провела анализ результатов в ы ­
полнения большого количества программных проектов. Оказалось, что
только 24% проектов м о ж н о признать в той или и н о й степени успешны­
м и , 26% не были завершены, а остальные столкнулись с большими проб­
лемами, например, бюджет был превышен вдвое или затрачено в 1,5 раза
больше времени.
О с н о в н ы м и п р и ч и н а м и неудач были п р и з н а н ы следующие:
• постоянное изменение требований;
• нечеткие или неполные с п е ц и ф и к а ц и и ;
• низкое качество кода;
• с л и ш к о м широкая постановка задачи;
• ошибка в подборе кадров;
• плохая организация работы;
• нечетко сформулированные цели.
Для преодоления этих трудностей был предложен набор моделей
М ш к ^ й Solution Framework ( M S F ) , в котором учтен опыт, н а к о п л е н н ы й
группами разработки программных продуктов.
С а м ы м и р е в о л ю ц и о н н ы м и оказались модель команды разработчи¬
ков и модель процесса разработки. Первая модель (team model) описыва¬
ет, как д о л ж н ы быть организованы коллективы и к а к и м и п р и н ц и п а м и им
надо руководствоваться для достижения успеха в разработке программ.
Разные коллективы могут по-своему применять на практике различные
элементы этой модели — все зависит от масштаба проекта, размера колле¬
ктива и к в а л и ф и к а ц и и его участников.
Ф о р м и р о в а н и е коллектива — сложная задача, которая должна ре­
шаться с п о м о щ ь ю психологов. Вот некоторые основные положения:
• не должно быть команды из одних лидеров;
• не должно быть команды из одних исполнителей;
• в случае неудачи команда расформировывается;
• система штрафов (если проект проваливается — наказывают всех).
44

Организация коллектива разработчиков в компании Microsoft

Этот «бублик» описывает только роли, за н и м и могут скрываться
несколько человек, и с п о л н я ю щ и х каждую роль. Самое удивительное, что
в этой модели не предусмотрено единоначалия — все роли важны, все р о ­
ли равноправны, поэтому M S F называют моделью равных (team of peers).
Program management — управление программой. Исполнитель этой
роли отвечает за организацию (но н е руководит!): осуществляет ведение
графика работ, утренние 15-минутные совещания, обеспечивает соответ­
ствие стандартам и с п е ц и ф и к а ц и я м , ф и к с а ц и ю нарушений, н а п и с а н и е
технической документации.
Product management — управление продуктом. Исполнители этой р о ­
ли отвечают за о б щ е н и е с заказчиком, н а п и с а н и е с п е ц и ф и к а ц и и , разъяс¬
н е н и е задач разработчикам.
Development — наиболее традиционная роль — разработка и началь¬
н о е тестирование продукта.
User education — обучение пользователей. Н а п и с а н и е пользователь¬
ской документации, обучающих курсов, п о в ы ш е н и е эффективности ра¬
боты пользователей.
Logistics management — установка, сопровождение и техническая под¬
держка продукта, а также материально-техническое обеспечение работы
коллектива.
Testing — тестирование. Выявление и устранение недоработок, и с ­
правление о ш и б о к , другие ф у н к ц и и QA.
Все решения принимаются коллективно, разделяется и ответствен¬
ность в случае провала проекта.
В M S F утверждается, что такую модель м о ж н о масштабировать, раз­
бивая систему по ф у н к ц и я м . Л и ч н о у меня это утверждение (как и колле­
ктивная ответственность) вызывает большие сомнения.
45

Курс

Технология программирования

Модель процесса определяет, когда и какие работы д о л ж н ы быть вы¬
полнены.
Перечислим основные п р и н ц и п ы и практические приемы, лежащие
в основе модели:
• итеративный подход (последовательный выпуск версий);
• подготовка четкой документации;
• учет неопределенности будущего;
• учет компромиссов;
• управление р и с к а м и ;
• поддержание ответственного отношения коллектива к срокам выпу¬
ска продукта;
• разбиение крупных проектов на более мелкие управляемые части;
• ежедневная сборка проекта;
• постоянный анализ хода работ.
Process model имеет три основные особенности:
• разбиение всего процесса на фазы;
• введение опорных точек;
• итеративность.
Весь процесс разбивается на четыре взаимосвязанных фазы. Прежде
чем переходить к следующей фазе, на предыдущей д о л ж н ы быть получе¬
н ы определенные результаты.
Process model
stabilizing
(15-20 %)

envisioning
(5-10 %)

a-version

Vision approved

developing
(30-35 %)

planning
(35-40 %)

46

Организация коллектива разработчиков в компании Microsoft

В п р и н ц и п е , ничего нового тут нет, это известная спиральная м о ­
дель, н о необычно разбиение трудоемкости п о фазам, связанное с тем,
что и назначение каждой фазы весьма своеобразно.
Envisioning — выработка единого п о н и м а н и я проекта всеми членами
коллектива. Эта фаза заканчивается разработкой формализованного до¬
кумента:
problem statement — описание задачи объемом не более одной страницы;
vision statement — от чего хотим уйти, чего хотим добиться;
solution concept — что хотим внедрить и как;
user profiles — кто будет этим пользоваться;
business goals — возврат инвестиций;
design goals — конкретные цели и ограничения продукта, его кон¬
кретные свойства.
Planning — планирование очередного цикла разработки:
• функциональные спецификации;
• п л а н - г р а ф и к работ;
• оценка рисков.
Developing — разработка, причем рекомендуются различные техно¬
логические приемы, например, переиспользование кусков кода, програм¬
мирование по контракту, н а п и с а н и е защищенного от о ш и б о к П О и т.д.
Stabilizing — создание стабильной версии, готовой к использованию.
Важную роль играют о п о р н ы е точки (milestones), в которых анали¬
зируется состояние работ и производится их синхронизация. В этих точ­
ках приложение или его с п е ц и ф и к а ц и и н е замораживаются. О п о р н ы е
точки позволяют проанализировать состояние проекта и внести необхо­
д и м ы е коррективы, например, перестроиться под изменившиеся требо­
вания заказчика или отреагировать на р и с к и , возможные в ходе дальней­
шей работы. Д л я каждой опорной точки определяется, какие результаты
д о л ж н ы быть получены к этому моменту.
Каждая фаза процесса разработки завершается главной опорной
точкой (major milestone). Характеризующие ее результаты видны н е толь­
ко коллективу разработчиков, н о и заказчику. Главная опорная точка —
это момент, когда все ч л е н ы коллектива синхронизируют полученные ре¬
зультаты. Назначение таких точек в том, что о н и позволяют оценить жиз¬
неспособность проекта. После анализа результатов коллектив разработ¬
ч и к о в и заказчик совместно решают, м о ж н о л и переходить на следующую
фазу. Таким образом, главные о п о р н ы е точки — это критерии перехода с
одной фазы проекта на другую.
Внутри каждой фазы определяются промежуточные о п о р н ы е точки
(interium milestones). О н и , к а к и главные, служат для анализа и синхрони­
зации достигнутого, а н е для замораживания проекта. Н о , в отличие от
главных опорных точек, промежуточные видны только членам коллекти47

Курс

Технология программирования

ва р а з р а б о т ч и к о в . П р о м е ж у т о ч н ы е о п о р н ы е т о ч к и отмечают более
с к р о м н ы е достижения и разбивают большую задачу на мелкие части, вы¬
полнение которых легче контролировать.
Итеративность процесса заключается в его многократном повторе­
н и и на протяжении всего цикла создания и существования продукта. На
каждой успешной итерации в продукт включаются только те новые сред­
ства и ф у н к ц и и , которые удовлетворяют и з м е н я ю щ и м с я требованиям
бизнеса.
Важную роль в M S F играет postmortem — так р а н ь ш е называли рас¬
печатки памяти после аварийных завершений программы. В этом доку­
менте описывается, что было хорошо и какие возникали проблемы, т.е.
такие з н а н и я , которые м о ж н о накапливать для использования в следую¬
щих проектах.

48

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

1 1 . Документирование
Одним из главных отличий просто программы от программного п р о ­
дукта является наличие разнообразной, хорошо подготовленной доку­
ментации. Чтобы как-то структурировать этот параграф, воспользуемся
ГОСТом Е С П Д (Единая Система Программной Документации) еще с о ­
ветских времен, кстати, до сих пор не обновлявшимся[13].
Самым главным документом является ТЗ (Техническое Задание), в
котором описываются цели и задачи работы, заказчик и исполнители, тех­
нические требования, сроки и этапы, требования секретности, ф о р с - м а ­
ж о р н ы е обстоятельства и правила предъявления результатов. Техниче­
ские требования, в свою очередь, делятся на функциональные, э к о н о м и ­
ческие, требования по надежности, эффективности, з а щ и щ е н н о с т и от
несанкционированного доступа и др. ТЗ должно быть составлено таким
образом, чтобы исключить в о з м о ж н ы е разночтения, все требования
д о л ж н ы быть сформулированы так, чтобы их м о ж н о было проверить од¬
н о з н а ч н ы м образом. Самая главная ошибка н а ч и н а ю щ и х руководителей
— это неаккуратно составленное ТЗ или неоднозначные с п е ц и ф и к а ц и и . В
моей практике было много случаев, когда заказчики, пользуясь неопыт¬
ностью наших руководителей, отказывались от финальных платежей,
требовали дополнительных работ или еще каких-то преференций. С дру¬
гой стороны, при утверждении ТЗ, я как генеральный директор, не могу
уследить за всеми деталями, поэтому еще много лет назад взял себе за пра­
вило проверять только финансовую сторону договора, а уж если руково¬
дитель договора прозевал что-то по технике, то пусть ему это будет уро¬
ком. Разумеется, в таком случае пострадает и предприятие, но надо же
как-то учить руководителей.
Следующим по важности документом является П М И (Программа
и Методика И с п ы т а н и й ) . Структурно П М И подобна ТЗ — практически
для каждого пункта ТЗ в П М И говорится, как этот пункт будет проверять­
ся. Способы проверки могут быть с а м ы м и р а з н ы м и — от пропуска специ­
ального теста до изучения исходных текстов программы, но они д о л ж н ы
быть предусмотрены заранее, а не придумываться в момент испытаний.
Н о в и ч к и приступают к составлению П М И непосредственно перед завер¬
ш е н и е м работ, а о п ы т н ы е руководители составляют П М И практически
одновременно с ТЗ (хотя бы в общих чертах) и согласовывают ее с заказ­
ч и к а м и вместе с ТЗ. И м е н н о хорошо составленная П М И является гаран¬
тией успешной сдачи работ.
Руководство системного программиста, на современном чисто рус¬
ском я з ы к е называется руководством по инсталляции. В нем описывает­
ся порядок установки системы на Э В М , как проверить корректность п о ­
ставленной системы, как вносить и з м е н е н и я и т.п. Обычно это простой
49

Курс

Технология программирования

короткий документ; в противном случае система, наверное, плохая, сде­
ланная непрофессионалами.
Руководство оператора (пользователя) — это, собственно, основной
документ, о п и с ы в а ю щ и й , к а к пользоваться системой. В хорошем руко­
водстве сначала описывается идея системы, основные ф у н к ц и и и к а к и м и
пользоваться, а уже потом идет описание всех клавиш и меню. М н о г и е
современные к н и г и п о программам Microsoft представляют собой я р к и е
п р и м е р ы никуда н е годных руководств — м о ж н о прочесть 100 страниц и
не понять основных ф у н к ц и й .
Руководство программиста. Часто это самый объемный документ,
о п и с ы в а ю щ и й внутреннюю организацию программы. Обычно этот доку¬
мент идет в паре с документом «текст программы» — одностраничный д о ­
кумент с оглавлением дискеты или C D . Руководство программиста дает
заказчику возможность дописать какие-то новые фрагменты программы
или переделать старые. В современной литературе этот документ называ¬
ется S D K (Software Development Kit). Продукт, снабженный S D K , может
стоить на порядок дороже, ч е м такой ж е продукт без оного, так что мож­
но понять, насколько трудно создать действительно полезный S D K . С е й ­
час н е очень принято продавать исходные тексты программ — проблемы
с интеллектуальной собственностью, даже при наличии S D K трудно
«влезть» в чужую программу — к а к говорится, себе дороже. Поэтому боль­
ш о е распространение получили A P I (Application Program Interface). П р о ­
грамма передается только в виде D L L (библиотека двоичных кодов), н о
известно, к а к обратиться к каждой ф у н к ц и и и з других программ, т.е. и з ­
вестно и м я точки входа, количество, т и п ы и значения параметров. Нали¬
ч и е множества A P I , конечно, хуже, ч е м наличие исходных текстов (на¬
пример, нельзя переделать что-то в середине ф у н к ц и и ) , зато много п р о ­
щ е в использовании. С другой стороны, все большую популярность п р и ­
обретает F S F (Free Software Foundation)[14]. Основателем этого движения
был Ричард Столман, который забил тревогу п о поводу п о п ы т о к крупных
ф и р м запатентовать многие основные алгоритмы и программы: «Дойдет
до того, что о н и запатентуют понятия «цикл» и «подпрограмма», что м ы
будем тогда делать?» F S F представляет собой собрание программ в исход¬
ных текстах; любой программист может свободно использовать их в сво¬
их целях, н о все добавления и улучшения, которые о н сделал, тоже следу­
ет положить в FSF. Таким образом, F S F представляет собой одно и з самых
больших доступных хранилищ программ. М н о г и е ведомства (например,
военные) просто н е могут использовать программы, текстов которых о н и
не имеют. М ы уже много раз пользовались FSF, естественно, соблюдая все
правила игры.
Остальные документы, перечисленные в Е С П Д , носят формальный
или необязательный характер, поэтому м ы их обсуждать н е будем.
50

Сопровождение

12. Сопровождение
Случилось чудо — вам удалось сдать программу, а заказчик начал ее
п р о м ы ш л е н н о е использование. Вы облегченно вздохнули, обрадова¬
лись... и, как всегда, рано. Начинается этап сопровождения [4], который
длится, пока программа живет. В процессе эксплуатации возникают н о ­
вые требования, всплывают о ш и б к и , объемы обрабатываемых данных
растут, соответственно, растут и требования к эффективности. Нравится
вам это или нет, «живущую» программу придется все время изменять.
О с н о в н ы м и задачами сопровождения являются:
• исправление ошибок;
• регулярное проведение замеров производительности (профилиро¬
вание);
• улучшение «времяпожирающих» мест в программе (еще говорят «бу¬
тылочное горлышко»);
• улучшение документации;
• р а с ш и р е н и е функциональности;
• принятие р е ш е н и я о п р е к р а щ е н и и эксплуатации программы или ее
р е и н ж и н и р и н г е (переводе программы на другую платформу).
Очень трудно сопровождать программу, в процессе разработки кото¬
р о й о сопровождении никто не думал. Такие простые вещи, как разумные
к о м м е н т а р и и , выбор и д е н т и ф и к а т о р о в и ступенчатое р а с п о л о ж е н и е
строк исходного текста, заметно облегчают сопровождение, но часто раз¬
работчики об этом не заботятся. Только на этапе разработки м о ж н о пред­
усмотреть средства для профилирования, снятия трасс, отладочных печатей
и т.п. «Программист, который в процессе разработки продукта пользуется
отладочными средствами, а перед сдачей программы в п р о м ы ш л е н н у ю
эксплуатацию выкидывает их, похож на человека, который ходит по берегу
в спасательном жилете, а, уходя в море, оставляет жилет на берегу».
Важным элементом сопровождения является «горячая линия» — 24 ча­
са в сутки, 7 дней в неделю должен быть доступен специалист (по телефону
или по электронной почте), готовый ответить на вопрос, принять замеча¬
ние, просто поговорить с пользователем, и этому специалисту нужны ин¬
струментальные средства для быстрой подготовки ответов. Словом, воп­
росы сопровождения д о л ж н ы быть предусмотрены при разработке.
Сопровождение — это особое искусство. Старые программы (lega¬
cy — унаследованные) обычно состоят из сотен или даже тысяч модулей
о б щ и м объемом в м и л л и о н ы строк исходного кода. Вряд ли кто-то возь­
мется все прочитать, понять и запомнить. Обычно сопровождающий п р о ­
граммист, исправляя ошибку, л и ш ь п р и м е р н о знает, где ее искать. Более
того, после нахождения неправильного фрагмента не всегда я с н о , как п о ­
влияет исправление на другие участки кода.
51

Курс

Технология программирования

Часто бывает, что, исправив одну ошибку, получаешь две других.
Профессиональные организации, получив контракт на сопровожде¬
н и е большой программы, тратят время и деньги на ее изучение, анализ
модульной структуры, потоков управления и т.д. Такое действие называ­
ется reverse engineering (возвратное проектирование). Иногда использует­
ся термин knowledge mining (дословно — «откапывание знаний») — вос¬
становление утраченных знаний о программе только на основе ее текста.
Если есть подходящие инструментальные средства, то очень полезно уда¬
лить недостижимые участки кода (в старых программах их объем может
достигать 30%), провести удаление goto и реструктуризацию программы
(гораздо легче понимать стройную иерархическую структуру, ч е м «клубок
змей» или «спагетти»). Есть и другие специальные средства, которые м ы
рассмотрим в следующем параграфе.

52

Реинжиниринг

13. Р е и н ж и н и р и н г
Особый интерес вызывает вопрос, когда ж е следует прекращать со¬
провождение. Н а этот вопрос отвечает известная диаграмма:
. Сложность
^ исправления

выкинуть

реинжинирить

сопровождать

улучшать

Важность
для бизнеса

Здесь п о горизонтали растет важность программы для бизнеса к о м ­
п а н и и , а по вертикали — сложность внесения исправлений. Так вот, если
исправлять несложно, н о и важность — небольшая, то надо просто сопро­
вождать, исправляя о ш и б к и (corrective fixing), если ж е программа важна
для к о м п а н и и , то м о ж н о и улучшать ее (adaptive fixing). Если исправлять
сложно, а важность — небольшая, то легче программу выкинуть, если ж е
программа важна, содержит определенные з н а н и я бизнес-процессов, н о
сопровождать ее трудно, например, потому, что авторы программы поки¬
нули к о м п а н и ю или к о м п а н и я вынуждена сменить платформу, то п р о ­
грамму следует подвергнуть р е и н ж и н и р и н г у [15].
Попросту говоря, р е и н ж и н и р и н г — это перевод программы со ста­
рых я з ы к о в (Кобол, П Л 1 , Адабас-Натурал и т.п.) на новые, такие к а к Java,
Visual Basic, C++. Н а самом деле, все гораздо сложнее. Смена о п е р а ц и о н ­
н о й системы, используемой базы данных, стиля организации диалога с
пользователем — каждая и з этих задач весьма нетривиальна. Если ж е до¬
бавить естественное желание реструктурировать программу, выкинуть от¬
м е р ш и е части, перейти к объектно-ориентированной организации про¬
граммы и т.д., да еще вспомнить, что все эти задачи требуют перебора и
анализа путей в графе управления программы, число которых растет э к с ­
поненциально относительно числа вершин, то задача вообще выглядит
н е р е ш а е м о й . М ы потратили на н е е много лет п о заказу к о м п а н и и
Relativity technologies ( С Ш А , Северная Каролина) и создали продукт
Rescueware, который известная консалтинговая к о м п а н и я Gartner Group
уже дважды признала лучшим в мире в области legacy understanding и lega¬
cy transformation. Забавно, что сначала а м е р и к а н ц ы обратились в н е 53

Курс

Технология программирования

сколько известных университетов С Ш А , н о отовсюду получили ответ,
о б ъ я с н я ю щ и й невозможность решения. Н а н а ш е счастье, среди заказчи­
ков был выходец из С С С Р (Лен Эрлих), который посоветовал обратиться
к русским математикам, справедливо утверждая, что русские могут сде­
лать то, чего американцы н е могут. С о в е р ш е н н о случайно Г П «Терком»
оказался в числе трех российских к о м п а н и й , к которым обратились аме­
р и к а н ц ы . Опыта общения с и н о с т р а н н ы м и заказчиками у нас н е было,
как определять цену работы, м ы н е знали. Кстати, с этим вопросом связа­
на забавная, н о поучительная история. П р и н и м а л я американцев в своем
кабинете, наскоро переделанном и з обычной аудитории. Н а полу в лино¬
леуме была большая дырка, на которую м ы н е обращали в н и м а н и я . Через
много лет я узнал, что эта дырка уменьшила стоимость самого первого
американского заказа р о в н о в два раза.
М ы долго ломали голову, к а к подступиться к этой задаче. М ы все бы¬
ли математиками, поэтому хорошо п о н и м а л и , почему американские уче¬
н ы е отказались от нее. Н о потом сообразили, что в большинстве случаев
н а м и н е нужен п о л н ы й перебор путей в графе, а в тех случаях, когда без
него н е обойтись, м о ж н о за один перебор р е ш и т ь сразу несколько задач
или одну задачу, н о сразу для многих переменных. Н а тему реинжинирин¬
га у нас опубликовано множество работ, все о н и выложены на сайте ка¬
федры системного программирования.
Чтобы дать хоть какое-то представление о системе Rescueware, пере¬
ч и с л и м некоторые ее возможности:
1.
И н в е н т а р и з а ц и я . Осуществляется т а к н а з ы в а е м ы й ослабленный
синтаксический анализ (точный анализ затруднен из-за огромного
числа диалектов старых я з ы к о в ) , к а к и е ф а й л ы включения использу­
ются, кто кого вызывает, что и з этого есть в наличии. Случая н е бы¬
ло, чтобы заказчик выдал все сразу, н е забыв н и одного файла.
На основании различных метрик оценивается сложность работы,
трудоемкость и приблизительная стоимость.
2.
Строится дерево синтаксического разбора (видонезависимый и в и дозависимый анализы), пользователю в диалоговом р е ж и м е предос¬
тавляется возможность дополнительного изучения исходного п р и ­
ложения, представленного в виде гипертекста — на экране одновре¬
м е н н о в разных окнах видны дерево разбора и исходный тест. Если
пользователь смещается по дереву, автоматически перемещается и
курсор в исходном тексте, и наоборот. Гипертекст, к а к и другие про¬
граммы визуализации, был разработан группой М. Бульонкова в
Академгородке (г. Новосибирск), много лет работающей в тесном
контакте с нами [16].
3.
П о оригинальным алгоритмам исходное приложение преобразуется
таким образом, чтобы уменьшить или вообще свести к нулю число
54

Реинжиниринг

операторов goto, разбить приложение на процедуры или на объекты
(напоминаю, что в я з ы к е Кобол вообще не было понятия «процеду­
ра»), удалить ставшие со временем недостижимыми участки кода;
реализуются различные методы глобальной оптимизации. Здесь сле­
дует отметить, что в отличие от обычной к о м п и л я ц и и , в которой
главным требованием является семантическое соответствие объект­
ного кода исходному, (при этом сам объектный код никто не читает),
в процессе р е и н ж и н и р и н г а создается н о в ы й исходный код на другом
я з ы к е , который будет сопровождаться этими же или другими п р о ­
граммистами, поэтому на первый план выходят такие странные для
к о м п и л я ц и и вопросы как «естественность» представления програм­
м ы , структурное подобие исходному п р и л о ж е н и ю , наглядное фор¬
матирование текста и т.п.
4.
Генерация нового исходного текста на целевом я з ы к е с учетом толь¬
ко что перечисленных требований.
5.
Особого у п о м и н а н и я заслуживает B R E — Business Rules Extraction —
выделение бизнес-правил. Представьте себе, что у Вас есть приложе­
ние (как обычно, н а п и с а н н о е на разных языках), которое в ы п о л н я ­
ет 10 ф у н к ц и й . 7 из них уже безнадежно устарели, оставшиеся 3
очень важны для вашего бизнеса. П р и л о ж е н и е старое, описания ис¬
ходных алгоритмов уже не сохранились или сильно отстали от реаль¬
ной программы, авторы давно разбежались кто куда. Таким образом,
единственным носителем актуального з н а н и я осталась работающая
программа, но ее сопровождение обходится очень дорого, поэтому
хотелось бы выделить из текста только те описания и операторы, к о ­
торые задействованы в нужных трех функциях, а весь остальной
текст выкинуть. Скорее всего, получившаяся программа будет боль­
ше чем 30% от исходного текста, но все-таки намного меньше, чем
вся исходная программа, поэтому сопровождать ее будет п р о щ е и де¬
шевле.
Идея B R E очень проста — находите в к о н ц е графа программы узлы,
где возникают к о н е ч н ы е значения нужных ф у н к ц и й , и двигаетесь назад,
выбирая только те узлы и ребра, которые влияют на промежуточные
вычисления уже помеченные, как нужные.
М о ж н о и наоборот — если известно, что из 100 входных данных ин¬
тересными остаются только 40, а остальными 60 м о ж н о пренебречь, мож¬
но пройтись по графу программы слева направо аналогичным образом.
Разумеется, на практике все гораздо сложнее — чего стоят одни мас­
сивы, в которых разные элементы влияют на разные ф у н к ц и и . Тем не ме­
нее, н а м удалось добиться практически значимых результатов.

55

Курс

Технология программирования

14. У п р а в л е н и е к а ч е с т в о м
Согласно современным международным стандартам, качество про¬
граммного обеспечения, как и любого другого продукта, — это его соот­
ветствие потребностям заказчика[17]. Самый верный путь повысить каче­
ство ПО — улучшить процесс создания и сопровождения продукта.
Качество программного обеспечения (программных средств, инст¬
рументов, п р и л о ж е н и й ) , используемого в коммерческих и государствен¬
ных структурах, служащего основой всемирной сети и разнообразных ин¬
ф о р м а ц и о н н ы х систем, является критически важным фактором. Сегодня
деятельность многих организаций, предприятий и, особенно, высокотех­
нологичных к о м п а н и й напрямую зависит от качественной обработки ин¬
ф о р м а ц и и соответствующими компьютерными системами.
П р и м е н е н и е некачественного программного обеспечения может
привести к серьезным потерям и затратам на восстановление утерянных
данных и программной системы в целом. Предприятия наиболее уязвимы
в период внедрения и использования новых программных продуктов и
и н ф о р м а ц и о н н ы х систем. И м е н н о в это время ущерб от некачественного
программного обеспечения наиболее вероятен.
П о д а н н ы м исследования Тома де М а р к о ( С Ш А , 1982 г.):
• 15% всех программных проектов так и не достигли своего завершения;
• превышение стоимости проектов на 100-200% не является чем-то
необычным;
• превышение стоимости на 30% в программной индустрии считается
успехом.
Проблемы, выявленные в ходе более чем 150 экспериментов по
оценке различных программных проектов:
• помехи со стороны правительства — 10%;
• технологические факторы — 12%;
• в н е ш н и е поступления — 12%;
• оборудование — 15%;
• недостаточность контроля — 35%;
• недостаточность/недостатки планирования производственных про¬
цессов — 55%.
Выдержка из статьи «Software's Chronic Crisis», появившейся через 12 лет
после публикации этого исследования (автор W. Wayt Gibbs, журнал
«Scientific American», сентябрь 1994 года): «Исследования показали, что
на каждые 6 крупных систем программного обеспечения, запущенных в
действие, приходится 2 (т.е. 30-35%) системы, разработка которых была
прекращена из-за невозможности добиться удовлетворительного ф у н к ­
ционирования. Средний проект разработки программного обеспечения
затягивается на половину первоначально запланированного срока, круп56

Управление качеством

н ы е проекты — и того хуже. Три четверти всех больших систем либо вы¬
полняют не все функции, которые на них возлагались, либо не использу­
ются вовсе».
П о д а н н ы м Департамента по Торговле и П р о м ы ш л е н н о с т и Велико­
британии (DTI), при внедрении проектов и н ф о р м а ц и о н н ы х технологий
на предприятиях потери из-за некачественного программного обеспече­
н и я составляют в среднем около 20% от общего объема потерь. П о раз­
н ы м о ц е н к а м , аналогичный показатель для России достигает величины
от 30 до 50%.
Может показаться, что управлять количеством о ш и б о к в коде невоз¬
м о ж н о и их число зависит только от способностей конкретного разработ¬
чика. Это не совсем так. В к о н ц е 80-х — начале 90-х годов в программной
индустрии был проведен ряд серьезных исследований эффективности
труда программистов.
Вот д а н н ы е американского института программной инженерии SEI.
П р о ф е с с и о н а л ь н ы е программисты со стажем 10 и более лет на 1000 строк
кода ( С К — строка исходного текста, которая содержит программную и н ­
струкцию) допускают в среднем 131,3 о ш и б к и . Следовательно, большая
система размером м и л л и о н С К может содержать 100 тысяч ошибок! И з
них до 50% выявляется на этапе к о м п и л я ц и и (если транслятор имеет раз­
витую систему предупреждений). Н а этапе тестирования отдельных моду¬
лей (типичный программный модуль по определению SEI содержит от 5
до 5 тысяч С К ) обнаруживается половина оставшихся ошибок. Получает­
ся, что перед этапами внедрения и комплексного тестирования в продук­
те еще скрывается 25 тыс. ошибок. Н а их устранение на заключительных
этапах тратится от 10 до 40 человеко-часов на ошибку, т.е. на доведение
продукта до идеального состояния потребуется 125 человеко-лет работы!
Другая статистика. Типичный небольшой проект имеет объем 50 т ы ­
сяч С К . Его создают 5 программистов, делая при этом 100 о ш и б о к на т ы ­
сячу С К . 50% о ш и б о к выявляется на этапе к о м п и л я ц и и с незначительны­
ми расходами времени, устранение о ш и б о к на этапе тестирования з а н и ­
мает 90% времени. Стоимость устранения одной о ш и б к и в готовом п р о ­
дукте оценивается в 4 тыс. долл. (по д а н н ы м I B M , устранение о ш и б о к в
продуктах к о м п а н и и , введенных в эксплуатацию, обходится в 20 тысяч
долларов на ошибку).
Корень проблемы — в неправильных акцентах при управлении качест­
вом ПО. Корреляция между числом о ш и б о к , обнаруженных при тестиро­
вании отдельных модулей, и числом ошибок, найденных пользователями
в готовом продукте, равна 0,91. Отсюда вывод — если на тестирование по¬
ступит некачественный продукт, он таким и будет выпущен в продажу!
Таким образом, организация производства качественного программ­
ного обеспечения является ключевой проблемой управления процессом раз57

Курс

Технология программирования

работки ПО, которой в индустриально развитых странах стали активно за­
ниматься п р и м е р н о с середины 1960-х годов. К числу бесспорных дости­
ж е н и й теории менеджмента качества относятся современное понятие ка¬
чества и его смысловое наполнение, а также известные модели систем ка¬
чества серии ISO 9000.
Анализ известных нормативных документов дает основание предпо¬
лагать, что при коммерческой эксплуатации программного продукта к
числу наиболее значимых показателей качества, базирующихся на обос­
нованных претензиях пользователей, м о ж н о отнести:
• неадекватность ф у н к ц и о н и р о в а н и я программного продукта;
• недостаточное взаимодействие продукта с другими п р о г р а м м н ы м и ,
аппаратными и телекоммуникационными средствами;
• отказы программного продукта в процессе применения по назначению;
• замедленное время работы программного продукта и задержки пре­
доставления им промежуточной и выходной и н ф о р м а ц и и ;
• неполнота отражения и н ф о р м а ц и и ;
• несоответствие хранимых данных и и н ф о р м а ц и и , вводимой опера¬
тором;
• потеря актуальности и н ф о р м а ц и и , циркулирующей в информаци¬
о н н о й системе;
• нарушения конфиденциальности и н ф о р м а ц и и ;
• содержание сопроводительной документации и справочной системы
программного продукта.
К р о м е таких «первичных» данных о качестве, идущих непосредст¬
венно от потребителя, в роли показателей могут выступать: число строк
кода в стандартном модуле, количество выявленных ошибок на 1000 строк
кода, вероятность появления специфических ошибок, параметры сложно­
сти программы, стоимость единицы кода, цена «человеко-месяца», стати­
стические характеристики процессов (математические ожидания, д и с ­
персии, к о р р е л я ц и о н н ы е ф у н к ц и и и т. д.) и другие оценочные параметры.
Отсюда следует «генеральная» задача разработчика П О — на основе
анализа взаимной корреляции ранжированных потребительских, техно¬
логических и технических характеристик создать систему целевых показа¬
телей (метрик), которая задает ориентиры разработки и критерии о ц е н к и
ее качества.
Такая задача трудна даже для искушенного разработчика, однако исполь­
зование ранее наработанного опыта и знаний, накопленных в межпроектных
базах данных и отраженных в корпоративных и международных стандар¬
тах, позволяют существенно уменьшить «размерность» задачи.
Ранее было отмечено, что из-за отсутствия адекватных систем упра­
вления качеством во многих проектах (особенно крупных) временные и
э к о н о м и ч е с к и е показатели значительно в ы ш е запланированных. Н о даже
58

Управление качеством

п р е в ы ш е н и е показателей н е гарантирует в ы п о л н е н и я технических требо­
ваний. Р я д крупных IT-проектов, к а к в Европе, так и в Америке, н е д о с ­
тигли заявленных результатов, будучи н е в состоянии реализовать требуе­
м ы е технические и технологические параметры, хотя отпущенные время
и средства были значительно превышены.
Система управления качеством является частью системы управле­
н и я организацией. Цели в сфере качества дополняют основные (стратеги­
ческие) задачи организации. Различные части системы управления орга­
низации-разработчика могут быть объединены вместе с системой м е ­
неджмента качества в единую, у н и ф и ц и р о в а н н у ю систему управления с
о б щ и м и элементами. Это способствует эффективному планированию,
распределению ресурсов, установлению взаимодополняющих целей и ре­
альной оценке эффективности.
И н и ц и а т и в ы внедрения систем качества в ш и р о к и х масштабах в
Я п о н и и в начале 50-х годов, поддержанные правительственными про¬
граммами, обеспечили быстрый рост конкурентоспособности и выход
страны на лидирующие п о з и ц и и в ряде областей промышленности. Ак¬
тивное внедрение новых р е ш е н и й , направленных на обеспечение качест¬
ва, в С Ш А и Европе началось в начале 60-х годов.
Если говорить о программировании, то идеи реализации качества на
базе создания стандартного процесса разработки и сопровождения П О
п р и ш л и в эту область из промышленности в ответ на программный кри¬
зис конца 60-х годов [Wheeler Sh., Duggins Sh. Improving software quality —
A C M Proceedings of the 36th annual conference on South-East regional con¬
ference, April 1998].
Среди стандартов в области разработки систем качества, о ц е н к и ка¬
чества процессов и уровня зрелости к о м п а н и й , разрабатывающих п р о ­
граммное обеспечение, сегодня наиболее популярными являются: ISO
9000 (версии 1994 и 2000 гг.), ISO 12207, TickIT, SEI S W - C M M , Trilium,
ISO 15504 (SPICE), C M M I .
Компьютерная программа представляет собой материальный объ­
ект, н о она строится на абстрактных идеях и состоит из сложнейших вир¬
туальных конструкций. Это в корне отличает ее от физических объектов,
с которыми имеет дело обычное производство, и поэтому невозможно со¬
здать качественное П О , н е р е ш и в ряд типичных проблем:
• команда разработчиков, к а к правило, состоит из творческих лично¬
стей, которых часто бывает трудно привести к «общему знаменате¬
лю»;
• каждый программный продукт неизбежно содержит о ш и б к и , отра¬
ж а ю щ и е к в а л и ф и к а ц и ю и индивидуальный стиль разработчика —
разнообразие и нестандартность о ш и б о к сильно усложняет процесс
достижения стандартных целей в области качества;
59

Курс

Технология программирования

• каждый успешный проект по-своему уникален. О н подобен мозаике
со сложным р и с у н к о м , поэтому очень трудно выделить из него
некий базовый процесс-клише, который м о ж н о было бы применить
в дальнейших разработках;
• по сходной п р и ч и н е трудно поставить производство сложного и
уникального П О на поток, так как часто для его разработки требует­
ся создание сопутствующего специального программного «инстру­
ментария» для проектирования, оптимизации и тестирования;
• одна из специфических проблем программирования состоит в том,
что продуктивность в этой области растет очень медленно, если рас¬
тет вообще — по некоторым оценкам, средний программист спосо¬
бен создать 10-50 строк операторов в день. К р о м е того, эти о ц е н к и
д о л ж н ы быть уменьшены для больших систем, так как увеличенная
нагрузка требует значительных затрат (в относительных единицах).
Это обстоятельство резко отделяет программирование от других в и ­
дов деятельности, где поточное производство радикально уменьша­
ет цену е д и н и ц ы продукта. Вся э к о н о м и к а строится на этом далеко
не новом п р и н ц и п е — но только не производство программного обес¬
печения!
В последние годы постепенно сложилась определенная культура, поя­
вились традиции и стиль работы в сфере создания программных продуктов.

Продукт
(методики
разработки)

Проект
(методики менедж¬
мента проектов)

Персонал
(методики управ¬
ления персоналом)

1

Определение
продукта (состав,
клиентская среда
и требования)

1

Оценка стоимости
проекта в целом
(как правило, в че¬
ловеко-месяцах)

1

Набор персонала
(как правило,
на конкурсной
основе)

2

Процессы оцени¬
вания (определе­
н и я критериев)

2

Документирова¬
2
н и е общего и опе­
ративных планов

Отбор команды
проекта и обуче­
ние персонала

3

Оценка альтерна¬
тивных подходов
к реализации
продукта

3

Оценка трудо¬
затрат в структуре
проекта

3

Создание
команды проекта
и распределение
ответственности

4

Управление
требованиями

4

Оценка и менедж¬ 4
мент р и с к о в

Оценка потенци¬
альных возмож¬
ностей участни¬
ков проекта

60

Управление качеством

Продукт
(методики
разработки)
5

Проект
(методики менедж¬
мента проектов)

Персонал
(методики управ¬
ления персоналом)

Создание структу¬ 5
р ы пооперацион¬
ного перечня
работ

Оценка произво¬
дительности
команды в целом
и отдельных
участников

5

Управление
субподрядом

6

Выполнение
6
начальной оценки

Оценка ключевых
стадий и состав¬
л е н и е графика
работ

6

Взаимодействие и
общение на уров¬
не групп и коман¬
д ы в целом

7

Отбор инструмен¬ 7
тов, методов,
стандартов, раз¬
работка внутрен¬
них стандартов

Отбор инструмен¬ 7
тов управления
проектом

Обучение проект¬
ных команд для
получения
оптимальных
результатов

8

Настройка
процессов
на в ы п о л н е н и е
требований ТЗ

Знание стандартов 8
процесса и на¬
стройка стандар¬
тов на процесс

Эффективное
представление и
использование
навыков

9

П о н и м а н и е дей¬
9
ствий по разра¬
ботке продукта
(полное представ¬
ление о необходи¬
мых действиях в
течение всего Ж Ц )

Формирование
метрических по¬
казателей для
измерения пара¬
метров процессов
и управления
процессами

Успешное ведение
переговоров с
внешними и внут¬
р е н н и м и участ¬
н и к а м и проекта,
совместные об¬
суждения и оценки

10

Управление
изменениями

10 Отслеживание
10 Организация эф¬
процессов (про¬
фективных встреч
цессный монито¬
для планирования
р и н г и совершен¬
совместных работ
ствование качества)

11

Отслеживание
качества продукта
в ходе разработки
(мониторинг
качества рабочих
продуктов)

11 Отслеживание
процесса разра¬
ботки (монито¬
ринг соответствия
стандартного про¬
цесса разработки
П О принятым
требованиям)

8

12 Отслеживание хода
разработки проекта

61

9

11 Вопросы индиви¬
дуальной и кол¬
лективной интел¬
лектуальной
собственности

Курс

Технология программирования

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

62

Стандарты ISO

15. С т а н д а р т ы ISO
В 1947 году в Л о н д о н е представители 25 стран решили создать меж¬
дународную организацию, основной задачей которой стала бы координа¬
ц и я разработок и у н и ф и к а ц и я международных стандартов. Новая органи­
зация получила название International Organization for Standardization
(ISO). В настоящее время ее членами являются около 100 стран.
Главной п р и ч и н о й появления единых стандартов стало желание
инициаторов создания этой организации устранить технические барьеры
в торговле, которые возникли вследствие того, что в разных странах для
одних и тех ж е технологий и товаров действовали разнородные стандар¬
ты. Сегодня стандартами ISO «перекрыты» многие технологические от­
расли — от программирования и телекоммуникаций д о банковской и фи¬
нансовой сферы.
П о уставу членом ISO может стать «самая авторитетная в стране о р ­
ганизация, занимающаяся выработкой стандартов». Таким образом, и н ­
тересы какой-либо страны в ISO может представлять только одна органи­
зация. П о м и м о основных членов, в ISO входят так называемые ч л е н ы корреспонденты (как правило, и м и становятся относительно крупные
«стандартообразующие» организации отдельных стран, однако е щ е недо¬
статочно м о щ н ы е , чтобы распространить свое в л и я н и е на стандартиза­
ц и ю технологий п о всей стране). Члены-корреспонденты н е принимают
активного участия в разработке международных стандартов, н о имеют
п о л н ы й доступ к интересующей их и н ф о р м а ц и и . Н а к о н е ц , есть е щ е и
ч л е н ы - п о д п и с ч и к и — о н и представлены организациями развивающихся
стран. Россия на сегодня имеет статус члена-корреспондента ISO.
Выполнение технической работы в ISO возложено на 2700 техниче¬
ских комитетов, подкомитетов и рабочих групп, в состав которых входят
представители правительственных, п р о м ы ш л е н н ы х , научно-исследова¬
тельских и юридических кругов (всего около 500 организаций). Каждая
организация — член ISO — имеет право включить своего представителя в
любой комитет, в деятельности которого о н а особо заинтересована.
Н о в ы е стандарты рождаются в соответствии с тремя п р и н ц и п а м и .
Во-первых, о н и являются результатом консенсуса всех заинтересован­
ных сторон — производителей, поставщиков, потребителей, профессио¬
нальных разработчиков, правительственных и исследовательских органи¬
заций.
Во-вторых, стандарты имеют действительно мировое распростране­
ние и удовлетворяют к а к производителей, так и потребителей.
В-третьих, появление новых стандартов диктуется исключительно
требованиями свободного рынка, а н е чьей-то злой или доброй волей. Если
р ы н о к созрел для нового стандарта, то такой стандарт появляется.
63

Курс

Технология программирования

Процесс создания нового стандарта включает три этапа. Обычно
инициатива его разработки исходит от производителей, которые доводят
базовые предложения стандарта до своего представителя в ISO. Если эта
организация признает целесообразность создания нового стандарта, то
соответствующая рабочая группа определяет техническую область, на к о ­
торую предполагаемый стандарт будет распространяться. Н а втором эта¬
пе происходит выработка технических с п е ц и ф и к а ц и й , в ходе которой
представители различных стран стремятся достичь консенсуса. Н а заклю­
чительном этапе первая версия стандарта утверждается (за стандарт долж­
но проголосовать 75% кворума) и публикуется.
П о мере совершенствования технологий, появления новых материа­
лов, методов обработки, п о в ы ш е н и я требований к качеству и надежности
изделий возникает необходимость в пересмотре стандартов. В ISO суще¬
ствует правило: все стандарты д о л ж н ы пересматриваться н е реже ч е м раз
в пять лет. Сегодня «перу» ISO принадлежит около 9300 различных стан¬
дартов, описание которых занимает 171000 страниц текста на английском
языке.
Серия ISO 9000 [18] (управление качеством) включает в себя следу¬
ю щ и е стандарты:
• ISO 9000-1 (1994 г.). Управление качеством и гарантии качества.
Часть 1. Руководство п о выбору и использованию.
• ISO 9000-2 (1993 г.). Управление качеством и гарантии качества.
Часть 2. Общее руководство п о п р и м е н е н и ю стандартов ISO 9001,
ISO 9002 и ISO 9003.
• ISO 9000-3 (1991 г.). Управление качеством и гарантии качества.
Часть 3. Руководство по п р и м е н е н и ю стандарта ISO 9001 п р и разра¬
ботке, установке и сопровождении П О .
• ISO 9000-4 (1993 г.). Управление качеством и гарантии качества.
Часть 4. Руководство по управлению надежностью программ.
О с н о в о п о л а г а ю щ и й стандарт ISO 9001 (1994 г.) задает модель
системы качества для процессов проектирования, разработки, производ­
ства, установки и обслуживания (продукта, системы, услуги).
О с н о в н ы м преимуществом моделей ISO серии 9000 является их из¬
вестность, распространенность, признание на мировом уровне, большое
количество экспертов и аудиторов и невысокая стоимость услуг сертифи¬
кации. Универсальность ж е моделей ISO серии 9000 имеет определенные
недостатки: о н и являются достаточно высокоуровневыми, задают абст¬
р а к т н ы е модели и н е содержат конкретных методологических разработок.
П о ISO качество — это совокупность свойств и характеристик проду¬
кта, процесса или услуги, которые обеспечивают способность удовлетво¬
рять заявленным или подразумеваемым потребностям. С о в р е м е н н ы е
с п о с о б ы обеспечения качества базируются н а подходах T Q M (Total
64

Стандарты ISO

Quality Management). Э т о у п р а в л е н и е р е с у р с а м и и п р и м е н е н и е к о л и ­
чественных методов анализа для улучшения: разработок, материалов
и услуг, п о с т а в л я е м ы х в о р г а н и з а ц и ю ; всех п р о ц е с с о в в н у т р и о р г а н и ­
з а ц и и ; степени удовлетворенности настоящих и будущих потребностей
клиентов.
В модели ISO 9000 л и ш ь упоминаются требования, которые д о л ж н ы
быть реализованы, н о н е говорится, к а к это м о ж н о сделать. Поэтому для
построения п о л н о ц е н н о й системы качества п о ISO п о м и м о основной м о ­
дели ISO 9001 (1994 или 2000 года), необходимо использовать вспомогатель­
н ы е отраслевые и рекомендательные стандарты. Д л я организации, з а н и ­
мающейся разработкой программного обеспечения, такими стандартами
являются: ISO 9004-1:94 (ISO 9004:2000), ISO 8402:94 (ISO 9000:2000),
ISO 9000-3:91, ISO 10007:95, ISO 10013:95, ISO 12207:95.
Семейство стандартов ISO 9000 версии 2000 года разработано с тем
чтобы преодолеть недостатки ISO 9000 версии 1994 года и помочь органи­
зациям всех специализаций, типов и размеров внедрить и использовать
э ф ф е к т и в н ы е системы менеджмента качества.
Подход к системам менеджмента качества является о б щ и м и п р и м е ­
няется к организациям в любой отрасли э к о н о м и к и , поэтому д а н н ы й
стандарт н е устанавливает каких-либо конкретных требований к про¬
граммным продуктам. Требования к н и м могут определяться заказчиками
или третьими лицами и содержаться в технических спецификациях, стан­
дартах на продукт, стандартах на процесс, контрактных соглашениях
и нормативных документах.
В основу построения системы качества в соответствии с моделью
ISO 9000:2000 закладываются следующие п р и н ц и п ы :
• концентрация на потребностях заказчика;
• активная лидирующая роль руководства;
• вовлечение исполнителей в процессы совершенствования;
• реализация процессного подхода;
• системный подход к управлению;
• обеспечение непрерывных улучшений;
• принятие р е ш е н и й на основе фактов;
• взаимовыгодные отношения с поставщиками.
П р и этом методически в п о л н о м соответствии с д и с ц и п л и н о й по¬
строения сложных систем в стандарте ISO 9000:2000 предусматривается,
с одной стороны, построение организационной системы «сверху — вниз»:
от целей предприятия и его политики — к организационной структуре и
ф о р м и р о в а н и ю бизнес-процессов, и с другой — итеративное развитие о р ­
ганизационной системы через механизмы измерения и улучшения.

65

Курс

Технология программирования

Внедрение системы менеджмента качества организацией—разработ¬
ч и к о м программных продуктов по ISO 9000 версии 2000 года состоит и з
нескольких этапов. В их числе выделяются:
• измерение характеристик продуктов для определения эффективно¬
сти каждого процесса, направленного на достижение соответствую¬
щего качества;
• п р и м е н е н и е результатов измерений для определения текущей э ф ф е ­
ктивности процессов создания и внедрения продуктов;
• определение способов предотвращения дефектов, снижения и з м е ­
няемости продукции и м и н и м и з а ц и и доработок;
• поиск возможностей по с н и ж е н и ю р и с к о в и улучшению эффектив¬
ности и производительности технологических и иных процессов;
• выявление и расстановка в порядке важности тех улучшений, кото¬
р ы е могут давать оптимальные результаты с приемлемыми р и с к а м и ;
• планирование стратегии, процессов и ресурсов для получения иден¬
т и ф и ц и р о в а н н ы х улучшений продукции;
• контроль результатов улучшений;
• сравнение полученных результатов с ожидаемыми;
• определение подходящих корректирующих действий.
Реализация этих этапов возможна только при наличии в организа¬
ц и и системы критериев, показателей и факторов качества, а также мето¬
дов их измерения и оценки.

66

Capability Maturity Model for Software (Модель SEI SW-CMM)

16. Capability M a t u r i t y M o d e l f o r S o f t w a r e
( М о д е л ь SEI S W - C M M )
В 1982 году М и н и с т е р с т в о о б о р о н ы С Ш А образовало к о м и с с и ю ,
о с н о в н о й задачей к о т о р о й стало исследование проблем, в о з н и к а ю щ и х
п р и разработке п р о г р а м м н ы х продуктов в организациях министерства.
В результате деятельности к о м и с с и и в декабре 1984 году был создан И н ­
ститут и н ж е н е р о в - р а з р а б о т ч и к о в п р о г р а м м н о г о о б е с п е ч е н и я (Software
Engineering Institute, SEI) на базе Университета К а р н е г и - М е л л о н а в
Питсбурге.
В 1986 году SEI и корпорация Mitre под руководством Уоттса Хам­
ф р и (Watts Humphrey) приступили к разработке критериев о ц е н к и зрело­
сти технологических процессов — Capability Maturity Model ( C M M ) [19].
Далее события развивались в следующем порядке.
1987 г. S E I публикует: краткое о п и с а н и е структуры C M M ; методы
о ц е н к и п р о ц е с с о в р а з р а б о т к и П О ; методы о ц е н к и зрелости п р о ц е с с о в
производства П О ; анкету д л я в ы я в л е н и я с т е п е н и зрелости п р о ц е с с о в
(для п р о в е д е н и я самостоятельного, внутреннего аудита и в н е ш н е г о ау¬
дита).
1991 г. Выпуск версии C M M v1.0.
1992 г. Выпуск версии C M M v1.1.
1997 г. Выпуск очередной (усовершенствованной) версии C M M .
Методология C M M разрабатывалась и развивалась в С Ш А как сред­
ство, позволяющее выбирать лучших производителей П О для выполне­
н и я госзаказов. Для этого предполагалось создать критерии оценки зре­
лости ключевых процессов компании-разработчика и определить набор
действий, необходимых для их дальнейшего совершенствования. В итоге
методология оказалась чрезвычайно полезной для большинства компа­
н и й , стремящихся качественно улучшить существующие процессы п р о ­
ектирования, разработки, тестирования программных средств и свести
управление и м и к п о н я т н ы м и легко реализуемым алгоритмам и техноло­
гиям, о п и с а н н ы м в едином стандарте.
С М М де-факто стал и м е н н о таким стандартом. Его п р и м е н е н и е по¬
зволяет поставить разработку П О на п р о м ы ш л е н н у ю основу, повысить
управляемость ключевых процессов и производственную культуру в це¬
лом, гарантировать качественную работу и исполнение проектов точно в
срок. Основой для создания С М М стало базовое положение о том, что
фундаментальная проблема «кризиса» процесса разработки качественно­
го П О заключается не в отсутствии новых методов и средств разработки,
а в неспособности к о м п а н и и организовать технологические процессы и
управлять ими.
67

Курс

Технология программирования

Для о ц е н к и степени готовности предприятия разрабатывать качест­
в е н н ы й программный продукт С М М вводит ключевое понятие зрелость
организации (Maturity). Незрелой считается организация, в которой:
• отсутствует долговременное и проектное планирование;
• процесс разработки программного обеспечения и его ключевые с о ­
ставляющие не и д е н т и ф и ц и р о в а н ы , реализация процесса зависит от
текущих условий, конкретных менеджеров и исполнителей;
• методы и процедуры не стандартизированы и не документированы;
• результат не предопределен реальными критериями, вытекающими
из запланированных показателей, п р и м е н е н и я стандартных техно¬
логий и разработанных метрик;
• процесс выработки решения происходит стихийно, на грани искусства.
В этом случае велика вероятность появления неожиданных проблем,
п р е в ы ш е н и я бюджета или н е в ы п о л н е н и я сроков сдачи проекта. В такой
к о м п а н и и , к а к правило, менеджеры и разработчики не управляют п р о ­
цессами — они вынуждены заниматься разрешением текущих и спонтан­
но возникающих проблем. Отметим, что на д а н н о м этапе развития нахо­
дится большинство российских к о м п а н и й .
Основные признаки зрелой организации:
• в компании имеются четко определенные и документированные про­
цедуры управления требованиями, планирования проектной деятель­
ности, управления конфигурацией, создания и тестирования про­
граммных продуктов, отработанные механизмы управления проектами;
• эти процедуры постоянно уточняются и совершенствуются;
• оценки времени, сложности и стоимости работ основываются на на¬
копленном опыте, разработанных метриках и количественных пока¬
зателях, что делает их достаточно точными;
• актуализированы в н е ш н и е и созданы внутренние стандарты на клю¬
чевые процессы и процедуры;
• существуют обязательные для всех правила оформления методоло¬
гической программной и пользовательской документации;
• технологии незначительно меняются от проекта к проекту на осно¬
вании стабильных и проверенных подходов и методик;
• максимально используются наработанные в предыдущих проектах
организационный и производственный опыт, программные модули,
библиотеки программных средств;
• активно апробируются и внедряются новые технологии, произво­
дится оценка их эффективности.
С М М определяет пять уровней технологической зрелости к о м п а н и и ,
по которым заказчики могут оценивать потенциальных претендентов на
заключение контракта, а разработчики — совершенствовать процессы со¬
здания П О .
68

Capability Maturity Model for Software (Модель SEI SW-CMM)

Каждый и з уровней, кроме первого, состоит и з нескольких ключе­
вых областей процесса (Key Process Area), содержащих цели (Goal), обяза­
тельства по выполнению (Commitment to Perform), осуществимость выпол­
нения (Ability to Perform), выполняемые действия (Activity Performed), их
измерение и анализ (Measurement and Analysis) и проверку внедрения
(Verifying Implementation). Таким образом, С М М фактически является
комплексом требований к ключевым параметрам эффективного стан¬
дартного процесса разработки П О и способам его постоянного улучшения.
Выполнение этих требований, в конечном счете, увеличивает вероят­
ность достижения предприятием поставленных целей в области качества.
Начальный уровень (Initial Level — Level 1).
К данному уровню относится к о м п а н и я , которой удалось получить
заказ, разработать и передать заказчику программный продукт. Стабиль¬
ность разработок отсутствует. Л и ш ь некоторые процессы определены, ре¬
зультат всецело зависит от усилий отдельных сотрудников. Успех одного
проекта н е гарантирует успешности следующего. К этой категории мож¬
но отнести любую к о м п а н и ю , которая хоть как-то исполняет взятые на
себя обязательства.
Ключевые области процесса этого уровня н е зафиксированы.
Повторяемый уровень (Repeatable Level — Level 2).
Этому уровню соответствуют предприятия, обладающие определен­
н ы м и технологиями управления и разработки. Управление требованиями
и планирование в большинстве случаев основываются на разработанной
документированной политике и н а к о п л е н н о м опыте. Установлены и вве¬
д е н ы в повседневную практику базовые показатели для о ц е н к и парамет¬
р о в проекта. Менеджеры отслеживают выполнение работ и контролиру¬
ют временные и производственные затраты.
В к о м п а н и и разработаны некоторые внутренние стандарты и орга¬
н и з о в а н ы специальные группы проверки качества (QA). И з м е н е н и я вер¬
сий конечного программного продукта и созданных промежуточных про¬
граммных средств отслеживаются в системе управления конфигурацией.
Имеется необходимая д и с ц и п л и н а соблюдения установленных правил.
Э ф ф е к т и в н ы е методики и процессы институционализируются (устанавли­
ваются), что обеспечивает возможность повторения успеха предыдущих
проектов в той ж е прикладной области.
Ключевые области процесса разработки П О этого уровня:
• Управление требованиями (Requirements management).
• П л а н и р о в а н и е проекта разработки П О (Software project planning).
• Отслеживание хода проекта и контроль (Software project tracking and
oversight).
• Управление субподрядчиками разработки П О (Software subcontract
management).
69

Курс

Технология программирования

• Обеспечение уверенности в качестве разработки П О (Software quali¬
ty assurance).
• Управление конфигурацией продукта (Software configuration manage¬
ment).
Определенный уровень (Defined Level — Level 3).
Уровень характеризуется детализированным методологическим под¬
ходом к управлению (то есть описаны и закреплены в документирован¬
ной политике т и п и ч н ы е действия, необходимые для многократного п о ­
вторения: роли и ответственность участников, стандартные процедуры и
операции, порядок действий, количественные показатели и метрики про¬
цессов, форматы документов и пр.).
Для создания и поддержания методологий в актуальном состоянии в
организации уже подготовлена и постоянно функционирует специальная
группа. К о м п а н и я регулярно проводит тренинги для п о в ы ш е н и я п р о ф е с ­
сионального уровня своих сотрудников.
Начиная с этого уровня, организация практически перестает зави¬
сеть от личностных качеств конкретных разработчиков и не имеет тен¬
д е н ц и и опускаться на н и ж е с т о я щ и е уровни. Эта независимость обуслов­
лена продуманным механизмом постановки задач, планирования меро­
приятий, выполнения операций и контроля исполнения.
Управленческие и инженерные процессы документированы, стандар­
тизированы и интегрированы в у н и ф и ц и р о в а н н у ю для всей организации
технологию создания П О . К а ж д ы й проект использует утвержденную вер­
сию этой технологии, адаптированную к особенностям текущего проекта.
Ключевые области процесса разработки П О этого уровня:
• Цель упорядочивания работы организации (Organization Process
Focus).
• Определение (стандартного) процесса организации (Organization
Process Definition).
• Программа обучения (Training Program).
• Интегрированное управление разработкой П О (Integrated Software
Management).
• Технология разработки программных продуктов (Software Product
Engineering).
• Межгрупповая координация (Intergroup Coordination).
• Экспертные (совместные) о ц е н к и коллег (Peer Reviews).
Управляемый уровень (Managed Level — Level 4).
Уровень, при котором разработаны и закреплены в соответствующих
нормативных документах количественные показатели качества. Более
высокий уровень управления проектами достигается за счет уменьшения
отклонений различных показателей проекта от запланированных. П р и
этом систематические и з м е н е н и я в производительности процесса (тен70

Capability Maturity Model for Software (Модель SEI SW-CMM)

д е н ц и и , тренды) м о ж н о выделить и з случайных вариаций (шума) на ос¬
новании статистической обработки результатов измерений по процессам,
особенно в хорошо освоенных и достаточно формализованных процесс¬
ных областях.
Ключевые области процесса разработки П О этого уровня:
• К о л и ч е с т в е н н о е у п р а в л е н и е п р о ц е с с о м (Quantitative Process
Management).
• Управление качеством П О (Software Quality Management).
Оптимизирующий уровень (Optimizing Level — Level 5).
Для этого уровня мероприятия п о совершенствованию рассчитаны
не только на существующие процессы, н о и на внедрение, использование
новых технологий и оценку их эффективности. Основной задачей всей
организации на этом уровне является постоянное совершенствование су¬
ществующих процессов, которое в идеале направлено на предотвращение
известных о ш и б о к или дефектов и предупреждение возможных. Приме¬
няется механизм повторного использования компонентов от проекта к
проекту (шаблоны отчетов, форматы требований, процедуры и стандарт¬
н ы е операции, библиотеки модулей программных средств).
Ключевые области процесса разработки П О этого уровня:
• Предотвращение дефектов (Defect Prevention).
• Управление
изменением
технологий
(Technology
Change
Management).
• Управление изменением процесса (Process Change Management).
С М М определяет следующий м и н и м а л ь н ы й набор требований: реа­
лизовать 18 ключевых областей процесса разработки П О , содержащих 52
цели, 28 обязательств к о м п а н и и , 70 возможностей в ы п о л н е н и я (гарантий
к о м п а н и и ) и 150 ключевых практик.
В результате аудита и аттестации к о м п а н и и присваивается опреде¬
л е н н ы й уровень, который п р и последующих аудитах в дальнейшем может
повышаться или понижаться. Следует отметить, что каждый следующий
уровень в обязательном порядке включает в себя все ключевые характери­
стики предыдущих. В связи с этим сертификация к о м п а н и и п о одному из
уровней предполагает безусловное в ы п о л н е н и е всех требований более
низких уровней.
К преимуществам модели SEI S W - C M M относится то, что она о р и ­
ентирована на организации, занимающиеся разработкой программного
обеспечения. В д а н н о й модели удалось более детально проработать тре­
бования, с п е ц и ф и ч н ы е для процессов, связанных с разработкой П О . П о
этой п р и ч и н е в SEI S W - C M M приведены н е только требования к процес¬
сам организации, н о и примеры реализации таких требований.
Основной ж е недостаток S W - C M M заключается в том, что модель
не авторизована в качестве стандарта н и международными, н и н а ц и о 71

Курс

Технология программирования

нальными органами п о стандартизации. Впрочем, C M M давно уже стала
п р о м ы ш л е н н ы м стандартом де-факто.
К недостаткам д а н н о й модели необходимо отнести также большие
в н е ш н и е накладные расходы на приведение процессов к о м п а н и и в соот¬
ветствие модели С М М , нежели к моделям ISO 9000. Это связано с мень¬
шей распространенностью модели в мире, м е н ь ш и м количеством консал¬
тинговых органов и экспертов и, в результате, с гораздо большими внеш¬
н и м и затратами на консалтинг и на подтверждение соответствия процес¬
сов независимой третьей стороной. Тем н е менее, C M M , н е с о м н е н н о , по¬
лезнее ISO 9000.

72

CASE-технологии

17. C A S E - т е х н о л о г и и
На протяжении всей истории программирования программные п р о ­
екты все более и более усложнялись, объем работ стремительно увеличи­
вался (особенно это проявилось в бизнес-приложениях), возникла по¬
требность в таком универсальном средстве, которое могло бы помочь както структурировать, упорядочить и даже автоматизировать создание П О .
Проблема была глубже — необходимо было как-то объединить заказчи­
ков, разработчиков, программистов, пользователей — причем в условиях
постоянно меняющейся ситуации. А для того, чтобы о чем-то договорить­
ся, нужен какой-то общий язык. Традиционные я з ы к и программирования
в силу малой наглядности, избыточности и многословия для этой роли
не подходили, и, в к о н ц е концов, стали предприниматься попытки созда­
н и я четкого графического языка. Реализации графических я з ы к о в и мето­
дологии их использования способствовали появлению программно-тех­
нологических средств специального класса — CASE-средств [20]. Аббре­
виатура C A S E р а с ш и ф р о в ы в а е т с я к а к Computer-Aided Software
Engineering, т.е. разработка П О с помощью компьютера.
Изобразим ось времени, в качестве начальной точки возьмем 1965 год.
И м е н н о тогда начался период раннего внедрения компьютеров в бизнесе.
В то время применялись в основном м э й н ф р е й м ы (mainframes) — боль­
ш и е Э В М коллективного пользования.

1970
MF

1980

1990

2000

2005

20 лет
CS

—

10 лет
Internet

•••
5 лет

M F — Mainframe
CS — Client Server

UNPC

• — период ранней адаптации системы в бизнесе
— система доминирует
• — система продолжает существовать

73

Курс

Технология программирования

С 1970 по 1990 год м э й н ф р е й м ы доминировали на р ы н к е . Мэйн¬
ф р е й м в то время — э т о , прежде всего, I B M 360/370. Все д а н н ы е храни¬
лись и обрабатывались на одной очень большой Э В М , пользователи ра¬
ботали за экранами терминалов, которые могли только отображать ин¬
ф о р м а ц и ю , н о н и к а к о й обработки н е производили. В С С С Р скопировали
м э й н ф р е й м ы под именем Е С Э В М . Б ы л и к л о н ы I B M 360/370 в Англии,
ФРГ и Японии.

СТРУКТУРНОЕ
ПРОГРАММИРОВАНИЕ

ХАОС

-1970

RYO

SDM

IE

G U I & OO

1970

1980

1990

2000

2005

В середине 1980-х годов появляется альтернатива м э й н ф р е й м а м : с и ­
стемы клиент-сервер (client-server), которые занимали ведущее положе¬
н и е с 1990 по 2000-е годы. В этом случае на клиентском рабочем месте уже
могла осуществляться какая-то обработка данных, например, их ф о р м а ­
тирование, распаковка, простые расчеты. Основные вычисления п о прежнему выполнялись в центре (на сервере).
В середине 1990-х начинается адаптация Internet-систем, которые
доминируют с середины 2000-го года. Сейчас начинают появляться новые
системы, которым р а н ь ш е н е было аналогов; их принято называть «не
ПК» (un-PC). В их число м о ж н о включить мобильные телефоны, к а р м а н ­
н ы е компьютеры, системы управления автомобилем (например, стои­
мость программного обеспечения автомобиля Ford уже превышает стои¬
мость железа, и з которого о н сделан) и многое другое.
Характерно, что с развитием компьютерных технологий о н и стано­
вятся дешевле, а сами компьютеры — более доступными (особенно это
проявилось в 1980-90-е гг.); к а к следствие, создается больше систем на ба¬
зе каждой конкретной технологии.
Прослеживается такая закономерность: период д о м и н и р о в а н и я ка­
ждой последующей технологии сокращается вдвое; одновременно все бо­
лее многочисленными и масштабными становятся создаваемые системы.
Посмотрим на эволюцию подхода к проектированию систем.
74

CASE-технологии

Развитие методологии проектирования
С середины 1960-х до середины 1970-х годов программы преимуще¬
ственно писались по п р и н ц и п у R Y O (Roll Your Own), т. е. каждый писал
так, как хотел и к а к умел — не было определенных подходов к процессу
разработки П О . В середине 70-х годов прошлого столетия возникла идея
структурного программирования ( S D M , Structure Design Methodology),
происходит развитие методологии программирования и технологии моде­
лирования. В Европе главным идеологом структурного программирова­
н и я считается Дейкстра, а в С Ш А — Д е М а р к о . Разработчики приходят к
п о н и м а н и ю , что систему (программу) м о ж н о описывать без использова¬
н и я конструкций я з ы к а программирования, а на более абстрактном уров­
не. В этот период времени программисты (и не только) п о н я л и , что моде­
лирование играет немаловажную роль, а вместе с н и м и правила для моде­
лирования. К этому моменту относится и введение блок-схем (flow charts).
Для этого этапа развития технологии моделирования характерно, что
центром программного продукта является процесс, а не д а н н ы е (для хра­
н е н и я данных использовались индексные ф а й л ы и иерархические базы
данных).
В середине 1980-х годов происходит очередной прорыв: появляются
р е л я ц и о н н ы е базы данных, один из авторов которых — James Martin.
Главной частью программного продукта становятся д а н н ы е и базы д а н ­
ных. Теоретиками была создана реляционная алгебра [21], ставшая о с н о ­
вой для построения реляционных баз данных. Отсюда и новый подход к
моделированию систем — IE (Information Engineering — методы и средст¬
ва проектирования прикладных и и н ф о р м а ц и о н н ы х программ), в кото­
рых за основу принимаются не процессы, а структуры обрабатываемых
данных.
С появлением персональных компьютеров на уровне систем клиентсервер развивается графический интерфейс ( G U I , Graphic User Interface).
В связи с этим рождается объектно-ориентированный подход к проекти¬
р о в а н и ю (ОО), объединивший в одной сущности программу и данные.
Стоит отметить два вида объектно-ориентированного программиро¬
вания, которые по сей день сосуществуют, хотя и велись споры о правиль­
ности каждого из них и нелогичности другого. Object Action заключается в
том, что сначала выбирается объект, а потом уже реализовываются его
действия, которые впоследствии будут использованы. Action Object ж е , на­
оборот, предлагает продумать необходимые действия, а затем выбрать, ка¬
кой и м е н н о объект будет их реализовывать.
Главные составляющие CASE-продукта таковы:
• методология (Method Diagrams), которая задает единый графический
я з ы к и правила работы с н и м . CASE-технологии обеспечивают всех
75

Курс

Технология программирования

участников проекта, включая заказчиков, единым, строгим, нагляд­
н ы м и интуитивно п о н я т н ы м графическим я з ы к о м , позволяющим
получать обозримые к о м п о н е н т ы с простой и я с н о й структурой.
П р и этом программы представляются двумерными диаграммами
(которые п р о щ е в использовании, ч е м многостраничные о п и с а н и я ) ,
позволяющими заказчику участвовать в процессе разработки, а раз­
работчикам — общаться с экспертами предметной области, разде­
лять деятельность системных аналитиков, проектировщиков и п р о ­
граммистов, облегчая и м защиту проекта перед руководством, а так­
же обеспечивая легкость сопровождения и внесения и з м е н е н и й в
систему.
• графические редакторы (Graphic Editors), которые помогают рисовать
диаграммы; возникли с распространением P C и G U I . Этими двумя
составляющими (так называемые upper case технологии) CASE-тех­
нологии поначалу и были ограничены. Диаграммы стало легко рисовать,
их появилось множество, н о пользы от н и х было мало — проектиро­
вание было развито л и ш ь на уровне рисования. Существовало мно¬
го проблем: никто н е знал все используемые в тот момент техноло¬
гии (не мог писать и для м э й н ф р е й м о в , и для клиента, и для серве­
ра); н е я с н о было, к а к объединять написанное для разных платформ.
• генератор: п о графическому представлению модели м о ж н о сгенери­
ровать исходный код для различных платформ (так называемая low
case часть CASE-технологии). Генерация программ позволяет авто­
матически построить до 85-90% объектного кода или текстов на я з ы ­
ках высокого уровня, н о только для хорошо формализуемых частей
программы (прежде всего, для описания баз данных и для задания
ф о р м ввода-вывода и н ф о р м а ц и и ) . Сложная обработка, к а к обычно,
может быть описана с п о м о щ ь ю ручного программирования.
• репозиторий, своеобразная база данных для хранения результатов р а ­
боты программистов (сложилась парадоксальная ситуация: к тому
моменту базами данных пользовались все, кроме программистов),
происходит переход от «плоских» файлов к системе хранения ин¬
ф о р м а ц и и о разработке проекта.

Примеры CASE-средств
Если сначала диаграммы рисовались вручную, то в середине 1980-х
годов появляются первые продукты, реализующие CASE-технологию.
К о м п а н и я T I (Texas Instruments) выпускает продукт I E F (Information
Engineering Facility), к о м п а н и я K W (Knowledge Ware) создает ADW. Целе¬
в ы м и п л а т ф о р м а м и обоих продуктов были только м э й н ф р е й м ы , ч т о
являлось их о с н о в н ы м недостатком. В 1986 году начинаются разработки
76

CASE-технологии

продукта H P S (High Productivity System), а в 1990 году образуется компа­
н и я S E E R , которая выпускает H P S на рынок. В 1992-1993гг. по заказу
этой к о м п а н и и м ы полностью переписали H P S , сохранив их замечатель¬
н ы е бизнес-идеи.
Технологии оказались востребованными на р ы н к е : на 1995 год объе¬
м ы продаж I E F равнялись 200 млн. долл., A D W — 150 млн. долл., H P S —
120 млн. долл. У продукта H P S был более высокий уровень генерации к о ­
да (lower case), н о более слабый уровень методологии и графических реда¬
кторов (upper case).
В середине 1980-х годов м ы также разработали технологию RTST, к о ­
торая включала в себя все перечисленные в ы ш е к о м п о н е н т ы , в том числе
генератор в Алгол 68. В чем-то м ы даже превзошли американцев, по¬
скольку о н и умели генерировать только э к р а н н ы е ф о р м ы , базы данных и
стандартные действия C R U D (create, read, update, delete), а м ы в д о п о л н е ­
н и е к этому генерировали и бизнес-логику на основе SDL-диаграмм. Эта
технология до сих п о р активно используется п р и производстве П О теле¬
ф о н н ы х станций, н о н и о каких продажах в н а ш е й стране пиратского П О
м ы и н е думали.
Рассмотрим таблицу, характеризующую основные уровни развития
использования CASE-технологии в бизнесе:
Годы

Организации

Тип систем

1965 — 1975

немногие

Изолированные

1975 — 1985

многие

Изолированные

1985 — 1995

многие

Enterprise level

1995 — 2000

многие

Department level

с 2000

многие

SOA

К середине 1980-х годов системы и проекты разрастаются. Поначалу
немногие организации могли создавать м о щ н ы е системы. Затем, с рас¬
п р о с т р а н е н и е м м э й н ф р е й м о в , к о л и ч е с т в о т а к и х о р г а н и з а ц и й увели¬
ч и л о с ь , н о разработка систем п о - п р е ж н е м у н и к а к н е координирова¬
лась. Д л я ранних уровней развития проектирования характерная черта —
и з о л и р о в а н н о с т ь «островков автоматизации» в «море» о р г а н и з а ц и и
(этап с 1965 по 1985 гг.). Позже, при п о м о щ и IEF, A D W , H P S (на базе I E
и CASE-технологий), п р е о б л а д а ю щ и м становится ц е н т р а л и з о в а н н о е
планирование в рамках всей организации (enterprise level). В то время
проекты требовали участия 500-1000 человек в течение 1-2 лет.

77

Курс

Технология программирования

В середине 1990-х годов такая «гигантомания» признается экономи¬
чески нецелесообразной, разработка систем переходит на уровень depart¬
ment level, когда проектирование и планирование осуществляются в р а м ­
ках одного отдела (департамента); для этого требуется работа 2-5 человек
в течение одного-двух месяцев. В этот момент были очень популярны
средства быстрого прототипирования — Rapid Application Development
( R A D ) , такие как Power Builder, F O R T E , Sun Microsystems Powery.
Средства быстрого п р о т о т и п и р о в а н и я отодвинули на второй п л а н
CASE-средства, н о , в свою очередь, б ы л и задавлены а г р е с с и в н о й п о ­
л и т и к о й Microsoft. Н а к а к о е - т о в р е м я с а м ы м п о п у л я р н ы м я з ы к о м
стал Visual Basic. В последнее в р е м я наблюдается переход к у р о в н ю
SOA (Service-Oriented Architecture), о с н о в а н н о м у н а О О - м о д е л и р о вании.
К 2000 году от графической разработки моделей практически отказа¬
лись и, как оказалось, зря.
С 1998 года стала набирать силу технология Rational Rose, основанная
на объектно-ориентированном подходе и на последовательно уточняю­
щихся графических моделях. Первоначально п р о м ы ш л е н н о м у использо­
ванию такого подхода мешало разнообразие похожих, но различающихся
моделей. Заслугой ф и р м ы Rational м о ж н о считать то, что она сумела объ¬
единить трех классиков объектного проектирования («three amigos» Рэмбо,
Буча и Якобсона), которые создали универсальный я з ы к О О - м о д е л и р о вания U M L — Universal Modeling Language [22].
Технология стала настолько успешной и популярной, что I B M купила
фирму Rational Software более чем за 2 млрд. долларов и включила Rational
Rose в свою линейку продуктов.
Аналогичный путь проделала технология к о м п а н и и Together Soft,
правда, значительно более скромная по своим возможностям. И х купила
Borland за 56 млн. долларов.
Что же случилось с первыми CASE-технологиями?
В 1996 году известный собиратель устаревших средств — к о м п а н и я
Sterling Software скупила почти все CASE-средства, кроме H P S ф и р м ы
S E E R Technologies. Идея бизнеса ф и р м ы Sterling Software понятна — есть
сотни к о м п а н и й , использующих CASE-средства, купленные в начале
1990-х годов. В С Ш А п р и н я т о , что ежегодное сопровождение П О стоит
до 20% его продажной ц е н ы . Таким образом, «могильщик» Sterling
Software собирал огромные деньги только на сопровождении, не ведя ни¬
каких новых разработок. Один раз о н и захотели расширить свой р ы н о к и
заказали н а м конвертор Cobol -— Coolgen (новое название, которое они
дали I E F ) . М ы - т о , конечно, все сделали как надо, н о , на н а ш взгляд, к о м ­
п а н и я допустила стратегическую ошибку: лучше было бы заказать нам

78

CASE-технологии

конвертор Coolgen - Cobol, т.к. большинство пользователей старых
средств хотят освободиться от зависимости от них.
В к о н ц е к о н ц о в , к о м п а н и я Computer Associates купила Sterling
Software, и о н и заказали нам конвертор A D W - Cobol, а потом и е щ е бо¬
лее пяти проектов п о реинжинирингу ADW-проектов в Cobol.
Параллельно с этим два конкурента — S E E R Technologies и Relativity
Technologies — заказали н а м конверторы H P S - Cobol. С их стороны был
определенный риск, что ж и з н е н н о важная для бизнеса и н ф о р м а ц и я уте­
чет через нас к конкурентам, н о м ы их, разумеется, н е подвели, и сейчас
на р ы н к е активно продаются оба варианта.
Таким образом, м ы познакомились и так или иначе п р и н я л и участие
в создании всех массовых CASE-средств. Этот опыт оказался бесценным
для н а ш и х собственных работ.

79

Курс

Технология программирования

Часть II. Технология программирования
встроенных систем реального времени
1 . Понятие в с т р о е н н о й с и с т е м ы
реального времени
Встроенная система — это программно-аппаратная система, в кото­
рой один или несколько компьютеров управляют аппаратурой в реальном
масштабе времени. Масштаб времени зависит от типа системы, но обыч¬
но это микросекунды или миллисекунды. Главная особенность встроен­
ных систем состоит в абсолютной обязательности, необходимости уло­
житься в заданный интервал — если система не уложилась, и н ф о р м а ц и я
просто безвозвратно пропадет. Типичными примерами встроенных сис¬
тем являются телефонные станции, системы вооружения, роботы, меди­
ц и н с к о е оборудование и т.д.
М н о г и е авторы относят создание встроенных систем к числу самых
трудных задач; в каком-то смысле, здесь сконцентрированы практически
все проблемы системного программирования.
Надежность. Все программы д о л ж н ы быть н а д е ж н ы м и , но во встро¬
енных системах ошибка может привести к катастрофическим последст¬
виям. Отладка П О реального времени осложняется тем, что эксперименты
трудны, дороги или вообще невозможны, например, ядерные испытания
запрещены, но ракеты с я д е р н ы м и головками производятся. Д а ж е в тех
случаях, когда отладка П О на конкретном оборудовании возможна, часто
ошибочную ситуацию трудно воспроизвести, поскольку каждый запуск
оборудования может сопровождаться р а з н ы м и в р е м е н н ы м и задержками,
а от них зависит последовательность запуска программных процессов.
П О телефонной станции может успешно работать годами, потом, при оп¬
ределенном сочетании внешних и внутренних параметров, сломаться,
а после рестарта — снова долго работать без замечаний. Ч т о б ы поймать
такую редкую ошибку, нужно проявить чудеса изобретательности.
Реактивность. П о определению, встроенная система реального вре­
мени должна всегда укладываться в некоторые временные рамки. Отсюда
вытекают требования к тщательному анализу времени протекания раз¬
личных процессов, выделению критически важных задач (здесь, к а к все¬
гда, действует правило 20-80 — 20% задач занимают 80% времени и с п о л ­
н е н и я ) , глубинной оптимизации программ.
Компактность. Оптимизировать нужно не только время и с п о л н е н и я ,
но и объем используемой памяти. Н а п р и м е р , в современных автомобилях
80

Понятие встроенной системы реального времени

карбюратором управляет м и к р о Э В М , в которой н и к а к о й в н е ш н е й п а м я ­
ти нет. Если программа и д а н н ы е превысят наличную память м и к р о Э В М
на 1 байт, то нужно будет переделывать всю систему. В обычных про¬
граммных системах скорость счета обычно «разменивают» на больший
объем памяти, здесь ж е такие п р и е м ы н е проходят.
Работа с базами данных. Н а п р и м е р , все телефонные станции одного
типа имеют одну и ту ж е программу, н о каждый экземпляр станции имеет
свой набор абонентов, количество соединительных л и н и й к другим теле¬
ф о н н ы м станциям, одним абонентам м о ж н о звонить п о межгороду, а дру­
гим — нет и т.д. Эта и н ф о р м а ц и я собирается в базе данных, часто распре¬
деленной.
Взаимодействие с человеком. Н е к о т о р ы е в с т р о е н н ы е с и с т е м ы
не имеют никаких способов взаимодействия с человеком (напри­
мер,система техобслуживания). Такие системы принято называть «глубо­
ко встроенными системами» (deeply embedded systems). Другие ж е , наобо¬
рот, иногда требуют вмешательства человека-оператора. Это е щ е более
усложняет ситуацию, поскольку для человека важно иметь удобный и н ­
терфейс и оперативное отображение текущего состояния всех техниче¬
ских элементов.
Надеюсь, даже этого короткого перечня проблем достаточно, чтобы
понять, почему в нашем коллективе разработчики систем реального вре¬
м е н и всегда пользовались наибольшим уважением.

81

Курс

Технология программирования

2. Инструментальная и целевая Э В М
Для обычных Э В М технология разработки П О в последние годы бы¬
ла более или менее стандартизирована. Такие ее элементы как алгоритми¬
ческие я з ы к и высокого уровня (АЯВУ) и компиляторы для них, тексто¬
вые и графические редакторы, р а з л и ч н ы е средства поддержки коллектив¬
ной разработки и т.п. используются повсеместно. Вряд ли кто-нибудь се­
годня решится программировать в кодах Э В М без каких-либо инструмен¬
тальных средств.
Теперь представим себе, что нам нужно запрограммировать контрол¬
лер карбюратора автомобиля, микропроцессор в мобильном телефоне или
какое-то другое специализированное устройство. Наверняка там не будет
традиционной ОС, многопользовательского режима, трансляторов и м н о ­
гого другого, к чему м ы привыкли. Более того, из-за ограничений памяти,
отсутствия обычных устройств ввода-вывода и коммерческих соображе­
н и й (разовая, не массовая разработка!) все это и невозможно реализовать.
Будем действовать следующим образом.
Всю разработку осуществляем на АЯВУ на хорошо о с н а щ е н н о й
Э В М , которую будем называть «инструментальной». Для получения кода
на нужной «целевой» Э В М создаем транслятор с нашего АЯВУ, который
работает на инструментальной Э В М , но в качестве результата выдает код
целевой ЭВМ. Такой транслятор называется «кросс-транслятором».
На самом деле это предельно упрощенная схема. Чтобы как м о ж н о
дольше оставаться на инструментальной Э В М , кроме кросс-транслятора,
нужно разработать различные и м и т а ц и о н н ы е модели, средства снятия и
сравнения трасс, средства замера временных интервалов и т.д.
Самую сложную, на моей памяти, схему отладки м ы реализовали для
военных заказчиков, которым нужно было разработать сложное П О на
Алголе 68 для управляющего вычислительного комплекса (УВК) «Сам¬
сон». В качестве инструментальной Э В М м ы использовали П Э В М .
Сначала все программы транслировались в коды П Э В М и проверя­
лись на и м и т а ц и о н н ы х моделях. Так была проверена правильность основ¬
ных алгоритмов. Естественно, м ы не могли проверить реактивность и
другие временные параметры.
Затем все программы были оттранслированы кросс-транслятором в
коды «Самсона» и были еще р а з проверены на П Э В М , но с использова¬
н и е м интерпретатора системы команд У В К «Cамсон». Так м ы получили
р а з м е р ы реальных объектных кодов, проверили правильность адресации
и смогли подсчитать время и с п о л н е н и я всех фрагментов программы,
не зависящих от внешних сигналов.
Н а к о н е ц , на стенде, в котором несколько П Э В М и один «Самсон»
были связаны в локальную сеть, м ы получили возможность запускать
82

Инструментальная и целевая ЭВМ

программы непосредственно на «Самсоне», но с п о л н ы м контролем со
стороны П Э В М (остановка по команде, по адресу чтения и т.п.) «Самсон»
в то время был всего один (это обычная ситуация, когда П О и оборудова­
н и е разрабатываются одновременно), а разработчиков — много; при этом
каждый из них мог запускать программы со своего рабочего места.
Такая «трехступенчатая» схема отладки помогла разработать чрезвы¬
ч а й н о важное П О .

83

Курс

Технология программирования

3. К о м п л е к с в ы ч и с л и т е л ь н ы х с р е д с т в
К р у п н ы е встроенные системы реального времени обычно управля­
ются не одним, а несколькими компьютерами, связанными сетью переда­
ч и данных. Если все компьютеры и их о п е р а ц и о н н ы е системы одинако­
вы, сеть называется гомогенной, в и н о м случае — гетерогенной. Управ­
лять гетерогенной сетью намного сложнее, хотя в н а ш век стандартных
протоколов связи эти трудности успешно преодолеваются. П о н я т и е
«комплекс вычислительных средств» и связанные с этим понятием проб¬
л е м ы м ы продемонстрируем на нескольких примерах.
Более 6 лет м ы разрабатывали большую междугородную телефонную
станцию. Эта А М Т С предназначалась для правительственной связи, п о э ­
тому главным требованием была надежность. И м е н н о из-за соображений
надежности для управления А М Т С был разработан довольно сложный
комплекс вычислительных средств (КВС).

PMO1 основное —
PMO1 резервное PMO30 основное
PMO30 резервное

ЦКМО

_
ПУУ1

. . .

ПУУ100

Во главе К В С стоит троированный «Самсон», его надежность во
много раз превосходит надежность любого другого элемента К В С . Имен¬
но «Самсон» принимает окончательное р е ш е н и е во всех спорных ситуа¬
циях. Через центральный канал м е ж м а ш и н н о г о обмена ( Ц К М О ) «Сам­
сон» связан с п е р и ф е р и й н ы м и управляющими устройствами (ПУУ), к о ­
торых может быть до 100 штук, и Ц К М О , и П У У дублированы. Каждая
половинка П У У связана с одним подканалом Ц К М О , но может быть п е ­
реключена и на другой подканал. Каждое П У У представляет собой
84

Комплекс вычислительных средств

небольшую Э В М , управляющую т е л е ф о н н ы м оборудованием (абонент¬
с к и м и комплектами, коммутационным полем, концентраторами и т.д.)
Две половинки ПУУ работают синхронно, выполняя одну и ту же прог­
рамму. Существует специальная схема, проверяющая совпадение резуль­
татов половинок, выдаваемых в Ц К М О . Если «Самсон» получит сигнал о
несовпадении результатов (то, в первую очередь, проверяется коррект­
ность Ц К М О ) — просто посылается контрольный запрос на соседние
ПУУ: если ответ поступит, то сбилось ПУУ, если нет, то что-то случилось
с Ц К М О . Если вышел из строя один из подканалов Ц К М О , он выводится из
конфигурации, второй подканал переводится в другой режим работы, на­
пример, каждое сообщение повторяется или кодируется специальным к о ­
дом с избыточностью, который позволяет обнаруживать и даже исправлять
ошибки передачи.
Если ж е с Ц К М О все в порядке то, прежде всего надо выяснить, ка­
кая из п о л о в и н о к П У У сломалась. «Самсон» запускает короткий диагно¬
стический тест в обеих половинках, затем выводит неисправную часть из
конфигурации и сообщает оператору о необходимости ремонта. Ввод в
конфигурацию п о л о в и н к и П У У после ремонта является весьма нетриви¬
альной задачей. Остановить работающую половинку даже на короткое
время для выравнивания данных с вводимой половинкой нельзя из-за
требований надежности и готовности А М Т С в целом. Нам удалось приду­
мать хитрый алгоритм постепенного выравнивания данных, но посколь¬
ку несколько поколений студентов заваливало экзамен на этом вопросе,
я отказался от мысли изложить содержание алгоритма в лекциях, хотя го­
тов рассказать его интересующимся в индивидуальной беседе.
А М Т С управляется операторами, с и д я щ и м и за рабочими местами
операторов ( Р М О ) , которых может быть до 30 штук. Каждое Р М О — это
две обычных персональных Э В М (основная и резервная). Н и к а к и х аппа­
ратных средств резервирования П Э В М не имела, поэтому пришлось и з о ­
бретать программную реализацию. И основная, и резервная П Э В М свя¬
зана с «Самсоном» отдельным, сравнительно медленным последователь¬
н ы м каналом. В «Самсоне» для каждого Р М О предусмотрен специальный
драйвер, который «знает», какая П Э В М в д а н н ы й момент основная, а ка­
кая — резервная. Любая и н ф о р м а ц и я для Р М О из «Самсона» посылается
в обе П Э В М , все действия оператора разбиты на короткие транзакции по
базе данных конкретного Р М О . Если основная П Э В М отказала, что вид­
но по тестам, таймерным событиям или просто визуально, оператору д о ­
статочно пересесть на резервную П Э В М . П р и этом гарантируется, что все
транзакции, завершенные на основной П Э В М , закончены и на резерв¬
ной, поэтому оператору не придется заново вводить более одной команды.
В 1996 году м ы успешно прошли государственные испытания этой
А М Т С , накопили бесценный опыт разработки и комплексной отладки
85

Курс

Технология программирования

сложных программно-аппаратных средств, отработали технологию про¬
граммирования R T S T на базе S D L , в общем, все было хорошо. М ы были
уверены в скором и успешном продолжении работ, но в этот момент госу¬
дарственное ф и н а н с и р о в а н и е окончательно прекратилось, и н а ш отдел
разработки средств телекоммуникаций остался без работы.
Поэтому к а к нельзя кстати оказалось предложение Л Н П О «Красная
Заря» переделать или написать заново программное обеспечение для уже
существующей сельской АТС «Бета». Станция была разработана в Л Н П О
«Красная Заря», сертифицирована и уже серийно выпускалась. Н о оказа­
лось, что П О , сделанное «на коленках», без всякой технологии, очень до¬
рого в сопровождении — трудно исправить ошибку, сложно добавить но¬
вую ф у н к ц и ю . В результате каждая АТС после полугода эксплуатации об­
ладала индивидуальным П О , а если после этого исправлялась какая-то
незамеченная ранее ошибка или добавлялась новая ф у н к ц и я , то приходи лось переделывать все версии П О .
В другой ситуации м ы , возможно, и отказались бы от такого предло¬
ж е н и я , но поскольку другой работы не было, делать было нечего. Только
много позже м ы поняли, как нам повезло. М ы изучили чужой опыт, позна­
комились с требованиями рынка, получили подробно изложенные алгорит­
м ы большинства протоколов, используемых на российских каналах связи.

МГО

Для начала нас познакомили с общей архитектурой АТС «Бета».
МАЛ — модуль абонентских л и н и й , к которому подключаются до
180 телефонов.
СЛ — соединительная л и н и я к другой АТС.
М Г О — модуль группового оборудования.

86

Комплекс вычислительных средств

Каждый из этих модулей управлялся контроллером i8086 и имел
небольшую оперативную память. Все модули связывались между собой
общей ш и н о й с пропускной способностью 9,6 кбит/сек.
Н а м объяснили, что общая ш и н а является самым узким местом
станции, многие протоколы н е укладываются в ограничения п о времени,
поэтому сейчас о н и думают перейти на скорость 19,2 кбит/сек.
Н а ш специалист Н . Ф . Ф о м и н ы х тут ж е подсчитал, что тогда каждый
контроллер будет тратить больше п о л о в и н ы своего времени только на об¬
работку прерываний (известно, что п р и тактовой частоте 4,67 М г ц этот
процессор имеет чуть больше 1 млн. операций в секунду).
В результате часа разговоров с разработчиками АТС м ы н а ш л и
несколько способов уменьшить нагрузку на общую шину:
1.
Д л я защиты от о ш и б о к п р и передаче по ш и н е использовался слож­
н ы й протокол, который обычно применяется п р и передаче на боль­
ш и е расстояния (сотни километров). А тут внутри одной стойки к
каждому пакету добавляется несколько байтов!
2.
Н а каждый полученный пакет каждый модуль должен был послать
двухбайтовую квитанцию, подтверждающую правильность приема.
Н о оказалось, что порядок посылки пакетов жестко определен —
всегда М Г О сначала посылает какому-то модулю запрос, затем этот
модуль должен послать ответ в М Г О , причем каждый пакет имеет
контрольную сумму своих битов. Н . Ф . Ф о м и н ы х предложил в каж¬
дом пакете иметь всего 1 бит, подтверждающий правильность пере¬
дачи предыдущего пакета.
Уже первые два предложения снизили нагрузку на ш и н у более ч е м в
2 раза. Н о м ы п о ш л и е щ е дальше. Разработчики АТС «Бета» предполага¬
ли, что МАЛ (модуль абонентских л и н и й ) будет очень простым, напри¬
мер, о н будет принимать номер вызываемого абонента по одной ц и ф р е и
пересылать ее в М Г О .
3.
М ы предложили принимать в МАЛ весь номер, а только потом сра¬
зу в одном пакете передавать его в М Г О . Чтобы понять, сколько
ц и ф р надо принять — одну (8 для входа в межгород), две (01,02,03),
три (для внутриофисных вызовов), пять (сельская связь) и т.д., в ка­
ж д ы й МАЛ пришлось поместить по небольшой таблице, настоящая
таблица маршрутизации все р а в н о осталась в М Г О . Таким образом,
нагрузка на сеть упала е щ е в 5-7 раз.
Самое забавное и поучительное событие произошло через несколь¬
ко месяцев после того к а к м ы начали разрабатывать новое П О для АТС
«Бета». Н а ш а операционная система теряла отдельные сообщения, хотя
по всем расчетам производительности процессора должно было хватать.
После долгих мучительных поисков о ш и б к и в П О Н . Ф . Ф о м и н ы х р е ш и л
проверить правильность работы аппаратуры и обнаружил ошибку в р а з 87

Курс

Технология программирования

водке платы процессора. Вместо тактовой частоты 4,67 МГц на вход clock
процессора подавалась частота 1 МГц, предназначавшаяся совсем для
других целей. Таким образом, все 30 АТС, выпущенные до нас, управля¬
лись в 5 раз более медленными Э В М , чем могли бы. Потому и все проб¬
лемы были связаны с ш и н о й , т.к. любая работа с ней связана c обработ¬
кой прерываний, где производительность процессора критична. Боюсь,
если бы разработчики АТС «Бета» обнаружили эту ошибку сами, к нам бы
вообще не обратились и тогда бы история нашего коллектива сложилась
совсем иначе.

88

Параллельные процессы

4. Параллельные процессы
Вообще-то, п р о параллельные процессы принято рассказывать в
других курсах, чаще всего в курсе «Операционные системы» [23]. Н о по¬
скольку м ы хотим изложить придуманную в нашем коллективе эффек¬
тивную организацию вычислительного процесса во встроенных системах
реального времени, нужно, чтобы читатель понимал «что почем» в мире
параллельных процессов.
М о ж н о предложить следующую иерархию разбиения сложной с и с ­
темы на взаимодействующие куски:
1.
С а м ы м простым является вызов подпрограммы (subroutine). Часто
встречающийся кусок кода оформляется к а к подпрограмма. В том
месте программы, где необходимо использовать эту подпрограмму,
ставится команда «переход с возвратом» (branch and l i n k ) , которая
запоминает адрес следующей команды в регистре, а затем передает
управление в начало подпрограммы. В к о н ц е подпрограммы ставит¬
ся команда перехода по адресу, записанному в регистре. Разумеется,
д о л ж н ы соблюдаться определенные соглашения о связях, например,
возврат из подпрограммы должен всегда осуществляться по одному
и тому ж е номеру регистра. Каждая подпрограмма должна сохранить
значение этого регистра в какой-то памяти, если внутри нее есть вы¬
зовы других подпрограмм. В любом случае, накладные расходы на
вызов подпрограммы небольшие (2-4 команды).
2.
Следующим п о сложности является вызов процедуры. К действиям
по вызову подпрограммы добавляется захват области памяти для ло¬
кальных переменных процедуры и различных рабочих данных при
входе в процедуру и освобождение памяти п р и выходе (возврате) из
процедуры. Память используется в стековом режиме — последняя за­
нятая память освобождается первой.
П р и м е р н ы й перечень действий п р и вызове процедуры:
• Захват секции памяти.
• Установка динамической цепочки (адрес начала секции памяти вы¬
зывающей процедуры).
• Сохранение регистров.
• Сохранение адреса возврата.
• Передача параметров.
• Передача управления.
П р и возврате нужно восстановить регистры, освободить память и
восстановить контекст вызывающей процедуры. Д л я Э В М без аппарат¬
н о й поддержки вызов процедуры может потребовать от 30 до 150 команд.
Когда-то м ы очень гордились, что сумели для архитектуры I B M / 3 6 0 при¬
думать реализацию вызова процедуры за 11 команд.
89

Курс

Технология программирования

Заметим, что описанная реализация вызова допускает рекурсию, к о ­
гда процедура вызывает самое себя, а основное направление оптимиза¬
ц и и вызовов — сведение вызова процедуры к вызову подпрограммы.
3.
Е щ е более сложным является вызов сопрограммы ( c o r o u t i n e ) . В д о ­
полнение к действиям «создать» и «уничтожить» сопрограмму вво­
дится оператор t r a n s f e r (p) — прервать исполнение текущей сопро¬
граммы и передать управление в сопрограмму р (точнее, возобно¬
вить ее исполнение). П р и приостановке сопрограммы ее память н е
освобождается, поэтому когда-то управление может в нее вернуться
(опять-таки оператором t r a n s fer). Такая структура управления пол¬
ностью детерминирована и очень удобна при моделировании раз¬
личных процессов. Наиболее известным я з ы к о м , использующим с о ­
программы, является Модула 2 [24]. П о времени исполнения вызов
сопрограммы мало ч е м отличается от вызова процедуры, н о по объ­
ему используемой памяти, разумеется, о н обходится дороже.
4.
С а м ы м о б щ и м , м о щ н ы м и дорогим средством организации взаимо­
действия различных фрагментов большой программы являются па¬
раллельные процессы. Процесс — это практически независимый
объект, о н имеет свой исполняемый код, свою область памяти, его
состояние определяется содержимым этой памяти и адресом и с п о л ­
няемой в д а н н ы й момент команды. Если программный код устроен
таким образом, что в него никто н е пишет, одна к о п и я кода может
разделяться многими параллельно и с п о л н я ю щ и м и с я процессами
(reenterable), н о рабочая память у каждого процесса должна быть
своя. Процессы могут исполняться параллельно, например, на раз¬
ных процессорах. Во многих операционных системах задача — это
процесс, к которому п р и п и с а н ы р а з л и ч н ы е ресурсы (максимально
доступные объемы памяти и процессорного времени, объемы д и с к о ­
вого пространства и т.д.). Если приложение состоит из нескольких
параллельных процессов, о н и д о л ж н ы иногда взаимодействовать.
Это очень непростая задача. Рассмотрим пример.
Пусть два процесса р 1 и р2 используют общую переменную S вида
s t r u c t ( i n t a , b ) , т.е. S является структурой с двумя целыми полями.
Предположим, процесс р 1 р е ш и л прочитать значение структуры S, успел
прочитать первое поле a, н о был по какой-то п р и ч и н е прерван. Процесс
р2 записал в структуру S новое значение, потом процесс р 1 был возобно¬
влен и продолжил чтение со второго поля b. В результате р 1 получит зна­
ч е н и я полей а и b из разных ф а з обработки.
Таким образом, м ы приходим к идее м о н о п о л и з а ц и и ресурсов и л и ,
другими словами, синхронизации действий параллельных процессов.
Было придумано несколько чисто программных р е ш е н и й , н о все о н и об¬
ладают одним о б щ и м недостатком — какое—то время о ж и д а ю щ и й п р о 90

Параллельные процессы

цесс «висит» на процессоре в пустом цикле, бесполезно растрачивая са­
м ы й драгоценный ресурс — время процессора.
Е щ е в к о н ц е 50-х годов ХХ века известный ученый Э. Дейкстра п р и ­
думал п р и н ц и п и а л ь н о новую конструкцию — семафор [25]. Семафор —
это структура с одним целым полем, но и м я поля неизвестно, поэтому
о б ы ч н ы м и способами н и прочитать, н и изменить это поле нельзя. Сема¬
ф о р допускает только три операции — установить значение семафора
( l e v e l ) , увеличить (up) значение на 1 и уменьшить (down) на 1. Если во
время и с п о л н е н и я операции down значение семафора стало отрицатель­
н ы м , текущий процесс приостанавливается (suspend), если при выполне­
н и и операции up значение семафора из отрицательного становится ну¬
лем, один из процессов, приостановленных из-за этого семафора, возоб¬
новляется (resume). Считается, что в операционной системе есть очередь
готовых к и с п о л н е н и ю процессов и очередь процессов, ожидающих неот¬
рицательного значения какого-то семафора, но никакого определенного
порядка и с п о л н е н и я не подразумевается. П р и н ц и п и а л ь н о новой идеей в
семафорах является их неделимость. В операции down между вычитанием
е д и н и ц ы и проверкой на неотрицательность никакое прерывание про¬
цесса невозможно. В н а ш е время любая память Э В М обеспечивает, к р о ­
ме обычных операций чтения и записи, специальную операцию «сема­
ф о р н о е чтение», в которой в одном такте выдается значение байта, а в
байт пишется 1. Нетрудно сообразить, как, используя эту операцию, кор¬
р е к т н о реализовать операции up и down.
Рассмотрим пример:
sema s = l e v e l 1;
par
begin
do НАЧАЛО1;
down s; ДЕЙСТВИЯ1; up s;
КОНЕЦ1
od ,
do НАЧАЛО2;
down s; ДЕЙСТВИЯ2; up s;
КОНЕЦ2
od
end
Здесь два параллельных процесса представлены бесконечными цик¬
лами. Каждый процесс включает в себя последовательность операторов,
ограниченную операторами down и up. Начальное значение семафора
равно 1.
Действия НАЧАЛО 1 и НАЧАЛО2 выполняются параллельно, допус¬
тим, второй процесс р а н ь ш е достигает своего оператора down s . Тогда s
получит значение 0, начнется в ы п о л н е н и е последовательности Д Е Й С Т 91

Курс

Технология программирования

ВИЯ2. Пусть теперь и первый процесс достигнет оператора down s. Так
как текущее значение s равно 0, первый процесс приостановится и будет
ждать, пока второй процесс н е выполнит оператор up s. Кстати, никто
не гарантирует, что после этого возобновится первый процесс — если вто­
рой процесс выполняется быстрее первого, то вполне возможно, что
р а н ь ш е снова сработает оператор down s второго процесса.
Я хотел показать на этом примере, что Д Е Й С Т В И Я 1 никогда н е бу¬
дут выполняться параллельно последовательности Д Е Й С Т В И Я 2 — или
Д Е Й С Т В И Я 1, или Д Е Й С Т В И Я 2 , н о н е вместе. Такие фрагменты парал­
лельных процессов называются критическими интервалами.
На практике столь простая и фундаментальная конструкция, к а к с е ­
м а ф о р , оказалась очень опасной. Два семантически связанных действия
разнесены п о тексту. Кто-то забудет открыть семафор, а кто-то — закрыть.
Позже Т. Хоар предложил более безопасную конструкцию для с и н ­
хронизации параллельных процессоров — монитор[26]. Представьте себе
дверь в комнату, в замок которой вставлен ключ. Вы открываете дверь,
вынимаете ключ, входите в комнату и закрываетесь в ней. Следующий,
кто захочет войти в комнату, н е найдет ключа и вынужден будет ждать,
пока в ы н е выйдете. В я з ы к и программирования ввели оператор s e i z e m
(схватить ресурс m). Если ресурс занят, процесс зависает прямо на этом
операторе s e i z e — никакого «парного» оператора н е надо. Вроде бы пус­
тяк, н о оказалось, что этот оператор значительно технологичнее.
Значительно позже появились почтовые я щ и к и , «рандеву» и многие
другие средства. Математически о н и все эквивалентны, т.е. выражаются
друг через друга, н о с точки зрения технологичности, выразительности,
эффективности реализации — существенно различаются.
В нашем коллективе принято пользоваться механизмом сообщений.
Параллельные процессы могут использовать операторы send m (послать
сообщение) и r e c e i v e m (получить сообщение). После оператора send
процесс ничего н е ждет, а работает дальше, сообщение «заплетается» в
очередь входных сообщений того процесса, которому о н о предназначено
(обычно адресат указывается либо отдельным параметром, либо просто
включается в сообщение).
П о оператору r e c e i v e процесс просматривает свою очередь входных
сообщений. Если она пуста, то процесс «зависает», иначе берется очеред­
ное сообщение и обрабатывается.
Нам нравится, что сообщения н е только играют роль синхрониза¬
ц и и , н о и несут семантическую нагрузку — обмен д а н н ы м и .
Иногда требуется более жесткая схема синхронизации, тогда вместо
send используется оператор ask m, после которого процесс приостанав­
ливается и ждет ответа.

92

Работа с временными интервалами

5. Работа с в р е м е н н ы м и и н т е р в а л а м и
В системах реального времени часто возникает ситуация, когда теку¬
щ и й процесс должен быть задержан на определенный период времени.
Ч а щ е всего такая ситуация возникает, когда процесс должен дождаться
о к о н ч а н и я работы какого-то внешнего устройства. Задержку на опреде­
ленное время осуществляет оператор d e l a y m, где m — количество какихто единиц времени, например, миллисекунд.
М ы уже много лет п р и м е н я е м следующую реализацию оператора
delay. Процесс, в котором исполнялся этот оператор, приостанавливает­
ся и ставится в очередь задержанных процессов. Эта очередь упорядочена
по времени ожидания. Н а п р и м е р , пусть p1 и p2 ждут 10 мсек, p3, p4, p5 —
30 мсек, p6, p7 — 100 мсек. Тогда в очереди задержанных процессов п е р ­
вым узлом будет узел с временем ожидания 10, к которому «заплетены» p1
и p2, за н и м следует узел с ожиданием 30, к которому «заплетены p3, p4 и
p5 , а последним узлом в очереди задержанных процессов будет узел с вре¬
менем ожидания 100 с «заплетенными» к нему p6 и p7.
В операционной системе есть системный таймер, который «тикает»,
например, через каждую миллисекунду, т.е. каждую миллисекунду возни¬
кает прерывание, обработчик которого пробегает по очереди задержан¬
ных процессов и вычитает единицу и з времени ожидания каждого узла.
Если время ожидания узла превращается в ноль, «заплетенные» к нему
процессы переводятся в очередь готовых к и с п о л н е н и ю процессов.
Очевидной оптимизацией является хранение в узлах н е абсолютных
значений времени ожидания, а нарастающих итогов, например, в н а ш е м
примере, н е 10, 30, 100, а 10, 20, 70. Тогда каждую миллисекунду надо в ы ­
читать 1 только из первого узла. В У В К «Самсон» м ы ввели так называе­
мое «мягкое» прерывание: каждую миллисекунду м ы вычитали 1 и з вер¬
хушки списка задержанных процессов на микропрограммном уровне и
только п р и обращении верхушки в 0 реально вызывалась ф у н к ц и я О С .
Все это кажется вполне очевидным, и я н е стал бы включать описа¬
н и е этой реализации в курс л е к ц и й , если бы н е две забавные истории.
В начале восьмидесятых годов ХХ-го века м ы неожиданно обрели
конкурента в лице одного пензенского завода. И х бывший директор стал
большим начальником в области правительственной связи и, к а к это
принято в н а ш е й стране, стал «сливать» и м все заказы с большими день­
гами, хотя р а н ь ш е о н и никогда телефонных станций н е делали. И м за ма¬
л ы е АТС давали большие деньги, чем н а м за большие АТС, и м разрешали
использовать и м п о р т н ы е микросхемы, нам — нет и т.д. Так вот, о н и даже
с лучшими американскими микропроцессорами того времени хрониче¬
ски н е укладывались во временные ограничения. Разобраться, в чем дело,
причем втайне от большого начальника, поручили нам. Среди многих
93

Курс

Технология программирования

неграмотных р е ш е н и й с а м ы м несуразным оказалась р е а л и з а ц и я опера­
тора delay. Каждую миллисекунду о н и приостанавливали текущий п р о ­
цесс, заходили во все процессы (т.е. возобновляли их), проверяли, нет л и
там оператора d e l a y , если есть — вычитали 1 и снова сворачивали про¬
цесс. Процессов было больше 1000, свертка-развертка у н и х занимала
500-600 команд — п о н я т н о , куда уходило время. В результате «разбора по¬
летов» четырех ведущих разработчиков из П е н з ы прислали к нам на ста¬
жировку на месяц, н о мат-мех за месяц н е закончишь. Хотя свою АТС о н и
все-таки сдали — с пятилетним опозданием.
Другой пример связан с французской АТС М Т / 2 0 . В 1979 году С С С Р
о ф и ц и а л ь н о купил л и ц е н з и ю на право производства этой АТС (что было
редкостью в то время). В Уфе построили большой завод, и после многих
трудностей, связанных, в основном, с попытками «улучшить» и «совети¬
зировать» готовую АТС, наладили массовое производство. Д а ж е к началу
X X I века это была самая массовая цифровая АТС в нашей стране (более
3 млн. абонентов). М Т / 2 0 проживет е щ е 15-20 лет, однако ее центральная
Э В М 3202 (два больших шкафа) первой н е выдержала испытания време­
нем. Уже н е выпускаются микросхемы, используемые в этой Э В М , давно
забыты технологические средства, применявшиеся при ее разработке, н а ­
к о н е ц , н е осталось и инженеров, умеющих ее налаживать. П о н я т н о , что
основной ценностью М Т / 2 0 является ее программное обеспечение. Заводчане п о с т е п е н н о м о д е р н и з и р о в а л и о с н о в н ы е а п п а р а т н ы е б л о к и
М Т / 2 0 , прежде всего, блоки памяти, вызывавшие много нареканий,
уменьшили массогабариты и энергопотребление, н о н е смогли сущест¬
венно модернизировать П О .
П о заказу завода м ы разработали новую Э В М , идентичную по архи¬
тектуре и системе команд старой 3202. Главной задачей было обеспечение
работы оригинального П О . Это было непросто, точных о п и с а н и й Э В М
не сохранилось, многие детали, особенно на стыках с телефонной аппа¬
ратурой, п р и ш л о с ь восстанавливать экспериментально. Когда новая
Э В М , наконец, заработала на французских тестах, причем в 10 р а з быст¬
рее старой, оригинальное П О н е заработало.
Оказалось, что в оригинальном П О оператор d e l a y был реализован
«жужжанием», т.е. задержка на 10 мсек реализовывалась повторением 100 раз
команды со временем исполнения 100 микросекунд. А у нас эта ж е к о ­
манда исполнялась всего 10 микросекунд! П р и ш л о с ь выискивать все та¬
кие места и увеличивать число повторений в 10 раз.
Это к вопросу о том, почему я так не люблю дилетантов и троечников.

94

Организация вычислительного процесса

6. О р г а н и з а ц и я в ы ч и с л и т е л ь н о г о п р о ц е с с а
Обычно считается, что используемая технология программирования
должна обеспечить реализацию любой структуры, выдуманной проекти¬
р о в щ и к о м . Однако все известные н а м п о п ы т к и п р и м е н е н и я общих под¬
ходов к такой сложной задаче как П О встроенных систем реального вре¬
м е н и , приводили к н е э ф ф е к т и в н ы м р е ш е н и я м . П о нашему м н е н и ю , тех­
нология программирования должна отвечать не только на т р а д и ц и о н н ы й
вопрос «как построить, добиться, оценить», но и «что м ы хотим постро­
ить». М ы к этому выводу п р и ш л и постепенно, по мере накопления о п ы ­
та в ы п о л н е н и я п р о м ы ш л е н н ы х заказов. Ч т о б ы обеспечить высокое каче¬
ство, м ы разработали технологию, первоначально полностью ориентиро¬
ванную только на программное обеспечение телефонных станций, кото¬
рая получила название R T S T — Real-Time Software Technology [28].
П р и разработке R T S T м ы заранее зафиксировали определенные
структурные р е ш е н и я и тем самым ограничили разнообразие вариантов
организации вычислительного процесса.

Процессы
Параллельные процессы — классический способ описания поведе­
н и я сложных систем: независимое управление в каждой подсистеме, л о ­
кализация данных, развитые средства взаимодействия позволяют о п и с ы ­
вать системы наиболее п о н я т н ы м для разработчиков способом. Тем не
менее, в реальных системах этот способ используется редко из-за н и з к о й
эффективности реализации. Дело в том, что в них параллельно существу¬
ют тысячи процессов, абсолютное большинство которых находится в
неактивном («подвешенном») состоянии, ожидая каких-либо событий.
Традиционным механизмом реализации параллелизма такого типа я в л я ­
ется диспетчеризация через короткие промежутки времени по сигналам
от таймера (системы разделения времени), однако при этом самой частой
операцией становится свертка/развертка процессов, сильно увеличиваю­
щая накладные расходы системы [27].
Чтобы сделать параллельные процессы э ф ф е к т и в н ы м и , м ы восполь¬
зовались особенностью встроенных систем, состоящей в том, что обычно
их процессы имеют очень короткие действия — переходы в терминах рас­
ш и р е н н о й конечно-автоматной модели рекомендаций Z.100 М К К Т Т [29].
М ы считаем, что если процесс получил управление по какому-то входно¬
му сигналу, то он должен довести переход до к о н ц а (до следующего состо¬
я н и я ) и только затем передать управление диспетчеру, который опреде­
лит, какой из процессов, готовых к и с п о л н е н и ю (т.е. получивших сообще­
н и я ) , будет работать следующим. Синхронная организация параллелизма
95

Курс

Технология программирования

делает возможной простую процедурную реализацию, в отличие от традици¬
онного асинхронного подхода, при реализации которого необходимы про¬
цессы. Против синхронной реализации обычно выдвигают два аргумента.
Во-первых, часть сообщений приходит по сети от других Э В М или
оборудования в непредсказуемое время. Для решения этой проблемы со¬
берем все ф у н к ц и о н а л ь н ы е процессы в один большой процесс О С , внут¬
р и которого будем использовать синхронную организацию взаимодейст¬
вия функциональных процессов, а драйверы сети, которые осуществляют
буферизацию сообщений (никакой обработки!), будем реализовывать
простыми обработчиками прерываний на стеке текущего процесса. Инте¬
ресно, что на одно внешнее событие обычно приходится 5-10 внутренних
переключений функциональных процессов.
Во-вторых, что будет, если один из процессов все-таки имеет слиш¬
ком д л и н н ы й переход? Тогда м о ж н о вставить несколько промежуточных
ф и к т и в н ы х состояний (на практике это встречается крайне редко).
Такая последовательная и непрерываемая организация переходов
позволяет процессам пользоваться глобальными д а н н ы м и (кроме спи¬
сков входных сообщений, к которым имеют доступ параллельно работа¬
ю щ и е драйверы сети) без семафоров, критических интервалов и других
дорогостоящих средств м о н о п о л и з а ц и и ресурсов.

Данные
Традиционный подход к разработке П О встроенных систем подразу¬
мевает создание единой базы данных (централизованной или распреде¬
л е н н о й ) , к которой все процессы обращаются через специальные прими¬
т и в ы доступа. В общем случае обращение к некоторой структуре требует
ее монополизации на момент обращения, что и н е э ф ф е к т и в н о (несколь­
ко обращений к ф у н к ц и я м ОС), и ненадежно (одна из самых частых и
трудно обнаруживаемых о ш и б о к возникает, когда программист забывает
захватить ресурс или, что еще хуже, захватывает, но забывает освободить
после использования). Проектирование единой базы данных обычно ве­
дется только в интересах П О без учета соответствия данных элементам ре­
ального оборудования. Это приводит к необходимости довольно сложной
генерации данных П О на основе исходной с п е ц и ф и к а ц и и оборудования
и сильно затрудняет задачу м о д и ф и к а ц и и данных в процессе ф у н к ц и о н и ­
рования системы («на ходу»).
Такие особенности встроенных систем, как структурное подобие
большей части данных управляемому оборудованию и определенная л о ­
кализация действий вокруг каждого устройства, прямо подталкивают к
использованию объектно-ориентированной парадигмы, однако ее эффе¬
ктивность не очевидна.
96

Организация вычислительного процесса

Во-первых, не вызовет ли разбиение данных на сравнительно мел­
к и е объекты (с точностью до прибора) значительного расходования памя¬
ти? Действительно, заголовки процессов в большинстве О С достигают
100-200 байтов, поэтому представление объектов в виде полноправных
процессов О С действительно очень накладно. Н о , как м ы уже видели,
возможны у п р о щ е н н ы е синхронные варианты реализации объектов —
при этом длина заголовка уменьшается на порядок.
Во-вторых, не подменяем ли м ы сложные операции доступа к БД
не менее дорогостоящими операциями обмена сообщениями? Другими
словами, хорошо, если 90% запросов осуществляется к локальным д а н ­
н ы м объекта и только ради 10% приходится посылать сообщения, а если
наоборот? Разумеется, на этот вопрос нет однозначного ответа, но прак­
тический опыт показывает, что обычно удается распределить д а н н ы е по
объектам достаточно удачно, т.е. организовать своеобразный конвейер.
Сначала управление получает один объект, который, пользуясь своими
локальными д а н н ы м и , выполняет определенные действия и посылает со¬
о б щ е н и е следующему объекту с результатами своей р а б о т ы в качестве па¬
раметра сообщения, т.е. сообщения играют не только и н ф о р м а ц и о н н у ю ,
но и управляющую роль.
Случаи, когда сообщение посылается только с целью получения д а н ­
ных, локализованных в другом объекте, нужно сводить к минимуму. Здесь
также м о ж н о воспользоваться особенностями встроенных систем, в кото¬
р ы х процессы чаще всего далеко не р а в н о п р а в н ы по приоритетам. На¬
пример, в телефонных станциях процессы установления/освобождения
соединения критичны по времени, а процессы техобслуживания, кото¬
р ы е по объему во много раз больше, — нет. Соответственно, при разбие¬
н и и системы на объекты нужно учитывать только локализацию данных,
необходимых для установления и разъединения соединений, а д а н н ы е ,
которые требуются для техобслуживания, распределять, э к о н о м я только
собственные силы.
В качестве примера рассмотрим упрощенную телефонную станцию.

Рис. 1. Упрощенная телефонная станция
97

Курс

Технология программирования

АЛ — Абонентская Л и н и я ;
СЛ — Соединительная Л и н и я ;
Т К — Телефонная Книга;
К П — Коммутационное Поле.
Здесь каждому абоненту соответствует объект типа АЛ, каждой ли¬
н и и , соединяющей данную станцию с другой, — объект типа СЛ. Объект
типа Т К является справочником номеров абонентов данной телефонной
станции и хранит д а н н ы е , необходимые для маршрутизации. Объект ти¬
па К П соответствует реальному коммутационному полю. Драйверы игра¬
ют связующую роль с в н е ш н и м миром и обычно реализуются в виде ас­
семблерных программ, вызываемых по прерываниям.
Когда абонент поднимает трубку, соответствующий объект АЛ полу¬
чает сообщение, принимает все ц и ф р ы номера и посылает сообщение
объекту Т К с п р и н я т ы м номером в качестве параметра. Заметим, что все
это время АЛ работает только со своими локальными д а н н ы м и . Т К осу­
ществляет п о и с к вызываемого абонента также только по своим локаль¬
н ы м д а н н ы м и посылает сообщение найденному объекту типа АЛ или СЛ.
Вызываемый абонент или соединительная л и н и я по своим локальным
д а н н ы м определяет, занят он или свободен, и если свободен, то посылает
сообщение К П на подключение. К П по своим локальным д а н н ы м нахо¬
дит свободную п р о м л и н и ю и т.д.

98

Технология RTST

7. Технология RTST
Итак, создаваемую систему удалось разбить на объекты и зафикси¬
ровать организацию вычислительного процесса. Н а самом деле, удачное
р а з б и е н и е — весьма нетривиальный творческий процесс, и это заставило
нас уже после нескольких выполненных проектов приступить к развитию
технологии «вверх», с упором на начальные этапы разработки.
Уже с середины 1980-х годов нам было я с н о , что разработка системы
должна начинаться с описания на специальном я з ы к е схемы объектов
(в языках программирования п р и н я т о говорить «тип», а в базах данных —
«схема»). Сначала объект описывается как ч е р н ы й я щ и к (точки его под­
ключения к другим объектам, перечни входящих и исходящих сообщений
и их параметры). Затем описываются внутренние атрибуты объекта. О н и
могут быть двух видов — те, которые не могут быть и з м е н е н ы самим объ¬
ектом (статические), и обычные рабочие переменные (динамические).
В нашем коллективе удобный для разработчиков я з ы к описания схем
объектов предложил В.В. П а р ф е н о в [30], п р и м е р н о через 5 лет Object
Management Group предложила для этих ж е целей свой я з ы к I D L [31], на
удивление похожий на наш.
Задать поведение объекта значительно сложнее, причем трудности
носят скорее «человеческий», нежели технический характер, то есть про¬
блемы возникают не из-за недостаточной к в а л и ф и к а ц и и кого-либо из
участников разработки, а из-за взаимного недопонимания. С л и ш к о м
много людей вовлечено в р е ш е н и е этой задачи — алгоритмисты, специа¬
листы по протоколам, программисты, и н ж е н е р ы - э л е к т р о н щ и к и и т.д.
Для преодоления этих трудностей Международный Консультацион­
н ы й Комитет по Телеграфии и Телефонии (ныне I T U - T ) разработал се­
р и ю графических способов описания, в частности, я з ы к и S D L ( с п е ц и ф и ­
кация Z.100) и M S C ( с п е ц и ф и к а ц и я Z.120) [32].
SDL-диаграмма (Specification and Description Language) очень похо­
жа на традиционные блок-схемы, но с несколькими важными отличиями:
символ состояния, в котором процесс не занимает процессор, ожидая
приема одного или нескольких сигналов; символ приема сигнала и сим¬
вол посылки сигнала.
В примере, изображенном на рис. 2, объект в состоянии S0 ожидает
сообщения x или у. Получив сообщение у, он совершает переход: выпол­
няет проверку некоторого условия C и, в зависимости от результата, в ы ­
полняет определенное действие (Оператор Var:=0) или посылает сообще­
н и е z. После этого объект переходит в состояние S1. В R T S T существует
графический редактор для с п е ц и ф и к а ц и и поведения объекта в таком в и ­
де, который, кроме того, осуществляет проверку синтаксической кор¬
ректности с п е ц и ф и к а ц и и и формирует ее внутреннее представление.
99

Курс

Технология программирования

Рис. 2. П р и м е р SDL-диаграммы
В дальнейшем конечно-автоматные диаграммы S D L м ы будем называть
просто SDL-диаграммами.
SDL-диаграммы очень удобны для наглядного описания параллель­
ных процессов. Н а практике не принято графически детализировать п р о ­
цесс до отдельных мелких операторов, например:

И даже
100

Технология RTST

заменяется на один оператор с коротким условным оператором внутри.
Графическая детализация нужна до такой степени, чтобы была вид¬
на логика обмена сигналами, например,

не стоит сводить к одному оператору, так как при одном значении усло¬
вия будет посылка сигнала, а при другом — нет.
П р и разработке нашего программного средства м ы р е ш и л и не изо¬
бретать велосипед и воспользоваться рекомендациями МКТТ. Первый
редактор SDL-диаграмм был реализован на Е С Э В М в 1984 году (тогда
еще без всякой ориентации на объектно-ориентированное программиро­
вание). К о н е ч н о , графическим его м о ж н о было назвать л и ш ь с некоторой
натяжкой, поскольку и э к р а н ы , и устройства печати были только тексто­
выми. Однако если забыть про некоторую громоздкость SDL-диаграмм,
о н и выглядели как настоящие.
Первые опыты по п р и м е н е н и ю SDL-редактора на реальных теле­
ф о н н ы х станциях оказались неудачными — представьте себе две-три сот­
н и больших печатных листов диаграмм, набранных с п о м о щ ь ю S D L - р е 101

Курс

Технология программирования

дактора и напечатанных на А Ц П У (алфавитно-цифровое печатающее
устройство), которые м о ж н о только читать и водить пальцем по связям.
Поэтому м ы разработали конвертор из SDL-диаграмм в код высоко­
го уровня, систему имитационного моделирования, различные отладчи­
ки, средства для снятия и анализа трасс, другие инструменты, которые
обеспечили первые возможности практического п р и м е н е н и я SDL-диаграмм.
В начале 90-х годов м ы перевели все технологические средства на
П Э В М , а заодно начали использовать объектно-ориентированный под¬
ход к проектированию П О . Нам удалось найти эффективную реализацию
вычислительного процесса для систем реального времени; усилить раз­
л и ч н ы е статические проверки, например, если сигнал не упомянут в о п и ­
сании объекта, то его невозможно использовать в SDL-диаграммах; раз¬
работать средства автоматической генерации данных и так далее.
Под именем R T S T (Real Time Software Technology) [33] эта техноло­
гия просуществовала около 10 лет, с ее п о м о щ ь ю было разработано более
10 типов различных телефонных станций и несколько других программ¬
но-аппаратных средств, причем 70-80% SDL-диаграмм легко переноси¬
лись с одной п л а т ф о р м ы на другую. Существенно было облегчено сопро¬
вождение П О , введение в коллектив новых специалистов, переиспользо¬
вание фрагментов, так что в настоящее время м ы являемся убежденными
сторонниками графических средств проектирования.
MSC-диаграммы (Message Sequence Chart) позволяют описывать
сценарии поведения системы во времени. Время течет сверху вниз, верти­
кальные л и н и и представляют объекты системы, а между н и м и рисуются
стрелки, обозначающие сигналы.

Об1

Об2

102

Об3

Технология RTST

Если объект Об2, получив сигнал x, может не отправлять объекту Об3
сигнал у, а вместо него отправить объекту Об1 другой сигнал, например,
свидетельствующий об ошибке, нужно нарисовать еще одну M S C - д и а грамму для другого сценария.
MSC-диаграммы ш и р о к о применяются различными международ­
н ы м и организациями для описания протоколов, в том числе стандартов,
разработанных организацией ITU-T, однако редко когда приводятся и с ­
ч е р п ы в а ю щ и е описания поведения системы, включая обработку аварий­
ных ситуаций, техобслуживания, т а р и ф и к а ц и и и так далее.
На наш взгляд, это связано с недостаточностью выразительных воз­
можностей стандарта M S C , в связи с чем получающиеся диаграммы
с л и ш к о м громоздки. Может быть, поэтому MSC-диаграммы р а н ь ш е ред­
ко использовались для реального проектирования. В R T S T M S C диаграм­
м ы практически не применялись.
С п о м о щ ь ю т р а н с л я т о р а схем с п е ц и ф и к а ц и и о б ъ е к т о в п р е о б р а ­
з у ю т с я во в н у т р е н н ю ю схему д а н н ы х , к о т о р а я я в л я е т с я «сердцем» с и с ­
темы.
С п о м о щ ь ю конвертора SDL-диаграммы превращаются в текст на
алгоритмическом я з ы к е (ранее Алгол 68, теперь С или Java), при этом в ы ­
полняются дополнительные проверки на соответствие схеме объектов, по
ней ж е происходит генерация служебных процедур (отправка сообщения,
генерация экземпляра объекта в оперативной памяти и т.д.).
Тексты, полученные в результате конвертации, транслируются в к о ­
д ы целевой управляющей Э В М (или, в целях отладки, в коды инструмен­
тальной Э В М ) и собираются вместе со средствами динамической под¬
держки в загрузочный модуль.
Настройка типовой программы на конкретное приложение осущест¬
вляется посредством ф о р м и р о в а н и я статической базы данных, содержа¬
щей описание конфигурации аппаратных средств встроенной системы
и ее внешней среды.
Управление объектно-ориентированной базой данных осуществляется
системой управления базой данных (СУБД). В ведении СУБД находятся
задачи создания, уничтожения, соединения и разъединения объектов,
коррекции статических параметров объектов. Для повышения реактивности
системы в случае рестартов СУБД реализована по методу «тщательного
замещения», когда внутри транзакции н и один блок не пишется на старое
место, поэтому после рестарта система мгновенно откатывается на начало
транзакции.
Поддержка ф у н к ц и о н и р о в а н и я объектов осуществляется диспетче­
р о м , который производит последовательный запуск программ поведения
готовых к и с п о л н е н и ю объектов и управляет обменом с о о б щ е н и я м и ме­
жду связанными объектами. П о запросам от СУБД диспетчер осуществ103

Курс

Технология программированияя

Спецификация
структуры данных

Спецификация
поведения

(

( Таблицы схем ^
данных

SDLдиаграммы

(_
Г

1

Конвертор
Объектноориентированный
редактор

(

)

1

Программа (
на АЯВУ I
1

Данные
конкретной АТС

Транслятор
с АЯВУ

(
Стабильный
образ системы
(БД)

Диспетчер
объектов

Управляющая
программа
/

Оперативный
образ системы

104

1

Типовая уп- /"
равляющая I
программа

\

1

Отладчик

Групповая разработка, управление версиями

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

105

Курс

Технология программированияя

8. Технология REAL
Многолетний опыт использования технологии RTST убедил нас в дос­
тоинствах графического проектирования П О и сквозного контроля. Очень
многие ошибки исчезли — например, нельзя послать сообщение объекту,
если он этого сообщения не ожидает, в S D L - диаграммах нельзя использо­
вать атрибут, если он не определен в описании схем объектов и т.д.
Однако постепенно п р и ш л о п о н и м а н и е и недостатков RTST. Преж¬
де всего, оказалось, что трудно сразу создать описание классов, да еще
в текстовом виде. М ы уже начали продумывать графические ф о р м ы для
описания проектируемой системы на этапах раннего моделирования, но
тут появился U M L . М ы были знакомы с подходами, которые до этого
предлагали Буч, Рэмбо и Я к о б с о н по отдельности, но каждый из них ох­
ватывал только отдельные фазы жизненного цикла проектирования П О .
Интеграция этих подходов в едином графическом я з ы к е U M L к о р е н н ы м
образом изменила ситуацию, особенно на начальных этапах проектиро¬
вания. С другой стороны, в 1990-х годах U M L не имел практически н и к а ­
ких средств для определения детальных алгоритмов. М ы решили исполь¬
зовать н а ш опыт и объединить подходы U M L и S D L в одной техноло¬
гии [34]. Новая технология получила название R E A L — с одной стороны,
хотелось подчеркнуть преемственность с R T S T и системами реального
времени, с другой стороны, м ы надеялись, что новая технология окажет
реальную п о м о щ ь создателям П О .
К а к и прежде, м ы приложили много усилий, чтобы обеспечить пол¬
ноту и сквозной характер технологии. Если технология поддерживает все
фазы жизненного цикла программирования, кроме какой-то одной (осо¬
бенно где-то в середине жизненного цикла), то м о ж н о быть уверенным,
что большинство о ш и б о к будет и м е н н о там. Если разработчик изменил
что-то на ранних фазах проектирования, а технология не отметила каким то образом все места в более поздних фазах, затронутые этим изменением,
развитие
и
сопровождение
системы
становится
практически
невозможным. Было очень непросто подобрать английский эквивалент
понятию «сквозной характер технологии» при объяснении основных идей
R E A L иностранным заказчикам. В к о н ц е концов, один американец пред¬
ложил перевод «drill down — просверленный». Кажется, это подходит.
Теперь приступим к изложению основных идей R E A L , точнее, я п о ­
я с н ю , к а к м ы понимаем способы проектирования сложного П О и то, как
R E A L поддерживает этапы проектирования. На наш взгляд, проектируе­
мая система должна быть аккуратно описана с трех точек зрения.
Пользовательский
уровень (иногда говорят «уровень требований»).
Система описывается как «черный я щ и к » , задаются все интерфейсы
с в н е ш н и м окружением, для каждого интерфейса дается его вербальное
106

Технология REAL

описание, т.е. описание на русском, английском или каком-то другом
языке (человеческом, а не формальном). Интерфейсы задаются с помощью
диаграмм случаев использования, для каждого случая использования
строится диаграмма ф у н к ц и й , которые система должна уметь исполнять.
Структурный уровень. Для каждой функции рисуется диаграмма объе­
ктов, которые вместе могли бы реализовать эту функцию. Часто для разных
функций удается использовать объекты одного и того же типа или находят­
ся объекты, которые лишь слегка отличаются друг от друга. Тогда приступа­
ют к созданию диаграммы классов. Класс — это тип (или схема в терминах
баз данных), а объекты — это экземпляры значений какого-то типа (т.е. ка­
кого-то класса). Если два объекта Об1 и Об2 являются экземплярами похо­
жих классов, то в диаграмме классов удобно использовать наследование:

Здесь класс Кл содержит атрибуты и методы, о б щ и е для двух классов,
а классы Кл1 и Кл2 содержат о п и с а н и я , специфические для каждого клас­
са. Объект Об1 содержит все атрибуты и методы, о п и с а н н ы е в классах Кл1
и Кл, объект Об2 — все атрибуты и методы из Кл2 и Кл.
Если классы Кл1 и Кл2 не могут существовать без класса Кл, исполь¬
зуется агрегирование:

Объекты агрегированных классов нельзя уничтожать по отдельности —
только все вместе.
Поведенческий уровень. Здесь описывается динамическое поведение
системы. Р а н н и е версии U M L слабо поддерживали этот уровень, поэтому
107

Курс

Технология программированияя

м ы решили использовать стандарты I T U - T (международного союза по те­
л е к о м м у н и к а ц и я м ) . В 2004 году появились предварительные версии
U M L 2.0, которые перекрывают возможности S D L , и м ы уже приступили
к их изучению и реализации.
Первым типом диаграмм на поведенческом уровне являются M S C диаграммы (Message Sequence Chart — диаграмма последовательности с о ­
о б щ е н и й ) , рекомендация I T U - T Z.120.
Исчерпывающее описание поведения системы на M S C , включаю­
щее в себя так называемые «обратные ветки» (обработка аварийных ситу­
аций и т.п.), оказалось с л и ш к о м громоздким, поэтому м ы р а с ш и р и л и
я з ы к M S C , включив туда текстовые ф о р м ы для ветвлений, процедурыф у н к ц и и , возвращающие результат обработки, и некоторые другие воз¬
можности. Впрочем, при желании можно автоматически сгенерировать по
расширенному M S C куда более громоздкий, зато стандартный вариант.
Если проектировщик не поленился и представил в MSC-диаграммах
действительно полное описание поведения системы, появляется возмож¬
ность впервые определить поведение каждого объекта по отдельности (до
сих пор м ы говорили о системе в целом). Перебираются все вертикальные
л и н и и (объекты) на MSC-диаграмме, каждая л и н и я рассматривается во
всех сценариях поведения. Работа объекта представляется в виде последо­
вательных устойчивых состояний, в каждом состоянии объект ждет опре¬
деленных сигналов. Получив один из возможных сигналов (сообщение),
объект переходит в следующее состояние. Таким образом, получается к о ­
нечно-автоматная модель объекта (STD — State Transition Diagram), кото­
рую м о ж н о рассматривать как скелет, основную схему поведения объек¬
та. Здесь еще нет ветвлений, присваиваний, вызовов ф у н к ц и й и т.п., но
основные контуры поведения объекта уже есть. Ранее этот переход от
M S C к S T D рассматривался как самый трудный момент проектирования
сложных систем. В 2004 году аспирант нашей кафедры системного про¬
граммирования Владимир Соколов придумал и реализовал систему автома­
тической генерации S T D по M S C . В отличие от других известных н а м ме­
тодов (собственно, более-менее существенный результат м ы знаем только
один [35]), В. Соколов предоставил проектировщику возможность влиять
на структуру генерируемого автомата, что существенно повысило удобст¬
во работы и качество получаемого результата [36].
И м е я качественную STD-модель, уже нетрудно преобразовывать ее
в STL-диаграмму (Specification and Description Language, рекомендация
I T U - T Z.100). Прежде всего, определяется, когда и при каких условиях
этим объектом посылаются сообщения, затем добавляется работа с база­
ми данных, какие-то вычисления и т. д.
SDL-диаграмма является к о н е ч н ы м продуктом проектирования,
конвертация в выбранный промежуточный алгоритмический я з ы к высо108

Технология REAL

кого уровня (АЯВУ) и трансляция в объектные коды происходят автома­
тически. Технология R E A L предусматривает определенные правила рабо­
ты проектировщиков П О , например, нельзя вносить правки непосредст­
венно в тексте на АЯВУ, все исправления нужно вносить только в S D L диаграммы, контроль версий следует вести в терминах объектов, а не ка¬
ких-то промежуточных файлов и т.д. Все попытки горе-проектировщиков
«для скорости» нарушить правила и влезть куда-то «грязными руками»
приводят к огромным трудностям в дальнейшем развитии системы и со¬
провождении, поэтому все развитие технологии R E A L направлено на
ужесточение контроля — делается все, чтобы корректные действия поль­
зователя были легкими и удобными, а попытки совершить некорректные
действия блокировались.
Постепенно общее развитие технологии R E A L разделилось на два
направления. Первое связано с традиционной областью п р и м е н е н и я —
системы реального времени. Здесь главной является SDL-диаграмма,
в технологию добавляются различные средства снятия и анализа трасс
сигналов, имитаторы нагрузки, э ф ф е к т и в н ы е способы организации вы¬
числительного процесса.
Второе направление связано с проектированием и н ф о р м а ц и о н н ы х
систем. Лидером этого направления стал Александр И в а н о в , который
придумал и реализовал средства автоматической генерации различных
ф о р м ввода и вывода и н ф о р м а ц и и , средства разграничения прав доступа,
учета связей между различными атрибутами и т.д. [37]
В этом варианте технологии главной является диаграмма классов.
П о ней автоматически строится описание базы данных на я з ы к е D D L
(data definition language), программы C R U D (Create, Read, Update, Delete,
т.е. создать, прочитать, исправить, удалить), A P I (Aplication Program
Interface — интерфейс программных приложений) для работы с р е л я ц и о н ­
н о й базой данных как с объектно-ориентированной. П о этой ж е диаграм­
ме генерируются программы работы с визуальными ф о р м а м и , а с п о м о ­
щ ь ю диаграммы объектов задаются связи между атрибутами и ограниче­
н и я прав доступа.
Программа «Студент» [38], автоматизирующая деятельность декана¬
тов и ректората нашего университета (а также многих других университе¬
тов) практически полностью автоматически сгенерирована, и л и ш ь очень
малый процент подпрограмм был написан вручную на Visual Basic.

109

Литература
1.
2.
3.

4.
5.
6.
7.

8.

9.
10.

11.
12.

13.
14.
15.

16.

Дж. Фокс. Программное обеспечение и его разработка.
М.: «Мир», 1982
Алгол 68. Методы реализации. П о д ред. Г.С. Цейтина. — Л.: Изд.
ЛГУ, 1976, 224 с.
И.В. Вельбицкий, В.Н. Ходаковский, Л . И . Ш о л м о в .
Технологический комплекс производства программ на м а ш и н а х Е С
Э В М и Б Э С М - 6 . — М.: «Статистика», 1980, 263 с.
И. Соммервиль. И н ж е н е р и я программного обеспечения. — М.: Изд.
«Вильямс», 2002.
Ф. Брукс. М и ф и ч е с к и й человеко-месяц или К а к создаются
программные системы. — СПб.: Изд. «Символ-плюс», 2000.
Э. Дейкстра. Д и с ц и п л и н а программирования. — М.: 1982.
Обратный метод установления выводимости н е п р е ф и к с н ы х формул
в исчислениях предикатов. Докл. Акад. Наук С С С Р 172, 1967,
с. 22-25.
М. Кантор. Управление программными проектами. Практическое
руководство п о разработке успешного программного обеспечения —
М.: «Вильямс», 2002.
В.В. Липаев. Тестирование программ. — М.: «Радио и связь»,
1986, 296 с.
«Инструкции к программе DICO» , С.Н. Баранов, А . Н . Терехов,
Г. С. Ц е й т и н (Методические материалы по программному
обеспечению Э В М . Серия 4. Выпуск 5. Изд. ЛГУ, 1974).
Maslow A . A . Motivation and Personality. — N e w York: Harper and Row,
1954.
Сайт «Microsoft Solutions Framework. Методология создания
программных р е ш е н и й » ,
http://www.microsoft.com/rus/msdn/msf/default.mspx
— Книга «Анализ требований и создание архитектуры р е ш е н и й
на основе Microsoft .NET. Учебный курс M C S D » ,
Русская редакция, 2004, 416 с.
ГОСТ 19.001-77. Единая система программной документации.
О б щ и е положения.
сайт http://www.fsf.org/
А.Н. Терехов, Л.А. Эрлих, А.А. Терехов. История и архитектура
проекта RescueWare. Автоматизированный р е и н ж и н и р и н г
программ. П о д ред. А.Н. Терехова, А.А. Терехова— С П б . :
Изд-во С.-Петербургского университета, 2000, с. 7-19.
М.А. Бульонков, Д . Е . Бабурин, HyperCode — открытая система
визуализации программ. Автоматизированный р е и н ж и н и р и н г
110

17.

18.

19.

20.

21.

22.
23.

24.
25.

26.
27.
28.

29.
30.

программ. Под ред. А.Н. Терехова, А.А. Терехова— СПб.:
Изд. С.-Петербургского университета, 2000, с. 165-183.
Р. Фатрелл, Д. Ш а ф е р , Л. Ш а ф е р . Управление программными
проектами: достижение оптимального качества при минимуме
затрат — М., «Вильямс», 2003.
Международный стандарт ISO 9001-94. Системы качества. Модель
обеспечения качества при проектировании, разработке,
производстве, монтаже и обслуживании — М.: И П К ,
Изд. стандартов, 1996, 19 с.
М . С Paulk, C.V. Weber, B. Curtis, M . B . Chrissis et al. «The Capability
Maturity Model: Guidelines for Improving the Software Process»,
Addison-Wesley, 1995.
А.М. Вендров. CASE-технологии. Современные методы и средства
проектирования и н ф о р м а ц и о н н ы х систем. — М.: Ф и н а н с ы
и статистика, 1998. — 176 с.: илл.
E.F. Codd. A Relational Model of Data for Large Shared Data Banks.
Communications of the A C M , Vol. 13, N o . 6, June 1970, pp. 377-387.
Copyright " 1970, Association for Computing Machinery, Inc.
O M G Unified Modeling Language Specification. Version 1.5, March
2003 formal/03-03-01//www.omg.org
В.Е. Карпов, К.А. Коньков. Основы операционных систем. Курс
л е к ц и й . Учебное пособие. — М.: Интеренет-Университет
И н ф о р м а ц и о н н ы х Технологий, 2004, 628 с.
Н. Вирт. Modula-2 и объектно-ориентированное
программирование. ИнфоАрт, 1998.
Edsger W. Dijksta. Cooperating sequential processes. / / Programming
Languages: N A T O Advanced Study Institute. Academic Press, 1968.
P. 43—112.
C . A . R . Hoare. Monitors: an operating system structuring concept.
Communications of the A C M , Volume 17 Issue 10. October 1974
М.Т. Хиллс, С. Кано. Программирование для электронных систем
коммутации — М.: «Связь», 1980, с. 248.
«RTST — технология программирования встроенных систем
реального времени» (Сб. «Записки семинара кафедры системного
программирования «CASE-средства R T S T + + » . Вып. 1, СПб.; Изд.
СПбГУ, 1998).
C C I T T Recommendation Z.100: C C I T T Specification and Description
Language (SDL) / / C O M X - R 26, I T U General Secretariat, Geneva, 1992.
В.В. П а р ф е н о в Объектно-ориентированный подход в
проектировании программного обеспечения встроенных систем
реального времени. / / Проблемы теоретического
и экспериментального программирования. Новосибирск. 1992.
111

31.
32.
33.

34.

35.

36.

37.

38.

C O R B A 3.0 — O M G I D L Syntax and Semantics chapter», available at
http://www.omg.org/cgi-bin/apps/doc7formal/02-06-39.pdf
I T U Recommendation Z.120: Message Sequence Chart. 11/1999. P. 138.
«Объектно-ориентированное р а с ш и р е н и е технологии RTST»
A . Терехов, А. И в а н о в , Д м . К о з н о в , А. Лебедев, Т. Мурашова,
B. Парфенов. (Сб. «Записки семинара кафедры системного
программирования «CASE-средства R T S T + + » . Вып. 1, С П б . ; Изд.
СПбГУ, 1998).
А.Н. Терехов, К . Ю . Романовский, Дм.В. Кознов, П . С . Долгов,
А.Н. Иванов. R E A L : методология и CASE-средство для разработки
систем реального времени и и н ф о р м а ц и о н н ы х
c и с т е м / / П р о г р а м м и р о в а н и е , 1999, № 5. с. 44-52.
N . Mansurov. Automatic synthesis of S D L from M S C and its application
in forward and reverse engineering//Computer Languages. Vol. 27.
N 1/3.2001. P. 115-136.
В.В. Соколов. Проверка соответствия SDL-диаграмм M S C документации п р и имеющихся отличиях. Системное
программирование. Сб. статей/ Под. ред. А . Н . Терехова и
Д . Ю . Булычева. — Спб., 2004, с. 366-390.
А.Н. Иванов. Технологическое р е ш е н и е R E A L - I T : создание
и н ф о р м а ц и о н н ы х систем на основе визуального моделирования.
Системное программирование. Сб. статей/ Под. ред. А.Н. Терехова
и Д . Ю . Булычева. — Спб., 2004, с. 89-100.
С.А. Стригун, А.Н. И в а н о в , Д . И . Соболев. Технология R E A L для
создания и н ф о р м а ц и о н н ы х систем и ее п р и м е н е н и е на примере
системы «Картотека».//Математические модели и
и н ф о р м а ц и о н н ы е технологии в менеджменте. Выпуск 2./ П о д ред.
п р о ф . Казанцева А.К. и доц. Должикова В.В. — С П б : Изд. СПбГУ,
2004. с 120-139.

112

П р и л о ж е н и я :
Статьи
И н т е р в ь ю
Д о к л а д ы
О б авторе

114

Как г о т о в и т ь с и с т е м н ы х п р о г р а м м и с т о в * '
С каждым годом растет интерес выпускников средней ш к о л ы к про¬
фессии программиста. П р о ф е с с и я программиста привлекает еще и пото­
му, что считается высоко оплачиваемой. В этом году многие выпускники
математических ш к о л , мечтавшие стать «чистыми математиками», вы¬
брали для себя профессию программиста. Тем не менее, далеко не все
стремящиеся стать программистами представляют, что нужно знать тем,
кто хочет стать в ы с о к о к в а л и ф и ц и р о в а н н ы м специалистом в области про¬
граммирования. М н о г и е ребята считают, что з н а н и е одного или несколь­
ких я з ы к о в программирования уже делает их программистами. Редакция
журнала обратилась к одному из ведущих специалистов в области про¬
граммирования, являющемуся одновременно крупным ученым и руково¬
дителем созданной им ж е ф и р м ы , заведующему кафедрой системного
программирования Санкт-Петербургского государственного университе¬
та п р о ф . А. Н. Терехову с просьбой высказать свое м н е н и е о подготовке
системных программистов вообще и в С П б Г У в частности.
П р о ф е с с и о н а л ь н ы м преподавателем Университета я стал почти слу­
чайно. Я читал спецкурсы, будучи еще студентом математико-механического факультета, руководил д и п л о м н ы м и работами, 9 человек защитили
кандидатские диссертации под м о и м руководством. Е щ е в молодые годы
я начал руководить лабораторией системного программирования Н И И
математики и механики математико-механического факультета. Когда уе¬
хал работать во Ф р а н ц и ю заведующий кафедрой математического обес¬
печения А.О. Слисенко (сейчас он заведует кафедрой в университете П а риж-12), наш декан решил, что я буду хорошей кандидатурой на этот пост.
Н а собрании кафедры меня попросили рассказать о своей программе.
Она была очень короткой, всего из двух пунктов. Первый тезис: каждый
преподаватель должен быть сначала исследователем, а уж потом — препо¬
давателем. Я готов простить некоторые недоработки, но не готов про¬
стить начетничества, когда преподаватель сегодня почитает книжку, а
завтра расскажет. Надо, чтобы преподаватели в основном рассказывали о
своих работах или о тех, в которых они п р и н и м а л и участие. Второй тезис
состоял в том, что надо соответствовать международным программам.
* Интервью главному редактору журнала «Компьютерные технологии в образовании»,
СПб 2001, № 3-4 (май-август), стр. 3-19.
115

За каждым из этих тезисов была моя выстраданная позиция. Н е люблю
я «начетчиков». Страдал от таких преподавателей, когда сам учился, и, есте¬
ственно, не хочу поддерживать их сейчас. А с международными стандартами
бывали ужасные истории. Например, м ы по роду своей деятельности много
контактировали с группой молодых людей из Академгородка из Новосибир¬
ска, которые под руководством доктора наук Котова делали новую машину
«Кронос». М ы в это время делали свою машину «Самсон», поэтому очень
интересно было поговорить, пообщаться, обменяться результатами, и ребята
произвели на меня незабываемое впечатление. Они часто приезжали к нам,
жили у меня дома. Многих из них я хорошо помню до сих пор. Двое из них в
конце 1980-х годов пробовали поступить в аспирантуру в американском уни­
верситете. Оба были очень умными, я мечтал бы иметь таких сотрудников.
И не поступили. Н е потому, что плохо говорят по-английски, или по какойлибо другой формальной причине. Они просто на половину вопросов не зна­
ли ответов. Хотя у них была очень мощная поддержка. Руководителем их ла¬
боратории был А. Марчук, а его отец был президентом Академии наук, поэ¬
тому сотрудники А. Марчука имели дополнительные возможности, получа¬
ли доступ к материалам, связанным с аспирантурой в Америке, которых
младшие научные сотрудники других организаций не имели.
На меня это произвело оглушающее впечатление, потому что я п р и ­
в ы к думать, что м ы , п о крайней мере, в области программирования «впе­
реди планеты всей». В некоторых областях это действительно так. В обла­
сти техники трансляции, в области теоретических вопросов программи­
р о в а н и я , теории оптимизации. Н о оказалось, что программирование за
это время разрослось, и м ы в своих работах, в основном, на оборону,
очень многие аспекты просто упустили. И в 1992 году, по м о и м подсчетам,
м ы н е охватывали даже 40% международного стандарта по специальности
«computer science and software engineering». Я сказал сотрудникам кафед¬
р ы , что нечего почивать на лаврах, нужно засучить рукава и заниматься,
догонять мировую цивилизацию. Была масса проблем, были дискуссии
на Ученом Совете. Б ы л и н е п р и я т н ы е и даже болезненные ситуации, н о в
результате сформировалась новая кафедра.
Так 6 лет назад я стал заведующим кафедрой системного программи­
рования. Я начал честно воплощать собственную программу, развивать и с ­
следования, которых у нас раньше н е было. Думаю, что сейчас м ы охваты¬
ваем примерно 80% международного стандарта, н о н е могу обещать, что
скоро м ы охватим все 100%. И м е н н о сотрудники нашей кафедры руково­
дят командами нашего Университета на международных соревнованиях.
М ы дважды стали ч е м п и о н а м и , н о для меня е щ е важнее, что в течение 5
лет подряд м ы были в призовой «десятке» из 2500 команд. Заметна ста¬
бильность результата. Я считаю, что кафедра системного программирова¬
н и я , несмотря на свою молодость, развивается достаточно успешно.
116

Сейчас я хочу сосредоточиться не на успехах (я отчетливо п о н и ­
маю — сегодня есть успех, а завтра тебя никто не вспомнит), а на пробле­
мах, которые мешают нам развиваться дальше. Их несколько, и я не знаю,
сумею ли я связно о них рассказать в этом интервью. Н о попробую.
Начну я, как ни странно это, может показаться читателю, с практики.
Студенты должны иметь практику. Программирование — это такая специ­
альность, которой не научишь у доски с мелом в руках. Для того чтобы луч­
ш е понять возможные пути организации практики, мысленно перенесемся
в Оксфордский университет, где м н е доводилось читать лекции, и я специ­
ально изучал местную постановку образования. Конечно, там иногда отда¬
ет некоторой «замшелостью», но, тем не менее, сотрудники университета
свято следуют традиции и с большой неохотой расстаются с чем-то старым.
Иногда им это можно поставить в минус. Например, сейчас Оксфордский
университет несколько отстал в области естественных наук от Кембриджа,
и специалисты говорят, что одна из причин этого отставания в том, что в
Оксфорде на 60 лет позже отменили обязательное обучение латыни. В К е м ­
бридже отменили в 1920-х годах, а в Оксфорде только в 1980-х. И на
протяжении этих 60 лет многих молодых людей отпугивала необходимость
учить мертвый я з ы к только потому, что так делали 800 лет назад.
Верность традициям достойна уважения. Н а п р и м е р , в Оксфорде для
каждого предмета есть теоретический курс, то есть л е к ц и и ; практический
курс, когда преподаватель со студентами решает задачи в аудитории, у до¬
ски, у компьютера, но при этом стоит рядом, и практикум по каждому
курсу — студент должен выполнить некоторую работу самостоятельно.
Причем не раз в полгода, как наша курсовая работа, одна на весь семестр,
а по каждому предмету каждые две недели. Есть огромные аудитории,
сотни свободных вычислительных м а ш и н . Приходишь, садишься, реша­
ешь, и затем свой результат показываешь тьютору. Это еще одна особен¬
ность — персональное обучение. П о каждому предмету час в неделю сту¬
дент работает со своим тьютором — таким преподавателем, который за не¬
го отвечает. Было пять предметов в неделю — значит, пять часов студент с
преподавателями проведет один на один. Причем тьютор составляет о с ­
нову преподавания. И м е н н о тьютор ведет вступительные э к з а м е н ы ,
и м е н н о тьютор отбирает себе студентов, а не колледж или университет в
целом. И м е н н о тьютор может сказать своему коллеге: «Знаешь, я уже на¬
брал себе нужное количество студентов, есть еще такой-то студент, возь¬
ми его себе в другой колледж».
Если читают, например, операционную систему реального времени,
то каждый студент должен написать программу: управление памятью, уп¬
равление процессорами, управление временем. Преподаватель смотрит
не только на результат, но и на то, как написана программа. П о всем пред¬
метам есть л е к ц и и , практика и практикум.
117

У нас с этим слабее. Курсовые работы — раз в семестр, и часто они
превращаются в ф и к ц и ю . Трудно изменить эту ситуацию к лучшему, п о ­
тому что нет соответствующих материальных ресурсов. К а к обязать всех
студентов по каждому предмету сделать самостоятельную работу, если м ы
не можем и м обеспечить п о л н о ц е н н ы й доступ к вычислительным маши¬
нам? Классы всегда перегружены. У нас не принято, чтобы студенты за­
нимались без преподавателя: и вирус занесут, и что-нибудь украдут, и ч т о нибудь сломают. Самостоятельную работу очень трудно наладить. О тьюторстве я даже не мечтаю. Это прежде всего вопрос денег. У нас наверня­
ка нашлось бы много хороших преподавателей, но для того чтобы обеспе¬
чить индивидуальное обучение, сколько надо преподавателей и какое по¬
требуется финансирование? Хотя еще со средних веков известно, что обу¬
ч е н и е — это всегда работа мастера с подмастерьем с непосредственной пе¬
редачей опыта. Единственная «живая» практика у нас — на пятом курсе,
полугодовая преддипломная практика. И здесь тоже есть свои проблемы.
Хорошо если практика была в известной ф и р м е , которая успешно и п р о ­
дуктивно на современном технологическом уровне занимается програм¬
мированием. Н о так бывает не всегда.
Отсюда первый тезис — сегодня надо практику реально совместить
с теорией. Формально говоря, все у нас есть. Студенты пятого курса пол­
года проходят преддипломную практику. И чем это кончается? Вот у ме­
ня толстая пачка отчетов по практике. Люди просто пристраиваются ра­
ботать (например, программистами) в какую-нибудь малоизвестную к о н ­
тору, ч а щ е всего я даже названия этой конторы не знаю. О н и работают.
С одной стороны, к а к и е могут быть претензии? Человек полгода прора­
ботал, получал деньги, кому-то был полезен. Спрашиваю я как заведую­
щ и й кафедрой: «Чему ты там научился?» «Вот, получил практический
опыт программирования на Java или C + + » . «Как была организована ра­
бота?» «Никак. Начальник дал задание, я написал программу». «Как был
организован коллектив? К а к и е были взаимоотношения? К а к велось пла­
нирование, отчетность? Б ы л и ли еженедельные собрания? Была ли регу­
лярная проверка качества? Б ы л и ли перекрестные чтения?» «Не было»
«Так чему ты, м и л ы й , там научился?» «Программированию» «Почему то¬
гда надо говорить, что ты заканчиваешь математико-механический фа¬
культет старейшего университета России?» Здесь я в н о е несоответствие
теории и практики.
Приведу другой пример. У нас несколько человек проходили прак¬
тику в зарубежной ф и р м е здесь, в Санкт-Петербурге. В этой ф и р м е все
хорошо организовано, но есть другая крайность: везде завеса секретно¬
сти. Д а ж е если дипломную работу студент написал там, ее в университете
защитить нельзя. Надо защищать в ф и р м е , организовывать ГЭК. Это ц е ­
лая проблема. Ладно, в к о н ц е к о н ц о в , даже на военных работали, могли
118

все организовать. Н о ведь человек отрывается от коллектива, ничего
не может обсудить. Самое главное в обучении — это беседа, разговор. А тут
несколько человек проходят практику и даже со своими однокурсниками
не общаются. Запрещено. Совершенно другая крайность. Очень высокий
уровень работы, но слишком индивидуальный. Люди из этой ф и р м ы , воз¬
м о ж н о , скажут, что я н е прав, что у них есть и семинары, и регулярное обу­
чение. Но я говорю о том, что вижу по результатам работы наших студентов.
Некоторые студенты проходят практику на предприятиях. Я требую,
чтобы это была н е только работа, н о и обучение. Тоже возникают проти¬
воречия: « М ы — производственное предприятие, нам надо зарабатывать
деньги, приносить прибыль, поэтому заниматься чисто учебными делами
как-то н е с руки. Нет-нет, м ы понимаем, что надо готовить кадры, н о все
д о л ж н ы заниматься своим делом».
Е щ е раз повторю, поскольку для меня это важно: практика — это
не просто работа «от забора до обеда», «переделал готовую программу»
или «спаял электронную схему». Практика подразумевает некоторое ис¬
следование, обучение организационным ф о р м а м , современным методам.
Практика должна быть разнообразной. Н а п р и м е р , э л е к т р о н щ и к должен
не только спаять, н о и спроектировать схему, спроектировать кристаллы,
которые внутри. Он должен участвовать в отладке — и н е просто участво¬
вать, а сделать тестовое окружение. Электронщики д о л ж н ы программи¬
ровать. Это все тесно связано.
Вас не удивляет, что я все время вспоминаю электронику? У меня
есть целый отдел электронщиков, у них и руководитель отдела — матема¬
тик, и многие сотрудники — математики. Сейчас электроника такая, что
все р а в н о надо программировать. Н о приходят и н ж е н е р ы , которые
не знают, к а к простейший тест написать. А как написать не один тест, а си¬
стему тестов для исчерпывающего тестирования, им даже объяснить н е ­
возможно. Практика должна включать в себя организационные аспекты,
элементы дизайна, элементы разработки, и самое главное — доводку до
результата. За полгода всегда м о ж н о получить результат. Н а эту тему мож¬
но говорить долго.
Тезис второй — чему учим? Вот передо м н о й лежит программа 35.15.
П о этой программе учится отделение и н ф о р м а т и к и математико-механического факультета. М ы с сотрудниками нашей кафедры п р и н и м а л и уча¬
стие в ее разработке. Д л я сравнения скажу: у нас отделение прикладной
математики учится п о специальности 01.02. Математическая статистика,
моделирование, теоретическая кибернетика — это все замечательно. В дипло­
ме написано: «Математик. Системный программист». Я обращаюсь к ав­
торам этой программы: «Покажите, где здесь программирование». Н а п е р ­
вом курсе учат программированию на я з ы к е С, и все. Я ж е н е говорю, что
в программу включили л и ш н и й материал. Все нужные вещи: и моделиро119

вание нужно, и кибернетика нужна, и распознавание образов, и вопросы
оптимизации. Н о зачем пишут в дипломе «Системный программист»?
Вот я заведую кафедрой системного программирования. Надеюсь, что
я знаю, что такое системное программирование. Давайте я тоже буду
учить программированию, а писать в дипломе «специалист по методу
Монте-Карло». Кому это понравится? К о н е ч н о , все понимают, что надо
привлечь людей, звучит название специальности хорошо, но не совсем
соответствует содержанию курса.
Вернемся к тому, что я действительно считаю хорошим. Н а п р и м е р ,
к специализации 35.15: математические основы и н ф о р м а т и к и , и н ф о р м а ­
ц и о н н ы е системы, технологии программирования, архитектуры вычис­
лительных систем, сети. Далее: экспертные системы, теория оптимиза­
ц и и баз данных, Интернет и Интранет, инструментальные системы для
С + + , Java-технологии, инструментальные средства визуального програм­
мирования, инструментальные средства логического программирования,
технология трансляции, я з ы к и и системы программирования, архитекту¬
р а Э В М , программно-аппаратные комплексы, о п е р а ц и о н н ы е системы
реального времени, телекоммуникации и так далее.
М ы на кафедре подсчитали часы по этой программе, и все равно
50 % — это «чистая математика». Самый главный недостаток даже не в этом,
а в том, что та половина времени, которая отведена на специальность, от¬
несена на конец. На первых трех семестрах — только 4 часа в неделю. Пред¬
ставьте себе: человек поступил на отделение информатики. Н е на отделе¬
ние «чистой математики», не на отделение астрономии или механики. И
учится полтора года, три семестра, имея 4 часа программирования в неде­
лю! В самых разных видах, все про все. Как можно его научить? Самое цен­
ное время уходит. Я даже встречался с заместителем министра образования,
обсуждал это все у нас в Университете, в У М О . Сценарий разговора всегда
был таким: «На кого жалуетесь, вы же сами профессор, член УМО! Вот и
вносите предложение, сократите то, добавьте это, для чего и создано
УМО». Хорошо. Н о как только я пытаюсь это делать, м н е сразу говорят:
«Как? Ты что? На факультете работают старые профессора, которые и тебя
учили математическому анализу, алгебре, высшей геометрии... Если ты
уменьшишь нагрузку, их надо будет сокращать. Неужели ты хочешь уволить
старых профессоров-математиков?» Конечно, не хочу. Правила, установ¬
л е н н ы е Министерством, предписывают, что количество преподавателей
должно быть связано с количеством студентов. Если число студентов
уменьшилось, соответственно уменьшается число преподавателей. То есть
такая простая вещь как перераспределение часов, сталкивается с министер¬
скими правилами, и никакой Университет, никакое У М О изменить это не
может.

120

В нашей программе есть федеральный компонент, вузовский компо¬
нент (региональный) и компонент по выбору. Федеральный компонент:
математический анализ — 4 семестра, количество часов в неделю: 8, 4, 6,
6. Алгебра и теория чисел — 3 семестра, часы: 4, 4, 4. Геометрия и тополо­
гия — 3 семестра, часы: 4, 4, 4. Дифференциальные уравнения — 2 семестра,
по 4 часа. Ф у н к ц и о н а л ь н ы й анализ — один семестр, 4 часа. Когда я был
студентом, было два семестра. Уравнения математической ф и з и к и — один
семестр, но 6 часов. Теория вероятностей и математическая статистика —
два семестра, 7 часов.
Когда я учился, вся теория вероятностей ограничивалась изучением
меры Лебега. О том, что вероятность находит применение в нашей науке, я
узнал лет через 15: оказывается, отказы вычислительной техники распреде­
лены по закону Пуассона. Так можно оценить вероятность отказа, но узнал
я об этом, только когда столкнулся на практике. М ы сделали новую вычис­
лительную машину, от нас потребовали расчет, я взялся за книги и с удив­
лением узнал, что теория вероятностей — полезная наука. М н е было уже
под сорок. Ничему такому — предсказывать отказы, считать их интенсив¬
ность, ничему этому нас не учили. Одни интегралы, интегралы, интегралы.
Конечно, из этих интегралов потом следуют и закон Пуассона, и все ос¬
тальное, но мостика между мерой Лебега и еще чем-нибудь полезным нет.
Есть вычислительный практикум — три семестра по 2 часа, и есть
программирование — три семестра, 3, 2, 2 часа. А здесь д о л ж н ы быть об¬
щепрофессиональные д и с ц и п л и н ы (федеральный компонент): архитек¬
тура вычислительных систем компьютерной сети, операционная система
оболочки, структура алгоритма компьютерной обработки данных, базы
данных и СУБД, компьютерное моделирование, компьютерная графика,
теория формальных я з ы к о в и трансляций, спецкурсы по выбору, спецсе¬
минары. Н о против всего этого — пустые клетки.
Посмотрим на третий курс (пятый-шестой семестр). Десять часов
в неделю. К а к можно за такое время научить чему-либо студентов? И толь­
ко на 4—5 курсе начинают учить «по специальности». Н о на пятом курсе
уже преддипломная практика, там только спецкурсы, и то понемножку. То
есть м ы можем учить практически только четвертый курс. Разве так мож¬
но? Вот где проблема. Причем не могу сказать, что у меня есть решение.
Тезис третий — необходимость теории. Один мой б ы в ш и й однокурс¬
н и к — сейчас профессор Западно-Берлинского технического университе¬
та. Я бывал у него, и он у нас бывал несколько раз. Я однажды его спро¬
сил, чему учат у них в университете. Выяснилось, что изучают и логику,
и все остальное, но только формулировки теорем. Я его спросил: «Скажи
честно, если я сейчас подойду к какому-нибудь вашему студенту и спро­
шу, что такое теорема Геделя о неполноте, он ответит?» «Нет, — говорит, —
даже не вспомнит». «Тогда зачем так учить?» «Ну, положено. А зачем вам
121

теорема Геделя?» «Хотя бы для того, — говорю, — чтобы молодой специа¬
лист имел представление о границах применимости теории. Теорема Геделя говорит о том, что корректность арифметики нельзя проверить средст­
вами самой арифметики, и дает теоретические ограничения, предлагает
искать какие-то метатеории, привлекать дополнительные возможности.
Если человек об этом даже не подозревает, о н будет в каких-то местах н а ­
прасно тратить время. У меня был случай, когда один выпускник кафедры
математической физики, работающий у нас, должен был реализовать анализ
потоков данных в программе. Он довольно быстро все реализовал. Самая
м о щ н а я м а ш и н а тогда была 486-я, и он на ней 4 часа тест из 20 строк го­
нял. Я посмотрел программу — простой перебор путей в графе. Я его спра¬
шиваю: «Ты разве не знаешь, что число путей в графе растет экспоненци¬
ально относительно числа вершин?» «Не знаю. Подумаешь, экспонента!
М а ш и н а железная, все посчитает». Я ему долго читал л е к ц и ю про акту¬
альную бесконечность, о том, что если в программировании видишь экс¬
поненту, то надо искать другое р е ш е н и е . Это не значит, что надо сдавать¬
ся. Я часто привожу студентам такой пример. На к о н ф е р е н ц и и , посвя¬
щ е н н о й 1000-летию алгоритма, в Ургенче (на р о д и н е Аль-Хорезми), была
представлена статья Ю.В. Матиясевича «Что н а м делать с э к с п о н е н ц и ­
ально с л о ж н ы м и задачами?» Вот это м н е нравится, это конструктивный
подход. Н е просто «Все, сдаюсь, больше ничего сделать не можем». Всег¬
да м о ж н о найти частные случаи. Есть и другая противоположность «тео­
ретического» восприятия задачи. Другой не менее известный ученый ме­
ня мучил, когда я сдавал кандидатский минимум: что значит теорема Ге­
деля о неполноте? И заставлял меня на экзамене (за две недели до защи¬
ты диссертации!) признать, что из этого следует, что м а ш и н а не все может.
Н о это не так! Нет общего подхода — найдем частные.
Например, знаете, на чем основана шифрация? Сводят задачу к ка¬
кой-нибудь трудноразрешимой (например, разложению числа на множи¬
тели). М о и коллеги, практики, сделали систему ш и ф р а ц и и . Популярная
система, продается хорошо. Они меня попросили показать кому-нибудь
из коллег; чтобы услышать мнение о том, насколько их работа теоретиче­
ски обоснована. Я попросил Ю.В. Матиясевича посмотреть их статьи. О н
минут 10 смотрел, тут же указывает мне фразу: «Поскольку никакого дру¬
гого способа вычислить, кроме простого перебора, нет, — это трудноразре¬
ш и м а я задача». М н е даже обидно стало, что сам не разглядел. А вдруг н а й ­
дется какой-то другой метод, который для данного конкретного класса за­
дач даст х о р о ш и й алгоритм? Тогда все это рассыплется, как карточный
домик. Возможно, такого метода и не найдется, но математика отличает­
ся тем, что все надо доказывать. Они не доказали, что другого метода, к р о ­
ме прямого перебора, нет.

122

Итак, нужны теоретики, нужны исследования и нужны доказатель­
ства. И уж если человек говорит, что эта система ш и ф р а ц и и стойкая —
будь любезен, докажи, что никакого способа, кроме полного перебора,
нет. Другое дело, что и в некоторых классических задачах криптографии
этот вопрос до сих пор открыт.
Если у тебя нет теоретической подготовки, то так и будешь перебирать
пути в графе, не задумываясь об экспоненциальной сложности алгоритма.
На практике это означает, что алгоритм работать не будет. Теория дает о п ­
ределенные границы: за что браться, за что не браться, где искать, где не ис¬
кать. Где с самого начала надо искать срез, подзадачу, специальный случай.
Все-таки это з н а н и е составляет малую часть н а ш е й профессии
5—10%. Просто есть вещи, которые надо знать. Если ты их вообще не зна¬
ешь, можешь налететь на такие грабли, что лоб себе р а с ш и б е ш ь .
... Однако, давайте поговорим о программировании. Я много раз чи¬
тал л е к ц и и в Гамбурге в Классическом университете и в Техническом уни¬
верситете. Там даже поговорить о программировании часто не с кем. Две
крайности: или «коробочники», которые умеют пользоваться стандарт­
н ы м и программами, или теоретики, которые занимаются чем-нибудь та­
к и м , что неизвестно когда на практике осуществится. А людей, з а н и м а ю ­
щихся нормальным программированием, часто и не встретишь.
Я приведу еще один пример. П р и м е р н о в 1975 году м ы получили пер¬
вую Е С Э В М 1030 среди гражданских организаций СССР, об этом даже в
газетах писали. Первые Е С Э В М шли только на оборону. И вот ленинград¬
ский математико-механический факультет получил самую первую маши¬
ну за счет того, что мы делали много программ для Е С ЭВМ. М а ш и н а ча¬
сто ломалась, а м ы сидели вечерами и даже ночами. Весь чай был выпит,
все возможные темы обсуждены, И вот я начал одну девушку-оператора
учить своему любимому языку АЛГОЛ-68. Такой сложный я з ы к програм­
мирования, и редко какой студент мог его освоить в полном объеме. За н е ­
сколько месяцев я научил ее так, что не каждый студент мог с ней срав­
ниться. Говорю ей: «Теперь тебе надо переходить работать программистом.
И зарплата выше, и работа интересная. Ведь что такое работа оператора?
Поставить диск, загрузить машину». И тут я с ужасом понял, что она не
знает, что программировать. Она не знает, как можно итеративно вычис¬
лить квадратный корень, она не знает, как устроен транслятор. Она знает
я з ы к программирования, экзамен сдать может, а программировать не м о ­
жет. На меня этот эпизод произвел очень сильное впечатление.
П р о ш л о 25 лет, вроде бы многое изменилось. Н о посмотрите, м ы
с вами здесь сидим, каждые 10 минут дверь открывается. К а ж д ы й третий
приходит с вопросом: «Андрей Николаевич, я хочу у вас работать. Я слы­
шал, что у Вас много людей занимается интересной работой». «Отлично,
что ты умеешь?» «Я умею программировать на Паскале». «А что ты зна123

ешь-то?» «Ну, как, я ж е научусь» «Посмотри на список спецкурсов кафед¬
р ы . Ч т о из этого т ы знаешь?» «Ничего» «И к а к ты будешь работать? Я те¬
бя определю в группу «Телефония». Ты знаешь, что к а к устроено? Ч т о т ы
там будешь программировать? Ты умеешь писать a:=b, a:=b+c, н о ведь это
не программирование. Надо знать, что программировать».
Результат таких разговоров может быть двояким. Кто-то всю ж и з н ь
меня после этого ненавидит за то, что о н хотел заниматься интересным де¬
л о м , а злобный Терехов на него ушат холодной воды вылил, а бывают та¬
кие упрямцы, которые говорят: «Ничего, я научусь». Хорошо, первые три
месяца — стажировка, и, если выяснится, что человек работать не может,
ему просто вежливо скажут: «Извини, друг, н о нам надо двигаться даль­
ше». Это не значит, что человек пропадет, может быть, о н попадет в другую
группу. Бывает, что люди с третьей попытки свое место находят. Бывает
так, что человек научится в процессе работы, н о это скорее исключение,
чем правило. Это обходится большими усилиями, ч е м у студента в процес­
се учебы, но зато закрепление совсем другое и мотивация другая.
Итак, между собой взаимосвязаны теория, практика, границы п р и ­
менимости теории, некоторые л и ч н ы е знания. Я объясняю своим студен­
там, что системный программист — это сфера обслуживания. М ы н е дела¬
ем конечных продуктов. Н а п р и м е р , человек производит расчеты. У него
есть какой-то результат. П р и этом о н пользуется трансляторами, операци¬
о н н ы м и системами, вычислительными м а ш и н а м и , которые придумали
другие люди. И системщики — к а к раз те люди, которые делают трансля¬
торы, инструментальные средства, разрабатывают методологии п о их ис¬
пользованию. А потом уже прикладные программисты этими средствами
и методологиями пользуются и получают к о н е ч н ы й результат. Очень ч а с ­
то, кстати, люди видят только к о н е ч н ы й результат, особенно когда идет
речь о делении денег, и совсем н е видят той дороги, тех трудностей, кото¬
р ы е были преодолены, чтобы этот результат получить. Системное про¬
граммирование — это довольно старое название. По-русски м ы хорошо
знаем, что такое системное программирование. Н о были проблемы, к а к
перевести это словосочетание на английский я з ы к . Есть наука computer
science, она более теоретическая. А есть наука software engineering. Вот я ,
заведующий кафедрой software engineering. Еngineering — это разработка
программного обеспечения. И м н е кажется, что это довольно четко сей¬
час определилось.
Теперь следующий тезис, следующая проблема. Вот защищается мой
аспирант у нас на Совете. Я сам — член Ученого Совета. И каждый р а з по¬
падается какой-нибудь, мягко сказать, недоброжелатель, который, по¬
скольку на Ученом Совете может выступать кто угодно, говорит: «Вы зна¬
ете, я н е п о н и м а ю , почему это математика. Нет теорем, нет доказательств
сходимости, почему эта диссертация защищается на математическом ф а 124

культете?» В реальной действительности самый лучший ответ — сказать:
«Вы ничего не понимаете в этой области». Времена, когда математика бы¬
ла только в теоремах, кончились как м и н и м у м 100 лет назад, а может
быть, и больше. В середине X I X века Ч . Бэббидж придумал вычислитель­
ную машину, в которой были все основные элементы (процессор, память,
программа, хранящаяся в памяти). Дочь Байрона Ада Августа леди Л а в лейс пятистраничный доклад этого Ч . Бэббиджа на итальянском я з ы к е
преобразовала в 100-страничный английский текст, где впервые ввела
слова «Переадресация», «Процедура», «Цикл» — это что, не математика?
Это было сделано более 150 лет назад.
Проблема решается просто, если говорить серьезно. Есть специаль­
ность «Математическое обеспечение вычислительных м а ш и н , сетей и с и ­
стем». Это не математический анализ, не математическая физика. Есть
критерии, предъявляемые к кандидатской диссертации: новые результа­
ты с практическим внедрением, я з ы к и программирования, их реализа­
ц и я , операционные системы и, самое главное, модели. Математика н а ч и ­
нается тогда, когда м ы можем что-то формализовать, когда м ы можем
сформулировать задачу настолько точно, что м о ж н о построить алгоритм.
Почему возникли потребности в строгой формализации? Потому
что п р и ш л о п о н и м а н и е , что некоторые задачи в п р и н ц и п е нельзя решить,
потребовалась алгоритмическая формализация, и с п о м о щ ь ю этих фор¬
мальных методов удалось доказать неразрешимость нескольких проблем.
Первые такие доказательства были получены в 30-х годах X X века. Почему,
когда я доказал про что-то, что этого нет и быть не может, — это матема­
тика, а когда я построил формальную модель и по ней сделал алгоритм,
который работает, — это уже не математика? Н и к т о не сказал, что только
отрицательные результаты являются математическими. В нашей стране
такой консерватизм особенно силен. Граница между «наукой» и «не нау¬
кой» в д а н н о м случае, когда речь идет о программировании, достаточно
понятная, но трудно формализуемая, поэтому вызывает массу проблем,
профессионал их знает. И постоянно на Ученом Совете кто-нибудь начи¬
нает возражать, что это «не наука». Важно создать новую модель, н о в ы й
я з ы к , н о в ы й метод, н о в ы й алгоритм, показать, что о н отличается от дру¬
гих. Я уже много р а з был оппонентом, а не только руководителем диссер¬
тации. Для новичка, для человека со стороны это, может быть, будет даже
удивительно. В задачу оппонента входит не только оценить, хорошая д и с ­
сертация или плохая. Главная задача — оценить соотношение этой работы
с другими известными работами. Н е забыл л и диссертант, что это уже сде¬
лано? Он сравнивал свою работу с другими? Н е забыл ли он какой-то важ­
н ы й результат, который был получен другим, а у него даже не упомянут?
Насколько корректно проведено сравнение собственной работы с други¬
ми известными работами? Есть такая наука, которая называется software
125

engineering, в ней есть своя область деятельности, свои требования, свои
критерии. П р о ф е с с и о н а л ы знают, что сделать хороший транслятор — это
очень трудная задача. Сделать технологию, которой будет пользоваться
ш и р о к и й круг людей, тоже очень трудно.
У меня защищалось в этом году 19 человек. Приходит студент V кур¬
са, проведший полгода где-то на практике. Показывает свою программу.
Я говорю: «Хорошо, давай посмотрим, насколько научна твоя работа. Ч т о
здесь самое главное? Во-первых, насколько это н о в ы й результат? Писал
ли кто-нибудь об этом раньше?» «Не знаю» «Ты делал обзор литературы?».
«Нет»... Ч е м отличается исследователь от практика в худшем п о н и м а н и и
этого слова? Исследователь поймет, что н е надо изобретать велосипед. В
н а ш е время, когда есть Интернет и другие каналы получения информа¬
ц и и , имеет смысл посмотреть, что сделали другие. С этого надо начинать.
Далеко н е всем это приходит в голову. Н а ш е л , что такого результата нет, и
ты его сам получаешь. Н о есть похожие результаты. Проведи сравнитель¬
ную характеристику. М н е н е нравится такая ситуация: люди работали, пи¬
сали д и п л о м ы , писали диссертации. Спрашиваешь: «Чем ваша техноло¬
гия лучше, ч е м остальные?» И следуют аргументы: «С одной стороны,
нельзя н е признать, с другой стороны, нельзя н е согласиться...» С п р а ш и ­
ваю: «Ребята, вы потратили на эту работу столько сил и времени. М ы ин¬
туитивно понимаем, что это хорошо. Н о разве так трудно все это четко
сформулировать? У многих программ есть демо-версии, и сравнение их с
вашим вариантом входит в работу». Н ы н е ш н я я молодежь с трудом п о н и ­
мает, что просто сделать что-то, что работает, — это м е н ь ш е п о л о в и н ы д е ­
ла. Настоящий исследователь должен смотреть, к а к работают другие, ска­
чивать демо-версии, читать инструкции — к а к у н и х запускается програм­
ма, научиться запускать, посмотреть, поработать, понять, что хорошо, что
плохо, может быть, заимствовать какие-то идеи. Необходимо четко с ф о р ­
мулировать, в ч е м твоя заслуга. Ч т о т ы такого сделал, чего у других нет?
Сейчас этим занимаются только бедные диссертанты, и то, к сожалению,
есть такая десятилетиями сложившаяся практика, что о н и занимаются
этим в последний момент, когда уже «кирпич» пишут. Положено иметь
обзор литературы п о теме — о н и и сидят в библиотеке по 3 месяца в самом
конце. Между прочим, на моих глазах была ситуация, когда аспирант за­
щищается п о отладке, а его на Совете спрашивают: «Как это соотносится
с такими-то методами отладки?» Оказалось, что о н в библиотеке Акаде¬
м и и Наук сравнивал свой метод с американскими работами, а то, что в
С С С Р есть такие работы, и н е знал...
Сейчас я попытаюсь е щ е раз сформулировать эту идею. Дали тебе
работу — н е поленись, потрать время, посмотри, что есть у других. К а к и е
есть методы. Н е изобретай велосипед. И в то ж е время — никакого низко¬
поклонства перед Западом, даже если там есть какие-то публикации. П о 126

смотри, насколько о н и хороши. Если хороши — используй, со ссылкой.
Для этого и существует вся мировая наука, чтобы пользоваться ее резуль¬
татами. Н е надо ничего высасывать из пальца. Н о плохо, когда человек
не потратил времени на то, чтобы л и ш н и й р а з посмотреть, а потом ему
кто-то другой указывает на точно такие ж е , если н е лучшие, результаты
других исследователей.
Итак, важно умение сформулировать задачу, умение посмотреть на нее
со стороны «что есть в мире» и умение четко объяснить, что у тебя нового.
Я в очередной раз отвлекся, н о все-таки закончу. Приходит студент и з
мелкой ф и р м ы с программой. Никакого анализа н е сделано, сравнитель­
ных характеристик н е сделано, никаких моделей н е построено, ничему
новому он не научился, то есть просто сидел и работал на зарплату. Что те­
перь делать? Я уверяю, что это н е может быть дипломной работой. Д и п л о м ­
ная работа обязательно должна нести элемент научного творчества.
Преддипломная практика — на первом семестре пятого курса. И к о ­
гда человек нормально практику прошел, чему-то научился и пришел
с результатом, у него е щ е есть время на то, чтобы превратить эту работу
в дипломную. Бывают с м е ш н ы е случаи. Два студента сделали транслятор
с Java. Н и к а к и х ссылок — будто о н и в безвоздушном пространстве.
«Сколько вы знаете трансляторов с Java?» «Один или два». П о и с к а л и в
Интернете — оказалось, 20—30. «Дайте сравнительные характеристики».
Выяснилось, что проигрывают в 500 раз одному и з трансляторов. Говорю:
«Ребята, я читал про унтер-офицерскую вдову, которая сама себя высек¬
ла, н о н е думал, что это может быть среди студентов мат-меха». Посмот¬
рели программу — это оптимизирующий транслятор с я з ы к а С. Java — это
интерпретатор по определению, поэтому их и сравнивать по эффективно¬
сти нельзя — это задачи с совершенно р а з н ы м и целями. Умение грамотно
сформулировать задачу здесь было необходимо. Хорошо, что я успел уви­
деть эту дипломную работу, иначе над н а м и бы еще долго смеялись.
И л и другой пример. Приходит студент с работой по теме «распарал¬
леливание». Я н е был научным руководителем, н о , прочитав работу, по¬
чувствовал, что я такое сто раз слышал. У меня в это время дочь в Англии
была и к а к р а з занималась распараллеливанием. П о з в о н и л ей, она пере¬
числила методы и средства, которые сейчас используются. Н а мальчика
было жалко смотреть. К о н е ч н о , он получил нормальный результат, что-то
сосчитал и думал, что изобрел н о в ы й метод. О н был уверен, что никто
в мире этого н е знает. Откуда такая уверенность? К о н е ч н о , м ы учим сво¬
их студентов тому, что «мат-мех лучше всех», н о всему есть свой предел.
Так ж е нельзя, т ы ж е н е один в мире.
Итак, следующий тезис такой. М ы готовим университетских людей,
которые д о л ж н ы быть способны — я на этом жестко настаиваю — н е толь¬
ко написать программу и придумать э ф ф е к т и в н ы й алгоритм, н о и срав127

нить, обосновать, понять теоретически возможные границы п р и м е н и м о ­
сти. Это обязательно входит в университетское образование.
Н о кто сказал, что только такие люди нужны? М ы переходим к сле¬
дующему вопросу. Вот передо м н о й лежит проект программы «Федераль­
ная целевая программа электронной России на 2002 — 2010 годы». М н е
очень понравилась фраза: «В настоящее время наблюдается определенное
перепроизводство «массовых» специалистов с в ы с ш и м образованием,
в частности, в области создания программного обеспечения и техниче¬
ской поддержки информационно-вычислительных и коммуникацион¬
ных систем, которые часто вынуждены выполнять ф у н к ц и и , н е требую¬
щ и е ш и р о к о й теоретической подготовки, которые могут и д о л ж н ы заме¬
щаться специалистами со средним образованием». Е щ е год назад, в связи
с к о н ф е р е н ц и е й п о Наукограду, я изучал материалы п р о аналогичные з о ­
н ы в И н д и и , в Ирландии. В И н д и и готовится в год 5000 master of science
(аналог нашего высшего образования) и 27000 бакалавров. М ы пытались
прикинуть, сколько у нас готовится. Получилось несколько тысяч п р о ­
граммистов с в ы с ш и м образованием очень разного профиля. У нас и же¬
лезнодорожный институт, и институт водного транспорта готовит про¬
граммистов, н о все равно получается всего несколько тысяч. А бакалав­
ров нет вообще. У меня, к а к видите, вся стена увешана досками с имена­
ми наших сотрудников, которые готовят команды на международные
олимпиады п о программированию. Пять лет подряд в десятке и з 2500 к о ­
манд, два года подряд — ч е м п и о н ы . Это приятно. Н о только за 5 лет н и
один из них н е стал профессиональным программистом. О н и математи¬
ки. Сейчас Андрей Лопатин перешел на нашу кафедру и переучивается.
Нельзя сказать, что у него все так бравурно идет — о н тратит силы, время,
и надеюсь, что и з него м ы сделаем профессионала. Это первый такой
пример за 5 лет. Я и раньше пытался сказать, что м ы с л и ш к о м сильно
сконцентрировались на результатах олимпиад. Действительно, важно по¬
беждать на олимпиадах, важно иметь исследователей. У меня на предпри­
я т и и есть несколько человек, таких, что, если хотя бы один из н и х уйдет,
мое предприятие лопнет. Есть люди, на которых держится предприятие,
потому что о н и придумывают новые идеи, о н и все цементируют. У меня
на предприятии больше — 200 человек, а таких, без которых все остано­
вится — 2—3, может быть, 5, если молодых прибавить. Если уйдут другие,
м о ж н о найти и м замену. Н о и м е н н о остальные 200 человек выполняют
основной объем работы. Бакалавриат у нас как-то н е прижился, н о нуж¬
но найти какие-то у п р о щ е н н ы е ф о р м ы подготовки программистов.
Иногда говорят: «У нас такой отсев, у нас уезжают на Запад». У нас
на кафедре немногие уезжают — за все годы человек 15 и з 250—300 выпу¬
с к н и к о в уехали за рубеж. М н о г и е из этих 15 н е просто так уехали, а по со¬
гласованию со м н о й перешли в к о м п а н и и в С Ш А , которые со м н о й ж е
128

сотрудничают. То есть м о ж н о сказать, что эти выпускники со м н о й ж е и
работают, только с другой стороны. Кстати, это очень помогает. Всегда
п р и я т н о , когда там свои люди, говорящие по-русски, с н а ш и м ментали­
тетом. Дело не в английском я з ы к е , у нас по-английски все говорят, н о ,
когда там сидит человек и может поговорить на «ты» с кем-то из н а ш и х
это всегда сильно помогает. Так что это даже нельзя назвать потерей. Б ы ­
вает отсев, когда уходят в другие к о м п а н и и . Бывает так, что выпускник
н а ш е й кафедры уходит за зарплатой в 1000 долларов. Я столько платить не
могу. А о н и уходят и часто страдают. Вот сейчас Artificial Life объявила,
что закрывается, другие к о м п а н и и сокращают количество сотрудников. Я
не то что мстительный, просто я слежу за своими учениками. Этот был
вынужден уйти сюда, этот туда. Н е все у них плохо, слава Богу, но за длин¬
н ы м рублем гнаться не стоит, особенно в молодые годы.
Е щ е немного отвлекусь, уж больно пример для меня интересный. К о ­
гда уезжали хоккеисты уровня Ларионова и Фетисова, это было одно. Л ю ­
д и , сделавшие и м я , они за рубежом уже были хорошо известны. Когда уез­
жают 19-20-летние ребята, чтобы годами играть в фарм-клубе, то потом,
даже когда пытаются вернуться, уже здесь не могут играть на хорошем
уровне, потому что там они не играли у таких великих тренеров, как Тихо¬
нов, Тарасов, и имели мало игровой практики. Аналогия абсолютная. Од¬
но дело — человек закончил математико-механический факультет, еще
лучше — аспирантуру, защитился, получил 5-10 лет стажа, поработал, п р и ­
нес пользу своему предприятию, своему родному университету, научил м о ­
лодых специалистов и поехал. Вперед, я даже помогу. Это профессиональ­
н ы й рост, это интересная работа. Я вовсе не к тому, что нельзя ездить. О н
там получит новые знания, новые силы, новую и н ф о р м а ц и ю для себя и,
возможно, для нас. Может нам принести заказы, интересные научные и с ­
следования. Все это понятно. Я считаю, что это нормально. Совсем другое
дело, когда уезжает совсем молодой человек. У меня был случай, когда сту­
дент полгода недоучился, диплом не защитил и уехал. Ведь диплом Л е н и н ­
градского — Петербургского университета во всем мире признается. «Вы
извините, может быть, мне перейти на другую кафедру, чтобы вашу кафед¬
ру не позорить?» «Да, — говорю, — и так уезжай!» Н о я считаю, что это уже
перебор. Кому он там нужен? Сейчас там перепроизводство программи¬
стов, массовые сокращения. Опять-таки не подумайте, что я злорадствую.
Хотя, конечно, тех, кто меня бросил, тем более «на полуслове», не передав
материалы, не передав и н ф о р м а ц и ю , я тоже запоминаю. Были разные
неприятные случаи, но м н е не хотелось бы о них подробно рассказывать.
Д о л ж н ы быть какие-то законы. Я в начале разговора вспоминал про
федеральную составляющую. Я не могу этот закон обойти. Если я его
не в ы п о л н ю , то д и п л о м будет считаться недействительным. Эти вопросы
надо решать на государственном уровне. Точно такая ж е ситуация и с отъ129

ездом молодых специалистов. И она, кстати, решается. Н е решена, но ре­
шается. Если этим интересуетесь, п о и щ и т е в Интернете. Во многих стра­
нах дается кредит на образование, который ты должен отработать. Если
уезжаешь — будь любезен, отдай. Неужели м ы настолько богаты, чтобы об
этом не думать? Д о л ж н ы быть определенные жесткие государственные
законы. Если студент или его родители платили по 5000 долларов за се¬
местр — уезжай, куда хочешь. Н о если на тебя государство истратило
столько денег — почему м ы д о л ж н ы отпускать человека, который у нас
получил образование?
Я п о н и м а ю , что у человека, занимающегося классической математи­
к о й , могут быть проблемы. Один мой приятель, алгебраист, который
недавно уехал, говорил: «Если бы н а ш е государство хотя бы треть тех де­
нег, что в С Ш А , платило, я работал бы здесь. П о й м и меня, я не хочу з а н и ­
маться программированием». Все понятно, я тоже не хотел бы занимать­
ся алгеброй. А это — фундаментальная наука, и государство ее практиче­
ски не поддерживает. А у него семья, двое детей, вот он и уехал. Я в него
к а м н е м не кину. У него выхода не было, его государство так подставило.
И не он один. Н о это «классическая наука». А люди, которые занимаются
прикладными вещами, живут. Причем, не только программисты. Я сейчас
общаюсь, например, с людьми, которые корабли строят. Есть заказы, есть
интересная работа, есть зарплата.
Если программист бедный — значит, он плохо работает. У нас такая
специальность, что на кусок хлеба заработать можно. Для меня отъезд за
границу не представляется серьезной проблемой. Когда говорят про «утеч­
ку мозгов», это скорее лозунги для демонстрации. Создайте рабочие мес¬
та, обеспечьте людей интересной работой, обеспечьте приличную зарпла¬
ту (пусть не на уровне С Ш А , но такую, чтобы м о ж н о было содержать се¬
мью) — и почти никто не уедет. Поедут только те, кто любит приключения.
Что такое государственная поддержка? В И р л а н д и и , если предпри­
я т и е делает программное обеспечение, оно платит 10% налога с прибыли
при норме 28%. Н о это относится только к прибыли, полученной от п р о ­
граммного обеспечения. Программное обеспечение отличается в лучшую
сторону от многих других видов продукции тем, что это возобновляемый
ресурс. И н д и я , благодаря развитию телекоммуникаций и программного
обеспечения, получает большие деньги с экспорта, в страну возвращают­
ся те, кто ранее ее покинул. Ирландия — маленькая страна, но производит
40% программного обеспечения в Европе. Десять лет назад это было тру­
дно предположить, но многое решает разумная государственная поддерж¬
ка. Все должно быть в разумных пределах.
Государственная поддержка — важный момент, и есть положитель­
н ы е п р и м е р ы — И н д и я , Ирландия, Израиль. Имеется в виду не только н а ­
логовая политика. Н а п р и м е р , хорошо подобранная программа обучения
130

— это государственная поддержка. Инфраструктура телекоммуникаций —
это государственная поддержка. Удобный проезд до крупнейших учебных
заведений — тоже государственная поддержка. Вспомните н а ш мат-мех!
У нас мог бы быть совсем и н о й контингент студентов, если бы электрич¬
ка ходила полчаса, а н е час, к а к сейчас. В Сингапуре в Ш к о л е программи¬
рования на I V курсе занятия начинаются в 17 часов. Дело в том, ч т о , если
ты н е работал на фирму п о л н ы й рабочий день — диплом н е выдадут. Ка¬
кой т ы программист, если никогда н е работал профессионально? И это —
на дневном отделении. Сначала поработай, и пусть отзыв дадут, что т ы
действительно программист.
На юге Ш в е ц и и в некоторых маленьких городках, где п о 30 тысяч
жителей, есть свои IT-университеты. Н а п р и м е р , пять факультетов: про¬
граммирование, технологии, архитектура телекоммуникаций, экономи¬
ка, юриспруденция. Отделения в Англии, в Техасе, много профессоров, и
программы хорошие, я сам их смотрел. В Ш в е ц и и каждый университет
окружен технопарком, 200-300 мелких к о м п а н и й . Государство предостав­
ляет здание (побольше нашего матмеха). Аудитории, места для к о н ф е р е н ­
ц и й , дешевые гостиницы. Получается такой симбиоз: университет гото¬
вит специалистов, которые работают в этих фирмах. Технопарку выгодно
иметь ресурсы, а университету выгодно иметь финансовую поддержку
и обратную связь, чему учить и к а к учить. Я уже давно говорю, что в на¬
ш е м университетском городке тоже надо бы сделать технопарк. П о к а ни¬
как н е получается.
И е щ е одна тема — развитие собственно науки. Есть класс людей, ко¬
торые готовы работать за м е н ь ш и е деньги, н о при условии, что будут за¬
ниматься наукой. Это особенность психики человека, которому неинте¬
р е с н о делать программное обеспечение с заранее указанными свойствами
в жесткие сроки. Н о таких людей мало. И проблема в том, что в Петербур¬
ге есть сотни к о м п а н и й , где платят п р и л и ч н ы е деньги, и программист м о ­
жет просто зарабатывать, н о предприятия наукой заниматься н е хотят.
М ы н е можем все свести к работам «по заказу», даже если работа хо¬
р о ш о организована, поддержана м о щ н ы м и современными технологиями
и налажены все организационные процессы. Кто будет создавать новые
идеи, новые методологии, новые инструментальные средства? Н а мой
взгляд, есть определенный процент выпускников университета, у кото­
рых в особенностях психики заложено, что о н и хотят сидеть в т и ш и лабо­
ратории и заниматься наукой. Это люди, которые готовы получать, ска­
ж е м , в два раза меньшую зарплату, ч е м люди на фирмах, н о заниматься
своей л ю б и м о й наукой.
Кстати, первый раз я столкнулся с этой проблемой в Гамбурге. Это
было в 1989 году. Х о р о ш и е преподаватели Гамбургского университета по¬
лучают 7000 марок. Я навел справки и выяснил, что можно работать в п р о 131

граммистской фирме и получать 20000 марок тут же, в Гамбурге. И места
есть, и приглашают. Н о преподаватели на такую работу н е стремятся п о ­
пасть. Я постарался узнать, почему. Ответ был следующим: «Во-первых,
7000 марок вполне достаточно, у меня есть д о м , у меня есть дача, маши¬
на, что м н е е щ е надо? В бочку, что л и , эти деньги складывать? А во-вто¬
рых, в программистской ф и р м е будет жесткое управление, жесткие при¬
казы. Я этого н е люблю. Я работаю в университете. Этой зарплаты м н е до¬
статочно, чтобы прилично существовать, н о я хочу заниматься и м е н н о
наукой».
Я понимаю этого преподавателя. Есть такие люди. Если бы не было та¬
ких людей, то наша наука бы остановилась. Где и м работать здесь, в СанктПетербурге? Какая ф и р м а возьмет на себя обязанность материально под­
держивать фундаментальные исследования?
Кстати, а что это такое — фундаментальные исследования? У моих
прагматичных друзей-американцев есть забавный, н о полезный крите¬
р и й , к а к отличать фундаментальные исследования от нефундаменталь­
ных. Если исследование 3 года н е приносит прибыль, о н о считается ф у н ­
даментальным, и та часть прибыли, которая в него вложена, освобожда­
ется от налогов. И ф и р м е это полезно. Если ж е , н е дай Бог, через 2,5 года
из этого исследования получился результат, который был п р и м е н е н на
практике, продан, получены деньги за него — налоговый инспектор пере¬
считает налоги за него. Значит, исследование н е было фундаментальным.
М о ж н о улыбаться, глядя на это правило, н о о н о существует, и о н о рабо¬
тает. В С Ш А очень много забавных правил, н о е щ е более забавно, что ос¬
новная масса людей этим правилам следует.
Так, и л и похожим образом, или совсем по-другому, н о м о ж н о приду­
мать законы для поддержки фундаментальных исследований. Н а п р и м е р ,
я директор предприятия. У меня есть свой директорский ф о н д , то есть
сравнительно небольшая сумма денег, которую я отнимаю от других зака¬
зов и имею право тратить их по своему усмотрению. Практически все эти
деньги я трачу на поддержку исследований.
Н о те люди, которые получают деньги, чувствуют себя «людьми вто­
рого сорта», потому что время от времени я вынужден и м напоминать, что
м н е нужны результаты, что я ради вас брал деньги у такой-то группы...
Это н е улучшает психологический климат. И те люди, у которых я отнял
деньги, тоже н е рады: «Лучше бы ты н а м е щ е два компьютера купил, луч¬
ш е бы ты н а м новую мебель купил» и так далее. Всегда есть необходи¬
мость что-то купить, разумно истратив деньги для той группы, которая их
заработала. У меня даже распадались группы, и одной и з п р и ч и н ухода с о ­
трудников было их несогласие с моей политикой распределения денег.
О н и твердо настаивали на том, что о н и заработали деньги, поэтому эти
деньги д о л ж н ы быть истрачены на их зарплату, в крайнем случае, на их
132

инфраструктуру, на компьютеры. Даже, может быть, и на исследования,
но только в этой узкой области, где о н и заработали деньги. И все мои по¬
пытки объяснить и м , что так н е бывает, что никто н е может предсказать,
какое направление в науке проявит себя через два-три года, н и к чему
не приводят. Я уж н е говорю о том, что понятие «они заработали» — совер­
ш е н н о неправильное. Зарабатывает предприятие, директор, маркетологи,
завхоз, сетевые администраторы и т.д. Когда «уговаривают» заказчика,
ссылаются на предыдущие работы предприятия. Заказчик с большим удо­
вольствием работает с устоявшимся большим коллективом, а н е с малой
группой, которая в любой момент может разбежаться.
Я н е настаиваю на том, что мое р е ш е н и е — единственно правильное.
Возможно, в чем-то и о н и были правы. Н о , тем н е менее, я искренне счи­
таю, что большое предприятие, диверсифицированное, то есть имеющее
много направлений работы и много направлений исследований, стабиль¬
нее и надежнее. Бывает, что некоторые направления, даже очень м н о г о ­
обещающие, неожиданно коллапсируют. Н ы н е ш н и е резкие падения ко¬
э ф ф и ц и е н т а высокотехнологичных производств в Америке, по-моему,
как раз это и показали. Сколько было ожиданий от всех этих бесконечных
интернет-приложений! А теперь идет массовое закрытие ф и р м , увольне¬
н и е людей. Может быть, найдется 2-3 умных человека, которые скажут:
«Я об этом и говорил», только я таких н е знаю. Трудно предугадать, что
разовьется, а что нет.
Я считаю, что м ы (тем более м ы , выпускники мат-меха!) д о л ж н ы ра¬
ботать в возможно более ш и р о к о м наборе направлений. Во-первых, это
интересно, во-вторых, таковы з а к о н ы науки, а в-третьих, это обеспечит
определенную стабильность, если что-то все-таки п о н е зависящим от нас
п р и ч и н а м или из-за нашей плохой работы н е оправдает надежд. В этом
случае маленький коллектив обанкротится и будет вынужден искать дру­
гие с п о с о б ы существования, а большие п р е д п р и я т и я это с п о к о й н о пе¬
реживут.
В к о н ц е к о н ц о в , я пришел к п о н и м а н и ю , что поддержка науки
не может быть выполнена на уровне спонсорской поддержки, на уровне
отдельных пожертвований. К а к и везде, нужна системность, нужна стру¬
ктура, нужны определенные «правила игры».
Сейчас я прилагаю много усилий для создания института, который
так и будет называться: научно-исследовательский институт и н ф о р м а ц и ­
онных технологий, входящий в структуру моего родного Санкт-Петер¬
бургского государственного университета. Я провел беседы со многими
исследователями нашего факультета, в частности, и с такими, которые
весьма далеки от практики, н о продуктивно работали в нашей области
и в computer science. М ы с н и м и наметили несколько направлений, в к о ­
торых исследования особенно важны сейчас, даже без стопроцентной
133

уверенности, что через два-три года они приведут к видимому результату,
который м о ж н о будет использовать. Я получил поддержку Ученого Сове¬
та факультета, хотя тоже не без вопросов. Вопросы были такие ж е , как
несколько лет назад, когда создавалась новая кафедра: «Зачем нужно еще
что-то новое? Нельзя ли обойтись старыми структурами?» Н о , тем не ме¬
нее, процесс идет.
Я надеюсь, что м н е удастся этот институт создать. Более того, под
этот пока не созданный институт я нашел западную к о м п а н и ю , которая
готова материально поддержать проект. Причем я их не обманывал. Я го­
ворил, что институт будет заниматься исследованиями и не обещал
немедленной прибыли. Тем не менее, крупные к о м п а н и и понимают, что
если поддержат исследования, то все равно получат выгоду. Если появит­
ся положительный результат, он, в первую очередь, будет применен в их
интересах. Это нормальный мировой процесс хоть в Западной Европе,
хоть в С Ш А . Л ю б о й ученый из любого университета до 40% своего време¬
н и тратит на п о и с к грантов, их обоснование. Н е считается зазорным де­
лать 3, 5, 10 попыток. В одном, в другом, в третьем фонде.
В первую очередь, нужна структура для такого поиска. Н у ж н ы спе­
циальные люди, которые следят, где объявлены гранты, где объявлены
программы, какие к н и м предъявляются требования. И м е н н о эти люди
д о л ж н ы оформлять бумаги. Сначала надо сообщить: «Коллеги! Есть та­
кие-то предложения. Требования такие-то, сроки такие-то». Специаль­
н ы е люди д о л ж н ы оформлять и рассылать бумаги (ученые не всегда удач­
но их оформляют). Должна вестись база данных: на что получен п о л о ж и ­
тельный ответ, какие замечания были, к а к на них реагировать. Этим
д о л ж н ы заниматься специально подготовленные люди, а не сами иссле­
дователи. И я думаю, что в н а ш е время научно-исследовательский и н с т и ­
тут — это как раз та структура, которая сможет сконцентрировать внутри
себя исследователей, обеспечить им определенную поддержку для того
чтобы получить финансирование, отслеживать сроки и этапы исследований.
Короче говоря, все должно быть сделано для того, чтобы ученые ма­
ксимум своего времени тратили на исследования, получали за это достой­
ную зарплату, чтобы не надо было «халтурить», отвлекаться на различные
работы. М е ш к и с картошкой и песком сейчас никто уже не грузит, но слу¬
чаи, когда заслуженные ученые, профессора вынуждены заниматься
неинтересной работой, далекой от науки, только для того, чтобы полу­
чить зарплату, я знаю. И х много.
Кто знает, каким получится этот институт? Н о я и с к р е н н е верю, что
институт с международным участием поможет тем ученым, которые пред¬
расположены к научной деятельности, не только выжить, но и активно
участвовать в развитии нашей л ю б и м о й науки.
134

Индустриальная программа подготовки
I T - к а д р о в на б а з е к а ф е д р ы
с и с т е м н о г о п р о г р а м м и р о в а н и я СПбГУ*'
Компания ЛАНИТ-ТЕРКОМ решает проблему нехватки кадров, еже­
годно набирая студентов в так называемые «студенческие проекты», которые
позволяют молодым специалистам получить бесценный опыт работы в реаль­
ных условиях, а компании — приобрести хорошо подготовленных сотрудни­
ков.
Проблема нехватки к в а л и ф и ц и р о в а н н ы х кадров в IT-индустрии
давно стала острой и часто обсуждаемой темой. Сегодняшний програм­
мист — вчерашний студент, а то, что существующая сегодня система выс­
шего образования н е отвечает потребностям индустрии разработки п р о ­
граммного обеспечения — факт известный и печальный. В вузах Петер­
бурга выжило н е более 5 п р и з н а н н ы х кафедр, готовящих 300-400 профес¬
сиональных программистов в год.
На протяжении последних трех лет к о м п а н и я Л А Н И Т - Т Е Р К О М с о ­
вместно с кафедрой системного программирования математикомеханического факультета С П б Г У проводит эксперимент с целью подго¬
товки высококвалифицированных IT-специалистов. Используются са­
м ы е разнообразные формы: дополнительные вечерние занятия, стипен¬
д и и , стажировки, работа студентов в инвестиционных проектах, наконец,
непосредственная работа на предприятии п о темам, которые близки н а ­
правлениям обучения на кафедре. Высокая востребованность выпускни¬
ков кафедры доказывает правильность выбранного подхода. М н о г и е сот¬
рудники Л А Н И Т - Т Е Р К О М (основу коллектива составляют выпускники
СПбГУ) преподают на кафедре, курируют студенческие проекты.
Таким образом, к о м п а н и я обеспечивает себе непрерывный приток
кадров из числа выпускников университета. П р и этом молодой специа¬
лист сразу может приступать к работе без дополнительного обучения.
Опыт участия в студенческих проектах на базе предприятия позволяет
еще во время обучения в вузе сориентировать молодого программиста на

* Доклад на всероссийской конференции «Преподавание информационных технологий в
России», г. Рыбинск (Ярославская область), 11-13 мая 2005 г.
135

интересующую его область IT, на актуальность того или иного направле¬
н и я , учит работе в команде и правилам производственного процесса.
В Л А Н И Т - Т Е Р К О М все департаменты п р и н и м а ю т активное уча¬
стие в подготовке студентов, что позволяет каждому студенту выбрать
наиболее близкое ему направление. В каждом департаменте выделяются
сотрудники, курирующие данную программу, все они являются выпуск¬
н и к а м и математико-механического факультета СПбГУ.
Для студентов ц и к л подготовки начинается на втором курсе. Обыч­
но я провожу общее собрание для всех студентов, желающих принять уча­
стие в программе, и знакомлю их с деятельностью ф и р м ы . Далее от каж¬
дого департамента выступают специалисты — потенциальные руководи¬
тели проектов. Студенты выбирают одно из направлений деятельности
к о м п а н и и и приступают к обучению. Обычно практическая работа пред­
варяется вводным курсом л е к ц и й , в ходе которого студентов знакомят со
с п е ц и ф и ч н ы м и для каждого направления темами. В результате этих лек­
ц и й часть студентов отсеивается. Кому-то из студентов не понравилось
выбранное направление, кто-то нашел работу и темы для исследований в
других местах, кто-то просто ленится. Студенты хотят поскорее присту­
пить к настоящей практической работе, за которой они собственно и п р и ­
ходят в к о м п а н и ю . Это понимают и кураторы проектов, поэтому такие
л е к ц и и длятся не больше 2-3 недель. Затем в течение нескольких месяцев
со студентами ведутся практические занятия, мало чем отличающиеся от
обычных студенческих семинаров, но ориентированные, прежде всего, на
практику.
В начале третьего курса студентам предлагаются исследовательские
проекты. Н и к т о не рассчитывает на создание продаваемых продуктов, ос¬
новная цель — обучение, но часто результаты студенческих проектов я в ­
ляются хорошими прототипами будущих реальных проектов. К а к прави­
ло, в проекте участвуют 10-12 студентов, из них 5-6 вносят основной
вклад в проект. В течение семестра каждый департамент ведет 2-3 проек¬
та в зависимости от потребностей предприятия и активности научных ру¬
ководителей. Руководители — молодые энергичные специалисты, желаю¬
щ и е получить опыт управления. Проекты длятся от 1 до 2-х семестров, в
результате студенты получают опыт п р о м ы ш л е н н о й разработки, реко¬
мендации на кафедру системного программирования, а также возмож¬
ность работать в Л А Н И Т - Т Е Р К О М .
Департаментам предоставляется определенная свобода в разработке
программ обучения и стратегии привлечения студентов. Поскольку сту¬
дентов на отделении ограниченное количество, между департаментами
существует конкуренция, и каждый департамент имеет свои уникальные
п р и е м ы работы со студентами и опыт привлечения их и м е н н о на свои н а ­
правления.
136

Так, для департамента аутсорсинга это н о в е й ш и е технологии, что, в
первую очередь, обусловлено с п е ц и ф и к о й работы самого департамента.
Особое в н и м а н и е уделяется изучению и м е н н о тех технологий, которые
планируется использовать в реализации проектов. Практикуются семина¬
р ы внутри департамента, где сотрудники ф и р м ы или студенты, участвую¬
щ и е в проектах, выступают с докладами, рассказывая коллегам и студен­
там о перспективных направлениях в отрасли. К а к правило, студенческие
проекты этого департамента находят п р и м е н е н и е внутри к о м п а н и и . П р и ­
мером является ряд проектов по созданию web-интерфейсов: от проекти­
рования web-интерфейса и обработки недельных отчетов сотрудников до
«Системы с web-интерфейсом для подведения результатов турниров по
настольному теннису», реализованных в разных популярных сегодня тех­
нологиях. В департаменте создана и совершенствуется база данных ре¬
зультатов всех студенческих проектов, система учета выведена на автома¬
тический уровень, что позволяет руководителям проектов более четко
планировать свою работу.
В департаменте р е и н ж и н и р и н г а студентов привлекает перспектива
работы со стабильными крупными зарубежными заказчиками, что я в л я ­
ется весомым аргументом для молодых специалистов. М н о г и е студенты,
участвующие в программе подготовки IT-специалистов, выбирают и м е н ­
но этот департамент. В качестве заданий здесь используются несложные
части реальных проектов. Студенты занимаются разработкой и тестиро¬
ванием синтаксических анализаторов, средств генерации, анализа гра¬
ф о в , оптимизаторов и т.п. П о о к о н ч а н и и работы студенты устраивают
презентацию полученного продукта. Руководители проекта считают, что
такая схема подготовки новых кадров для работы в департаменте весьма
удачна. В результате предыдущего цикла подготовки п р и н я л и активное
участие и успешно завершили проект 11 человек, из которых 7 остались
работать в департаменте р е и н ж и н и р и н г а .
В департаменте электронных систем в качестве задания студенты так¬
ж е работают с частью реального проекта или типичной небольшой зада¬
чей. Примером может служить проект «Аппаратное моделирование архи¬
тектур цифровых фильтров», работая над которым, студенты занимались
VHDL-программированием специализированного процессора. Результа¬
ты этого проекта в дальнейшем использовались в работе департамента.
Количество студентов, которых этот департамент может привлечь к рабо¬
те в студенческих проектах, в значительной мере ограничено необходимо¬
стью определенного количества специального оборудования и приборов.
С п е ц и ф и ч е с к о й особенностью работы в департаменте телекомму¬
н и к а ц и й является большой объем з н а н и й по этой отрасли, не входящих в
университетскую программу, что отпугивает часть студентов от данного
направления, но зато привлекает других. Важно подчеркнуть, что нас и н 137

тересуют «программистские» аспекты телекоммуникаций, но м ы н и в ко¬
ей мере не конкурируем с отраслевыми институтами.
В качестве основного проекта в этом году планируется развитие п р о ­
дукта Л А Н И Т - Т Е Р К О М — универсальной телефонной станции «Юнивер»
с функциями многоканального радиоудлиннителя абонентских телефон­
ных линий. В рамках студенческого проекта планируется реализация н о ­
вых функций этой станции. Ведутся также такие интересные студенческие
проекты, как: «Реализация протокола VXML» (оказание голосовых услуг
через Internet), «Синтез речи», «Сервер компьютерной и IP-телефонии».
Прежде чем студенты приступят к практическим занятиям, им пред­
стоит пройти значительный курс дополнительного обучения, в который
входят: S D L / M S C (для п о н и м а н и я алгоритмов), R T S T / R E A L (эти техно¬
логии разработки П О реального времени созданы в Л А Н И Т - Т Е Р К О М ) ,
курсы технологии сборки и отладки Ф П О .
К сожалению, даже такое крупное предприятие, как Л А Н И Т - Т Е Р К О М , штат которого насчитывает 300 человек, не может обеспечить от¬
дельного руководителя (тьютора) для каждого студента. Н о даже с груп­
пой из 4-5 студентов практическая работа несравненно э ф ф е к т и в н е й
классического университетского подхода. Студенты обучаются не только
научным и техническим приемам, но и умению работать в группе, плани¬
ровать работу, отвечать за сроки, результаты и бюджет. П о итогам первых
лет работы м о ж н о уверенно сказать, что такой симбиоз университетского
и практического образования позволяет готовить действительно сильных
специалистов. Однако возникли и проблемы:
1.
Вечерняя работа преподавателей и сотрудников оплачивается пред­
приятием, причем по достаточно высоким ставкам. Для студентов же
это обучение бесплатно. Необходимо иметь возможность заключения
определенного контракта с каждым обучаемым, в соответствии с кото¬
рым получивший дополнительное образование студент был бы обязан
отработать, скажем, 3 года на предприятии, которое финансировало
его образование. На данном этапе неясно, как гарантируются такие
контракты Российским законодательством. Иначе получается, что мы
готовим элитные кадры для работы на западные компании, представ­
ленные в России, т.к. они имеют возможность платить гораздо больше
(в Санкт-Петербурге — это Intel, Sun, HP, Motorola, Alcatel и т.п.). У нас
есть некоторые неэкономические средства — аспирантура, отсрочка от
армии, возможность заниматься наукой, поэтому процентов 70 обу­
ченных нами студентов остается работать на нашем предприятии, но
понятно, что нужны и более прямые экономические рычаги.
2.
В настоящее время многие толковые студенты приезжают с п е р и ф е ­
рии России и из стран бывшего СССР. Хотелось бы иметь возмож¬
ность оставить их работать без л и ш н и х бюрократических проблем.
138

3.

Часть студентов — из малообеспеченных семей, и вместо того, чтобы
совершенствовать свои профессиональные з н а н и я , о н и работают
разнорабочими и т.п., в особенности на младших курсах. М н о г и м из
них м ы предоставляем стипендии, н о , естественно, н а ш е предпри­
ятие не может заменить государство.
4.
В таких вопросах к а к разработка новых программ обучения, подго­
товка преподавателей для других вузов, н а п и с а н и е учебников и т.п.,
хотелось бы видеть более активное участие государства, например, в
виде адресных программ или целевых грантов.
На н а ш взгляд, н а к о п л е н н ы й н а м и опыт вполне может использо­
ваться и другими IT-предприятиями, и м е ю щ и м и тесные связи с универ­
ситетами. Во всяком случае, м ы всегда готовы поделиться методиками,
примерами решаемых задач и любой другой и н ф о р м а ц и е й . М ы понима¬
ем, что предлагаемый н а м и подход не может служить глобальным реше¬
н и е м проблемы — на все IT-предприятия университетов не хватит. М ы
уже начали прорабатывать вопрос р а с ш и р е н и я масштабов эксперимента
путем создания технопарка в Петергофе вокруг естественных факультетов
СПбГУ. На д а н н ы й момент с кафедрой системного программирования
взаимодействует 5-7 IT-предприятий, руководители которых когда-то за­
кончили мат-мех под м о и м научным руководством. Кафедра предостав­
ляет предприятиям возможность встреч со студентами, принимает в ка¬
честве курсовых и дипломных проектов работы, в ы п о л н е н н ы е под руко¬
водством сотрудников этих предприятий. Сотрудники предприятий ведут
занятия не только со «своими» студентами, но и с другими студентами ка­
федры, предоставляют свою технику, а самое главное, свои интересные
задачи и опыт их решения.
В настоящее время планируется строительство большого IT-технопарка в непосредственной близости от мат-меха в Петергофе. Имеется
договоренность с университетом о предоставлении и н ж е н е р н о обустро¬
е н н о й территории и с потенциальным инвестором. М ы стараемся дер­
жаться вне жарких споров различных министерств. Разумеется, предоста¬
вление налоговых скидок ускорит процесс строительства нашего и других
технопарков. М ы пока не ставим вопрос строительства технопарка в зави¬
симость от получения каких-то преференций, надеемся, что практически
бесконечный источник к в а л и ф и ц и р о в а н н ы х кадров, возможность разви¬
тия и использования новейших научных достижений в IT являются д о с ­
таточными аргументами как для большинства предприятий, работающих
в области IT, так и для инвесторов, ну а польза для университета предста­
вляется совершенно бесспорной.

139

Наукоград и технопарки в Петергофе
М н о г о лет назад было замечено, что концентрация многих высоко­
технологичных предприятий, Н И И различного п р о ф и л я и исследова¬
тельских лабораторий на сравнительно небольшой территории дает боль¬
ш о й эффект. Развитие науки, высоких технологий требует наличия боль¬
шого количества ученых, различных специалистов в одном месте, опреде¬
л е н н о й «критической массы» з н а н и й и умений. Полностью этот ф е н о м е н
объяснить достаточно трудно, хотя основные идеи понятны: научное об¬
щ е н и е , доведение идей до р е ш е н и й и продуктов, воспитание молодежи
на «живых» примерах и т.д. И м е н н о поэтому в С С С Р были созданы ака¬
демгородки на Урале, в С и б и р и , на Дальнем Востоке. В С Ш А классиче­
ским примером является знаменитая Силиконовая долина. Сразу заме¬
тим, что все известные центры такого рода создавались вокруг крупных
университетов, причем с обоюдной пользой — как для университета, так
и для предприятий и исследовательских центров.
В современной России законодательно определено понятие «Науко­
град». Если на территории муниципального образования валовый доход
научных предприятий превышает половину дохода всего м у н и ц и п а л ь н о ­
го образования или количество научных работников составляет более
25% от всех работающих, то такое образование может быть объявлено
«наукоградом». (На самом деле требований гораздо больше, но основная
идея понятна). Наукограды имеют определенные привилегии (например,
до половины федеральных налогов м о ж н о тратить прямо на месте), ф о р ­
мируется специальный госзаказ, короче, многое делается для развития
как территории в целом, так и отдельных предприятий.
К р о м е академгородков и наукоградов, в мире активно развиваются
технопарки. В п р и н ц и п е , большой р а з н и ц ы между этими п о н я т и я м и нет.
Технопарк часто ориентирован на одно научное направление, например,
и н ф о р м а ц и о н н ы е технологии ( И Т ) или биотехнологии, а наукоград
обычно носит более к о м п л е к с н ы й характер; технопарк — это отдельное
учреждение, а наукоград — это целое муниципальное образование. Хотя
бывают и многоцелевые технопарки (например, в Ф и н л я н д и и ) , часто тех­
нопарки тоже строят жилье для своих сотрудников, постепенно превра­
щаясь в целые городки.

140

В нашем случае будем для определенности считать, что Наукоград —
это муниципальное образование Петергоф, а в составе Наукограда стро¬
ятся технопарки с различными специализациями — ИТ, биотехнологии,
нанотехнологии, экологии и т.д. Наукоград создается и управляется д и ­
рекцией, которая планирует бюджет и контролирует его исполнение.
Стратегические цели Наукограда формулируются общественными сове­
тами. Одной из первоочередных задач д и р е к ц и и является строительство
и поддержание инфраструктуры (дороги, связь, транспорт, экологическая
обстановка, досуг и т.п.). Развитие каждого технопарка или отдельного
предприятия — задача их местного руководства, н о д и р е к ц и я Наукограда
обязана координировать их деятельность и всемерно способствовать
междисциплинарной кооперации.
Так что же такое «Технопарк»? Представьте себе небольшое (10-15 с о ­
трудников) предприятие. Такому предприятию трудно содержать квали¬
ф и ц и р о в а н н о г о системного администратора локальной сети и сервера ба¬
зы данных, юриста и т.д. Н а Западе в этой ситуации применяется out­
sourcing — использование ресурсов других организаций. Даже бухгалтерию
для маленьких предприятий ведут крупные специализированные органи¬
зации. У нас в России классический аутсорсинг н е с л и ш к о м развит, более
того, это п о н я т и е «оккупировано» предприятиями, в ы п о л н я ю щ и м и зака­
зы п о программированию иностранных к о м п а н и й . Тоже, разумеется, аут¬
сорсинг, н о только в одном из возможных смыслов. Технопарки призваны
вернуть п о н я т и ю «аутсорсинг» первоначальный смысл, т.е. брать на себя
заботы многих организаций, работающих в технопарке.
Прежде всего, технопарк должен иметь большой д о м или несколько
домов.
Очень хорошо, если технопарк может предоставлять и жилье по в ы ­
годным для сотрудников ипотечным схемам; программисты обычно хо¬
р о ш о зарабатывают, поэтому оформление ипотеки может быть упрощено.
Должна быть обеспечена охрана, телефоны, Internet. ИТ-технопарк
должен обеспечивать серверы, локальные сети, брандмауэры, хороших
сисадминов. Один м о й з н а к о м ы й бизнесмен образно охарактеризовал
ИТ-технопарк так: «все п о м е щ е н и я там д о л ж н ы иметь фальшпол». О н
имел в виду просто легкость реконструирования локальных сетей, н о в од¬
н о й фразе выразил необходимость «заточенности» п о м е щ е н и й и м е н н о на
IT-индустрию.
Однако сдача в аренду площадей н е является единственной деятель¬
ностью технопарка. Технопарк должен иметь м о щ н у ю юридическую
службу (иностранные контракты, трудовые соглашения, вопросы интел­
лектуальной собственности и т.п.). Большую пользу и прибыль может
принести специальная служба п о организации ш к о л , выставок, к о н ф е ­
р е н ц и й . Технопарк должен иметь большие и малые к о н ф е р е н ц - з а л ы с с о 141

ответствующим оборудованием. Очень важно иметь спортзал и открытые
спортивные площадки. Нельзя забывать о буфетах, к а ф е и об организа¬
ц и и досуга.
М н о г и е технопарки мира имеют в своем составе венчурные ф и р м ы ,
поддерживающие новые оригинальные идеи и помогающие довести их до
продаваемого продукта. Неотъемлемой частью любого технопарка я в л я ­
ются службы, занимающиеся поиском и переподготовкой кадров, серти¬
ф и ц и р о в а н н ы м и авторизованным обучением, сертификацией, поставка¬
ми компьютеров, сетевого оборудования, расходных материалов и т.п.
Разумеется, перечисленный список предоставляемых услуг не я в л я ­
ется исчерпывающим. Администрация технопарка должна быть доста­
точно оперативной и гибкой: возникла какая-то новая потребность (на­
пример, обслуживание бухгалтерии, ф и н а н с о в ы й аудит, IP-телефония,
call-центры) — нужно оперативно предоставить и эти услуги.
Технопарк, предоставляющий весь комплекс услуг (а не только арен­
ду п о м е щ е н и й ) , является прибыльным предприятием. В этом заключает­
ся интерес инвесторов, которые вкладывают деньги в строительство тех¬
нопарка.
Предприятия «кучкуются» в технопарке, так к а к ж и з н ь сильно упро­
щается — не нужно за каждой отдельной услугой бегать по всему городу. Од­
нако главное, зачем предприятия (особенно молодые) стремятся в техно­
парки — это кадры. Обычно технопарки располагаются в непосредствен¬
ной близости от университетов. Если между технопарком и университе¬
том расстояние, которое м о ж н о преодолеть за 10-15 минут п е ш к о м , сот­
рудников п р о м ы ш л е н н ы х предприятий м о ж н о привлечь к преподаванию
в университете. Особенно важна такая п о м о щ ь в организации практики,
руководстве курсовыми и д и п л о м н ы м и работами.
Многолетний опыт показывает, что если студент, начиная с третьего
курса, пишет курсовые, работает, получая приличную зарплату, наконец,
пишет дипломную работу на каком-то предприятии, то после о к о н ч а н и и
университета он с большой вероятностью останется работать на этом
предприятии. Такие сотрудники с существенно большей вероятностью
закрепляются на предприятии, чем сотрудники, п р и ш е д ш и е «с улицы».
Н е будем забывать, что даже для высокопрофессиональных специалистов
со стороны требуется время для «доводки».
Не менее важной, чем приток кадров, причиной для многих IT-предприятий, работающих в технопарке, является возможность «держать руку
на пульсе» новейших научных разработок, результатов апробации новых
технологий, возможность заказать необходимое исследование, причем
и м е н н о тем кафедрам и профессорам, которые хорошо известны пред¬
приятиям.

142

Н а ц и о н а л ь н ы е ч е р т ы п р о и з в о д с т в а ПО
Понять свою уникальность м о ж н о только сравнивая себя с кем-то.
Р а н ь ш е нас учили, что отечественное — значит отличное. М ы видели, что
сильно отличаемся от американцев, а про себя отмечали, что порой н е
в лучшую сторону..
Я хорошо п о м н ю , к а к начиналось сотрудничество с американцами
в 1992 году. С самого начала о н и признавали н а ш е преимущество в созидательности (модном сегодня понятии "creativity"), в уровне образования,
общей математической культуре. Сразу ж е обнаружились и н а ш и основ¬
н ы е проблемы: плохо работающая почта (электронной почты тогда еще
не было), резкое несоответствие технического о с н а щ е н и я у нас и в Аме¬
р и к е , недоступность новых технологий и даже их описаний. П е р в ы й в на¬
шей организации факс м н е привезли итальянцы в 1993 году. Специаль¬
ную рулонную бумагу к нему в России приобрести было очень трудно.
М ы осознавали, чему н а м стоит поучиться у западных коллег. Что
такое п л а н и р о в а н и е , м ы , разумеется, знали. Н о были и с к р е н н е убежден ы ( и обстоятельства того времени располагали к такому м н е н и ю ) что де¬
тальное п л а н и р о в а н и е на год — это шарлатанство. Сдвиги сроков испол¬
н е н и я квартального заказа на 1-2 недели были н о р м о й . П о н я т и я п л а н и ­
р о в а н и я р и с к о в для нас н е существовало. Пользу регулярных недельных
отчетов м ы осознали только через несколько лет. Д о этого м ы к н и м от¬
носились к а к к блажи заказчика, неизбежной в процедуре получения от
него вознаграждения. То ж е м о ж н о сказать и о базе данных о ш и б о к , где
из года в год накапливаются все серьезные и мелкие недочеты. И м е н н о
а м е р и к а н ц ы объяснили м н е , что если к а к о й - т о сотрудник сделал много
о ш и б о к в течение недели, это е щ е ничего н е значит. Такая нестабиль¬
ность может быть обусловлена проблемами личного характера. Н о если
один программист в течение 5-10 недель допускает в 5 раз больше о ш и ­
бок, чем другой, то п о этому факту уже м о ж н о судить о способностях ка¬
ждого и з них п р и наличии достоверной статистики. Так, о с н о в н о й проб¬
лемой стало н а ш е воспитание, склад ума. Нашему программисту ничего
н е стоило забыть ответить н а запрос в тот ж е день. Более того, когда аме¬
р и к а н ц ы устраивали по этому поводу скандал, я про себя думал: «чего
прицепились...». Все эти недочеты м ы исправляли, руководствуясь опы¬
том западных коллег.
143

Постепенно н а м удалось наладить процесс производства П О в точ¬
ности так, к а к это принято у американцев. Н о вместе с тем стала очевид­
на и обратная сторона медали. Современному молодому сотруднику
с двухлетним опытом работы в жесткой производственной структуре на¬
чинает казаться, что, к р о м е в ы п о л н е н и я правил игры, от него ничего н е
требуется. Редко кто из молодежи проявляет инициативу, предлагает ва­
р и а н т ы рационализации процесса, хотя это было естественно для моло­
дого поколения 30 лет назад. И уж н и к а к нельзя опустить я в н ы й м е р к а н ­
тилизм: очень часто предложение о небольшом п о в ы ш е н и и зарплаты я в ­
ляется для молодых сотрудников достаточным поводом для того, чтобы
сменить работу. Аргументом служит: «А что, в Америке принято раз в год
менять работу и переезжать из штата в штат, почему у нас должно быть
по-другому?» С другой стороны, такой борьбе за «рубль подлиннее» спо¬
собствовала и общая нищета в стране. Отсутствие государственной под¬
держки индустрии в целом спровоцировало ситуацию, когда н а ш и элит¬
н ы е вузы готовили специалистов высшей к в а л и ф и к а ц и и для приходящих
на н а ш р ы н о к западных к о м п а н и й , способных предложить достойный
уровень заработной платы. Р о с с и й с к и м производителям П О при этом о с ­
тавалось довольствоваться тем, что осталось, хотя немалый вклад в подго¬
товку будущих специалистов внесли и м е н н о о н и .
На м о й взгляд, корень проблемы — и м е н н о в слепом следовании
американскому опыту. Если м ы выберем этот путь — м ы всегда гаранти¬
рованно будем отставать в организации производства П О на 10-15 лет.
Нужно стараться выявить н а ш и преимущества, четко их сформулировать,
развивать коллективизм в работе, сделав основную ставку на образование
и способность самостоятельно созидательно мыслить.
В Америке я много раз сталкивался с ситуацией, когда разработчик,
с и д я щ и й за соседним столом, н е хочет потратить 5 минут, чтобы объяс­
нить тебе что-то. Там это называется job security. Сегодня я тебе что-то
объясню, завтра т ы станешь лучше, ч е м я , а послезавтра меня выгонят...
Хочется верить, что эта американская черта н е приживется в нашей дей¬
ствительности.
Я много лет играл в баскетбол. Тренеры учат, ч т о основное в н и м а н и е
надо уделять ш л и ф о в к е своих сильных сторон, а н е тратить время на ос¬
воение того, что т ы н е выучил в детстве. Я думаю, что эта мысль приме¬
н и м а и в нашем случае. Неистовое стремление «стать похожими» только
отдалит нас от возможности быть уникальными. Пытаясь равняться на
и н д и й с к и е software house или довольно безликие американские програм­
мистские организации, м ы потеряем свое л и ц о и потенциальную возмож­
ность занять достойное место в мировой индустрии П О .

144

Говорят к о л л е г и . И г о р ь А г а м и р з я н :
Профессор Андрей Николаевич Терехов — удивительный человек,
з а н и м а ю щ и й совершенно уникальное место на р о с с и й с к о м р ы н к е ин¬
ф о р м а ц и о н н ы х технологий. Судьба свела меня с н и м 30 лет назад, когда я
учился на математико-механическом факультете ЛГУ (Санкт-Петербург­
ского, а в то время Ленинградского — государственного университета), а
Андрей Николаевич (совсем молодой, недавний выпускник мат-меха и
даже еще не кандидат наук) возглавлял небольшую группу в лаборатории
системного программирования, где в это время шла работа над трансля­
тором с Алгола-68 для Е С Э В М . Уже тогда я почувствовал его отличие от
других н а ш и х преподавателей (а преподавательский состав на мат-мехе
того времени был очень сильным) — Терехов был твердо уверен, в том, что
о н программист-практик, и учил студентов (с которыми любил работать,
и аккуратно отбирал лучших) не теории, а практическим навыкам и при¬
емам. П р и этом и м е н н о под его влиянием теория, обильно вливаемая в
н а ш и головы на лекциях, оседала и кристаллизовывалась. Очень часто у
меня складывалось впечатление, что это происходило только с н а м и , с
той небольшой группой, которая работала с Тереховым — у многих других
н а ш и х соучеников теория так и оставалась в «жидком виде».
Парадокс, однако, заключается в том, что на самом деле Андрей Н и ­
колаевич всегда был скорее теоретиком и методологом, нежели настоя­
щ и м практиком. Несмотря на то, что на протяжении всей своей творче¬
ской биографии Терехов работал в сугубо практических проектах, в совет¬
ское время ориентированных в первую очередь на оборонную п р о м ы ш ­
ленность и программирование систем связи, а в пост-советское — на ком¬
мерческие программные продукты, о н всегда привносил в них глубокий
теоретический и методический базис. И зачастую оказывалось, что фор¬
мируемая методика (почти никогда не формализованная, а существую­
щая в виде историй, баек и анекдотов) имела большую ценность, чем ре¬
зультат проекта сам по себе.
Сегодня трудно говорить о программировании как науке. С другой
стороны, проводимый многими с легкой руки Дональда Кнута подход к
программированию как к искусству, тоже себя изжил. За последние 30 лет
программирование прошло через стадию ремесла, и в последнее десяти­
летие в крупных софтверных компаниях стало выходить на уровень ф а б 145

р и ч н о г о производства. И и м е н н о на этом этапе теоретико-методологиче¬
ский подход к созданию программного продукта оказывается необыкно¬
венно востребованным.
За плечами Андрея Николаевича Терехова — не только ряд успешных
(а иногда и неуспешных) проектов, не только 30 лет преподавательской
работы в университете и опыт руководства исследовательской лаборато¬
рией и кафедрой, но и сформировавшаяся за эти годы уникальная науч­
но-практическая школа программирования, успешность которой под­
тверждается и в ы п о л н е н н ы м и проектами, и победами студенческих к о ­
манд в олимпиадах по программированию, и просто теми к о м п а н и я м и , в
которых работают ученики Терехова. В каком-то смысле предлагаемая
в н и м а н и ю читателя книга как раз и отражает дух этой ш к о л ы — прагма¬
т и ч н ы й , не очень ф о р м а л ь н ы й , со ставкой на сочетание индивидуально¬
го блеска и э ф ф е к т и в н о й командной работы. А вдумчивый читатель уви¬
дит за интересными историями глубокие методологические п р и н ц и п ы как в свое время м ы , первые ученики Андрея Николаевича, за байками и
приемами находили те самые неочевидные связи между теоретическими
результатами и потребностями практики.
Игорь Агамирзян,
Директор по стратегии Microsoft в России и СНГ

146

Говорят к о л л е г и . В а л е н т и н М а к а р о в :
Дорогие читатели, перед вами книга, написанная замечательным ч е ­
ловеком, сумевшим совместить в себе талант преподавателя, ученого,
п р о м ы ш л е н н о г о разработчика программного обеспечения и бизнесмена.
И в каждой сфере своей деятельности Андрей Николаевич достигал неви­
данных успехов. Заведующий кафедрой на знаменитом мат-мехе Петер¬
бургского Государственного Университета, директор созданного им са¬
м и м Института И н ф о р м а ц и о н н ы х Технологий СПбГУ, создатель и глав¬
н ы й архитектор целой серии блестящих аппаратных и программных ком¬
плексов и генеральный директор одной из самых известных петербург¬
ских к о м п а н и й разработчиков программного обеспечения — все это один
человек — Андрей Терехов. Если прибавить к этому поразительные успе¬
хи, достигнутые его детьми — Андреем и К а р и н о й — в той же сфере и н ­
ф о р м а ц и о н н ы х технологий, то м о ж н о прямо признать, что перед вами —
легендарная фигура российской индустрии разработки программного
обеспечения, настоящий классик и верный кандидат на звание «нацио­
нального достояния».
Андрей Николаевич начал свою карьеру в советское время и был из
тех, кто участвовал в ф о р м и р о в а н и и самого понятия «советской вычисли¬
тельной техники». Затем в труднейшие годы перестройки он сумел соз¬
дать при Университете жизнеспособную структуру для промышленного
программирования, которая буквально спасла от отъезда с Р о д и н ы в н и ­
куда сотни блестящих российских программистов, дав им возможность
зарабатывать своей профессией, оттачивать знания и применять их для
р е ш е н и я сложнейших математических задач.
Затем в к о н ц е 1990-х он сделал, пожалуй, самое главное дело для ста­
новления российской индустрии разработчиков программного обеспече­
н и я , отдав много сил и энергии созданию и взрослению Консорциума
«Форт Росс». Его вклад в н а ш е обще дело был оценен коллегами, избрав­
ш и м и его Председателем Правления общероссийской организации п р о ­
граммистских к о м п а н и й , в которую превратился «Форт Росс» — Неком¬
мерческого Партнерства РУССОФТ.
Для чего я перечисляю заслуги Андрея Николаевича? Для того что¬
бы вы, любезные читатели, правильно подошли к прочтению этой книги.
В ней вы найдете фантастическое соединение академического подхода к
147

построению изложения, выстраданный опыт организации процесса раз­
работки программного обеспечения, аналитический научный подход к
выявлению проблем и поиску их р е ш е н и й — и замечательный юмор, поз­
в о л я ю щ и й читать книгу как увлекательную повесть, усваивая материал
даже на подсознательном уровне.
Читайте эту книгу, работайте над собой, старайтесь взять на воору¬
ж е н и е идеи автора и — идите дальше, ставьте новые задачи и и щ и т е их ре¬
ш е н и я . Н е боги горшки обжигают. Предлагаемая вам книга создает уве­
ренность в силах человека, крепко стоящего на своей земле и о п и р а ю щ е ­
гося на свою школу. И это, пожалуй, еще одно из замечательных качеств
и предназначений этой книги.
Валентин
Макаров,
Президент Некоммерческого Партнерства
программного обеспечения РУССОФТ

148

разработчиков