Ocenite etot tekst:


---------------------------------------------------------------
     THE MYTHICAL MAN-MONTH
     (Essays on Software Engineering)
     ADDISON-WESLEY PUBLISHING COMPANY READING 1975

     Copyright  (c)   1975  by  Acldison-Wesley   Publishing  Company,  Inc.
Philippines;  Copyright  1975  by  Addison-Wesley Publishing  Company,  Inc.
Copvrisht (c) 1972 by Frederick P. Brooks, Jr.
     OCR, formating: Jek , Alex Buloichik
---------------------------------------------------------------




     Posvyashchenie izdaniya 1975 goda
     Posvyashchaetsya  dvoim lyudyam,  blagodarya  kotorym  moi gody  v  IBM  byli
osobenno nasyshchennymi: Tomasu  Dzh.  Uotsonu Mladshemu, ch'e glubokoe vnimanie k
lyudyam  po-prezhnemu  oshchushchaetsya v  ego firme,  i Bobu  O.  |vansu, ch'e  smeloe
rukovodstvo prevratilo rabotu v priklyuchenie.
     Posvyashchenie izdaniya 1995 goda
     Posvyashchaetsya Nensi, Bozh'emu daru dlya menya.
     Predislovie k izdaniyu 1995 goda
     K moemu  udivleniyu i udovol'stviyu, "Mificheskij cheloveko-mesyac" ostaetsya
populyarnym  cherez 20 let posle vyhoda.  Tirazh prevysil 250 000  ekzemplyarov.
Menya chasto  sprashivayut, kakie  iz ocenok  i  rekomendacij, izlozhennyh v 1975
godu, ya po- prezhnemu schitayu vernymi, a kakie preterpeli izmeneniya, i  v  chem
imenno. Nesmotrya  na to,  chto  v moih  lekciyah  etot vopros vremya ot vremeni
zatragivaetsya, ya davno zhdu vozmozhnosti izlozhit' ego v pechatnom vide.
     Piter   Gordon   (Peter   Gordon),   yavlyayushchijsya   sejchas   sovladel'cem
izdatel'stva Addison-Wesley,  terpelivo i s  pol'zoj sotrudnichaet so mnoj  s
1980  goda.  On  predlozhil  podgotovit'  yubilejnoe  izdanie.  My  reshili  ne
ispravlyat' original, a perepechatat' ego v neprikosnovennosti, za isklyucheniem
obychnyh opechatok, i dopolnit' myslyami, voznikshimi v bolee pozdnee vremya.
     V  glave 16 perepechatyvaetsya stat'ya "Serebryanoj  puli net:  sushchnost'  i
akcidenciya v  programmnoj  inzhenerii", opublikovannaya  IFIPS  (Mezhdunarodnaya
federaciya  obshchestv  po   obrabotke  informacii)  v  1986  godu  i  yavivshayasya
rezul'tatom  opyta,  poluchennogo  mnoyu vo  vremya  rukovodstva  issledovaniem
ispol'zovaniya  programmnogo obespecheniya  v  voennyh oblastyah, provodivshegosya
Voennym komitetom po  nauke. Moi soavtory po etomu issledovaniyu, a takzhe nash
ispolnitel'nyj sekretar' Robert L. Patrik, okazali mne neocenimoe sodejstvie
v moem  vozvrashchenii k krupnym prakticheskim programmnym proektam. Stat'ya byla
perepechatana  v  izdanii  IEEE  "Computer"  v 1987 godu, blagodarya  kotoromu
poluchila shirokuyu izvestnost'.
     Stat'ya "Serebryanoj puli net" byla  derzkoj. V  nej predrekalos', chto  v
techenie   blizhajshego  desyatiletiya  ne  vozniknet  metodov  programmirovaniya,
ispol'zovanie    kotoryh    pozvolit    na    poryadok    velichin    povysit'
proizvoditel'nost' razrabotki  programmnogo obespecheniya  pri  prochih  ravnyh
usloviyah.  Do   konca   etogo  desyatiletiya  ostalsya  god,  i,   pohozhe,  moe
predskazanie  sbylos'. Stat'ya  vyzvala bolee  ozhivlennuyu diskussiyu v pechati,
chem "Mificheskij  cheloveko-mesyac", poetomu  v glave  17 soderzhatsya  otvety na
nekotorye  iz  opublikovannyh  kriticheskih  zamechanij,  a  takzhe  utochnyayutsya
vzglyady, izlozhennye v 1986 godu.
     Pri  podgotovke retrospektivnogo  analiza i utochneniya knigi "Mificheskij
cheloveko-mesyac"  ya byl udivlen  tem, kak malo soderzhavshihsya v nej  zayavlenij
podverglos'  kritike  -  kak  iz  chisla  dokazannyh,   tak  i  oprovergnutyh
posleduyushchim  opytom  i  issledovaniyami  v  oblasti  razrabotki  programmnogo
obespecheniya.  Mne  pokazalos'  poleznym  sistematizirovat' eti  zayavleniya  v
chistom vide, bez  soputstvuyushchih dokazatel'stv i  dannyh.  YA vklyuchil  v knigu
etot ocherk v kachestve glavy  18, nadeyas', chto eti chistye utverzhdeniya vyzovut
poisk  argumentov i faktov dlya dokazatel'stva,  oproverzheniya, peresmotra ili
utochneniya.
     Glava  19   sobstvenno   i  predstavlyaet   soboj  popytku  peresmotret'
iznachal'nye utverzhdeniya. Sleduet predupredit' chitatelya, chto izlagaemye novye
vzglyady  daleko  ne v toj mere  podkrepleny "boevym opytom", kak  eto bylo v
pervoj  chasti  knigi.  Delo  v  tom, chto  v  poslednee  vremya  ya  rabotal  v
universitetskoj srede,  a  ne  v  promyshlennosti, i  nad  nebol'shimi,  a  ne
krupnomasshtabnymi    proektami.   S   1986    goda   ya   zanimayus'    tol'ko
prepodavatel'skoj   deyatel'nost'yu   v   oblasti    razrabotki   programmnogo
obespecheniya, no ne issledovaniyami v nej. Moya issledovatel'skaya rabota bol'she
kasaetsya virtual'nyh sred i ih primenenij.
     Pri  podgotovke  dannoj retrospektivy  ya  pointeresovalsya  sovremennymi
vzglyadami   svoih   druzej,   kotorye  prakticheski   zanimayutsya  razrabotkoj
programmnogo obespecheniya.  V chislo teh, pered  kem ya v dolgu  za  gotovnost'
podelit'sya  svoimi  vzglyadami, sdelat' poleznye zamechaniya k  pervonachal'nomu
tekstu i usovershenstvovat'  moe obrazovanie, vhodyat Barri Bem (Barry Boehm),
Ken  Bruks  (Ken  Brooks),  Dik Kejs  (Dick  Case),  Dzhejms  Koggins  (James
Coggins),  Tom Demarko (Tom  DeMarco),  Dzhim  Makkarti (Jim McCarthy), Devid
Parnas  (David Parnas),  |rl  Uiler (Earl Wheeler) i  |dvard Jordon  (Edward
Yordon).  Fej  Uard  (Fay  Ward)  prekrasno  vypolnila  tehnicheskuyu  rabotu,
svyazannuyu s izdaniem novyh glav.
     YA blagodaren  moim  kollegam iz Gruppy po  programmnomu obespecheniyu dlya
voennyh celej Voennogo komiteta po nauke  Gordonu Bellu (Gordon Bell), Bryusu
B'yukenenu (Bruce  Buchanan),  Riku  Hejz-Rotu (Rick  Hayes-Roth)  i osobenno
Devidu  Parnasu - za ih plodotvornye idei, a Rebeke Birli (Rebekah Bierly) -
za  podgotovku  k  pechati  stat'i, opublikovannoj  v dannoj knige v kachestve
glavy 16. Analiz problem programmirovaniya v  kategoriyah "sushchnost'" (essence)
i   "akcidenciya"   (accident)   vozniklo  blagodarya  Nensi   Grinvud  Bruks,
ispol'zovavshej  takoj analiz v  stat'e  ob obuchenii igre  na skripke metodom
Suzuki.
     Obychai izdatel'stva Addison-Wesley  ne pozvolili mne  v  predislovii  k
izdaniyu 1975 goda vyrazit'  blagodarnost' ego sotrudnikam  za sygrannuyu  imi
vazhnuyu rol'. Sleduet osobenno otmetit' vklad dvuh  chelovek: Normana Stentona
(Norman  Stenton), yavlyavshegosya  otvetstvennym redaktorom,  i Gerberta  Bouza
(Herbert  Boes),  byvshego hudozhestvennym  redaktorom.  Bouz  sozdal  izyashchnyj
stil',  osobo  otmechennyj  odnim  iz recenzentov: "shirokie polya i tvorcheskoe
ispol'zovanie shriftov i komponovki materiala". CHto eshche vazhnee, on dal vazhnyj
sovet pomestit' v nachale kazhdoj glavy svoyu kartinku. (V to vremya u menya byli
tol'ko kartinki Smolyanyh yam  i Rejmskogo  sobora.) CHtoby najti vse kartinki,
mne potrebovalsya celyj god, no ya beskonechno blagodaren za sovet.
     Soli  Deo  gloria - Bogu  edinomu  slava! F. P.  B.,  Jr.  CHapel  Hill,
Severnaya Karolina
     Mart 1995
     Predislovie k pervomu izdaniyu
     Vo   mnogih  otnosheniyah   upravlenie  bol'shim  proektom   razrabotki
programmnogo obespecheniya  analogichno lyubomu  drugomu  krupnomu nachinaniyu - v
bol'shej  mere, chem obychno schitayut programmisty. Odnako vo  mnogih otnosheniyah
imeet otlichiya -  v  bol'shej  mere,  chem obychno predpolagayut professional'nye
menedzhery. Idet process  nakopleniya professional'nyh znanij v  etoj oblasti.
Sostoyalos'   neskol'ko  konferencij,  zasedanij   na   konferenciyah   AFIPS,
opublikovano  neskol'ko knig i  statej. No znaniya  eshche ne  oformilis'  v tom
vide,  kogda  ih  mozhno sistematicheski  izlozhit'  v  uchebnike. Tem ne menee,
predstavlyaetsya  umestnym  predlozhit'  etu   nebol'shuyu   po   ob®emu   knigu,
otrazhayushchuyu, v osnovnom, moi lichnye vzglyady.
     Moe professional'noe stanovlenie v vychislitel'noj tehnike pervonachal'no
bylo svyazano s programmirovaniem,  odnako v  period 1956-1963  godov,  kogda
razrabatyvalis' avtonomnye upravlyayushchie programmy i yazyki  vysokogo urovnya, ya
zanimalsya, v  osnovnom,  arhitekturoj komp'yuterov. Kogda v 1964 godu ya  stal
menedzherom proekta razrabotki  Operating System/360,  to obnaruzhil,  chto mir
programmirovaniya  sovershenno izmenilsya  blagodarya  uspeham,  dostignutym  za
neskol'ko poslednih let.
     Rukovodstvo razrabotkoj  OS/360 bylo  ochen' pouchitel'nym, hotya i polnym
rasstrojstv.  Komande  razrabotchikov, v  tom  chisle  smenivshemu  menya F.  M.
Trapnellu (F. M.  Trapnell), mozhno  mnogim gordit'sya. Sistema soderzhit mnogo
otlichnyh  reshenij v konstrukcii i funkcionirovanii,  i ej  udalos'  poluchit'
shirokoe  rasprostranenie.  Nekotorye  idei,  v pervuyu  ochered',  organizaciya
vvoda/vyvoda, nezavisimaya  ot ustrojstv,  i upravlenie vneshnimi bibliotekami
stali tehnicheskimi novinkami, nyne shiroko  ispol'zuemymi. Sejchas eta sistema
vpolne nadezhna, dostatochno proizvoditel'na i ves'ma gibka.
     Odnako  proekt  nel'zya  nazvat'  vpolne uspeshnym. Vsyakomu  pol'zovatelyu
OS/360 bystro stanovitsya yasno, naskol'ko luchshe mogla by byt' sistema. Oshibki
proektirovaniya i realizacii osobenno zametny v upravlyayushchej programme, a ne v
kompilyatorah  yazykov.  Bol'shaya  chast'  etih  proschetov  otnositsya  k periodu
1964-65 godov i potomu dolzhna byt' otnesena na moj schet. Bolee togo, sistema
vyshla s  zaderzhkoj, potrebovala bol'she pamyati, chem predpolagalos', stoimost'
razrabotki v neskol'ko  raz prevysila  zaplanirovannuyu, i  pervye  neskol'ko
versij funkcionirovali ne slishkom udachno.
     Pokinuv v 1965 godu IBM i pridya v CHepel Hill, kak eto i predpolagalos',
ya vozglavil  razrabotku OS/360  i  stal  analizirovat' opyt etoj razrabotki,
chtoby  izvlech'  uroki  tehnologicheskih  reshenij   i   administrirovaniya.   V
chastnosti,  ya  hotel   ponyat',   pochemu   stol'  razlichnym   okazalsya   opyt
administrirovaniya  pri  razrabotke  apparatnoj  chasti  System/360,  s  odnoj
storony,  i  sozdanii  operacionnoj  sistemy OS/360  - s  drugoj. |ta  kniga
yavlyaetsya zapozdalym otvetom na voprosy  Toma Uotsona otnositel'no  trudnosti
upravleniya razrabotkoj programm.
     V reshenii etoj zadachi ya poluchil bol'shuyu pol'zu ot dlitel'nogo obshcheniya s
R. P. Kejsom (R. P. Case), pomoshchnikom menedzhera proekta v 1964-65  godah,  i
F. M. Trapnellom, menedzherom proekta v 1965-68  godah. YA obsudil svoi vyvody
s  menedzherami  drugih krupnyh programmnyh  proektov, v  tom  chisle  F.  Dzh.
Korbato (F. J. Corbato) iz  MTI, Dzhonom Harrom (John Harr) i V. Vysockim (V.
Vyssotsky)  iz Bell  Telephone  Laboratories,  CHarl'zom  Portmanom  (Charles
Portman)   iz   International  Computers   Limited,   A.   P.   Ershovym   iz
Vychislitel'nogo  centra Sibirskogo otdeleniya Akademii nauk SSSR, a  takzhe A.
M. P'etrasanta (A. M. Pietrasanta) iz IBM.
     Sobstvennye  moi   vyvody   soderzhatsya   v   sleduyushchih  nizhe   ocherkah,
prednaznachennyh professional'nym programmistam, professional'nym  menedzheram
i osobenno professional'nym menedzheram v programmirovanii.
     Hotya kniga napisana kak  otdel'nye ocherki, u nee est' central'naya tema,
izlagaemaya  v  glavah  2-7.  Vkratce  moe  mnenie  zaklyuchaetsya  v  tom,  chto
trudnosti,  ispytyvaemye  pri upravlenii  krupnymi  programmnymi  proektami,
inogo  roda,  nezheli  pri upravlenii  nebol'shimi  proektami, chto  svyazano  s
problemami  razdeleniya   truda.  YA  schitayu  vazhnejshej   zadachej   sohranenie
konceptual'noj  celostnosti  samogo  produkta.  V  etih  glavah  obsuzhdayutsya
trudnosti, voznikayushchie na puti k etomu edinstvu, i sposoby ih preodoleniya. V
glavah, sleduyushchih za nimi, obsuzhdayutsya drugie aspekty upravleniya razrabotkoj
programmnogo obespecheniya.
     Imeyushchayasya  po  etoj  teme  literatura  ne  slishkom  bogata,  no  ves'ma
raspylena.  Poetomu  ya postaralsya  vklyuchit'  ssylki na  literaturu,  kotorye
pomogut  osvetit'  otdel'nye voprosy i  otoshlyut zainteresovannogo chitatelya k
drugim  poleznym  rabotam.  Rukopis'  knigi  prochli  mnogie  moi  druz'ya,  i
nekotorye iz  nih sdelali  prostrannye i poleznye zamechaniya.  V teh sluchayah,
kogda, nesmotrya na cennost', oni ne vpolne vpisyvalis' v tekst, ya vklyuchal ih
v primechaniya.
     Poskol'ku eta kniga predstavlyaet  soboj sbornik  ocherkov, a  ne  edinyj
tekst,  vse ssylki  i  primechaniya vyneseny v konec,  i  chitatelyu  pri pervom
chtenii mozhno ih propustit'.
     YA gluboko  priznatelen miss Sare |lizabet Mur (Sara  Elizabeth  Moore),
misteru  Devidu  Vagneru (David Wagner) i  missis  Rebekke  Berris  (Rebecca
Burris) za  pomoshch' v podgotovke dannoj rukopisi, a  takzhe professoru Dzhozefu
Slounu (Joseph C. Sloane) za sovety v otnoshenii illyustracij.
     F. P. B., Jr.
     CHepel Hill, Severnaya Karolina
     Oktyabr' 1974





    Glava 1. Smolyanaya yama

     Een Schip op bet strand is een baken in zee.
     [Korabl' na meli - moryaku mayak.]
     GOLLANDSKAYA POSLOVICA
     Samaya yarkaya scena  doistoricheskih vremen - bor'ba ogromnyh zhivotnyh so
smert'yu  v smolyanyh  yamah. Voobrazhenie predstavlyaet dinozavrov,  mamontov  i
sablezubyh tigrov, pytayushchihsya vysvobodit'sya iz smoly. CHem otchayannej  bor'ba,
tem  sil'nee zatyagivaet  smola,  i kak by ni  byl  silen ili  lovok zver', v
konechnom itoge emu ugotovana gibel'.
     Takoj  smolyanoj  yamoj  v  poslednee desyatiletie  bylo  programmirovanie
bol'shih  sistem: v nej sginul ne  odin  bol'shoj i sil'nyj  zver'. Po bol'shej
chasti eto proishodilo  v  oblasti sistem, gde malo komu udalos'  realizovat'
specifikacii, ulozhit'sya v  grafik  i  byudzhet.  Bol'shie  i malye, massivnye i
zhilistye - odna  za  drugoj eti komandy  uvyazli v  smole. Kazalos',  nichto v
otdel'nosti  ne  vyzyvaet  trudnostej - odnu lapu vsegda mozhno vytashchit'.  No
nakoplenie dejstvuyushchih odnovremenno i vzaimovliyayushchih  faktorov vse  bolee  i
bolee   zamedlyaet  dvizhenie.  Vyzyvaet   udivlenie  nepriyatnost'   voznikshej
problemy, i raspoznat' ee sushchnost'  nelegko. No  nuzhno eto sdelat',  esli my
sobiraemsya reshit' ee.
     Poetomu   nachnem   s   opredeleniya    togo,   chto    takoe    sistemnoe
programmirovanie, i kakie radosti i pechali ono tait.
     Sistemnyj programmnyj produkt
     Vremya  ot   vremeni   mozhno   prochest'  v  gazete  o   tom,   kak  v
pereoborudovannom garazhe para programmistov sdelala zamechatel'nuyu programmu,
ostavivshuyu pozadi  razrabotki  bol'shih komand. I  kazhdyj  programmist ohotno
verit v  eti skazki, poskol'ku znaet, chto  mozhet sozdat' lyubuyu programmu  so
skorost'yu, znachitel'no prevyshayushchej  te 1000  operatorov v god,  kotorye,  po
soobshcheniyam, pishut programmisty v promyshlennyh brigadah.
     Pochemu  zhe do  sih por  vse professional'nye  brigady programmistov  ne
zameneny oderzhimymi  duetami  iz  garazhej?  Nuzhno  posmotret'  na  to,  chto,
sobstvenno, proizvoditsya.
     V levom  verhnem  uglu risunka 1.1  nahoditsya  programma. Ona  yavlyaetsya
zavershennym produktom, prigodnym dlya  zapuska svoim  avtorom na  sisteme, na
kotoroj byla razrabotana. V garazhah obychno proizvoditsya takoj produkt, i eto
- tot  ob®ekt, posredstvom  kotorogo  otdel'nyj  programmist  ocenivaet svoyu
proizvoditel'nost'.
     Est' dva sposoba, kotorymi programmu mozhno prevratit' v bolee poleznyj,
no i bolee dorogoj ob®ekt. |ti dva sposoba predstavleny po krayam risunka.
     Pri   peremeshchenii   vniz   cherez   gorizontal'nuyu   granicu   programma
prevrashchaetsya  v  programmnyj produkt.  |to programma, kotoruyu lyuboj  chelovek
mozhet  zapuskat',   testirovat',   ispravlyat'   i   razvivat'.   Ona   mozhet
ispol'zovat'sya v razlichnyh operacionnyh sredah i so mnogimi naborami dannyh.
CHtoby stat' obshcheupotrebitel'nym programmnym produktom, programma dolzhna byt'
napisana v  obobshchennom stile.  V chastnosti,  diapazon i  vid vhodnyh  dannyh
dolzhny  byt'  nastol'ko  obobshchennymi,   naskol'ko  eto  dopuskaetsya  bazovym
algoritmom.  Zatem  programmu  nuzhno  tshchatel'no  protestirovat',  chtoby byt'
uverennym   v  ee   nadezhnosti.  Dlya  etogo  nuzhno  podgotovit'  dostatochnoe
kolichestvo kontrol'nyh primerov dlya proverki  diapazona dopustimyh  znachenij
vhodnyh  dannyh   i  opredeleniya  ego  granic,   obrabotat'  eti  primery  i
zafiksirovat'  rezul'taty. Nakonec, razvitie programmy v programmnyj produkt
trebuet  sozdaniya podrobnoj dokumentacii,  s pomoshch'yu  kotoroj kazhdyj mog  by
ispol'zovat'  ee,  delat' ispravleniya  i rasshiryat'. YA pol'zuyus' prakticheskim
pravilom, soglasno  kotoromu programmnyj  produkt  stoit,  po men'shej  mere,
vtroe dorozhe, chem prosto otlazhennaya programma s takoj zhe funkcional'nost'yu.

     

     Ris. 1.1 |volyuciya sistemnogo programmnogo produkta
     Pri  peresechenii vertikal'noj  granicy programma stanovitsya komponentom
programmnogo kompleksa. Poslednij predstavlyaet soboj nabor vzaimodejstvuyushchih
programm, soglasovannyh po funkciyam i formatam,  i vkupe sostavlyayushchih polnoe
sredstvo  dlya   resheniya  bol'shih  zadach.  CHtoby  stat'  chast'yu  programmnogo
kompleksa,  sintaksis  i   semantika  vvoda   i  vyvoda   programmy   dolzhny
udovletvoryat' tochno  opredelennym interfejsam.  Programma dolzhna  byt' takzhe
sproektirovana  takim obrazom, chtoby ispol'zovat' zaranee ogovorennyj byudzhet
resursov  -  ob®em  pamyati,  ustrojstva  vvoda/vyvoda,  processornoe  vremya.
Nakonec,  programmu  nuzhno   protestirovat'  vmeste  s   prochimi  sistemnymi
komponentami vo vseh sochetaniyah, kotorye mogut vstretit'sya. |to testirovanie
mozhet okazat'sya bol'shim  po ob®emu, poskol'ku kolichestvo testiruemyh sluchaev
rastet eksponencial'no.  Ono takzhe  zanimaet mnogo vremeni, tak  kak skrytye
oshibki vyyavlyayutsya pri neozhidannyh  vzaimodejstviyah otlazhivaemyh komponentov.
Komponent  programmnogo kompleksa stoit,  po krajnej mere, vtroe dorozhe, chem
avtonomnaya programma  s temi zhe funkciyami. Stoimost' mozhet uvelichit'sya, esli
v sisteme mnogo komponentov.
     V  pravom  nizhnem  uglu risunka  1.1  nahoditsya  sistemnyj  programmnyj
produkt.  Ot  obychnoj  programmy on  otlichaetsya vo vseh  perechislennyh  vyshe
otnosheniyah.  I   stoit,  sootvetstvenno,   v   desyat'  raz  dorozhe.  No  eto
dejstvitel'no poleznyj  ob®ekt, kotoryj yavlyaetsya cel'yu bol'shinstva sistemnyh
programmnyh proektov.
     Radosti professii
     Pochemu  zanimat'sya  programmirovaniem  interesno?   Kakimi  radostyami
voznagrazhdayutsya te, kto im zanimaetsya?
     Vo-pervyh, eto prosto radost', poluchaemaya pri sozdanii chego-libo svoimi
rukami. Kak  rebenok  raduetsya, delaya  kulichiki  iz  peska,  tak i  vzroslyj
poluchaet  udovol'stvie, sozdavaya  kakie-libo  veshchi, osobenno esli  sam  ih i
pridumal. YA dumayu, chto etot  vostorg - otrazhenie vostorga Gospoda, tvoryashchego
mir, vostorga, proyavlyayushchegosya v individual'nosti i novizne  kazhdogo listochka
i kazhdoj snezhinki.
     Vo-vtoryh, eto udovol'stvie sozdavat'  veshchi, kotorye mogut byt' polezny
drugim lyudyam. Gluboko v  dushe my ispytyvaem potrebnost' v tom,  chtoby drugie
ispol'zovali  rezul'taty  nashego  truda  i  schitali  ih  poleznymi.  V  etom
otnoshenii programmnaya  sistema  po  svoej suti - to zhe,  chto i izgotovlennaya
rebenkom podstavka dlya karandashej "pape v podarok".
     V-tret'ih,  eto  ocharovanie  sozdaniya  slozhnyh  golovolomnyh  ob®ektov,
sostoyashchih iz vzaimodejstvuyushchih dvizhushchihsya chastej i nablyudeniya za ih rabotoj,
krug  za krugom demonstriruyushchej rezul'taty iznachal'no zalozhennyh  principov.
Komp'yuter s rabotayushchej  na nem programmoj  obladaet  dovedennym  do  vysshego
predela ocharovaniem igornogo ili muzykal'nogo avtomata.
     V-chetvertyh,  eto radost', poluchaemaya ot  neizmennogo uznavaniya novogo,
proistekayushchego iz nepovtorimoj prirody  zadachi. V  tom  ili  inom  otnoshenii
zadacha vsegda  stavitsya  po-novomu,  i tot,  kto  ee  reshaet, poluchaet novye
znaniya - libo prakticheskie, libo teoreticheskie, libo te i drugie vmeste.
     Nakonec, naslazhdenie dostavlyaet  rabota so stol' podatlivym materialom.
Programmist, podobno  poetu, rabotaet pochti neposredstvenno s chistoj mysl'yu.
On stroit svoi zamki v vozduhe i iz vozduha, tvorya siloj voobrazheniya. Trudno
najti drugoj material,  ispol'zuemyj  v tvorchestve, kotoryj stol'  zhe gibok,
prost dlya  shlifovki  ili pererabotki i dostupen  dlya voploshcheniya  grandioznyh
zamyslov. (Kak my pozdnee uvidim, takaya podatlivost' tait svoi problemy.)
     Odnako  programmnaya konstrukciya,  v  otlichie  ot  poeticheskih tvorenij,
real'na,  v tom smysle,  chto  ona dvizhetsya  i  rabotaet,  proizvodya  vidimye
rezul'taty, kotorye  otdelimy ot samoj konstrukcii. Ona pechataet rezul'taty,
risuet kartinki, proizvodit  zvuki, privodit v dvizhenie rychagi. V nashe vremya
osushchestvilos'  volshebstvo  mifa  i  legendy.  S  klaviatury vvoditsya  vernoe
zaklinanie, i ekran monitora  ozhivaet, pokazyvaya to, chego  nikogda ne bylo i
ne moglo byt'.
     Takim  obrazom,  programmirovanie  dostavlyaet  udovol'stvie,  poskol'ku
otvechaet  glubokoj  vnutrennej  potrebnosti  v  tvorchestve  i  udovletvoryaet
chuvstvennye potrebnosti, kotorye est' u vseh nas.
     Pechali professii
     Ne  vse, odnako,  v radost',  i esli predvidet' prisushchie etomu remeslu
ogorcheniya, to oni legche perenosyatsya.
     Vo-pervyh, neobhodima bezoshibochnaya tochnost'  dejstvij. V etom otnoshenii
komp'yuter takzhe  napominaet  volshebstvo. Odin nevernyj  znak,  odna  pauza v
zaklinanii, i chudo ne sostoyalos'. CHeloveku nesvojstvenno sovershenstvo, i ono
yavlyaetsya neobhodimym lish'  v  nemnogih sferah ego deyatel'nosti. Mne kazhetsya,
chto  pri  osvoenii  programmirovaniya trudnee  vsego privyknut' k  trebovaniyu
sovershenstva.1
     Krome  togo, postanovka zadach,  obespechenie  resursami i predostavlenie
informacii  osushchestvlyaetsya  drugimi  lyud'mi.  Redko  udaetsya  kontrolirovat'
usloviya raboty i  dazhe ee celi. Na yazyke administrirovaniya eto oznachaet, chto
polnomochiya  nizhe otvetstvennosti. Vprochem, pohozhe,  chto v lyuboj  rabote, gde
dolzhen  byt'  poluchen  rezul'tat, formal'naya  vlast' nikogda ne soizmerima s
otvetstvennost'yu. Na praktike  fakticheskaya (v protivopolozhnost'  formal'noj)
vlast' priobretaetsya v rezul'tate uspeshnogo vypolneniya zadach.
     Zavisimost' ot drugih imeet osobenno nepriyatnuyu sistemnomu programmistu
storonu. On nahoditsya v zavisimosti ot  programm, napisannyh drugimi lyud'mi,
i eti programmy zachastuyu  ploho sproektirovany, slabo napisany,  polucheny  v
nepolnom  vide  (bez  ishodnogo  teksta  i  kontrol'nyh  primerov)  i  ploho
dokumentirovany.  Poetomu  programmistu prihoditsya tratit'  mnogie  chasy  na
izuchenie  i  ispravlenie  veshchej, kotorye,  v  ideale, dolzhny  byt'  polnymi,
dostupnymi i godnymi k ispol'zovaniyu.
     Sleduyushchij  "minus" svyazan s tem,  razrabotka  grandioznyh  idej  -  eto
udovol'stvie, a poisk parshivyh malen'kih "zhuchkov" - eto vsego lish' rabota. V
kazhdom tvorcheskom dele  byvayut uzhasnye periody odnoobraznogo i  kropotlivogo
truda, i programmirovanie ne yavlyaetsya isklyucheniem.
     Dalee  okazyvaetsya,  chto  pri  otladke  programmy  shodimost'  yavlyaetsya
linejnoj, esli ne huzhe,  hotya  mozhno bylo  predpolagat'  nekoe  kvadratichnoe
priblizhenie k okonchaniyu. V itoge otladka prodolzhaetsya dolgo, prichem na poisk
poslednih bolee  slozhnyh  oshibok  uhodit bol'she  vremeni, chem  na  otyskanie
pervyh.
     Poslednyaya gorest', a chasto  i  poslednyaya  kaplya, - to,  chto produkt, na
kotoryj bylo polozheno stol'ko  truda,  okazyvaetsya  ustarevshim v  moment ego
zaversheniya (ili dazhe ran'she). Kollegi i konkurenty uzhe  s pylom rabotayut nad
novymi  i luchshimi  ideyami.  I unichtozhenie  ploda  vashej mysli uzhe  ne tol'ko
zadumano, no i zaplanirovano.
     Na  samom dele  polozhenie obychno luchshe, chem kazhetsya. V to vremya kak vash
produkt uzhe zavershen, etot novyj i luchshij  produkt, kak pravilo, otsutstvuet
na rynke, o nem  lish' mnogo razgovorov,  i dlya  ego  razrabotki  potrebuyutsya
mesyacy.  Nastoyashchij   tigr  ne  para   bumazhnomu,   esli  trebuetsya  real'noe
ispol'zovanie. Real'noe sushchestvovanie imeet preimushchestva.
     Konechno,  tehnologicheskaya  osnova  razrabotki vsegda  razvivaetsya.  Kak
tol'ko  razrabotka  proekta  zakonchena, on  stanovitsya  ustarevshim v  smysle
zalozhennyh  v   nem  koncepcij.  No  dlya   osushchestvleniya  real'nogo  proekta
neobhodimo razbienie  na stadii  i urovni.  Sudit' o tom, yavlyaetsya  li nekaya
realizaciya ustarevshej,  mozhno lish'  sravnivaya  ee  s  drugimi  sushchestvuyushchimi
realizaciyami, a  ne s nerealizovannymi ideyami.  Trudnost' i cel'  sostoyat  v
tom, chtoby najti real'nye resheniya dlya real'nyh zadach v ustanovlennye  sroki,
ispol'zuya imeyushchiesya resursy.
     Takovo  programmirovanie  -  i  smolyanaya yama,  v  kotoroj uvyazli mnogie
proekty, i  tvorchestvo so svoimi radostyami  i pechalyami.  Dlya  mnogih radosti
znachat gorazdo bol'she, chem pechali. Dlya nih i  napisana eta kniga  v  popytke
prolozhit' kakie-to mostki cherez eto boloto.


    Glava 2. |tot mificheskij "cheloveko-mesyac"

     CHtoby prigotovit' vkusnuyu pishchu,
trebuetsya vremya. Esli vam prishlos' zhdat', to lish' potomu, chto my hotim luchshe
obsluzhit' vas i dostavit' vam udovol'stvie.
     MENYU RESTORANA "ANTUAN" VNXYU-ORLEANE
     Programmnye  proekty  chashche provalivayutsya iz-za  nehvatki  kalendarnogo
vremeni,  chem  po vsem ostal'nym prichinam  vmeste vzyatym. Pochemu eta prichina
neudach stol' rasprostranena?
     Vo-pervyh, slabo razvity nashi metody ocenok. V  sushchnosti,  oni otrazhayut
molchalivoe i sovershenno nevernoe predpolozhenie, chto vse budet idti horosho.
     Vo-vtoryh,  nashi metody ocenki  oshibochno  putayut dostignutyj progress s
zatrachennymi usiliyami,  neyavno  dopuskaya,  chto skorost'  vypolneniya  proekta
proporcional'na kolichestvu zanyatyh v nem sotrudnikov.
     V-tret'ih, poskol'ku  menedzhery programmnyh proektov ne uvereny v svoih
ocenkah, im chasto nedostaet vezhlivogo  upryamstva, kak u shef-povara restorana
"Antuan".
     V-chetvertyh,  vypolnenie  grafika  rabot slabo kontroliruetsya.  Tipovye
oprobovannye  v drugih inzhenernyh disciplinah metody  schitayutsya radikal'nymi
novovvedeniyami pri razrabotke programmnogo obespecheniya.
     V-pyatyh,   pri  obnaruzhenii  otstavaniya   ot  grafika   estestvennoj  i
obshcheprinyatoj  reakciej  yavlyaetsya  uvelichenie  chisla  razrabotchikov. |to  vse
ravno, chto tushit' plamya benzinom.  V rezul'tate dela  idut znachitel'no huzhe.
CHem sil'nee plamya, tem bol'she nuzhno benzina, i v itoge  etot put' privodit k
katastrofe.
     Kontrol'  vypolneniya  grafika  budet  predmetom  otdel'nogo  razgovora.
Rassmotrim bolee podrobno ostal'nye aspekty problemy.
     Optimizm
     Vse programmisty - optimisty. Vozmozhno, eta sovremennaya raznovidnost'
koldovstva osobenno privlekatel'na dlya teh, kto verit v heppi-endy i  dobryh
fej.  Vozmozhno,  sotni  neudach  ottalkivayut  vseh,  krome  teh,  kto  privyk
sosredotochivat'sya na konechnoj celi. A mozhet byt', delo vsego lish' v tom, chto
komp'yutery i programmisty molody,  a molodosti svojstven optimizm. Kak by to
ni  bylo, v rezul'tate odno: "Na etot raz ona tochno pojdet!" Ili : "YA tol'ko
chto vyyavil poslednyuyu oshibku!"
     Itak, v osnove planirovaniya razrabotki programm lezhit lozhnoe dopushchenie,
chto vse budet  horosho,  t.e.  kazhdaya zadacha zajmet stol'ko vremeni,  skol'ko
"dolzhna" zanyat'.
     Glubokij optimizm programmistov  zasluzhivaet bolee ser'eznogo izucheniya.
Doroti  Sejers  (Dorothy Cayers) v svoej prevoshodnoj  knige  "Razum tvorca"
("The  Mind  of the  Maker") vydelyaet v tvorcheskoj deyatel'nosti  tri stadii:
zamysel,  realizaciyu,  vzaimodejstvie.  Sootvetstvenno, kniga, komp'yuter ili
programma snachala  voznikayut kak  ideal'noe  postroenie, sushchestvuyushchee ne  vo
vremeni i  prostranstve,  a lish'  v mozgu svoego sozdatelya. Realizaciya zhe vo
vremeni  i prostranstve proishodit  s pomoshch'yu pera, chernil,  bumagi, libo  -
provodov,  kremniya i  ferrita.  Tvorenie  budet  zaversheno,  kogda  kto-libo
prochtet  knigu, vospol'zuetsya komp'yuterom ili zapustit programmu, tem  samym
vstupiv vo vzaimodejstvie s razumom ih sozdatelya.
     |to opisanie  ispol'zuemoe  Sejers dlya  osveshcheniya  ne tol'ko tvorcheskoj
deyatel'nosti cheloveka, no  i  hristianskogo  dogmata Troicy,  pomozhet nam  v
nashej tekushchej zadache.  Dlya  cheloveka,  kotoryj chto-to sozdaet,  nepolnota  i
protivorechivost'  idej  vyyavlyayutsya tol'ko  pri  ih  realizacii.  Poetomu dlya
teoretika  izlozhenie  na  bumage, eksperimentirovanie, izgotovlenie yavlyaetsya
neot®emlemymi chastyami tvorcheskogo processa.
     Vo  mnogih  vidah tvorcheskoj deyatel'nost' material  s trudom  poddaetsya
obrabotke.  Derevo  koletsya,  kraski pachkayutsya, elektricheskie cepi "zvenyat".
|ti fizicheskie ogranicheniya suzhayut krug idej, kotorye mogut byt'  vyrazheny, a
takzhe sozdayut neozhidannye trudnosti pri realizacii.
     Realizaciya, takim obrazom, trebuet sil  i vremeni kak iz-za fizicheskogo
materiala, tak  i vvidu neadekvatnosti osnovopolagayushchih  idej. Bol'shuyu chast'
zatrudnenij  pri realizacii  my sklonny ob®yasnyat'  nedostatkami  fizicheskogo
materiala,  poskol'ku on  "chuzhd"  nam  -  v otlichie  ot  idej,  kotorymi  my
gordimsya.
     Pri  sozdanii  zhe  programm  my  imeem  delo  s  chrezmerno   podatlivym
materialom.  Programmist  osushchestvlyaet  svoi  postroeniya  na osnove  chistogo
myshleniya - ponyatij i ochen' gibkih ih predstavlenij. Poskol'ku material stol'
podatliv,  my ne ozhidaem  trudnostej pri  realizacii, otsyuda i  nash glubokij
optimizm.  Iz-za  oshibochnosti  nashih  idej  voznikayut  oshibki v  programmah.
Sledovatel'no, nash optimizm ne imeet opravdaniya.
     Dlya  otdel'noj  zadachi  dopushchenie,  chto vse  bude horosho,  okazyvaet na
grafik rabot  veroyatnostnyj effekt. Vse  mozhet dejstvitel'no idti po  planu,
poskol'ku est' nekotoroe raspredelenie veroyatnosti dlya vozmozhnoj zaderzhki  i
sushchestvuet konechnaya veroyatnost' togo,  chto zaderzhki ne budet. Odnako bol'shoj
programmnyj  proekt  sostoit iz mnozhestva zadach, chast' iz kotoryh mozhet byt'
nachata tol'ko posle okonchaniya drugih. Veroyatnost' togo, chto vse zadachi budut
zaversheny v srok, beskonechno mala. CHeloveko-mesyac Vtoraya oshibka  rassuzhdenij
zaklyuchena  v   samoj  edinice  izmereniya,  ispol'zuemoj   pri  ocenivanii  i
planirovanii:   cheloveko-mesyac.  Stoimost'   dejstvitel'no   izmeryaetsya  kak
proizvedeniya  chisla   zanyatyh  na  kolichestvo  zatrachennyh  mesyacev.  No  ne
dostignutyj rezul'tat.  Poetomu  ispol'zovanie cheloveko-mesyaca  kak  edinicy
izmereniya ob®ema raboty yavlyaetsya opasnym zabluzhdeniem.

     

     Ris. 2.1  Zavisimost' vremeni ot chisla zanyatyh -  polnost'yu  razdelimaya
zadacha
     CHislo  zanyatyh i chislo mesyacev  yavlyayutsya  vzaimozamenyaemymi  velichinami
lish' togda, kogda zadachu  mozhno raspredelit' sredi  ryada rabotnikov, kotorye
ne imeyut mezhdu soboj vzaimosvyazi  (ris. 2.1).  |to verno, kogda zhnut pshenicu
ili sobirayut hlopok, no v sistemnom programmirovanii eto daleko ne tak.

     

     Ris. 2.2 Zavisimost' vremeni ot chisla zanyatyh - nerazdelimaya zadacha
     Esli zadachu nel'zya  razbit' na  chasti, poskol'ku sushchestvuyut ogranicheniya
na posledovatel'nost'  vypolneniya etapov, to uvelichenie zatrat  ne okazyvaet
vliyaniya na grafik (ris.  2.2). CHtoby rodit' rebenka trebuetsya devyat' mesyacev
nezavisimo ot  togo,  skol'ko  zhenshchin  privlecheno  k resheniyu  dannoj zadachi.
Mnogie zadachi programmirovaniya otnosyatsya  k etomu tipu, poskol'ku otladka po
svoej suti nosit posledovatel'nyj harakter.

     

     Ris.  2.3 Zavisimost'  vremeni ot  chisla  zanyatyh  - razdelimaya zadacha,
trebuyushchaya obmena dannymi
     Dlya  zadach, kotorye  mogut  byt' razbity na  chasti,  no trebuyut  obmena
dannymi mezhdu podzadachami, zatraty na obmen dannymi dolzhny  byt' dobavleny k
obshchemu ob®emu  neobhodimyh  rabot. Poetomu  dostizhimyj  nailuchshij  rezul'tat
okazyvaetsya  neskol'ko  huzhe,  chem  prostoe  sootvetstvie  chisla  zanyatyh  i
kolichestva mesyacev (ris. 2.3).
     Dopolnitel'naya  nagruzka  sostoit  iz dvuh chastej - obucheniya  i  obmena
dannymi.  Kazhdogo rabotnika nuzhno obuchit'  tehnologii, celyam proekta,  obshchej
strategii  i  planu  raboty. |to obuchenie nel'zya  razbit'  na chasti, poetomu
dannaya chast' zatrat izmenyaetsya linejno v zavisimosti ot chisla zanyatyh.

     

     Ris.  2.4  Zavisimost' vremeni ot  chisla  zanyatyh -  zadacha so slozhnymi
vzaimosvyazyami
     S obmenom dannymi delo obstoit huzhe. Esli vse chasti zadaniya dolzhny byt'
otdel'no skoordinirovany  mezhdu  soboj,  to zatraty vozrastayut kak n(n-2)/2.
Dlya treh rabotnikov trebuetsya vtroe bol'she poparnogo obshcheniya, chem dlya  dvuh,
dlya  chetyreh  -  vshestero.  Esli  pomimo  etogo  voznikaet  neobhodimost'  v
soveshchaniyah treh, chetyreh i t.d. rabotnikov dlya sovmestnogo resheniya voprosov,
polozhenie stanovitsya eshche huzhe. Dopolnitel'nye zatraty na obmen dannymi mogut
polnost'yu  obescenit'  rezul'tat  drobleniya ishodnoj  zadachi  i  privesti  k
polozheniyu, opisyvaemomu risunkom 2.4.
     Poskol'ku  sozdanie programmnogo  produkta  yavlyaetsya po  suti sistemnym
proektom - praktikoj slozhnyh vzaimosvyazej, zatraty na obmen dannymi veliki i
bystro nachinayut preobladat' nad sokrashcheniem srokov, dostigaemym v rezul'tate
razbieniya  zadachi  na  bolee  melkie  podzadachi.  V  etom sluchae privlechenie
dopolnitel'nyh rabotnikov ne sokrashchaet, a udlinyaet grafik rabot.
     Sistemnoe testirovanie
     Iz vseh elementov grafika  rabot  naibol'shemu  vozdejstviyu so storony
ogranichenij  na posledovatel'nost'  vypolneniya  dejstvij  podverzheny otladka
komponentov i sistemnoe testirovanie. Krome togo, zatraty vremeni zavisyat ot
kolichestva  vyyavlennyh   oshibok  i   ot   togo,  naskol'ko   oni  "skrytye".
Teoreticheski, oshibok  byt'  ne  dolzhno.  Iz-za  svoego  optimizma my  obychno
sklonny  nedoocenivat'   dejstvitel'noe   kolichestvo   oshibok.   Poetomu   v
programmirovanii  priderzhivat'sya grafikov  rabot  obychno  trudnee vsego  pri
otladke.
     V techenie ryada let pri planirovanii razrabotki programmnogo obespecheniya
ya pol'zuyus' sleduyushchim empiricheskim pravilom:
     1/3 - planirovanie,
     1/6 - napisanie programm,
     1/4   -   testirovanie   komponentov   i   predvaritel'noe    sistemnoe
testirovanie,
     1/4 - sistemnoe testirovanie pri nalichii vseh komponentov.
     |to   pravilo  imeet   neskol'ko   vazhnyh   razlichij   s   obshcheprinyatym
planirovaniem:
     1. Na  planirovanie otvoditsya  bol'she vremeni, chem  obychno. I vse ravno
etogo   vremeni  edva  dostatochno  dlya   razrabotki  podrobnyh   i  nadezhnyh
tehnicheskih uslovij  i  nedostatochno dlya  provedeniya issledovatel'skih rabot
ili poiska novejshih tehnologij.
     2. Polovina grafika rabot,  otvedennaya  na otladku  zakonchennogo  koda,
znachitel'no vyshe normy.
     3. Ta chast', kotoruyu legko ocenit', t.e. napisanie koda, zanimaet vsego
odnu shestuyu obshchego vremeni.
     Izuchaya proekty, grafik kotoryh  byl sostavlen tradicionnym  obrazom,  ya
obnaruzhil,  chto  nemnogie  iz nih otvodili po  grafiku  polovinu  vremeni na
otladku,  no  na  praktike  v  bol'shinstve sluchaev  tratili na  nee polovinu
fakticheskogo vremeni. Mnogie proekty ukladyvalis'  v grafik na vseh  etapah,
isklyuchaya sistemnoe testirovanie.2
     Osobenno  katastroficheskie  posledstviya  mozhet imet' nedostatok vremeni
dlya  sistemnogo testirovaniya. Poskol'ku zaderzhka proishodit v konechnoj chasti
grafika, nikto ne podozrevaet o tom, chto  grafik nahoditsya pod ugrozoj sryva
vplot'  do  dnya  sdachi  produkta. Plohie  vesti,  poluchennye  pozdno  i  bez
preduprezhdeniya, obeskurazhivayut klientov i menedzherov.
     Bolee togo, zaderzhka na etom etape imeet  osobenno tyazhelye material'nye
i   psihologicheskie   posledstviya.   Proekt   osushchestvlyaetsya   pri    polnoj
ukomplektovannosti  rabotnikami  i  maksimal'nyh  finansovyh  izderzhkah. CHto
vazhnee, programmnoe obespechenie  dolzhno obespechit' podderzhku drugoj  delovoj
aktivnosti (postavki komp'yuterov, zapuska novyh proizvodstvennyh moshchnostej i
t.p.), i svyazannye s  zaderzhkoj vtorichnye izderzhki ochen' vysoki. Na praktike
eti vtorichnye izderzhki mogut byt' vyshe, chem vse prochie. Poetomu ochen'  vazhno
v iznachal'nom  grafike  rabot  otvesti  dostatochno  vremeni  dlya  sistemnogo
testirovaniya.
     Robost' v ocenkah
     Dlya programmista, kak i dlya povara, davlenie so storony  hozyaina  mozhet
opredelyat'  zaplanirovannyj srok  zaversheniya zadachi, no  ne mozhet opredelyat'
vremya  ee fakticheskogo  zaversheniya. Omlet, obeshchannyj cherez dve minuty, mozhet
uspeshno zharit'sya, no esli  cherez  dve minuty on ne gotov,  to u klienta est'
dve vozmozhnosti: zhdat' eshche ili s®est' ego syrym. Tot zhe vybor vstaet i pered
zakazchikom programmnogo obespecheniya.
     U povara  est' eshche odna  vozmozhnost': dobavit' zharu. V rezul'tate omlet
chasto okazyvaetsya beznadezhno isporchennym:  gorelym s odnogo kraya i syrym - s
drugogo.
     YA ne dumayu, chto u menedzherov programmnyh produktov men'she hrabrosti ili
tverdosti, chem u povarov  ili  drugih menedzherov  v inzhenernyh oblastyah.  No
lipovye grafiki,  nacelennye  na zhelatel'nuyu hozyainu datu, vstrechayutsya zdes'
znachitel'no chashche,  chem v  lyubyh  drugih  inzhenernyh oblastyah. Ochen'  tyazhelo,
riskuya poteryat'  rabochee mesto, s energiej  i lyubeznost'yu  otstaivat'  srok,
kotoryj  opredelen  bez primeneniya  kakih-libo  kolichestvennyh  metodov  pri
nedostatke dannyh i podkreplen, v osnovnom, intuiciej menedzhera.
     Ochevidno,  neobhodimo sdelat' dve  veshchi. My dolzhny  poluchit'  i sdelat'
obshchedostupnymi chislennye dannye, harakterizuyushchie proizvoditel'nost', chastotu
programmnyh oshibok, metody ocenki  i t.d. Vsya otrasl' mozhet  tol'ko vyigrat'
ot opublikovaniya takih dannyh.
     Poka  metody ocenivaniya  ne  poluchat bolee prochnoj  osnovy,  menedzheram
ostaetsya tol'ko muzhat'sya i zashchishchat' svoi prognozy, utverzhdaya, chto polagat'sya
na ih slabuyu intuiciyu vse zhe luchshe, chem osnovyvat'sya na odnih zhelaniyah.
     Dejstviya pri sryve grafika
     CHto  delayut,  kogda vazhnyj programmnyj  proekt nachinaet  otstavat'  ot
grafika? Estestvenno, dobavlyayut lyudej. Kak pokazyvayut risunki  2.1-2.4,  eto
ne vsegda pomogaet.
     Rassmotrim primer.3 Predpolozhim, chto trudoemkost' zadachi  ocenivaetsya v
12 cheloveko-mesyacev, i tri  cheloveka dolzhny vypolnit' ee za 4 mesyaca, prichem
v konce kazhdogo  mesyaca imeyutsya  chetyre kontrol'nye  tochki A,  B, C  i  D, v
kotoryh mozhno proizvesti izmereniya (ris. 2.5).

     

     Ris. 2.5
     Predpolozhim  teper', chto pervaya kontrol'naya tochka byla dostignuta lish'
po istechenii dvuh mesyacev. Kakie al'ternativy imeyutsya u menedzhera?
     1. Dopustim, chto neobhodimo soblyusti srok vypolneniya zadachi, i oshibochno
ocenena  byla tol'ko pervaya chast' zadachi,  t.e.  risunok 2.6 verno  otrazhaet
polozhenie.  Znachit, ostaetsya  9 cheloveko-mesyacev  trudozatrat  i dva mesyaca,
poetomu  ponadobitsya 4½ cheloveka,  i k troim imeyushchimsya  nuzhno  dobavit'  eshche
dvoih.

     

     Ris. 2.6
     2.   Dopustim,  chto  neobhodimo  soblyusti  srok  vypolneniya  zadachi,  i
odinakovo zanizhena byla  vsya  ocenka , t.e.  polozhenie sootvetstvuet risunku
2.7. Znachit, ostaetsya 18 cheloveko-mesyacev trudozatrat i dva  mesyaca, poetomu
ponadobitsya 9 chelovek. K troim imeyushchimsya nuzhno dobavit' eshche shesteryh.

     

     Ris. 2.7
     3. Izmenit' grafik.  Mne  nravitsya zamechanie, sdelannoe P. Faggom  (P.
Fagg), opytnym inzhenerom po  vychislitel'noj  tehnike: "Malen'kih zaderzhek ne
byvaet". |to oznachaet, chto  v novom grafike dolzhno  byt' dostatochno vremeni,
chtoby rabota byla ispolnena tshchatel'no i  polnost'yu,  i ne prishlos' by  vnov'
peredelyvat' grafik.
     4. Sokratit' zadachu. Na praktike etim vsegda i konchaetsya, kogda komanda
obnaruzhivaet,  chto ne  ukladyvaetsya v  grafik.  Kogda ochen' vysoki vtorichnye
izderzhki,  eto edinstvennoe,  chto mozhno sdelat'.  Menedzheru  predostavlyaetsya
vozmozhnost' oficial'no i akkuratno sokratit' zadachu,  izmenit'  grafik, libo
nablyudat', kak  zadacha molcha urezaetsya  pri  pospeshnom  izmenenii proekta  i
nepolnom testirovanii.
     V pervyh dvuh sluchayah nastaivat' na tom, chtoby zadacha v neizmennom vide
byla vypolnena za chetyre mesyaca, chrevato katastrofoj. Rassmotrim, k primeru,
vosstanovitel'nyj   effekt  pervoj   al'ternativy  (ris.  2.8).  Dvoe  novyh
rabotnikov,  kakimi by znayushchimi oni ni byli, i  kak by bystro ne udalos'  ih
najti, dolzhny izuchit' zadachu s pomoshch'yu odnogo iz opytnyh razrabotchikov. Esli
dlya etogo potrebuetsya mesyac, to 3 cheloveko-mesyaca budut potracheny na rabotu,
kotoraya  ne uchityvaetsya  v ishodnoj ocenke.  Krome  togo,  zadacha,  razbitaya
pervonachal'no na tri  potoka, dolzhna byt' teper' perekroena na  pyat' chastej.
Poetomu chast'  uzhe sdelannoj raboty budet poteryana, a sistemnoe testirovanie
nuzhno budet prodlit'. V rezul'tate v konce tret'ego  mesyaca ostanetsya raboty
sushchestvenno bol'she, chem  na  7  cheloveko-mesyacev,  a  v rasporyazhenii budet 5
podgotovlennyh chelovek  i odin  mesyac.  Soglasno risunku 2.8  produkt  budet
zapazdyvat' tak zhe,  kak esli by ni  odnogo cheloveka  ne bylo dobavleno (sm.
ris. 2.6).
     Esli rasschityvat' upravit'sya za chetyre  mesyaca  s uchetom tol'ko vremeni
obucheniya,  no  ne  pereraspredeleniya  zadach  i   dopolnitel'nogo  sistemnogo
testirovaniya, to  v konce  vtorogo  mesyaca  potrebuetsya dobavit'  4, a ne  2
cheloveka.  CHtoby  kompensirovat'   vozdejstvie  pereraspredeleniya   zadach  i
sistemnogo testirovaniya, potrebuyutsya eshche novye lyudi. Teper', odnako, komanda
sostoit  ne  iz  3,  a, po krajnej  mere, 7  chelovek, i  takie voprosy,  kak
organizaciya  komandy i raspredelenie  zadach  priobretayut  novyj kachestvennyj
uroven'.
     Obratite  vnimanie, chto  k koncu tret'ego  mesyaca  delo vyglyadit ves'ma
mrachno.  Nesmotrya  na   vse   administrativnye   usiliya  kontrol'naya  tochka,
namechennaya  na  1 marta, ne dostignuta.  Voznikaet sil'nyj soblazn povtorit'
cikl, dobaviv eshche lyudej. |to bezumnoe reshenie.

     

     Ris. 2.8
     V  predshestvuyushchih  rassuzhdeniyah  predpolagalos',  chto  tol'ko  pervaya
kontrol'naya  tochka  byla   neverno   rasschitana.   Esli   1   marta  sdelat'
konservativnoe predpolozhenie, chto ves' grafik  byl izlishne optimistichen, kak
otrazheno na risunke  2.7,  trebuetsya dobavit' 6 chelovek  k ishodnoj  zadache.
Raschet   vozdejstviya  obucheniya,   pereraspredeleniya   zadach   i   sistemnogo
testirovaniya  predostavlyaetsya sdelat' chitatelyu  v  kachestve uprazhneniya.  Net
somnenij, chto pri popytke ulozhit'sya v srok v itoge poluchitsya hudshij produkt,
chem  pri izmenenii  grafika i sohranenii pervonachal'nyh  troih  chelovek  bez
usileniya.
     Krajne uproshchaya, sformuliruem Zakon Bruksa:
     Esli  proekt  ne  ukladyvaetsya  v  sroki,  to  dobavlenie  rabochej sily
zaderzhit ego eshche bol'she.
        |to   razvenchivaet    mif   o   cheloveko-mesyace.   Prodolzhitel'nost'
osushchestvleniya    proekta     zavisit    ot     ogranichenij,    nakladyvaemyh
posledovatel'nost'yu rabot. Maksimal'noe  kolichestvo razrabotchikov zavisit ot
chisla  nezavisimyh podzadach.  |ti  dve velichiny  pozvolyayut  poluchit'  grafik
rabot,  v  kotorom  budet men'she  zanyatyh  razrabotchikov  i  bol'she mesyacev.
(Edinstvennaya  opasnost'  zaklyuchaetsya  v  vozmozhnom  ustarevanii  produkta.)
Nel'zya, odnako,  sostavit' rabotayushchie grafiki, v kotoryh zanyato bol'she lyudej
i  trebuetsya  men'she vremeni.  Programmnye proekty chashche provalivayutsya  iz-za
nehvatki kalendarnogo vremeni, chem po vsem ostal'nym prichinam vmeste vzyatym.


    Glava   3.   Opracionnaya   brigada

     |ti   issledovaniya   vyyavili   bol'shie
individual'nye  razlichiya  v  proizvoditel'nosti  mezhdu   luchshimi  i  hudshimi
rabotnikami, chasto na poryadok velichin.
     SAKMAN, |RIKSON I GRANT1
     Na  vstrechah  komp'yuternyh  specialistov  mozhno   postoyanno  slyshat'
utverzhdeniya molodyh menedzherov programmnyh proektov, chto im predpochtitel'nej
nebol'shie deyatel'nye  komandy  pervoklassnyh  specialistov, chem  proekty,  v
kotoryh uchastvuyut sotni programmistov, chto podrazumevaet ih srednij uroven'.
I vsem nam tozhe.
     Takoe  naivnoe  predstavlenie  al'ternativ uhodit  ot  resheniya  slozhnoj
zadachi  - kak sozdavat' bol'shie  sistemy v  razumnye sroki? Rassmotrim  etot
vopros bolee podrobno so vseh storon.
     Problema
     Menedzhery programmnyh  proektov davno ponyali,  chto  horoshie  i  plohie
programmisty  ochen'  sil'no  razlichayutsya  mezhdu soboj po proizvoditel'nosti.
Odnako real'no  izmerennye  velichiny porazitel'ny.  V odnom  iz issledovanij
Sakman   (Sackman),    |rikson   (Erikson)    i   Grant   (Grant)   izmeryali
proizvoditel'nost' truda v gruppe opytnyh programmistov.  Vnutri odnoj  lish'
etoj gruppy  sootnoshenie  mezhdu luchshimi  i  hudshimi  rezul'tatami  sostavilo
primerno 10:1 po  proizvoditel'nosti truda i 5:1 po skorosti raboty programm
i trebuemoj dlya  nih  pamyati! Koroche,  programmist, zarabatyvayushchij  20 tysyach
dollarov  v   god,  mozhet  byt'  v  desyat'  raz  produktivnee  programmista,
zarabatyvayushchego  10 tysyach dollarov. Pravda, vozmozhno i  obratnoe. Poluchennye
dannye   ne   vyyavili   kakoj-libo   korrelyacii  mezhdu   stazhem   raboty   i
proizvoditel'nost'yu. (YA ne uveren, chto eto vsegda spravedlivo.)
     Vyshe ya dokazal, chto samo chislo razrabotchikov,  dejstviya  kotoryh  nuzhno
soglasovyvat',   okazyvaet   vliyanie   na   stoimost'   proekta,   poskol'ku
znachitel'naya  chast' izderzhek vyzvana  neobhodimost'yu  obshcheniya  i  ustraneniya
otricatel'nyh  posledstvij  razobshchennosti  (sistemnaya  otladka).  |to  takzhe
navodit  na  mysl', chto zhelatel'no  razrabatyvat'  sistemy vozmozhno  men'shim
chislom lyudej. Dejstvitel'no, opyt razrabotki bol'shih programmnyh sistem, kak
pravilo, pokazyvaet, chto podhod s  pozicij gruboj  sily  vlechet  udorozhanie,
zamedlennost',  neeffektivnost',  a  sozdavaemye  v  rezul'tate  sistemy  ne
yavlyayutsya konceptual'no celostnymi.  Spisok, illyustriruyushchij  eto, beskonechen:
OS/360, Exec 8, Scop 6600, Multics, TSS, SAGE i drugie.
     Vyvod  prost:  esli  nad  proektom   rabotayut   200  chelovek,   vklyuchaya
menedzherov, yavlyayushchihsya naibolee znayushchimi i opytnymi programmistami,  uvol'te
175 bojcov, i pust' menedzhery snova zajmutsya programmirovaniem.
     Davajte  rassmotrim  eto  reshenie. S  odnoj  storony,  emu  ne  udaetsya
priblizit'sya k  idealu  nebol'shoj  aktivnoj  komandy, v  kotoroj,  po obshchemu
priznaniyu,  dolzhno  byt'  ne  bolee  10  chelovek.  Poetomu  razmer   brigady
predpolagaet nalichie  kak  minimum  dvuh urovnej upravleniya, ili  okolo pyati
menedzherov.  Potrebuyutsya dopolnitel'ny finansovye rashody, sotrudniki, mesto
dlya raboty, sekretari i operatory mashin.
     S drugoj  storony, ishodnaya komanda iz 200  chelovek imela  chislennost',
nedostatochnuyu dlya sozdaniya dejstvitel'no krupnyh sistem metodom gruboj sily.
Rassmotrim, k  primeru, OS/360. Odno vremya v ee  sozdanii bylo zanyato bol'she
1000  chelovek   -   programmistov,  sostavitelej  dokumentacii,  operatorov,
klerkov, sekretarej, menedzherov, vspomogatel'nyh grupp i t.d. S 1963 po 1966
god  na   ee  proektirovanie,  realizaciyu  i   napisanie  dokumentacii  bylo
zatracheno, veroyatno, okolo  5000  cheloveko-let.  Esli by  strogo soblyudalas'
proporciya  mezhdu  kolichestvom  zanyatyh  i  prodolzhitel'nost'yu  rabot,  nashej
predpolagaemoj  komande  iz dvuhsot chelovek potrebovalos' by  25  let, chtoby
dovesti produkt do segodnyashnego urovnya!
     V  etom i sostoit iz®yan idei  malen'koj aktivnoj komandy: dlya  sozdaniya
po-  nastoyashchemu  krupnyh  sistem  ej  potrebuetsya  slishkom   mnogo  vremeni.
Posmotrim,  kak  razrabotka  OS/360  osushchestvlyalas'  by  malen'koj  aktivnoj
komandoj,  dopustim, iz  10  chelovek.  Polozhim, chto  oni  v sem'  raz  bolee
produktivny  srednih programmistov  (chto  daleko  ot  istiny). Dopustim, chto
umen'shenie ob®ema obshcheniya blagodarya  malochislennosti komandy pozvolilo eshche v
sem' raz  povysit'  proizvoditel'nost'.  Dopustim, chto  na protyazhenii  vsego
proekta rabotaet odna i ta zhe komanda. Takim obrazom, 5000/(10*7*7)=10, t.e.
rabotu  v  5000  cheloveko-let  oni  vypolnyat  za  10  let. Budet  li produkt
predstavlyat' interes cherez  10  let posle  nachala  razrabotki  ili  ustareet
blagodarya stremitel'nomu razvitiyu programmnyh tehnologij?
     Dilemma predstavlyaetsya  zhestokoj. Dlya  effektivnosti  i  konceptual'noj
celostnosti   predpochtitel'nee,  chtoby  proektirovanie  i  sozdanie  sistemy
osushchestvili neskol'ko  svetlyh  golov. Odnako dlya bol'shih sistem  zhelatel'no
postavit' pod ruzh'e znachitel'nyj kontingent, chtoby produkt mog uvidet'  svet
vovremya. Kak mozhno primirit' eti dva zhelaniya?
     Predlozhenie Millza
     Predlozhenie Harlana Millza daet svezhee i tvorcheskoe  reshenie2,3. Millz
predlozhil,  chtoby  na  kazhdom  uchastke raboty  byla  komanda  razrabotchikov,
organizovannaya  napodobie  brigady hirurgov, a ne myasnikov. Imeetsya v  vidu,
chto  ne kazhdyj  uchastnik gruppy  budet  vrezat'sya  v zadachu, no rezat' budet
odin,  a  ostal'nye  okazyvat'  emu  vsevozmozhnuyu   podderzhku,  povyshaya  ego
proizvoditel'nost' i plodotvornost'.
     Pri nekotorom razmyshlenii yasno, chto eta ideya privedet k zhelaemomu, esli
ee  udastsya osushchestvit'.  Lish'  neskol'ko  golov  zanyato  proektirovaniem  i
razrabotkoj, i v to zhe vremya mnogo  rabotnikov  nahoditsya na podhvate. Budet
li takaya organizaciya rabotat'? Kto igraet rol' anesteziologov i operacionnyh
sester v  gruppe programmistov, a kak osushchestvlyaetsya razdelenie truda? CHtoby
narisovat' kartinu  raboty takoj komandy  s  vklyucheniem vseh  myslimyh vidov
podderzhki, ya pozvolyu sebe vol'noe obrashchenie k metaforam.
     Hirurg. Millz nazyvaet ego glavnym programmistom.  On  lichno opredelyaet
tehnicheskie  usloviya  na funkcional'nost'  i ekspluatacionnye harakteristiki
programmy,   proektiruet   ee,  pishet   kod,  otlazhivaet  ego  i  sostavlyaet
dokumentaciyu. On pishet  na  yazyke strukturnogo  programmirovaniya, takom  kak
PL/I, i imeet  pryamoj dostup  k  komp'yuternoj sisteme, na kotoroj ne  tol'ko
proizvoditsya  otladka, no  i sohranyayutsya  razlichnye  versii  ego  programm s
vozmozhnost'yu legkoj modifikacii fajlov, a takzhe osushchestvlyaet  redaktirovanie
dokumentacii.  On  dolzhen  obladat'  bol'shim  talantom,  stazhem raboty svyshe
desyati let i sushchestvennymi znaniyami v sistemnyh i prikladnyh oblastyah, budto
prikladnaya matematika, obrabotka delovyh dannyh ili chto-libo inoe.
     Vtoroj pilot. |to vtoroe "ya" hirurga, mozhet vypolnyat' lyubuyu ego rabotu,
no menee opyten. Ego glavnaya zadacha - uchastvovat' v  proektirovanii,  gde on
dolzhen dumat', obsuzhdat' i ocenivat'. Hirurg ispytyvaet na nem svoi idei, no
ne svyazan  ego predlozheniyami. CHasto vtoroj pilot  predstavlyaet  svoyu brigadu
pri obsuzhdenii s drugimi gruppami funkcij i interfejsa. On horosho znaet ves'
kod   programmy.   On   issleduet   vozmozhnosti   al'ternativnyh   strategij
programmirovaniya. On, ochevidno, podstrahovyvaet na  sluchaj kakoj-libo bedy s
hirurgom.   On  mozhet   dazhe   zanimat'sya  napisaniem   koda,  no  ne  neset
otvetstvennosti za kakuyu-libo ego chast'.
     Administrator. Hirurg - nachal'nik, i emu prinadlezhit poslednee  slovo v
otnoshenii personala, pribavok k  zhalovan'yu, pomeshchenij i t.p., no na eti dela
on  dolzhen   tratit'   kak  mozhno  men'she  vremeni.  Poetomu  emu  neobhodim
professional'nyj   administrator,  zabotoj  kotorogo  budut  den'gi,   lyudi,
pomeshcheniya,  mashiny,  i   kotoryj  budet  kontaktirovat'  s  administrativnym
mehanizmom organizacii v celom.  Bejker schitaet, chto na polnyj  rabochij den'
administrator  dolzhen  privlekat'sya  lish'  v  sluchae,  kogda   otnosheniya   s
zakazchikom  opredelyayut sushchestvennye yuridicheskie,  kontraktnye, otchetnye  ili
finansovye  trebovaniya k  proektu. V  ostal'nyh  sluchayah  odin administrator
mozhet obsluzhivat' dve komandy.
     Redaktor. Obyazannost' razrabotki dokumentacii lezhit  na hirurge.  CHtoby
ona byla  maksimal'no  ponyatna, on  dolzhen  pisat' ee sam.  |to otnositsya  k
opisaniyam,  prednaznachennyh  kak  dlya  vneshnego,  tak   i  dlya   vnutrennego
ispol'zovaniya.  Zadacha  redaktora  - vzyat' sozdannyj  hirurgom  chernovik ili
zapis'   pod  diktovku,  kriticheski   pererabotat',  snabdit'   ssylkami   i
bibliografiej, prorabotat' neskol'ko versij i obespechit' publikaciyu.
     Dva sekretarya.  Administratoru i  redaktoru nuzhny sekretari.  Sekretar'
administratora  obrabatyvaet  perepisku,   svyazannuyu  s  proektom,  a  takzhe
dokumenty, ne otnosyashchiesya k produktu.
     Deloproizvoditel'. On otvechaet za registraciyu  vseh tehnicheskih  dannyh
brigady v biblioteke programmnogo produkta. On imeet sekretarskuyu podgotovku
i neset otvetstvennost' za vse fajly, prednaznachennye kak dlya mashiny, tak  i
dlya chteniya.
     Vse  dannye dlya vvoda  v komp'yuter postupayut deloproizvoditelyu, kotoryj
registriruet ih ili vvodit  pri neobhodimosti  s klaviatury. Listingi vyvoda
takzhe postupayut k nemu dlya registracii i  hraneniya. Rezul'taty  samyh svezhih
progonov vseh modelej zanosyatsya v zhurnal  rezul'tatov, a predydushchie hranyatsya
v hronologicheskom poryadke v arhive.
     ZHiznenno   vazhnym    dlya   koncepcii   Millza   yavlyaetsya    prevrashchenie
programmirovaniya  "iz  lichnogo  iskusstva v obshchestvennuyu deyatel'nost'" putem
predostavleniya  rezul'tatov vseh progonov  vsem chlenam komandy i opredeleniya
vseh  programm  i dannyh, kak  obshchej  sobstvennosti  komandy, a  ne  ch'ej-to
lichnoj.
     Osobye  obyazannosti,  vozlagaemye   na  deloproizvoditelya,  osvobozhdayut
aktivnyh programmistov  ot  rutinnyh rabot,  sistematiziruyut  i obespechivayut
nadlezhashchee vypolnenie teh rutinnyh operacij,  kotorymi chasto prenebregayut, i
priblizhayut glavnoe,  dlya  chego  rabotaet komanda  -  ee programmnyj produkt.
YAsno, chto predlozhennaya koncepciya predpolagaet progon paketnyh  zadanij. Esli
ispol'zuyutsya interaktivnye  terminaly, v osobennosti bez vozmozhnosti pechati,
funkcii deloproizvoditelya ne sokrashchayutsya,  no preterpevayut izmeneniya. V etom
sluchae on vedet uchet vseh izmenenij, vnosimyh v obshchij ekzemplyar programmy iz
lichnyh  kopij,  osushchestvlyaet  progon  vseh  paketnyh  zadanij  i  so  svoego
terminala    osushchestvlyaet    kontrol'    celostnosti   i   rabotosposobnosti
uvelichivayushchegosya v razmerah produkta.
     Instrumental'shchik.  Blagodarya  vozmozhnosti v  lyuboe  vremya redaktirovat'
fajly  i teksty i pol'zovat'sya sluzhboj  interaktivnoj otladki komande  redko
trebuetsya  svoya vychislitel'naya mashina i gruppa obsluzhivayushchego personala.  No
dostup k  etim  sluzhbam  dolzhen  osushchestvlyat'sya  s  bezuslovnoj  bystrotoj i
nadezhnost'yu.  Tol'ko  hirurg  mozhet  reshat',  udovletvoryaet  li  ego  rabota
imeyushchihsya   sluzhb.   Emu  neobhodim   instrumental'shchik,   otvetstvennyj   za
obespechenie dostupa  k osnovnym sluzhbam, a takzhe  za  sozdanie,  podderzhku i
obnovlenie  special'nyh  instrumentov  -  v osnovnom,  interaktivnyh  sluzhb,
kotorye   trebuyutsya  ego   komande.  U  kazhdoj  komandy   dolzhen  byt'  svoj
instrumental'shchik,   nezavisimo   ot   kachestva   i   nadezhnosti    imeyushchihsya
centralizovannyh  sluzhb,  i  ego   delo  obespechit'  vsem   neobhodimym  ili
zhelatel'nym   instrumentom   svoego   hirurga,   a   ne    drugie   komandy.
Instrumental'shchik obychno pishet specializirovannye utility, katalogizirovannye
procedury, makrobiblioteki.
     Otladchik. Hirurgu potrebuetsya nabor podhodyashchih kontrol'nyh primerov dlya
otladki napisannyh  im fragmentov koda,  a zatem  i vsej programmy. Otladchik
yavlyaetsya,  takim   obrazom,  kak  protivnikom,  razrabatyvayushchim  kontrol'nye
primery dlya sistemnogo testirovaniya,  ishodya iz funkcional'nyh specifikacij,
tak i  pomoshchnikom, gotovyashchim  dannye dlya ezhednevnoj otladki. On takzhe obychno
planiruet posledovatel'nost' testirovaniya i sozdanie sredy  dlya testirovaniya
komponentov.
     YAzykoved. Vskore posle poyavleniya Algol obnaruzhilos', chto v  bol'shinstve
vychislitel'nyh centrov est'  odin-dva  cheloveka, porazhayushchih svoim  vladeniem
tonkostyami yazyka programmirovaniya. |ti eksperty okazyvayutsya ochen' poleznymi,
i s nimi  chasto sovetuyutsya. Zdes'  trebuetsya  inoj talant,  chem  u  hirurga,
kotoryj   yavlyaetsya  preimushchestvenno  sistemnym  proektirovshchikom   i   myslit
predstavleniyami.  YAzykoved  mozhet  najti  effektivnye  sposoby ispol'zovaniya
yazyka dlya resheniya slozhnyh, neyasnyh  i hitroumnyh zadach. Inogda emu trebuetsya
provesti  nebol'shoe  issledovanie  (dva-tri  dnya)  dlya   nahozhdeniya  udachnoj
tehnologii. Odin yazykoved mozhet rabotat' s dvumya ili tremya hirurgami.
     Vot takim obrazom 10 chelovek mogut vypolnyat' horosho  differencirovannye
i specializirovannye roli v komande programmistov, organizovannoj po obrazcu
operacionnoj brigady.
     Kak eto rabotaet
     Sozdannaya  nami  brigada  mozhet  dostich'  zhelaemoj  celi  neskol'kimi
sposobami.   Nad  zadachej   trudyatsya   desyat'   chelovek,  sem'   iz  kotoryh
professionaly,  no  sistema yavlyaetsya produktom odnogo uma,  po krajnej  mere
dvuh, dejstvuyushchih uno animo (kak odno celoe).
     Obratite   osoboe  vnimanie  na   razlichie   mezhdu   gruppoj   iz  dvuh
programmistov s obychnoj organizaciej i gruppoj tipa "hirurg - vtoroj pilot".
Vo-pervyh, v obychnoj brigade rabotniki delyat zadachu mezhdu soboj, i kazhdyj iz
nih otvechaet za zamysel i voploshchenie nekotoroj chasti. V operacionnoj brigade
i hirurg,  i  vtoroj  pilot  nahodyatsya  v  vedenii  vsego  proekta  i  vsego
programmnogo koda. |to sberigaet zatraty  na  raspredelenie pamyati, dostup k
diskam i t.p., a takzhe obespechivaet konceptual'nuyu celostnost' produkta.
     Vo-vtoryh,  v obychnoj brigade partnery  ravny, i neizbezhnye raznoglasiya
dolzhny razreshat'sya putem  peregovorov ili  kompromissov.  Poskol'ku zadacha i
resursy razdeleny, raznoglasiya otnosyatsya k obshchej strategii i interfejsam, no
k  nim  primeshivaetsya  i protivopolozhnost' interesov,  naprimer,  ch'yu pamyat'
ispol'zovat' dlya  bufera. V hirurgicheskoj brigade razlichij  interesov net, a
raznoglasiya  edinolichno reshayutsya  hirurgom. |ti dva  razlichiya  -  otsutstvie
razbieniya zadachi i otnoshenie podchinennosti - pozvolyayut hirurgicheskoj brigade
dejstvovat' uno animo.
     Krome togo,  reshayushchee vliyanie na effektivnost'  okazyvaet specializaciya
funkcij  ostal'nyh   chlenov  brigady,  tak   kak  v  rezul'tate  osushchestvima
znachitel'no  bolee  prostaya  shema  kontaktov  mezhdu  sotrudnikami,  kotoraya
pokazana na risunke 3.1.
     V stat'e Bejkera3 soobshchaetsya ob odnoj proverke takoj koncepcii brigady,
provedennoj v  ogranichennom  masshtabe.  Kak  i  predskazyvalos',  rezul'taty
okazalis' velikolepnymi.
     Masshtabirovanie
     Do sih  por  vse bylo  horosho. Problema, odnako, sostoit  v  tom,  kak
sozdavat'  produkty,  na  kotorye  sejchas  uhodit  ne  20  ili  30,  a  5000
cheloveko-let. Brigada iz 10 chelovek mozhet byt' effektivna vne zavisimosti ot
svoej  organizacii,  esli zadacha  celikom nahoditsya v ee kompetencii. No kak
ispol'zovat'  ideyu operacionnoj  brigady v  zadachah, dlya  vypolneniya kotoryh
privlekayutsya sotni lyudej?
     Uspeh   pri   masshtabirovanii   obuslovlivaetsya   korennym   uluchsheniem
konceptual'nogo edinstva  kazhdogo  uchastka, ved'  kolichestvo proektirovshchikov
umen'shilos'  v  sem' raz.  Poetomu  mozhno privlech' k rabote nad zadachej  200
chelovek, i neobhodimost' koordinacii umstvennyh usilij potrebuetsya vsego dlya
20 iz nih - hirurgov.

     

     Ris. 3.1 Shema kontaktov mezhdu sotrudnikami v brigade iz 10 chelovek
     Odnako  zadacha  koordinacii   trebuet   ispol'zovaniya  osobyh  metodov,
obsuzhdaemyh v posleduyushchih glavah. Poka dostatochno skazat', chto vsya sistema v
celom  dolzhna  obladat'  konceptual'nym  edinstvom,  i  neobhodim  sistemnyj
arhitektor, chtoby  proektirovat'  ee celikom, v nishodyashchem  napravlenii. Dlya
togo chtoby  etoj  rabotoj mozhno bylo upravlyat', neobhodimo provesti  strogoe
razgranichenie  arhitektury  i  voploshcheniya,  i  sistemnyj  arhitektor  dolzhen
dobrosovestno  posvyatit' sebya razrabotke arhitektury.  Opyt pokazyvaet,  chto
takoe  raspredelenie rolej i takie  metody osushchestvimy i  okazyvayutsya ves'ma
rezul'tativnymi.


    Glava   4.  Aristokratiya,  demokratiya   i  sistemnoe  proektirovanie

     |tot
velichestvennyj   hram  yavlyaetsya   vydayushchimsya   proizvedeniem   iskusstva.  V
principah, kotorye on izlagaet, net ni suhosti, ni besporyadka...
     |to  vershina  stilya, trud hudozhnikov,  kotorye  ponyali i vosprinyali vse
dostizheniya  svoih  predshestvennikov, v sovershenstve  vladeya  tehnikoj svoego
veka, no pol'zovalis'  ej,  izbegaya  neskromnogo  pokaza  ili neobosnovannoj
demonstracii masterstva.
     Nesomnenno, zamysel  obshchego  plana zdaniya prinadlezhit dOrbe, i te,  kto
ego  smenil,  priderzhivalis' etogo plana,  po krajnej  mere,  v sushchestvennyh
chertah. |to odna iz prichin udivitel'noj garmonichnosti i edinstva zdaniya.
     PUTEVODITELX PO REJMSKOMU SOBORU 1
     Konceptual'noe edinstvo
     U  bol'shinstva  evropejskih  soborov  chasti,   postroennye   raznymi
pokoleniyami stroitelej, imeyut razlichiya  v  planirovke i arhitekturnom stile.
Bolee   pozdnie  stroiteli  ispytyvali   soblazn  "uluchshit'"  proekt   svoih
predshestvennikov, chtoby  otrazit' novye veyaniya  mody i svoi lichnye vkusy.  V
itoge mirnyj normannskij  transept  sozdaet konflikt  s primykayushchim  k  nemu
voznosyashchimsya  v  vys'  goticheskim   nefom,   i  rezul'tat  stol'  zhe  sluzhit
voshvaleniyu slavy Gospodnej, skol' i gordyni stroitelej.
     Arhitekturnoe   edinstvo   Rejmskogo   sobora   nahoditsya    v   pryamoj
protivopolozhnosti s  takim smesheniem stilej. Istochnikom  napolnyayushchej zritelya
radosti  sluzhat  kak   cel'nost'  konstrukcii,  tak  i   otdel'nye   obrazcy
sovershenstva.  Kak  skazano   v  putevoditele,   cel'nost'  byla  dostignuta
blagodarya  samootrecheniyu  vos'mi pokolenij stroitelej sobora, pozhertvovavshih
svoimi ideyami radi chistoty obshchego zamysla. To chto poluchilos'  v  rezul'tate,
sluzhit  voshvaleniyu   ne  tol'ko  slavy  Gospodnej,  no  i  Ego  mogushchestva,
sposobnogo spasti greshnyh lyudej ot ih gordyni.
     Hotya na sozdanie programmnyh sistem ne uhodyat veka, v bol'shinstve svoem
oni demonstriruyut  men'shuyu  soglasovannost' koncepcij,  chem  v lyubom sobore.
Obychno eto  proishodit  ne ottogo, chto  glavnye  proektirovshchiki smenyayut drug
druga,  a potomu, chto proekt  rasshcheplyaetsya na ryad zadach, vypolnyaemyh raznymi
razrabotchikami.
     YA   ubezhden,   chto   konceptual'naya   celostnost'   yavlyaetsya  vazhnejshej
harakteristikoj  sistemnogo  proekta.  Luchshe  ubrat'  iz  sistemy  otdel'nye
neobychnye  vozmozhnosti  i  usovershenstvovaniya  i  realizovat'  edinyj  nabor
konstruktivnyh   idej,    chem    osnastit'   ee    mnogimi    horoshimi,   no
nevzaimosvyazannymi i  nesoglasovannymi ideyami. V  etoj  i  dvuh  posleduyushchih
glavah  my izuchim sledstviya etoj  koncepcii  dlya proektirovaniya  programmnyh
sistem:
     - Kak dostich' konceptual'noj celostnosti?
     -   Ne   budet  li   eto   trebovanie  prichinoj   raskola   na   elitu,
aristokraticheskij  klass   arhitektorov   -   s   odnoj   storony,  i  tolpy
plebeev-ispolnitelej, ch'i tvorcheskie talanty i idei podavlyayutsya, - s drugoj?
     -  Kak  uderzhat'  arhitektorov  ot  vitaniya   v  oblakah  i  razrabotki
nesushchestvennyh ili chrezmerno dorogih specifikacij?
     -  Kak dobit'sya  togo,  chtoby  lyubaya  meloch' iz sozdannoj  arhitektorom
specifikacii doshla do ispolnitelya, byla im pravil'no ponyata i tochno vnedrena
v produkt?
     Dostizhenie konceptual'noj celostnosti
     Naznachenie  sistemy   programmirovaniya  -   oblegchit'  ispol'zovanie
komp'yutera. Dlya  etogo  postavlyayutsya yazyki i razlichnye sredstva, yavlyayushchiesya,
po suti, programmami, vyzyvaemymi i upravlyaemymi vozmozhnostyami yazyka. No eti
sredstva  stoyat deneg:  ob®em vneshnego opisaniya sistemy  programmirovaniya  v
desyat'-  dvadcat'  raz  bol'she opisaniya sobstvenno  vychislitel'noj  sistemy.
Pol'zovatelyu  okazyvaetsya znachitel'no proshche zadat' lyubuyu  vybrannuyu funkciyu,
no  vybor  ochen'  velik, i  nuzhno  pomnit'  znachitel'no bol'she  variantov  i
formatov.
     Ispol'zovanie oblegchaetsya,  tol'ko  esli  vyigrysh  vremeni  pri zadanii
funkcii  prevyshaet  vremya, potrachennoe  na  obuchenie,  zapominanie  i  poisk
rukovodstv.  Sovremennye sistemy  programmirovaniya  dayut takoj  vyigrysh,  no
pohozhe,  chto v poslednie gody  otnoshenie  vyigrysha k zatratam  umen'shilos' v
rezul'tate dobavleniya vse bolee i  bolee slozhnyh funkcij. YA chasto vspominayu,
kak  legko  bylo ispol'zovat'  IBM  650,  dazhe  bez  assemblera  ili  voobshche
kakih-libo programm.
     Poskol'ku   cel'yu  proektirovaniya   yavlyaetsya   prostota  ispol'zovaniya,
okonchatel'nuyu    ocenku   proekta   sistemy   daet   dostignutoe   otnoshenie
funkcional'nosti k slozhnosti koncepcij.  Ni funkcional'nost', ni  prostota v
otdel'nosti ne yavlyayutsya priznakami horoshego proekta.
     |to  obstoyatel'stvo chasto nepravil'no ponimaetsya. Operating  System/360
prevoznositsya  svoimi  sozdatelyami,  kak  luchshaya  iz  kogda-libo  sozdannyh,
poskol'ku  neosporimo,  chto  v nej  bol'she  funkcij.  Funkcii, a ne prostota
vsegda  sluzhili kriteriem  prevoshodstva  ee  sozdatelej. S drugoj  storony,
sozdateli   sistemy   s   razdeleniem  vremeni  dlya  PDP-10  prevoznosyat  ee
prevoshodstvo vvidu prostoty i nemnogochislennosti polozhennyh  v osnovu idej.
Odnako po vsem merkam ee funkcional'nost' nizhe po klassu, chem OS/360. Esli v
kachestve kriteriya  opredelena prostota  ispol'zovaniya, stanovitsya  ochevidnoj
nesbalansirovannost' etih sistem, dostigayushchih celi lish' napolovinu.
     Odnako  dlya   nekotorogo   zadannogo  urovnya   funkcional'nosti  luchshej
okazyvaetsya ta sistema, v  kotoroj  mozhno  rabotat' s naibol'shej prostotoj i
neposredstvennost'yu. Prostota - eto eshche ne vse. YAzyk TRAC, sozdannyj Muerom,
i  Algol  68  dostigayut  prostoty, esli  kolichestvenno  izmeryat'  ee  chislom
otdel'nyh elementarnyh  ponyatij. Neposredstvennost',  odnako,  ne harakterna
dlya nih. CHtoby vyrazit' svoi  namereniya, chasto  trebuetsya  sochetat'  bazovye
sredstva   slozhnym  i  neozhidannym  obrazom.  Nedostatochno  izuchit'  bazovye
elementy i  pravila ih  kombinirovaniya,  nuzhno  izuchit'  eshche  idiomaticheskoe
ispol'zovanie,  celuyu  oblast' znanij o  tom, kak na praktike  kombinirovat'
elementy.  Prostota  i  neposredstvennost'   proistekayut  iz  konceptual'noj
celostnosti.  Vo  vseh  chastyah  dolzhny  najti  otrazhenie edinaya filosofiya  i
edinoobraznye proporcii  mezhdu zhelaemymi celyami. V kazhdoj chasti dolzhny takzhe
ispol'zovat'sya  odinakovyj  sintaksis i  shodnye  semanticheskie oboznacheniya.
Takim   obrazom,   prostota   ispol'zovaniya    trebuet   edinstva   proekta,
konceptual'noj celostnosti.
     Aristokratiya i demokratiya
     Konceptual'naya celostnost', v  svoyu  ochered',  trebuet, chtoby  proekt
ishodil  ot  odnogo  razrabotchika,  ili  nebol'shogo  chisla  ih,  dejstvuyushchih
soglasovanno i v unison.
     S  drugoj storony, napryazhennost' grafika trebuet  privlecheniya  bol'shogo
chisla rabotnikov.  Est' dva metoda razresheniya etoj dilemmy. Pervyj sostoit v
tshchatel'nom razdelenii truda mezhdu arhitekturoj i ispolneniem. Vtoroj - novyj
sposob  organizacii   brigad  programmistov-ispolnitelej,   obsuzhdavshijsya  v
predydushchej glave. 31 Otdelenie razrabotki arhitektury ot realizacii yavlyaetsya
effektivnym  sposobom  dostizheniya  konceptual'noj celostnosti pri rabote nad
ochen' bol'shimi proektami.  YA lichno  byl svidetelem  uspeshnogo ego primeneniya
pri sozdanii IBM komp'yutera Stretch  i serii  produktov System/360. No on ne
srabotal  pri   razrabotke  Operating   System/360,  poskol'ku  nedostatochno
primenyalsya.
     Pod  arhitekturoj  sistemy  ya  ponimayu polnuyu i podrobnuyu  specifikaciyu
interfejsa pol'zovatelya. Dlya komp'yutera eto rukovodstvo po programmirovaniyu.
Dlya  kompilyatora  eto  rukovodstvo  po  yazyku. Dlya upravlyayushchej programmy eto
rukovodstvo  po  odnomu  ili neskol'kim  yazykam, ispol'zuemym dlya  vyzova ee
funkcij. Dlya  sistemy v celom - eto nabor vseh  rukovodstv, k kotorym dolzhen
obrashchat'sya pol'zovatel' pri rabote.
     Arhitektor sistemy,  kak  i arhitektor  zdaniya, yavlyaetsya predstavitelem
pol'zovatelya.  Ego  zadacha  -   ispol'zovat'  vse  svoi  professional'nye  i
tehnicheskie znaniya  isklyuchitel'no v interesah  pol'zovatelya,  a ne prodavca,
izgotovitelya i t.p.2
     Arhitektura i razrabotka  dolzhny byt' tshchatel'no  razdeleny. Kak  skazal
Blau (Blaauw),  "arhitektura govorit, chto dolzhno proizojti,  a razrabotka  -
kak sdelat', chtoby  eto proizoshlo".3 V kachestve prostogo primera on privodit
chasy, arhitektura kotoryh sostoit iz ciferblata, strelok i zavodnoj golovki.
Rebenok,  osvoivshij  eto  arhitekturu,  s odinakovoj  legkost'yu mozhet uznat'
vremya  i po  ruchnym chasam,  i  po chasam  na kolokol'ne. Ispolnenie zhe i  ego
realizaciya opisyvayut,  chto  proishodit  vnutri: peredacha usilij i upravlenie
tochnost'yu kazhdym iz mnogih mehanizmov.
     K  primeru, v System/360 odna i ta zhe arhitektura komp'yutera sovershenno
po-  raznomu realizovana primerno v devyati modelyah. Obratnym obrazom, odna i
ta  zhe  realizaciya  potoka  dannyh,  pamyati  i  mikroprogramm  iz  Model  30
ispol'zovalas' v raznoe vremya v  chetyreh razlichnyh arhitekturah: System/360,
mul'tipleksnom   kanale  s   podklyucheniem   do  224   logicheski  nezavisimyh
podkanalov, selektornom kanale i komp'yutere 1401.4
     Takie zhe  razlichiya mozhno provodit' v otnoshenii sistem programmirovaniya.
Sushchestvuet standart  dlya Fortran IV. |to arhitektura, ispol'zuemaya vo mnogih
kompilyatorah. V ramkah etoj arhitektury vozmozhny raznye  realizacii: tekst v
operativnoj    pamyati    ili   kompilyator,   bystraya   ili   optimiziruyushchaya,
sintaksicheskaya  ili  ad  hoc. Analogichno,  lyuboj  yazyk assemblera  ili  yazyk
upravleniya   zadaniyami   dopuskaet    mnogie   realizacii   assemblera   ili
planirovshchika.
     Teper'  my   mozhem   zanyat'sya  ves'ma  chuvstvitel'nym  voprosom  bor'by
aristokratii  i demokratii. Ne  stali li  arhitektory  novoj  aristokratiej,
intellektual'noj    elitoj,   prizvannoj   raz®yasnit'   bednym    bezglasnym
ispolnitelyam,  chto  oni  dolzhny  delat'?  Ne  zahvatila  li  eta  elita  vsyu
tvorcheskuyu deyatel'nost', sdelav  ispolnitelej lish' zubchikami v mehanizme? Ne
okazhetsya li, chto bolee  sovershennyj  produkt mozhno poluchit',  ispol'zuya idei
vsej  brigady  i  ispoveduya  filosofiyu demokratii,  a  ne  ogranichivaya  krug
razrabotchikov neskol'kimi licami?
     Proshche  vsego  otvetit' na  poslednij  vopros. YA, razumeetsya,  ne  stanu
utverzhdat',  chto  horoshie  arhitekturnye  idei  mogut  voznikat'  tol'ko   u
arhitektorov.  CHasto svezhaya ideya ishodit  ot  ispolnitelya  ili pol'zovatelya.
Odnako  ves'  lichnyj  opyt  ubezhdaet  menya,  i ya pytalsya  eto  pokazat', chto
prostotu  pol'zovaniya  sistemoj opredelyaet  ee  konceptual'naya  celostnost'.
Dostojnye vnimaniya  funkcii  i  idei,  kotorye  ne ob®edinyayutsya s  osnovnymi
koncepciyami  sistemy, luchshe  ostavit'  v  storone.  Esli  takih  vazhnyh,  no
nesovmestimyh  idej  poyavlyaetsya  slishkom  mnogo,  vykidyvayut vsyu  sistema  i
nachinayut  razrabotku   celostnoj  sistemy  snachala,  osnovyvaya  ee  na  inyh
osnovopolagayushchih koncepciyah.
     CHto  kasaetsya obvinenij  v  aristokratizme, to otvet i polozhitel'nyj, i
otricatel'nyj. Polozhitel'nyj, potomu chto dejstvitel'no dolzhno byt' neskol'ko
arhitektorov,  ch'i  rezul'taty  zhivut  dol'she, chem  otdel'nye realizacii,  i
arhitektor  nahoditsya  v fokuse  sil, kotorye  on  v  konechnom itoge  dolzhen
ispol'zovat'  v  interesah  pol'zovatelya.  Esli  vy  hotite,  chtoby  sistema
obladala  konceptual'noj  celostnost'yu,  to  rukovodstvo koncepciyami  dolzhen
vzyat' kto-to odin. |to aristokratizm, kotoryj ne nuzhdaetsya v izvineniyah.
     Otvet otricatel'nyj,  poskol'ku  razrabotka  proekta trebuet  ne men'she
tvorchestva, chem zadanie vneshnih specifikacij. |to tozhe tvorcheskaya rabota, no
drugogo haraktera.  Razrabotka  proekta  dlya zadannoj arhitektury trebuet  i
dopuskaet stol'ko zhe tvorcheskoj deyatel'nosti, novyh idej, izobretatel'nosti,
kak   i    proekt    vneshnih    specifikacij.    Prakticheski,    koefficient
stoimost'/effektivnost' sozdannogo produkta bol'she zavisit ot ispolnitelya, a
prostota ego ispol'zovaniya - ot arhitektora.
     Est'  massa  primerov,  podskazannyh  drugimi iskusstvami i  remeslami,
kotorye  podvodyat k mneniyu,  chto disciplina  idet na  pol'zu. Dejstvitel'no,
aforizm hudozhnika  glasit, chto "forma osvobozhdaet".  Samye uzhasny stroeniya -
eto te, byudzhet kotoryh byl  slishkom velik dlya postavlennyh celej. Tvorcheskuyu
aktivnost'  Baha  edva   li  mogla  podavlyat'   neobhodimost'   ezhenedel'naya
neobhodimost'  izgotavlivat'  kantatu  opredelennogo  vida.  YA  uveren,  chto
arhitektura komp'yutera Stretch stala by luchshe, esli by na nee nalozhili bolee
zhestkie  ogranicheniya;  tak,  ogranicheniya, nalozhennye byudzhetom na  System/360
Model 30, po moemu mneniyu, prinesli lish' pol'zu arhitekture Model 75.
     Analogichno, ya  schitayu, chto poluchenie  arhitektury izvne usilivaet, a ne
podavlyaet   tvorcheskuyu   aktivnost'   gruppy    ispolnitelej.   Oni    srazu
sosredotochivayutsya na  toj chasti  zadachi, kotoroj  nikto  ne  zanimalsya, i  v
rezul'tate izobretatel'nost' b'et klyuchom. V ne ogranichivaemoj gruppe bol'shaya
chast'  obdumyvaniya  i obsuzhdeniya posvyashchena  arhitekturnym resheniyam  v  ushcherb
realizacii.5
     |tot mnogokratno nablyudavshijsya mnoj effekt podtverdil R. U. Konvej  (R.
W.  Conway), ch'ya gruppa  razrabotala  v  Kornel'skom universitete kompilyator
PL/C dlya yazyka  PL/I.  On govorit: "V konechnom  itoge my reshili  realizovat'
yazyk bez izmenenij i usovershenstvovanij,  poskol'ku obsuzhdenie yazyka  otnyalo
by u nas vse sily."6
     CHem zanyat'sya razrabotchiku, poka on vynuzhden zhdat'?
     Ochen'  nepriyatno sovershit'  oshibku stoimost'yu v  million dollarov, no
zato  ona nadolgo zapominaetsya. YA otchetlivo pomnyu tot den', kogda my prinyali
reshenie o tom, kak prakticheski organizovat' sostavlenie vneshnih specifikacij
dlya  OS/360. Menedzher  po  arhitekture, menedzher po  realizacii  upravlyayushchej
programmy i ya prorabatyvali plan, grafik i razdelenie obyazannostej.
     U menedzhera  po arhitekture bylo 10 horoshih specialistov. On utverzhdal,
chto oni v sostoyanii napisat' specifikacii i sdelat' eto dolzhnym obrazom. |to
dolzhno bylo zanyat' 10 mesyacev - na tri bol'she, chem otvodilos' po grafiku.
     U  menedzhera po realizacii upravlyayushchej programmy bylo  150 chelovek.  On
zayavlyal,  chto   oni  mogut   podgotovit'   specifikacii,   pri  etom  gruppa
arhitektorov  vypolnyala by koordiniruyushchie funkcii. Obeshchalos', chto eto  budet
sdelano horosho i praktichno, s soblyudeniem srokov. Bolee togo,  esli ostavit'
specifikacii  gruppe arhitektorov, ego  150 chelovek v techenie desyati mesyacev
budut bit' baklushi.
     Na   eto   menedzher  po  arhitekture   vozrazil,  chto  esli  ya   sdelayu
otvetstvennoj  za  napisanie  specifikacij gruppu upravlyayushchej  programmy, to
rezul'tata v  srok  ne budet: on  vse ravno zaderzhitsya na  tri mesyaca, no po
kachestvu budet  mnogo  huzhe.  Tak  ono  i  okazalos' v dejstvitel'nosti.  On
okazalsya prav v oboih punktah. Krome  togo, iz-za otsutstviya  konceptual'noj
celostnosti sozdanie i vnesenie  izmenenij v  sistemu  okazalis' znachitel'no
bolee dorogostoyashchimi, i, po moim ocenkam, otladka udlinilas' na god.
     Konechno, mnogie faktory povliyali  na prinyatie etogo oshibochnogo resheniya,
no opredelyayushchimi byli zhelanie ulozhit'sya v grafik i stremlenie zanyat' rabotoj
etih 150 chelovek. Penie etih siren tait  smertel'nye opasnosti, kotorye  ya i
hochu sejchas pokazat'.
     Kogda predlagaetsya, chtoby vse vneshnie specifikacii dlya komp'yuternoj ili
programmnoj  sistemy   byli   sostavleny  nebol'shoj  komandoj  arhitektorov,
ispolniteli vydvigayut tri vozrazheniya:
     -  Specifikacii  budut  peregruzheny  funkciyami  i  ne  budut  uchityvat'
prakticheskih zatrat na realizaciyu.
     -   Arhitektory   poluchat   vse  radosti   tvorchestva   i   zablokiruyut
izobretatel'nost' ispolnitelej.
     -  Mnogochislennym  ispolnitelyam  pridetsya ozhidat'  v  prazdnosti,  poka
specifikacii projdut cherez uzkoe gorlyshko komandy arhitektorov.
     Pervoe  vozrazhenie otrazhaet real'nuyu opasnost'  i  budet rassmotreno  v
sleduyushchej glave. Ostal'nye dva yavlyayutsya chistym zabluzhdeniem.  Kak  my videli
vyshe,  razrabotka takzhe yavlyaetsya v vysshej stepeni tvorcheskoj  deyatel'nost'yu.
Vozmozhnost'   proyavit'  tvorchestvo   i  izobretatel'nost'   pri   razrabotke
neznachitel'no  ogranichivaetsya  neobhodimost'yu  rabotat'  v  ramkah  zadannyh
vneshnih  specifikacij,  i  takaya  disciplina  mozhet  dazhe   usilit'  stepen'
tvorchestva. |to, nesomnenno, verno dlya proekta v celom.
     Poslednee  vozrazhenie kasaetsya planirovaniya  vremennyh  ramok i etapov.
Proshche vsego vozderzhat'sya  ot  najma  ispolnitelej do  zaversheniya raboty  nad
specifikaciyami. Kogda vozdvigaetsya zdanie, tak i postupayut.
     Odnako  pri  sozdanii  komp'yuternyh sistem  tempy  vyshe,  i  zhelatel'no
uplotnit' grafik rabot.  V kakoj mere razrabotka  specifikacij  i razrabotka
mogut perekryvat'sya?
     Kak  otmechaet  Blau, vsyu programmu  sozdaniya  sostavlyayut tri  otdel'nye
stadii: arhitektura, razrabotka i realizaciya.  Okazyvaetsya, chto na  praktike
ih  mozhno  nachinat'  parallel'no i prodolzhat'  odnovremenno.  Naprimer,  pri
proektirovanii  komp'yuterov proektirovshchik  mozhet pristupat'  k rabote,  imeya
otnositel'no obshchie dopushcheniya v otnoshenii rukovodstva pol'zovatelya, neskol'ko
bolee yasnye  idei otnositel'no tehnologii  i vpolne  opredelennye  zadachi po
stoimosti i rabochim harakteristikam. On mozhet nachat'  proektirovanie potokov
dannyh,  upravlyayushchih posledovatel'nostej, obshchih idej  komponovki i  t.d.  On
razrabatyvaet ili adaptiruet neobhodimyj  instrumentarij,  osobenno  sistemu
vedeniya ucheta, v tom chisle sistemu avtomatizacii proektirovaniya.
     V   to   zhe   vremya  na   urovne   realizacii   nuzhno   sproektirovat',
usovershenstvovat'  i  opisat'  mikroshemy,  platy,  kabeli,  karkasy,  bloki
pitaniya i ustrojstva pamyati. |ta rabota protekaet parallel'no s arhitekturoj
i razrabotkoj.
     To zhe samoe spravedlivo  pri  sozdanii programmnyh  sistem. Zadolgo  do
zaversheniya vneshnih specifikacij  proektirovshchik mozhet  najti  sebe dostatochno
raboty.  On  mozhet  pristupit' k  delu,  osnovyvayas'  na grubom  priblizhenii
funkcional'nosti  sistemy,  kotoraya  v  konechnom  itoge budet  voploshchena  vo
vneshnih specifikaciyah. U nego dolzhny byt' yasno opredelennye celi v otnoshenii
pamyati i vremennyh  parametrov. On  dolzhen izuchit' konfiguraciyu sistemy,  na
kotoroj  budet  vypolnyat'sya ego produkt.  Zatem on mozhet nachat'  opredelenie
granic   modulej,  struktur  tablic,  raschleneniya  na  prohody   ili  stadii
algoritmov i  vsevozmozhnyh  instrumental'nyh  sredstv.  Nekotoroe  vremya  on
dolzhen takzhe posvyatit' obshcheniyu s arhitektorom.
     V   to  zhe  vremya   dostatochno   raboty  i  na  urovne   realizacii.  U
programmirovaniya  svoya tehnologiya. Esli  mashina  novaya, mnogo  truda trebuyut
soglasheniya  po  podprogrammam, tehnologiya  raboty s supervizorom,  algoritmy
poiska i sortirovki.7
     Konceptual'naya  celostnost'  trebuet,  chtoby  sistema  otrazhala  edinuyu
filosofiyu,  i tehnicheskie  usloviya, v tom  vide, v kotorom  oni  budut vidny
pol'zovatelyu,  proistekali ot malogo  chisla avtorov.  |to  ne oznachaet,  chto
sproektirovannaya   takim   obrazom  sistema   sozdaetsya   dol'she,  poskol'ku
ispol'zuetsya  dejstvitel'noe razdelenie truda  na arhitekturu,  razrabotku i
realizaciyu. Opyt pokazyvaet obratnoe: cel'naya sistema prodvigaetsya bystree i
trebuet  men'she vremeni  dlya otladki. V  rezul'tate  shiroko rasprostranennoe
gorizontal'noe   razdelenie   truda   znachitel'no   sokrashchaetsya   za    schet
vertikal'nogo razdeleniya, chto vlechet  rezkoe umen'shenie obmena informaciej i
uluchshenie konceptual'noj celostnosti.


    Glava 5. |ffekt vtoroj sistemy

     Adde parvum parvo magnus acervus erit.
     [Skladyvaj maloe s malym, i poluchish' bol'shuyu kuchu.]
     OVIDIJ
     Esli   otvetstvennost'   za   specifikaciyu   funkcij   otdelit'   ot
otvetstvennosti  za  bystroe sozdanie  nedorogogo produkta, to chem  sderzhat'
izobretatel'skij entuziazm arhitektora?
     Principial'noe  reshenie  -  obespechenie  vsestoronnego,  tshchatel'nogo  i
dobrozhelatel'no  obmena  informaciej  mezhdu  arhitektorom  i  razrabotchikom.
Odnako imeyutsya i bolee tonkie resheniya, kotorye zasluzhivayut vnimaniya.
     Disciplina vzaimodejstviya dlya arhitektora
     Arhitektor,  stroyashchij  zdanie,  dejstvuet  v ramkah smety,  ispol'zuya
metody  ocenki,  kotorye  v  posleduyushchem  podtverzhdayutsya  ili korrektiruyutsya
zayavkami podryadchikov. CHasto sluchaetsya, chto vse predlozheniya vyhodyat  za ramki
smety. Togda  arhitektor  peresmatrivaet  svoi ocenki  v storonu  uvelicheniya
smety,  a  proekt  -  v  storonu  sokrashcheniya, i cikl povtoryaetsya. Inogda  on
predlagaet  podryadchikam  sposoby  udeshevleniya  realizacii   ego  proekta   v
sravnenii s izbrannymi imi sposobami.
     Shodnye processy proishodyat s arhitektorom komp'yuternyh ili programmnyh
sistem. Odnako u nego est' to preimushchestvo, chto predlozheniya podryadchika mozhno
poluchit'  na  rannih   stadiyah  proektirovaniya,  chasto  -  v  lyuboj  moment.
Nedostatkom obychno  yavlyaetsya to, chto rabota idet s edinstvennym podryadchikom,
kotoryj mozhet menyat' cenu  v  zavisimosti ot stepeni svoej udovletvorennosti
proektom.  Na  praktike,  process  obshcheniya,  nachatyj  na   rannih  etapah  i
prodolzhayushchijsya nepreryvno, mozhet dat' arhitektoru vernuyu ocenku stoimosti, a
razrabotchiku   -   uverennost'  v  proekte,  ne   snimaya  pri  etom  chetkogo
razgranicheniya sfer otvetstvennosti.
     U  arhitektora, kogda on stalkivaetsya s nepriemlemo vysokoj stoimost'yu,
est' dva vyhoda: sokratit' proekt ili vozdejstvovat' na stoimost', predlagaya
bolee deshevye  sposoby realizacii. Vtoroj sposob  neizbezhno vyzyvaet emocii,
ved'  arhitektor osparivaet  to,  kak stroitel' spravlyaetsya so  svoim delom.
CHtoby uspeshno spravit'sya s etim, arhitektoru neobhodimo:
     -  pomnit',  chto  otvetstvennost'  za  izobretatel'nost' i  tvorchestvo,
proyavlyaemye pri realizacii, neset  stroitel', poetomu arhitektor predlagaet,
a ne trebuet;
     -  vsegda  byt'  gotovym predlozhit'  nekotoryj sposob  realizacii svoih
zamyslov i  byt' gotovym soglasit'sya s  lyubym  drugim  sposobom, pozvolyayushchim
reshit' zadachu ne huzhe;
     - vydvigaya takie predlozheniya, dejstvovat' bez shuma i oglaski;
     - ne rasschityvat' na priznatel'nost' za sdelannye predlozheniya.
     Obychno razrabotchik pariruet predlozheniem izmenenij v arhitekture. CHasto
on prav  -  realizaciya kakoj-nibud' malosushchestvennoj detali  mozhet okazat'sya
neozhidanno dorogostoyashchej.
     Samodisciplina - effekt vtoroj sistemy
     Pervyj proekt arhitektora stremitsya k skromnosti i yasnosti. Arhitektor
ponimaet,  chto  ne znaet,  chem zanimaetsya,  poetomu  on  zanimaetsya etim  so
staraniem i samoogranicheniem.
     Pri rabote nad pervym proektom emu postoyanno prihodyat v golovu to odni,
to  drugie  "ukrasheniya".  Oni  otkladyvayutsya v storonu dlya ispol'zovaniya  "v
sleduyushchij raz". V konce koncov,  pervaya sistema zakonchena,  i  arhitektor, s
tverdoj uverennost'yu v  sebe  i prodemonstrirovannym osvoeniem etogo  klassa
sistem, gotov k sozdaniyu novogo proekta.
     |ta vtoraya sistema tait  naibol'shie  opasnosti dlya proektirovshchika.  Pri
rabote nad tret'ej i posleduyushchimi  sistemami  zakreplyaetsya  poluchennyj ranee
opyt v  otnoshenii  obshchih  harakteristik takih sistem, a  razlichiya mezhdu nimi
vyyavlyayut te  chasti  opyta,  kotorye nosyat chastnyj harakter i  ne mogut  byt'
obobshcheny.
     Obshchaya tendenciya  zaklyuchaetsya v peregruzhennosti proekta  vtoroj  sistemy
ideyami i ukrashatel'stvami, blagorazumno otlozhennymi v storonu pri rabote nad
pervym proektom.  V  rezul'tate poluchaetsya, govorya slovami Ovidiya,  "bol'shaya
kucha".  Rassmotrim,  naprimer, arhitekturu  IBM  709, voploshchennuyu pozdnee  v
mashine  7090. |to - modernizaciya, vtorya sistema dlya ochen' uspeshnoj i  horosho
skroennoj  sistemy  704.  Nabor komand byl nastol'ko bogat i  izobilen,  chto
regulyarno ispol'zovalas' primerno lish' polovina ego.
     Rassmotrim  v kachestve bolee sil'nogo primera arhitekturu, razrabotku i
dazhe  realizaciyu  komp'yutera  Stretch,  kotorye  dali  vyhod  sderzhivayushchimsya
izobretatel'skim stremleniyam mnogih lyudej,  dlya bol'shinstva kotoryh eto bylo
vtoraya sistema. Vot chto pishet v svoem obzore Strejchi (Strachey):
     U menya  sozdalos' vpechatlenie,  chto  nekotorym  obrazom Stretch  yavlyaet
soboj okonchanie opredelennogo napravleniya razrabotok. Kak i nekotorye rannie
komp'yuternye programmy,  eta sistema chrezvychajno izobretatel'na, chrezvychajno
slozhna i ochen' effektivna, no v to zhe vremya yavlyaetsya syroj, rastochitel'noj i
neizyashchnoj, ostavlyaya oshchushchenie, chto eti veshchi mozhno delat' luchshim obrazom.1
     Operating   System/360  byla  vtoroj  sistemoj  dlya  bol'shinstva  svoih
proektirovshchikov.  Gruppy  proektirovshchikov prishli posle raboty  nad  diskovoj
operacionnoj  sistemoj  1410-7010, operacionnoj  sistemoj  Stretch, sistemoj
real'nogo  vremeni Project Mercury i  IBSYS dlya 7090. Edva  li kto-to iz nih
imel opyt raboty nad dvumya predshestvuyushchimi operacionnymi sistemami.  Poetomu
OS/360 yavlyaetsya  yarkim  primerom effekta vtoroj sistemy,  analogom Stretch v
iskusstve programmirovaniya, k kotoromu v polnoj mere primenimy i  pohvaly, i
upreki privedennoj kritiki Strejchi.
     Naprimer,  v  OS/360  otvoditsya  26  bajt  dlya  rezidentnoj   procedury
preobrazovaniya daty,  chtoby pravil'no obrabatyvat'  31  dekabrya v visokosnom
godu (kogda eto 366-j den'). |to mozhno bylo ostavit' operatoru.
     |ffekt  vtoroj  sistemy  imeet  i  drugoe  proyavlenie,  krome  prostogo
ukrashatel'stva  funkciyami.  |to  - sklonnost'  k usovershenstvovaniyu metodov,
samo sushchestvovanie kotoryh stalo anahronizmom blagodarya izmeneniyam v bazovyh
principah sistemy.  OS/360  soderzhit  mnogochislennye primery, podtverzhdayushchie
eto.
     Rassmotrim  redaktor  svyazej,  prednaznachennyj dlya  zagruzki nezavisimo
skompilirovannyh programm i razresheniya ih  perekrestnyh  ssylok. Pomimo etoj
osnovnoj  funkcii on  takzhe  upravlyaet programmnymi  overleyami.  |to odno iz
luchshih  kogda-libo  sozdannyh  sredstv raboty  s  overleyami.  Ono  pozvolyaet
sozdavat' overlejnuyu strukturu vneshnim obrazom pri redaktirovanii svyazej, ne
trogaya  ishodnogo  koda.  Ono  pozvolyaet  izmenyat'  strukturu  overleev  bez
perekompilyacii pri  kazhdom progone. Ono predostavlyaet bogatyj vybor poleznyh
opcij i  vozmozhnostej. V  izvestnom smysle, eto zavershayushchij itog mnogoletnej
razrabotki tehnologii staticheskih overleev.
     I  v  to  zhe  vremya eto  poslednij i sovershennejshij dinozavr, poskol'ku
vhodit  v sistemu, v kotoroj  mnogoprogrammnost' yavlyaetsya obychnym rezhimom, a
dinamicheskoe raspredelenie pamyati - bazovym principom. |to vstupaet v pryamoj
konflikt s  ponyatiem  ispol'zovaniya  staticheskih  overleev. Neskol'ko  luchshe
rabotala by  sistema, esli by  usiliya,  potrachennye na upravlenie overleyami,
byli  perenapravleny  na  to,   chtoby   uskorit'  rabotu  sredstv  podderzhki
dinamicheskogo raspredeleniya pamyati i perekrestnyh ssylok!
     Bolee togo, redaktor svyazej  trebuet  tak mnogo pamyati,  i sam soderzhit
stol'ko overleev, chto dazhe  pri ispol'zovanii tol'ko dlya redaktirovaniya  bez
upravleniya overleyami ustupaet v skorosti bol'shinstvu sistemnyh kompilyatorov.
Ironiya  sostoit v tom, chto naznachenie  redaktora svyazej - izbezhat' povtornoj
kompilyacii.  Kak  u  kon'kobezhca  korpus  okazyvaetsya  vperedi  nog,  tak  i
usovershenstvovaniya prodolzhalis',  poka ne vyshli  daleko  za ramki  sistemnyh
principov.
     Drugim   primerom   etoj   tendencii  yavlyaetsya  otladchik  TESTRAN.  |to
sovershennyj  paketnyj  otladchik,  predostavlyayushchij  dejstvitel'no  elegantnye
sredstva  polucheniya mgnovennyh  snimkov i dampov pamyati.  V nem ispol'zuetsya
ponyatie  upravlyayushchih razdelov i  iskusnaya tehnologiya  generacii, pozvolyayushchie
osushchestvlyat'  izbiratel'nuyu  trassirovku i poluchenie mgnovennyh  snimkov bez
dopolnitel'nyh  rashodov  na  interpretaciyu ili  rekompilyaciyu. Zdes'  pyshnym
cvetom rascveli  vpechatlyayushchie koncepcii operacionnoj sistemy Share Operating
System3 dlya modeli 709.
     Mezhdu tem ustarela sama ideya paketnoj otladki bez rekompilyacii. Glavnyj
vyzov  byl broshen interaktivnym  vychislitel'nym sistemam s  interpretatorami
yazykov programmirovaniya  i  poshagovymi kompilyatorami.  No dazhe v  sistemah s
paketnoj obrabotkoj poyavlenie kompilyatorov s bystroj kompilyaciej i medlennym
vypolneniem  sdelalo  bolee predpochtitel'noj  tehnologiyu  otladki  na urovne
ishodnogo koda i  polucheniya mgnovennyh snimkov. Naskol'ko luchshe okazalas' by
sistema, esli by sily, potrachennye na proekt TESTRAN, byli perenapravleny na
uskorennoe sozdanie  luchshih  sredstv  dlya  interaktivnoj  raboty  i  bystroj
kompilyacii!
     Eshche  odin  primer - planirovshchik, predostavlyayushchij dejstvitel'no otlichnye
vozmozhnosti   dlya  upravleniya  potokom  fiksirovannyh  paketov  zadanij.  Na
praktike   etot  planirovshchik  yavlyaetsya   usovershenstvovannoj,  uluchshennoj  i
nadelennoj  raznymi  ukrasheniyami  vtoroj  sistemoj,  kotoroj  predshestvovala
diskovaya  operacionnaya  sistema 1410-7010 - sistema paketnoj  obrabotki,  ne
yavlyayushchayasya mnogoprogrammnoj, za isklyucheniem vvoda-vyvoda, i prednaznachennoj,
glavnym obrazom,  dlya delovyh prilozhenij. V etom kachestve planirovshchik OS/360
horosh.  No  na nego  pochti nikakogo vliyaniya ne okazali potrebnosti  OS/360 v
udalennom  vvode  zadanij,   mnogoprogrammnosti   i  rezidentnom  razmeshchenii
interaktivnyh  podsistem.  I dejstvitel'no,  proekt  planirovshchika zatrudnyaet
reshenie etih zadach.
     Kak arhitektoru izbezhat' effekta vtoroj  sistemy? Ochevidno,  propustit'
svoyu  vtoruyu sistemu on ne mozhet. No on mozhet  otdavat' sebe otchet  v osobyh
opasnostyah,  kotorym   ona  ego   podvergaet,   i   proyavit'  dopolnitel'nuyu
samodisciplinu, chtoby izbezhat'  funkcional'nogo ukrashatel'stva i  sohraneniya
funkcij, nuzhda v kotoryh otpala vvidu izmenenij v principah i celyah.
     Poryadok, sposobnyj otkryt'  arhitektoru glaza, zaklyuchaetsya v tom, chtoby
prisvoit' chislennoe znachenie  kazhdoj, pust' maloj, funkcii: harakteristika x
dolzhna  obojtis'  ne bolee chem v  m  bajtov pamyati i  n mikrosekund na  odin
vyzov.  |ti  velichiny  dolzhny sluzhit' rukovodstvom  pri  prinyatii  nachal'nyh
reshenij, a takzhe napominaniem i rukovodstvom pri realizacii.
     Kak menedzheru proekta izbezhat'  effekta vtoroj  sistemy?  Nastaivat' na
tom, chtoby ego starshij arhitektor imel opyt  razrabotki hotya by dvuh sistem.
Krome  togo,  buduchi   osvedomlennym  o   vozmozhnyh  opasnostyah,  on   mozhet
pred®yavlyat' neobhodimye trebovaniya dlya togo, chtoby v detal'nom proekte nashli
polnoe otrazhenie ideologicheskih koncepcij i celi.


    Glava 6. Donesti slovo

     On syadet zdes'  i budet  rasporyazhat'sya:  "Sdelajte
eto! Sdelajte to!" A delo i s mesta ne sdvinetsya.
     GARRI S. TRUMEN. "O PREZIDENTSKOJ VLASTI"1
     Kak   menedzheru,  imeya  opytnyh  disciplinirovannyh  arhitektorov   i
dostatochnoe chislo ispolnitelej, dobit'sya togo, chtoby vse uslyshali,  ponyali i
vypolnili  resheniya  arhitektora? Kak gruppe iz 10 arhitektorov  podderzhivat'
konceptual'nuyu  celostnost' sistemy, nad kotoroj truditsya 1000 chelovek?  Dlya
dostizheniya etogo pri osushchestvlenii programmy proektirovaniya apparatnoj chasti
System/360  byla razrabotana  celaya tehnologiya,  kotoraya  v  ravnoj  stepeni
primenima dlya proektov sozdaniya programmnogo obespecheniya.
     Pis'mennye specifikacii - rukovodstvo
     Rukovodstvo, ili pis'mennaya dokumentaciya, yavlyaetsya neobhodimym, hotya i
ne dostatochnym,  instrumentom.  Rukovodstvo yavlyaetsya  vneshnej  specifikaciej
produkta. V nem  raspisany  vse podrobnosti togo, chto  vidit pol'zovatel', i
potomu ono yavlyaetsya glavnym produktom, kotoryj sozdaet arhitektor.
     Ego  podgotovka  idet  krugami,   sobiraya  zamechaniya  pol'zovatelej   i
razrabotchikov  o   nedostatkah  proekta,   zatrudnyayushchih   ispol'zovanie  ili
realizaciyu.  Dlya  udobstva  razrabotchikov  neobhodimo kvantovat'  izmeneniya:
soglasno opredelennym v grafike datam vypuskat' ocherednye versii.
     Instrukciya dolzhna ne tol'ko opisyvat' vse,  chto vidit  pol'zovatel',  v
tom  chisle vse  interfejsy,  no i  vozderzhivat'sya  ot  opisaniya  togo,  chego
pol'zovatel' ne vidit. Poslednee - zabota razrabotchika, i  zdes' svoboda ego
reshenij  ne  dolzhna  byt'  ogranichena. Arhitektor vsegda dolzhen  byt'  gotov
pokazat' primer  realizacii lyuboj opisannoj im  funkcii,  no  on  ne  dolzhen
pytat'sya navyazyvat' opredelennuyu realizaciyu.
     Stil' dolzhen byt' tochnym, polnym i  ochen' podrobnym. Pol'zovatel' chasto
obrashchaetsya k otdel'nomu  opredeleniyu,  poetomu vo  vseh  iz  nih dolzhny byt'
povtoreny vse sushchestvennye elementy,  i vse oni dolzhny byt' soglasovany drug
s drugom. Po  etoj prichine instrukcii chasto skuchno chitat', no tochnost' imeet
prioritet pered uvlekatel'nost'yu.
     Edinstvo "Principov raboty System/360" proistekaet iz  togo, chto  u nih
bylo  lish' dva avtora: Dzherri Blau i  Andris Padega.  Avtorami idej yavlyayutsya
poryadka desyati chelovek, no  esli trebuetsya soblyusti soglasovannost' opisaniya
i  produkta, otlivku reshenij v prozaicheskie specifikacii dolzhny osushchestvlyat'
ne bolee  dvuh chelovek.  Dlya napisaniya  opredeleniya trebuetsya prinyat'  massu
mini-reshenij,  kotorye  ne  stol'  vazhny,  chtoby  vynosit'  ih  na  vseobshchee
obsuzhdenie.  Dlya System/360  primerom  sluzhat  podrobnosti  togo,  kak posle
kazhdoj  operacii  ustanavlivaetsya   kod   usloviya.  Odnako  zadacha  vseobshchej
soglasovannosti takih mini- reshenij ne yavlyaetsya trivial'noj.
     Dumayu, chto luchshij vidennyj mnoj obrazec  rukovodstva -  eto  napisannoe
Blau prilozhenie  k "Principam raboty  System/360". V nem  tshchatel'no i  tochno
opisany  granicy sovmestimosti System/360. Dano  opredelenie  sovmestimosti,
predpisyvaetsya,  k chemu nuzhno  stremit'sya, i  perechisleny te oblasti vneshnih
proyavlenij, gde  arhitektura  namerenno molchit, i gde rezul'taty, poluchennye
na raznyh modelyah, mogut otlichat'sya mezhdu soboj, gde raznye ekzemplyary odnoj
modeli mogut dat' razlichnye  rezul'taty i dazhe odin i tot zhe ekzemplyar mozhet
davat'  razlichiya posle konstruktivnyh izmenenij.  |to  uroven'  tochnosti,  k
kotoromu stremyatsya sostaviteli  rukovodstv. Oni  dolzhny  odinakovo opisyvat'
kak to, chto mozhno delat', tak i to, chto delat' nel'zya.
     Formal'nye opredeleniya
     Anglijskij  yazyk,  kak i  lyuboj  drugoj  estestvennyj yazyk, po  svoej
prirode  ne  yavlyaetsya  tochnym instrumentom,  prigodnym  dlya takih  opisanij.
Poetomu sostavitel'  rukovodstva  dolzhen  derzhat'  v uzde  sebya i svoj yazyk,
chtoby    dostich'    neobhodimoj    strogosti.   Privlekatel'na   vozmozhnost'
ispol'zovaniya dlya takih opredelenij formal'nyh oboznachenij. V konce  koncov,
cel'yu  yavlyaetsya tochnost', chto obuslovlivaet pravo formal'nyh oboznachenij  na
zhizn'.
     Rassmotrim   dostoinstva   i  slabosti  formal'nyh   opredelenij.   Kak
otmechalos', formal'nye opredeleniya yavlyayutsya tochnymi. Oni tyagoteyut k polnote:
probely  zametnee,  a  potomu  skoree  vosstanavlivayutsya.  Ih  nedostatok  -
trudnost' ponimaniya. Na anglijskom yazyke mozhno opisat' strukturnye principy,
ochertit' struktury  po  etapam  ili  po  urovnyam i privesti  primery.  Legko
otmetit' isklyucheniya i  podcherknut' protivopolozhnosti. Eshche vazhnee,  chto mozhno
ob®yasnit' prichiny. Predlagavshiesya do sih por formal'nye opredeleniya vyzyvali
voshishchenie svoej elegantnost'yu i uverennost' v ih tochnosti. No oni trebovali
tekstual'nyh poyasnenij dlya  oblegcheniya  izucheniya svoego soderzhaniya. Po  etoj
prichine  ya  polagayu,  chto v  budushchem  specifikacii  budut  sostoyat'  kak  iz
formal'nyh, tak i iz tekstovyh opisanij.
     Drevnee izrechenie  preduprezhdaet o tom,  chto  v  more nel'zya vyhodit' s
dvumya hronometrami: nuzhno vzyat' odin ili tri. To zhe, ochevidno, primenimo i k
tekstovym i formal'nym  opredeleniyam. Esli imeyutsya oba vida,  to odin dolzhen
byt' standartom,  a drugoj - proizvodnym  opisaniem, o chem dolzhno byt' pryamo
ukazano. Osnovnym standartom mozhet byt' lyuboj iz nih. V Algol  68 v kachestve
standarta vybrano formal'noe opredelenie, a tekstovye  opredeleniya  yavlyayutsya
opisatel'nymi.  V PL/I standartom yavlyaetsya tekst, a formal'noe opredelenie -
proizvodnym.  V  System/360  takzhe  v  kachestve  standarta prinyat  tekst,  a
proizvodnymi yavlyayutsya formal'nye opisaniya.
     Est'  mnogo sredstv  sozdaniya  formal'nyh opredelenij.  Dlya opredeleniya
yazykov chasto  ispol'zuetsya  forma  Bekusa-Naura,  po  kotoroj  est'  bogataya
literatura.2  V  formal'nom  opisanii PL/I  ispol'zuyutsya  novye  oboznacheniya
abstraktnogo  sintaksisa,  nadlezhashchim obrazom opisannye.3  APL  Iversona byl
ispol'zovan dlya opisaniya mashin, v chastnosti, IBM 70904 i System/360.7 Bell i
N'yuell predlozhili novye notacii dlya opisaniya kak konfiguracij,  tak i mashin,
i  proillyustrirovali ih  na neskol'kih mashinah, vklyuchaya DEC PDP-8,6 70906  i
System/360.7
     Pochti  vse formal'nye opredeleniya  okazalis' prigodnymi dlya  voploshcheniya
ili opisaniya apparatnyh sredstv ili programmnyh sistem, vneshnie specifikacii
kotoryh oni reglamentiruyut. Sintaksis  mozhno opisat' bez etogo, no semantika
obychno opredelyaetsya  s pomoshch'yu programmy, vypolnyayushchej opredelyaemuyu operaciyu.
Konechno,   eto  yavlyaetsya  realizaciej  i  v   etom  kachestve  pereopredelyaet
arhitekturu.  Poetomu  nuzhno  ukazat', chto formal'noe opredelenie  otnositsya
tol'ko k vneshnim specifikaciyam, i ob®yasnit', chto imi yavlyaetsya.
     Ne tol'ko formal'noe opredelenie  yavlyaetsya realizaciej, no i realizaciya
mozhet sluzhit' formal'nym opredeleniem. Kogda byli sozdany pervye sovmestimye
komp'yutery, ispol'zovalas' imenno  eta tehnologiya.  Novaya mashina dolzhna byla
sootvetstvovat' imeyushchejsya.  Rukovodstvo  tumanno v nekotoryh mestah? Zadajte
vopros  mashine!  Sozdavalas' testovaya  programma dlya  vyyasneniya povedeniya, i
novaya mashina stroilas' tak, chtoby dostigalos' sootvetstvie.
     Programmnaya   model'   apparatnoj   ili   programmnoj   sistemy   mozhet
ispol'zovat'sya  tochno  takim  zhe  obrazom.  |to - realizaciya.  Ona rabotaet.
Poetomu  vse voprosy,  svyazannye  s opredeleniem, mogut  byt'  resheny  putem
proverki.
     Ispol'zovanie  realizacii   v   kachestve  opredeleniya  imeet  nekotorye
preimushchestva.  Vse  problemy mozhno  odnoznachno  reshit'  putem  eksperimenta.
Diskussij ne  trebuetsya, poetomu otvet poluchaetsya  bystro. Otvet  mozhet byt'
skol' ugodno tochnym i,  po opredeleniyu, vsegda yavlyaetsya pravil'nym. S drugoj
storony,  est'  znachitel'noe  kolichestvo   nedostatkov.   Realizaciya   mozhet
pereopredelyat'  dazhe  vneshnie  specifikacii.  Dazhe pri  oshibochnom sintaksise
vsegda  poluchaetsya  nekotoryj  rezul'tat;   v  kontroliruemoj  sisteme  etot
rezul'tat  yavlyaetsya ukazaniem na oshibku  i nichem bol'she.  V nekontroliruemoj
sisteme  mogut   vozniknut'  lyubye  pobochnye  effekty  i  byt'  ispol'zovany
programmistami. Kogda my,  naprimer,  emulirovali  IBM 1401  na  System/360,
vyyavilos'  30  razlichnyh "kur'ezov"  -  pobochnyh  effektov  predpolozhitel'no
nezakonnyh  operacij,  kotorye  shiroko  ispol'zovalis'  i dolzhny  byli  byt'
priznany chast'yu opredeleniya.  Realizaciya v kachestve opredeleniya vozobladala.
Ona ne tol'ko govorila  o tom, chto dolzhna delat' mashina, no i mnogoe skazala
o tom, kak mashina ne dolzhna byla eto delat'.
     Krome   togo,   na  pronicatel'nye  voprosy   realizaciya  inogda   daet
neozhidannye  otvety, i  opredelenie de-fakto  chasto  okazyvaetsya neizyashchnym v
etih  osobyh   sluchayah  potomu,  chto  nad  nimi  nikogda  ne   zadumyvalis'.
Kopirovanie  etoj  neelegantnosti  v  drugoj  realizacii  chasto  okazyvaetsya
zamedlyayushchim  ili dorogostoyashchim.  Naprimer,  v nekotoryh  mashinah v  registre
mnozhimogo  posle  umnozheniya ostaetsya  musor.  Tochnaya  priroda  etogo  musora
stanovitsya  chast'yu  opredeleniya   de-fakto,  odnako  ego  kopirovanie  mozhet
pomeshat' ispol'zovaniyu bolee bystrogo algoritma umnozheniya.
     Nakonec, ispol'zovanie  realizacii  v kachestve formal'nogo  opredeleniya
mozhet sozdat'  neyasnost', kakoe iz opisanij  - tekstovoe ili formal'noe  - v
dejstvitel'nosti  yavlyaetsya standartom. |to otnositsya osobenno k  programmnym
modelyam. Sleduet  takzhe vozderzhivat'sya ot  vneseniya  izmenenij v realizaciyu,
poka ona sluzhit v kachestve standarta.
     Pryamoe vklyuchenie
     U arhitektorov programmnyh  sistem est' chudesnyj metod rasprostraneniya
i  vnedreniya  opredelenij.  On osobenno  polezen  pri  ustanovlenii  esli ne
semantiki, to  sintaksisa mezhmodul'nyh  interfejsov.  |tot  priem sostoit  v
sozdanii  ob®yavlenij  peredavaemyh  parametrov  ili  sovmestno  ispol'zuemoj
pamyati  i  trebovanii  vklyucheniya  etih  ob®yavlenij   pri  operaciyah  vremeni
kompilyacii (makros ili  %INCLUDE  v  PL/I). Esli, krome togo,  vse ssylki na
interfejs  proishodyat  tol'ko  po  simvolicheskim  imenam,  ob®yavleniya  mozhno
menyat', dobavlyaya ili  vstavlyaya  novye imena i lish'  zanovo kompiliruya, no ne
izmenyaya ispol'zuyushchuyu ego programmu.
     Konferencii i sudy
     Net nuzhdy  govorit'  o  tom, chto soveshchaniya  neobhodimy.  Sotni chastnyh
konsul'tacij dolzhny dopolnyat'sya krupnymi  i bolee formal'nymi sobraniyami. My
priznali  poleznymi  dva urovnya  takih  sobranij. Pervyj  - eto ezhenedel'naya
konferenciya   vseh   arhitektorov  vmeste  s  oficial'nymi   predstavitelyami
razrabotchikov apparatnoj  i  programmnoj  chasti  i  sotrudnikami  marketinga
prodolzhitel'nost'yu  v polovinu rabochego dnya  pod  predsedatel'stvom glavnogo
arhitektora sistemy.
     Predlagat'  zadachi  i  izmeneniya  mozhno  vsem,  no  obychno  predlozheniya
rasprostranyayutsya  v  pis'mennom  vide  do  soveshchaniya.  Obychno  novaya  zadacha
nekotoroe  vremya obsuzhdaetsya.  Upor delaetsya  na  tvorcheskoj storone,  a  ne
prosto  na  prinyatii  resheniya. Gruppa pytaetsya predlozhit' neskol'ko  reshenij
problemy,  zatem ryad predlozhennyh  reshenij peredaetsya odnomu ili  neskol'kim
arhitektoram  dlya razrabotki podrobnyh i tochno sformulirovannyh  predlozhenij
po vneseniyu izmenenij v rukovodstvo.
     Podrobnye  predlozheniya  ob  izmeneniyah  zatem  vynosyatsya  dlya  prinyatiya
resheniya.  Predlozheniya tshchatel'no izuchayutsya  ispolnitelyami i pol'zovatelyami, i
vyyasnyayutsya  vse "za" i "protiv".  Esli  voznikaet  vseobshchee soglasie, vse  v
poryadke.  V protivnom sluchae reshenie  prinimaet glavnyj  arhitektor. Vedetsya
protokol, i resheniya formal'no, operativno i shiroko rasprostranyayutsya.
     Resheniya ezhenedel'nyh  konferencij dayut  bystrye rezul'taty  i pozvolyayut
prodolzhit'  rabotu.  Esli  kto-to ochen'  nedovolen, dopuskaetsya  nemedlennaya
apellyaciya k menedzheru proekta, no eto proishodit ochen' redko.
     Plodotvornost' etih soveshchanij obuslovlena neskol'kimi prichinami:
     1. Odna i ta  zhe gruppa  - arhitektory, razrabotchiki i ispolniteli - na
protyazhenii  mesyacev vstrechayutsya  mezhdu  soboj  kazhduyu  nedelyu. Ne  trebuetsya
vremeni, chtoby vvesti lyudej v kurs dela.
     2.  Gruppa sostoit iz predpriimchivyh, sposobnyh, horosho osvedomlennyh v
voprosah  i gluboko zainteresovannyh v  konechnom rezul'tate lyudej. Nikto  ne
uchastvuet  s  "soveshchatel'nym" golosom. Vse  upolnomocheny prinimat'  na  sebya
obyazatel'stva.
     3.  Pri  vozniknovenii problem resheniya  ishchutsya  kak  vnutri, tak i  vne
ochevidnyh granic.
     4.  Blagodarya  formalizmu   pis'mennyh  predlozhenij   sosredotochivaetsya
vnimanie,  trebuetsya   prinyatie  resheniya  i  ustranyaetsya  nesoglasovannost',
svojstvennaya chernovym resheniyam komissij.
     5. Otkrytoe predostavlenie prava prinyatiya  resheniya glavnomu arhitektoru
pomogaet izbezhat' poiska kompromissov i zaderzhek.
     So  vremenem  vyyasnyaetsya,  chto  nekotorye  resheniya  ne  v  polnoj  mere
vypolnyayutsya.  Tot  ili  inoj  iz  uchastnikov  tak  i  ne prinyal  vsej  dushoj
kakuyu-libo  meloch'.  Drugie  resheniya  porodili  nepredvidennye  problemy,  i
ezhenedel'noe soveshchanie otkazyvaetsya povtorno ih rassmatrivat'. Tak voznikaet
hvost  iz  melkih  vozrazhenij,  otkrytyh   tem   ili  razdrazheniya.   Dlya  ih
uregulirovaniya  my  provodim  ezhegodnye  "sessii  verhovnogo  suda",  obychno
prodolzhayushchiesya dve nedeli. (Esli by ya  provodil ih sejchas, to  delal by  eto
raz v polgoda.)
     |ti sessii  provodilis'  nakanune  vazhnyh  dat  okonchatel'nogo prinyatiya
razdelov rukovodstva. Prisutstvovali ne tol'ko predstaviteli programmistov i
proektirovshchikov po arhitekture, no i menedzhery programmnyh,  marketingovyh i
realizacionnyh proektov.  Predsedatel'stvoval menedzher  proekta  System/360.
Povestka raboty  vklyuchala  obychno  okolo  200  punktov, v  osnovnom  melkih,
perechislennyh v razveshannyh po komnate  spiskah. Zaslushivalis' vse storony i
prinimalis'  resheniya.  Blagodarya  chudu komp'yuternoj verstki  (i prevoshodnoj
rabote sotrudnikov) kazhdoe utro kazhdyj uchastnik obnaruzhival na svoem rabochem
meste  ispravlennoe rukovodstvo, v  kotoroe  byli vneseny  resheniya, prinyatye
nakanune.
     |ti "osennie festivali" byli polezny  ne tol'ko dlya peresmotra reshenij,
no i dlya togo,  chtoby oni byli prinyaty. Kazhdyj byl  uslyshan, kazhdyj prinimal
uchastie,  kazhdyj  luchshe  ponimal  slozhnye  ogranicheniya i  vzaimosvyazi  mezhdu
resheniyami.
     Mnozhestvennye realizacii
     U arhitektorov System/360 bylo dva pochti besprecedentnyh preimushchestva:
dostatochno vremeni  dlya tshchatel'noj raboty i  takoe zhe politicheskoe  vliyanie,
kak  u proektirovshchikov. Nalichie  vremeni  bylo  obespecheno grafikom po novoj
tehnologii;  politicheskoe  ravenstvo  proishodilo  blagodarya  odnovremennomu
sozdaniyu neskol'kih realizacij. Neobhodimost' ih strogoj sovmestimosti luchshe
vsego sposobstvovala ispolneniyu specifikacij.
     V  bol'shinstve komp'yuternyh proektov nastupaet den', kogda okazyvaetsya,
chto mashina i rukovodstvo po ee ispol'zovaniyu  ne  soglasuyutsya. V posleduyushchem
konflikte  obychno  proigryvaet  rukovodstvo,  poskol'ku ego  mozhno  izmenit'
znachitel'no bystree  i men'shej cenoj,  chem  mashinu. Odnako  eto ne tak, esli
sushchestvuet  neskol'ko  realizacij. Togda  vremennye  i  finansovye izderzhki,
svyazannye s ispravleniem mashiny s oshibkami, mogut byt' nizhe, chem svyazannye s
peredelkoj mashin, verno sledovavshih rukovodstvu.
     |to  zamechanie   mozhno  s  pol'zoj   primenit'  pri  opredelenii  yazyka
programmirovaniya.  Mozhno  s  uverennost'yu  utverzhdat', chto  rano ili  pozdno
potrebuetsya sozdat' neskol'ko  interpretatorov  ili  kompilyatorov dlya raznyh
celej. Opredelenie budet yasnee,  a disciplina bolee krepkoj, esli iznachal'no
stroyatsya kak minimum dve realizacii.
     ZHurnal registracii telefonnyh razgovorov
     Kakimi  by  tochnymi  ne  byli  specifikacii,  po  hodu proektirovaniya
voznikaet neschetnoe mnozhestvo voprosov kasatel'no interpretacii arhitektury.
Ochevidno,  mnogie iz etih voprosov trebuyut bolee yasnogo izlozheniya  v tekste.
Prochie prosto otrazhayut nepravil'noe ponimanie.
     Vazhno, chtoby ozadachennye ispolniteli zvonili otvetstvennym arhitektoram
i zadavali voprosy, a ne prodolzhali rabotu na osnovanii dogadok. Vazhno takzhe
ponimat',  chto otvety na  takie  voprosy yavlyayutsya avtoritetnymi  zayavleniyami
arhitektorov i dolzhny dovodit'sya do vseh.
     Poleznym  mehanizmom  yavlyaetsya vedenie arhitektorom zhurnala registracii
telefonnyh  razgovorov, v kotoryj  im zanosyatsya vse voprosy i otvety. Kazhduyu
nedelyu zhurnaly neskol'kih arhitektorov ob®edinyayutsya  voedino, razmnozhayutsya i
raspredelyayutsya  sredi  pol'zovatelej   i   ispolnitelej.  Nesmotrya  na  svoyu
neformal'nost', takoj mehanizm yavlyaetsya i bystrym, i ponyatnym.
     Testirovanie produkta
     Luchshij drug menedzhera proekta  - ego postoyannyj protivnik, nezavisimaya
organizaciya,  testiruyushchaya produkt.  Gruppa  proveryaet  sootvetstvie  mashin i
produktov  specifikaciyam  i  vystupaet  posobnikom d'yavola,  ukazyvaya na vse
zamechennye defekty i nesootvetstviya. Kazhdoj organizacii, vedushchej razrabotki,
nuzhna  takaya  nezavisimaya  gruppa  tehnicheskogo audita, kotoraya  dolzhna byt'
nepodkupna.
     Poslednij  analiz  v   kachestve  nezavisimogo   auditora   osushchestvlyaet
pokupatel'. V  bezzhalostnom  svete  prakticheskogo  primeneniya  stanet  viden
kazhdyj  ogreh.  Gruppa testirovaniya  produkta kak  raz zamenyaet  pokupatelya,
nastroennogo na poisk oshibok. Vremya  ot vremeni tshchatel'naya proverka produkta
obnaruzhivaet mesta, gde  ne uslyshali ukazanie, gde  proektnye resheniya ponyali
nepravil'no ili vypolnili netochno. Poetomu takaya gruppa proveryayushchih yavlyaetsya
neobhodimym  zvenom  v  cepochke,  po kotoroj  dohodit slovo  proektirovshchika,
zvenom,   kotoroe   dolzhno  nachat'   dejstvovat'   rano  i   odnovremenno  s
proektirovaniem.


    Glava 7. Pochemu ne udalos' postroit' Vavilonskuyu bashnyu?

     Na vsej zemle byl
odin yazyk i odno narechie. Dvinuvshis' s vostoka, oni  nashli v  zemle  Sennaar
ravninu i  poselilis' tam. I skazali drug drugu: nadelaem kirpichej i obozhzhem
ognem. I stali u nih kirpichi vmesto kamnej, a zemlyanaya smola vmesto izvesti.
I skazali oni: postroim sebe gorod i bashnyu, vysotoyu do nebes, i sdelaem sebe
imya prezhde, nezheli rasseemsya po licu vsej zemli.  I soshel Gospod' posmotret'
gorod i bashnyu, kotorye stroili  syny chelovecheskie.  I  skazal Gospod':  vot,
odin  narod, i odin u vseh yazyk; i vot chto  oni nachali delat', i ne otstanut
oni ot togo, chto zadumali delat'; sojdem zhe i smeshaem tam yazyk ih, tak chtoby
odin ne ponimal rechi drugogo.  I rasseyal ih Gospod' ottuda po  vsej zemle; i
oni perestali stroit' gorod [i bashnyu].
     KNIGA BYTIYA 11:1-8
     Audit menedzhmenta Vavilonskogo proekta
     Soglasno Knige bytiya, Vavilonskaya bashnya byla vtorym krupnym inzhenernym
predpriyatiem cheloveka posle Noeva  kovchega.  Vavilonskaya bashnya  stala pervym
inzhenernym fiasko.
     |ta  istoriya gluboka i  pouchitel'na v neskol'kih  otnosheniyah.  Davajte,
odnako, rassmotrim ee kak  chisto tehnicheskij proekt i posmotrim, kakie uroki
administrirovaniya  mozhno  iz  nee  izvlech'.  Naskol'ko  horosho   proekt  byl
obespechen neobhodimymi sostavlyayushchimi uspeha? Imelis' li:
     1. YAsnost' celi?  Da, hotya i  naivno  nedostizhimoj.  Proekt  provalilsya
zadolgo do togo, kak stolknulsya s eti principial'nym ogranicheniem.
     2. CHelovecheskie resursy? V bol'shom chisle.
     3. Materialy? Glina i bitum v izobilii imeyutsya v Mesopotamii.
     4.  Dostatochno  vremeni?  Da, net  nikakih ukazanij  na ogranicheniya  po
vremeni.
     5.  Adekvatnye  tehnologii? Da,  piramidal'noj ili konicheskoj strukture
prisushcha ustojchivost'  i  horoshee  raspredelenie  nagruzki  szhatiya. Ochevidno,
svojstva kamennoj kladki byli horosho  izvestny.  Proekt provalilsya  do togo,
kak vyshel za predely tehnologicheskih ogranichenij.
     Tak pochemu zhe provalilsya proekt, esli vse eto u nih bylo? CHego u nih ne
hvatalo?  Dvuh veshchej - obmena informaciej i vytekayushchej  iz nego organizacii.
Oni  ne  mogli  razgovarivat' drug s drugom i, kak sledstvie,  soglasovyvat'
usiliya. Kogda  otkazala  koordinaciya, rabota  vstala. CHitaya  mezhdu strok, my
obnaruzhivaem, chto  otsutstvie obmena informaciej privelo  k  sporam, durnomu
nastroeniyu i vzaimnoj revnosti. Vskore  klany nachali rashodit'sya,  predpochtya
obosoblennost' sporam.
     Obmen informaciej v bol'shom programmnom proekte
     V   nashe   vremya  proishodit  tozhe  samoe.  Otstavanie  ot  grafika,
nesootvetstvie funkcional'nosti, sistemnye oshibki - vse eto iz-za  togo, chto
levaya ruka ne  znaet, chto tvorit pravaya.  Po hodu raboty uchastvuyushchie  v  nej
neskol'ko  brigad  ponemnogu izmenyayut funkcii,  razmer, bystrodejstvie svoih
programm, yavno ili  kosvenno  menyayut dopushcheniya otnositel'no vhodnyh dannyh i
ispol'zovaniya vyhodnyh.
     Naprimer,  ispolnitel'  funkcii,   osushchestvlyayushchej  overlejnuyu  zagruzku
programm,   mozhet  stolknut'sya  s  problemami   i  snizit'   bystrodejstvie,
osnovyvayas' na statisticheskih dannyh, ukazyvayushchih na  redkost' ispol'zovaniya
etoj  funkcii v  prikladnyh  programmah.  V  to  zhe  vremya  ego sosed  mozhet
razrabatyvat' vazhnuyu chast' supervizora takim obrazom, chto ona krajne zavisit
ot skorosti  vypolneniya etoj funkcii. |to  izmenenie  skorosti vypolneniya, v
sushchnosti,  stanovitsya  znachitel'nym  izmeneniem  specifikacij,  o  nem nuzhno
shiroko ob®yavit' i ocenit' s tochki zreniya sistemy.
     Kak  zhe  dolzhny brigady obmenivat'sya  mezhdu  soboj  informaciej?  Vsemi
vozmozhnymi sposobami:
     -   Neformal'no.   Horoshaya   telefonnaya  svyaz'  i   yasnoe   opredelenie
vzaimozavisimostej  mezhdu  brigadami  dolzhny  sposobstvovat'  mnogochislennym
telefonnym peregovoram, ot  kotoryh  zavisit  edinaya  interpretaciya pechatnyh
dokumentov.
     -   Soveshchaniya.  Nel'zya   pereocenit'  znachenie   regulyarnyh   soveshchanij
uchastnikov  proekta s poocherednym zaslushivaniem  tehnicheskih otchetov brigad.
Takim putem ustranyayutsya sotni melkih neponimanij.
     - Rabochaya tetrad'. V  samom nachale  nuzhno zavesti rabochuyu tetrad' ucheta
prodelannoj raboty. |ta tema zasluzhivaet otdel'nogo razdela.
     Rabochaya tetrad' proekta
     CHto. Rabochaya tetrad' proekta yavlyaetsya ne stol'ko  otdel'nym dokumentom,
skol'ko strukturoj,  nalagaemoj na vse  dokumenty, kotorye  budut sozdany vo
vremya vypolneniya proekta.
     Vse dokumenty proekta dolzhny vhodit'  v  etu strukturu,  vklyuchaya  celi,
vneshnie  specifikacii,  specifikacii  interfejsov,  tehnicheskie   standarty,
vnutrennie specifikacii i administrativnye zapiski.
     Pochemu.  Tehnologicheskij  dokument prakticheski vechen. Esli  issledovat'
genealogiyu   rukovodstva  pol'zovatelya   po  kakomu-nibud'  apparatnomu  ili
programmnomu  produktu, mozhno  prosledit' ne  tol'ko idei,  no  i  mnozhestvo
otdel'nyh  predlozhenij  i paragrafov,  vplot'  do  pervoj  pamyatnoj zapiski,
predlagayushchej  produkt   ili  poyasnyayushchej  pervyj   proekt.   Dlya  sostavitelya
dokumentacii nozhnicy i klej - takaya zhe vazhnaya veshch', kak pero.
     Raz eto tak, i zavtrashnie rukovodstva dlya gotovogo produkta razvivayutsya
iz  segodnyashnih pamyatnyh zapisok, ochen' vazhno pravil'no opredelit' strukturu
dokumentacii.   Razrabotka  rabochej  tetradi  proekta   na   rannih   etapah
obespechivaet produmannuyu, a ne sluchajnuyu strukturu dokumentacii. Bolee togo,
zadanie struktury pozvolyaet  sostavlennye pozdnee dokumenty oformit'  v vide
otryvkov, kotorye vpisyvayutsya v etu strukturu.
     Vtoroj  prichinoj  dlya vedeniya  rabochej tetradi  yavlyaetsya  neobhodimost'
upravleniya   processom  rasprostraneniya  informacii.  Zadacha  sostoit  ne  v
ogranichenii dostupa k informacii, a v tom, chtoby sootvetstvuyushchaya  informaciya
dostigla vseh, komu ona mozhet ponadobit'sya.
     Pervym  delom  sleduet pronumerovat'  vse  pamyatnye zapiski,  tak chtoby
imelis'  uporyadochennye spiski nazvanij,  i kazhdyj rabotnik  mog  ubedit'sya v
nalichii  neobhodimyh   emu  materialov.  Organizaciya  rabochej  tetradi  idet
znachitel'no  dal'she, ustanavlivaya  drevovidnuyu  strukturu  pamyatnyh zapisok.
Drevovidnaya   struktura   pozvolyaet,   esli   nuzhno,  organizovat'  dostavku
informacii sootvetstvenno podderev'yam.
     Mehanika. Kak i vo  mnogih  zadachah upravleniya programmnymi  proektami,
problema  tehnicheskih  memorandumov uslozhnyaetsya  nelinejnym obrazom  po mere
uvelicheniya  ob®ema dannyh. Esli v rabote  uchastvuyut  10  chelovek,  dokumenty
mozhno  prosto  pronumerovat'. Esli uchastvuyut  100  chelovek, chasto dostatochno
neskol'kih  linejnyh  posledovatel'nostej.  Dlya 1000 sotrudnikov,  neizbezhno
razbrosannyh    po   neskol'kim    ploshchadkam,   vozrastaet   potrebnost'   v
strukturirovannoj  rabochej  tetradi, i, sledovatel'no, vozrastaet ee  ob®em.
Kak postupat' v etom sluchae?
     YA dumayu,  my  pravil'no  postupili pri rabote nad  proektom OS/360.  Na
neobhodimosti horosho strukturirovannoj rabochej tetradi osobenno nastaival O.
S.  Loken,  kotoryj  ubedilsya  v  ee  effektivnosti  pri  rabote  nad  svoim
predydushchim proektom, - operacionnoj sistemoj 1410-7010.
     My  bystro  prinyali  reshenie,  chto  kazhdyj   programmist  dolzhen  imet'
vozmozhnost' videt'  ves'  material,  t.e.  dolzhen  imet'  ekzemplyar  rabochej
tetradi v svoem ofise.
     Reshayushchee  znachenie  imeet  svoevremennoe  obnovlenie.  Rabochaya  tetrad'
dolzhna  otrazhat' tekushchee  sostoyanie proekta.  |to ochen' trudno  osushchestvit',
kogda dlya vneseniya obnovlenij nuzhno perepechatyvat' celye dokumenty. Odnako v
tetradi  s  vynimayushchimisya listami dostatochno zamenit' otdel'nye  stranicy. U
nas  imelas'   komp'yuternaya  sistema   redaktirovaniya   teksta,  okazavshayasya
bescennoj  dlya svoevremennogo  obnovleniya.  Ofsetnye  formy  izgotavlivalis'
neposredstvenno na printere, i  cikl obrabotki sostavlyal men'she  odnogo dnya.
Pered poluchatelem  vseh  etih obnovlennyh  stranic vstaet,  odnako, problema
usvoeniya.  Kogda  on  vpervye poluchaet obnovlennuyu  stranicu, to  emu  nuzhno
znat',  chto  bylo izmeneno.  Kogda on  pozzhe  obrashchaetsya k nej, to emu nuzhno
znat', kakoe opredelenie dejstvitel'no na tekushchij den'.
     Poslednyuyu    potrebnost'    udovletvoryaet   nepreryvnost'    obnovleniya
dokumentacii.  CHtoby  vydelit' izmeneniya, trebuyutsya drugie mery.  Vo-pervyh,
nuzhno  otmetit'  na  stranice   izmenennyj   tekst,   naprimer,  s   pomoshch'yu
vertikal'noj  linii na polyah ryadom  s kazhdoj izmenennoj strochkoj. Vo-vtoryh,
neobhodimo vmeste s izmenennymi stranicami  rasprostranyat' kratkuyu otdel'nuyu
svodku s perechisleniem izmenenij i harakteristikoj ih znacheniya.
     Nash proekt ne pereshel  i shestimesyachnogo rubezha, kogda  my stolknulis' s
drugoj problemoj.  Tolshchina rabochej  tetradi sostavila okolo polutora metrov!
Esli by my slozhili v odnu stopku trebuyushchiesya programmistam 100 ekzemplyarov v
svoih pomeshcheniyah  zdaniya Time-Life v Manhettene, ona by  prevysila po vysote
samo zdanie. Krome togo, ezhednevnye  ispravleniya  imeli tolshchinu  bol'she pyati
santimetrov  i naschityvali okolo 150  stranic, kotorye nado  bylo  zamenit'.
Podderzhka  rabochej  tetradi stala  zanimat' znachitel'nuyu  chast'  ezhednevnogo
rabochego vremeni.
     S etogo vremeni my pereshli na mikrofishi, chto  sbereglo million dollarov
dazhe s uchetom stoimosti  ustrojstv dlya chteniya mikrofishej v kazhdom  ofise. My
smogli  dostich'  otlichnoj prodolzhitel'nosti cikla  proizvodstva  mikrofishej.
Rabochaya tetrad' umen'shilas' v ob®eme s 90  dm3 do 5 dm3 i, chto  bolee vazhno,
obnovleniya  vypuskalis'  porciyami   po  sotne  stranic,  stokratno  umen'shaya
slozhnost' zameny listov.
     Mikrofishi imeyut svoi  nedostatki.  S tochki zreniya menedzhera, neudobstvo
zameny  bumazhnyh stranic  garantirovalo, chto  ih prochtut, dlya  chego i velas'
rabochaya tetrad'. Mikrofishi slishkom oblegchili zadachu vedeniya rabochej tetradi,
esli  tol'ko  oni  ne  soprovozhdalis' pechatnym  dokumentom  s  perechisleniem
izmenenij.
     Krome  togo, mikrofishi  ne  pozvolyayut chitatelyu legko delat'  vydeleniya,
pometki  i  kommentarii. Dokumenty, s  kotorymi  chitatel'  rabotal, prinosyat
bol'she pol'zy  avtoru  i chitatelyu.  Vzveshivaya vse, ya polagayu, chto  mikrofishi
yavlyayutsya ochen' udachnoj tehnologiej,  i dlya ochen' krupnyh proektov ya by otdal
im predpochtenie pered bumazhnoj rabochej tetrad'yu.
     Kak  mozhno osushchestvit' eto segodnya? Segodnyashnie sistemnye tehnologii, ya
dumayu,  delayut  predpochtitel'nee  vedenie rabochej  tetradi  v  fajle pryamogo
dostupa  s  poloskami,  pomechayushchimi  izmenennye  chasti,  i  datami  vneseniya
izmenenij.  Lyuboj pol'zovatel'  mozhet  obratit'sya k  zhurnalu  s  displejnogo
terminala. Svodka izmenenij, gotovyashchayasya ezhednevno,  dolzhna hranit'sya v vide
steka  (LIFO) s ustanovlennoj tochkoj dostupa. Programmist mozhet ezhednevno ee
chitat',  no esli  on propustil odin  den',  emu  pridetsya  dol'she  chitat' na
sleduyushchij den'. Prochtya ob izmeneniyah, on  mozhet  prervat'sya  i  prochest' sam
izmenennyj tekst.
     Obratite vnimanie, chto sama  rabochaya tetrad' ostaetsya  neizmennoj.  Ona
po-  prezhnemu  ostaetsya  sobraniem vsej  proektnoj  dokumentacii,  tshchatel'no
organizovannoj. Edinstvennoe izmenenie - mehanizm raspredeleniya  dostupa. D.
S.   |nglebart   s   kollegami   sozdali   takuyu  sistemu   v   Stenfordskom
issledovatel'skom institute i ispol'zuyut ee dlya vedeniya dokumentacii po seti
ARPA.
     D.  L.  Pranas  i  Universiteta   Karnegi-Melona  predlozhil  eshche  bolee
radikal'noe reshenie.1 On polagaet, chto proizvoditel'nost' programmista  vyshe
vsego, kogda on ograzhden ot podrobnostej konstrukcii teh chastej sistemy, nad
kotorymi on ne rabotaet.  |to predpolagaet, chto vse interfejsy  polnost'yu  i
tochno zadany.  Takoj proekt  opredelenno  horosh, no  esli polagat'sya na  ego
ideal'noe osushchestvlenie, eto  privedet k katastrofe.  Horoshaya informacionnaya
sistema ne  tol'ko dolzhna vyyavlyat' oshibki v interfejsah, no i sposobstvovat'
ih ispravleniyu.
     Organizaciya krupnogo programmnogo proekta
     Esli  nad  proektom  rabotaet  n  chelovek,  to   sushchestvuet  (n2-n)/2
interfejsov, cherez  kotorye mozhet  proishodit' obmen dannymi, i potencial'no
sushchestvuet pochti 2n grupp, vnutri  kotoryh  dolzhno proishodit' soglasovanie.
Cel' organizacii  raboty sostoit  v sokrashchenii  neobhodimogo  ob®ema  obmena
informaciej  i soglasovaniya.  Poetomu  sozdanie  pravil'noj  organizacionnoj
struktury  yavlyaetsya  reshayushchim napravleniem  resheniya  problem informacionnogo
obmena, rassmatrivavshihsya vyshe.
     Sposoby,  kotorymi sokrashchaetsya obmen  informaciej, - razdelenie truda i
specializaciya  funkcij.   Drevovidnaya  organizacionnaya   struktura  otrazhaet
umen'shenie  potrebnosti v  podrobnom  obmene  informaciej pri  ispol'zovanii
razdeleniya truda i specializacii.
     V   dejstvitel'nosti,  organizaciya  v   vide   dereva   voznikaet   kak
strukturizaciya polnomochij  i  otvetstvennosti.  Princip, chto nikto  ne mozhet
byt'   slugoj  dvuh  gospod,  trebuet,   chtoby   struktura  polnomochij  byla
drevovidnoj. Odnako  struktura obmena  informaciej  ne  stol'  ogranichena, i
derevo  yavlyaetsya  malo  prigodnym priblizheniem  struktury  obshcheniya,  kotoraya
yavlyaetsya   set'yu.   Neadekvatnost'  priblizheniya   derevom  sluzhit   prichinoj
vozniknoveniya  brigad, celevyh grupp, komissij i dazhe organizacij matrichnogo
tipa, sushchestvuyushchih vo mnogih inzhenernyh laboratoriyah.
     Rassmotrim   drevovidnuyu    organizaciyu   programmistov   i   issleduem
sushchestvennye harakteristiki, kotorymi dolzhny obladat' podderev'ya, chtoby byt'
effektivnymi. Takovymi yavlyayutsya:
     1 - zadanie,
     2 - prodyuser,
     3 - tehnicheskij direktor ili arhitektor,
     4 - grafik rabot,
     5 - razdelenie truda,
     6 - opredelenie interfejsov mezhdu raznymi chastyami.
     Vse perechislennoe ochevidno i obychno, isklyuchaya razlichie mezhdu prodyuserom
i tehnicheskim direktorom. Snachala  rassmotrim sami eti dve funkcii, a  zatem
ih vzaimootnosheniya.
     V  chem naznachenie prodyusera? On sobiraet brigadu, raspredelyaet rabotu i
ustanavlivaet grafik ee vypolneniya. On  zanimaetsya priobreteniem neobhodimyh
resursov. |to  oznachaet,  chto bol'shaya chast' ego  funkcij sostoit v  obshchenii,
kotoroe napravleno vne brigady,  - vverh i v storony. On ustanavlivaet shemu
svyazi i predostavleniya otchetnosti vnutri brigady.  Nakonec, on  obespechivaet
vypolnenie  grafika,  osushchestvlyaya  manevr  resursami i  menyaya organizaciyu  v
sootvetstvii s novymi obstoyatel'stvami.
     A chto zhe tehnicheskij direktor? On postigaet proekt, kotoryj dolzhen byt'
realizovan, vyyavlyaet ego sostavlyayushchie,  opredelyaet,  kak  on budet vyglyadet'
vneshne, i  delaet eskiz vnutrennej  struktury.  On  obespechivaet edinstvo  i
konceptual'nuyu  celostnost' proekta v  celom  i takim  obrazom  sposobstvuet
ogranicheniyu  slozhnosti  sistemy.  Pri  vozniknovenii tehnicheskih problem  on
izyskivaet ih resheniya  ili pri neobhodimosti izmenyaet sistemnyj proekt.  On,
soglasno prelestnomu  vyrazheniyu  Ala  Kappa,  yavlyaetsya  "svoim  chelovekom  v
parshivyh delah". Obshchenie ego proishodit  preimushchestvenno vnutri komandy. Ego
rabota pochti isklyuchitel'no tehnicheskaya.
     Teper'  vidno,  chto dlya etih dvuh  funkcij trebuyutsya sovershenno  raznye
sposobnosti. Sposobnosti vstrechayutsya v  raznyh sochetaniyah, i otnosheniya mezhdu
prodyuserom  i  direktorom dolzhny opredelyat'sya temi konkretnymi  sochetaniyami,
kotorymi oni  obladayut. Ne lyudi dolzhny byt'  vtisnuty v  chisto teoreticheskie
organizacionnye formy,  a organizaciya dolzhna  stroit'sya  vokrug  teh  lyudej,
kotorye est'.
     Vozmozhny  tri  tipa  otnoshenij,  i vse  oni  s  uspehom vstrechayutsya  na
praktike.
     Odno i to  zhe  lico mozhet byt' prodyuserom i tehnicheskim direktorom. |to
vpolne  opravdano  v  malen'kih komandah,  naschityvayushchih  ot  treh do  shesti
programmistov. V bolee krupnyh proektah eto  ochen' redko osushchestvimo po dvum
prichinam. Vo-pervyh,  redko  vstrechayutsya lyudi,  sochetayushchie  v  sebe  bol'shie
administrativnye i  tehnicheskie sposobnosti.  Mysliteli  vstrechayutsya  redko,
praktiki eshche rezhe, no rezhe  vsego - mysliteli-praktiki. Vo-vtoryh, v bol'shih
proektah vypolnenie kazhdoj  iz funkcij trebuet polnogo rabochego dnya ili dazhe
bol'she.  Prodyuseru  trudno   peredat'  komu-libo  dostatochnuyu  chast'   svoih
obyazannostej,  chtoby  vysvobodit'  vremya dlya  tehnicheskoj raboty.  Direktoru
nevozmozhno  peredat'  svoi  obyazannosti,  ne  nanosya  ushcherba  konceptual'noj
celostnosti proekta.  Prodyuser mozhet byt'  nachal'nikom,  a  direktor  -  ego
pravoj  rukoj.  Slozhnost' zdes' sostoit  v tom, chtoby opredelit'  polnomochiya
direktora  pri prinyatii tehnicheskih reshenij, s tem chtoby  on ne tratil  svoe
vremya, uchastvuya v administrativnoj cepochke.
     Ochevidno,   prodyuser   dolzhen  ob®yavit'  o   polnomochiyah  direktora   v
tehnicheskoj oblasti  i v vysshej stepeni  ukreplyat' ih  v voznikayushchih spornyh
situaciyah. CHtoby eto bylo vozmozhno, prodyuser i direktor dolzhny  imet' shozhie
vzglyady  po  osnovnym  tehnicheskim  voprosam.  Oni  dolzhny  chastnym  obrazom
soglasovyvat'  osnovnye  tehnicheskie problemy,  prezhde  chem  oni  vstanut na
povestku  dnya.  Prodyuser  dolzhen  takzhe  s bol'shim  uvazheniem  otnosit'sya  k
tehnicheskomu masterstvu direktora.
     CHto  menee  ochevidno, prodyuser mozhet s pomoshch'yu  simvolov statusa (takih
kak  razmer kabineta, kovrovoe pokrytie, mebel', rassylka vtoryh ekzemplyarov
dokumentov i t.p.) podcherkivat', chto direktor, nahodyas' vne administrativnoj
cepochki, obladaet, tem ne menee, vlast'yu v prinyatii reshenij.
     |to  mozhet  dejstvovat'  ochen'  uspeshno.  K  neschast'yu,  k  etomu redko
pribegayut.  CHto  huzhe  vsego  poluchaetsya  u  menedzherov proektov, - tak  eto
ispol'zovanie    tehnicheskogo    geniya   lyudej,    ne   ochen'   sil'nyh    v
administrirovanii.
     Direktor mozhet byt'  nachal'nikom, a prodyuser - ego pravoj rukoj. Robert
Hajnlajn yarko opisyvaet takuyu organizaciyu v "CHeloveke, prodavshem Lunu".
     Koster zakryl lico rukami, zatem vzglyanul vverh:
     - YA razbirayus' v etom. YA znayu, chto nuzhno delat', no vsyakij raz, kogda ya
pytayus' zanyat'sya  tehnicheskoj problemoj, kakoj-nibud' bolvan hochet,  chtoby ya
prinyal  reshenie  po  povodu  gruzovikov, ili telefonov, ili eshche kakoj-nibud'
erundy. Prostite, mister Garriman. Mne kazalos', ya spravlyus' so vsem etim.
     Garriman ochen' myagko skazal:
     - Ne otchaivajsya,  Bob. Ty  ved'  nedosypal poslednee vremya, pravda? Vot
chto ya skazhu: my perehitrim Fergyusona. YA voz'mu tvoj stol na neskol'ko dnej i
postroyu organizaciyu, kotoraya ogradit tebya ot takih veshchej. YA hochu, chtoby tvoi
mozgi byli zanyaty  vektorami reakcii, effektivnost'yu topliva  i  slozhnostyami
proekta,  a ne  kontraktami  po  gruzovikam.  -  Garriman podoshel  k  dveri,
vyglyanul naruzhu i zametil cheloveka, kotoryj byl, vozmozhno, starshim  klerkom.
- |j, vy! Podojdite syuda!
     CHelovek pokazalsya ozadachennym, vstal i, podojdya k dveri, sprosil:
     Da?
     -  YA hochu, chtoby etot stol v uglu i  vse, chto na nem, byli pereneseny v
pustuyu komnatu na etom etazhe, i nemedlenno.
     On prosledil,  kak Koster i vtoroj ego stol pereehali v druguyu komnatu,
ubedilsya,  chto telefon v  novom  pomeshchenii otklyuchen,  i,  podumav,  zastavil
perenesti tuda divan.
     - My  postavim proektor, chertezhnuyu dosku,  knizhnye shkafy  i  vse  takoe
prochee segodnya vecherom, - skazal on  Kosteru. - Prosto sostav' spisok  vsego
neobhodimogo, chtoby  zanimat'sya  delom. - On vernulsya v oficial'nyj  kabinet
glavnogo inzhenera i s radost'yu vzyalsya  za rabotu, pytayas'  vyyasnit',  kakovo
polozhenie del, i chto ne laditsya.
     CHasa  cherez tri on  pozval Barkli,  chtoby  poznakomit'  ego s Kosterom.
Glavnyj inzhener spal, sidya za stolom, polozhiv golovu na ruki. Garriman hotel
vyjti, no Koster prosnulsya.
     Proshu proshcheniya, - skazal on, krasneya, - ya, navernoe, zadremal.
     - Dlya etogo ya pritashchil tebe divan, - skazal Garriman, - na nem udobnee.
Bob,  poznakom'sya s Dzhokom Berkli.  |to tvoj novyj rab. Ty ostaesh'sya glavnym
inzhenerom   i   neosporimym  nachal'nikom.  Dzhok  budet  Glavnym  lordom  Vse
Ostal'noe. S etogo momenta tebe  absolyutno ne o  chem bespokoit'sya - isklyuchaya
takuyu meloch', kak lunnyj korabl'.
     Oni pozhali ruki.
     -  Hochu  prosit'  ob  odnoj veshchi,  mister  Koster,  -  skazal  Berkli s
ser'eznost'yu, - peredavajte mne vse, chto  sochtete neobhodimym - vasha storona
tehnicheskaya, - no Boga radi, zapisyvajte  vse, chtoby ya byl v kurse. YA  hochu,
chtoby vam na stol postavili vyklyuchatel', kotoryj budet upravlyat' opechatannym
magnitofonom na moem stole.
     Otlichno! - Garrimanu pokazalos', chto Koster pomolodel.
     -  I  esli  vam  ponadobitsya  chto-libo, ne  otnosyashcheesya  k  tehnike, ne
zanimajtes' etim sami. Nazhmite vyklyuchatel' i svistnite. Vse budet sdelano. -
Berkli  vzglyanul na Garrimana. - Hozyain govorit, chto sobiraetsya pogovorit' s
vami o nastoyashchej rabote. YA vas pokinu i zajmus' delami. - On vyshel. Garriman
sel. Koster posledoval ego primeru i skazal:
     Uf!
     Tak luchshe?
     Mne ponravilsya etot Berkli.
     - |to horosho. Teper' eto tvoj dvojnik. Ne bespokojsya: on rabotal u menya
ran'she. Ty pochuvstvuesh' sebya, kak v horoshej bol'nice.2
     |tot  tekst  edva  li  nuzhdaetsya  v  analiticheskih  kommentariyah. Takaya
organizaciya tozhe mozhet effektivno dejstvovat'.
     Mne kazhetsya, chto poslednij tip organizacii luchshe podhodit dlya nebol'shih
komand, opisannyh v glave  3 "Operacionnaya brigada". Polagayu, chto prodyuser v
kachestve  nachal'nika bolee podhodit  dlya  bol'shih podderev'ev  dejstvitel'no
krupnyh proektov.
     Vavilonskaya  bashnya  byla,  vozmozhno,  pervym inzhenernym fiasko,  no  ne
poslednim.  Reshayushchee znachenie  dlya uspeha  imeyut shema svyazi i vytekayushchaya iz
nee organizaciya.  Tehnologii  obmena  informaciej i sozdaniya organizacionnyh
struktur trebuyut  ot menedzhera bol'shoj raboty mysli i takoj zhe podkreplennoj
opytom kompetentnosti, kak i sama tehnologiya programmnogo obespecheniya.


    Glava 8. Ob®yavlyaya udar

     Praktika - luchshij uchitel'.
     PUBLIJ
     Opyt - dorogoj uchitel', no dlya glupcov inogo net.
     ALXMANAH BEDNOGO  RICHARDSA(Bednyj Richard  -  obraz neobrazovannogo,  no
zdravomyslyashchego  domoroshchennogo filosofa, sozdannyj  Bendzhaminom  Franklinom,
izdavavshim v  1732  - 1757  godah ezhegodnyj  al'manah i  ispol'zovavshim etot
psevdonim (primech. perev.).)
     Skol'ko  vremeni potrebuet zadacha sistemnogo  programmirovaniya? Skol'ko
sil ponadobitsya? Kak mozhno eto ocenit'?
     Ranee  ya predlozhil sootnosheniya,  kotorye  mozhno primenyat'  dlya  vremeni
planirovaniya,  napisaniya programm, testirovaniya komponentov  i  testirovaniya
sistemy.  Vo-pervyh, nuzhno  skazat', chto  nel'zya delat'  ocenku vsej zadachi,
ocenivaya tol'ko  chast', otnosyashchuyusya k napisaniyu  programm, a  zatem primenyaya
sootnosheniya. Napisanie programm sostavlyaet lish' odnu shestuyu chast' zadachi ili
okolo togo, i oshibki pri ego ocenivanii ili v sootnosheniyah mogut privesti  k
smehotvornym rezul'tatam.
     Vo-vtoryh,   nuzhno  uchityvat',  chto  ocenki,  poluchennye  pri  sozdanii
otdel'nyh   nebol'shih  programm,  nel'zya  primenyat'  dlya  bol'shih  sistemnyh
produktov.  K  primeru, dlya  programmy,  naschityvayushchej  3200  slov,  Sakman,
|rikson i  Grant ocenivayut summarnoe vremya napisaniya programm i otladki  dlya
odnogo programmista v 178 chasov, chto ekstrapoliruetsya do 35800  operatorov v
god. Vdvoe men'shaya programma potrebovala men'she chetverti ukazannogo vremeni,
chto  pri   ekstrapolyacii  daet  proizvoditel'nost',   blizkuyu  uzhe  k  80000
operatoram v  god.1  Neobhodimo  dobavit'  zatraty vremeni  na planirovanie,
sostavlenie  dokumentacii,  testirovanie, sistemnuyu integraciyu  i  obuchenie.
Linejnaya ekstrapolyaciya dannyh, otnosyashchihsya k korotkim zadacham, bessmyslenna.
Esli  ekstrapolirovat'  vremya,  za  kotoroe mozhno probezhat' stometrovku,  to
okazhetsya, chto mozhno probezhat' milyu menee chem za tri minuty.
     Prezhde chem otkazat'sya  ot etih  dannyh,  otmetim,  chto i dlya ne  sovsem
sravnimyh  zadach  oni  pokazyvayut,  chto  ob®em raboty  rastet  kak stepennaya
funkciya  razmera,   dazhe  bez  ucheta  processa   otmena  informaciej  (krome
programmista s sobstvennoj pamyat'yu).
     Pokazannye  na  ris.  8.1  dannye  vyzyvayut  grustnye  chuvstva.  Grafik
demonstriruet  rezul'taty,  poluchennye  v issledovanii, provedennom  Nanusom
(Nanus) i Farrom (Farr)2 v System Development Corporation. V  nem vyyavlyaetsya
zavisimost' s pokazatelem stepeni 1,5:
     Ob®em raboty = (konstanta) CH (kolichestvo komand)1,5.
     V drugom  issledovanii, provedennom v etoj kompanii, o kotorom soobshchaet
Vajnvurm (Weinwurm)3, takzhe poluchen pokazatel', blizkij k 1,5.
     Est'  neskol'ko   issledovanij  otnositel'no  proizvoditel'nosti  truda
programmista,  v  kotoryh  predlozhen ryad  tehnologij ocenivaniya.  Est' obzor
opublikovannyh  dannyh,  podgotovlennyj Mourinom  (Morin).4 YA  privedu zdes'
lish' neskol'ko naibolee pokazatel'nyh rezul'tatov.

     

     Ris. 8.1 Zatraty na programmirovanie kak funkciya razmera programmy
     Dannye Portmana
     CHarl'z Portman (Charles Portman), menedzher otdela programmirovaniya ICL
- Computer Equipment  Organization (Northwest) v Manchestere, predlagaet svoe
ponimanie problemy, kotoroe mozhet okazat'sya poleznym.
     On  obnaruzhil,  chto  ego  komandy  programmistov  otstayut  ot  grafikov
primerno napolovinu, t.e. kazhdoe zadanie  vypolnyaetsya primerno vdvoe dol'she,
chem predpolagalos'.  Pri  etom ocenki  ochen' tshchatel'no provodilis'  gruppami
opytnyh  ekspertov,  ocenivavshih  v cheloveko-chasah  trudoemkost'  neskol'kih
soten  podzadach  s pomoshch'yu diagramm  PERT.  Kogda vyyavlyalos'  otstavanie  ot
grafika, on prosil vesti podrobnye ezhednevnye zhurnaly ispol'zovaniya vremeni.
Iz nih  vyyasnilos',  chto oshibka  ocenok polnost'yu ob®yasnyaetsya  tem, chto  ego
komandy  ispol'zovali  na  programmirovanie  i  otladku  lish'  50  procentov
rabochego  vremeni.  Ostal'noe  vremya  teryalos'  iz-za   otkazov  mashiny,  na
nebol'shie srochnye postoronnie zadaniya, soveshchaniya, pisanie bumag, dela firmy,
bolezni,  lichnoe vremya  i  t.d.  Koroche ocenki  ishodili iz  nerealistichnogo
predpolozheniya o tom, kakaya chast' rabochego vremeni otvoditsya  neposredstvenno
rabote.6
     Dannye Arona
     Dzhoel  Aron  (Joel  Aron), menedzher IBM  po  sistemnym  tehnologiyam  v
Gejtersberge, shtat  Merilend,  izuchal effektivnost'  truda  programmistov vo
vremya raboty nad devyat'yu krupnymi sistemami (krupnaya sootvetstvuet bolee chem
25 programmistam  i 30000 operatorov).7  On  klassificiruet takie sistemy  v
sootvetstvii s intensivnost'yu vzaimodejstviya mezhdu programmistami (i chastyami
sistemy) i obnaruzhivaet sleduyushchie velichiny proizvoditel'nosti:
     Ochen' slaboe vzaimodejstvie 10000 instrukcij na cheloveka v god
     Nekotoroe vzaimodejstvie 5000 instrukcij na cheloveka v god
     Sushchestvennoe vzaimodejstvie 1500 instrukcij na cheloveka v god
     CHeloveko-god  zdes'  ne uchityvaet  podderzhku  i sistemnoe testirovanie,
tol'ko  razrabotku i programmirovanie. Pri vvedenii popravki s koefficientom
dva  s  cel'yu  ucheta sistemnogo testirovaniya eti cifry  blizko sootvetstvuyut
dannym Harra.
     Dannye Harra
     Dzhon  Harr  (John  Harr),  menedzher  po  programmirovaniyu  Electronic
Switching System, vhodyashchej v  sostav Bell Telephone  Laboratories, soobshchil o
svoem  sobstvennom  opyte  i  drugih  izvestnyh  emu  dannyh  v  doklade  na
Ob®edinennoj  konferencii  po  komp'yuteram  vesnoj  1969  goda.8 |ti  dannye
privedeny na risunkah 8.2, 8.3 i 8.4.
     Naibolee  pouchitelen  i soderzhit  bol'she dannyh risunok 8.2. Pervye dva
zadaniya yavlyayutsya, po  preimushchestvu, upravlyayushchimi programmami, a dva vtoryh -
yazykovymi   translyatorami.   Proizvoditel'nost'   izmeryaetsya  v   kolichestve
otlazhennyh   slov   za   cheloveko-god.    Pri    etom   uchityvaetsya    vremya
programmirovaniya, otladki  i sistemnogo testirovaniya. Neizvestno, uchteny  li
zatraty na planirovanie, podderzhku mashiny, sostavlenie dokumentacii i t.p.

     

     Ris.  8.2   Svodka   po   chetyrem   vazhnejshim   programmnym   proektam,
osushchestvlennym v ESS
     Proizvoditel'nost' razbivaetsya na dva klassa: dlya  upravlyayushchih programm
sostavlyaet okolo 600 slov na cheloveka za god, dlya translyatorov - okolo 2200.
Obratite vnimanie,  chto vse  chetyre programmy priblizitel'no odnogo razmera,
razlichie  sostoit  v  razmere  rabochih  grupp,  prodolzhitel'nosti  raboty  i
kolichestve modulej. CHto  yavlyaetsya  prichinoj,  a chto -  sledstviem?  Byla  li
slozhnost' prichinoj togo, chto dlya  upravlyayushchih  programm  trebovalos'  bol'she
lyudej? Ili zhe  bol'shee chislo  modulej i cheloveko-mesyacev obuslovleno bol'shim
chislom  lyudej,  privlechennyh  k  rabote?  Byla li  bol'shaya prodolzhitel'nost'
vypolneniya vyzvana slozhnost'yu  problem ili  mnogochislennost'yu zanyatyh lyudej?
Trudno  skazat'  s uverennost'yu. Konechno,  upravlyayushchie  programmy byli bolee
slozhnymi. Esli ostavit' v storone eti  neopredelennosti, to cifry  opisyvayut
real'nuyu   proizvoditel'nost'  pri   sozdanii  bol'shih   sistem,  i   potomu
predstavlyayut cennost'.
     Na  risunkah   8.3  i  8.4  pokazany  nekotorye  interesnye  dannye   o
fakticheskoj skorosti programmirovaniya i otladki v sravnenii s prognozom.
     Dannye OS/360
     Opyt OS/360 podtverzhdaet dannye Harra, hotya  dannye po OS/360 ne stol'
podrobny.  V  gruppah  razrabotki  upravlyayushchej programmy  proizvoditel'nost'
sostavila 600-800 otlazhennyh komand v god  na cheloveka. V gruppah razrabotki
translyatorov proizvoditel'nost' dostigla 2000-3000  otlazhennyh  komand v god
na  cheloveka. Pri etom uchityvaetsya planirovanie,  testirovanie  komponentov,
sistemnoe  testirovanie  i  nekotorye zatraty na podderzhku. Naskol'ko ya mogu
sudit', eti dannye soglasuyutsya s rezul'tatami Harra.

     

     Ris. 8.3 Predskazannaya i fakticheskaya skorost' programmirovaniya

     

     Ris. 8.4 Predskazannaya i fakticheskaya skorost' otladki
     Dannye  Arona, Harra  i OS/360 druzhno  podtverzhdayut  rezkie razlichiya  v
proizvoditel'nosti v  zavisimosti ot slozhnosti i trudnosti  samoj  zadachi. V
rabote ocenivaniya slozhnosti ya priderzhivayus' toj linii, chto kompilyatory vtroe
huzhe obychnyh paketnyh prikladnyh programm, a operacionnye sistemy vtroe huzhe
kompilyatorov.9
     Dannye Korbato
     Dannye  Harra  i  OS/360   otnosyatsya  k  programmirovaniyu  na   yazyke
assemblera.   Est'   nemnogo   publikacij  otnositel'no   proizvoditel'nosti
sistemnogo programmirovaniya s ispol'zovaniem yazykov vysokogo urovnya. Korbato
(Corbato) iz proekta MAC Massachusetskogo tehnologicheskogo instituta soobshchaet
o  srednej  proizvoditel'nosti  1200  strok  otlazhennyh  operatorov  PL/I na
cheloveka  v  god pri  razrabotke  operacionnoj  sistemy  MULTICS (ot  1 do 2
millionov slov).10
     |to chislo ochen' vdohnovlyaet. Kak u drugih proektov, MULTICS vklyuchaet  v
sebya  upravlyayushchie  programmy  i  yazykovye   translyatory.  Rezul'tatom  takzhe
yavlyaetsya  sistemnyj produkt,  otlazhennyj i dokumentirovannyj. Dannye kazhutsya
sravnimymi  v  otnoshenii  vidov  ispolnennoj  raboty.  A  proizvoditel'nost'
povyshaetsya   do   srednej   velichiny   mezhdu   upravlyayushchimi  programmami   i
translyatorami v drugih proektah.
     No  Korbato ukazyvaet kolichestvo strok za  god na cheloveka, a ne  slov!
Kazhdomu operatoru v ego sisteme sootvetstvuet  ot  treh  do pyati  slov koda,
napisannogo vruchnuyu! Iz etogo mozhno sdelat' dva vazhnyh vyvoda:
     - Proizvoditel'nost', izmerennaya v elementarnyh  operaciyah, okazyvaetsya
postoyannoj, chto kazhetsya razumnym,  esli  uchityvat',  skol'ko  vremeni  nuzhno
dumat' nad operatorom, i skol'ko oshibok mozhet v nem byt'.11
     -    Pri    ispol'zovanii    podhodyashchego    yazyka    vysokogo    urovnya
proizvoditel'nost' mozhno povysit' v pyat' raz.12


    Glava 9. Dva v  odnom

     Avtoru stoit prismotret'sya k Noyu i...  pouchit'sya na
primere Kovchega, kak v ochen' malen'koe prostranstvo vtisnut' ochen' mnogo.
     SIDNEJ SMIT, "|DINBURGSKOE REVYU"
     Razmer programmy kak stoimost'
     Kakova stoimost'  programmy?  Esli ne  schitat'  vremeni vypolneniya, to
pomyat',  zanimaemaya programmoj, sostavlyaet glavnye  izderzhki. |to verno dazhe
dlya sobstvennyh razrabotok,  kogda  pol'zovatel'  platit  avtoru sushchestvenno
men'she,  chem stoit razrabotka. Voz'mem interaktivnuyu sistemu IBM  APL. Plata
za ee  ispol'zovanie sostavlyaet  $400  v mesyac. Pri  rabote ona  trebuet  ne
men'she  160  Kbajt pamyati.  U mashiny  Model 165 ezhemesyachnaya  arenda 1 Kbajta
pamyati  stoit okolo  $12.  Esli  pol'zovat'sya programmoj  kruglosutochno,  to
mesyachnaya plata sostavit $400 za pol'zovanie  programmoj  i $1920 za  pamyat'.
Esli pol'zovat'sya  sistemoj APL lish'  chetyre chasa v  den', to mesyachnaya plata
sostavit $400 za pol'zovanie programmoj i $320 za ispol'zovanie pamyati.
     Neredko mozhno vstretit' cheloveka,  vyrazhayushchego uzhas po povodu togo, chto
v mashine,  imeyushchej  2 Mbajt  pamyati, pod  operacionnuyu  sistemu  mozhet  byt'
otvedeno 400 Kbajt.  |to stol' zhe  glupo, kak rugat' Boing-747 za to, chto on
stoit 27 millionov dollarov.  Nado zhe sprosit':  "A chto  ona delaet?" Kakuyu,
sobstvenno,  prostotu  v  ispol'zovanii  i  proizvoditel'nost'  (posredstvom
effektivnogo ispol'zovaniya sistemy) poluchaesh' za  potrachennye den'gi? Nel'zya
li vlozhennye v arendu pamyati $4800 v mesyac izrashodovat' s bol'shej pol'zoj -
na drugie apparatnye sredstva, programmistov, prikladnye programmy?
     Proektirovshchik   sistemy  otvodit   chast'   vseh   apparatnyh   resursov
programmam, rezidentno nahodyashchimsya v pamyati,  esli schitaet, chto pol'zovatelyu
eto  nuzhnee, chem summatory,  diski  i  t.d.  Nel'zya kritikovat'  programmnuyu
sistemu  za   razmer   kak  takovoj,  i   v  to  zhe   vremya  posledovatel'no
propagandirovat' tesnuyu integraciyu proektirovaniya apparatnogo i programmnogo
obespecheniya.
     Poskol'ku razmer  opredelyaet znachitel'nuyu  dolyu  togo, vo chto obhoditsya
pol'zovatelyu  sistemnyj programmnyj produkt, izgotovitel' dolzhen planirovat'
razmer, kontrolirovat'  ego i  razrabatyvat' tehnologii, umen'shayushchie razmer,
podobno  tomu,  kak  izgotovitel'  apparatnoj   chasti  planiruet  kolichestvo
detalej,  kontroliruet  ego  i  razrabatyvaet metody  sokrashcheniya  kolichestva
detalej.  Kak i  dlya  vsyakoj  ceny,  ploh  ne bol'shoj  razmer kak takovoj, a
razmer, ne vyzyvaemyj neobhodimost'yu.
     Upravlenie razmerom
     Dlya  menedzhera   proekta   upravlenie   razmerom   yavlyaetsya  otchasti
tehnicheskoj,  otchasti administrativnoj zadachej. CHtoby ustanavlivat'  razmery
predlagaemyh sistem,  neobhodimo izuchat'  pol'zovatelej i  ispol'zuemye  imi
prilozheniya.  Zatem sistemy  dolzhny razlagat'sya  na  komponenty,  dlya kotoryh
opredelyayutsya proektnye razmery.  Poskol'ku var'irovat' sootnosheniem skorosti
i  razmera  mozhno  lish' dostatochno  bol'shimi  skachkami, planirovanie razmera
yavlyaetsya neprostym delom, trebuyushchim znaniya vozmozhnyh kompromissov dlya kazhdoj
chasti. Opytnyj  menedzher sdelaet  sebe takzhe "zanachku", kotoruyu mozhno  budet
ispol'zovat' v processe raboty.
     Vse zhe pri rabote nad OS/360 prishlos' izvlech' neskol'ko gor'kih urokov,
nesmotrya na to, chto vse opisannye mery byli prinyaty.
     Prezhde vsego,  nedostatochno  ustanovit' razmer  pamyati, nuzhno  vzvesit'
razmer so vseh storon.  Bol'shinstvo prezhnih  operacionnyh sistem razmeshchalos'
na magnitnyh lentah, i bol'shoe vremya poiska na lente ne raspolagalo k chastoj
zagruzke programmnyh  segmentov. OS/360  raspolagalas' na  diske,  kak  i ee
neposredstvennye predshestvenniki - operacionnaya sistema  Stretch  i diskovaya
operacionnaya  sistemy  1410-7010.  Ee  sozdateli  poluchili  svobodu  legkogo
obrashcheniya   k   disku.   Pervonachal'no  eto   obernulos'   katastrofoj   dlya
proizvoditel'nosti.
     Pri   opredelenii  razmerov  pamyati  komponentov   my   ne   ustanovili
odnovremenno  byudzhetov  dostupa.  Kak   i  sledovalo  ozhidat',  programmist,
vyhodivshij za ramki  opredelennoj emu pamyati, razbival programmu na overlei.
V rezul'tate i summarnyj razmer uvelichivalsya, i vypolnenie zamedlyalos'. Huzhe
to, chto nasha sistema  administrativnogo kontrolya  ne smogla  eto obnaruzhit'.
Kazhdyj programmist  soobshchal,  skol'ko  pamyati on ispol'zoval, i  tak  kak on
ukladyvalsya v zadanie, nikto ne bespokoilsya.
     K schast'yu,  vskore nastal den', kogda zarabotala  sistema modelirovaniya
tehnicheskih   harakteristik   OS/360.  Pervye  rezul'taty  pokazali  nalichie
ser'eznyh problem. Modelirovanie kompilyacii s Fortran H na mashine Model 65 s
barabanami dalo rezul'tat pyat' operatorov  v minutu! Analiz pokazal, chto vse
modeli upravlyayushchej  programmy  delali  mnozhestvo  obrashchenij  k  disku.  Dazhe
intensivno  ispol'zuemye  moduli  supervizora  chasto  obrashchalis' k disku,  i
rezul'tat po zvuku ves'ma napominal shelest perelistyvaemoj knigi.
     Pervaya moral' yasna: planirovat' nuzhno kak razmer rezidentnoj chasti, tak
i  obshchij  razmer.  Pomimo  planirovaniya  etih razmerov nuzhno  planirovat'  i
kolichestvo obrashchenij k disku dlya obratnoj zapisi.
     Vtoroj urok byl analogichen. Resursy  pamyati ustanavlivalis' prezhde, chem
dlya kazhdogo modulya bylo opredeleno tochnoe raspredelenie pamyati  dlya funkcij.
V rezul'tate kazhdyj programmist, ne ukladyvavshijsya v  razmery, iskal, chto iz
ego  koda  mozhno  vykinut'  cherez  zabor  v  pamyat'  sosedu. Poetomu  bufera
upravlyayushchej programmy stali  chast'yu  pamyati pol'zovatelya. CHto  huzhe,  tak zhe
postupali  vse   upravlyayushchie   bloki,  i   v   rezul'tate   byli   polnost'yu
skomprometirovany bezopasnost' i zashchita sistemy.
     Poetomu vtoroj vyvod  tozhe sovershenno yasen:  pri zadanii razmera modulya
nuzhno tochno opredelit', chto on dolzhen delat'.
     I  tretij,  bolee ser'eznyj urok, kotoryj nuzhno izvlech' iz etogo opyta.
Proekt byl  slishkom velik,  a obshchenie mezhdu menedzherami nedostatochnym, chtoby
mnogochislennye uchastniki mogli  pochuvstvovat' sebya dobyvayushchimi zachetnye ochki
dlya komandy, a  ne  sozdatelyami  programmnyh produktov. Kazhdyj optimiziroval
svoj  lichnyj  uchastok,  chtoby  reshit'  postavlennye   zadachi,  i   malo  kto
zadumyvalsya nad  tem,  kak eto otrazitsya na  zakazchike. Poterya  orientacii i
svyazi predstavlyayut soboj glavnuyu opasnost'  dlya  bol'shih proektov. V techenie
vsej   razrabotki  sistemnye  arhitektory  dolzhny   podderzhivat'  postoyannuyu
bditel'nost'  dlya  obespecheniya postoyannoj celostnosti  sistemy. Odnako takaya
strategiya  zavisit ot  pozicii samih  razrabotchikov.  Edva  li ne glavnejshej
funkciej menedzhera  programmnogo  proekta  dolzhno  byt'  vospitanie  pozicii
zaboty ob obshchej sisteme, orientirovki na pol'zovatelya.
     Tehnologii sberezheniya pamyati
     Nikakoe  raspredelenie resursov pamyati i kontrol' ne sdelayut programmu
malen'koj. Dlya etogo trebuetsya izobretatel'nost' i masterstvo.
     Ochevidno,  chto chem bol'she  funkcij, tem bol'she trebuetsya pamyati pri tom
zhe  samom  bystrodejstvii.  Poetomu  pervoj oblast'yu,  gde  nuzhno  prilozhit'
masterstvo,  yavlyaetsya  nahozhdenie  kompromissa   mezhdu  funkcional'nost'yu  i
razmerom.  Zdes' my srazu stalkivaemsya s  vazhnoj strategicheskoj problemoj. V
kakoj  mere etot vybor  mozhno  predostavit' pol'zovatelyu? Mozhno  razrabotat'
programmu so mnogimi fakul'tativnymi funkciyami, kazhdaya  iz  kotoryh  trebuet
pamyati.  Mozhno skonstruirovat'  generator,  prosmatrivayushchij spisok  opcij  i
sootvetstvuyushchim  obrazom  adaptiruyushchij  programmu.  No  cel'naya   programma,
sootvetstvuyushchaya kazhdomu otdel'nomu spisku opcij, zanyala  by  men'she  pamyati.
|to kak v avtomobile: esli  podsvetka  karty, prikurivatel' i chasy  vhodyat v
prejskurant kak edinaya stat'ya,  ih stoimost' okazhetsya nizhe, chem esli porozn'
vybirat'  kazhdyj iz  predmetov.  Poetomu  proektirovshchiku  sleduet opredelit'
stepen' detalizacii opcij pol'zovatelya.
     Esli  sistema  proektiruetsya  dlya  raboty  s  pamyat'yu  raznogo  ob®ema,
voznikaet drugoj vazhnyj  vopros. Diapazon  prisposoblyaemosti nel'zya  sdelat'
proizvol'no shirokim - dazhe pri razbienii programmy na ochen' melkie moduli. V
malen'koj  sisteme  bol'shinstvo  modulej peregruzhaetsya.  Znachitel'naya  chast'
rezidentnoj pamyati malen'koj sistemy dolzhna byt' otvedena dlya  vremennoj ili
stranichnoj  pamyati,  v  kotoruyu   zagruzhayutsya  drugie   chasti.   Ee   razmer
ogranichivaet  razmer  kazhdogo modulya. A  razbienie  funkcij na melkie moduli
vlechet poteri i proizvoditel'nost', i pamyati. Poetomu v bol'shoj sisteme, gde
vremennaya  pamyat' v  dvadcat'  raz  bol'she,  ona  lish'  pozvolyaet  umen'shit'
kolichestvo  obrashchenij.  Iz-za malen'kih  razmerov modulej  sistema  vse-taki
teryaet  v skorosti i rashodovanii  pamyati.  Po  etoj  prichine  effektivnost'
sistemy, kotoruyu mozhno postroit' ih modulej malen'koj sistemy, ogranichena.
     Vtoroj oblast'yu  prilozheniya masterstva yavlyaetsya nahozhdenie  kompromissa
mezhdu  pamyat'yu  i bystrodejstviem. Dlya otdel'noj funkcii  uvelichenie  pamyati
vlechet za soboj rost bystrodejstviya,  chto  spravedlivo v udivitel'no shirokom
diapazone velichin. |tot fakt delaet vozmozhnym ustanovlenie resursov pamyati.
     CHtoby  oblegchit'  svoej  komande  poisk  pravil'nogo sootnosheniya  mezhdu
pamyat'yu  i proizvoditel'nost'yu, menedzher mozhet sdelat' dve  veshchi. Vo-pervyh,
organizovat' obuchenie tehnike programmirovaniya,  a ne prosto  polagat'sya  na
prirodnyj um i predshestvuyushchij opyt. |to osobenno vazhno, esli mashina ili yazyk
novye.  Osobennosti ih  effektivnogo  ispol'zovaniya  nuzhno  bystro izuchit' i
sdelat' obshchim dostoyaniem, vozmozhno, prisuzhdaya osobye prizy za osvoenie novoj
tehniki.
     Vo-vtoryh,  nuzhno  ponyat',  chto  u programmirovaniya est'  tehnologiya  i
komponenty nuzhno sobirat' iz gotovyh chastej. V kazhdom proekte dolzhen imet'sya
nabor  horoshih  procedur  ili  makrosov  dlya  obrabotki  ocheredej,   poiska,
heshirovaniya  i  sortirovki,  prichem  ne  menee  chem v dvuh  variantah: odnom
bystrom,  drugom  ekonomyashchem  pamyat'.  Razrabotka  takoj tehnologii yavlyaetsya
vazhnoj zadachej  realizacii, kotoruyu mozhno  reshat' parallel'no  s razrabotkoj
sistemnoj arhitektury.
     Predstavlenie - sut' programmirovaniya
     Za masterstvom stoit izobretatel'nost',  blagodarya  kotoroj poyavlyayutsya
ekonomichnye  i  bystrye programmy. Pochti  vsegda  eto  yavlyaetsya  rezul'tatom
strategicheskogo   proryva,   a   ne   takticheskogo  umeniya.   Inogda   takim
strategicheskim   proryvom  yavlyaetsya   algoritm,   kak,   naprimer,   bystroe
preobrazovanie Fur'e, predlozhennoe Kuli i  T'yuki, ili zamena n2 sravnenij na
n log n pri sortirovke.
     Gorazdo    chashche   strategicheskij   proryv   proishodit   v   rezul'tate
predstavleniya  dannyh  ili  tablic.  Zdes'  zaklyuchena serdcevina  programmy.
Pokazhite mne blok- shemy, ne pokazyvaya tablic, i ya  ostanus'  v zabluzhdenii.
Pokazhite  mne vashi tablicy, i blok-shemy, skorej vsego, ne ponadobyatsya:  oni
budut ochevidny.
     Primery   moshchi,  kotoroj  obladaet  predstavlenie,  legko  umnozhit'.  YA
vspominayu    odnogo    molodogo     cheloveka,    zanimavshegosya     sozdaniem
usovershenstvovannogo konsol'nogo interpretatora dlya  IBM  650.  Emu  udalos'
vmestit'  ego  v   porazitel'no  maloe  prostranstvo   blagodarya  razrabotke
interpretatora  dlya interpretatora  i  ponimaniyu  togo,  chto  vzaimodejstvie
cheloveka s  mashinoj proishodit medlenno i redko, a pamyat' doroga. |legantnyj
malen'kij kompilyator s Fortran firmy Digitek ispol'zuet osoboe ochen' plotnoe
predstavlenie koda samogo kompilyatora,  blagodarya chemu ne trebuetsya  vneshnej
pamyati. Vremya, kotoroe  tratitsya na raspakovku koda, desyatikratno  okupaetsya
za schet otsutstviya vvoda-vyvoda. (Uprazhneniya v konce glavy  6 knigi Bruksa i
Iversona  "Avtomaticheskaya   obrabotka   dannyh"1  vklyuchaet  podborku   takih
primerov, kak i mnogie uprazhneniya u Knuta.2)
     Programmist, lomayushchij golovu po povodu nehvatki pamyati,  chasto postupit
luchshe  vsego,  ostaviv  v  pokoe  svoj  kod,  vernuvshis'  nazad i horoshen'ko
posmotrev svoi dannye. Predstavlenie - sut' programmirovaniya.


    Glava 10. Dokumentarnaya gipoteza

     Gipoteza:
     Sredi  morya  bumag neskol'ko  dokumentov  stanovyatsya kriticheski vazhnymi
osyami,  vokrug  kotoryh  vrashchaetsya  vse  upravlenie proektom.  Oni  yavlyayutsya
glavnymi lichnymi instrumentami menedzhera.
     Tehnologiya,  pravila  firmy  i  tradicii  remesla  trebuyut  vypolnit'
nekotoroe  kolichestvo kancelyarskoj  raboty  po  proektu.  Menedzheru-novichku,
tol'ko chto samomu byvshemu masterovym, eta rabota kazhetsya sovershennoj pomehoj
i nenuzhnym otvlecheniem, bumazhnym valom, grozyashchim zahlestnut' ego. Po bol'shej
chasti tak i est' v dejstvitel'nosti.
     Odnako ponemnogu  on  nachinaet  ponimat', chto nekotoraya nebol'shaya chast'
etih  dokumentov zaklyuchaet v sebe znachitel'nuyu  chast'  ego  administrativnoj
raboty. Podgotovka kazhdogo iz nih sluzhit glavnym povodom dlya  sosredotocheniya
mysli i  kristallizacii  obsuzhdenij,  kotorye  bez  etogo  dlilis' by vechno.
Vedenie etih dokumentov  stanovitsya  mehanizmom nablyudeniya i preduprezhdeniya.
Sam dokument stanovitsya pamyatkoj, indikatorom  sostoyaniya  i bazoj dannyh dlya
sostavleniya otchetov.
     CHtoby  uvidet',  kak  eto   dolzhno  rabotat'  v   programmnom  proekte,
rassmotrim nekotorye dokumenty, poleznye i  v drugom kontekste, i posmotrim,
mozhno li sdelat' obobshcheniya.
     Dokumenty dlya proekta razrabotki komp'yutera
     Predpolozhim, chto razrabatyvaetsya komp'yuter. Kakie  vazhnejshie dokumenty
dolzhny byt' razrabotany?
     Celi. Zdes' opisyvaetsya, kakie potrebnosti nuzhno udovletvorit', a takzhe
zadachi, pozhelaniya, ogranicheniya i prioritety.
     Specifikacii.   |to   rukovodstvo   po  komp'yuteru   plyus  specifikacii
tehnicheskih harakteristik.  |to odin iz  pervyh dokumentov, sostavlyaemyh dlya
novogo produkta, i zavershaetsya on poslednim.
     Grafik.
     Byudzhet.  |to  ne  prosto  ogranichenie, no  odin  iz  naibolee  poleznyh
menedzheru dokumentov.  Nalichie  byudzheta  zastavlyaet osushchestvlyat' tehnicheskie
resheniya, kotoryh staralis' by izbezhat', i, chto eshche vazhnee, sluzhit vypolneniyu
i raz®yasneniyu strategicheskih reshenij.
     Organizacionnaya struktura.
     Prostranstvennoe raspolozhenie.
     Ocenka, prognoz,  ceny. Oni  nahodyatsya v ciklicheskoj  vzaimosvyazi,  chto
opredelyaet uspeh ili proval proekta:

     

     CHtoby  sdelat'  prognoz  rynka,  nuzhny  tehnicheskie   harakteristiki  i
ustanovlennye  ceny.  Cifry  prognoza  vmeste  s  zadannym  proektom  chislom
komponentov  opredelyayut  ocenku stoimosti proizvodstva  i  dolyu  rashodov na
razrabotku  i  fiksirovannyh  zatrat,  prihodyashchihsya  na odno ustrojstvo. |ti
rashody, v svoyu ochered', opredelyayut ceny.
     Esli  ceny nizhe  ustanovlennyh, nachinaetsya  radostnaya raskrutka spirali
uspeha.   Prognoz  rastet,  stoimost'  odnogo  ustrojstva  padaet,   a  ceny
opuskayutsya eshche nizhe.
     Esli ceny vyshe ustanovlennyh, nachinaetsya raskrutka spirali  katastrofy,
i vse  sily  dolzhny byt' brosheny  na to,  chtoby slomit'  ee.  Nuzhno uluchshit'
tehnicheskie  harakteristiki  i razrabotat' novye  prilozheniya,  chtoby podnyat'
rynochnyj  prognoz.  Izderzhki  nuzhno snizit',  chtoby  poluchit'  bolee  nizkie
ocenki. Napryazhennost' takogo cikla  chasto trebuet bol'shih usilij marketologa
i inzhenera.
     Pri etom  vozmozhny zabavnye kolebaniya.  YA vspominayu mashinu, u kotoroj v
techenie  treh  let razrabotki kazhdye polgoda schetchik komand ustraivalsya to v
operativnoj  pamyati,  to vne  ee. Na  odnom etape  trebovalis'  chut'  luchshie
harakteristiki,  i  schetchik  delali  na  tranzistorah.  Na  sleduyushchem  etape
nachinalas' bor'ba za snizhenie stoimosti, poetomu schetchik organizovyvalsya kak
adres v operativnoj pamyati. V drugom proekte  luchshij izvestnyj  mne menedzher
po  inzhenernym proektam  sluzhil  gigantskim  mahovikom, gasya  svoej inerciej
kolebaniya, ishodivshie ot marketinga i menedzhmenta.
     Dokumenty dlya fakul'teta v universitete
     Nesmotrya  na  ogromnye razlichiya v  celyah i  deyatel'nosti,  kriticheskoe
mnozhestvo dlya predsedatelya  fakul'teta  v  universitete  sostavlyaet  shodnoe
chislo  shodnyh  dokumentov. Pochti kazhdoe reshenie dekana,  soveta kafedry ili
predsedatelya yavlyaetsya specifikaciej ili izmeneniem sleduyushchih dokumentov:
     Celi.
     Opisanie kursa.
     Trebovaniya k soiskatelyu stepeni.
     Predlozheniya   po  issledovatel'skoj  rabote  (i   plany,   pri  nalichii
finansirovaniya).
     Raspisanie zanyatij i naznachenie prepodavatelej.
     Byudzhet.
     Pomeshcheniya.
     Naznachenie rukovoditelej dlya aspirantov.
     Obratite vnimanie, chto dokumenty ochen' pohozhi na te, kotorye nuzhny dlya
komp'yuternogo  proekta: celi,  specifikacii produkta, raspredelenie vremeni,
deneg, mesta i lyudej. Tol'ko dokumenty s cenami otsutstvuyut: etim zanimaetsya
zakonodatel'noe  sobranie. Shodstvo  ne sluchajno  -  zabotami  vsyakoj zadachi
upravleniya yavlyayutsya: chto, kogda, po kakoj cene, gde i kto.
     Dokumenty dlya programmnogo proekta
     Vo mnogih programmnyh  proektah  rabota  nachinaetsya s  soveshchanij,  na
kotoryh obsuzhdaetsya struktura; zatem pristupayut k napisaniyu programm. Odnako
kak  by  ni byl  mal  proekt,  menedzher postupit  mudro, esli  srazu  nachnet
formalizovat' hotya by minidokumenty, kotorye posluzhat ego bazoj dannyh. I on
obnaruzhit, chto emu nuzhny, po  bol'shej chasti, te  zhe dokumenty, chto  i drugim
menedzheram.
     CHto:  celi.   Zdes'  opredelyaetsya,   kakie   potrebnosti  dolzhny   byt'
udovletvoreny, a takzhe zadachi, pozhelaniya, ogranicheniya i prioritety.
     CHto: specifikacii produkta. Nachinaetsya kak predlozhenie, a konchaetsya kak
rukovodstvo   i   vnutrennyaya   dokumentaciya.   Vazhnejshej   chast'yu   yavlyayutsya
specifikacii skorosti i pamyati.
     Kogda: grafik.
     Po kakoj cene: byudzhet.
     Gde: raspolozhenie pomeshchenij.
     Kto: organizacionnaya  struktura.  Ona  perepletaetsya  so  specifikaciej
interfejsa, kak  predskazyvaet  zakon  Konveya:  "Organizacii,  proektiruyushchie
sistemy, neizbezhno proizvodyat sistemy, yavlyayushchiesya kopiyami ih organizacionnyh
struktur".1  Konvej idet dal'she i ukazyvaet, chto  organizacionnaya  struktura
pervonachal'no  otrazhaet   proekt  pervoj  sistemy,  kotoryj  navernyaka   byl
oshibochnym. Esli proekt  sistemy  dolzhen  dopuskat'  vnesenie izmenenij, to i
organizaciya dolzhna byt' gotova k peremenam.
     Zachem nuzhny formal'nye dokumenty?
     Vo-pervyh,  neobhodimo  zapisyvat'  prinyatye  resheniya.  Tol'ko  kogda
pishesh', stanovyatsya vidny propuski i prostupayut nesoglasovannosti. V processe
zapisyvaniya  voznikaet  neobhodimost'  prinyatiya  soten  mini-reshenij,  i  ih
nalichie otlichaet chetkuyu i yasnuyu politiku ot rasplyvchatoj.
     Vo-vtoryh,  posredstvom  dokumentov  resheniya  soobshchayutsya  ispolnitelyam.
Menedzheru prihoditsya  postoyanno udivlyat'sya, chto  politika, kotoruyu on schital
izvestnoj  vsem, okazyvaetsya  sovershenno neizvestnoj odnomu  iz  chlenov  ego
komandy. Poskol'ku osnovnaya ego rabota sostoit v tom,  chtoby vse dvigalis' v
odnom  napravlenii,  ego  glavnaya  ezhednevnaya  zadacha  zaklyuchaetsya  v obmene
informaciej, a  ne  prinyatii  reshenij, i  dokumenty ochen'  oblegchat emu  etu
nagruzku.
     Nakonec,  dokumenty obrazuyut  bazu  dannyh menedzhera i ego  kontrol'nyj
spisok.  Periodicheski izuchaya ih,  on vidit, v kakoj tochke puti  nahoditsya, i
opredelyaet neobhodimost' smeshcheniya akcentov ili izmeneniya napravleniya.
     YA  ne  razdelyayu   vydvigaemyh   prodavcami   videnij   "vseohvatyvayushchej
informacionnoj sistemy dlya  upravleniya", v  kotoroj  administrator  vvodit v
komp'yuter zapros s klaviatury, i na ekrane vspyhivaet nuzhnyj emu otvet. Est'
mnogo fundamental'nyh  prichin,  po kotorym etogo ne proizojdet. Odna prichina
zaklyuchaetsya v  tom, chto  tol'ko  malen'kaya  chast',  vozmozhno  20  procentov,
rabochego vremeni  administratora zanyata zadachami, kotorye trebuyut  svedenij,
otsutstvuyushchih v ego pamyati. A vse ostal'noe vremya  -  eto obshchenie:  slushat',
otchityvat'sya, obuchat', ubezhdat', sovetovat', obodryat'. No  dlya toj doli, dlya
kotoroj  dejstvitel'no nuzhny dannye, neobhodimy neskol'ko vazhnyh dokumentov,
kotorye udovletvoryayut bol'shinstvo nuzhd.
     Zadacha menedzhera sostoit v tom, chtoby razrabotat' plan i vypolnit' ego.
No tol'ko zapisannyj plan yavlyaetsya tochnym i mozhet byt' soobshchen drugim. Takoj
plan sostoit  iz dokumentov, opisyvayushchih:  chto, kogda,  po kakoj cene, gde i
kto.  |tot  malen'kij  nabor vazhnyh dokumentov ohvatyvaet znachitel'nuyu chast'
raboty  menedzhera.  Esli  v samom  nachale ponyat' ih vseohvatyvayushchuyu i vazhnuyu
sushchnost', to oni stanut dlya menedzhera dobrym instrumentom, a ne razdrazhayushchej
obuzoj. Sdelav eto, on opredelit svoj kurs bolee chetko i bystro.


    Glava  11.  Planirujte  na  vybros

     V  etom  mire  net  nichego  postoyannee
nepostoyanstva.
     SVIFT
     Razumno vzyat'  metod i ispytat' ego. Pri  neudache  chestno priznajtes' v
etom i poprobujte drugoj metod. No glavnoe, delajte chto-nibud'.
     FRANKLIN D. RUZVELXT
     Opytnye zavody i masshtabirovanie
     Inzhenery-himiki  davno ponyali, chto process,  uspeshno osushchestvlyaemyj v
laboratorii, nel'zya odnim  mahom  perenesti v  zavodskie  usloviya. Neobhodim
promezhutochnyj shag, sozdanie opytnogo zavoda, chtoby poluchit' opyt narashchivaniya
kolichestv veshchestv  i funkcionirovaniya  v  nezashchishchennyh  sredah.  K  primeru,
laboratornyj process  opresneniya  vody  sleduet proverit' na opytnom  zavode
moshchnost'yu 50  tysyach litrov  v  den',  prezhde chem  ispol'zovat'  v  gorodskoj
sisteme vodosnabzheniya moshchnost'yu 10 mln. litrov v den'.
     Razrabotchiki programmnyh sistem tozhe poluchili etot urok, no, pohozhe, do
sih  por ego  ne  usvoili.  V  odnom  proekte za  drugim  razrabatyvayut  ryad
algoritmov  i  zatem nachinayut  sozdavat'  postavlyaemoe  klientu  programmnoe
obespechenie po grafiku, trebuyushchemu postavki pervoj zhe sborki.
     V  bol'shinstve proektov  pervoj  postroennoj  sistemoj  s  trudom mozhno
pol'zovat'sya. Ona mozhet byt' slishkom medlennoj, slishkom bol'shoj, neudobnoj v
ispol'zovanii,  a to i vse  vmeste. Ne  ostaetsya  drugoj al'ternativy, krome
kak, poumnev,  nachat' snachala i  postroit' pereproektirovannuyu  programmu, v
kotoroj  eti  problemy resheny. Brakovka  i pereproektirovanie mogut delat'sya
dlya vsej sistemy srazu ili po chastyam. No ves' opyt razrabotki bol'shih sistem
pokazyvaet, chto  budet  sdelano.2 V  teh sluchayah,  kogda  ispol'zuyutsya novye
sistemnye  koncepcii  i novye tehnologii,  prihoditsya  sozdavat' sistemu  na
vybros,  poskol'ku dazhe samoe  luchshee planirovanie ne stol' vsevedushche, chtoby
popast' v cel' s pervogo raza.
     Poetomu problema ne v tom,  sozdavat' ili  net opytnuyu sistemu, kotoruyu
pridetsya  vybrosit'.  Vy vse ravno eto sdelaete. Vopros  edinstvenno  v tom,
planirovat'  li zaranee razrabotku sistemy  na vybros ili  obeshchat'  klientam
postavku sistemy, kotoruyu pridetsya  vybrosit'. Esli smotret' pod etim uglom,
otvet  stanovitsya namnogo proshche.  Postavka  hlama klientu pozvolyaet vyigrat'
vremya,   no   proishodit   eto  cenoj   muchenij   pol'zovatelya,   otvlechenij
razrabotchikov  vo vremya  pereproektirovaniya  i  durnoj  reputacii  produkta,
kotoruyu  dazhe   samoj  udachno  pereproektirovannoj  programme  budet  trudno
pobedit'.
     Poetomu planirujte vybrosit' pervuyu versiyu - vam vse ravno pridetsya eto
sdelat'.
     Postoyanny tol'ko izmeneniya
     Posle uyasneniya togo, chto  opytnuyu  sistemu  nuzhno  sozdavat', a potom
vybrosit',  i  chto pereproektirovanie  s novymi  ideyami  neizbezhno,  polezno
obratit'sya licom k izmeneniyu  kak  yavleniyu prirody. Pervyj  shag -  priznanie
togo,  chto  izmenenie  -  eto obraz  zhizni,  a  ne  postoronnee  i  dosadnoe
isklyuchenie. Kosgrouv mudro ukazal, chto programmist postavlyaet udovletvorenie
potrebnosti pol'zovatelya, a ne kakoj- to osyazaemyj produkt. I v to vremya kak
programmy  sozdayutsya, testiruyutsya i  ispol'zuyutsya, menyayutsya  kak fakticheskie
potrebnosti pol'zovatelya, tak i ponimanie im svoih potrebnostej.3
     Konechno, eto  spravedlivo  i v otnoshenii potrebnostej,  udovletvoryaemyh
fizicheskimi  produktami,   bud'   to  avtomobili  ili  komp'yutery.  No  samo
sushchestvovanie  osyazaemogo  produkta opredelyaet  zaprosy  pol'zovatelya  i  ih
kvantovanie. Podatlivost'  i  neosyazaemost' programmnogo produkta  pobuzhdayut
ego sozdatelej k beskonechnomu izmeneniyu trebovanij.
     YA dalek ot togo, chtoby schitat',  budto vse izmeneniya celej i trebovanij
klienta mozhno  ili  neobhodimo  uchityvat' v  proekte. Ochevidno,  dolzhen byt'
ustanovlennyj  porog, kotoryj  dolzhen podnimat'sya vse  vyshe  i vyshe  po hodu
razrabotki, inache ni odin produkt nikogda ne budet sozdan.
     Tem  ne  menee  nekotorye  izmeneniya  v  zadachah  neizbezhny,  i   luchshe
podgotovit'sya  k  nim  zaranee,  chem  predpolagat',  chto  ih  ne  vozniknet.
Neizbezhny  ne tol'ko  izmeneniya  v celyah,  no  takzhe  izmeneniya  v strategii
razrabotki i  tehnologii.  Koncepciya  "raboty na  musornyj  yashchik" est'  lish'
priznanie togo fakta, chto po mere priobreteniya opyta menyaetsya proekt.4
     Planirujte vnesenie izmenenij v sistemu
     Sposoby proektirovaniya  sistemy s  uchetom  budushchih  izmenenij  horosho
izvestny i shiroko obsuzhdayutsya v literature - vozmozhno, shire obsuzhdayutsya, chem
primenyayutsya. Oni vklyuchayut v sebya tshchatel'noe razbienie na moduli, intensivnoe
ispol'zovanie  podprogramm,   tochnoe  i   polnoe   opredelenie  mezhmodul'nyh
interfejsov  i  polnuyu  ih  dokumentaciyu.  Menee  ochevidno,  chto  pri  lyuboj
vozmozhnosti  neobhodimo ispol'zovat' standartnye posledovatel'nosti vyzova i
tehnologii tablichnogo upravleniya.
     Ochen'   vazhno   ispol'zovat'  yazyki   vysokogo  urovnya   i   tehnologii
samodokumentirovaniya,  chtoby umen'shit' chislo  oshibok,  vyzyvaemyh izmenenij.
Moshchnuyu   podderzhku  pri  vnesenii  izmenenij   okazyvayut   operacii  vremeni
kompilyacii po vklyucheniyu standartnyh ob®yavlenij.
     Vazhnym priemom yavlyaetsya kvantovanie izmenenij.  Kazhdyj  produkt  dolzhen
imet' numerovannye versii, i kazhdaya versiya dolzhna imet' svoj grafik  rabot i
datu fiksacii, posle kotoroj izmeneniya vklyuchayutsya uzhe v sleduyushchuyu versiyu.
     Planirujte organizacionnuyu strukturu dlya vneseniya izmenenij
     Kosgrouv rekomenduet ko vsem planam, veham i grafikam otnosit'sya kak k
probam, chtoby oblegchit' izmeneniya. Zdes' on zahodit slishkom daleko - segodnya
gruppy programmistov  terpyat  neudachi  obychno  iz-za  slishkom slabogo, a  ne
slishkom sil'nogo administrativnogo kontrolya.
     Tem ne  menee on vykazyvaet bol'shuyu pronicatel'nost'.  On zamechaet, chto
nezhelanie dokumentirovat' proekt proishodit ne tol'ko ot leni ili nedostatka
vremeni.  Ono  proishodit  ot  nezhelaniya   proektirovshchika   svyazyvat'   sebya
otstaivaniem reshenij, kotorye, kak on znaet, predvaritel'nye.  "Dokumentiruya
proekt,  proektirovshchik stanovitsya ob®ektom  kritiki so vseh storon, i dolzhen
zashchishchat' vse, chto napisal. Esli organizacionnaya struktura mozhet predstavlyat'
ugrozu, ne budet dokumentirovat'sya nichego, krome togo, chto nel'zya osporit'."
     Sozdavat'  organizacionnuyu  strukturu  s  uchetom   vneseniya  v  budushchem
izmenenij znachitel'no trudnee,  chem proektirovat' sistemu  s uchetom  budushchih
izmenenij. Kazhdyj poluchaet zadanie, rasshiryayushchee krug ego obyazannostej, chtoby
sdelat'  tehnicheski  bolee  gibkim  vse  podrazdelenie.  V  bol'shih proektah
menedzheru nuzhno imet' dvuh  ili treh vysokoklassnyh programmistov v kachestve
rezerva, kotoryj mozhno brosit' na samyj opasnyj uchastok boya.
     Strukturu  upravleniya takzhe nuzhno izmenyat'  po mere  izmeneniya sistemy.
|to oznachaet, chto  rukovoditel' dolzhen udelit' bol'shoe  vnimanie tomu, chtoby
ego  menedzhery   i  tehnicheskij  personal  byli  nastol'ko  vzaimozamenyaemy,
naskol'ko pozvolyayut ih sposobnosti.
     Bar'ery  yavlyayutsya   sociologicheskimi,   i  s  nimi  nuzhno  bditel'no  i
nastojchivo  borot'sya. Vo-pervyh, menedzhery sami  rassmatrivayut  rukovoditelya
kak  "slishkom   bol'shuyu  cennost'",  chtoby  ispol'zovat'  ih  dlya  real'nogo
programmirovaniya.  Vo-  vtoryh,  rabota  menedzhera  obladaet  bolee  vysokim
prestizhem.  CHtoby  preodolet'   eti  slozhnosti,  v  nekotoryh  laboratoriyah,
naprimer,  v  Bell  Labs,  uprazdnyayut  vse  naimenovaniya dolzhnostej.  Kazhdyj
professional'nyj  sluzhashchij  yavlyaetsya "tehnicheskim  sotrudnikom".  V  drugih,
naprimer   v   IBM,   vvodyat  dvojnuyu  lestnicu  prodvizheniya   (ris.  11.1).
Sootvetstvuyushchie stupen'ki teoreticheski ravnoznachny.

     

     Ris. 11.1 Dvojnaya sluzhebnaya lestnica IBM
     Legko   ustanovit'   sootvetstvuyushchie   stupen'kam   razmery  zhalovaniya.
Znachitel'no  trudnee  dat' im sootvetstvuyushchij prestizh.  Ofisy  dolzhny  imet'
odinakovyj  razmer  i  obstanovku. Sekretarskie i  prochie sluzhby dolzhny byt'
sootvetstvuyushchimi. Perevod s tehnicheskoj lestnicy  v upravlencheskuyu ne dolzhen
soprovozhdat'sya povysheniem, i o nem vsegda nuzhno soobshchat' kak o "perevode", a
ne  kak  o  "povyshenii".  Obratnyj  perevod  vsegda  dolzhen   soprovozhdat'sya
pribavkoj k zhalovan'yu.
     Menedzherov  nuzhno  posylat'  na  kursy  tehnicheskoj  perepodgotovki,  a
starshij tehnicheskij personal - na  kursy obucheniya upravleniyu. Celi  proekta,
hod raboty i administrativnye problemy dolzhny dovodit'sya do vseh rukovodyashchih
rabotnikov.
     Esli pozvolyaet podgotovka, rukovodyashchie rabotniki dolzhny byt' tehnicheski
i  moral'no gotovy  vozglavit' gruppy  ili nasladit'sya razrabotkoj  programm
sobstvennymi rukami. Konechno, osushchestvlenie vsego etogo trebuet mnogo truda,
no rezul'tat togo stoit!
     Ideya  organizacii  grupp  programmistov  napodobie operacionnyh  brigad
predstavlyaet  soboj   korennoe  reshenie  etoj   problemy.   Ona   zastavlyaet
rukovodyashchego rabotnika  pochuvstvovat', chto  on ne unizhaet  sebya, kogda pishet
programmy,  i pytaetsya ubrat'  social'nye prepyatstviya, meshayushchie emu ispytat'
radost' tvorchestva.
     Bolee  togo,   eta  struktura   prednaznachena   dlya   sokrashcheniya  chisla
interfejsov. Blagodarya ej sistemu mozhno izmenyat' s maksimal'noj legkost'yu, i
stanovitsya otnositel'no prosto perenapravit' vsyu brigadu na drugoe zadanie v
sluchae   neobhodimosti    organizacionnyh   izmenenij.   |to   dejstvitel'no
dolgosrochnoe reshenie problemy gibkoj organizacii.
     Dva shaga vpered, shag nazad
     Programma  ne  perestaet  izmenyat'sya posle  svoej  postavki  klientu.
Izmeneniya  posle  postavki  nazyvayutsya  soprovozhdeniem  programmy,  no  etot
process v korne otlichaetsya ot soprovozhdeniya apparatnoj chasti.
     Soprovozhdenie apparatnoj  chasti komp'yuternoj  sistemy  sostoit iz  treh
vidov   deyatel'nosti:  zameny   isporchennyh  detalej,  chistki   i  smazki  i
osushchestvleniya tehnicheskih izmenenij dlya ispravleniya konstruktivnyh defektov.
(Bol'shaya   chast'  tehnicheskih  izmenenij,   no  ne  vse,  ustranyaet  defekty
razrabotki   ili   realizacii,   a   ne   arhitektury,  i  potomu  nezametna
pol'zovatelyu.)
     Soprovozhdenie  programm  ne  predpolagaet  chistki,  smazki  ili  zameny
isportivshihsya   komponentov.  Ono  sostoit  glavnym  obrazom  iz  izmenenij,
ispravlyayushchih konstruktivnye defekty. Gorazdo chashche, chem dlya apparatnoj chasti,
eti  izmeneniya vklyuchayut  v  sebya dopolnitel'nye funkcii.  Obychno  oni  vidny
pol'zovatelyu.
     Obshchaya  stoimost'  soprovozhdeniya shiroko  ispol'zuemoj  programmy  obychno
sostavlyaet 40 i bolee procentov stoimosti ee razrabotki. Udivitel'no, chto na
stoimost'  soprovozhdeniya  sil'no  vliyaet  chislo  pol'zovatelej.  CHem  bol'she
pol'zovatelej, tem bol'she oshibok oni nahodyat.
     Betti Kempbell iz  Laboratorii  yadernoj  fiziki MTI otmechaet interesnyj
cikl  v  zhizni otdel'noj  versii  programmy.  On pokazan na risunke 11.2.  V
nachale  sushchestvuet  tendenciya   povtornogo  poyavleniya  oshibok,  najdennyh  i
ustranennyh v predydushchih  versiyah. Obnaruzhivayutsya oshibki v funkciyah, vpervye
poyavivshihsya v novoj  versii.  Vse oni  ispravlyayutsya, i  v techenie neskol'kih
mesyacev vse idet horosho. Zatem kolichestvo obnaruzhennyh oshibok snova nachinaet
rasti. Po mneniyu Kempbell, eto  proishodit  potomu, chto pol'zovateli vyhodyat
na novyj uroven'  slozhnosti,  nachinaya  polnost'yu primenyat' novye vozmozhnosti
versii.  |ta  intensivnaya  rabota  vyyavlyaet  bolee skrytye  oshibki  v  novyh
funkciyah.5

     

     Ris.  11.2  CHastota  obnaruzheniya oshibok  kak  funkciya  vozrasta  versii
programmy
     Fundamental'naya problema pri soprovozhdenii  programm sostoit v tom, chto
ispravlenie odnoj  oshibki s bol'shoj  veroyatnost'yu  (20-50 procentov)  vlechet
poyavlenie novoj. Poetomu  ves' process  idet po  principu  "dva shaga vpered,
odin nazad".
     Pochemu ne udaetsya  ustranit'  oshibki bolee  akkuratno? Vo-pervyh,  dazhe
skrytyj  defekt  proyavlyaet   sebya  kak  otkaz  v  kakom-to  odnom  meste.  V
dejstvitel'nosti  zhe  on chasto  imeet razvetvleniya po  vsej sisteme,  obychno
neochevidnye. Vsyakaya popytka ispravit' ego minimal'nymi usiliyami  privedet  k
ispravleniyu lokal'nogo i ochevidnogo,  no esli  tol'ko  struktura ne yavlyaetsya
ochen'  yasnoj ili dokumentaciya  ochen' horoshej,  otdalennye  posledstviya etogo
ispravleniya ostanutsya nezamechennymi. Vo-vtoryh, ispravlyaet  oshibki obychno ne
avtor programmy, i chasto eto mladshij programmist ili stazher.
     Vsledstvie   vneseniya  novyh  oshibok  soprovozhdenie  programmy  trebuet
znachitel'no  bol'she  sistemnoj otladki  na  kazhdyj operator,  chem  pri lyubom
drugom vide programmirovaniya.  Teoreticheski, posle kazhdogo ispravleniya nuzhno
prognat'  ves'  nabor kontrol'nyh primerov,  po kotorym  sistema proveryalas'
ran'she,  chtoby   ubedit'sya,  chto  ona  kakim-nibud'  neponyatnym  obrazom  ne
povredilas'. Na praktike takoe vozvratnoe testirovanie  dejstvitel'no dolzhno
priblizhat'sya k etomu teoreticheskomu idealu, i ono ochen' dorogo stoit.
     Ochevidno, metody  razrabotki  programm, pozvolyayushchie  isklyuchit' ili,  po
krajnej  mere,  vyyavit'  pobochnye  effekty,  mogut  rezko snizit'  stoimost'
soprovozhdeniya,  kak i  metody razrabotki proektov men'shim chislom  lyudej  i s
men'shim chislom interfejsov - a znachit, i s men'shim chislom oshibok.
     SHag vpered, shag nazad
     Leman  i  Beladi  izuchili istoriyu  posledovatel'nyh  vypuskov  bol'shoj
operacionnoj  sistemy.6  Oni  schitayut,  chto  obshchee kolichestvo modulej rastet
linejno s  nomerom versii, no chislo modulej,  zatronutyh izmeneniyami, rastet
eksponencial'no  v  zavisimosti  ot nomera  versii.  Vse  ispravleniya  imeyut
tendenciyu  k razrusheniyu  struktury,  uvelicheniyu  entropii  i  dezorganizacii
sistemy. Vse men'she sil tratitsya  na ispravlenie  oshibok ishodnogo proekta i
vse bol'she - na likvidaciyu posledstvij predydushchih ispravlenij. Po proshestvii
vremeni sistema stanovitsya vse menee i menee organizovannoj. Rano ili pozdno
ispravlenie oshibok teryaet  smysl. Na kazhdyj shag vpered prihoditsya shag nazad.
V principe godnaya dlya vechnogo ispol'zovaniya sistema  perestaet byt'  osnovoj
razvitiya.   Krome   togo,   menyayutsya   mashiny,    konfiguracii,   trebovaniya
pol'zovatelya,  tak   chto  fakticheski   sistema  yavlyaetsya  vechnoj.  Neobhodim
sovershenno novyj proekt, vypolnyaemyj s samogo nachala.
     Ot mehanicheskoj statisticheskoj  modeli Beladi i Leman prihodyat k obshchemu
zaklyucheniyu otnositel'no programmnyh sistem, kotoroe podkrepleno vsem  opytom
chelovechestva. "Luchshaya pora veshchej - kogda oni tol'ko chto poyavilis'", - skazal
Paskal'. CH. S. L'yuis vyrazil eto bolee vesomo:
     Vot   klyuch  k  ponimaniyu   istorii.  Vysvobozhdaetsya  ogromnaya  energiya,
voznikayut civilizacii, sozdayutsya prekrasnye uchrezhdeniya, no vsyakij raz chto-to
proishodit ne tak. Kakaya-to rokovaya oshibka voznosit na vershinu sebyalyubivyh i
zhestokih lyudej, i  vse  skatyvaetsya nazad,  v nishchetu i ruiny. Dejstvitel'no,
mashina glohnet. Ona normal'no startuet i proezzhaet neskol'ko metrov, a zatem
lomaetsya.7
     Sistemnoe programmirovanie yavlyaetsya processom,  umen'shayushchim entropiyu, a
potomu emu vnutrenne prisushcha metastabil'nost'. Soprovozhdenie  programm  est'
process,  uvelichivayushchij entropiyu,  i dazhe  samoe  umeloe  ego  vedenie  lish'
otdalyaet vpadenie sistemy v beznadezhnoe ustarevanie.


    Glava 12. Ostryj instrument

     Horoshego rabotnika uznayut po instrumentu.
     POSLOVICA
     Dazhe  v  nashe  vremya  mnogie  programmnye  proekty,  s  tochki  zreniya
ispol'zovaniya  instrumentariya,  rabotayut  kak  mehanicheskie   masterskie.  U
kazhdogo mehanika  est' svoj nabor  instrumentov, sobiravshijsya v techenie vsej
zhizni, kotoryj  on tshchatel'no zapiraet i  ohranyaet -  naglyadnoe svidetel'stvo
lichnogo  masterstva. Tochno  takzhe programmist sobiraet malen'kie  redaktory,
sortirovki, dvoichnye dampy, utility dlya raboty s diskami i pripryatyvaet ih v
svoih fajlah.
     Odnako takoj  podhod ne opravdan  pri rabote nad  programmnym proektom.
Vo- pervyh,  vazhnoj zadachej yavlyaetsya  obmen informaciej, a lichnyj instrument
emu  meshaet,  a ne sodejstvuet. Vo-vtoryh, pri perehode na novuyu  mashinu ili
novyj rabochij  yazyk  tehnologiya  menyaetsya,  poetomu  srok zhizni  instrumenta
nedolog.   I    nakonec,   ochevidno,   znachitel'no   effektivnee   sovmestno
razrabatyvat' i soprovozhdat' programmnye instrumenty obshchego naznacheniya.
     Odnako   nedostatochno   imet'   instrumenty  obshchego   naznacheniya.   Kak
special'nye zadachi,  tak i lichnye predpochteniya  obuslovlivayut  neobhodimost'
imet' takzhe  i specializirovannyj instrument. Poetomu pri obsuzhdenii sostava
komandy programmistov ya predlagal  imet' v brigade odnogo instrumental'shchika.
|tot chelovek vladeet vsemi  obshchedostupnymi instrumentami i  mozhet obuchat' ih
ispol'zovaniyu.  On  mozhet takzhe  sozdavat'  specializirovannye  instrumenty,
kotorye potrebuyutsya ego nachal'niku.
     Takim  obrazom, menedzher proekta dolzhen ustanovit' principy  i vydelit'
resursy dlya razrabotki obshchih instrumentov. V to zhe vremya  on dolzhen ponimat'
neobhodimost'   v  specializirovannyh  instrumentah   i  ne   prepyatstvovat'
razrabotke  sobstvennyh  instrumentov v podchinennyh  rabochih  gruppah.  Est'
opasnyj  soblazn  popytat'sya  dostich'  bol'shej  effektivnosti, sobrav vmeste
otdel'nyh    razrabotchikov    instrumenta    i    dorabotav    obshchegruppovoj
instrumentarij. No eto ne udaetsya.
     CHto  eto za instrumenty, razrabotku kotoryh menedzher dolzhen obdumyvat',
planirovat' i  organizovyvat'?  Prezhde  vsego, vychislitel'nye  sredstva. Dlya
etogo trebuyutsya mashiny, i dolzhna byt' prinyata politika planirovaniya vremeni.
Dlya etogo trebuetsya operacionnaya sistema, i dolzhna byt' ustanovlena politika
obsluzhivaniya. Dlya  etogo trebuetsya  yazyk, i  dolzhna byt' zalozhena politika v
otnoshenii   yazyka.   Zatem  idut   utility,   sredstva  otladki,  generatory
kontrol'nyh  primerov  i  tekstovyj processor  dlya  raboty s  dokumentaciej.
Rassmotrim ih poocheredno.1
     Celevye mashiny
     Mashinnuyu  podderzhku polezno razdelit'  na  celevye  mashiny i  rabochie
mashiny. Celevaya mashina - eto ta, dlya kotoroj pishetsya programmnoe obespechenie
i na kotoroj, v konce koncov,  ego nuzhno budet testirovat'. Rabochie mashiny -
eto te, kotorye  predostavlyayut  servisy, ispol'zuemye dlya  sozdaniya sistemy.
Esli sozdaetsya novaya operacionnaya sistema dlya staroj mashiny, poslednyaya mozhet
sluzhit' odnovremenno i celevoj, i rabochej.
     Kakovy tipy celevyh sredstv?  Esli brigada sozdaet novyj supervizor ili
drugoe  programmnoe  sredstvo,  sostavlyayushchee  serdcevinu  sistemy,  to   ej,
konechno,  nuzhna svoya  mashina. Dlya  takih sistem potrebuyutsya operatory i odin
ili dva sistemnyh programmista, chtoby mashina byla v rabochem sostoyanii.
     Esli   trebuetsya  otdel'naya  mashina,   to  ona  dolzhna  byt'   dovol'no
specificheskoj:  ne  trebuetsya,  chtoby  ona  byla bystroj,  no  trebuetsya, po
men'shej mere,  1 Mbajt  operativnoj  pamyati,  100 Mbajt v aktivnyh diskah  i
terminaly.  Dostatochno  simvol'nyh terminalov,  no  so  znachitel'no  bol'shej
skorost'yu,  chem  15  simvolov v  sekundu, harakternyh  dlya  pishushchih mashinok.
Nalichie  bol'shoj pamyati  znachitel'no sposobstvuet  produktivnosti,  pozvolyaya
zanyat'sya razbieniem na overlei  i  minimizaciej  razmera posle  testirovaniya
funkcij.
     Mashina ili programmnye sredstva dlya otladki dolzhny takzhe imet' sredstva
dlya avtomaticheskogo podscheta i izmerenij lyubyh parametrov programmy vo vremya
otladki. K primeru, karty ispol'zovaniya pamyati sluzhat moshchnym diagnosticheskim
sredstvom pri vyyasnenii  strannoj  logiki povedeniya  ili  neozhidanno  nizkoj
proizvoditel'nosti.
     Planirovanie  vremeni. Esli celevaya mashina novaya, -  naprimer, dlya  nee
sozdaetsya  pervaya  operacionnaya  sistema,  -  to  mashinnogo  vremeni malo, i
planirovanie  stanovitsya  bol'shoj  problemoj. Potrebnosti  v rabochem vremeni
celevoj mashiny imeet specificheskuyu krivuyu rosta. Pri razrabotke OS/360 u nas
byli  horoshie  emulyatory System/360 i  drugie mashiny. Po prezhnemu  opytu  my
ocenili, skol'ko  chasov  rabochego  vremeni S/360  nam  ponadobitsya, i  stali
poluchat'  pervye  mashiny s proizvodstva. No mesyac  za mesyacem oni ostavalis'
bez  nagruzki.  Zatem  srazu   vse  16  sistem  okazalis'  zagruzhennymi,   i
raspredelenie  vremeni   stalo  problemoj.   Ispol'zovanie  mashin  vyglyadelo
primerno  kak  na risunke 12.1.  Vse odnovremenno  nachali otlazhivat'  pervye
komponenty, i zatem vse komandy postoyanno chto-to otlazhivali.

     

     Ris. 12.1 Rost ispol'zovaniya celevyh mashin
     My  centralizovali vse  svoi  mashiny  i  biblioteki  magnitnyh  lent  i
organizovali dlya ih raboty professional'nuyu i opytnuyu gruppu mashinnogo zala.
Dlya maksimizacii byvshego v nedostatke mashinnogo vremeni S/360 vse otladochnye
progony my osushchestvlyali v  paketnom rezhime na  podhodyashchih svobodnyh mashinah.
My  dobilis'  chetyreh  zapuskov v  den'  (oborachivaemost'  sostavila  dva  s
polovinoj    chasa),   a    trebovalas'    chetyrehchasovaya    oborachivaemost'.
Vspomogatel'naya mashina  1401 s terminalami  ispol'zovalas' dlya  planirovaniya
progonov, otslezhivaniya tysyach zadanij i kontrolya vremeni oborachivaemosti.
     No  so  vsej etoj  organizovannost'yu my perestaralis'. Posle neskol'kih
mesyacev nizkoj oborachivaemosti, vzaimnyh obvinenij i prochih muk my pereshli k
vydeleniyu mashinnogo  vremeni  krupnymi blokami.  K primeru,  vsya  gruppa  iz
pyatnadcati  chelovek,  zanimavshayasya sortirovkoj,  poluchala sistemu na srok ot
chetyreh do shesti chasov. Planirovanie etogo vremeni bylo ih vnutrennim delom.
Dazhe esli sistema byla na zanyata, postoronnie ne mogli eyu pol'zovat'sya.
     |to  okazalos'  bolee udachnym sposobom planirovaniya.  Hotya  koefficient
ispol'zovaniya mashiny, vozmozhno, neskol'ko upal (a  chasto  i etogo  ne bylo),
proizvoditel'nost'  podnyalas'. Dlya kazhdogo  chlena komandy  desyat' zapuskov v
techenie   shesti   chasov   znachitel'no  produktivnee,  chem  desyat'  zapuskov,
osushchestvlennyh s  pereryvami v tri chasa, poskol'ku  postoyannaya  koncentraciya
sokrashchaet vremya obdumyvaniya. Posle  takoj  gonki  komande obychno trebovalos'
odin-dva  dnya,  chtoby  podognat'  rabotu s dokumentami, prezhde chem prosit' o
vydelenii novogo  bloka.  Zachastuyu vsego tri  programmista mogut  s  pol'zoj
podelit' i raspredelit' mezhdu soboj vydelennyj im blok  vremeni. Pohozhe, chto
eto   luchshij  sposob   ispol'zovaniya  celevoj   mashiny  pri  otladke   novoj
operacionnoj sistemy.
     Tak  bylo na  praktike,  hotya eto ne sootvetstvovalo  teorii. Sistemnaya
otladka vsegda byla zanyatiem dlya nochnoj smeny,  podobno astronomii. Dvadcat'
let nazad, rabotaya  nad 701-j mashinoj, ya vpervye poznal produktivnuyu svobodu
ot formal'nostej, prisushchuyu  predrassvetnym  chasam,  kogda vse  nachal'niki iz
mashinnogo  zala krepko spyat po domam, a operatory ne raspolozheny borot'sya za
soblyudenie  pravil.  Smenilos'  tri  pokoleniya  mashin,  polnost'yu izmenilis'
tehnologii,  poyavilis'  operacionnye sistemy,  no etot luchshij  sposob raboty
ostalsya prezhnim.  On prodolzhaet zhit', poskol'ku naibolee  effektiven. Prishla
pora priznat' ego produktivnost' i shire primenyat'.
     Rabochie mashiny i sluzhby dannyh
     |mulyatory.  Esli  celevoj  komp'yuter  novyj,   to  dlya  nego  neobhodim
logicheskij  emulyator.  |to daet apparat  dlya  otladki zadolgo do  togo,  kak
celevaya  mashina budet  v  nalichii.  CHto  stol' zhe vazhno,  dazhe togda,  kogda
stanovitsya dostupnoj celevaya mashina, imeetsya dostup k nadezhnomu sredstvu dlya
otladki.
     Nadezhnoe -  ne to zhe samoe, chto tochnoe. |mulyator neizbezhno v kakom-libo
otnoshenii  budet otstupat' ot vernoj  i tochnoj realizacii arhitektury  novoj
mashiny. No eto budet  odna i ta zhe  realizaciya i segodnya, i zavtra,  chego ne
skazhesh' o novoj apparatnoj chasti.
     V  nashe vremya  my privykli  k  tomu,  chto apparatnaya  chast'  komp'yutera
bol'shuyu chast' vremeni rabotaet bez sboev. Esli tol'ko razrabotchik prikladnoj
programmy  ne  zamechaet,  chto  sistema  neodinakovo  vedet  sebya pri  raznyh
identichnyh progonah  programmy, emu pravil'nee vsego poiskat' oshibki v svoem
kode, a ne v tehnike.
     |tot opyt,  odnako, sosluzhil plohuyu  sluzhbu  pri programmirovanii novoj
mashiny.   Laboratornye  razrabotki,  predvaritel'nye  ili   rannie   vypuski
komp'yuterov ne rabotayut dolzhnym obrazom, ne  rabotayut nadezhno i  ne ostayutsya
neizmennymi den' oto dnya. Po  mere obnaruzheniya oshibok  tehnicheskie izmeneniya
proizvodyatsya  vo  vseh  ekzemplyarah  mashiny,  vklyuchaya  ispol'zuemyj  gruppoj
programmistov. Takaya  neustojchivost' osnovaniya dostatochno  nepriyatna. Otkazy
apparatury, obychno skachkoobraznye, eshche huzhe. I huzhe  vsego neopredelennost',
lishayushchaya stimula staratel'no kopat'sya  v svoem  kode v poiskah  oshibki  - ee
mozhet tam vovse ne byt'. Poetomu nadezhnyj emulyator na zreloj mashine ostaetsya
poleznym znachitel'no dol'she, chem mozhno bylo predpolozhit'.
     Mashiny  dlya  kompilyatora i assemblera. Po  tem  zhe  prichinam  trebuyutsya
kompilyatory  i assemblery, rabotayushchie na nadezhnyh  mashinah, no kompiliruyushchie
ob®ektnyj  kod dlya celevoj  sistemy.  Zatem  mozhno  nachat'  ego  otladku  na
emulyatore.
     Pri  programmirovanii  na  yazykah vysokogo  urovnya  znachitel'nuyu  chast'
otladki  mozhno  proizvesti  pri  kompilyacii  dlya  vspomogatel'noj  mashiny  i
testirovanii rezul'tiruyushchej programmy,  prezhde chem  otlazhivat' programmu dlya
celevoj   mashiny.  |tim  dostigaetsya   proizvoditel'nost'  neposredstvennogo
ispolneniya, a ne emulyacii, v sochetanii s nadezhnost'yu stabil'noj mashiny.
     Biblioteki  programm  i  uchet.  Ochen'  uspeshnym  i  vazhnym  primeneniem
vspomogatel'noj  mashiny  v  programme  razrabotki   OS/360  byla   podderzhka
bibliotek programm. Sistema, razrabotannaya pod rukovodstvom U. R. Krouli (W.
R. Crowley), sostoyala iz dvuh soedinennyh vmeste mashin 7010 i obshchej diskovoj
bazoj  dannyh.  Na  7010  podderzhivalsya  takzhe assembler  dlya S/360. V  etoj
biblioteke  hranilsya  ves'  protestirovannyj  ili  nahodyashchijsya   v  processe
testirovaniya kod, kak ishodnyj, tak  i assemblirovannye  zagruzochnye moduli.
Na praktike  biblioteka byla razbita na  podbiblioteki s razlichnymi  pravami
dostupa.
     Prezhde  vsego,  u  kazhdoj  gruppy  ili  programmista  byla  oblast' dlya
hraneniya ekzemplyarov  programm,  kontrol'nyh primerov i  okruzheniya,  kotoroe
trebovalos' dlya testirovaniya komponentov.  Na etoj ploshchadke dlya  igr ne bylo
nikakih ogranichenij na dejstviya s sobstvennymi programmami.
     Kogda komponent  programmista  byl  gotov k vklyucheniyu  v bolee  krupnuyu
chast',  ego  ekzemplyar  peredavalsya  menedzheru etoj  bolee krupnoj  sistemy,
kotoryj  pomeshchal  ego  v podbiblioteku sistemnoj integracii. Teper' avtor ne
mog  ego  izmenit'   bez  razresheniya  menedzhera  integracii.  Kogda  sistema
sobiralas' voedino, etot menedzher provodil vse vidy sistemnogo testirovaniya,
vyyavlyaya oshibki i poluchaya ispravleniya.
     CHerez nekotoroe vremya sistemnaya versiya byla  gotova  dlya bolee shirokogo
ispol'zovaniya. Togda ona  peremeshchalas' v  podbiblioteku tekushchej versii. |tot
ekzemplyar byl svyashchennym, i  dostup  k nemu razreshalsya tol'ko dlya ispravleniya
razrushitel'nyh  oshibok.  Ego  mozhno  bylo  ispol'zovat' dlya integrirovaniya i
testirovaniya vseh  novyh versij modulej. Programmnyj katalog  na mashine 7010
otslezhival  vse versii  kazhdogo  modulya,  ego sostoyanie,  mestonahozhdenie  i
izmeneniya.
     Zdes' vazhny dva obstoyatel'stva. Pervoe -  eto kontrol', oznachayushchij, chto
ekzemplyary   programm   prinadlezhat   menedzheram,   i   tol'ko   oni   mogut
sankcionirovat' ih izmenenie. Vtoroe - formal'noe razdelenie i peremeshchenie s
ploshchadki dlya igr k integracii i vypusku novoj versii.
     Po  moemu mneniyu, eto bylo odnim iz luchshih reshenij v programme  OS/360.
|ta chast' tehnologii  upravleniya  byla nezavisimo razrabotana dlya neskol'kih
krupnyh programmnyh proektov, v  tom  chisle v  Bell Labs, ICL i Kembridzhskom
universitete.2 Ona primenima kak k programmam, tak  i k dokumentacii.  |to -
neocenimaya tehnologiya.
     Programmnye  instrumenty. Po  mere  poyavleniya  novyh tehnologij otladki
starye teryayut znachenie, no ne ischezayut. Po-prezhnemu neobhodimy dampy pamyati,
redaktory ishodnogo teksta, dampy mgnovennogo sostoyaniya, dazhe trassirovki.
     Analogichnym obrazom, trebuetsya polnyj nabor  utilit dlya zagruzki  kolod
perfokart na  diski,  kopirovaniya  magnitnyh  lent, pechati fajlov, izmeneniya
katalogov.  Esli  instrumental'shchika proekta  naznachit' na dostatochno  rannej
stadii, to  vse eto mozhet  byt'  sdelano srazu  i  nahodit'sya v gotovnosti k
momentu nadobnosti.
     Sistema dokumentacii.  Iz  vseh instrumentov  bol'she vsego  truda mozhet
sberech' komp'yuterizirovannaya sistema  redaktirovaniya  teksta, dejstvuyushchaya na
nadezhnoj  mashine. Nasha  sistema,  razrabotannaya  Dzh.  U.  Franklinom  (J. W.
Franklin),  byla  ochen'  udobna.  YA  dumayu,  bez nee  rukovodstva  po OS/360
poyavilis'  by  znachitel'no pozdnee  i okazalis'  by  bolee zaputannymi. Est'
lyudi, kotorye stanut utverzhdat', chto dvuhmetrovaya polka rukovodstv po OS/360
yavlyaetsya sledstviem  nederzhaniya  rechi,  i sama  ee ob®emistost' yavlyaet soboj
novyj tip nepostizhimosti. I dolya pravdy v etom est'.
     No u menya est' dva vozrazheniya. Vo-pervyh, hotya dokumentaciya po OS/360 i
oshelomlyaet razmerami, plan ee izucheniya  tshchatel'no izlozhen. Esli ispol'zovat'
ego izbiratel'no,  to chashche vsego mozhno ne obrashchat' vnimaniya na bol'shuyu chast'
vsej  massy. Dokumentaciyu po OS/360  nuzhno rassmatrivat' kak  biblioteku ili
enciklopediyu, a ne material dlya obyazatel'nogo chteniya.
     Vo-vtoryh, eto gorazdo luchshe, chem krajnyaya nedostatochnost' dokumentacii,
harakternaya dlya bol'shinstva sistem programmirovaniya. YA ohotno soglashus', tem
ne menee,  chto v nekotoryh mestah tekst  mozhno bylo znachitel'no uluchshit',  i
rezul'tatom  luchshego  opisaniya  stal  by   men'shij  ob®em.  Nekotorye  chasti
(naprimer, "Koncepcii i sredstva") sejchas ochen' horosho napisany.
     |mulyator proizvoditel'nosti. Luchshe ego imet'. Razrabotajte ego "snaruzhi
vnutr'",   kak   opisano   v   sleduyushchej   glave.   Ispol'zujte   odinakovoe
proektirovanie  sverhu  vniz  dlya  emulyatora  proizvoditel'nosti,  emulyatora
logiki  i  samogo  produkta.  Nachnite  rabotu   s  nim   kak  mozhno  ran'she.
Prislushajtes' k tomu, chto on vam skazhet.
     YAzyki vysokogo urovnya i interaktivnoe programmirovanie
     Segodnya dva  vazhnejshih instrumenta  sistemnogo programmirovaniya - eto
te, kotorye ne ispol'zovalis' pri razrabotke OS/360 pochti desyatiletie nazad.
Oni do  sih por ne ochen' shiroko  ispol'zuyutsya, no vse ukazyvaet na ih moshch' i
primenimost'.   |to:  a)   yazyki  vysokogo   urovnya   i   b)   interaktivnoe
programmirovanie.  YA  ubezhden,  chto  tol'ko  inertnost'  i len' prepyatstvuet
povsemestnomu  prinyatiyu  etih instrumentov, tehnicheskie trudnosti  bolee  ne
yavlyayutsya izvineniyami.
     YAzyki vysokogo  urovnya.  Glavnye  osnovaniya  dlya  ispol'zovaniya  yazykov
vysokogo   urovnya   -    eto   proizvoditel'nost'   i   skorost'    otladki.
Proizvoditel'nost' my obsuzhdali ran'she (glava 8).  Imeyushchiesya dannye,  hotya i
nemnogochislennye, ukazyvayut  na  mnogokratnyj  rost, a ne  na uvelichenie  na
neskol'ko procentov.
     Uluchshenie otladki  proishodit  blagodarya  tomu, chto  oshibok  stanovitsya
men'she, a nahodit' ih legche. Ih men'she,  poskol'ku ustranyaetsya celyj uroven'
obrazovaniya oshibok, uroven',  na  kotorom delayutsya ne tol'ko sintaksicheskie,
no i semanticheskie oshibki,  takie kak nepravil'noe ispol'zovanie  registrov.
Ih legche nahodit', poskol'ku v  etom pomogaet diagnostika kompilyatora i, chto
eshche vazhnee, ochen' legko vstavlyat' poluchenie otladochnyh momental'nyh snimkov.
     Menya  eti  vozmozhnosti  proizvoditel'nosti i  otladki  oshelomlyayut.  Mne
trudno  predstavit'   sebe  sistemu  programmirovaniya,  kotoruyu  ya  stal  by
sozdavat' na yazyke assemblera.
     Nu, a  kak s  klassicheskimi vozrazheniyami  protiv etogo instrumenta?  Ih
tri:  ya  ne mogu  sdelat'  to,  chto hochu; rezul'tiruyushchaya  programma  slishkom
velika; rezul'tiruyushchaya programma slishkom medlenna.
     CHto kasaetsya vozmozhnostej, vozrazhenie, ya dumayu, bol'she ne sostoyatel'no.
Vse  svidetel'stvuet  v pol'zu  togo,  chto mozhno  delat'  to,  chto  hochetsya,
potrudivshis' najti sposob, no inogda dlya etogo prihoditsya izlovchit'sya.3, 4
     CHto  kasaetsya  pamyati,  to  novye  optimiziruyushchie  kompilyatory nachinayut
pokazyvat'  ves'ma  udovletvoritel'nye  rezul'taty, i ih  usovershenstvovanie
prodolzhaetsya.
     CHto kasaetsya  skorosti,  to optimiziruyushchie kompilyatory inogda porozhdayut
kod, kotoryj  zachastuyu  vypolnyaetsya bystree, chem napisannyj  vruchnuyu.  Bolee
togo,  problemy skorosti mozhno obychno reshit', zameniv  ot  1 do 5  procentov
skompilirovannoj  programmy  kodom,  napisannym  vruchnuyu,  posle  ee  polnoj
otladki.5
     Kakoj  yazyk  vysokogo   urovnya  sleduet   ispol'zovat'  dlya  sistemnogo
programmirovaniya? Segodnya  edinstvennyj  dostojnyj kandidat  - PL/I.6 U nego
ochen'  polnyj  nabor  operatorov;  on  sootvetstvuet  okruzheniyu operacionnoj
sredy;   imeetsya   celyj  ryad  kompilyatorov   s  raznymi   osobennostyami   -
interaktivnyh,  bystryh,  s  uluchshennoj  diagnostikoj,  s  vysokoj  stepen'yu
optimizacii. Lichno ya  bystree razrabatyvayu algoritmy s pomoshch'yu APL;  zatem ya
perevozhu ih v PL/I dlya sootvetstviya sistemnomu okruzheniyu.
     Interaktivnoe programmirovanie. Odnim iz opravdanij proekta MTI MULTICS
byla  ego pol'za dlya  sozdaniya sistem programmirovaniya. MULTICS (i vsled  za
tem TSS IBM) konceptual'no otlichaetsya ot  drugih  interaktivnyh komp'yuternyh
sistem  imenno   v  teh   otnosheniyah,  kotorye  neobhodimy   dlya  sistemnogo
programmirovaniya: mnogourovnevaya sistema razdeleniya dostupa i  zashchity dannyh
i  programm, intensivnoe upravlenie bibliotekami i  sredstva dlya  sovmestnoj
raboty  pol'zovatelej  terminalov.  YA  ubezhden,  chto  vo mnogih  prilozheniyah
interaktivnye  sistemy nikogda ne  zamenyat  sistemy  s  obrabotkoj  paketnyh
zadanij. No ya dumayu, chto sozdateli MULTICS priveli samye ubeditel'nye dovody
v ee pol'zu imenno v primenenii k sistemnomu programmirovaniyu.
     Poka  est'  ne  mnogo svidetel'stv  dejstvitel'noj plodotvornosti  etih
ochevidno moshchnyh instrumentov. Sushchestvuet shiroko  rasprostranennoe  priznanie
togo,  chto   otladka   yavlyaetsya   trudnoj  i  medlennoj   chast'yu  sistemnogo
programmirovaniya,  i  medlennaya oborachivaemost' - proklyatie otladki. Poetomu
logika interaktivnogo programmirovaniya kazhetsya neumolimoj.7

     

     Ris.  12.2 Sravnitel'naya proizvoditel'nost'  pri paketnom i  dialogovom
Programmirovanii
     Pomimo togo,  est' horoshie otzyvy teh, kto  razrabotal  takim  sposobom
nebol'shie  sistemy  ili  chasti sistem.  Edinstvennye  dostupnye  mne  dannye
otnositel'no vliyaniya  na programmirovanie bol'shih  sistem  ishodyat  ot Dzhona
Harra iz Bell Labs. Oni predstavleny  na risunke 12.2. |ti cifry  ohvatyvayut
napisanie, assemblirovanie i otladku programm. Pervaya  programma yavlyaetsya, v
osnovnom,  upravlyayushchej.  Ostal'nye tri -  yazykovye translyatory, redaktory  i
t.p. Dannye Harra pozvolyayut predpolozhit', chto sredstva interaktivnoj raboty,
po krajnej mere, udvaivayut proizvoditel'nosti sistemnogo programmirovaniya.8
     |ffektivnoe  ispol'zovanie  bol'shinstva  interaktivnyh sredstv trebuet,
chtoby rabota proizvodilas'  na  yazyke vysokogo urovnya,  poskol'ku teletajp i
pishushchuyu  mashinku  nel'zya  ispol'zovat'   dlya  polucheniya  dampa   pamyati.   S
ispol'zovaniem yazyka  vysokogo urovnya  legko redaktirovat'  ishodnyj tekst i
delat'  otdel'nye  raspechatki.  Vmeste  oni  dejstvitel'no  sostavlyayut  paru
ottochennyh instrumentov.


    Glava 13. Celoe i chasti

     YA duhov vyzyvat' mogu iz bezdny.
     I ya mogu, i kazhdyj mozhet,
     Vopros lish', yavyatsya l' na zov oni?
     SHEKSPIR, KOROLX GENRIH IV
     Sredi sovremennyh kudesnikov, kak i  vstar', vstrechayutsya hvastuny: "YA
mogu  pisat' programmy, kotorye upravlyayut vozdushnym dvizheniem, perehvatyvayut
ballisticheskie  rakety,  delayut  perevody  po  bankovskim  schetam, upravlyayut
proizvodstvennymi liniyami". Na chto est' otvet: "I ya mogu, i kazhdyj mozhet, no
budet li rabotat' to, chto ty napishesh'?"
     Kak napisat'  programmu, kotoraya  budet  rabotat'?  Kak  protestirovat'
programmu? I kak  ob®edinit' nabor  protestirovannyh programm-komponentov  v
protestirovannuyu  i  nadezhnuyu  sistemu?  Neskol'ko   raz  my  uzhe   kasalis'
sootvetstvuyushchih priemov, davajte teper' rassmotrim ih bolee sistematicheski.
     Proektirovanie bez oshibok
     Zashchita  opredelenij  ot  oshibok. Samye pagubnye i neulovimye  sistemnye
oshibki   voznikayut  iz-za   nesootvetstviya   dopushchenij,  sdelannyh  avtorami
razlichnyh komponentov. Podhod k  konceptual'noj celostnosti, izlozhennyh vyshe
v glavah  4, 5  i  6, neposredstvenno obrashchaetsya  k  etim problemam.  Kratko
govorya,  konceptual'naya  celostnost'   produkta   ne   tol'ko  uproshchaet  ego
ispol'zovanie, no takzhe  oblegchaet razrabotku  i  delaet  menee podverzhennym
oshibkam.
     Takuyu  zhe  rol'  vypolnyaet  detalizirovannaya   trudoemkaya   rabota   po
razrabotke arhitektury,  podrazumevaemaya  etim  podhodom. V.  A. Vysockij iz
proekta  Safeguard, vypolnyavshegosya v  Bell  Telephone Laboratories,  govorit
tak: "Reshayushchaya zadacha - dat' opredelenie dlya produkta. Ochen' mnogie  neudachi
svyazany imenno s  temi aspektami, kotorye ne byli  vpolne specificirovany".1
Tshchatel'noe  opredelenie  funkcij,  tshchatel'naya  specifikaciya  i  staratel'noe
izbeganie  vseh ukrashatel'stv funkcij i poletov tehnicheskoj  mysli - vse eto
snizhaet kolichestvo sistemnyh oshibok, kotorye budut obnaruzheny.
     Proverka specifikacii. Zadolgo  do napisaniya vsyakogo koda  specifikaciya
dolzhna  byt'  peredana   storonnej  gruppe   testirovaniya  dlya   tshchatel'nogo
rassmotreniya  polnoty  i  yasnosti. Kak schitaet Vysockij,  sami  razrabotchiki
sdelat'  eto ne mogut: "Oni ne  mogut priznat'sya,  chto  ne ponimayut  ee, oni
budut schastlivo prokladyvat' svoj put' cherez propushchennye i temnye mesta".
     Nishodyashchee proektirovanie. V ochen' chetkoj stat'e 1971 goda Niklaus Virt
formalizoval   proceduru   razrabotki,   godami   ispol'zovavshuyusya   luchshimi
programmistami.2 Bolee togo, ego zamechaniya, sdelannye v otnoshenii razrabotki
programm,  polnost'yu  primenimy  k  razrabotke  slozhnyh  programmnyh sistem.
Voploshcheniem  etih   zamechanij   yavlyaetsya  razdelenie  sozdaniya   sistem   na
proektirovanie arhitektury,  razrabotku i realizaciyu. Bolee  togo, kazhdaya iz
zadach proektirovaniya arhitektury, razrabotki i  realizacii luchshe vsego mozhet
byt' reshena nishodyashchimi metodami.
     Vkratce,  metod  Virta  opredelyaet  razrabotku  kak  posledovatel'nost'
utochnyayushchih shagov.  Nabrasyvaetsya primernoe  opisanie zadachi  i  grubyj metod
resheniya,   pozvolyayushchij  poluchit'   osnovnoj   rezul'tat.  Zatem  opredelenie
izuchaetsya  bolee  pristal'no,  chtoby  uvidet',  v  chem  otlichie  poluchennogo
rezul'tata  ot  trebuemogo, i  krupnye  etapy  resheniya razbivayutsya  na bolee
melkie.  Kazhdoe  utochnenie   v  opredelenii  zadachi   stanovitsya  utochneniem
algoritma resheniya i mozhet soprovozhdat'sya utochneniem predstavleniya dannyh.
     V  etom  processe  vyyavlyayutsya moduli  resheniya  ili  dannyh,  dal'nejshee
utochnenie  kotoryh  mozhet  byt'  prodolzheno  nezavisimo  ot osnovnoj raboty.
Stepen' takoj modul'nosti opredelyaet gibkost' i izmenyaemost' programmy.
     Virt schitaet neobhodimym ispol'zovanie na kazhdom shage notacii kak mozhno
bolee  vysokogo urovnya,  chtoby  vydelit' ponyatiya i skryt'  detali,  poka  ne
stanet neobhodimym dal'nejshee utochnenie.
     Pravil'no osushchestvlyaemoe nishodyashchee  proektirovanie  pozvolyaet izbegat'
oshibok   po  neskol'kim   prichinam.  Vo-pervyh,  prozrachnost'  struktury   i
predstavleniya  oblegchaet  tochnuyu  formulirovku  trebovanij k  modulyam  i  ih
funkcij.  Vo-vtoryh, raschlenenie i  nezavisimost' modulej pomogayut  izbezhat'
sistemnyh oshibok. V- tret'ih, proekt mozhno testirovat' na  kazhdom utochnyayushchem
shage,   poetomu  testirovanie   mono   nachat'  ran'she   i  na   kazhdom  shage
sosredotochit'sya na podhodyashchem urovne detalizacii.
     Process  poshagovogo utochneniya ne oznachaet,  chto v sluchae stolknoveniya s
kakoj- nibud' neozhidanno zatrudnitel'noj detal'yu ne  prihoditsya vozvrashchat'sya
nazad, otbrasyvat' samyj verhnij uroven' i nachinat' vse snachala. Na praktike
eto chasto sluchaetsya. No stanovitsya  znachitel'no legche tochno uvidet', kogda i
pochemu  nuzhno otbrosit' ves' proekt i nachat'  snachala. Mnogie slabye sistemy
poyavlyayutsya  v rezul'tate popytok  sohranit'  skvernyj  pervonachal'nyj proekt
putem  raznogo   roda   kosmeticheskih  zaplatok.  Nishodyashchee  proektirovanie
umen'shaet takoj soblazn.  YA ubezhden, chto nishodyashchee proektirovanie  yavlyaetsya
vazhnejshej novoj formalizaciej programmirovaniya za desyatiletie.
     Strukturnoe programmirovanie. Drugoj  vazhnyj  krug idej dlya razrabotki,
sokrashchayushchih  chislo  oshibok v  programme, ishodit to  Dejkstry (Dijkstra)3  i
postroen na teoreticheskoj strukture Bema (Boehm) i Dzhakopini (Jacopini).4
     V svoej  osnove podhod zaklyuchaetsya v razrabotke  programm,  upravlyayushchie
struktury kotoryh sostoyat tol'ko iz ciklov, opredelyaemyh takimi operatorami,
kak  DO  WHILE  i  gruppami  uslovno  vypolnyaemyh  operatorov,  ogranichennyh
skobkami  s  ispol'zovaniem  operatorov  usloviya  IF...THEN...ELSE.  Bem   i
Dzhakopini  pokazyvayut teoreticheskuyu dostatochnost'  takih struktur.  Dejkstra
dokazyvaet, chto al'ternativnoe neogranichennoe primenenie vetvlenie s pomoshch'yu
GO TO obrazuet struktury, raspolagayushchie k poyavleniyu logicheskih oshibok.
     V osnove, nesomnenno, lezhat zdravye mysli. Pri obsuzhdenii sdelano mnogo
kriticheskih  zamechanij   -  v  chastnosti,   bol'shoe   udobstvo  predstavlyayut
dopolnitel'nye  upravlyayushchie  struktury, takie kak n-variantnyj  perehod (tak
nazyvaemyj  operator   CASE)  dlya  razlicheniya  sredi  neskol'kih  sluchaev  i
avarijnyj  vyhod (GO  TO  ABNORMAL END).  Krome togo, nekotorye dogmaticheski
izbegayut vseh GO TO , chto predstavlyaetsya chrezmernym.
     Vazhnoj  i  sushchestvennoj  dlya sozdaniya  programm,  ne soderzhashchih oshibok,
yavlyaetsya  neobhodimost'  rassmatrivat'  upravlyayushchie  struktury  sistemy  kak
upravlyayushchie struktury, a ne kak  otdel'nye operatory perehoda.  Takoj  obraz
mysli yavlyaetsya bol'shim shagom vpered.
     Otladka komponentov
     Za poslednie dvadcat' let procedury  otladki programm  proshli  bol'shoj
krug  i v  nekotoryh  otnosheniyah vernulis'  k  nachal'noj  tochke. Cikl proshel
chetyre etapa i lyubopytno prosledit' ih, otmetiv motivaciyu perehoda.
     Otladka  v  aktivnom rezhime. U  pervyh  mashin bylo  sravnitel'no slaboe
oborudovanie  vvoda-vyvoda, obuslovlivavshee bol'shie zaderzhki.  Obychno mashina
ispol'zovala  dlya  chteniya  i  zapisi  bumazhnye  i  magnitnye  lenty,  a  dlya
podgotovki  lent i  pechati  ispol'zovalis'  avtonomnye sredstva. Iz-za etogo
vvod-vyvod  na  lentu  byl  nevynosimo  neudoben  dlya  otladki,  i  dlya  nee
ispol'zovalas'  konsol'.  Poetomu  otladka  organizovyvalas'  takim obrazom,
chtoby obespechit' za seans raboty s mashinoj vozmozhno bol'shee chislo proverok.
     Programmist  tshchatel'no razrabatyval  svoi procedury  otladki,  planiruya
mesta ostanovki,  adresa  pamyati  dlya prosmotra,  ih vozmozhnoe  soderzhimoe i
dal'nejshie   dejstviya   v   zavisimosti   ot   soderzhimogo.   |to   dotoshnoe
programmirovanie  samogo  sebya  v kachestve  otladchika  vpolne  moglo  zanyat'
polovinu vremeni napisaniya otlazhivaemoj programmy.
     Glavnym grehom bylo smelo nazhat' knopku START, ne razbiv predvaritel'no
programmu na otlazhivaemye sekcii s zaplanirovannymi ostanovkami.
     Dampy pamyati.  Otladka  v aktivnom rezhime  byla  ochen'  effektivnoj. Za
dvuhchasovuyu otladku mozhno bylo zapustit' programmu raz desyat'. No komp'yutery
byli malochislenny i ochen' dorogi, i mysl' o takoj naprasnoj trate  mashinnogo
vremeni uzhasala.
     Poetomu,  kogda poyavilis'  skorostnye printery, podklyuchaemye v aktivnom
rezhime,   tehnologiya  izmenilas'.   Programma  zapuskalas'  i   rabotala  do
vozniknoveniya oshibki, posle chego raspechatyvalsya damp pamyati. Togda nachinalsya
kropotlivyj trud za stolom po izucheniyu  soderzhimogo kazhdogo  adresa. Vremeni
uhodilo primerno stol'ko  zhe,  skol'ko i  pri otladke na mashine, no eto bylo
uzhe posle kontrol'nogo progona, i rabota sostoyala v rasshifrovke dannyh, a ne
v  planirovanii,  kak  prezhde.  Dlya kazhdogo otdel'nogo pol'zovatelya  otladka
zanimala znachitel'no  bol'shij  srok,  poskol'ku testovye zapuski zaviseli ot
oborachivaemosti  paketnoj   obrabotki.   Odnako  procedura   v   celom  byla
prednaznachena dlya sokrashcheniya vremeni ispol'zovaniya komp'yutera i obsluzhivaniya
vozmozhno bol'shego chisla programmistov.
     Snimki momental'nogo sostoyaniya. Mashiny,  dlya kotoryh  byli  razrabotany
dampy pamyati, imeli pamyat'  razmerom 2000-4000  slov, ili 8-16 Kbajt. Odnako
razmer pamyati ros  ogromnymi tempami, i delat' damp pamyati stalo nereal'nym.
Poetomu  razrabotali  metody  vyborochnogo dampa,  vyborochnoj  trassirovki  i
vstavki v programmy komand dlya momental'nyh snimkov. Vershinoj razvitiya etogo
napravleniya  stal  TESTRAN  v  OS/360,  pozvolyavshij  vstavlyat'  v  programmu
momental'nye snimki bez povtornoj sborki i kompilyacii.
     Interaktivnaya otladka. V  1959 godu Kodd (Codd) s  kollegami5 i Strejchi
(Strachey)6  soobshchili  o  rabote,  cel'yu  kotoroj   byla  otladka  v  rezhime
razdeleniya    vremeni,    pozvolyayushchaya   odnovremenno   dostich'    mgnovennoj
oborachivaemosti otladki v aktivnom rezhime i effektivno ispol'zovat' mashinnoe
vremya,  kak pri  paketnoj obrabotke  zadanij.  Komp'yuter dolzhen byl  imet' v
pamyati neskol'ko programm, gotovyh k zapusku. Terminal,  upravlyaemyj  tol'ko
programmoj,  dolzhen  byl  byt'  svyazan s  kazhdoj  iz  otlazhivaemyh programm.
Otladka  dolzhna byla prohodit' pod  upravleniem programmy-supervizora. Kogda
programmist  za  terminalom  ostanavlival svoyu programmu, chtoby  izuchit'  ee
vypolnenie  ili  vnesti  izmeneniya,  supervizor  zapuskal  druguyu programmu,
zanimaya takim obrazom mashinu.
     Mul'tiprogrammnaya sistema Kodda  byla razrabotana, no akcent byl sdelan
na uvelichenie proizvoditel'nosti blagodarya effektivnomu ispol'zovaniyu vvoda-
vyvoda, i  interaktivnaya otladka  ne  byla  osushchestvlena. Idei Strejchi  byli
uluchsheny   i  v  1963   godu   voploshcheny   Korbato   s  kollegami  v  MTI  v
eksperimental'noj  sisteme  7090. |to  razrabotke  privela  k MULTICS, TSS i
drugim segodnyashnim sistemam razdeleniya vremeni.
     Glavnymi oshchushchaemymi pol'zovatelem  razlichiyami mezhdu otladkoj v aktivnom
rezhime, kak  ona osushchestvlyalas' ranee, i segodnyashnej interaktivnoj  otladkoj
yavlyayutsya   vozmozhnosti,  poluchennye  v  rezul'tate   prisutstviya  programmy-
supervizora i svyazannyh s nej interpretatorov yazykov programmirovaniya. Mozhno
programmirovat' i proizvodit' otladku na yazykah vysokogo urovnya. |ffektivnye
sredstva  redaktirovaniya  pozvolyayut legko  delat' izmeneniya  i  momental'nye
snimki.
     Vozvrat  k mgnovennoj oborachivaemosti otladki v aktivnom rezhime poka ne
privel  k vozvrashcheniyu predvaritel'nogo planirovaniya  otladochnyh  seansov.  V
sushchnosti,  takoe  predvaritel'noe  planirovanie  ne  stol'  neobhodimo,  kak
ran'she, poskol'ku mashinnoe vremya teper' ne  tratitsya  vpustuyu, poka  chelovek
sidit i dumaet.
     Tem   ne  menee  interesnye  eksperimental'nye   dannye   Golda  (Gold)
pokazyvayut,  chto vo vremya  pervogo dialoga kazhdogo seansa dostigaetsya  vtroe
bol'shij progress v interaktivnoj otladke, chem pri posleduyushchih dialogah.8 |to
ubeditel'no govorit o tom, chto iz-za otsutstviya planirovaniya my ne polnost'yu
realizuem potencial dialogovoj raboty. Pora stryahnut' pyl' so staryh metodov
raboty v interaktivnom rezhime.
     YA  schitayu,  chto  dlya  pravil'nogo  ispol'zovaniya  horoshej  terminal'noj
sistemy na kazhdye dva chasa raboty za terminalom dolzhno prihodit'sya dva  chasa
raboty za stolom. Polovina etogo  vremeni uhodit na podchistki posle  pervogo
seansa:  vnesenie izmenenij  v  zhurnal otladki, podshivku  novyh  listingov v
sistemnyj zhurnal,  ob®yasnenie  neponyatnyh yavlenij.  Vtoraya  chast'  uhodit na
podgotovku:   planirovanie  izmenenij   i  usovershenstvovanij  i  razrabotku
detal'nyh  testov  dlya ocherednogo  seansa. Bez  takogo  planirovaniya  trudno
podderzhivat' produktivnost' na  protyazhenii vseh  dvuh  chasov.  Bez podchistki
posle  seansa trudno  sdelat'  posledovatel'nost'  seansov  sistematichnoj  i
prodvigayushchej rabotu vpered.
     Kontrol'nye  primery.  CHto  kasaetsya  razrabotki  fakticheskih  procedur
otladki  i  kontrol'nyh  primerov,  osobenno  udachnoe  izlozhenie  predlagaet
Gryunberger (Gruenberger),9 est' i bolee korotkie opisaniya v drugih izvestnyh
uchebnikah.10, 11
     Sistemnaya otladka
     Neozhidanno   trudnym   etapom  sozdaniya   sistemy   programmirovaniya
okazyvaetsya testirovanie sistemy. YA uzhe obsuzhdal  nekotorye prichiny kak  ego
trudnosti,  tak i  nepredskazuemosti.  Mozhno  ne somnevat'sya  v  dvuh veshchah:
sistemnaya otladka zajmet bol'she vremeni, chem predpolagaetsya, a ee  slozhnost'
opravdyvaet  doskonal'no sistematichnyj i planovyj  podhod.  Rassmotrim,  chto
vklyuchaet v sebya takoj podhod.12
     Ispol'zujte  otlazhennye  komponenty.  Obychnyj  zdravyj  smysl, esli  ne
obychnaya  praktika, podskazyvayut, chto sistemnuyu otladku nuzhno nachinat', kogda
rabotaet kazhdaya sostavlyayushchaya chast'.
     Dalee  obshcheprinyataya  praktika sleduet  dvumya  putyami.  Pervyj podhod  -
"svinti i  poprobuj".  Vidimo,  on osnovyvaetsya  na tom, chto krome oshibok  v
komponentah najdutsya  i oshibki  v sisteme (t.e. v  interfejsah). CHem  skoree
chasti  budut soedineny vmeste, tem skoree  vsplyvut  sistemnye oshibki. Legko
takzhe predstavit',  chto, ispol'zuya komponenty  dlya testirovaniya drug  druga,
mozhno  v znachitel'noj mere izbezhat'  sozdaniya  okruzheniya dlya testirovaniya. I
to,  i drugoe, ochevidno, yavlyaetsya pravdoj, no,  kak pokazyvaet opyt, ne vsej
pravdoj: znachitel'no bol'she vremeni sberegaetsya  pri testirovanii sistemy  s
ispol'zovaniem chistyh otlazhennyh  komponentov,  chem ego tratitsya na sozdanie
okruzheniya i doskonal'noj proverki komponentov.
     Neskol'ko  bolee  tonkim yavlyaetsya podhod "dokumentirovannoj oshibki". On
oznachaet,  chto  komponent gotov k ispol'zovaniyu v sistemnoj proverke,  kogda
vse   ego   oshibki   najdeny,  no   neobyazatel'no  uzhe   ispravleny.  Togda,
teoreticheski,  pri  sistemnom  testirovanii  vozmozhnye  effekty etih  oshibok
izvestny  i  mogut  byt'  proignorirovany,  a sosredotochit'sya mozhno na novyh
yavleniyah.
     Vse eto oznachaet prinimat'  zhelaemoe  za dejstvitel'noe i proishodit ot
stremleniya ob®yasnit'  proval  grafika  rabot.  Nikto ne znaet vseh vozmozhnyh
posledstvij  izvestnyh   oshibok.  Esli   by  vse   bylo  prosto,   sistemnoe
testirovanie  ne   vyzyvalo  by   zatrudnenij.   Krome   togo,   ispravlenie
dokumentirovannyh  oshibok, nesomnenno,  privedet k vneseniyu novyh  oshibok, i
sistemnyj test okazhetsya isporchennym.
     Sozdajte bol'she okruzhenij. Pod "okruzheniem"  ya  ponimayu vse programmy i
dannye, sozdannye dlya celej otladki, no ne prednaznachennye dlya ispol'zovaniya
v  konechnom produkte.  V okruzhenii  net smysla imet'  i  poloviny togo koda,
kotoryj vhodit v produkt.
     Odin iz vidov okruzheniya  -  fiktivnyj komponent, kotoryj mozhet sostoyat'
tol'ko  iz  interfejsov i, vozmozhno, kakih-nibud'  iskusstvennyh dannyh  ili
nebol'shih kontrol'nyh primerov. Naprimer, v  sistemu mozhet vhodit' programma
sortirovki,  kotoraya  eshche  ne  zakonchena. Svyazannye  s nej  komponenty mozhno
testirovat' s pomoshch'yu fiktivnoj programmy, kotoraya prosto chitaet i proveryaet
format   vhodnyh  dannyh  i  vozvrashchaet  nabor  pravil'no  otformatirovannyh
bessmyslennyh, no uporyadochennyh dannyh.
     Drugoj  vid   -  mini-fajl.  Rasprostranennym  vidom  sistemnoj  oshibki
yavlyaetsya  nepravil'noe  vospriyatie  formatov lentochnyh  i  diskovyh  fajlov.
Poetomu stoit sozdat' neskol'ko malen'kih fajlov, soderzhashchih lish'  neskol'ko
tipovyh zapisej i vse opisaniya, ukazateli i t.p.
     Predel'nyj sluchaj mini-fajla  - fiktivnyj fajl,  kotoryj fakticheski  ne
sushchestvuet.  YAzyk upravlyayushchih zadanij  OS/360 imeet takoe  sredstvo,  i  ono
ochen' polezno dlya otladki komponentov.
     Drugoj vid okruzheniya - vspomogatel'nye programmy. Generatory dannyh dlya
testirovaniya, pechat' special'nogo analiza, analizatory  tablic  perekrestnyh
ssylok  -  vse  eto   primery  special'nyh  prisposoblenij,  kotorye   mozhet
potrebovat'sya sozdat'.13
     Kontrolirujte   izmeneniya.  ZHestkij  kontrol'   vo  vremya  testirovaniya
yavlyaetsya  vpechatlyayushchim  metodom  otladki apparatury, s uspehom  primenimym k
sistemam programmirovaniya.
     Prezhde vsego, kto-to  dolzhen byt' otvetstvennym. On, i tol'ko on dolzhen
razreshat' izmeneniya v komponentah i zamenu odnoj versii drugoj.
     Dalee,  kak  obsuzhdalos'  vyshe,  sistema  dolzhna  imet'  kontroliruemye
ekzemplyary: odin ekzemplyar s poslednimi versiyami,  nahodyashchijsya pod zamkom  i
ispol'zuemyj  dlya  testirovaniya  komponentov; odin  testiruemyj ekzemplyar  s
ustanovlennymi  ispravleniyami;  rabochie  ekzemplyary  kazhdogo  sotrudnika dlya
vneseniya ispravlenij i dopolnenij v svoi komponenty.
     V  tehnicheskih modelyah  System/360 sredi  obychnyh zheltyh provodov mozhno
bylo  inogda videt' fioletovye provoda. Pri obnaruzhenii defekta delalis' dve
veshchi. Bystro  pridumyvalos' ispravlenie i ustanavlivalos'  v  sisteme, chtoby
prodolzhit' otladku.  |to  izmenenie delalos'  fioletovymi provodami, tak chto
ono torchalo kak bel'mo na glazu. Izmenenie registrirovalos'  v  zhurnale. Tem
vremenem  gotovilsya  oficial'nyj dokument  o  vnesenii  ispravlenij, kotoryj
zapuskalsya  v  zhernova   avtomatizirovannogo  proektirovaniya.  V  itoge  eto
vylivalos' v izmenennye chertezhi i spiski provodov i  novuyu zadnyuyu panel',  v
kotoroj izmeneniya byli  sdelany na pechatnoj  plate  ili  zheltymi  provodami.
Teper'  fizicheskaya  model'  i dokumentaciya  sootvetstvovali  drug  drugu,  i
fioletovyj provod ischezal.
     Programmirovaniyu tozhe trebuetsya tehnologiya fioletovyh provodov, i ochen'
trebuetsya  zhestkij  kontrol' i  glubokoe uvazhenie  k  dokumentu,  kotoryj  v
konechnom  schete,   okazhetsya  produktom.  Neot®emlemymi  sostavlyayushchimi  takoj
tehnologii yavlyayutsya registraciya vseh izmenenij v zhurnale i  zametnoe otlichie
v  ishodnom   kode  mezhdu  zaplatkami  na   skoruyu  ruku  i  produmannymi  i
dokumentirovannymi ispravleniyami.
     Dobavlyajte  komponenty  po  odnomu. |tot  recept takzhe ocheviden, no  im
chasto  prenebregayut iz-za optimizma i leni.  CHtoby sledovat'  emu, trebuyutsya
fiktivnye  programmy i  raznoe  okruzhenie, a  eto  otnimaet vremya. I v konce
koncov, vsya eta rabota mozhet okazat'sya lishnej! Mozhet byt', oshibok i net!
     Net!  Protiv'tes' soblaznu!  |to to,  v chem  zaklyuchaetsya  sistematichnoe
testirovanie  sistemy.  Nuzhno   predpolagat',  chto  oshibok  budet  mnogo,  i
planirovat' uporyadochennuyu proceduru izbavleniya ot nih.
     Uchtite, chto nuzhno imet' polnyj  nabor kontrol'nyh primerov dlya proverki
chastichno  sobrannyh  sistem  posle  dobavleniya kazhdogo  komponenta.  Prezhnie
primery,  uspeshno   vypolnennye   na  poslednej   chastichnoj  sborke,   nuzhno
perezapustit' na novoj, chtoby proverit', ne uhudshilas' li sistema.
     Kvantujte  izmeneniya.  Po  mere  sozrevaniya  sistemy  vremya ot  vremeni
nachinayut  poyavlyat'sya razrabotchiki  komponentov,  prinosya svezhie versii svoih
izdelij  -   bolee   bystrye,  men'shie   po  razmeru,   bolee   polnye   ili
predpolozhitel'no  soderzhashchie  men'she  oshibok.  Zamena rabotayushchego komponenta
novoj versiej trebuet takoj zhe sistematicheskoj procedury testirovaniya, kak i
dobavlenie  novogo  komponenta,  hotya  i trebuet  men'she  vremeni, poskol'ku
obychno uzhe imeyutsya bolee polnye i effektivnye kontrol'nye primery.
     Kazhdaya komanda, sozdayushchaya novyj komponent,  ispol'zuet  novejshuyu versiyu
integrirovannoj sistemy  v kachestve  sredy  dlya  otladki  svoego komponenta.
Prodelannaya rabota budet otbroshena nazad, esli eta sreda izmenitsya. Konechno,
ona  dolzhna izmenit'sya.  No vnesenie izmenenij  nuzhno proizvodit'  kvantami.
Togda  u  kazhdogo pol'zovatelya  budut promezhutki produktivnoj  stabil'nosti,
preryvaemye  paketnym  obnovleniem  sredy   testirovaniya.  |to   okazyvaetsya
znachitel'no menee razrushitel'nym, chem postoyannye volneniya i drozh'.
     Leman i Beladi dayut svidetel'stva  v pol'zu togo,  chto kvant  izmenenij
dolzhen byt' libo  ochen' bol'shim i  redkim, libo  ochen' malen'kim i chastym.14
Poslednyaya  strategiya, soglasno ih modeli, bol'she  podverzhena neustojchivosti.
Moj opyt eto podtverzhdaet: ya nikogda ne risknu ispol'zovat' ee na praktike.
     Kvantovye   izmeneniya  horosho  vpisyvayutsya   v  tehnologiyu   fioletovyh
provodov.   Bystraya  zaplatka   derzhitsya  do  sleduyushchej   regulyarnoj  versii
komponenta,   kotoraya   dolzhna   soderzhat'   ispravlenie  v   otlazhennom   i
dokumentirovannom vide.


    Glava 14. Nazrevanie katastrofy

     Nikto ne lyubit prinosyashchego durnye vesti.
     SOFOKA
     Kak okazyvaetsya, chto proekt zapazdyvaet na god?
     ... Snachala zapazdyvaet na odin den'.
     Kogda slyshish' o katastroficheskom  otstavanii  proekta ot  grafika, to
predstavlyaetsya  ryad  obrushivshihsya na  nego bol'shih  bedstvij. Odnako  obychno
prichinoj katastrofy  sluzhat ne  smerchi,  a termity:  otstavanie  ot  grafika
proishodit nezametno,  no neumolimo. Na  samom  dele, s krupnymi  bedstviyami
spravit'sya  legche:  ispol'zuyutsya   krupnye  sily,   korennaya  reorganizaciya,
izobretayutsya novye podhody. Vsya komanda podnimaetsya na bor'bu.
     Otstavanie, rastushchee  ponemnogu  izo  dnya  v den', trudnee  raspoznat',
trudnee   predotvratit',  trudnee  ispravit'.  Vchera  ne  udalos'   provesti
soveshchanie iz-za bolezni  klyuchevogo rabotnika. Segodnya vyklyucheny  vse mashiny,
potomu chto molniya udarila v silovoj transformator. Zavtra ne  udastsya nachat'
testirovanie procedur raboty s  diskami, poskol'ku postavka s zavoda pervogo
diska zaderzhivaetsya na nedelyu.  Snegopad, rabota  v sude prisyazhnyh, semejnye
problemy,  ekstrennye  vstrechi s  klientami, proverki  rukovodstvom - spisok
beskonechen.  Kazhdoe  sobytie zaderzhivaet kakuyu-nibud'  rabotu na  poldnya ili
den'. I rastet otstavanie ot grafika, kazhdyj raz eshche na odin den'.
     Vehi ili pomehi?
     Kak upravlyat' bol'shim proektom po zhestkomu grafiku? Prezhde vsego, nado
imet'  grafik. U kazhdogo iz sobytij,  nazyvaemyh vehami, dolzhna  byt'  data.
Vybor dat -  uzhe obsuzhdavshayasya zadacha ocenki, i on reshayushchim obrazom  zavisit
ot opyta.
     Dlya vybora  vseh veh est' tol'ko odno prigodnoe pravilo.  Vehami dolzhny
sluzhit'  konkretnye  osobye sobytiya, kotorye mozhno identificirovat' s polnoj
opredelennost'yu. V kachestve otricatel'nyh  primerov  otmetim,  chto napisanie
programmy  "zakoncheno na 90  procentov"  v  techenie  poloviny vsego  vremeni
kodirovaniya. Otladka "zakonchena na 99 procentov" pochti vsegda. "Planirovanie
zaversheno" - sobytie, kotoroe mozhno ob®yavit' pochti proizvol'no.1
     Naprotiv,  vehi dolzhny  byt' 100-procentnymi  sobytiyami.  "Specifikacii
podpisany  arhitektorami  i  razrabotchikami", "ishodnyj  kod  gotov  na  100
procentov, otperforirovan i  zagruzhen  v biblioteku  na diske",  "otlazhennaya
versiya proshla vse kontrol'nye primery". Takie konkretnye vehi razgranichivayut
rasplyvchatye etapy planirovaniya, kodirovaniya i otladki.
     Nalichie  chetko  ocherchennyh  granic   i  nedvusmyslennost'  vazhnee,  chem
vozmozhnost' legkoj  proverki nachal'nikom.  Edva li  chelovek  stanet lgat'  o
prohozhdenii  vehi, esli  ona  ocherchena stol'  yasno,  chto  ot ne  mozhet  sebya
obmanyvat'. A vot esli veha rasplyvchata, nachal'nik chasto vosprinimaet doklad
inache, chem tot, kto emu dokladyvaet. Dopolnyaya Sofokla, skazhem,  chto nikto ne
lyubit i  sam  prinosit'  durnye vesti,  poetomu  oni  smyagchayutsya  bez  zlogo
namereniya vvesti v zabluzhdenie.
     Dva interesnyh issledovaniya povedeniya pravitel'stvennyh  podryadchikov po
provedeniyu ocenok v krupnomasshtabnyh issledovatel'skih proektah pokazali:
     1.   Ocenki   prodolzhitel'nosti   raboty,   tshchatel'no   provedennye   i
peresmatrivaemye kazhdye dve nedeli pered nachalom  raboty, ne sil'no menyayutsya
po mere  priblizheniya nachala  raboty, kakimi by  nevernymi oni ni okazalis' v
konechnom itoge.
     2.   Posle   nachala  raboty  zavyshennye  iznachal'no   ocenki  postoyanno
umen'shayutsya po mere prodvizheniya.
     3.  Zanizhennye ocenki sushchestvenno ne menyayutsya, poka do zaplanirovannogo
sroka okonchaniya rabot ne ostaetsya okolo treh nedel'.
     CHetko  razlichimye vehi v  dejstvitel'nosti  sozdayut  udobstvo  komande,
kotoraya dolzhna  rasschityvat',  chto menedzher ih horosho  opredelit.  S  neyasno
vidimoj  vehoj  zhizn' stanovitsya  trudnee.  |to  uzhe ne  veha, a  mel'nichnyj
kamen',  peretirayushchij  boevoj  duh,  poskol'ku   ona  vvodit  v  zabluzhdenie
otnositel'no poter' vremeni, poka oni ne stanut nepopravimymi. A hronicheskoe
otstavanie ot grafika ugnetayushche dejstvuet na moral'noe sostoyanie.
     "Drugaya chast' tozhe opazdyvaet"
     Otstavanie ot grafika na odin den' - nu i chto? Kogo volnuet otstavanie
na  odin  den'?  Pozzhe nagonim. Drugaya chast',  v  kotoruyu vhodit nasha,  tozhe
otstaet na odin den'.
     Menedzher bejsbola schitaet energiyu vazhnym talantom,  kak  dlya vydayushchihsya
igrokov,  tak i  dlya vydayushchihsya komand. |to sposobnost'  begat' bystree, chem
neobhodimo, peredvigat'sya  skoree, chem neobhodimo,  starat'sya  sil'nee,  chem
neobhodimo.  |nergiya  vazhna  i  dlya  vydayushchihsya  komand  programmistov.  Ona
obespechivaet uprugost', rezervnuyu moshchnost', pozvolyayushchie komande spravit'sya s
povsednevnymi  nepriyatnostyami, predvoshishchat'  melkie bedy  i  uberegat'sya ot
nih.  Rasschitannaya  reakciya, razmerennye usiliya  ohlazhdayut  energiyu.  Kak my
videli, nuzhno prihodit' v vozbuzhdenie iz-za otstavaniya na odin den', ibo oni
yavlyayutsya sostavlyayushchimi katastrofy.
     No  ne  vse  otstavaniya  na odin den' odinakovo katastrofichny.  Poetomu
neobhodimo rasschityvat' reakciyu, hotya eto i oslablyaet  energiyu. Kak otlichit'
otstavaniya, kotorye  sushchestvenny?  Nichem nel'zya zamenit'  diagrammy PERT ili
metod kriticheskogo  puti. Takaya  set'  pokazyvaet, kto nahoditsya v  ozhidanii
kakih sobytij. Ona pokazyvaet, kto nahoditsya na kriticheskom puti, na kotorom
lyuboe otstavanie vlechet perenos daty okonchaniya. Ona takzhe pokazyvaet,  kakoe
predel'noe otstavanie vozmozhno dlya nekotoroj raboty, prezhde chem ono privedet
na kriticheskij put'.
     Tehnologiya  PERT,  strogo  govorya,  est'  razrabotka  grafika  rabot  s
kriticheskim  putyami,  kogda  dlya  kazhdogo  sobytiya  proizvodyatsya tri ocenki,
sootvetstvuyushchie raznym  veroyatnostyam ulozhit'sya v ustanovlennye sroki.  YA  ne
dumayu,  chto takoe utochnenie  stoit  zatrachivaemyh usilij,  no  dlya kratkosti
vsyakuyu set' s kriticheskim putyami budu nazyvat' diagrammoj PERT.
     Podgotovka  diagramm  PERT  est'  samaya  cennaya  chast'  ee  primeneniya.
Opredelenie topologii seti, ukazanie zavisimostej v nej  i ocenivanie  putej
zastavlyayut vypolnit'  bol'shoj ob®em ochen'  konkretnogo planirovaniya na samyh
rannih  stadiyah  proekta. Pervaya  diagramma vsegda  uzhasna,  i  dlya sozdaniya
vtoroj prihoditsya proyavit' mnogo izobretatel'nosti.
     Vo vremya vypolneniya proekta diagramma PERT daet otvet na demoralizuyushchie
izvineniya  tipa  "drugaya chast'  tozhe  zapazdyvaet".  Ona  pokazyvaet,  kogda
neobhodimo  razvit' energiyu, chtoby uvesti svoyu  chast' raboty s  kriticheskogo
puti, i podskazyvaet sposoby naverstat' poteryannoe vremya v drugih chastyah.
     Pod kovrom
     Kogda  menedzher  nizovogo  zvena  vidit,  chto  ego malen'kaya  komanda
otstaet, on ne sklonen bezhat' k nachal'niku so svoim gorem. Vozmozhno, komanda
sumeet   naverstat'   vremya,  libo  on  smozhet  chto-nibud'   pridumat'   ili
reorganizovat' dlya resheniya problemy. Zachem zhe bespokoit' etim nachal'nika? Do
pory  do vremeni  eto  dopustimo. Dlya togo i sushchestvuyut  menedzhery  nizovogo
zvena,  chtoby reshat' takie problemy. A u nachal'nika dostatochno drugih zabot,
trebuyushchih  ego  vmeshatel'stva,  chtoby   iskat'  novye.  Tak  vsya  eta  gryaz'
zametaetsya pod kover.
     No kazhdomu nachal'niku nuzhny dva vida dannyh: informaciya o sryvah plana,
kotoraya trebuet vmeshatel'stva, i kartina sostoyaniya del, chtoby byt' v kurse.3
S etoj cel'yu on dolzhen znat' polozhenie del vo vseh svoih  komandah. Poluchit'
pravdivuyu kartinu nelegko.
     V  etom meste interesy menedzhera nizovogo zvena i nachal'nika vstupayut v
protivorechie. Menedzher nizovogo zvena boitsya, chto esli on dolozhit nachal'niku
o  voznikshej u  nego probleme, tot  voz'metsya  za nee sam. Ego vmeshatel'stvo
otnimet u menedzhera  ego funkcii,  umen'shit ego vlast' i narushit drugie  ego
plany.  Poetomu, poka menedzher schitaet, chto mozhet sam reshit' problemu, on ne
dokladyvaet o nej nachal'niku.
     U nachal'nika est' dva  sposoba zaglyanut' pod kovrik. Ispol'zovat' nuzhno
oba. Pervyj - umen'shit' konflikt rolej i  stimulirovat' otkrytie informacii.
Vtoroj - sdernut' kovrik.
     Umen'shenie konflikta rolej. V pervuyu ochered'  nachal'nik dolzhen provesti
razlichie mezhdu  dannymi i dejstviyah i  dannymi  o sostoyanii del.  On  dolzhen
priuchit' sebya ne vmeshivat'sya v problemy, kotorye mogut reshit' ego menedzhery,
i nikogda  ne  vmeshivat'sya  v  problemy  neposredstvenno vo  vremya  izucheniya
sostoyaniya del. YA znal odnogo nachal'nika,  kotoryj  neizmenno snimal trubku i
nachinal davat' ukazaniya, ne dochitav do konca pervyj abzac otcheta o sostoyanii
del. Pri takih dejstviyah vam obespecheno utaivanie polnyh dannyh.
     Naprotiv, esli menedzher znaet, chto ego nachal'nik  vosprimet  otchet  bez
paniki ili vmeshatel'stva, on budet davat' chestnye ocenki.
     Ves'  etot  process  idet  uspeshno, esli  nachal'nik  podcherkivaet,  chto
soveshchaniya, zaslushivaniya i konferencii nosyat harakter izucheniya sostoyaniya del,
a  ne  prinyatiya mer  po problemam,  i  vedet  sebya sootvetstvuyushchim  obrazom.
Ochevidno,  mozhno  sozvat'   soveshchanie  po  prinyatiyu   mer   po   rezul'tatam
zaslushivaniya o  sostoyanii del, esli  voznikaet oshchushchenie,  chto problema vyshla
iz-pod  kontrolya. No  togda  po krajnej  mere vse  znayut, chto proishodit,  i
nachal'nik dvazhdy podumaet, prezhde chem vzyat' upravlenie na sebya.
     Sdergivanie  kovrika.  Tem  ne  menee  neobhodimo imet'  sposob  uznat'
istinnoe  polozhenie del nezavisimo ot nalichiya  stremleniya k  sotrudnichestvu.
Osnovoj takogo izucheniya sluzhit diagramma PERT s chasto raspolozhennymi vehami.
V bol'shom proekte mozhno potrebovat'  ezhenedel'nogo izucheniya kakoj-libo chasti
ee, rassmatrivaya vsyu diagrammu raz v mesyac ili okolo togo.
     Glavnym  dokumentom  yavlyaetsya  otchet  s  ukazaniem  veh  i  stepeni  ih
fakticheskogo vypolneniya. (Na risunke 14.1 pokazan fragment  takogo  otcheta.)
On  mozhet pokazyvat' otstavanie  po nekotorym poziciyam i sluzhit'  v kachestve
povestki   dnya  soveshchaniya.  Vsem  izvestny  vynosimye  na  nego  voprosy,  i
sootvetstvuyushchie   menedzhery   gotovy   dolozhit'   o   prichinah   otstavaniya,
predpolagaemyh  srokah zaversheniya, prinimaemyh  merah, a takzhe  trebuetsya li
pomoshch' ot nachal'nika ili drugih grupp, i esli da, to kakaya.
     V.  Vysockij  iz   Bell  Telephone  Laboratories  dobavlyaet   sleduyushchee
nablyudenie:
     Dlya menya  okazalos' udobnym imet' v otchete  o sostoyanii del dve  daty -
"planovuyu"  i "ocenivaemuyu". Planovye  daty prinadlezhat menedzheru  proekta i
predstavlyayut  soboj  posledovatel'nyj  plan  raboty dlya proekta  v  celom, a
priori  yavlyayushchijsya  priemlemym.  Ocenivaemye   daty  prinadlezhat  menedzheram
nizshego zvena,  v peredelah kompetencii  kotoryh  nahodyatsya  rassmatrivaemye
uchastki, i predstavlyayut  ih mneniya o sroke fakticheskogo  nastupleniya sobytiya
pri  imeyushchihsya u nih resursah i poluchenii vhodnyh dannyh (ili obyazatel'stvah
ob ih postavke).  Menedzher proekta dolzhen ostorozhno otnosit'sya k ocenivaemym
datam  i   stremit'sya  k   polucheniyu   tochnyh,  neiskazhennyh  ocenok,  a  ne
uteshitel'no-optimistichnyh ili perestrahovochno- konservativnyh  dannyh.  Esli
eta poziciya utverditsya v umah, to menedzher

     

     Ris. 14.1
     proekta dejstvitel'no smozhet predvidet', chto on popadet v bedu, esli ne
predprimet kakih-nibud' mer.4
     Sozdanie diagrammy PERT yavlyaetsya obyazannost'yu  nachal'nika i podotchetnyh
emu menedzherov. Vnesenie v  nee izmenenij, peresmotr i podgotovka otchetnosti
dolzhny osushchestvlyat'sya  nebol'shoj (ot odnogo do treh chelovek) gruppoj, kak by
prodolzhayushchej nachal'nika. Takaya  gruppa planirovaniya i kontrolya neocenima pri
rabote nad bol'shim proektom. Ona ne obladaet  inymi polnomochiyami, krome  kak
trebovat' ot menedzherov nizovogo zvena predostavleniya svedenij  ob ustanovke
ili izmenenii veh  i ih dostizhenii. Poskol'ku gruppa planirovaniya i kontrolya
osushchestvlyaet vsyu  bumazhnuyu  chast' raboty,  nagruzka  na  menedzherov nizovogo
zvena ogranichivaetsya samym vazhnym - prinyatiem reshenij.
     U  nas byla umelaya, energichnaya i  diplomatichnaya  gruppa planirovaniya  i
kontrolya, vozglavlyavshayasya A. M. P'etrasanta  (A. M. Pietrasanta), proyavivshim
znachitel'nye  izobretatel'nye  sposobnosti  dlya  razrabotki effektivnyh,  no
nenavyazchivyh metodov kontrolya.  V rezul'tate ego gruppa pol'zovalas' shirokim
uvazheniem i horoshim otnosheniem.  |to nemaloe dostizhenie  dlya gruppy, kotoraya
po prirode svoej dolzhna vyzyvat' razdrazhenie.
     Vydelenie   nebol'shogo  chisla   podgotovlennyh  rabotnikov   v   gruppu
planirovaniya i kontrolya prinosit bol'shuyu  otdachu.  Dlya  uspeshnogo zaversheniya
proekta eto znachitel'no  luchshe,  chem esli by oni neposredstvenno  zanimalis'
razrabotkoj  programmnyh produktov, tak kak  gruppa  planirovaniya i kontrolya
stoit  na  strazhe   togo,  chtoby  neoshchutimye  zaderzhki  stali   vidimymi,  i
signaliziruet  o  kriticheskih  polozheniyah. |to  sistema  rannego obnaruzheniya
poteri goda, proishodyashchej den' za dnem.


    Glava 15. Obratnaya storona

     CHego my ne ponimaem, tem ne vladeem.
     GETE
     O, dajte mne vystupit' kommentatorom,
     Skol'zyashchim po poverhnosti i budorazhashchim umy.
     KRABB
     omp'yuternaya  programma  -  eto  poslanie  cheloveka   mashine.   Strogo
vystroennyj  sintaksis  i  tshchatel'nye  opredeleniya  naceleny  na  to,  chtoby
bezdumnoj mashine stali ponyatny namereniya cheloveka.
     No u  napisannoj  programmy  est' obratnaya storona:  ona dolzhna byt'  v
sostoyanii rasskazat'  o  sebe  pol'zovatelyu-cheloveku. |to trebuetsya dazhe dlya
programmy, napisannoj  isklyuchitel'no  dlya sobstvennyh nuzhd, poskol'ku pamyat'
mozhet izmenit' avtoru-pol'zovatelyu, i emu potrebuetsya osvezhit' detali svoego
truda.
     Naskol'ko  zhe  bolee  neobhodima  dokumentaciya  dlya   programmy  obshchego
pol'zovaniya,  pol'zovatel'  kotoroj  otdalen  ot  avtora  vo  vremeni,  i  v
prostranstve! Dlya programmnogo produkta  storona, obrashchennaya k pol'zovatelyu,
stol' zhe vazhna, kak i storona, obrashchennaya k mashine.
     Mnogie   iz  nas  branili  dalekogo   bezymyannogo   avtora   za  skudno
dokumentirovannuyu programmu. I mnogie poetomu pytalis' na vsyu zhizn'  privit'
molodym programmistam uvazhenie  k dokumentacii, preodolevayushchee len'  i press
grafika rabot. V celom nam eto ne udalos'. YA dumayu, my ispol'zovali nevernye
metody.
     Tomas Dzh. Uotson Starshij* (Thomas J. Watson, Sr.) rasskazal mne istoriyu
svoego pervogo opyta v kachestve prodavca kassovyh apparatov v severnoj chasti
shtata  N'yu-Jork.  Ispolnennyj  entuziazma,  on  otpravilsya v  put'  v  svoem
furgone, nagruzhennom kassovymi apparatami. On prilezhno ob®ehal svoj uchastok,
no  nichego ne prodal. Obeskurazhennyj,  on  soobshchil  ob etom  svoemu hozyainu.
Poslushav   nekotoroe  vremya,  upravlyayushchij   skazal:  "Pomogi  mne  zagruzit'
neskol'ko  kass  v  furgon,  zapryagaj loshad', i  poedem  snova."  Tak  oni i
sdelali,  i  obhodya  pokupatelej  odnogo za  drugim,  starik pokazyval,  kak
prodavat' kassovye apparaty. Sudya po vsemu, urok poshel vprok.
     Neskol'ko  let  ya  staratel'no  chital  gruppam  inzhenerov-programmistov
lekcii o neobhodimosti i zhelatel'nosti horoshej dokumentacii, uveshchevaya ih vse
s bol'shim pylom i krasnorechiem. |to ne podejstvovalo. YA predpolozhil, chto oni
ponyali,  kak  pravil'no  sostavlyat'  dokumentaciyu,  no  ne delali  etogo  po
nedostatku rveniya. Togda ya poproboval pogruzit' v povozku neskol'ko kassovyh
apparatov, t.e. pokazat' im, kak delaetsya  eta rabota. |to imelo znachitel'no
bol'shij uspeh.  Poetomu  ostavshayasya chast'  etogo povestvovaniya  posvyashchena ne
stol'ko poucheniyam, skol'ko ob®yasneniyu togo, kak delat' horoshuyu dokumentaciyu.
     Kakaya dokumentaciya trebuetsya?
     Neobhodimy   razlichnye   urovni   dokumentacii:  dlya   pol'zovatelya,
obrashchayushchegosya  k  programme ot  sluchaya k sluchayu, dlya  pol'zovatelya,  kotoryj
sushchestvenno zavisit ot programmy v svoej rabote, i dlya pol'zovatelya, kotoryj
dolzhen adaptirovat' programmu k izmenivshemusya okruzheniyu ili zadacham.
     CHtoby ispol'zovat' programmu. Kazhdomu pol'zovatelyu  trebuetsya slovesnoe
opisanie programmy. Po bol'shej chasti dokumentaciya stradaet otsutstvie obshchego
obzora. Opisany  derev'ya, prokommentirovany  kora  i list'ya, no plan  lesa *
Tomas  Dzh.  Uotson  Starshij  -  osnovatel'  kompanii  IBM  (primech.  perev.)
otsutstvuet. CHtoby napisat' poleznoe tekstovoe opisanie, vzglyanite izdaleka,
a zatem medlenno priblizhajtes':
     1. Naznachenie.  CHto yavlyaetsya glavnoj funkciej programmy i  prichinoj  ee
napisaniya?
     2. Sreda. Na kakih mashinah,  apparatnyh konfiguraciyah  i  konfiguraciyah
operacionnoj sistemy budet ona rabotat'?
     3. Oblast' opredeleniya i oblast' znachenij.  Kakovy  dopustimye znacheniya
vhodnyh  dannyh?  Kakie  pravil'nye  znacheniya  vyhodnyh   rezul'tatov  mogut
poyavit'sya?
     4.  Realizovannye  funkcii  i  ispol'zovannye algoritmy.  CHto konkretno
mozhet delat' programma?
     5. Formaty vvoda-vyvoda, tochnye i polnye.
     6.  Instrukciya po  rabote, v  tom  chisle opisanie vyvoda na  konsol'  i
ustrojstvo vyvoda pri normal'nom i avarijnom zavershenii.
     7. Opcii. Kakoj vybor predostavlyaetsya pol'zovatelyu v otnoshenii funkcij?
Kakim obrazom nuzhno ego zadavat'?
     8.  Vremya  raboty. Skol'ko  vremeni zanimaet reshenie  zadachi  zadannogo
razmera na zadannoj konfiguracii?
     9. Tochnost' i proverka. Kakova ozhidaemaya  tochnost'  rezul'tatov?  Kakie
imeyutsya sredstva proverki tochnosti?
     CHasto vse  eti dannye mozhno izlozhit' na treh ili chetyreh stranicah. Pri
etom nuzhno udelit' osoboe vnimanie  polnote i tochnosti.  Bol'shuyu chast' etogo
dokumenta nuzhno vcherne napisat'  do razrabotki  programmy,  poskol'ku v  nem
voploshcheny osnovnye planovye resheniya.
     CHtoby doveryat'  programme. Opisanie  togo, kak ispol'zovat'  programmu,
nuzhno dopolnit' opisaniem togo,  kak  ubedit'sya  v ee rabotosposobnosti. |to
oznachaet nalichie kontrol'nyh primerov.
     Kazhdyj  ekzemplyar  postavlyaemoj  programmy dolzhen  soderzhat'  neskol'ko
nebol'shih kontrol'nyh primerov, kotorye mozhno postoyanno ispol'zovat',  chtoby
uverit' pol'zovatelya v tom, chto on mozhet doveryat' programme, i ona pravil'no
zagruzhena v mashinu.
     Krome togo, nuzhny  bolee  tshchatel'nye  testy, kotorye obychno vypolnyayutsya
tol'ko  posle modifikacii programmy.  Oni otnosyatsya k  trem uchastkam oblasti
vhodnyh dannyh:
     1. Osnovnye parametry,  proveryayushchie glavnye funkcii programmy na obychno
vstrechaemyh dannyh.
     2.  Primery na grani dopustimogo,  proveryayushchie  granicy oblasti vhodnyh
dannyh i ubezhdayushchie, chto rabotayut naibol'shie znacheniya, naimen'shie znacheniya i
vse dopustimye isklyucheniya.
     3.  Primery  za  granicej  dopustimogo, proveryayushchie granicy  s obratnoj
storony  i  ubezhdayushchie,  chto  nedopustimye   znacheniya  vyzyvayut   pravil'nye
diagnosticheskie soobshcheniya.
     CHtoby modificirovat' programmu. Dlya adaptacii ili ispravleniya programmy
trebuetsya znachitel'no bol'she dannyh. Razumeetsya, trebuyutsya vse detali, a oni
soderzhatsya   v   horosho   prokommentirovannom  listinge.   U   pol'zovatelya,
modificiruyushchego  programmu ili  redko  ee  ispol'zuyushchego,  voznikaet  ostraya
neobhodimost' v yasnom otchetlivom obzore, na etot raz vnutrennej struktury. V
takoj obzor vhodyat:
     1. Blok-shema ili graf podprogrammnoj  organizacii.  Podrobnee  ob etom
sm. nizhe.
     2. Polnye opisaniya ispol'zuemyh algoritmov ili ssylki na takie opisaniya
v literature.
     3. Raz®yasnenie struktury vseh ispol'zuemyh fajlov.
     4. Obzor organizacii prohozhdeniya dannyh - posledovatel'nosti, v kotoroj
dannye ili programmy  zagruzhayutsya  s lenty ili diska  i opisanie  togo,  chto
delaetsya na kazhdom hode.
     5. Obsuzhdenie modifikacij, predpolagaemyh ishodnym proektom, sushchnost' i
raspolozhenie dobavochnyh  blokov  i vyhodov  i diskursivnoe obsuzhdenie myslej
avtora   programmy   otnositel'no   izmenenij,   kotorye   mogut   okazat'sya
zhelatel'nymi, i kak ih mozhno provesti. Polezno takzhe izlozhit' ego  zamechaniya
o skrytyh lovushkah.
     Bich blok-shem
     Blok-shema chashche vsego yavlyaetsya lishnej chast'yu programmnoj dokumentacii.
Dlya  mnogih programm blok-shemy  voobshche ne nuzhny. Redkie  programmy  trebuyut
blok- shemy bolee chem na odnu stranichku.
     Blok-shemy  pokazyvayut  strukturu   prinyatiya  programmoj  reshenij,  chto
yavlyaetsya  lish'   odnoj  storonoj   struktury  programmy.  Kogda   blok-shema
razmeshchaetsya  na  odnoj   stranice,   struktura   reshenij  vyglyadit  dovol'no
elegantno, no naglyadnost'  srazu utrachivaetsya, kogda est' neskol'ko stranic,
svyazannyh pronumerovannymi vhodami i vyhodami.
     Odnostranichnaya  blok-shema  dlya  znachitel'noj   po  razmeru   programmy
stanovitsya, v sushchnosti, diagrammoj struktury programmy i etapov ili shagov. V
etom  kachestve   ona  ochen'  udobna.  Risunok  15.1  pokazyvaet  takoj  graf
podprogrammnoj struktury.

     

     Ris. 15.1 Graf struktury programmy (primer W. V. Wright)
     Konechno, takoj strukturnyj graf ne trebuet  osobyh usilij po soblyudeniyu
standartov   ANSI   dlya   blok-shem.  Vse   eti  pravila  otnositel'no  vida
pryamougol'nikov,  soedinitel'nyh  linij,  numeracii i t.p. nuzhny  tol'ko dlya
ponimaniya podrobnyh blok-shem.
     Podrobnaya   poshagovaya   blok-shema   yavlyaetsya  dosadnym   anahronizmom,
prigodnym  tol'ko  dlya  novichkov   v  algoritmicheskom  myshlenii.   Vvedennye
Goldshtajnom  i  fon  Nejmanom1 pryamougol'niki  vmeste  so  svoim  soderzhimym
sluzhili yazykom  vysokogo urovnya, ob®edinyaya nepostizhimye operatory  mashinnogo
yazyka  v  osmyslennye  gruppy. Kak davno  ponyal  Iverson,2 v sistematicheskom
yazyke  vysokogo  urovnya gruppirovka  uzhe provedena,  i kazhdyj  pryamougol'nik
soderzhit  operator   (ris.  15.2).  Poetomu   sami  pryamougol'niki  yavlyayutsya
utomitel'nym i otnimayushchim mesto  uprazhneniem v cherchenii i  vpolne mogut byt'
udaleny. Togda ostayutsya tol'ko strelki. Strelki, svyazyvayushchie odin operator s
drugim, raspolozhennym v sleduyushchej stroke, izlishni, i ih mozhno udalit'. Togda
ostayutsya  tol'ko   GO   TO,   i   esli   priderzhivat'sya   horoshej   praktiki
programmirovaniya  i ispol'zovat'  blochnye struktury dlya minimizacii chisla GO
TO, takih strelok  okazhetsya nemnogo, no  oni  ochen'  sposobstvuyut ponimaniyu.
Vpolne mozhno narisovat' ih na listinge i vovse izbavit'sya ot blok-shemy.
     V dejstvitel'nosti o blok-shemah bol'she govoryat, chem  pol'zuyutsya imi. YA
nikogda ne videl opytnogo programmista, kotoryj  v povsednevnoj deyatel'nosti
risoval by  podrobnye blok-shemy, prezhde  chem  nachat' pisat' programmu. Tam,
gde blok-shemy trebuyutsya pravilami  organizacii, oni pochti vsegda  sozdayutsya
zadnim  chislom.  Mnogie  gordyatsya  ispol'zovaniem  special'nyh  programm dlya
generacii  etogo   "nezamenimogo  instrumenta  razrabotki"   na  osnove  uzhe
zakonchennoj programmy. Dumayu, chto etot vseobshchij opyt ne yavlyaetsya postydnym i
predosuditel'nym  othodom ot horoshej praktiki programmirovaniya, priznavat'sya
v kotorom mozhno  lish' s nervnym smeshkom.  Naprotiv,  eto  rezul'tat zdravogo
rassuzhdeniya, dayushchij nam urok otnositel'no poleznosti blok-shem.
     Apostol Petr skazal o novoobrashchennyh yazychnikah i zakone Moiseya: "CHto zhe
vy  [zhelaete]  vozlozhit'  na vyi uchenikov igo, kotorogo ne mogli  ponesti ni
otcy  nashi,  ni  my?"  (Deyaniya  apostolov  15:10).  To  zhe  skazal  by  ya  o
programmistah-novichkah i ustarevshej praktike blok-shem.
     Samodokumentiruyushchiesya programmy
     Odin  iz  osnovnyh principov  obrabotki dannyh  uchit, chto  bezrassudno
starat'sya podderzhivat'  sinhronnost'  nezavisimyh  fajlov. Znachitel'no luchshe
sobrat' ih v odin fajl, v kotorom kazhdaya zapis' soderzhit vse dannye ih oboih
fajlov, otnosyashchiesya k dannomu klyuchu.
     Tem  ne  menee  nasha  praktika dokumentirovaniya  programm  protivorechit
sobstvennym  teoriyam.  Obychno  my  pytaemsya  podderzhivat' programmu  v vide,
prigodnom dlya vvoda v mashinu, a nezavisimyj komplekt dokumentacii, sostoyashchej
iz teksta i blok-shem, - v vide, prigodnom dlya chteniya chelovekom.
     Rezul'taty   etogo   podtverzhdayut   mysl'  o   nerazumnosti   podderzhki
nezavisimyh fajlov. Programmnaya dokumentaciya poluchaetsya  udivitel'no plohoj,
a ee soprovozhdenie - i togo huzhe. Vnosimye v programmu izmeneniya ne poluchayut
bystrogo, tochnogo i obyazatel'nogo otrazheniya v dokumente.
     YA  polagayu,   chto  pravil'nym  resheniem  dolzhno  byt'  sliyanie  fajlov:
vklyuchenie  dokumentacii  v  ishodnyj tekst  programmy.  |to  odnovremenno  i
sil'nyj pobuditel'nyj motiv k  dolzhnomu soprovozhdeniyu,  i garantiya togo, chto
dokumentaciya vsegda budet pod rukoj u pol'zovatelya. Takie programmy nazyvayut
samodokumentiruyushchimisya.
     Ochevidno, pri etom neudobno, hotya i vozmozhno, vklyuchat' blok-shemy, esli
v  etom est' neobhodimost'.  No,  prinyav vo  vnimanie anahronizm blok-shem i
ispol'zovanie preimushchestvenno yazykov  vysokogo  urovnya, stanovitsya vozmozhnym
ob®edinit' programmu s dokumentaciej.
     Ispol'zovanie ishodnogo koda programmy v kachestve nositelya dokumentacii
vlechet  nekotorye  ogranicheniya. S  drugoj  storony,  neposredstvennyj dostup
chitatelya dokumentacii  k  kazhdoj stroke programmy otkryvaet vozmozhnost'  dlya
novyh tehnologij. Prishlo vremya razrabotat' radikal'no novye podhody i metody
sostavleniya programmnoj dokumentacii.
     V kachestve vazhnejshej celi my dolzhny popytat'sya predel'no umen'shit' gruz
dokumentacii - gruz, s kotorym  ni  my,  ni nashi  predshestvenniki tolkom  ne
spravilis'.
     Podhod.  Pervoe predlozhenie sostoit  v  tom,  chtoby razdely  programmy,
obyazannye prisutstvovat' v nej soglasno trebovaniyam  yazyka programmirovaniya,
soderzhali kak  mozhno bol'she dokumentacii. Sootvetstvenno,  metki,  operatory
ob®yavleniya i  simvolicheskie imena vklyuchayut  v  zadachu  peredat' chitatelyu kak
mozhno bol'she smysla.

     

     Ris. 15.2  Sravnenie blok-shemy  i  sootvetstvuyushchej  programmy  na PL/I
(fragment)
     Vtoroe predlozhenie -  v maksimal'noj mere ispol'zovat'  prostranstvo  i
format,  chtoby uluchshit'  chitaemost'  i  pokazat'  otnosheniya podchinennosti  i
vlozhennosti.
     Tret'e   predlozhenie  -  vklyuchit'  v  programmu  neobhodimuyu  tekstovuyu
dokumentaciyu  v   vide  paragrafov   kommentariev.  V  bol'shinstve  programm
dostatochno  imet' postrochnye kommentarii.  V programmah,  otvechayushchih zhestkim
standartam  organizacij  na  "horoshee  dokumentirovanie",  ih  chasto slishkom
mnogo.  Odnako  dazhe  v  etih  programmah   obychno  nedostatochno  paragrafov
kommentariev,  kotorye dejstvitel'no  sposobstvuyut ponyatnosti i  obozrimosti
celogo.
     Poskol'ku   dokumentaciya   vstraivaetsya   v   ispol'zuemye   programmoj
strukturu,  imena  i  formaty,  znachitel'nuyu  chast' etoj  raboty  neobhodimo
prodelat',  kogda programmu tol'ko nachinayut pisat'. No imenno  togda i nuzhno
pisat'  dokumentaciyu.  Poskol'ku   podhod  na  osnove   samodokumentirovaniya
sokrashchaet dopolnitel'nuyu rabotu, men'she prepyatstvij k ego osushchestvleniyu.
     Nekotorye   priemy.  Na  risunke  15.3  pokazana  samodokumentiruyushchayasya
programma na yazyke PL/I.3 CHisla v kruzhochkah ne yavlyayutsya ee  chast'yu, a sluzhat
metadokumentaciej dlya ssylok pri obsuzhdenii.
     1. Ispol'zujte dlya kazhdogo zapuska svoe  imya zadaniya i vedite zhurnal, v
kotorom uchityvajte predmet proverki, vremya i poluchennye rezul'taty. Esli imya
sostoit iz mnemoniki (zdes'  QLT) i chislovogo suffiksa (zdes' 4), to suffiks
mozhno ispol'zovat' v kachestve  nomera zapuska, svyazyvayushchego zapis' v zhurnale
i listing. Pri etom dlya raznyh progonov trebuyutsya svoi karty zadaniya, no  ih
mozhno delat' kolodami s dublirovaniem postoyannyh dannyh.
     2.   Ispol'zujte   mnemonicheskie    nazvaniya    programmy,   vklyuchayushchie
identifikator versii  - v predpolozhenii, chto budet neskol'ko  versij.  Zdes'
indeks - dve mladshie cifry goda.
     3. Vklyuchite tekstovoe opisanie v kachestve kommentariev k PROCEDURE.
     4.  Dlya   dokumentirovaniya  algoritmov  ssylajtes',   gde   mozhno,   na
literaturu. |to  ekonomit  mesto,  adresuet k bolee polnomu  osveshcheniyu,  chem
mozhno  dat'  v  programme,  i daet vozmozhnost' znayushchemu chitatelyu  propustit'
ssylku, ostavlyaya uverennost', chto on vas pojmet.
     5. Pokazhite  svyaz'  s algoritmom, opisannym  v knige:  a) izmeneniya; b)
osobennosti ispol'zovaniya; v) predstavlenie dannyh.
     6.   Ob®yavite   vse  peremennye.  Ispol'zujte  mnemoniku.   Ispol'zujte
kommentarii  dlya  prevrashcheniya   operatora  DECLARE  v  polnocennuyu  legendu.
Obratite vnimanie, chto on uzhe soderzhit imena i opisaniya struktur, nuzhno lish'
dopolnit'  ego  opisaniyami   naznacheniya.  Sdelav   eto  zdes',  vy  izbezhite
otdel'nogo povtoreniya imen i strukturnyh opisanij.
     7. Postav'te metku v nachale inicializacii.
     8.   Postav'te   metki   pered  gruppami   operatorov,  sootvetstvuyushchie
operatoram algoritma, opisannogo v knige.
     9. Ispol'zujte otstupy dlya pokaza struktury i gruppirovaniya.
     10.  Vruchnuyu  postav'te  strelki,   pokazyvayushchie   logicheskij   poryadok
operatorov. Oni  ochen'  polezny  pri otladke i vnesenii izmenenij. Ih  mozhno
pomestit' na pravom pole mesta dlya kommentariev i sdelat' chast'yu vvodimogo v
mashinu teksta.
     11. Vstav'te strochnye kommentarii dlya  poyasneniya vsego, chto neochevidno.
Pri   ispol'zovanii  izlozhennyh   vyshe  priemov  oni   okazhutsya   koroche   i
malochislennej, chem obychno.
     12. Pomeshchajte neskol'ko operatorov na odnoj stroke ili odin operator na
neskol'kih strokah v sootvetstvii s  logicheskoj gruppirovkoj,  a takzhe chtoby
pokazat' svyaz' s opisaniem algoritma.
     Vozrazheniya.  Kakovy nedostatki takogo podhoda  k  dokumentirovaniyu? Oni
sushchestvuyut, i  v prezhnie vremena  byli  sushchestvennymi, no sejchas  stanovyatsya
mnimymi.

     

     Ris. 15.3 Samodokumentiruyushchayasya programma
     Samym  ser'eznym  vozrazheniem  yavlyaetsya  uvelichenie  razmera  ishodnogo
teksta,  kotoryj  nuzhno hranit'. Poskol'ku  praktika  vse  bolee tyagoteet  k
hraneniyu  ishodnogo  koda  v  aktivnyh  ustrojstvah, eto  vyzyvaet  rastushchee
bespokojstvo.  Lichno ya  pishu bolee kratkie kommentarii v programmah  na APL,
kotorye  hranyatsya  na diske, chem v  programmah na  PL/I, kotorye hranyatsya na
perfokartah.
     Odnako  odnovremenno  my dvizhemsya  k  hraneniyu  v  aktivnyh ustrojstvah
tekstovyh dokumentov, dostup k kotorym  i izmenenie osushchestvlyaetsya s pomoshch'yu
komp'yuterizirovannyh  tekstovyh  redaktorov.  Kak  ukazyvalos' vyshe, sliyanie
teksta i programmy sokrashchaet obshchee kolichestvo hranimyh simvolov.
     Analogichnoe  vozrazhenie  vyzyvaet argument,  chto  samodokumentiruyushchiesya
programmy trebuyut bol'she vvoda s klaviatury. V pechatnom dokumente trebuetsya,
po  men'shej  mere,  odno  nazhatie  na klavishu dlya  kazhdogo simvola na kazhdyj
chernovoj ekzemplyar.  V samodokumentiruyushchejsya programme summarnoe  kolichestvo
simvolov men'she, i na odin simvol prihoditsya men'she nazhatij na klavishi,  tak
kak chernoviki ne perepechatyvayutsya.
     A chto  zhe  blok-shemy i strukturnye  grafy?  Esli  ispol'zuetsya  tol'ko
strukturnyj graf  samogo  vysokogo  urovnya, on vpolne  mozhet  soderzhat'sya  v
otdel'nom  dokumente, poskol'ku  redko podvergaetsya  izmeneniyam. No konechno,
ego  mozhno vklyuchit' v ishodnyj  tekst programmy v kachestve kommentariya,  chto
budet blagorazumno.
     V kakoj mere opisannye  vyshe priemy primenimy  dlya  programm  na  yazyke
assemblera? YA dumayu,  chto  bazovyj podhod dokumentirovaniya  primenim  vsyudu.
Svobodnym prostranstvom i formatami  mozhno pol'zovat'sya s  men'shej  stepen'yu
svobody,  i poetomu  oni  ispol'zuyutsya ne  tak  gibko.  Imena  i  ob®yavleniya
struktur,  nesomnenno,  mozhno  ispol'zovat'.  Ochen'  mogut  pomoch'  makrosy.
Intensivnoe ispol'zovanie paragrafov kommentariem yavlyaetsya horoshej praktikoj
v lyubom yazyke.
     No  podhod  na  osnove  samodokumentirovaniya  stimulirovan  primeneniem
yazykov vysokogo urovnya  i obretaet naibol'shuyu moshch' i naivysshee  opravdanie v
yazykah  vysokogo urovnya, ispol'zuemyh  v rezhime on-lajn, bud'  to v paketnom
rezhime ili interaktivno. Kak ya dokazyval, takie yazyki i sistemy ochen' sil'no
oblegchayut zhizn' programmistov. Poskol'ku mashiny sdelany dlya lyudej, a ne lyudi
dlya mashin, ih ispol'zovanie opravdano kak s ekonomicheskoj tochki  zreniya, tak
i chisto po- chelovecheski.

        Glava  16.  Serebryanoj puli net  -  sushchnost' i akcidenciya v  programmnoj
inzhennerii     Net ni  odnogo otkrytiya  ni v tehnologii, ni v metodah upravleniya,
odno  tol'ko  ispol'zovanie   kotorogo  obeshchalo   by  v  techenie  blizhajshego
desyatiletiya na  poryadok  povysit'  proizvoditel'nost', nadezhnost',  prostotu
razrabotki programmnogo obespecheniya.
     Rezyume1
     Sozdanie programmnogo obespecheniya vsegda vklyuchaet v sebya sushchestvennye
zadachi   -  modelirovanie  slozhnyh  konceptual'nyh  struktur,   sostavlyayushchih
abstraktnyj  programmnyj  ob®ekt,  i  vtorostepennye   zadachi   -   sozdanie
predstavlenij etih abstraktnyh ob®ektov  s pomoshch'yu yazykov programmirovaniya i
otobrazhenie ih v mashinnye yazyki s uchetom ogranichenij po pamyati i skorosti. V
proshlom rost  produktivnosti  programmirovaniya  po bol'shej  chasti dostigalsya
blagodarya ustraneniyu iskusstvennyh pregrad,  delavshih  vtorostepennye zadachi
chrezmerno  trudnymi,  naprimer,  zhestkih apparatnyh  ogranichenij,  neudobnyh
yazykov  programmirovaniya,  nehvatki mashinnogo  vremeni.  Kakaya  chast' raboty
razrabotchikov programmnogo obespecheniya vse eshche svyazana so vtorostepennymi, a
ne  s  sushchestvennymi obstoyatel'stvami? Esli  ona  zanimaet  menee  9/10 vseh
zatrat,  to,  dazhe  svedya vse vtorostepennye zatraty  k nulyu,  my ne poluchim
rosta proizvoditel'nosti na poryadok velichin.
     Poetomu,  pohozhe,  nastalo  vremya  obratit'sya  k  sushchestvennym  zadacham
programmirovaniya, svyazannym s modelirovaniem konceptual'nyh struktur bol'shoj
slozhnosti. YA predlagayu:
     - Ispol'zovat' massovyj rynok, chtoby  izbezhat' sozdaniya togo, chto mozhno
kupit'.
     - Ispol'zovat' bystroe maketirovanie kak chast' zaplanirovannyh iteracij
dlya ustanovleniya tehnicheskih trebovanij k programmnomu obespecheniyu.
     -  Organichno  narashchivat' programmy,  dobavlyaya k  sistemam  vse  bol'shuyu
funkcional'nost' po mere ih zapuska, ispol'zovaniya i testirovaniya.
     -  Vyyavlyat'  i  rastit'  vydayushchihsya   razrabotchikov  koncepcij   novogo
pokoleniya.
     Vvedenie
     Iz vseh monstrov, kotorymi napolneny koshmary nashego  fol'klora, samymi
strashnymi  yavlyayutsya  oborotni,  poskol'ku nas pugaet neozhidannoe prevrashchenie
togo, chto  nam horosho  znakomo, v  nechto  uzhasnoe. My  ishchem serebryanye puli,
kotorye mogli by volshebnym obrazom ulozhit' oborotnej napoval.
     Horosho  znakomyj  programmnyj  proekt napominaet  takih  oborotnej  (po
krajnej  mere,  v   predstavlenii  menedzherov,  ne  yavlyayushchihsya  tehnicheskimi
specialistami) tem,  chto, buduchi prostym i nevinnym na  vid, on mozhet  stat'
chudishchem  provalennyh  grafikov  raboty,  razduvshihsya byudzhetov i nerabotayushchih
produktov.
     I  my slyshim otchayannye  kriki s pros'bami dat' serebryanuyu pulyu - nechto,
sposobnoe  snizit'  stoimost'  programmnyh  produktov  tak   zhe  rezko,  kak
snizilas' stoimost' komp'yuterov.
     No,  vglyadyvayas'  v  predstoyashchee  desyatiletie,  my  ne   vidim  nikakoj
serebryanoj puli.  Net ni  odnogo  otkrytiya  ni  v tehnologii,  ni v  metodah
upravleniya,  odno tol'ko ispol'zovaniya  kotoryh  obeshchalo  by hot' na poryadok
velichin  povysit' proizvoditel'nost', nadezhnost', prostotu. V etoj  glave my
popytaemsya uvidet', pochemu  eto tak, issleduya prirodu zadach programmirovaniya
i svojstva predlagaemyh pul'.
     Odnako  skepticizm - eto ne  pessimizm.  Hotya my ne  vidim oshelomlyayushchih
proryvov    i    dejstvitel'no    schitaem    ih   nesvojstvennymi    prirode
programmirovaniya,   proishodit   mnogo   vselyayushchih   nadezhdy   novovvedenij.
Disciplinirovannye  i posledovatel'nye usiliya, napravlennye na  ih razvitie,
rasprostranenie i  ispol'zovanie, dejstvitel'no mogut  dat' rost na  poryadok
velichin. Net carskogo puti, no vse zhe put' est'.
     Pervym  shagom k lecheniyu boleznej stala zamena predstavlenij o demonah i
"sokah"  v  organizme  teoriej  bakterij.  Sam etot shag, obeshchavshij  nadezhdu,
oproverg vse  mechty  o  chudesnom iscelenii. On podskazal issledovatelyam, chto
progress budet  osushchestvlyat'sya shazhkami, s bol'shim trudom, i chto postoyannoe i
neoslabnoe  vnimanie  nuzhno  udelyat' sanitarii.  To zhe  proishodit segodnya s
programmnoj inzheneriej.
     Neizbezhny li trudnosti? Trudnosti, vytekayushchie iz sushchnosti
     Serebryanyh pul' ne tol'ko ne vidno v nastoyashchee vremya, no v silu samoj
prirody  programmnogo obespecheniya maloveroyatno, chto oni voobshche budut najdeny
-  ne  budet  izobretenij, sposobnyh  povliyat'  na  produktivnost' sozdaniya,
nadezhnost'  i  prostotu  programmnogo  obespecheniya  tak,  kak   elektronika,
tranzistory i integral'nye shemy - na apparatnoe obespechenie komp'yuterov. Ne
sleduet ozhidat',  chto kogda-libo v budushchem kazhdye dva goda budet proishodit'
dvukratnyj rost.
     Vo-pervyh, sleduet schitat' neobychnym ne to, chto tak medlenno proishodit
progress v programmirovanii, a  to,  chto  on tak  bystro  idet  v apparatnom
obespechenii  komp'yuterov.  Ni   odna  drugaya  tehnologiya   za  vsyu   istoriyu
civilizacii  ne   imela  za   30  let  svoego  razvitiya  rosta   sootnosheniya
proizvoditel'nost'/cena  na  shest' poryadkov.  Ni  odna drugaya tehnologiya  ne
pozvolyaet   vybrat',   kakoj  vyigrysh   predpochest':  uluchshit'   tehnicheskie
harakteristiki  ili  snizit'  zatraty.   Oba  eti  vyigrysha  stali  vozmozhny
blagodarya perehodu proizvodstva  komp'yuterov  iz  sborochnogo proizvodstva  v
obrabatyvayushchee.
     Vo-vtoryh, chtoby posmotret',  kakoj skorosti razvitiya  mozhno ozhidat' ot
programmnyh tehnologij,  polezno  izuchit' imeyushchiesya  v nih trudnosti. Sleduya
Aristotelyu, ya  delyu ih na sushchnosti  - trudnosti, vnutrenne prisushchie  prirode
programmnogo  obespecheniya,   i  akcidencii  -  trudnosti,  kotorye   segodnya
soputstvuyut proizvodstvu  programmnogo obespecheniya, no ne yavlyayutsya vnutrenne
emu prisushchimi.
     Akcidencii ya rassmatrivayu  v sleduyushchem  paragrafe.  Snachala  rassmotrim
sushchnost'.
     Sushchnost'yu  programmnogo  ob®ekta  yavlyaetsya  konstrukciya,  sostoyashchaya  iz
sceplennyh  vmeste koncepcij: naborov dannyh, vzaimosvyazej mezhdu  elementami
dannyh, algoritmov  i  vyzovov  funkcij. |ta sushchnost' yavlyaetsya abstraktnoj v
tom  otnoshenii, chto konceptual'naya konstrukciya  ostaetsya odnoj i toj zhe  pri
razlichnyh predstavleniyah. Tem  ne  menee ona  obladaet  vysokoj tochnost'yu  i
bol'shim chislom detalej.
     YA schitayu, chto slozhnost' sozdaniya programmnogo obespecheniya zaklyuchaetsya v
zadanii    tehnicheskih    trebovanij,   proektirovanii   i   proverke   etoj
konceptual'noj konstrukcii, a ne v zatratah, svyazannyh s ee predstavleniem i
proverkoj tochnosti predstavleniya. Konechno, my  delaem sintaksicheskie oshibki,
no  v bol'shinstve  sistem  oni  nesushchestvenny  v sravnenii s konceptual'nymi
oshibkami.
     Verno  to,  chto  sozdanie  programmnyh  sistem  vsegda  budet  trudnym.
Serebryanoj puli net po samoj prirode veshchej.
     Rassmotrim neot®emlemye svojstva etoj nesokratimoj sushchnosti sovremennyh
programmnyh sistem: slozhnost', soglasovannost', izmenyaemost' i nezrimost'.
     Slozhnost'. Slozhnost' programmnyh ob®ektov bolee zavisit ot ih razmerov,
chem, vozmozhno, dlya lyubyh drugih sozdavaemyh chelovekom konstrukcij, poskol'ku
nikakie  dve ih chasti  ne shozhi  mezhdu soboj (po krajnej mere,  vyshe  urovnya
operatorov).  Esli oni  shozhi,  to  my  ob®edinyaem  ih v odnu  podprogrammu,
otkrytuyu ili zakrytuyu.  V etom otnoshenii  programmnye sistemy imeyut glubokoe
otlichie  ot  komp'yuterov, domov  i  avtomobilej, gde  povtoryayushchiesya elementy
imeyutsya v izobilii.
     Sami  cifrovye  komp'yutery  slozhnee,  chem  bol'shinstvo  izgotavlivaemyh
lyud'mi veshchej. CHislo  ih sostoyanij ochen' veliko, poetomu ih  trudno ponimat',
opisyvat' i testirovat'.  U programmnyh  sistem chislo vozmozhnyh sostoyanij na
poryadki velichin prevyshaet chislo sostoyanij komp'yuterov.
     Analogichno,  masshtabirovanie  programmnogo  ob®ekta  -  eto  ne  prosto
uvelichenie  v razmere teh  zhe samyh  elementov,  eto  obyazatel'no uvelichenie
chisla   razlichnyh    elementov.   V   bol'shinstve   sluchaev   eti   elementy
vzaimodejstvuyut mezhdu  soboj nekim  nelinejnym  obrazom, i  slozhnost' celogo
rastet znachitel'no bystree, chem linejno.
     Slozhnost'   programm   yavlyaetsya  sushchestvennym,   a   ne  vtorostepennym
svojstvom.  Poetomu  opisaniya  programmnyh ob®ektov, abstragiruyushchiesya  ot ih
slozhnosti,  chasto  abstragiruyutsya  ot ih sushchnosti.  Matematika i  fizicheskie
nauki za tri  stoletiya dostigli  bol'shih uspehov, sozdavaya uproshchennye modeli
slozhnyh fizicheskih yavlenij, poluchaya  iz etih  modelej svojstva i proveryaya ih
opytnym putem. |to udavalos' blagodarya tomu, chto slozhnosti, ignorirovavshiesya
v  modelyah, ne  byli  sushchestvennymi svojstvami yavlenij. I  eto ne dejstvuet,
kogda slozhnosti yavlyayutsya sushchnost'yu.
     Mnogie  klassicheskie  trudnosti   razrabotki  programmnogo  obespecheniya
proistekayut ih etoj slozhnosti sushchnosti i ee nelinejnogo rosta pri uvelichenii
razmera.  Slozhnost'  sluzhit  prichinoj  trudnosti   processa   obshcheniya  mezhdu
uchastnikami  brigady  razrabotchikov,   chto  vedet  k   oshibkam  v  produkte,
prevysheniyu  stoimosti  razrabotki, zatyagivaniyu  vypolneniya  grafikov  rabot.
Slozhnost' sluzhit prichinoj  trudnosti perechisleniya, a  tem  bolee  ponimaniya,
vseh  vozmozhnyh sostoyanij programmy, a  otsyuda  voznikaet  ee  nenadezhnost'.
Slozhnost'  funkcij  sluzhit prichinoj  trudnostej  pri ih vyzove,  iz-za  chego
programmami  trudno   pol'zovat'sya.  Slozhnost'  struktury  sluzhit   prichinoj
trudnostej pri razvitii  programm i dobavlenii novyh  funkcij tak,  chtoby ne
voznikali   pobochnye   effekty.   Slozhnost'  struktury   sluzhit   istochnikom
nevizualizuemyh sostoyanij, v kotoryh narushaetsya sistema zashchity.
     Slozhnost' sluzhit prichinoj ne  tol'ko tehnicheskih, no i administrativnyh
problem. Iz-za slozhnosti trudno osushchestvlyat' nadzor, a v rezul'tate stradaet
konceptual'naya  celostnost'.  Trudno  najti  i  derzhat'  pod  kontrolem  vse
svobodnye koncy.  Obuchenie  i ponimanie  stanovitsya kolossal'noj  nagruzkoj,
iz-za chego tekuchest' rabochej sily prevrashchaetsya v katastrofu.
     Soglasovannost'.  Lyudi,  svyazannye  s programmirovaniem,  ne odinoki  v
problemah slozhnosti.  Fizika imeet  delo s  ob®ektami chrezvychajnoj slozhnosti
dazhe  na  urovne  elementarnyh  chastic.  Odnako  fizik  rabotaet  v  tverdoj
uverennosti, chto mozhno najti obshchie principy, bud' to kvarki ili obshchaya teoriya
polya. |jnshtejn neodnokratno  utverzhdal,  chto  priroda  dolzhna imet'  prostye
ob®yasneniya, poskol'ku Bogu ne svojstvenny kapriznost' i proizvol.
     U  razrabotchika  programmnogo  obespecheniya net takoj uteshitel'noj very.
Slozhnost',  s  kotoroj  on  dolzhen  sovladat',  po  bol'shej  chasti  yavlyaetsya
proizvol'noj,   neobosnovanno   vyzvannoj    mnogochislennymi   chelovecheskimi
ustanovleniyami i  sistemami,  kotorym  dolzhny  udovletvorit' ego interfejsy.
Sistemy  razlichayutsya   interfejsami   i  menyayutsya   vo  vremeni  ne  v  silu
neobhodimosti, a lish' potomu, chto byli sozdany ne Bogom, a raznymi lyud'mi.
     Vo  mnogih  sluchayah  programmnoe  obespechenie  dolzhno  soglasovyvat'sya,
poskol'ku  tol'ko  chto poyavilos'  na  scene.  V  drugih  sluchayah  ono dolzhno
soglasovyvat'sya, poskol'ku est' oshchushchenie, chto ego  legche  vsego soglasovat'.
No vo vseh sluchayah znachitel'naya chast' slozhnosti proishodit ot soglasovaniya s
drugimi  interfejsami,  i  eto  nevozmozhno  uprostit'  tol'ko  v  rezul'tate
pereproektirovaniya programmnogo obespecheniya.
     Izmenyaemost'.  Programmnye  ob®ekty  postoyanno  podverzheny  izmeneniyam.
Konechno,  eto   otnositsya  i   k  zdaniyam,  avtomobilyam,   komp'yuteram.   No
proizvedennye  veshchi  redko  podvergayutsya  izmeneniyam  posle izgotovleniya. Ih
zamenyayut  novye modeli, ili sushchestvennye izmeneniya vklyuchayut v bolee  pozdnie
serijnye  ekzemplyary  togo  zhe  bazovogo  proekta.   Otzyvy  u  potrebitelej
avtomobilej na  praktike  vstrechayutsya  ves'ma  redko, a izmeneniya rabotayushchih
komp'yuterov  eshche  rezhe.   To  i   drugoe  sluchaetsya  znachitel'no  rezhe,  chem
modifikaciya rabotayushchego programmnogo obespecheniya.
     Otchasti  eto  proishodit potomu, chto programmnoe obespechenie v  sisteme
voploshchaet ee naznachenie, a naznachenie bolee vsego oshchushchaet vliyanie izmenenij.
Otchasti  eto proishodit potomu, chto programmnoe  obespechenie legche izmenit':
eto chistaya mysl',  beskonechno podatlivaya.  Zdaniya tozhe  perestraivayutsya,  no
priznavaemaya vsemi vysokaya stoimost' izmenenij umeryaet kaprizy novatorov.
     Vse  udachnye  programmnye  produkty  podvergayutsya izmeneniyam. Pri  etom
dejstvuyut  dva  processa.  Vo-pervyh,   kak  tol'ko   obnaruzhivaetsya  pol'za
programmnogo produkta,  nachinayutsya  popytki  primeneniya ego  na grani ili za
predelami  pervonachal'noj oblasti. Trebovanie  rasshireniya funkcij ishodit, v
osnovnom,  ot pol'zovatelej,  kotorye  udovletvoreny osnovnym naznacheniem  i
izobretayut dlya nego novye primeneniya.
     Vo-vtoryh,  udachnyj  programmnyj  produkt zhivet dol'she  obychnogo  sroka
sushchestvovaniya mashiny, dlya kotoroj on pervonachal'no byl sozdan. Prihodyat esli
ne  novye  komp'yutery,  to novye  diski, novye  monitory, novye printery,  i
programma dolzhna byt' soglasovana s vozmozhnostyami novyh mashin.
     Koroche, programmnyj  produkt  vstroen  v kul'turnuyu matricu prilozhenij,
pol'zovatelej, zakonov i mashin. Vse oni nepreryvno menyayutsya, i  ih izmeneniya
neizbezhno trebuyut izmeneniya programmnogo produkta.
     Nezrimost'. Programmnyj produkt nevidim i nevizualizuem. Geometricheskie
abstrakcii yavlyayutsya moshchnym instrumentom. Plan zdaniya pomogaet  arhitektoru i
zakazchiku ocenit' prostranstvo,  vozmozhnosti  peremeshcheniya,  vidy. Stanovyatsya
ochevidnymi   protivorechiya,  mozhno  zametit'   upushcheniya.  Masshtabnye  chertezhi
mehanicheskih detalej  i ob®emnye modeli molekul, buduchi abstrakciyami, sluzhat
toj  zhe  celi.  Geometricheskaya   real'nost'  shvatyvaetsya  v  geometricheskoj
abstrakcii.
     Real'nost'  programmnogo  obespecheniya   ne  vstraivaetsya   estestvennym
obrazom  v  prostranstvo.   Poetomu  u  nego  net  gotovogo  geometricheskogo
predstavleniya podobno tomu, kak mestnost'  predstavlyaetsya kartoj, kremnievye
mikroshemy -  diagrammami, komp'yutery - shemami  soedinenij.  Kak tol'ko  my
pytaemsya  graficheski predstavit'  strukturu  programmy, my obnaruzhivaem, chto
trebuetsya ne odin, a neskol'ko neorientirovannyh grafov, nalozhennyh odin  na
drugoj.  Neskol'ko  grafov  mogut  predstavlyat' upravlyayushchie  potoki,  potoki
dannyh,  shemy  zavisimostej,  vremennyh   posledovatel'nostej,  sootnoshenij
prostranstva  imen.  Obychno  oni  dazhe  ne  yavlyayutsya  ploskimi,  ne  to  chto
ierarhicheskimi.  Na  praktike odnim iz sposobov ustanovleniya konceptual'nogo
kontrolya  nad takoj  strukturoj yavlyaetsya  obrezanie svyazej  do teh por, poka
odin ili neskol'ko grafov ne stanut ierarhicheskimi.2
     Nesmotrya na  progress,  dostignutyj v  ogranichenii i uproshchenii struktur
programmnogo  obespecheniya, oni  ostayutsya nevizualizuemymi po svoej  prirode,
tem samym  lishaya nas  odnogo  iz  naibolee moshchnyh  instrumentov operirovaniya
koncepciyami. |tot  nedostatok  ne tol'ko zatrudnyaet  individual'nyj  process
proektirovaniya, no i ser'ezno zatrudnyaet obshchenie mezhdu razrabotchikami.
     Prezhnie proryvy razreshili vtorostepennye trudnosti
     Esli  rassmotret'  tri  naibolee  plodotvornyh  shaga  v  proizoshedshem
razvitii programmnyh tehnologij, to obnaruzhitsya,  chto vse oni byli sdelany v
napravlenii resheniya  razlichnyh krupnyh problem  razrabotki programm, no  eti
problemy zatragivali vtorostepennye, a  ne otnosyashchiesya k sushchnosti trudnosti.
Mozhno takzhe videt' estestvennye predely  ekstrapolirovaniya kazhdogo  ih  etih
napravlenij.
     YAzyki  vysokogo   urovnya.   Konechno,  naibol'shee  znachenie   dlya  rosta
proizvoditel'nosti,   nadezhnosti   i   prostoty  imelo  vse   bolee  shirokoe
ispol'zovanie yazykov vysokogo  urovnya.  Bol'shinstvo  issledovatelej schitaet,
chto etim byl dostignut, po krajnej mere, pyatikratnyj rost proizvoditel'nosti
pri odnovremennom vyigryshe v nadezhnosti, prostote i legkosti ponimaniya.
     CHto  delaet   yazyk   vysokogo  urovnya?  On   osvobozhdaet  programmu  ot
znachitel'noj doli neobyazatel'noj slozhnosti. Abstraktnaya programma sostoit iz
konceptual'nyh  konstrukcij: operacij,  tipov dannyh,  posledovatel'nostej i
svyazi.   Konkretnaya   mashinnaya  programma  svyazana  s   bitami,  registrami,
usloviyami,  perehodami, kanalami,  diskami i prochim. V  toj mere, v  kakoj v
yazyke   vysokogo   urovnya  voploshcheny   neobhodimye   abstraktnoj   programme
konstrukcii  i izbegayutsya konstrukcii nizshego  poryadka, on likvidiruet celyj
uroven' slozhnosti, sovershenno ne yavlyayushchijsya neobhodimym svojstvom programmy.
     Samoe  bol'shee,  chto  mozhet  sdelat'   yazyk  vysokogo  urovnya,   -  eto
predostavit'  vse  konstrukcii, kotorye  po  zamyslu  programmista  soderzhit
abstraktnaya programma.  Konechno, uroven' utonchennosti nashih  predstavlenij o
strukturah dannyh, tipah dannyh i operaciyah neuklonno rastet, no s postoyanno
ubyvayushchej  skorost'yu. I  yazyki v  svoem razvitii  vse  bol'she priblizhayutsya k
izoshchrennosti nashego myshleniya.
     Bolee togo, s nekotorogo  momenta dal'nejshaya razrabotka yazykov vysokogo
urovnya stanovitsya  obuzoj,  oslozhnyayushchej, a  ne  uproshchayushchej  intellektual'nye
zadachi pol'zovatelya, redko ispol'zuyushchego ezotericheskie konstrukcii.
     Razdelenie vremeni.  Bol'shinstvo issledovatelej schitaet, chto  blagodarya
rabote v rezhime razdeleniya vremeni proizoshel bol'shoj rost proizvoditel'nosti
truda programmistov i kachestva sozdavaemyh programmnyh produktov, hotya i  ne
takoj znachitel'nyj, kak vyzvannyj ispol'zovaniem yazykov vysokogo urovnya.
     Razdelenie  vremeni pomogaet  reshit'  sovsem  druguyu  zadachu. Blagodarya
razdeleniyu vremeni obespechivaetsya bezotlagatel'nost',  i potomu  vozmozhnost'
imet'  obshchee vpechatlenie o  slozhnosti.  Iz-za medlennoj  oborachivaemosti pri
paketnoj obrabotke my neizbezhno zabyvaem  melochi, esli  ne samoe napravlenie
nashej  mysli,  v  tot  moment,  kogda my prervalis' i  nachali  kompilyaciyu  i
vypolnenie  programmy.  |tot   obryv  mysli  dorogo  obhoditsya  po  vremeni,
poskol'ku prihoditsya vosstanavlivat' ee v pamyati.  V  hudshem  sluchae,  mozhno
voobshche poteryat' predstavlenie o tom, chto proishodit so slozhnoj sistemoj.
     Medlennaya  oborachivaemost', kak i slozhnosti mashinnyh  yazykov,  yavlyaetsya
vtorostepennoj,  a  ne  sushchestvennoj  trudnost'yu  processa programmirovaniya.
Predel'nyj    vklad,    vnosimyj     razdeleniem    vremeni,    opredelyaetsya
neposredstvenno.  Glavnoe - eto  sokratit'  vremya  otklika sistemy. Po  mere
priblizheniya  ego  k  nulyu,  ono  perehodit   porog   skorosti  chelovecheskogo
vospriyatiya,  sostavlyayushchej  okolo  100  millisekund.  Dal'she  nikakoj  vygody
poluchit' uzhe nel'zya.
     Ob®edinennye sredy programmirovaniya.  Schitaetsya, chto  Unix i Interlisp,
pervye  shiroko  rasprostranennye  integrirovannye  sredy   programmirovaniya,
povysili proizvoditel'nost' v neskol'ko raz. Pochemu?
     Oni napravleny  na  preodolenie  vtorostepennyh  trudnostej sovmestnogo
ispol'zovaniya  programm putem ispol'zovaniya obshchih bibliotek, unificirovannyh
formatov fajlov,  kanalov i fil'trov. V rezul'tate konceptual'nye struktury,
kotorye,  v   principe,   vsegda  mogut  vyzyvat',  obmenivat'sya  dannymi  i
ispol'zovat' drug druga, poluchayut vozmozhnost' osushchestvlyat' eto prakticheski.
     |to  dostizhenie,  v   svoyu   ochered',   stimulirovalo  razvitie   celyh
instrumental'nyh naborov, poskol'ku vsyakij novyj instrument mog  primenyat'sya
k lyubym programmam, ispol'zuya standartnye formaty.
     Blagodarya  etim uspeham  sredy programmirovaniya stali predmetom  mnogih
segodnyashnih  issledovanij v programmnoj inzhenerii. V sleduyushchem paragrafe  my
rassmotrim, chto ot nih mozhno ozhidat', i kakie im prisushche ogranicheniya.
     Nadezhdy na serebro
     Rassmotrim  teper'  te  tehnicheskie  dostizheniya,  kotorye chashche  vsego
vydvigayutsya  kandidatami  na  rol'  serebryanoj  puli.  K kakim  zadacham  oni
obrashchayutsya? Zadacham, otnosyashchimsya k sushchnosti,  ili ostatkam nashih akcidentnyh
slozhnostej?   Predlagayut  li  oni  revolyucionnoe   razvitie   ili  poshagovoe
prodvizhenie?
     Ada i  drugie dostizheniya  yazykov  vysokogo  urovnya.  Odnim iz  naibolee
reklamiruemyh dostizhenij  poslednego vremeni yavlyaetsya  yazyk programmirovaniya
Ada  - yazyk vysokogo urovnya obshchego naznacheniya  80-h godov. Ada dejstvitel'no
ne  tol'ko otrazhaet evolyucionnoe razvitie  koncepcij yazykov,  no i voploshchaet
cherty,   podderzhivayushchie  sovremennye  idei   proektirovaniya  i  modul'nosti.
Vozmozhno,  bol'shim  dostizheniem  yavlyaetsya ne yazyk Ada,  a  filosofiya Ada kak
filosofiya    modul'nosti,    abstraktnyh    tipov   dannyh,   ierarhicheskogo
strukturirovaniya. Ada, pozhaluj peregruzhen vozmozhnostyami, buduchi estestvennym
produktom  processa,   porodivshego   trebovaniya,  polozhennye  v  osnovu  ego
razrabotki. |to ne smertel'no, poskol'ku podmnozhestva rabochih slovarej mogut
reshit' problemu izucheniya, a progress  elektroniki  dast nam deshevye milliony
operacij    v    sekundu,    reshayushchie    problemu    kompilyacii.    Razvitie
strukturirovannosti programmnyh  sistem -  eto  ochen' horoshee primenenie dlya
deneg,  kotorye   my  tratim  na  priobretenie  vse  bol'shih  vychislitel'nyh
moshchnostej.  Operacionnye  sistemy,  gromko  osuzhdavshiesya  v  60-h  godah  za
dorogoviznu  pamyati  i  vychislenij,  okazalis'  horoshim sposobom  primeneniya
bystrodejstviya i deshevoj pamyati,  poluchennyh  v rezul'tate bystrogo razvitiya
apparatnyh sredstv.
     Tem ne menee Ada ne stanet toj serebryanoj pulej, kotoraya ulozhit monstra
nizkoj  proizvoditel'nosti  proizvodstva  programmnogo obespecheniya.  V konce
koncov eto vsego lish' eshche  odin yazyk vysokogo urovnya, a samuyu bol'shuyu otdachu
ot  primeneniya  takih  yazykov   my  uzhe  poluchili  pri  pervom  perehode  ot
vtorostepennoj  slozhnosti mashin  k bolee abstraktnoj formulirovke  poshagovyh
reshenij.  Posle  ustraneniya  teh akcidencij  ostalis' menee  sushchestvennye, i
vygody ot ih ustraneniya budet, konechno, men'she.
     YA predvizhu,  chto  cherez  desyatiletie, kogda  ocenyat  effektivnost' Ada,
budet priznan  znachitel'nyj vklad  etogo yazyka, no  ne blagodarya  kakoj-libo
otdel'noj ego  vozmozhnosti i  dazhe ne blagodarya im vsem  vmeste  vzyatym.  Ne
stanut  prichinoj uspehov i  novye sredy programmirovaniya na Ada.  Naibol'shim
vkladom Ada  yavitsya to, chto perehod  na etot yazyk posluzhit prichinoj izucheniya
programmistami sovremennyh metodov proektirovaniya programmnogo obespecheniya.
     Ob®ektno-orientirovannoe  programmirovanie. Mnogie, izuchayushchie iskusstvo
programmirovaniya,  svyazyvayut  s  ob®ektno-orientirovannym  programmirovaniem
bol'she nadezhd, chem  s lyubymi drugimi sovremennymi tehnicheskimi uvlecheniyami.3
YA  prinadlezhu k ih chislu. Mark SHerman (Mark Sherman)  iz Dartmuta  zamechaet,
chto sleduet provodit' otlichie mezhdu dvumya raznymi ideyami, figuriruyushchimi  pod
etim nazvaniem:  abstraktnyh tipov dannyh i ierarhicheskih  tipov, nazyvaemyh
takzhe klassami. Ponyatie abstraktnogo  tipa  dannyh  sostoit  v tom, chto  tip
ob®ekta  opredelyaetsya  imenem, mnozhestvom dopustimyh  znachenij i  mnozhestvom
dopustimyh operacij, a ne organizaciej hraneniya, kotoraya dolzhna byt' skryta.
Primerami  yavlyayutsya  pakety Ada  (s  zashchishchennymi  tipami) i moduli  v  yazyke
Modula.
     Ierarhicheskie  tipy,  takie  klassy  v Simula-67,  pozvolyayut opredelyat'
obshchie interfejsy,  kotorye v dal'nejshem mozhno utochnyat' s pomoshch'yu podchinennyh
tipov. |ti  dve  koncepcii ortogonal'ny:  mogut  byt'  otkrytye  ierarhii  i
skrytie bez  ierarhij.  Obe  koncepcii dejstvitel'no  yavlyayutsya dostizheniem v
iskusstve programmirovaniya.
     Kazhdaya  iz nih  ustranyaet eshche  odnu vtorostepennuyu  slozhnost', pozvolyaya
razrabotchiku vyrazit'  sushchnost'  svoego  proekta  bez ispol'zovaniya bol'shogo
kolichestva sintaksicheskogo materiala, ne dobavlyayushchego novogo informacionnogo
soderzhaniya.  Ispol'zovanie  kak  abstraktnyh,   tak  i  ierarhicheskih  tipov
ustranyaet  vtorostepennye  trudnosti  bolee  vysokogo  poryadka  i  pozvolyaet
vyrazit' proekt na bolee vysokom urovne.
     I vse zhe takie dostizheniya mogut  ne bolee chem  ustranit' vtorostepennye
trudnosti pri  vyrazhenii proekta. Sushchestvenna  slozhnost' samogo proekta,  na
chto reshenie  takih  zadach  nikak  ne mozhet  povliyat'.  Dobit'sya vyigrysha  na
poryadok velichin  s pomoshch'yu  ob®ektno-orientirovannogo programmirovaniya mozhno
lish'  v tom sluchae,  esli ostayushchayasya  segodnya v nashem yazyke programmirovaniya
neobyazatel'naya rabota  po  specifikacii  tipov sama po sebe otvetstvenna  za
9/10 usilij, zatrachivaemyh na proektirovanie programmnogo produkta. V etom ya
ne somnevayus'.
     Iskusstvennyj   intellekt.  Mnogie  ozhidayut,  chto   uspehi  v   oblasti
iskusstvennogo  intellekta  pozvolyat  osushchestvit'  revolyucionnyj  perevorot,
kotoryj prineset rost proizvoditel'nosti razrabotki programmnogo obespecheniya
i ego kachestva na poryadki velichin.4 YA etogo ne  zhdu. CHtoby  uvidet', pochemu,
razberem, chto ponimaetsya pod "iskusstvennym intellektom", a zatem posmotrim,
kakie vozmozhny primeneniya.
     Parnas vnes yasnost' v terminologicheskij haos:
     Segodnya   v  hodu   dva  sovershenno  raznyh   opredeleniya   II.   II-1:
ispol'zovanie  komp'yuterov dlya  resheniya  zadach,  kotorye  ran'she  mogli byt'
resheny  tol'ko  s  pomoshch'yu  chelovecheskogo  intellekta.  II-2:  ispol'zovanie
special'nyh  priemov  programmirovaniya,  izvestnyh  kak  evristicheskoe,  ili
osnovannoe na pravilah, programmirovanie. Pri takom podhode izuchayut dejstviya
ekspertov, chtoby opredelit', kakimi evristikami i prakticheskim pravilami oni
pol'zuyutsya pri reshenii zadach...  Programma  korrektiruetsya dlya resheniya zadach
tak, kak, po-vidimomu, ee reshaet chelovek.
     U pervogo opredeleniya skol'zkij smysl... Koe-chto ukladyvaetsya segodnya v
opredelenie II-1, no kak tol'ko my vidim rabotu programmy i ponimaem zadachu,
my  uzhe  ne  dumaem o nej, kak o II... K neschast'yu, ya  ne vizhu yadra metodov,
kotorye   unikal'ny    v   etoj   oblasti...   Po   bol'shej   chasti   metody
problemno-orientirovanny, i dlya ih perenosa trebuyutsya izvestnye abstrakciya i
tvorchestvo.5
     YA  polnost'yu  soglasen  s  etoj  kritikoj.   Priemy,  ispol'zuemye  dlya
raspoznavaniya  rechi,  vykazyvayut  malo  shodstva  s  metodami  raspoznavaniya
izobrazhenij, pri etom v ekspertnyh sistemah ispol'zuyutsya metody, otlichnye ot
teh  i drugih. YA zatrudnyayus' skazat', k primeru, kakoe vliyanie raspoznavanie
izobrazhenij   mozhet  okazat'  na   metody  programmirovaniya.   To  zhe  samoe
spravedlivo v otnoshenii raspoznavaniya  rechi. Pri razrabotke programm  trudno
reshit', chto  imenno  skazat',  a ne  sobstvenno skazat'. Nikakoe  oblegchenie
vyrazheniya ne mozhet dat' bol'she, chem neznachitel'nye vygody.
     Metody ekspertnyh sistem II-2 zasluzhivayut otdel'nogo paragrafa.
     |kspertnye sistemy.  Naibolee  razvitoj  i  shiroko  primenyaemoj  chast'yu
iskusstvennogo  intellekta  yavlyayutsya  ekspertnye sistemy.  Mnogie  uchenye  v
oblasti programmirovaniya napryazhenno trudyatsya nad primeneniem etoj tehnologii
v sredah razrabotki programmnogo obespecheniya.5 V chem sostoit ideya,  i kakovy
perspektivy?
     |kspertnaya  sistema -  eto  programma, soderzhashchaya  obobshchennyj generator
vyvodov i bazu pravil, prednaznachennuyu dlya priema vhodnyh dannyh i dopushchenij
i  issledovaniya logicheskih sledstvij cherez  zaklyucheniya,  vyvodimye  iz  bazy
pravil,   predostavlyayushchaya   zaklyucheniya   i   rekomendacii   i   predlagayushchaya
pol'zovatelyu ob®yasnenie poluchennyh rezul'tatov putem obratnogo proslezhivaniya
svoih rassuzhdenij. Pomimo chisto  determinirovannoj logiki, generator vyvodov
obychno mozhet rabotat' s nechetkimi ili veroyatnostnymi dannymi.
     Takie  sistemy   predostavlyayut  nekotorye  yavnye   preimushchestva   pered
zaprogrammirovannymi algoritmami resheniya teh zhe zadach:
     -   Tehnologiya   generatora  vyvodov  razrabatyvaetsya   nezavisimo   ot
primeneniya i ispol'zuetsya zatem vo mnogih prilozheniyah.
     - Izmenyaemye  chasti  specificheskih  dlya prilozheniya  dannyh edinoobrazno
kodiruyutsya v baze  pravil.  Obespechivaetsya  instrumentarij  dlya  razrabotki,
izmeneniya, proverki  i  dokumentirovaniya  bazy pravil.  |tim uporyadochivaetsya
znachitel'naya chast' slozhnosti samogo prilozheniya.
     |dvard Fejgenbaum (Edward Feigenbaum) schitaet,  chto  moshch'  takih sistem
rastet ne blagodarya sovershenstvovaniyu mehanizmov vyvoda, a skoree, blagodarya
popolneniyu bazy znanij,  vse  bolee tochno otrazhayushchej real'nyj mir. YA schitayu,
chto  samoe vazhnoe dostizhenie etoj  tehnologii sostoit v razdelenii slozhnosti
prilozheniya i samoj programmy.
     Kak  mozhno  ispol'zovat' ekspertnye sistemy pri  sozdanii  programmnogo
obespecheniya?   Razlichnymi   sposobami:   predlozhenie   pravil   interfejsov,
rekomendacii po  strategii otladki, zapominanie chastoty oshibok kazhdogo tipa,
podskazki po optimizacii i t.p.
     Predstavim  sebe,  k  primeru, nekoego  sovetchika  po otladke.  V samoj
zachatochnoj  forme   diagnosticheskaya  ekspertnaya  sistema  ves'ma  napominaet
pamyatku pilota, po suti, delaya  predpolozheniya otnositel'no vozmozhnyh  prichin
zatrudnenij.  Po mere  razvitiya bazy pravil predpolozheniya  stanovyatsya  bolee
specifichnymi,  bolee izoshchrenno uchityvaya simptomy problemy. Mozhno predstavit'
takogo  pomoshchnika predlagayushchim snachala  samye  obshchie resheniya,  no,  po  mere
voploshcheniya v baze pravil vse  bol'shej chasti struktury sistemy, stanovyashchegosya
vse bolee razborchivym v generiruemyh gipotezah  i predlagaemyh testah. Takaya
ekspertnaya sistema mozhet  reshitel'no otlichat'sya ot  obychnyh tem, chto ee baza
pravil,  veroyatno,  dolzhna  byt' ierarhicheski  razbita  na  moduli takim  zhe
obrazom,  kak  sootvetstvuyushchij  programmnyj produkt. Poetomu  pri  izmenenii
modul'noj  struktury  produkta izmenyaetsya  takzhe  modul'naya  struktura  bazy
diagnosticheskih pravil.
     Rabota,  kotoruyu  neobhodimo  prodelat'  dlya  sozdaniya  diagnosticheskih
pravil, v lyubom sluchae dolzhna byt' provedena pri sozdanii nabora kontrol'nyh
primerov  dlya  modulej  i  dlya  sistemy.  Esli eto delat'  dostatochno  obshchim
obrazom, s edinoobraznoj strukturoj pravil i pri nalichii horoshego generatora
vyvodov,  to  mozhno  dejstvitel'no  sokratit'   ob®em  rabot  pri  generacii
kontrol'nyh  primerov,  a  takzhe  pozhiznennom  soprovozhdenii  i testirovanii
modifikacij. Takie zhe usloviya  my mozhem postavit' i dlya  drugih  sovetchikov,
ispol'zuemyh dlya drugih uchastnikov zadachi sozdaniya  programmy. Vozmozhno, oni
budut mnogochislenny i inogda prosty.
     Na  puti   rannej   realizacii   poleznyh   ekspertnyh  sovetnikov  dlya
razrabotchika  programmy  stoit mnogo  prepyatstvij.  Reshayushchej  chast'yu  nashego
voobrazhaemogo scenariya  yavlyaetsya razrabotka  prostyh  sposobov  perehoda  ot
zadaniya  struktury   programmy  k  avtomaticheskomu  ili  poluavtomaticheskomu
sozdaniyu diagnosticheskih pravil. Eshche bolee slozhnoj i vazhnoj yavlyaetsya dvojnaya
zadacha priobreteniya  znanij: najti chlenorazdel'no vyrazhayushchihsya i sposobnyh k
samoanalizu ekspertov, ponimayushchih, pochemu oni delayut to ili drugoe dejstvie,
i razrabotat' effektivnye metody  izvlecheniya ih znanij i  prevrashcheniya v bazy
pravil. CHtoby postroit' ekspertnuyu sistemu, neobhodimo imet' eksperta.
     Naibol'shim vkladom ekspertnyh sistem, nesomnenno,  budet predostavlenie
neopytnomu   programmistu   opyta   i   vseh  znanij,   nakoplennyh  luchshimi
programmistami. I  eto  ne  malo. Razryv mezhdu  luchshimi i  srednimi priemami
programmirovaniya  ochen'  velik, vozmozhno,  on bol'she,  chem  v  lyuboj  drugoj
inzhenernoj discipline. Poetomu sredstvo rasprostraneniya horoshih priemov bylo
by ochen' vazhnym.
     "Avtomaticheskoe" programmirovanie.  Pochti 40 let  lyudi  zhdut i pishut ob
"avtomaticheskom  programmirovanii" - generacii  reshayushchej  zadachu  programmy,
ishodya iz formulirovki specifikacii  etoj  zadachi.  Nekotorye  vyskazyvayutsya
segodnya tak, budto ozhidayut ot etoj tehnologii gryadushchego perevorota.7
     Parnas predpolagaet,  chto termin ispol'zuetsya  iz-za effektnosti, a  ne
semanticheskogo soderzhaniya, utverzhdaya:
     Koroche,  avtomaticheskoe  programmirovanie  vsegda  bylo evfemizmom  dlya
programmirovaniya  na yazyke bolee vysokogo urovnya, chem dostupnyj programmistu
v dannyj moment.8
     On  utverzhdaet, v  sushchnosti, chto v  bol'shinstve  sluchaev  nuzhno  zadat'
specifikaciyu ne zadachi, a metoda resheniya.
     Mozhno otyskat' isklyucheniya.  Metod sozdaniya  generatorov  yavlyaetsya ochen'
moshchnym  i  povsednevno  s  pol'zoj  primenyaetsya  v   programmah  sortirovki.
Nekotorye sistemy integrirovaniya differencial'nyh  uravnenij takzhe pozvolyali
pryamuyu formulirovku zadachi. Sistema proizvodila  ocenku parametrov, vybirala
iz biblioteki metody resheniya i generirovala programmy.
     U etih primenenij est' svojstva, blagopriyatstvuyushchie avtomatizacii:
     - Problemy legko opisyvayutsya sravnitel'no nebol'shim chislom parametrov.
     -  Izvestno mnogo metodov resheniya, chto obespechivaet nalichie  biblioteki
al'ternativ.
     -  Tshchatel'nyj analiz  privel k  vyrabotke yavnyh  pravil vybora  metodov
resheniya v zavisimosti ot parametrov.
     Edva  li  vozmozhno   obobshchenie  takih  metodov  na  ves'   mir  obychnyh
programmnyh  sistem,  v  kotorom  situaciya  s  takimi  priyatnymi  svojstvami
yavlyayutsya  isklyucheniyami.  Trudno  dazhe  predstavit' sebe,  kak takoj proryv v
obobshchenii mog by proizojti razumnym obrazom.
     Graficheskoe programmirovanie. Izlyublennoj temoj doktorskih  dissertacij
v   programmnoj    inzhenerii    yavlyaetsya   graficheskoe,   ili    vizual'noe,
programmirovanie - primenenie komp'yuternoj grafiki v razrabotke programmnogo
obespecheniya.9 Inogda perspektivy takogo  podhoda osnovyvayutsya na  analogii s
proektirovaniem SBIS, v kotorom komp'yutery igrayut takuyu bol'shuyu rol'. Inogda
takoj  podhod  obosnovyvaetsya,  ishodya  iz  togo,  chto  blok-shemy  yavlyayutsya
ideal'nym  materialom  pri proektirovanii programm. Imeyutsya  moshchnye sredstva
dlya sozdaniya takih blok- shem.
     Nichego ubeditel'nogo i udivitel'nogo iz etih popytok poka ne vyshlo, - i
ya uveren, ne vyjdet.
     Vo-pervyh,  kak  ya vsyudu dokazyvayu,  blok-shema yavlyaetsya  ves'ma slaboj
abstrakciej struktury programmy.10  Luchshe vsego eto vidno iz popytok Berksa,
fon Nejmana  i Gol'dstajna  snabdit'  svoj predpolagaemyj  komp'yuter  krajne
neobhodimym upravlyayushchim yazykom vysokogo urovnya. V  tom zhalkom vide -  mnogie
stranicy   soedinennyh   liniyami  pryamougol'nikov,  -   v  kotorom   segodnya
razrabatyvayutsya blok-shemy,  oni dokazali,  v sushchnosti, svoyu  bespoleznost':
programmisty risuyut ih posle, a ne do sozdaniya opisyvaemyh imi programm.
     Vo-vtoryh,  segodnyashnie  ekrany  imeyut  slishkom  malo  pikselov,  chtoby
pokazat'  celikom i s dostatochnym razresheniem skol'ko-nibud' podrobnuyu shemu
programmy. Tak  nazyvaemaya "metafora rabochego  stola"  stanovitsya  metaforoj
"siden'ya  samoleta". Vsyakij,  komu prihodilos'  listat' pachku bumag,  buduchi
stisnutym  dvumya korpulentnymi  sosedyami, pochuvstvuet  raznicu: odnovremenno
mozhno  uvidet' ochen' nemnogo. Nastoyashchij rabochij stol pozvolyaet  obozrevat' i
proizvol'no  vybirat' mnozhestvo bumag.  Bolee togo, v poryve  tvorchestva  ne
odin programmist ili pisatel' predpochital rabochemu stolu bolee vmestitel'nyj
pol.   Apparatnym   tehnologiyam  nuzhno  sdelat'  ochen'  bol'shoj  nag,  chtoby
predostavlyaemyj  ekranami  obzor  byl  dostatochnym dlya zadach  proektirovaniya
programm.
     Esli  obratit'sya  k  osnovam,  programmnoe  obespechenie  ochen'   trudno
vizualizirovat',  kak  ya  dokazyval  eto  vyshe.  Sostavlyaem   li  my   shemy
upravlyayushchej logiki, vlozhennyh oblastej,  vidimosti peremennyh,  perekrestnyh
ssylok peremennyh, potokov dannyh, ierarhicheskih struktur dannyh ili chego-to
eshche,  oni otrazhayut lish' odno izmenenie  vzaimodejstvuyushchih zaputannym obrazom
chastej  programmnoj  sistemy.  Esli  nalozhit'  odna  na  druguyu  eti  shemy,
otrazhayushchie  vzglyad  s  razlichnyh  tochek  zreniya,  trudno  izvlech'  iz  etogo
kakuyu-libo  obshchuyu tochku zreniya.  Analogiya s integral'nymi shemami vvodit,  v
sushchnosti,   v   zabluzhdenie:   konstrukciya  mikroshemy  predstavlyaet   soboj
mnogoslojnyj  dvumernyj  ob®ekt,   geometriya   kotorogo  otrazhaet  sushchnost'.
Programmnaya sistema ne yavlyaetsya takim ob®ektom.
     Verifikaciya  programm.   Mnogo  truda  v  sovremennom  programmirovanii
tratitsya  na  otladku i ispravlenie oshibok. Mozhet byt', my najdem serebryanuyu
pulyu,   ustraniv   vse  oshibki  v   samom  nachale,   na   etape   sistemnogo
proektirovaniya? Mozhno li radikal'no povysit' proizvoditel'nost' i nadezhnost'
produkta, esli sledovat' sovershenno inoj strategii - obespechit' korrektnost'
proekta,  prezhde   chem   tratit'   ogromnye  usiliya  na   ego  realizaciyu  i
testirovanie?
     Ne dumayu, chto my obnaruzhim zdes' chudesa.  Verifikaciya programm yavlyaetsya
ochen'  moshchnoj koncepciej, i ona ochen' vazhna  dlya  takih veshchej,  kak sozdanie
nadezhnogo yadra  operacionnoj sistemy.  |ta  tehnologiya ne  obeshchaet,  odnako,
ekonomii  truda. Verifikaciya  trebuet stol'ko  raboty,  chto  ves'ma nemnogie
znachitel'nye programmy voobshche byli verificirovany.
     Verifikaciya programm ne oznachaet sozdaniya programm,  lishennyh oshibok. I
zdes' net  chudes. Matematicheskie  dokazatel'stva tozhe mogut byt' oshibochnymi.
Poetomu hotya verifikaciya mozhet oblegchit' testirovanie, ona ne mozhet otmenit'
ego.
     Bolee  sushchestvenno,  chto dazhe  samaya sovershennaya  verifikaciya programmy
mozhet  lish'  opredelit',  chto programma otvechaet svoim specifikaciyam.  Samaya
slozhnaya   zadacha  programmirovaniya  -  poluchit'  polnuyu  i  neprotivorechivuyu
specifikaciyu, i sushchnost'  sozdaniya programmy na praktike vo mnogom sostoit v
otladke specifikacii.
     Sredy programmirovaniya i instrumenty. Kakogo eshche vyigrysha mozhno ozhidat'
ot  stremitel'no  rasshiryayushchihsya  issledovanij   po  usovershenstvovaniyu  sred
programmirovaniya?   Instinktivno   kazhetsya,  chto   zadachi,   kotorye  sulili
naibol'shuyu otdachu, byli v chisle pervyh, za kotorye vzyalis', i ih uzhe reshili:
ierarhicheskie fajlovye sistemy, edinoobraznye formaty  fajlov  dlya polucheniya
edinoobraznyh    programmnyh   interfejsov    i   obobshchennyh   instrumentov.
Orientirovannye na konkretnye yazyki intellektual'nye redaktory poka ne ochen'
rasprostraneny,   no   bol'shee,   na  chto  oni   sposobny,  eto   ustranenie
sintaksicheskih oshibok i melkih semanticheskih.
     Vozmozhno,  naibol'shij  vyigrysh sreda  programmirovaniya  smozhet dat' pri
ispol'zovanii stroennyh sistem baz dannyh dlya otslezhivaniya miriadov detalej,
kotorye  kazhdyj  programmist  dolzhen  tochno  vspominat',  i  kotorye  dolzhny
hranit'sya v tekushchem sostoyanii v gruppe rabotayushchih nad odnoj sistemoj.
     Nesomnenno, chto  eto rabota zasluzhivaet  vnimaniya i prineset  nekotorye
plody  kak dlya proizvoditel'nosti, tak i dlya nadezhnosti. No  vvidu samoj  ee
suti otdacha dolzhna byt' neznachitel'noj.
     Rabochie    stancii.    Kakoj    vyigrysh   mozhet   poluchit'    iskusstvo
programmirovaniya ot  nesomnennogo i bystrogo rosta moshchnosti  i ob®ema pamyati
otdel'noj  rabochej  stancii?  Skol'ko  millionov  operacij  v sekundu  mozhno
plodotvorno  ispol'zovat'?  Sostavlenie  i  redaktirovanie  programm  vpolne
obespechivayutsya  segodnyashnimi  skorostyami. Kompilyaciya mozhet byt' uskorena, no
desyatikratnoe uvelichenie skorosti  mashiny, vne somneniya, sdelaet obdumyvanie
osnovnym zanyatiem programmista v techenie rabochego dnya. Pozhaluj, eto  tak uzhe
sejchas.
     Konechno,  my  privetstvuem  uvelichenie  moshchnosti  rabochih  stancij.  No
rasschityvat' na svyazannye s etim chudesa my ne mozhem.
     Perspektivnye podhody k konceptual'noj sushchnosti
     Hotya  nikakoj  proryv   v  tehnologii  ne   obeshchaet  takih  volshebnyh
rezul'tatov, kakie my  vidim v  apparatnoj  chasti komp'yuterov,  v  nastoyashchee
vremya delaetsya  mnogo  poleznogo,  i  est'  nadezhdy  na  neuklonnyj, hotya  i
nebroskij progress.
     Vse  tehnologicheskie  podhody  k akcidenciyam processa  programmirovaniya
principial'no ogranicheny uravneniem produktivnosti:

     

     Esli, kak ya polagayu, konceptual'nye sostavlyayushchie zadachi sejchas otnimayut
bol'shuyu chast'  vremeni,  to  nikakaya rabota nad  sostavnymi chastyami  zadachi,
yavlyayushchimisya prosto vyrazheniem koncepcij, ne dast bol'shogo vyigrysha.
     Poetomu my dolzhny rassmotret'  te napravleniya, kotorye zatragivayut samu
sushchnost'    problemy    programmirovaniya   -   formulirovku   etih   slozhnyh
konceptual'nyh struktur.  K  schast'yu, nekotorye iz  etih napravlenij  ves'ma
mnogoobeshchayushchi.
     Pokupat', a  ne sozdavat'. Naibolee  radikal'noe vozmozhnoe reshenie  pri
sozdanii programm - voobshche ne sozdavat' ih.
     S  kazhdym dnem eto stanovitsya vse  legche,  poskol'ku vse bol'shee  chislo
postavshchikov   predlagaet  vse  bolee  mnogochislennye  i  luchshie  programmnye
produkty    dlya    nemyslimogo    raznoobraziya    prilozhenij.    Poka    my,
inzhenery-programmisty,   trudilis'   nad    sovershenstvovaniem   metodologii
proizvodstva, revolyuciya, proizvedennaya  personal'nymi  komp'yuterami, sozdala
ne odin, a mnogo massovyh rynkov programmnogo obespecheniya. V kazhdom gazetnom
kioske  vystavleny ezhemesyachnye zhurnaly, v kotoryh, otsortirovannye  po tipam
mashin,   reklamiruyutsya  i   recenziruyutsya  desyatki  produktov  po  cenam  ot
neskol'kih  dollarov do  neskol'kih soten dollarov. Bolee specializirovannye
izdaniya predlagayut ochen' moshchnye produkty dlya rabochih stancij i drugih rynkov
Unix.  Dazhe  instrumenty  i sredy  programmirovaniya  mogut  byt'  kupleny  v
korobochnom vide. YA gde-to predlozhil bazar dlya otdel'nyh modulej.
     Lyuboj takoj produkt deshevle kupit', chem sozdavat' zanovo. Dazhe pri cene
100 000  dollarov kuplennyj produkt  stoit primerno stol'ko, skol'ko godovoe
soderzhanie  programmista.  I  postavka  nemedlennaya! Nemedlennaya, po krajnej
mere, dlya real'no sushchestvuyushchih produktov, prospekt kotoryh razrabotchik mozhet
poslat' schastlivomu pol'zovatelyu. Bolee togo, takie  produkty obychno gorazdo
luchshe dokumentirovany  i neskol'ko  luchshe soprovozhdayutsya,  chem  domoroshchennye
programmy.
     Razvitie  massovogo rynka yavlyaetsya, po moemu  mneniyu, naibolee glubokoj
dolgosrochnoj   tendenciej  programmnoj  inzhenerii.  Stoimost'   programmnogo
produkta  vsegda  opredelyalas'  stoimost'yu razrabotki,  a  ne tirazhirovaniya.
Razdeliv etu stoimost' dazhe na neskol'kih pol'zovatelej, my korennym obrazom
snizhaem  cenu na odnogo pol'zovatelya.  Vzglyanuv  na eto s drugoj storony, my
vidim, chto ispol'zovanie  n kopij programmnoj sistemy fakticheski umnozhaet na
n proizvoditel'nost'  ego razrabotchikov. |to rost proizvoditel'nosti otrasli
i vsej strany.
     Glavnym  voprosom,  konechno,  yavlyaetsya proizvoditel'nost'.  Smogu  li ya
ispol'zovat'  imeyushchijsya korobochnyj produkt dlya  resheniya  svoih zadach?  Zdes'
sluchilas' udivitel'naya veshch'. V 50-h i 60-h godah odno issledovanie za drugim
pokazyvalo,  chto  pol'zovateli ne  hotyat ispol'zovat' korobochnye  pakety dlya
rascheta  zarplaty,  upravleniya  skladom, ucheta  debitorov po raschetam i t.d.
Trebovaniya byli slishkom special'nymi, otkloneniya ot sluchaya k  sluchayu slishkom
bol'shimi. V  80-h godah  my  obnaruzhivaem  bol'shoj  spros na takie pakety  i
shirokoe ih ispol'zovanie. CHto izmenilos'?
     Tol'ko  ne  pakety.   Oni  stali  neskol'ko  bolee   obshchimi   i   luchshe
nastraivayutsya, chem  ran'she, no  ne namnogo. I ne  oblast'  ih primeneniya.  V
konce koncov,  segodnya potrebnosti  biznesa i  nauki  bolee  raznoobrazny  i
slozhny, chem 20 let nazad.
     Rezko izmenilos' sootnoshenie stoimosti komp'yuterov i programm. Tot, kto
v  1960  godu  pokupal  mashinu za  2  milliona  dollarov, schital, chto  mozhet
pozvolit' sebe potratit' eshche 250 000 dollarov na zakaznuyu programmu  rascheta
zarplaty, kotoraya legko i bez  ushcherba vpisalas' by vo vrazhdebnuyu komp'yuteram
social'nuyu  sredu.  Te,  kto segodnya  pokupayut  mashinu dlya  ofisa za 50  000
dollarov,  ne  mogut,  ponyatno,  pozvolit'  sebe zakaznye programmy  rascheta
zarplaty, poetomu  oni  prisposablivayut  svoi  procedury  rascheta zarplaty k
imeyushchimsya paketam. Komp'yutery sejchas stol' obychny, esli ne stol' lyubimy, chto
adaptaciya vosprinimaetsya kak obychnoe delo.
     Est'  yarkie  isklyucheniya iz  moego utverzhdeniya  o tom,  chto obobshchennost'
programmnyh paketov za poslednie gody malo izmenilas': elektronnye tablicy i
prostye sistemy baz dannyh. |ti moshchnye instrumenty, stol'  ochevidnye  zadnim
umom i tak pozdno  poyavivshiesya, imeyut beschislennoe  mnozhestvo primenenij,  v
tom chisle,  ves'ma  neobychnye. Est' massa  statej  i dazhe knig o  tom, kak s
pomoshch'yu elektronnoj tablicy reshat' neozhidannye zadachi. Bol'shoe chislo  zadach,
dlya  kotoryh ran'she byli  by napisany zakaznye programmy na Cobol ili Report
Program Generator, teper' shablonno reshaetsya s pomoshch'yu etih instrumentov.
     Mnogie pol'zovateli izo dnya v den' primenyayut svoi komp'yutery dlya raznyh
prilozhenij, nikogda ne napisav  ni odnoj  programmy. Na  praktike mnogie  iz
etih pol'zovatelej i ne mogut pisat' dlya svoih mashin novye programmy, no tem
ne menee priverzhency resheniyu voznikayushchih zadach s ih pomoshch'yu.
     YA schitayu, chto segodnya dlya  mnogih organizacij samaya pravil'naya politika
dlya povysheniya proizvoditel'nosti razrabotki programmnogo  obespecheniya -  eto
ustanovit' svoim ne imeyushchim komp'yuternyh znanij rabotnikam umstvennogo truda
komp'yutery  i  horoshie  obshchie  programmy  dlya obrabotki tekstov,  risovaniya,
raboty s fajlami i elektronnymi tablicami i otpustit' ih v vol'noe plavanie.
Takaya  zhe   politika   v   otnoshenii   rasprostranennyh   matematicheskih   i
statisticheskih  paketov, a takzhe nekotoryh navykov programmirovaniya podojdet
sotnyam uchenyh, rabotayushchih v laboratoriyah.
     Utochnenie  trebovanij i  bystroe maketirovanie. Samaya trudnaya otdel'naya
zadacha   v  razrabotke  programmnoj   sistemy  -  eto   tochno   reshit',  chto
razrabatyvat'.  Ni odna  drugaya  zadacha  raboty nad koncepciyami ne  yavlyaetsya
stol' trudnoj,  kak razrabotka podrobnyh tehnicheskih trebovanij, vklyuchaya vse
interfejsy  pol'zovatelej,  mashinnye   interfejsy   i  interfejsy  k  drugim
programmnym sistemam. Ni  odna drugaya chast' raboty ne  nanosit takogo ushcherba
gotovoj   sisteme,  esli  sdelana  nepravil'no.  Ni  odna  drugaya  chast'  ne
ispravlyaetsya pozdnee s bol'shim trudom.
     Poetomu  naibolee  vazhnoj  funkciej, osushchestvlyaemoj  razrabotchikami dlya
svoih klientov,  yavlyaetsya povtoryayushcheesya poluchenie  i utochnenie trebovanij  k
produktu. Pravda zaklyuchaetsya v tom, chto klienty ne znayut, chego hotyat. Obychno
oni  ne  znayut,  na  kakie voprosy  nuzhno  dat'  otvet,  i pochti  nikogda ne
zadumyvalis'  nad  zadachej  nastol'ko detal'no,  kak  eto  nuzhno  ukazat'  v
specifikacii.  Dazhe prostoj otvet - "sdelajte tak,  chtoby novaya  programmnaya
sistema rabotala tak, kak nasha staraya ruchnaya sistema obrabotki informacii" -
okazyvaetsya v dejstvitel'nosti slishkom uproshchennym. Klienty  nikogda ne hotyat
etogo  v  tochnosti.  Bolee  togo,  slozhnye  programmnye  sistemy  dejstvuyut,
dvizhutsya, rabotayut. Dinamiku etogo dejstviya trudno sebe predstavit'. Poetomu
pri planirovanii lyubyh dejstvij neobhodimo ostavit' rezerv dlya mnogokratnogo
vzaimodejstviya mezhdu klientom i proektirovshchikom pri opisanii sistemy.
     YA pojdu dal'she i stanu utverzhdat', chto na praktike klienty, dazhe vmeste
s   inzhenerami-programmistami,  ne  v  sostoyanii  ukazat'  polno,  strogo  i
korrektno tochnye trebovaniya k sovremennomu programmnomu produktu, prezhde chem
budut  sozdany  i oprobovany  kakie-libo  versii  produkta,  specifikacii  k
kotoromu oni sostavlyayut.
     Poetomu  odnim iz  naibolee  mnogoobeshchayushchih  sovremennyh napravlenij  v
tehnologii,  prichem  obrashchennyh  k  sushchnosti,  a  ne  k akcidenciyam  problem
programmirovaniya,  yavlyaetsya razrabotka  podhodov i instrumentov dlya bystrogo
sozdaniya  maketov  sistem   kak  chasti  iterativnogo   processa   razrabotki
specifikacij.
     Maket  programmnoj sistemy modeliruet  glavnye  interfejsy  i vypolnyaet
osnovnye funkcii  predpolagaemoj  sistemy,  pri etom  ne  obyazatel'no buduchi
svyazan   temi  zhe  ogranicheniyami  bystrodejstviya  komp'yutera,   razmera  ili
stoimosti. Obychno makety  vypolnyayut osnovnye zadachi sistemy, no ne  pytayutsya
obrabatyvat'  isklyuchitel'nye   situacii,   pravil'no  reagirovat'  na   vvod
nedopustimyh dannyh, korrektno preryvat' rabotu  i t.d. Naznachenie  maketa -
pokazat', kak voploshchaetsya  vybrannaya konceptual'naya struktura, chtoby  klient
mog proverit' ee prigodnost' k ispol'zovaniyu i neprotivorechivost'.
     Segodnya   mnogie  procedury   priobreteniya   programmnogo   obespecheniya
osnovyvayutsya   na  predpolozhenii,  chto   mozhno  zaranee  zadat'  tehnicheskie
trebovaniya  dlya  zhelaemoj  sistemy,  rassmotret'  predlozheniya razrabotchikov,
poluchit'  razrabotannuyu  sistemu  i  ustanovit'  ee.  YA  dumayu,  chto   takoe
predpolozhenie  v korne neverno,  i  iz-za  etoj  oshibki  proistekayut  mnogie
problemy pri priobretenii programm, poskol'ku eti problemy nel'zya  ustranit'
bez  peresmotra  osnov,  dlya kotorogo trebuetsya  interaktivnaya razrabotka  i
specifikacii maketov i produktov.
     Poshagovaya obrabotka: narashchivat' programmu, a ne stroit' srazu. YA do sih
por pomnyu  ispytannyj v 1958 godu udar, kogda vpervye uslyshal, kak moj  drug
govoril o stroitel'stve  (building)  programm  v protivopolozhnost' napisaniyu
(writing).  V  mgnovenie  on  rasshiril  vse  moe  predstavlenie  o  processe
programmirovaniya. Primenenie  metafory  bylo  sil'nym i tochnym.  Segodnya  my
ponimaem,  chto  shodstvo  sushchestvuet  mezhdu  sozdaniem  programmy i  drugimi
stroitel'nymi  processami,  i svobodno ispol'zuem drugie elementy  metafory,
takie kak  specifikacii  (specifications), sborka komponentov  (assembly  of
components), lesa (scaffolding).
     Metafora  stroitel'stva   perezhila  svoe  vremya.  Pora  snova   vnosit'
izmeneniya. Esli, kak ya schitayu, sozdavaemye  segodnya konceptual'nye struktury
slishkom slozhny, chtoby ih mozhno bylo tochno specificirovat' zaranee, i slishkom
slozhny, chtoby stroit' bez oshibok, togda nuzhen radikal'no inoj podhod.
     Obratimsya  k  prirode i  rassmotrim  slozhnost'  zhivyh  sozdanij,  a  ne
bezzhiznennyh tvorenij cheloveka. Tam  my obnaruzhivaem konstrukcii,  slozhnost'
kotoryh  vselyaet  v  nas  uzhas.  Odin  tol'ko  mozg  nastol'ko  slozhen,  chto
nevozmozhno sostavit'  ego shemu.  Ego  moshch' nevozmozhno  povtorit', on  bogat
svoeobraziem, sposoben k samosohraneniyu i samoobnovleniyu.  Sekret v tom, chto
mozg rastet, a ne stroitsya.
     Tak zhe dolzhny sozdavat'sya nashi programmnye sistemy. Neskol'ko let nazad
Harlan  Millz  predlozhil  narashchivat'  programmnye  sistemy  putem  poshagovoj
razrabotki.11 |to znachit,  chto snachala  sistemu nado  zastavit' vypolnyat'sya,
dazhe esli pri etom ona ne delaet  nichego poleznogo,  krome vyzova nekotorogo
chisla  fiktivnyh  podprogramm.  Zatem ona ponemnogu obrastaet  myasom, prichem
podprogrammy,  v svoyu ochered',  razrabatyvayutsya  snachala  kak vyzovy  pustyh
fiktivnyh podprogramm, nahodyashchihsya na uroven' nizhe.
     Nastaivaya na primenenii etoj tehnologii razrabotchikami proektov na moih
laboratornyh   zanyatiyah   po  programmnoj  inzhenerii,   ya   stal  svidetelem
porazitel'nyh rezul'tatov. Za poslednee desyatiletie nichto drugoe ne  okazalo
stol'  sil'nogo vliyaniya na moyu  sobstvennuyu  rabotu i ee effektivnost'. |tot
podhod predpolagaet nishodyashchee  proektirovanie, poskol'ku eto  -  nishodyashchee
narashchivanie  programmy.  On  pozvolyaet  legko otslezhivat' rabotu v  obratnom
napravlenii.  On predostavlyaet vozmozhnost' rannego sozdaniya maketov.  Kazhdaya
novaya funkciya ili vozmozhnost' raboty s bolee slozhnymi dannymi ili  usloviyami
organicheski vyrastayut na togo, chto uzhe imeetsya.
     Vozdejstvie na moral'nyj duh oshelomitel'noe. Kogda est' hotya by prostaya
rabotayushchaya  sistema,  vozrastaet entuziazm. |nergiya  udvaivaetsya,  kogda  na
ekrane  poyavlyaetsya kartinka iz  novoj graficheskoj programmnoj sistemy,  dazhe
esli eto  vsego lish' pryamougol'nik.  I na kazhdoj  stadii processa razrabotki
sushchestvuet  rabotayushchaya  sistema. YA schitayu,  chto za odinakovye  sroki komanda
mozhet narastit' znachitel'no bolee slozhnyj ob®ekt, chem postroit'.
     V  bol'shih proektah  mozhno  oshchutit'  takie  zhe vygody,  kak  i  v  moih
malen'kih.12
     Vydayushchiesya proektirovshchiki. Glavnaya problema sovershenstvovaniya iskusstva
programmirovaniya zaklyuchena, kak vsegda, v lyudyah.
     My  mozhem dobivat'sya  horoshih  proektov, sleduya  horoshim,  a ne  plohim
prakticheskim   priemam.  Horoshim   priemam   mozhno   obuchat'.   Programmisty
prinadlezhat k naibolee intellektual'noj chasti obshchestva, sledovatel'no, oni v
sostoyanii   izuchat'  horoshie  priemy.  Poetomu   vazhnejshim   napravleniem  v
Soedinennyh  SHtatah  yavlyaetsya rasprostranenie  horoshih sovremennyh  priemov.
Novye kursy, novye izdaniya, novye organizacii, takie kak Institut inzhenerov-
programmistov  (Software Engineering  Institute)  - vse eto vyzvano  k zhizni
stremleniem  povysit'  uroven'  nashih  prakticheskih  priemov. |to sovershenno
pravil'no.
     Tem  ne  menee,  ya  schitayu,  chto my  ne smozhem  podnyat'sya eshche  na  odnu
stupen'ku  vyshe, dejstvuya  v  etom  napravlenii.  Vybor  pravil'nogo  metoda
proektirovaniya  opredelyaet  razlichiya  mezhdu plohim i  horoshim konceptual'nym
proektom,  no  ne  mezhdu horoshim i vydayushchimsya. Vydayushchiesya  proekty sozdayutsya
vydayushchimisya   proektirovshchikami.   Sozdanie   programm  yavlyaetsya   tvorcheskim
processom.  Krepkaya metodologiya mozhet pridat'  silu i osvobodit'  tvorcheskij
um, no ona  ne mozhet vosplamenit'  ili vdohnovit'  togo,  kto  zanyat  nudnoj
rabotoj.
     I  raznica  nemalaya  - eto kak Sal'eri i Mocart.  Odno  issledovanie za
drugim  pokazyvayut, chto  luchshie proektirovshchiki  sozdayut  struktury,  kotorye
bystree, men'she po razmeru, proshche, ponyatnee i razrabotany men'shimi usiliyami.
Razlichiya mezhdu vydayushchimsya i srednim dostigayut poryadka velichiny.
     Netrudno  prosledit', chto  ryad horoshih  i  poleznyh programmnyh  sistem
proektirovalsya  komissiyami  i  sozdavalsya  s pomoshch'yu proektov, sostoyavshih iz
mnogih  chastej.  No  programmnye  sistemy,  vyzvavshie  voshishchenie  strastnyh
poklonnikov,  yavlyayutsya  produktom  odnogo  ili  nebol'shogo  chisla vydayushchihsya
proektirovshchikov. Posmotrite na Unix, APL, Pascal, interfejs Smalltalk i dazhe
Fortran - s odnoj storony, i Cobol, PL/I, Algol, MVS/370 i MS-DOS - s drugoj
(ris. 16.1).

     

     Ris. 16.1 Imeyutsya li u etih produktov strastnye poklonniki?
     Poetomu, vysoko cenya nyneshnie programmy peredachi tehnologij  i razvitiya
obucheniya,  ya  schitayu,  chto  naibolee  vazhnoj  programmoj,  kotoruyu  my mozhem
predprinyat',    yavlyaetsya    razvitie    sposobov    vospitaniya    vydayushchihsya
proektirovshchikov.
     Ni odna zanyataya v programmirovanii  organizaciya  ne mozhet  ignorirovat'
etu  problemu. Horoshih menedzherov,  kak  by malo ih  ni bylo, ne men'she, chem
horoshih proektirovshchikov. Kak vydayushchiesya  proektirovshchiki,  tak  i  vydayushchiesya
menedzhery vstrechayutsya redko.  V  bol'shinstve organizacij znachitel'nye usiliya
tratyatsya na poiska i vyrashchivanie podayushchih nadezhdy menedzherov.  YA ne  slyshal,
chtoby kto-  libo tratil  takie  zhe  usiliya  na poiski i razvitie  vydayushchihsya
proektirovshchikov,   ot  kotoryh,  v  konechnom   schete,  zavisit   tehnicheskoe
prevoshodstvo produktov.
     Pervoe  moe  predlozhenie  sostoit  v  tom,  chtoby   kazhdaya  zanyataya   v
programmirovanii  organizaciya  opredelila  dlya  sebya  i  provozglasila,  chto
vydayushchiesya proektirovshchiki imeyut dlya ee uspeha takoe zhe bol'shoe znachenie, kak
i vydayushchiesya menedzhery,  i chto oni  mogut rasschityvat' na takie zhe zabotu  i
voznagrazhdenie. Ne tol'ko zarplata, no i atributy polozheniya - razmery ofisa,
mebel',  tehnicheskoe  oborudovanie,  komandirovochnye  fondy,  obespechennost'
sotrudnikami - dolzhny byt' polnost'yu ravnoznachny.
     Kak rastit' vydayushchihsya  proektirovshchikov?  Mesto ne pozvolyaet  obsuzhdat'
eto prostranno, no vot nekotorye ochevidnye shagi:
     -   Sistematicheski   i  kak   mozhno   ran'she   vyyavlyat'   pervoklassnyh
proektirovshchikov. Luchshie - ne vsegda samye opytnye.
     -   Naznachit'   nastavnika,  otvetstvennogo   za   rost  perspektivnogo
proektirovshchika i tshchatel'no sledit' za ego kar'eroj.
     -  Razrabotat'  i  osushchestvlyat'  plan  sluzhebnogo   rosta  dlya  kazhdogo
perspektivnogo proektirovshchika,  vklyuchayushchij tshchatel'no  produmannoe obuchenie u
peredovyh  proektirovshchikov,  periody  dopolnitel'nogo formal'nogo  obucheniya,
kratkosrochnye  kursy,  peremezhayushchiesya  s samostoyatel'nym  proektirovaniem  i
naznacheniem na rukovodyashchie tehnicheskie dolzhnosti.
     - Obespechit' vozmozhnosti dlya vzaimodejstviya i vzaimnogo  stimulirovaniya
rastushchih proektirovshchikov.


    Glava  17.  Novyj vystrel  "Serebryanoj puli  net"

     U  vsyakoj  puli -  svoe
prednaznachenie.
     VILXGELXM III ORANSKIJ
     Kto hochet uvidet' obrazec sovershenstva,
     Tot mechtaet o tom, chego nikogda ne bylo,
     net i ne budet.
     ALEKSANDR POP, "O KRITIKE"
     Ob oborotnyah i prochih mificheskih uzhasah
     "Serebryanoj  puli net: sushchnost' i akcidenciya v  programmnoj inzhenerii"
(glava 16 dannoj knigi) pervonachal'no byla zakaznym dokladom dlya konferencii
IFIP (Mezhdunarodnoj federacii po obrabotki informacii) 1986 goda v Dubline i
byla  opublikovana  v  ee  trudah.1  ZHurnal  "Computer"  perepechatal ee  pod
oblozhkoj v  goticheskom  stile,  illyustriruya  kadrami iz fil'mov,  takih  kak
"Vervol'f  iz  Londona",2  i  snabdiv  bokovym  polem  "Ubit'  vervol'fa"  s
izlozheniem  sovremennoj legendy o tom, chto spravit'sya s nim  mozhno  tol'ko s
pomoshch'yu serebryanoj puli. Do publikacii ya ne znal ob illyustraciyah, i dlya menya
bylo  neozhidannost'yu,  chto  ser'eznaya  tehnicheskaya stat'ya byla  tak krasochno
izdana.
     Odnako  redaktory  "Computer" znali  svoe  delo  i  dostigli  zhelaemogo
rezul'tata: pohozhe, chto stat'yu prochli mnogie.  Poetomu  ya  podobral  dlya toj
glavy  eshche odnu kartinku s oborotnem - starinnoe izobrazhenie pochti zabavnogo
sozdaniya. Nadeyus', chto  eta menee  yarkaya kartinka okazhet  takoe zhe  poleznoe
dejstvie.
     Serebryanaya pulya vse-taki est' - VOT ONA!
     "Serebryanoj  puli  net"  utverzhdaet  i   dokazyvaet,  chto  v  techenie
desyatiletiya  (s momenta publikacii stat'i v  1986 godu) ni odna razrabotka v
oblasti   tehniki    programmnogo    obespecheniya    ne   pozvolit   povysit'
proizvoditel'nost' truda v programmirovanii na poryadok. Iz etogo desyatiletiya
proshlo uzhe devyat' let, i mozhno posmotret', naskol'ko sbyvaetsya predskazanie.
     V to vremya kak "Mificheskij cheloveko-mesyac" porodil chastoe citirovanie i
malo  sporov, stat'ya "Serebryanoj puli net" vyzvala stat'i s oproverzheniyami i
pis'ma  v  redakcii zhurnalov,  potok kotoryh ne prekratilsya i po  sej den'.3
CHashche vsego kritikuetsya  glavnoe  utverzhdenie o  tom, chto volshebnogo  resheniya
net,  i  moe  yasno  vyrazhennoe mnenie  o  tom,  chto  ego  i  byt'  ne mozhet.
Bol'shinstvo soglashaetsya  s osnovnoj chast'yu moih argumentov v "SPN", no zatem
zayavlyaet, chto v  dejstvitel'nosti serebryanaya  pulya  dlya  programmnogo  zverya
sushchestvuet, i izobrel ee  avtor. Perechityvaya segodnya rannie otkliki, ne mogu
ne otmetit', chto  patentovannye sredstva,  stol' energichno predlagavshiesya  v
1986 i 1987 godah, ne vozymeli effekta, na kotoryj pretendovali.
     YA  obychno  pokupayu komp'yutery  i programmy, proveryaya ih na  "schastlivom
obladatele", t.e. beseduya s vyzyvayushchimi  doverie lyud'mi, zaplativshimi den'gi
za produkt i  pol'zuyushchimisya im s udovol'stviem. Analogichno, ya s  gotovnost'yu
poveryu   v  materializaciyu  serebryanoj   puli,   kogda  vyzyvayushchij   doverie
nezavisimyj  pol'zovatel'  vystupit  vpered  i  skazhet: "YA  ispol'zoval  etu
metodologiyu, etot instrument ili produkt, i eto  pozvolilo mne  v desyat' raz
povysit' proizvoditel'nost' razrabotki programm".
     Mnogie korrespondenty  sdelali vernye popravki i raz®yasneniya. Nekotorye
proanalizirovali stat'yu punkt  za punktom i  priveli vozrazheniya, za chto ya im
blagodaren. V etoj glave ya hochu soobshchit' o sdelannyh popravkah i otvetit' na
oproverzheniya.
     Neyasnoe izlozhenie vlechet neponimanie
     Sudya  po  nekotorym  otklikam, mne  ne  udalos'  chetko izlozhit'  svoi
argumenty.
     Vtorostepennoe  svojstvo  (accident). V rezyume glavy 16 ya postaralsya so
vsej  vozmozhnoj  yasnost'yu  izlozhit'  osnovnye  argumenty  "SPN".  Nekotorye,
odnako,   byli  smushcheny  terminami  vtorostepennoe  svojstvo   (accident)  i
nesushchestvennyj,  vtorostepennyj (accidental), kotorye ya ispol'zoval v starom
upotreblenii,  voshodyashchem k Aristotelyu.4  Pod  accidental ya ne  imel  v vidu
"sluchajnyj"    ili   "otnosyashchijsya   k   neschastnomu   sluchayu",   a   skoree,
"nesushchestvennyj", "pobochnyj" (incidental) ili "prinadlezhashchij" (appurtinent).
     YA ne hochu porochit' rol' sluchajnosti pri  razrabotke programm.  Vsled za
anglijskim dramaturgom, avtorom detektivov i teologom Doroti Sejers (Dorothy
Sayers) ya rassmatrivayu vsyakuyu tvorcheskuyu deyatel'nost', kak sostoyashchuyu  iz: a)
formulirovaniya   konceptual'nyh   konstrukcij,  b)  voploshcheniya  v   real'nom
materiale  i  v)  dialoga  s  pol'zovatelem  v  real'noj  zhizni.5  Ta  chast'
postroeniya programmy,  kotoruyu  ya  nazval  sushchnost'yu (essence),  sostoit  iz
umstvennoj raboty  sozdaniya  konceputal'noj  konstrukcii,  a ta,  kotoruyu  ya
nazval vtorostepennoj (accident), est' process ee voploshcheniya.
     Vyyasnenie  istiny.  Mne  kazhetsya  (hotya  ne vse so  mnoj soglasny), chto
vernost' central'nogo argumenta svoditsya k vyyasneniyu otveta na vopros: kakaya
dolya zatrat svyazana  s  tochnym i uporyadochennym predstavleniem konceptual'noj
konstrukcii,   a  kakaya  -  s  umstvennymi  usiliyami  po  izgotovleniyu  etih
konstrukcij.  Poisk  i ustranenie oshibok popadayut v  tot ili  inoj  razdel v
zavisimosti  ot togo, yavlyayutsya li oshibki konceptual'nymi (naprimer,  propusk
kakogo-libo osobogo sluchaya) ili oshibkami  predstavleniya  (naprimer, oshibka v
ukazatele ili raspredeleniya pamyati).
     Moe lichnoe mnenie sostoit v tom, chto vtorostepennaya ili napravlennaya na
predstavlenie  chast' raboty  sejchas snizilas' do poloviny ili menee togo  ot
obshchego  ob®ema. Poskol'ku eta  dolya yavlyaetsya eksperimental'noj velichinoj, ee
znachenie, v principe, mozhno poluchit'  putem izmerenij.5 Esli eto ne udaetsya,
moyu  ocenku  mozhno  popravit' na  osnove bolee  polnyh  i bolee  sovremennyh
dannyh,  no ni v publichnyh, ni v chastnyh zayavleniyah nikto ne utverzhdal,  chto
neosnovnaya chast' dostigaet velichiny 9/10.
     "SPN"  s  nesomnennost'yu  dokazyvaet,  chto esli  dolya  neosnovnoj chasti
raboty men'she  9/10, to  dazhe  svedya ee  k nulyu (chto bylo  by chudom), nel'zya
poluchit'  rost  produktivnosti na  poryadok.  Ataku  neobhodimo  nacelit'  na
sushchestvennuyu chast'.
     Posle poyavleniya "SPN" Bryus Blum (Bruce  Blum)  obratil  moe vnimanie na
rabotu  1959  goda  Gercberga,  Moznera  i  Zejdermana  (Herzberg,  Mausner,
Sayderman).7   Oni   nahodyat,  chto   faktory   motivacii   mogut   uvelichit'
proizvoditel'nost'. S  drugoj storony, faktory  okruzheniya  i  vtorostepennye
faktory,  skol' by oni ni  byli polozhitel'ny,  ne mogut  etogo sdelat',  no,
buduchi   otricatel'nymi,  mogut   umen'shit'  proizvoditel'nost'.   V   "SPN"
dokazyvaetsya,  chto  znachitel'naya chast'  progressa  v  programmnoj  inzhenerii
dostignuta za  schet  ustraneniya  vliyaniya sleduyushchih  otricatel'nyh  faktorov:
krajne   neudobnyh   mashinnyh   yazykov,   paketnoj   obrabotki   s    dolgoj
oborachivaemost'yu,  slabogo instrumentariya i  strogih ogranichenij  na  razmer
pamyati.
     YAvlyayutsya  li  v  takom   sluchae  beznadezhnymi  trudnosti,  svyazannye  s
sushchnost'yu? Otlichnaya rabota "Serebryanaya pulya  est'", napisannaya Bredom Koksom
(Bred   Cox)  v  1990  godu,  krasnorechivo   dokazyvaet,   chto   mnogokratno
ispol'zuemye  i vzaimozamenyaemye komponenty  dolzhny  posluzhit'  osnovoj  dlya
ataki na konceptual'nuyu sushchnost' problemy.8 YA ohotno soglashayus'.
     Odnako Koks nepravil'no ponimaet "SPN" v dvuh otnosheniyah. Vo-pervyh, on
nahodit  v nej  utverzhdenie  togo,  chto  trudnosti  razrabotki  programmnogo
obespecheniya proistekayut iz "nekotoryh  porogov  tehnologij, ispol'zovavshihsya
programmistami v to  vremya".  YA zhe  dokazyval, chto  trudnosti,  svyazannye  s
sushchnost'yu,    yavlyayutsya    neot®emlemoj   chast'yu   konceptual'noj   slozhnosti
razrabatyvaemyh programmnyh funkcij vo vse vremena i pri lyubyh metodah.  Vo-
vtoryh, on  i mnogie drugie prochli v "SPN" utverzhdenie togo, chto net nikakih
nadezhd uspeshno spravit'sya  so  slozhnostyami razrabotki programm, svyazannymi s
voprosami  sushchnosti. |to ne to, chto  ya imel v vidu. Sozdanie  konceptual'noj
konstrukcii  dejstvitel'no  imeet  vnutrenne  prisushchie  trudnosti, takie kak
slozhnost', soglasovannost', izmenyaemost'  i nezrimost'. Odnako nepriyatnosti,
vyzyvaemye vsemi etimi trudnostyami, mozhno umen'shit'.
     Slozhnost' razdeleniya na urovni. Naprimer, naibolee ser'eznoj vnutrennej
trudnost'yu yavlyaetsya  slozhnost', no  ona  ne  vsegda neizbezhna.  Znachitel'naya
chast' (no ne vsya)  konceptual'noj slozhnosti v nashih programmnyh konstrukciyah
proistekaet ot proizvol'noj slozhnosti samih primenenij.  Dejstvitel'no, Lars
Sedal' iz MYSYGMA Sohdal  and Partners, mezhdunarodnoj konsaltingovoj firmy v
oblasti menedzhmenta, pishet:
     Moj  opyt pokazyvaet,  chto  vse slozhnosti,  s kotorymi stalkivayutsya pri
razrabotke sistem,  yavlyayutsya  priznakami  organizacionnyh nepoladok. Popytka
modelirovaniya   prakticheskoj   deyatel'nosti    programmami   sootvetstvuyushchej
slozhnosti vlechet sohranenie nerazberihi vmesto resheniya problem.
     Stiv  Lukashik  (Steve  Lukasik)  iz  Northrop  dokazyvaet,  chto  dazhe
organizacionnaya  slozhnost',  vozmozhno,  ne  yavlyaetsya proizvol'noj,  a  mozhet
ispytyvat' vozdejstvie principov uporyadocheniya:
     YA poluchil obrazovanie  v  oblati fiziki i  poetomu  vizhu, chto "slozhnye"
veshchi mogut byt'  opisany  na  yazyke  bolee prostyh ponyatij.  Vy mozhete  byt'
pravy,  i  ya ne stanu utverzhdat', chto vse slozhnye  veshchi  poddayutsya principam
uporyadocheniya... po tem zhe pravilam  dokazatel'stva nel'zya utverzhdat', chto ne
poddayutsya.
     ...To,  chto  vchera  bylo  slozhnost'yu,  zavtra  budet  v poryadke  veshchej.
Slozhnost'   besporyadochnogo   dvizheniya  molekul   privela   k   vozniknoveniyu
kineticheskoj  teorii gazov i  otkrytiyu treh  zakonov  termodinamiki.  Sejchas
programmnoe  obespechenie   ne  pozvolyaet  uvidet'  prisushchie   emu   principy
uporyadocheniya,  no vy kak raz i  dolzhny ob®yasnit', pochemu eto proishodit. |to
ne  proyavlenie  moej bestolkovosti ili zhelaniya posporit'.  YA ubezhden,  chto v
odin prekrasnyj den' "slozhnost'" programmnogo obespecheniya budet ob®yasnena na
yazyke kakih- nibud' ponyatij bolee vysokogo poryadka (invariantov, kak govoryat
fiziki).
     YA  ne zanimalsya  bolee  glubokim  analizom,  k  kotoromu  spravedlivo
prizyvaet  Lukashik.  Kak  otrasl'  nauki  my  nuzhdaemsya  v  razvitii  teorii
informacii    dlya    kolichestvennoj    ocenki   informacionnogo   soderzhaniya
statisticheskih  struktur, podobno  tomu, kak teoriya  SHennona delaet  eto dlya
informacionnyh potokov.  |to sovsem ne moya zadacha. Lukashiku ya prosto otvechu,
chto slozhnost' sistemy yavlyaetsya funkciej miriadov detalej, kazhdaya iz  kotoryh
dolzhna byt' tochno zadana libo s pomoshch'yu  kakogo-nibud'  obshchego pravila, libo
podrobnym  opisaniem, no  ne  prosto  statisticheski.  Predstavlyaetsya  ves'ma
somnitel'nym, chtoby nesoglasovannye rezul'taty raboty mnogih golov okazalis'
dostatochno svyaznymi, chtoby byt' tochno opisannymi obshchimi pravilami.
     Znachitel'no    bol'shaya   chast'   slozhnosti   programmnyh    konstrukcij
obuslovlena, odnako, ne sootvetstviem  vneshnemu miru, a  samoj realizaciej -
strukturami  dannyh,   algoritmami,   sposobami   kommunikacij.  Narashchivanie
programm s pomoshch'yu bol'shih blokov vysokogo urovnya, sozdannyh kogda-to ran'she
ili  kem-to  drugim,  pomogaet  izbezhat'   celyh  urovnej  slozhnosti.  "SPN"
provozglashaet  pohod  na  problemu  slozhnosti  v  polnoj  nadezhde, chto mozhno
dostich'  progressa.  Ona  vystupaet  za  dobavlenie  k  programmnoj  sisteme
neobhodimoj slozhnosti:
     - ierarhicheski, raspolagaya moduli ili ob®ekty po urovnyam;
     - poshagovo, chto obespechivaet postoyannuyu rabotosposobnost' sistemy.
     Analiz Harela
     Devid  Harel (David Harel) v stat'e 1992 goda "Kusaya serebryannuyu pulyu"
predprinimaet samyj tshchatel'nyj analiz "SPN" iz vseh opublikovannyh.9
     Pessimizm protiv  optimizma  i realizma. Harel rassmatrivaet kak "SPN",
tak   i  stat'yu  Parnasa  1984   goda  "Programmnye  aspekty  strategicheskih
oboronitel'nyh sistem"10  kak "slishkom  unylye".  On  namerevaetsya vysvetit'
bolee  yarkuyu storonu  problemy, predposylaya stat'e podzagolovok  "K svetlomu
budushchemu porgrammnyh  razrabotok". Tak zhe, kak i Koks, Harel  schitaet  "SPN"
pessimisticheskoj,  govorya:  "Esli vzglyanut' na  te  zhe fakty  s drugoj tochki
zreniya,  voznikayut  bolee  optimisticheskie  vyvody".  Oba   oni  nepravil'no
voprinyali tonal'nost' stat'i.
     Prezhde vsego, moya zhena, kollegi i redaktory schitayut, chto ya gorazdo chashche
vpadayu v  neopravdannyj optimizm, chem  v  pessimizm. V  konce  koncov  ya  po
proishozhdeniyu programmist, a optimizm - eto professional'naya bolezn' dannogo
remesla.
     V "SPN" pryamo  skazano: "Vglyadyvayas'  v  predstoyashchee desyatiletie, my ne
vidim serebryanoj puli... Odnako skepticizm ne est' pessimizm... Net carskogo
puti,  no put' est'".  Ona predskazyvaet,  chto novovvedeniya, proishodyashchie  v
1986  godu, buduchi razrabotany  i ispol'zovany, v sovokupnosti dejstvitel'no
pozvolyat dostich'  rosta proizvoditel'nosti na poryadok. Desyatiletie 1986-1996
podhodit  k  koncu,   i   eto  predskazanie  okazyvaetsya,  skoree,   slishkom
optimistichnym, a ne mrachnym.
     Dazhe esli by  vse bez isklyucheniya schitali  "SPN" pessimisticheskoj, chto v
etom  hudogo?  YAvlyaetsya li utverzhdenie |jnshtejna o tom,  chto nichego ne mozhet
peremeshchat'sya so skorost'yu, bol'shej skorosti  sveta, "unylym"  i "mrachnym"? A
kak  naschet rezul'tatov Gedelya o  tom, chto nekotorye veshchi nevychislimy? "SPN"
pytaetsya  utverzhdat',  chto  "sama  sushchnost'  programmnogo obespecheniya delaet
maloveroyatnym otkrytie  "serebryanyh  pul'" kogda-libo v budushchem".  Turskij v
svoem otlichnom otvetnom doklade na konferencii IFIP krasnorechivo zayavil:
     Iz  vseh popytok  nauki  prodvinut'sya  v  lozhnom  napravlenii  naibolee
vozvyshenny  te,  kotorye  byli  napravleny na  poisk  filosofskogo  kamnya  -
veshchestva,  s pomoshch'yu  kotorogo  predpolagalos'  obrashchat'  prostye metally  v
zoloto.  Vysshaya  cel'  alhimii, k  kotoroj s  rveniem  stremilis'  pokoleniya
issledovatelej, shchedro finansirovavshiesya svetskimi i duhovnymi pravitelyami, -
eto  v  chistom  vide  stremlenie  prinimat'  zhelaemoe  za  dejstvitel'noe  i
obshcheprinyatoe mnenie, chto veshchi  takovy, kakimi my hoteli  by ih  videt'.  |to
ochen'  po-chelovecheski.   Nuzhno  sdelat'  nad  soboj  bol'shoe  usilie,  chtoby
smirit'sya  s  sushchestvovaniem nerazreshimyh  problem. Stremlenie vopreki vsemu
najti vyhod, dazhe kogda  dokazano,  chto  ego ne  sushchestvuet, ochen'  i  ochen'
sil'no. I v bol'shinstve  svoem  my  s bol'shim sochuvstviem  otnosimsya k  etim
hrabrecam, kotorye pytayutsya dostich' nevozmozhnogo. |to prodolzhaetsya i  po sej
den'.   Pishutsya  sochineniya   o  kvadrature  kruga.  Stryapayutsya  los'ony  dlya
vosstanovleniya utrachennyh volos -  i  neploho  prodayutsya.  Rozhdayutsya  metody
povysheniya proizvoditel'nosti programmirovaniya - i horosho rashodyatsya.
     My slishkom chasto sklonny doveryat' svoemu optimizmu (ili ekspluatirovat'
optimisticheskie   nadezhdy  svoih  sponsorov).  My  slishkom  chasto  ne  hotim
prislushivat'sya k golosu  rassudka  i  obrashchaem mnogo  vnimaniya na  prodavcov
panacej, poyushchih golosami siren.11
     Turskij, kak i ya,  preduprezhdaet, chto mechtatel'nost' tormozit  dvizhenie
vpered i vedet k pustoj trate sil.
     "Mrachnye" temy. Harel schitaet, chto mrachnost' "SPN" pridayut tri temy:
     - Rezkoe razdelenie mezhdu sushchnost'yu i vtorostepennym.
     - Izolirovannoe rassmotrenie kazhdogo kandidata v "serebryanye puli".
     - Prognoz lish' na blizhajshie 10 let,  a ne  na srok,  v techenie kotorogo
mozhno ozhidat' "sushchestvennyh uluchshenij".
     CHto kasaetsya pervogo,  to v eto vsya sol' stat'i. YA  po-prezhnemu schitayu,
chto takoe razdelenie  neobhodimo dlya ponimaniya togo, pochemu trudno sozdavat'
programmnoe obespechenie.  I eto vernoe ukazanie,  kuda dolzhen byt' napravlen
udar.
     CHto  kasaetsya  izolirovannogo  rassmotreniya  kandidatov  v  "serebryanye
puli", to eto pravda. Raznye kandidaty predlagalis' poocheredno i nepomernymi
pretenziyami   na  sobstvennoe   vsesilie.   Pravomerno  i  rassmatrivat'  ih
poocheredno. YA vozrazhayu ne protiv samih tehnologij, no protiv ozhidaniya ot nih
chuda.  Glass, Vessi  i  Kondzher (Glass, Vessey, Conger) v  svoej stat'e 1992
goda  predstavili  mnogochislennye svidetel'stva togo, chto bespoleznye poiski
serebryanoj puli vse eshche prodolzhayutsya.12
     CHto kasaetsya vybora v kachestve perioda predskazanij 10, a ne 40 let, to
chastichno eto priznanie togo, chto nashi predskazaniya  na bol'shij  srok nikogda
ne byli  udachnymi. Kto iz  nas  v  1975  godu  predskazal  mikrokomp'yuternuyu
revolyuciyu 80-h?
     Est'   i  drugie  prichiny  ogranichit'sya  desyatiletiem:   vse  kandidaty
pretendovali na  poluchenie  rezul'tatov nemedlenno. YA  ne  pomnyu ni  odnogo,
kotoryj  by skazal: "Esli segodnya vy sdelaete investicii v predlagaemoe mnoj
sredstvo, to po proshestvii 10 let nachnete pozhinat' plody".  Bolee  togo,  za
desyatiletie  sootnoshenie proizvoditel'nost'/cena  dlya  komp'yuterov  vyroslo,
navernoe, v  sotni raz, i neizbezhno  podsoznatel'no proizvoditsya  sravnenie,
kotoroe sovershenno nedopustimo. My navernyaka dostignem bol'shego progressa za
predstoyashchie 40 let. Rost za 40 let na poryadok edva li pokazhetsya chudom.
     Myslennyj eksperiment Harela. Harel predlagaet myslennyj eksperiment, v
kotorom "SPN" byla napisana v 1952 godu,  a ne v 1986, no soderzhala by te zhe
utverzhdeniya.  On  hochet  ispol'zovat'  eto  v  kachestve   dokazatel'stva  ot
protivnogo v bor'be protiv popytok otdelit' sushchnost' ot akcidencii.
     |to  dokazatel'stvo neverno. Vo-pervyh, "SPN" nachinaetsya s utverzhdeniya,
chto  dlya  programmirovaniya v  1950-h  harakterno  znachitel'noe  preobladanie
trudnostej  v  akcidenciyah  nad  trudnostyami  v sushchnosti. |togo preobladaniya
bol'she  ne  sushchestvuet,  chto privelo k  rostu  proizvoditel'nosti na poryadki
velichin. Perenosit' eto  dokazatel'stvo na  40 let nazad bessmyslenno: nikto
ne stal by v 1952  godu utverzhdat', chto ne trudnosti akcidencij otvetstvenny
za bol'shuyu chast' zatrachivaemyh usilij.
     Vo-vtoryh, Harel netochno predstavlyaet polozhenie del v 1950-h:
     |to bylo vremya, kogda  vmesto togo, chtoby razrabatyvat' bol'shie slozhnye
sistemy, programmisty pisali obychnye  odnopol'zovtel'skie programmy, kotorye
na sovremennyh yazykah programmirovaniya  zanyali  by 100-200  strok, i kotorye
dolzhny  byli vypolnyat'  skromnye algoritmicheskie  zadachi. Pri sushchestvovavshih
togda  tehnologiyah  i metodologiyah  takie  zadachi tozhe byli ochen'  trudnymi.
Splosh' i ryadom byli neudachi, oshibki, narushenie srokov.
     Zatem  on  opisyvaet,  kak  za  poslednie  25 let  upomyanutye neudachi,
oshibki, narushennye sroki v obychnyh malen'kih odnovol'zovatel'skih programmah
byli uluchsheny na poryadok.
     No  v  dejstvitel'nosti  v  1950-h godah  vershinoj  tehnologii  byli ne
malen'kie odnopol'zovatel'skie  programmy.  V  1952  godu  Univac  byl zanyat
obrabotkoj dannyh perepisi 1950 goda  s pomoshch'yu slozhnoj  programmy,  kotoruyu
razrabatyvali primerno vosem'  programmistov.13 Drugie mashiny  primenyalis' v
himicheskoj  dinamike,  raschetah rasseyaniya nejtronov, raschetah poleta raket i
t.d.14 Povsednevno  ispol'zovalis' assemblery, peremeshchayushchie  komponovshchiki  i
zagruzchiki, sistemy interpretacii s plavayushchej tochkoj i t.p.15
     K 1955  godu uzhe sozdavalis' programmy dlya biznesa ob®emom ot 50 do 100
cheloveko-let.16  V  1956  godu  na zavode  Dzheneral  |lektrik  v  L'yuisville
rabotala  programma  razmerom bolee 80  000 slov.  V 1957 godu v techenie uzhe
dvuh let v sisteme protivovozdushnoj oborony rabotal  komp'yuter SAGE ANFSQ/7,
i  na  30  ploshchadkah  dejstvovala sistema real'nogo vremeni,  ispol'zovavshaya
telekommunikacii i  dublirovanie v  celyah otkazoustojchivosti, ob®emom 75 000
komand.17 Edva  li mozhno priderzhivat'sya mneniya, chto razvitie tehnologij  dlya
odnopol'zovatel'skih  programm  -  glavnaya  harakteristika  usilij v tehnike
programmnogo obespecheniya posle 1952 goda.
     VOT  ONA.  Harel  prodolzhaet,  predlagaya  sobstvennuyu serebryanuyu  pulyu,
tehnologiyu  modelirovaniya  pod  nazvaniem  "Vanilla  Framework"  ("vanil'naya
struktura"). Sam podhod opisan  nedostatochno  podrobno, chtoby ego mozhno bylo
ochenit', no est' ssylka na stat'yu i tehnicheskij otchet, kotoryj v svoe  vremya
dolzhen  byt'  opublikovan v vide  knigi.18  Modelirovanie kasaetsya sushchnosti,
pravil'noj razrabotki i otladki ponyatij, poetomu  tehnologiya mozhet okazat'sya
revolyucionnoj. Nadeyus', chto eto tak. Ken Bruks soobshchaet, chto eta metodologiya
okazalas' poleznoj, kogda on popytalsya primenit' ee k real'noj zadache.
     Nezrimost'.   Harel  energichno  dokazyvaet,   chto   znachitel'naya  chast'
konceptual'noj  konstrukcii  programmnogo  obespecheniya   yavlyaetsya  po  svoej
prirode topologicheskoj  zadachej, i  eti  vzaimosvyazi nahodyat  sootvetstvie v
prostranstvenno-graficheskih predstavleniyah:
     Ispol'zovanie podhodyashchego vizual'nogo formalizma mozhet okazat' zametnoe
vozdejstvie na inzhenerov i programmistov. Bolee  togo,  eto  vozdejstvie  ne
ogranichivaetsya oblast'yu akcidencij, bylo obnaruzheno polozhitel'noe vliyanie na
kachestvo i bystrotu samogo ih myshleniya. V budushchem uspehi v razrabotke sistem
budut svyazany  s  vizual'nymi  predstavleniyami. Snachala  my budem  sozdavat'
koncepcii   s   pomoshch'yu   "pravil'nyh"   ob®ektov   i  vzaimosvyazej,   zatem
formulirovat'   nashi   koncepcii  kak   posledovatel'nyj   ryad   vse   bolee
obstoyatel'nyh  modelej  s ispol'zovaniem  podhodyashchej  kombinacii  vizual'nyh
yazykov. Imenno kombinacii,  poskol'ku modeli sistem imeyut neskol'ko  granej,
kazhdaya iz kotoryh vyzyvaet v voobrazhenii razlichnye vidy obrazov.
     ...Nekotorye  grani processa  modelirovaniya ne  stol'  legko  poddayutsya
horoshej vizualizacii.  Naprimer,  algoritmicheskie operacii nad peremennymi i
strukturami dannyh, vozmozhno, ostanutsya tekstual'nymi.
     Zdes' nashi  pozicii blizki. YA  dokazyval, chto  struktura  programmnogo
obespecheniya  ne  yavlyaetsya trehmernoj, poetomu  ne  sushchestvuet  estestvennogo
otobrazheniya konceptual'nogo proekta v diagrammu v prostranstve kak dvuh, tak
i  bol'shego  chisla  izmerenij. Harel  dopuskaet, i ya soglasen, chto trebuetsya
mnogo  diagramm,  kazhdaya  iz  kotoryh  ohvatyvaet  kakuyu-to odnu storonu,  a
nekotorye aspekty voobshche ploho otobrazhayutsya na diagrammah.
     YA vpolne razdelyayu ego entuziazm  po  povodu ispol'zovaniya diagramm  kak
vspomogatel'nogo sredstva pri  obdumyvanii i proektirovanii.  Dolgoe vremya ya
lyubil  zadavat' kandidatam  na rabotu  programmistom vopros: "Gde  nahoditsya
sleduyushchij noyabr'?".  Esli  vopros  kazhetsya  zagadochnym,  to  v  drugom vide:
"Kakova vasha myslennaya myslennaya  model' kalendarya?" U dejstvitel'no horoshih
programmistov horoshee chuvstvo prostranstva, u nih obychno est' geometricheskaya
model' vremeni,  i oni chasto bez truda  ponimayut  pervyj vopros.  Ih  modeli
ochen' individual'ny.
     Tochka zreniya Dzhonsa: proiszvoditel'nost' prihodit vsled za Kachestvom
     Kapers Dzhons (Capers Jones) snachala v serii sluzhebnyh zapisok, a zatem
v otdel'noj knige  demonstriruet glubokuyu  intuiciyu,  otmechennuyu neskol'kimi
moimi  korrespondentami.   "Stat'ya   "SPN",  kak  i  mnogie   v   to  vremya,
sosredotochilas' na  proizvoditel'nosti  -  vyhode  programmnoj  produkcii na
edinicu vhodnyh  zatrat",  -  govorit  Dzhons.  -  "Net,  sosredotoch'tes'  na
kachestve,  a  proizvoditel'nost'  pridet   sledom."19   On  utverzhdaet,  chto
dorogostoyashchie i narushivshie sroki proekty trebuyut bol'she vsego dopolnitel'nyh
usilij i vremeni dlya  poiska i ustraneniya oshibok v specifikaciyah, v proekte,
v razrabotke. On privodit dannye,  svidetel'stvuyushchie  o  sil'noj  korrelyacii
mezhdu otsutstviem sistematicheskogo kontrolya kachestva i sryvom grafika rabot.
YA  im  vpolne  veryu.  Bem (Boehm)  ukazyvaet,  chto proizvoditel'nost'  snova
padaet, kogda  presleduetsya  isklyuchitel'no  vysokoe  kachestvo,  kak  bylo  v
programmah IBM dlya kosmicheskogo chelnoka.
     Analogichnym    obrazom,   Koki   (Coqui)   utverzhdaet,   chto   principy
sistematicheskoj  razrabotki  programmnogo  obespecheniya  yavilis'  otvetom  na
ozabochennost'   ne  stol'ko  proizvoditel'nost'yu,   skol'ko   kachestvom   (v
osobennosti, stremleniem izbezhat' krupnyh katastrof).
     No  obratite   vnimanie:  cel'yu  primeneniya   inzhenernyh   principov  k
razrabotke programmnogo  obespecheniya v 1970-h  godah bylo  podnyat' kachestvo,
testiruemost',  ustojchivost'  i predskazuemost' programmnyh produktov, a  ne
obyazatel'no proizvoditel'nost' truda programmistov.
     Dvizhushchej   siloj  ispol'zovaniya   pri  razrabotke   programm  principov
programmnoj inzhenerii bylo opasenie krupnyh avarij, k kotorym mogla privesti
razrabotka vse bolee slozhnyh sistem neupravlyaemymi hudozhnikami.20
     Tak chto zhe sluchilos' s proizvoditel'nost'yu?
     Proizvoditel'nost'  v cifah. Cifry, harakterizuyushchie proizvoditel'nost',
ochen' tyazhelo opredelit', kalibrovat' i  najti. Kapers Dzhons schitaet, chto dlya
dvuh  odinakovyh  programm  na Cobol,  napisannyh  s intervalom v 10 let - s
primeneniem   strukturnogo   programmirovaniya  i   bez  nego  -   raznica  v
proizvoditel'nosti troekratnaya.
     |d Jordon  (Ed Yourdin)  utverzhdaet:  "Po  moim nablyudeniyam,  blagodarya
rabochim stanciyam i programmnym instrumentam proizvoditel'nost' uvelichilas' v
pyat'   raz."  Tom  Demarko   (Tom  DeMarco)  schitaet,  chto   "vashe  ozhidanie
desyatikratnogo rosta  proizvoditel'nosti  za 10 let  blagodarya celomu naboru
tehnologij bylo optimistichnym: mne  neizvestny organizacii, dobivshiesya rosta
proizvoditel'nosti na poryadok."
     Programma  v upakovke: pokupajte, ne nado razrabatyvat'. Odna iz ocenok
"SPN"   okazalas',  ya  dumayu,  pravil'noj:  "Vozniknovenie  massovogo  rynka
yavlyaetsya...   naibolee   glubokoj   dolgosrochnoj  tendenciej   v  razrabotke
programmnogo obespecheniya". S tochki zreniya nauki, programmnoe obespechenie dlya
massovogo rynka obrazuet prakticheski novuyu otrasl' v sravnenii s razrabotkoj
zakaznyh  programm  kak vnutri firmy,  tak i storonnimi organizaciyami. Kogda
schet  prodannyh  paketov  idet na milliony ili hotya by  na  tysyachi, glavnymi
problemami stanovyatsya  kachestvo, svoevremennost', tehnicheskie harakteristiki
i  stoimost'  podderzhki,  a  ne stoimost'  razrabotki,  kotoraya  imeet takoe
bol'shoe znachenie pri razrabotke zakaznyh sistem.
     |lektroinstrument  dlya uma. Luchshij sposob  povysit'  proizvoditel'nost'
truda programmistov informacionno-upravlyayushchih sistem - eto pojti v blizhajshij
komp'yuternyj  magazin  i   kupit'  uzhe  gotovym  to,  chto   oni   sobirayutsya
razrabotat'. |to ne  shutka: dostupnost' deshevyh i moshchnyh korobochnyh programm
udovletvorila  mnogie  iz  potrebnostej,  ranee  udovletvoryavshihsya zakaznymi
programmami. |ti elektroinstrumenty  dlya uma bol'she pohozhi na  elektricheskte
dreli, pily i shlifoval'nye mashiny, chem na bol'shie i slozhnye proizvodstvennye
stanki. Integraciya  ih v sovmestimye  i perekrestno-svyazannye  nabory, takie
kak  Microsoft Works  ili  luchshe  integrirovannyj ClarisWorks,  obespechivaet
ogromnuyu  gibkost'. I  podobno domashnej kollekcii instrumenta, v  rezul'tate
chastogo  ispol'zovaniya nabol'shogo  nabora  dlya  raznyh  zadach vyrabatyvayutsya
privychnye  navyki.  Takoj  instrument  podcherkivaet  prostotu  ispol'zovaniya
obychnym pol'zovatelem, dazhe ne professionalom.
     Ivan Selin (Ivan Selin), glava American Management Systems pisal  mne v
1987 godu:
     YA hochu pridrat'sya k vashemu utverzhdeniyu,  chto v  dejstvitel'nosti pakety
ne nastol'ko izmenilis'... YA dumayu, chto vy slishkom  legko otbrosili  glavnye
sledstviya  vashego zamechaniya, chto (programmnye  pakety) "mogut  byt'  nemnogo
bolee obshchimi  i nemnogo luchshe  nastraivaemymi, chem  ran'she,  no ne namnogo".
Dazhe  prinimaya eto zayavlenie  za chistuyu monetu, ya polagayu,  chto pol'zovateli
rascenivayut  pakety,  kak  obladayushchie  bolee shirokimi  vozmozhnostyami i legche
nastraivaemye, i chto takoe vospriyatie delaet pol'zovatelej bolee podatlivymi
pered  paketami.  V   bol'shinstve  sluchaev,  izvestnyh  moej  kompanii,   ne
programmisty,   a  (konechnye)  pol'zovateli  neohotno  pol'zuyutsya  paketami,
pokskol'ku  dumayut,  chto  lishatsya vazhnyh  vozmozhnostej i  funkcij,  a potomu
vozmozhnost'  legkoj  nastrojki  ves'ma  povyshaet  dlya nih  privlekatel'nost'
produkta.
     YA  dumayu,  chto  Selin  sovershenno  prav:  ya  nedoocenil  kak  stepen'
nastraivaemosti paketa, tak i vazhnost' etogo faktora.
     Ob®ektno-orientirovannoe programmirovanie: a medna pulya ne podojdet?
     Razrabotka  iz  bol'shih chastej. Esli  osushchestvlyat'  sborku  iz  chastej,
kotorye  dostatochno  slozhny  i  imeyut  odnorodnye  interfejsy,  mozhno bystro
obrazovyvat' dovol'no bogatye struktury.
     Soglasno    odnomu    iz    vzglyadov     na    ob®ektno-orientirovannoe
programmirovanie   eta   disciplina   osushchestvlyaet  modul'nost'   i   chistye
interfejsy.  Drugaya  tochka  zreniya podcherkivaet inkapsulyaciyu - nevozmozhnost'
uvidet'  i eshche  menee  izmenit' vnutrennyuyu strukturu detali.  Eshche odna tochka
zreniya otmechaet nasledovanie i  soputstvuyushchuyu  emu  ierarhicheskuyu  strukturu
klassov  s virtual'nymi  funkciyami.  I eshche odin vzglyad:  vazhnejshej  yavlyaetsya
sil'naya abstraktnaya tipizaciya dannyh vmeste s garantiyami, chto konkretnyj tip
dannyh budet obrabatyvat'sya tol'ko primenimymi k nemu operaciyami.
     V  nastoyashchee  vremya  ne  nuzhen  ves' paket  Smalltalk  ili  C++,  chtoby
ispol'zovat'  lyuboj   iz   etih   disciplin  -   mnogie  iz   nih  poglotili
ob®ektno-orientirovannye    tehnologii.    Ob®ektno-orientirovannyj   podhod
privlekatelen,   kak  polivitaminy:   odnim   mahom  (t.e.   perepodgotovkoj
programmista) poluchaesh' vse. Ochen' mnogoobeshchayushchaya koncepciya.
     Pochemu  ob®ektno-orientirovannaya  tehnologiya  medlenno  razvivalas'?  V
techenie  devyati  let  posle vyhoda "SPN"  nadezhdy  neuklonno  rosli.  Pochemu
razvitie  bylo  takim medlennym?  Teorij  mnogo. Dzhejms Koggins,  v  techenie
chetyreh let vedushchij kolonku v The C++ Report, daet takoe ob®yasnenie:
     Problema v tom, chto programmisty, rabotayushchie  v OOP, eksperimentirovali
s  krovosmesitel'nymi  prilozheniyami  i   byli  naceleny  na  nizkij  uroven'
abstrakcii.  Naprimer,  oni  stroili takie  klassy, kak  "svyazannyj  spisok"
vmesto "interfejs pol'zovatelya", ili "luch radiacii", ili "model' iz konechnyh
elementov".  K  neschast'yu,   strogaya   proverka  tipov,   kotoraya   pomogaet
programmistam  C++  izbegat'   oshibok,  odnovremenno  zatrudnyaet  postroenie
bol'shih ob®ektov iz malen'kih.21
     On   vozvrashchaetsya   k   fundamental'noj   probleme  programmirovaniya  i
dokazyvaet,  chto odin iz  sposobov  udovletvorit' potrebnost' v  programmnom
obespechenii  -  uvelichit'  chislennost'  obrazovannoj   rabochej   sily  putem
podgotovki i privlecheniya nashih klientov. V pol'zu nishodyashchego proektirovaniya
privodyatsya takie argumenty:
     Esli  my  proektiruem  krupnye  klassy,   predstavlyayushchie  koncepcii,  s
kotorymi  nashi   klienty  uzhe  rabotayut,  to  oni  v  sostoyanii  ponimat'  i
kritikovat' proekt po mere ego razvitiya, a takzhe vmeste s nami razrabatyvat'
kontrol'nye  primery.  Oftal'mologov,  s  kotorymi  ya  rabotayu,  ne  volnuet
organizaciya  steka; ih  volnuet opisanie formy rogovicy s  pomoshch'yu polinomov
Lezhandra. Malen'kaya inkapsulyaciya daet i malen'kuyu vygodu.
     Devid  Parnas,  ch'ya stat'ya  byla  odnim  iz istochnikov  idej  ob®ektno-
orientirovannogo programmirovaniya, smotryat na veshchi po inomu. On pisal mne:
     Otvet prost. |to  iz-za privyazannosti  OOP  k  slozhnym  yazykam.  Vmesto
ob®yasneniya lyudyam,  chto OOP yavlyaetsya vidom  proektirovaniya,  i  vooruzheniya ih
principami  proektirovaniya,   ih   uchili,   chto  OOP  -  eto   ispol'zovanie
opredelennogo  instrumenta.  Lyubymi  sradstvami  mozhno  pisat'  i  plohie, i
horoshie programmy.  Esli ne uchit' lyudej proektirovaniyu,  to yazyki  ne  imeyut
bol'shogo znacheniya. Rezul'tatom budut plohie razrabotki s pomoshch'yu etih yazykov
i malaya vygoda. A esli vygoda nevelika, to OOP ne vojdet v modu.
     Rashody    sejchas,   pribyl'   potom.    Po   moemu    mneniyu,    u
ob®ektno-orientirovannyh   metodologij   osobenno  tyazhelyj  sluchaj  bolezni,
harakternoj dlya mnogih  usovershenstvovanij v metodologii. Ves'ma sushchestvenny
predvaritel'nye izderzhki -  v osnovnom,  chtoby nauchit' programmistov myslit'
sovershenno po novomu, a takzhe na preobrazovanie funkcij v obobshchennye klassy.
Vygody,  kotorye  ya  schitayu   real'nymi,   a  ne  chisto  predpolozhitel'nymi,
dostigayutsya  vo  vremya  vsego  cikla razrabotki,  no  nastoyashchaya  okupaemost'
proishodit pri razrabotke posleduyushchih programm, rasshirenii i  soprovozhdenii.
Koggins  kovorit:  "Ob®ektno-orientirovannoe  programmirovanie   ne  uskorit
razrabotku pervogo proekta, tak zhe kak i vtorogo. A vot pyatyj proekt iz togo
zhe semejstva budet sdelan ochen' bystro."22
     Riskovat'   real'nymi  nachal'nymi  den'gami  radi   predpolagaemyh,  no
neopredelennyh pribylej v budushchem - eto to, chem investory zanimayutsya izo dnya
v den'.  Odnako vo  mnogih programmiruyushchih organizaciyah menedzheram trebuetsya
dlya etogo smelost' - kachestvo bolee redkoe,  chem kompetenciya  v  tehnicheskih
voprosah ili  administrativnoe  masterstvo. YA  polagayu, chto  krajnyaya stepen'
avansiroaniya rashodov i  otkladyvaniya pribyli  yavlyaetsya  samym  sushchestvennym
faktorom, zamedlyayushchim prinyatie O-O tehnologij. No dazhe v takih usloviyah C++,
pohozhe, uverenno  vytesnyaet  C  vo  mnogih  organizaciyah.  CHto  s  povtornym
ispol'zovaniem? Luchshij  sposob spravit'sya  s razrabotkoj  chasti  programmnoj
sistemy, otnosyashchejsya k ee sushchnosti  - eto voobshche ee ne razrabatyvat'. Pakety
programm  -  odin  iz  sposobov  sdelat'  eto.  Drugoj  sposob  -  povtornoe
ispol'zovanie.  Dejstvitel'no,  odnoj  iz  naibolee   privlekatel'nyh   chert
ob®ektno-orientirovannogo  programmirovaniya   yavlyaetsya   obeshchanie   prostoty
povtornogo ispol'zovaniya klassov v sochetanii s legkost'yu nastrojki blagodarya
nasledovaniyu.
     Kak  chasto  byvaet, posle polucheniya nekotorogo  opyta raboty  po  novoj
tehnologii obnaruzhivaetsya,  chto ona ne  tak prosta, kak kazalos'  na  pervyj
vzglyad.
     Konechno,   programmisty   vsegda   povtorno  ispol'zovali   sobstvennye
razrabotki. Dzhons pishet:
     U  naibolee  opytnyh   programmistov  est'  svoi   lichnye   biblioteki,
pozvolyayushchie  im pri razrabotke  novyh programm povtorno  ispol'zovat' do 30%
koda po ob®emu. Na korporativnom urovne povtornoe ispol'zovanie priblizhaetsya
k  75%  po  ob®emu  i trebuet  special'nyh  bibliotek  i  administrirovaniya.
Povtornoe ispol'zovanie koda  v korporativnyh masshtabah trebuet izmenenij  v
buhgalterii proekta i metodah izmereniya raboty.23
     U. Huan (W.  Huang)  predlozhil organizaciyu programmnogo  proizvodstva s
matrichnoj strukturoj upravleniya funkcional'nymi specialistami, chtoby derzhat'
pod   kontrolem  ih  estestvennuyu   sklonnost'  k  povtornomu  ispol'zovaniyu
sobstvennogo koda.24
     Van  SHnajder  (Van  Snyder)  iz  JPL  napominaet  mne,  chto  v   krugah
razrabotchikov  matematicheskogo  programmnogo  obespecheniya sushchestvuet  davnyaya
tradiciya povtornogo ispol'zovaniya programm:
     My polagaem, chto prepyatstviya k povtornomu ispol'zovaniyu voznikayut ne so
storony  proizvoditelya,  a   so   storony   potrebitelya.  Esli   razrabotchik
programmnogo obespecheniya - potencial'nyj potrebitel' standartnyh programmnyh
komponentov - schitaet,  chto najti i proverit' nuzhnyj  komponent dorozhe,  chem
napisat' ego  zanovo, znachit,  budet  napisan  novyj  komponent, dubliruyushchij
prezhnij.  Obratite  vnimanie,  my  skazali  "schitaet" -  real'naya  stoimost'
povtornoj razrabotki ne imeet znacheniya.
     Povtornoe ispol'zovanie koda imeet uspeh  pri razrabotke matematicheskih
programm.   Prichin   etomu   dve:   1)   eto   magiya,  trebuyushchaya   ogromnogo
intellektual'nogo vklada v kazhduyu strochku koda,  i  2) sushchestvuet bogataya  i
standartnaya   terminologiya,    a   imenno   -   matematika,   dlya   opisaniya
funkcional'nosti    lyubyh    komponentov.   Poetomu   povtorno   razrabotat'
matematicheskij  komponent stoit  dorogo, a  razobrat'sya  v  funkcional'nosti
stoit    deshevo.   Davnyaya    tradiciya   publikacii   i   sbora    algoritmov
professional'nymi  zhurnalami i  predlozheniya ih po umerennoj  cene,  a  takzhe
kommercheskoe  predlozhenie  vysokokachestvennyh algoritmov po  neskol'ko bolee
vysokoj, no vse zhe skromnoj cene, delayut  poisk trebuemyh komponentov proshche,
chem v drugih oblastyah, gde chasto nevozmozhno tochno i szhato opisat' trebuemoe.
Blagodarya   sovmestnomu  dejstviyu   etih  faktorov  povtornoe  ispol'zovanie
matematicheskih programm bolee privlekatel'no, chem povtornoe ih izobretenie.
     Takoe  zhe yavlenie povtornogo ispol'zovaniya  obnaruzhivaetsya i v drugih
soobshchestvah,   naprimer,  v  razrabotke   programm  dlya  atomnyh  reaktorov,
modelirovaniya klimata,  modelirovaniya okeanov -  po tem zhe  samym  prichinam.
Kazhdoe iz etih soobshchestv vyroslo na odnih i  teh zhe uchebnikah, s odnoj i toj
zhe sistemoj oboznachenij.
     Kak segodnya  obstoyat  dela s povtornym  ispol'zovaniem na korporativnom
urovne?  Provedeno   mnozhestvo  issledovanij,  a  vot  praktikuetsya   v  SSHA
otnositel'no malo. CHto  zhe kasaetsya povtornogo ispol'zovaniya za  rubezhom, to
tut imeyut mesto nepravdopodobnye otchety.25
     Dzhons  soobshchaet,  chto  vse  klienty  ego  firmy,  u kotoryh bolee  5000
programmistov, provodyat formal'nye issledovaniya povtornoj  ispol'zuemosti, v
to vremya kak iz chisla klientov s  500 i menee programmstami eto delaet menee
10  procentov.26   Po  ego  soobshcheniyu,  v  otraslyah  s  vysokim  potencialom
povtornogo ispol'zovaniya  issledovaniya  (ne realizaciya) "vedutsya  aktivno  i
energichno, dazhe  esli ne vpolne uspeshno". |d  Jordon soobshchaet  o programmnoj
firme v Manile, v kotoroj 50 programmistov iz obshchego chisla 200 zanyaty tol'ko
razrabotkoj   povtorno   ispol'zuemyh  modulej   dlya   ispol'zovaniya   vsemi
ostal'nymi, i chto v teh sluchayah, kotorye on videl, prinyatie etoj  tehnologii
bylo vyzvano  organizacionnymi,  a  ne tehnicheskimi  faktorami  -  naprimer,
sistemoj pooshchrenij.
     Demarko  soobshchaet  mne,   chto  nalichie  massovyh  rynochnyh   paketov  i
vozmozhnost' predostavleniya imi obshchih  funkcij, takih kak sistemy baz dannyh,
sushchestvenno  snizili  kak  nastoyatel'nost',   tak  i  predel'nuyu  poleznost'
povtornogo   ispol'zovaniya   modulej   sobstvennyh   prilozhenij.   "Povtorno
ispol'zuemye  moduli  imeli  tendenciyu  v  konce koncov  stanovit'sya  obshchimi
funkciyami."
     Parnas pishet sleduyushchee:
     Povtornoe  ispol'zovanie  -   eto  to,   o   chem  legche  govorit',  chem
osushchestvit'.  Dlya  nego trebuyutsya kak horoshee  proektirovanie,  tak  i ochen'
horoshaya dokumentaciya. Dazhe kogda my vidim  horoshee proektirovanie,  chto  po-
prezhnemu   ne   chasto,   bez   horoshej  dokumentacii  komponenty  ne   budut
ispol'zovat'sya povtorno.
     Ken Bruks soobshchaet, chto trudno  rasschitat', kakaya stepen' obobshchennosti
okazhetsya  neobhodimoj:  "Mne  prihoditsya  menyat'  veshchi,  dazhe  v  pyatyj  raz
ispol'zuya sobstvennuyu biblioteku pol'zovatel'skih interfejsov."
     Real'no  povtornoe ispol'zovanie tol'ko nachinaetsya. Dzhons soobshchaet, chto
na otkrytom  rynke  est' neskol'ko modulej s povtorno ispol'zuemym  kodom po
cene  ot  1  do  20  procentov ot  obychnoj  stoimosti razrabotki.27  Demarko
govorit:
     Menya  vse  bolee   obeskurazhivaet   vsya   eta   istoriya   s   povtornym
ispol'zovaniem. Prakticheski otsutstvuet teorema sushchestvovaniya dlya povtornogo
ispol'zovaniya. Vremya  podtverdilo, chto sdelat'  veshchi povtorno  ispol'zuemymi
stoit dorogo.
     Jordon  daet  ocenku  togo, skol'ko eto stoit:  "Horoshee empiricheskoe
pravilo  govorit,  chto  povtorno  ispol'zuemye  komponenty  potrebuyut  vdvoe
bol'shih zatrat, chem "odnorazovye" komponenty."28 YA rassmatrivayu etu cenu kak
velichinu zatrat na zapusk komponentov  v proizvodstvo, obsuzhdavshuyusya v glave
1, poetomu ya ocenivayu rost zatrat kak troekratnyj.
     Konechno, my vidim razlichnye formy i varianty povtornogo  ispol'zovaniya,
no  ono daleko ne tak shiroko primenyaetsya, kak my predpolagali. Predstoit eshche
mnogoe ponyat'.
     Ponimanie   bol'shih   slovarej:   neozhidannaya    problema    povtornogo
ispol'zovaniya, kotoruyu mozhno bylo predvidet'
     CHem  vyshe uroven',  na  kotorom osushchestvlyaetsya  myshlenie,  tem  bolee
mnogochislenny primitivnye sostavlyayushchie  mysli,  s kotorymi prihoditsya  imet'
delo.  Tak,  yazyki  vysokogo  urovnya  gorazdo  slozhnee  mashinnyh  yazykov,  a
estestvennye  yazyki  eshche  bolee  slozhny.  U yazykov  vysokogo  urovnya  bol'she
slovari, bolee slozhnyj sintaksis i bolee strogaya semantika.
     Kak  nauchnaya  disciplina,  my ne vzvesili  posledstviya  etogo fakta dlya
povtornogo   ispol'zovaniya    programm.    CHtoby    povysit'    kachestvo   i
proizvoditel'nost',  my  hotim stroit' programmy  iz  chastej  s  otlazhennymi
funkciyami,  kotorye  sushchestvenno   vyshe  po  urovnyu,  chem  operatory  yazykov
programmirovaniya. Poetomu, delaem  li my eto s pomoshch'yu bibliotek klassov ili
bibliotek procedur, nam  pridetsya  stolknut'sya s rezkim uvelicheniem razmerov
nashih  slovarej  programmirovaniya. Izuchenie slovarya  sostavlyaet znachitel'nuyu
chast' prepyatstvij k povtornomu ispol'zovaniyu.
     Na segodnyashnij den' est'  biblioteki klassov, naschityvayushchie  svyshe 3000
chlenov. Mnogie ob®ekty trebuyut zadaniya  ot 10 do 20 parametrov i peremennyh-
pereklyuchatelej.  Vsyakij,  ispol'zuyushchij  takuyu  biblioteku,  dolzhen   izuchit'
sintaksis (vneshnie interfejsy) i semantiku (podrobnoe  povedenie funkcii) ee
chlenov,   esli   sobiraetsya  polnost'yu   realizovat'   potencial  povtornogo
ispol'zovaniya.
     |ta zadacha vovse ne beznadezhna.  Obychno chelovek ispol'zuet okolo  10000
slov rodnogo yazyka, obrazovannye lyudi - znachitel'no bol'she. Kakim-to obrazom
my  obuchaemsya sintaksisu  i  tonkim  semanticheskim  razlichiyam. My  pravil'no
operedelyaem   razlichiya  mezhdu  slovami  gigantskij,  ogromnyj,  prostrannyj,
kolossal'nyj,  gromadnyj  -  nikto  ne  govorit  o  kolossal'nyh pustynyah  i
prostrannyh slonah.
     Nuzhny  dopolnitel'nye   issledovaniya,  chtoby  mozhno  bylo  primenit'  k
probleme  povtornogo  ispol'zovaniya programm sushchestvuyushchie znaniya  o tom, kak
lyudi ovladevayut yazykom. Nekotorye vyvody neposredstvenno ochevidny:
     -   Obuchenie  proishodit   v   kontekste   predlozheniya,  poetomu  nuzhno
publikovat'  mnogochislennye  primery   sostavnyh  produktov,  a   ne  prosto
biblioteki sostavlyayushchih chastej.
     -   CHelovek  zapominaet  tol'ko  pravopisanie.  Sintaksis  i  semantika
izuchayutsya postepenno, v kontekste, putem primeneniya.
     - CHelovek gruppiruet pravila soedineniya slov v sintaksicheskie klassy, a
ne v sovmestimye podmnozhestva ob®ektov.
     CHistyj itog po pulyam: polozhenie prezhnee
     Itak,  my  vozvrashchaemsya  k  osnovam.  Slozhnost'  -  eto  to,  chem  my
zanimaemsya, i slozhnost' -  eto to,  chto nas ogranichivaet. R. L. Glass (R. L.
Glass) pisal v 1988 godu, tochno summiruya moi vzglyady 1995 goda:
     Tak chto zhe v itoge soobshchili nam Parnas i Bruks? CHto razrabotka programm
yavlyaetsya konceptual'no slozhnym  zanyatiem. CHto  volshebnye resheniya ne lezhat za
kazhdym uglom. CHto zanimayushchimsya etim  delom  pora izuchit' dostizheniya, imeyushchie
evolyucionnyj harakter, a ne zhdat' revolyuciyu i ne nadeyat'sya na nee.
     Nekotorye schitayut eto bezradostnoj kartinoj. |to te,  kto polagal,  chto
vot-vot nastupit proryv.
     No  nekotorye  iz  nas  -  dostatochno  svarlivye,  chtoby  schitat'  sebya
realistami,  - otnosyatsya k  etomu  kak  k glotku svezhego vozduha. Nakonec-to
mozhno sosredotochit'sya na chem-to bolee  blizkom k zhizni, chem zhuravl'  v nebe.
Teper',  veroyatno,  my  smozhem  zanyat'sya  postepennymi  usovershenstvovaniyami
proizvodstva programmnogo obespecheniya, kotorye dejstvitel'no dostizhimy, a ne
zhdat' proryvov, kotorye vryad li kogda-libo proizojdut.29

        Glava   18.   Zayavleniya   "Mificheskogo   cheloveko-mesyaca":   pravda  ili
lozh'?     Kratkost' ochen' polezna,
     Kogda nas ponimayut ili ne ponimayut.
     S|MYU|L BATLER, "GUDIBRAS"
     Segodnya  o  tehnike  razrabotki  programmnogo  obespecheniya  izvestno
znachitel'no bol'she,  chem v  1975 godu. Kakie iz utverzhdenij, soderzhashchihsya  v
pervom  izdanii  1975  goda, podtverdilis'  opytom  i  dannymi?  Kakie  byli
oprovergnuty? Kakie ustareli  v nashem izmenchivom mire? CHtoby vam  legche bylo
sudit',  zdes', v  vide  svodki, privedeny vazhnejshie utverzhdeniya  knigi 1975
goda, kotorye ya  schital vernymi:  fakty i  izvlechennye iz opyta prakticheskie
pravila,  privedennye s  sohraneniem iznachal'nogo  smysla.  (Mozhno  zadat'sya
voprosom:  esli eto  vse, chto bylo  skazano v pervonachal'nom izdanii, pochemu
togda eto zanyalo tak mnogo mesta?) V skobkah privedeny svezhie kommentarii.
     Bol'shinstvo etih predlozhenij mozhno proverit'  na praktike. Izlagaya ih v
szhatoj  forme,  ya  nadeyus'  skoncentrirovat'  mysli  chitatelya,  izmereniya  i
kommentarii.
     Glava 1. Smolyanaya yama
     1.1 Dlya sozdaniya sistemnogo programmnogo produkta trebuetsya primerno v
devyat'  raz  bol'she usilij  po  sravneniyu  s  sostavlyayushchimi ego programmami,
napisannymi otdel'no dlya chastnogo ispol'zovaniya. Po moej ocenke, prevrashchenie
programmy  v  produkt  vvodit   koefficient,  ravnyj  trem;  proektirovanie,
integraciya   i   testirovanie   komponentov,   kotorye   dolzhny   obrazovat'
soglasovannuyu sistemu,  takzhe  vvodit  koefficient,  ravnyj  trem;  vse  eti
sostavlyayushchie stoimosti sushchestvenno nezavisimy drug ot druga.
     1.2 Zanyatie programmirovaniem "otvechaet glubokoj vnutrennej potrebnosti
v tvorchestve  i udovletvoryaet chuvstvennye potrebnosti, kotorye est' u vseh u
nas", dostavlyaya pyat' vidov radosti:
     - Radost', poluchaemaya pri sozdanii chego-libo svoimi rukami.
     - Udovol'stvie sozdavat' veshchi, kotorye mogut byt' polezny drugim lyudyam.
     -  Ocharovanie  sozdaniya  slozhnyh  golovolomnyh  ob®ektov,  sostoyashchih iz
vzaimodejstvuyushchih dvizhushchihsya chastej.
     - Radost', poluchaemaya ot  neizmennogo uznavaniya novogo, nepovtoryaemosti
zadachi.
     -  Udovol'stvie  ot  raboty  so stol'  podatlivym  materialom -  chistoj
mysl'yu, kotoryj, tem ne menee, sushchestvuet, dvizhetsya i  rabotaet tak, kak  ne
mogut slovesnye ob®ekty.
     1.3 V to zhe vremya etomu zanyatiyu prisushchi i ogorcheniya:
     -  Pri  izuchenii programmirovaniya trudnee vsego privyknut' k trebovaniyu
sovershenstva.
     - Postanovka zadach osushchestvlyaetsya  drugimi lyud'mi i prihoditsya zaviset'
ot veshchej (osobenno, programm), kotorye nel'zya  kontrolirovat'; polnomochiya ne
sootvetstvuyut otvetstvennosti.
     -  Strashno  tol'ko  na slovah:  fakticheskaya  vlast'  priobretaetsya  kak
sledstvie uspeshnogo vypolneniya zadach.
     - Programmnyj proekt priblizhaetsya k  okonchatel'nomu vidu tem medlennee,
chem blizhe okonchanie, hotya kazhetsya, chto k koncu shodimost'  dolzhna byt' bolee
bystroj.
     -  Programmnomu  produktu  grozit ustarevanie eshche  do  ego  zaversheniya.
Nastoyashchij tigr - ne para bumazhnomu, esli trebuetsya real'noe ispol'zovanie.
     Glava 2. Mificheskij cheloveko-mesyac
     2.1 Programmnye proekty chashche provalivayutsya iz-za nehvatki kalendarnogo
vremeni, chem po vsem ostal'nym prichinam, vmeste vzyatym.
     2.2  CHtoby prigotovit'  vkusnuyu pishchu,  nuzhno  vremya;  nekotorye  zadachi
nel'zya uskorit', ne isportiv rezul'tat.
     2.3 Vse programmisty yavlyayutsya optimistami: "Vse budet horosho".
     2.4  Poskol'ku programmist  rabotaet  s  chistymi ideyami,  my ne ozhidaem
osobyh trudnostej pri realizacii.
     2.5 No sami nashi idei byvayut oshibochnymi - otsyuda i oshibki v programmah.
     2.6  Nashi  metody  ocenivaniya, osnovannye  na uchete  zatrat,  smeshivayut
zatraty  s  poluchennym  rezul'tatom.  CHeloveko-mesyac  yavlyaetsya  oshibochnym  i
opasnym zabluzhdeniem, poskol'ku predpolagaet, chto mesyacy  i kolichestvo lyudej
mozhno menyat' mestami.
     2.7 Razdelenie zadachi mezhdu neskol'kimi lyud'mi vyzyvaet dopolnitel'nye
zatraty na obuchenie i obmen informaciej.
     2.8 Moe prakticheskoe pravilo: 1/3 vremeni - na proektirovanie, 1/6 - na
napisanie programmy, 1/4 - na testirovanie komponentov i 1/4  - na sistemnoe
testirovanie.
     2.9 Kak nauchnoj discipline nam ne hvataet metodov ocenki.
     2.10  Poskol'ku my ne uvereny v  svoih ocenkah srokov raboty, nam chasto
ne dostaet smelosti upryamo otstaivat' ih pod nazhimom rukovodstva i klientov.
     2.11  Zakon Bruksa: esli proekt ne ukladyvaetsya v sroki,  to dobavlenie
rabochej sily zaderzhit ego eshche bol'she.
     2.12  Dobavlenie  rabochej  sily uvelichivaet  obshchij  ob®em zatrat  tremya
putyami:  trud  po perekraivaniyu  zadach  i  proishodyashchee  pri etom  narushenie
raboty, obuchenie novyh lyudej, dopolnitel'noe obshchenie.
     Glava 3. Operacionnaya brigada
     3.1  Samye  luchshie  programmisty-professionaly v 10  raz produktivnee
slabyh pri ravnoj podgotovke i dvuhletnem stazhe (Sakman, Grant i |rikson).
     3.2 Dannye  Sakmana,  Granta  i  |riksona  ne vyyavili  korrelyacii mezhdu
opytom i produktivnost'yu. YA dumayu, chto eto vsegda tak.
     3.3  Luchshe vsego  imet' malen'kuyu aktivnuyu komandu  - kak mozhno  men'she
myslitelej.
     3.4 CHasto luchshe vsego,  esli  komanda sostoit iz dvuh chelovek, odin  iz
kotoryh yavlyaetsya liderom. (Obratite vnimanie, kak Bogom zaduman brak.)
     3.5  Dlya  sozdaniya  dejstvitel'no  krupnyh  sistem  malen'kaya  aktivnaya
komanda rabotaet slishkom medlenno.
     3.6   Opyt  razrabotki   bol'shinstva   dejstvitel'no   bol'shih   sistem
pokazyvaet,  chto  podhod  k  uskoreniyu  s  pozicij gruboj  sily  okazyvaetsya
dorogostoyashchim, medlennym,  neeffektivnym  i privodit k poyavleniyu  sistem, ne
yavlyayushchihsya konceptual'no celostnymi.
     3.7  Organizaciya po tipu hirurgicheskih brigad s  glavnym  programmistom
predlagaet   sposob   dostizheniya   celostnosti   produkta   blagodarya    ego
proektirovaniyu v neskol'kih golovah i obshchej produktivnosti blagodarya nalichiyu
mnogochislennyh pomoshchnikov pri radikal'no sokrashchennom obmene informaciej.
     Glava 4. Aristokratiya, demokratiya i sistemnoe proektirovanie
     4.1 "Konceptual'naya celostnost' yavlyaetsya naibolee  vazhnym soobrazheniem
pri proektirovanii sistem."
     4.2    "Okonchatel'nuyu    ocenku   proektu    sistemy   daet   otnoshenie
funkcional'nosti k slozhnosti koncepcij", a ne tol'ko bogatstvo funkcij. (|to
sootnoshenie  yavlyaetsya  meroj   prostoty  ispol'zovaniya,  prigodnoj  kak  dlya
prostogo, tak i dlya slozhnogo ispol'zovaniya.)
     4.3 Dlya dostizheniya konceptual'noj celostnosti proekt dolzhen sozdavat'sya
odnim chelovekom ili gruppoj edinomyshlennikov.
     4.4   "Otdelenie   razrabotki  arhitektury   ot   realizacii   yavlyaetsya
effektivnym  sposobom dostizheniya konceptual'noj  celostnosti  pri rabote nad
ochen' bol'shimi proektami." (I malen'kimi tozhe.)
     4.5   "Esli  vy   hotite,   chtoby   sistema   obladala   konceptual'noj
celostnost'yu,  kto-  to  odin  dolzhen  vzyat'  rukovodstvo  koncepciyami.  |to
aristokratizm, kotoryj ne nuzhdaetsya v izvineniyah."
     4.6   Disciplina  polezna  iskusstvu.   Poluchenie   arhitektury   izvne
usilivaet, a ne podavlyaet tvorcheskuyu aktivnost' gruppy ispolnitelej.
     4.7  Konceptual'no   celostnye   sistemy  bystree   razrabatyvayutsya   i
testiruyutsya.
     4.8  Proektirovanie  arhitektury,  razrabotku  i   realizaciyu  mozhno  v
znachitel'noj  mere osushchestvlyat'  parallel'no.  (Proektirovanie apparatnogo i
programmnogo obespecheniya tozhe mogut prohodit' parallel'no.)
     Glava 5. |ffekt vtoroj sistemy
     5.1 Svyaz', ustanovlennaya na rannih etapah i prodolzhayushchayasya nepreryvno,
mozhet dat' arhitektoru vernuyu ocenku stoimosti, a razrabotchiku - uverennost'
v proekte, ne snimaya pri etom chetkogo razgranicheniya sfer otvetstvennosti.
     5.2 Kak arhitektoru uspeshno vliyat' na realizaciyu:
     -  Pomnit',  chto   otvetstvennost'  za  tvorchestvo,   proyavlyaemoe   pri
realizacii, neset stroitel', poetomu arhitektor tol'ko predlagaet.
     -  Vsegda byt' gotovym  predlozhit'  nekotoryj sposob  realizacii  svoih
zamyslov  i  byt' gotovym  soglasit'sya s lyubym drugim  sposobom, kotoryj  ne
huzhe.
     - Vydvigaya takie predlozheniya, dejstvovat' tiho i chastnym obrazom.
     -     Ne    rasschityvat'    na    priznatel'nost'    za    predlozhennye
usovershenstvovaniya.
     -   Vyslushivat'   predlozheniya   razrabotchikov   po   usovershenstvovaniyu
arhitektury.
     5.3 Iz vseh  proektiruemyh  sistem  naibol'shuyu  opasnost'  predstavlyaet
vtoraya po schetu; obychno ee prihoditsya pereproektirovat' zanovo.
     5.4 OS/360 yavlyaetsya yarkim primerom effekta vtoroj sistemy. (Pohozhe, chto
Windows NT - eto primer dlya 1990 goda.)
     5.5 Dostojnoj vnimaniya  praktikoj  yavlyaetsya predvaritel'noe  naznachenie
funkciyam velichin v bajtah i mikrosekundah.
     Glava 6. Donesti slovo
     6.1  Dazhe  v  bol'shoj  komande proektirovshchikov oformlenie rezul'tatov
nuzhno poruchit' odnomu ili dvum lyudyam, chtoby obespechit' soglasovannost' mini-
reshenij.
     6.2  Vazhno yavno opredelit' te chasti arhitektury,  kotorye  ne propisany
stol' zhe tshchatel'no, kak ostal'nye.
     6.3 Neobhodimo imet'  kak  formal'noe  opisanie proekta - dlya tochnosti,
tak i tekstual'noe - dlya ponimaniya.
     6.4   Libo  formal'noe,  libo  tekstual'noe  opredeleniya  vybirayutsya  v
kachestve standarta, pri etom vtoroe opredelenie yavlyaetsya proizvodnym. Kazhdoe
opredelenie mozhet vystupat' v lyuboj iz rolej.
     6.5  Realizaciya,   v  tom  chisle  model',  mozhet  sluzhit'  opredeleniem
arhitektury; takoe ispol'zovanie imeet sushchestvennye nedostatki.
     6.6 Pryamoe vklyuchenie yavlyaetsya ochen' iskusnym priemom  dlya osushchestvleniya
standartov arhitektury v programmnom obespechenii (v apparatnom obespechenii -
tozhe: voz'mite interfejs Mac WIMP, vstroennyj v ROM).
     6.7   Arhitekturnoe  "opredelenie   budet   yasnee,   a  (arhitekturnaya)
disciplina krepche, esli iznachal'no stroyatsya kak minimum dve realizacii".
     6.8   Vazhno,   chtoby  arhitektor   v  telefonnyh   razgovorah   otvechal
ispolnitelyam na ih voprosy; obyazatel'no nuzhno registrirovat' eti razgovory v
zhurnale i dovodit' ih do obshchego svedeniya. (Sejchas dlya etogo predpochtitel'nee
elektronnaya pochta.)
     6.9  "Luchshij  drug  menedzhera  proekta  -  ego   postoyannyj  protivnik,
nezavisimaya organizaciya, testiruyushchaya produkt."
     Glava 7. Pochemu ne udalos' postroit' Vavilonskuyu bashnyu?
     7.1  Proekt  Vavilonskoj  bashni  provalilsya  iz-za nedostatka  obmena
informaciej i, kak sledstvie, organizacii.
     Obmen informaciej
     7.2  "Otstavanie  grafika, nesootvetstvie  funkcional'nosti, sistemnye
oshibki  - vse eto iz-za  togo, chto levaya  ruka ne znaet, chto tvorit pravaya."
Predpolozheniya komand rashodyatsya.
     7.3 Brigady dolzhny podderzhivat'  mezhdu  soboj  svyaz'  vsemi  vozmozhnymi
sposobami: neformal'no, putem regulyarnyh soveshchanij po proektu s tehnicheskimi
otchetami i cherez obshchuyu rabochuyu tetrad' proekta. (A takzhe elektronnuyu pochtu.)
     Rabochaya tetrad' proekta
     7.4 Rabochaya tetrad'  proekta est'  "ne  stol'ko  otdel'nyj  dokument,
skol'ko  struktura, nalagaemaya  na  vse  dokumenty, kotorye, tak  ili inache,
budut sozdany vo vremya vypolneniya proekta."
     7.5 "Vse  dokumenty proekta  dolzhny  vhodit' v etu  strukturu  (rabochej
tetradi)."
     7.6 Strukturu rabochej tetradi nuzhno proektirovat' tshchatel'no i rano.
     7.7 Pravil'noe  strukturirovanie tekushchej dokumentacii  s samogo  nachala
pozvolyaet "sostavlennye pozdnee dokumenty  oformit' v vide otryvkov, kotorye
vpisyvayutsya v etu strukturu" i uluchshaet rukovodstva po produktu.
     7.8  "Kazhdyj  chlen   komandy  dolzhen   videt'  vse  materialy  (rabochej
tetradi)."  (Sejchas ya by skazal "dolzhen imet' vozmozhnost' videt'". Naprimer,
dostatochno WWW-stranic.)
     7.9 Svoevremennoe obnovlenie mozhet imet' kriticheskoe znachenie.
     7.10 Neobhodimo,  chtoby vnimanie pol'zovatelya  bylo osobo privlecheno  k
izmeneniyam, proizoshedshim posle ego poslednego prochteniya, prichem  s pometkami
ob ih znachenii.
     7.11 Rabochaya tetrad'  proekta  OS/360 nachinalas' s bumazhnogo varianta s
posleduyushchim perehodom na mikrofishi.
     7.12 Segodnya (i dazhe v  1975 godu)  obshchij elektronnyj  bloknot yavlyaetsya
znachitel'no  luchshim, bolee  deshevym  i  prostym  mehanizmom  dostizheniya etih
celej.
     7.13  Neobhodimo  pomechat'  tekst  s  pomoshch'yu  polosok   izmeneniya  dat
peresmotra (ili  ih  funkcional'nogo  ekvivalenta). Tak zhe neobhodima svodka
izmenenij po tipu steka.
     7.14  Parnas staraetsya  dokazat', chto  stremlenie k tomu, chtoby  kazhdyj
videl  vse,  sovershenno  oshibochno:  chasti  dolzhny   inkapsulirovat'sya  takim
obrazom, chtoby  nikomu ne trebovalos' ili ne razreshalos'  videt'  soderzhanie
kakih-  libo  chastej,  krome  svoih  sobstvennyh, a vidny mogut  byt' tol'ko
interfejsy.
     7.15 Predlozhenie  Parnasa  - put' k  katastrofe.  (Parnas vpolne ubedil
menya v obratnom, i ya sovershenno izmenil svoe mnenie.)
     Organizaciya
     7.16  Zadachej  organizacii  yavlyaetsya sokrashchenie  ob®ema  neobhodimogo
obshcheniya i soglasovaniya.
     7.17 Organizaciya  zaklyuchaet  v  sebe  razdelenie truda i  specializaciyu
funkcij s cel'yu sokratit' obmen informaciej.
     7.18  Obychnaya  drevovidnaya  organizaciya  otrazhaet  strukturnyj  princip
vlasti, kotoryj pokazyvaet, chto nel'zya odnovremenno sluzhit' dvum hozyaevam.
     7.19 Struktura  obmena informaciej v organizacii yavlyaetsya ne derevom, a
set'yu,  i  nuzhno   pridumat'  razlichnye  vidy  special'nyh   organizacionnyh
mehanizmov ("punktirnye linii"), chtoby preodolet' deficit obmena informaciej
v drevovidnoj organizacii.
     7.20  V kazhdom  subproekte  est' dve rukovodyashchie dolzhnosti:  prodyuser i
tehnicheskij direktor,  ili  arhitektor.  Ih funkcii  sovershenno  razlichny  i
trebuyut raznyh sposobnostej.
     7.21  Vpolne  effektivnym  mozhet byt' lyuboj tip  vzaimootnoshenij  mezhdu
etimi dvumya dolzhnostyami:
     - |to mozhet byt' odno lico.
     - Prodyuser mozhet byt' nachal'nikom, a direktor - ego pravoj rukoj.
     - Direktor mozhet byt' nachal'nikom, a prodyuser - ego pravoj rukoj.
     Glava 8. Ob®yavlyaya udar
     8.1  Nel'zya tochno ocenit' obshchij  ob®em ili grafik rabot  programmnogo
proekta,  prosto  oceniv vremya napisaniya  programmy i  umnozhiv na  nekotorye
koefficienty dlya ostal'nyh chastej zadaniya.
     8.2  Dannye, otnosyashchiesya  k  sozdaniyu  nebol'shih  otdel'nyh sistem,  ne
primenimy k proektam sozdaniya programmnyh kompleksov.
     8.3 Ob®em rabot rastet kak stepennaya funkciya razmera programmy.
     8.4 Nekotorye  opublikovannye  issledovaniya pokazyvayut, chto  pokazatel'
stepeni  primerno  raven  1,5. (Rezul'taty  Bema  s  etim ne  soglasuyutsya  i
menyayutsya ot 1,05 do 1,2.)1
     8.5  Dannye Portmana po ICL pokazyvayut,  chto  zanyatye na polnyj rabochij
den'   programmisty   tol'ko   okolo   50   procentov   vremeni   zanimayutsya
programmirovaniem   i   otladkoj,   a   ostal'noe   vremya   zanimayut  raznye
dopolnitel'nye zadachi.
     8.6 Po dannym Arona  iz IBM, proizvoditel'nost' truda lezhit  v predelah
ot  1,5  do 10  tysyach  strok  programmy  na cheloveka v god v zavisimosti  ot
kolichestva vzaimodejstvij mezhdu chastyami sistemy.
     8.7 Po dannym  Harra  iz Bell Labs, proizvoditel'nost' truda pri zadache
tipa razrabotki operacionnoj sistemy sostavila okolo 0,6 tysyach strok koda na
cheloveka v god, a pri razrabotke  kompilyatorov -  2,2 tysyachi dlya zakonchennyh
produktov.
     8.8 Dannye Bruksa  po OS/360 soglasuyutsya s dannymi Harra: 0,6-0,8 tysyach
strok  koda  na cheloveko-god  dlya  operacionnyh  sistem  i  2-3  tysyachi  dlya
kompilyatorov.
     8.9   Dannye   Korbato  po   proektu   MTI   MULTICS   pokazyvayut,  chto
proizvoditel'nost'  truda  pri   razrabotke  smesi  operacionnoj  sistemy  i
kompilyatorov sostavila 1,2 tysyach strok koda na cheloveka v god, no eto stroki
koda PL/I, a ostal'nye dannye otnosyatsya k strokam koda assemblera!
     8.10  Proizvoditel'nost' primerno postoyanna v perevode  na elementarnye
operatory.
     8.11    Pri   ispol'zovanii    podhodyashchih    yazykov   vysokogo   urovnya
proizvoditel'nost' mozhno uvelichit' v pyat' raz.
     Glava 9. Dva v odnom
     9.1 Esli ne schitat' vremeni vypolneniya, to glavnye izderzhki prihodyatsya
na  zanimaemoe programmoj  prostranstvo pamyati. |to  v osobennosti verno dlya
operacionnyh sistem, znachitel'naya chast' kotoryh ostaetsya rezidentnoj.
     9.2  Nesmotrya na  eto,  den'gi,  potrachennye na  pamyat' dlya  razmeshcheniya
programmy, dayut ochen' horoshee uluchshenie harakteristik na edinicu  vlozhenij -
luchshee, chem vse drugie sposoby investirovaniya v konfiguraciyu. Ploh ne razmer
programmy, a lishnij razmer.
     9.3  Razrabotchik  programmy  dolzhen  ustanavlivat' zadanie  po razmeru,
kontrolirovat' razmer i pridumyvat'  metody sokrashcheniya razmera, tak zhe,  kak
razrabotchik apparatnoj chasti delaet eto dlya detalej.
     9.4 Resursy po pamyati dolzhny yavno zadavat' ne tol'ko razmer rezidentnoj
chasti, no i intensivnost' obrashchenij programmy k disku.
     9.5  Resursy  pamyati dolzhny privyazyvat'sya k  naznacheniyu  funkcij: tochno
opredelyajte, chto dolzhen delat' modul', kogda zadaete ego razmery.
     9.6  Gruppy v sostave bol'shih brigad sklonny  proizvodit' optimizaciyu v
svoih uzkih interesah, ne dumaya o  konechnom effekte, kotoryj ona  okazhet  na
pol'zovatelya.  |ta poterya orientacii yavlyaetsya bol'shoj opasnost'yu dlya krupnyh
proektov.
     9.7   Na  vsem  protyazhenii  realizacii   sistemnye  arhitektory  dolzhny
postoyanno   proyavlyat'  bditel'nost'   s   cel'yu   nepreryvnogo   obespecheniya
celostnosti sistemy.
     9.8  Vospitanie  obshchesistemnogo  i   orientirovannogo  na  pol'zovatelya
podhoda yavlyaetsya, vozmozhno, glavnoj zadachej menedzhera po programmirovaniyu.
     9.9  Nuzhno uzhe na rannih etapah opredelit', naskol'ko  detalizirovannym
budet predostavlyaemyj pol'zovatelyu vybor opcij,  poskol'ku ob®edinenie opcij
v gruppy sberegaet pamyat' (a chasto i rashody na marketing).
     9.10  Vazhno opredelit' razmer tranzitnoj pamyati,  svyazannyj s  razmerom
peregruzhaemogo  koda,  poskol'ku  zavisimost'  proizvoditel'nosti  ot  etogo
razmera  sil'nee, chem linejnaya.  (|tot  punkt  polnost'yu  ustarel  blagodarya
nalichiyu  virtual'noj   pamyati   i   deshevizne   fizicheskoj  pamyati.   Teper'
pol'zovateli obychno pokupayut pamyat' v kolichestve, dostatochnom dlya razmeshcheniya
vsego koda osnovnyh prilozhenij.)
     9.11 Dlya dostizheniya horoshego kompromissa mezhdu prostranstvom i vremenem
neobhodimo  provodit'  obuchenie tehnike  programmirovaniya, prisushchej  dannomu
yazyku ili mashine, osobenno esli oni novye.
     9.12 U programmirovaniya est'  tehnologiya,  i  kazhdyj proekt nuzhdaetsya v
biblioteke standartnyh komponentov.
     9.13 Biblioteki programm dolzhny imet' po dve  versii kazhdogo komponenta
- bystruyu i kompaktnuyu. (Pohozhe, chto segodnya eto ustarelo.)
     9.14 Kompaktnye i  bystrye programmy pochti  vsegda yavlyayutsya rezul'tatom
strategicheskogo proryva, a ne takticheskoj gramotnosti.
     9.15 Takim proryvom chasto yavlyaetsya novyj algoritm.
     9.16  Eshche chashche  proryv  proishodit  blagodarya  izmeneniyu  predstavleniya
dannyh ili tablic. Predstavlenie - sushchnost' programmirovaniya.
     Glava 10. Dokumentarnaya gipoteza
     10.1  Gipoteza:  Sredi morya  bumag  neskol'ko  dokumentov  stanovyatsya
kriticheski vazhnymi  osyami, vokrug kotoryh vrashchaetsya vse upravlenie proektom.
Oni yavlyayutsya glavnymi lichnymi instrumentami menedzhera.
     10.2 Dlya  proekta razrabotki komp'yutera  reshayushchimi dokumentami yavlyayutsya
celi,   rukovodstvo,   grafik,   byudzhet,  organizacionnaya   struktura,  plan
pomeshchenij, a takzhe ocenka, prognoz i ceny dlya samoj mashiny.
     10.3 Dlya fakul'teta universiteta  vazhnejshie dokumenty analogichny: celi,
trebovaniya k soiskatelyam stepenej,  opisaniya  kursov, predlozheniya po nauchnoj
rabote,  raspisanie zanyatij i plan obucheniya, byudzhet, plan pomeshchenij, a takzhe
naznacheniya prepodavatelej i aspirantov.
     10.4 Dlya  programmnogo  proekta  trebovaniya  te  zhe: celi,  rukovodstvo
pol'zovatelya,  vnutrennyaya  dokumentaciya,  grafik,  byudzhet,   organizacionnaya
struktura i plan pomeshchenij.
     10.5  Poetomu dazhe  dlya  samogo  malen'kogo proekta menedzher  s  samogo
nachala dolzhen formalizovat' takoj nabor dokumentov.
     10.6   Podgotovka   kazhdogo   dokumenta  ih  etogo   malen'kogo  nabora
koncentriruet  mysl'  i kristallizuet obsuzhdenie.  Pri  izlozhenii  na bumage
trebuetsya prinyatie soten mini-reshenij, i ih nalichie otlichaet chetkuyu i tochnuyu
politiku ot rasplyvchatoj.
     10.7 Soprovozhdenie kazhdogo vazhnogo  dokumenta trebuet nalichiya mehanizma
slezheniya za sostoyaniem i preduprezhdeniya.
     10.8 Kazhdyj dokument v  otdel'nosti  sluzhit kontrol'nym spiskom i bazoj
dannyh.
     10.9  Vazhnejshaya zadacha menedzhera  - obespechit'  obshchee  dvizhenie v odnom
napravlenii.
     10.10  Glavnaya  postoyannaya  zadacha menedzhera  -  obshchenie, a ne prinyatie
reshenij; dokumenty informiruyut vsyu komandu o planah i resheniyah.
     10.11 Tol'ko malen'kaya chast',  vozmozhno, 20 procentov, rabochego vremeni
administratora  zanyata zadachami, kotorye trebuyut  svedenij, otsutstvuyushchih  v
ego pamyati.
     10.12  Po  etoj  prichine  modnaya ideya  "vseohvatyvayushchej  informacionnoj
sistemy dlya upravleniya", obespechivayushchej podderzhku rukovoditelya, osnovyvaetsya
na nevernoj modeli povedeniya rukovoditelya.
     Glava 11. Planirujte na vybros
     11.1  Inzhenery-himiki  vyyasnili,  chto  osushchestvlennyj  v  laboratorii
process nel'zya  odnim  mahom perenesti v  zavodskie usloviya,  no  neobhodimo
postroit' opytnyj zavod, chtoby poluchit' opyt narashchivaniya kolichestv veshchestv i
funkcionirovaniya v nezashchishchennyh sredah.
     11.2 |tot promezhutochnyj  shag  v ravnoj  mere neobhodim dlya  programmnyh
produktov, no dlya  inzhenerov-programmistov  poka ne stalo  obychnoj praktikoj
provodit' polevye  ispytaniya  opytnoj sistemy, prezhde chem  nachinat' postavki
gotovogo produkta.  (Sejchas eto  uzhe stalo obshchej praktikoj blagodarya vypusku
beta-versij. |to ne to zhe samoe, chto maket s ogranichennoj funkcional'nost'yu,
al'fa-versiya, kotoruyu ya takzhe propagandiruyu.)
     11.3  Dlya  bol'shinstva  proektov  pervuyu postroennuyu versiyu edva  mozhno
ispol'zovat':  slishkom   medlennaya,  slishkom   bol'shaya,  slishkom  slozhnaya  v
primenenii, ili vse eto vmeste.
     11.4 Otbrosit'  i pereproektirovat' mozhno vse srazu, a mozhno po chastyam,
no vse ravno eto pridetsya sdelat'.
     11.5 Postavka pervoj sistemy (hlama)  klientu pozvolyaet vyigrat' vremya,
no proishodit  eto cenoj  muchenij pol'zovatelej,  otvlecheniya  razrabotchikov,
podderzhivayushchih  sistemu  vo  vremya  pereproektirovaniya  i  durnoj  reputacii
produkta, kotoruyu budet trudno pobedit'.
     11.6  Poetomu  planirujte  vybrosit'  pervuyu  versiyu -  vam  vse  ravno
pridetsya eto sdelat'.
     11.7 "Programmist  postavlyaet udovletvorenie potrebnosti pol'zovatelya,
a ne kakoj-to osyazaemyj produkt" (Kosgrouv).
     11.8 Kak fakticheskie potrebnosti pol'zovatelya, tak i ponimanie im svoih
potrebnostej  menyayutsya  vo  vremya  sozdaniya,  testirovaniya  i  ispol'zovaniya
programmy.
     11.9  Podatlivost'  i neosyazaemost' programmnogo produkta pobuzhdayut ego
sozdatelej (isklyuchitel'no) k vechnomu izmeneniyu trebovanij.
     11.10 Nekotorye zakonnye  izmeneniya v zadachah (i strategiyah razrabotki)
neizbezhny, i luchshe podgotovit'sya k nim zaranee, chem predpolagat',  chto ih ne
budet.
     11.11  Sposoby  proektirovaniya  sistemy  s  uchetom  budushchih  izmenenij,
osobenno  strukturnoe   programmirovanie   s  tshchatel'nym   dokumentirovaniem
interfejsov  modulej,  horosho  izvestny, no  ne vsegda primenyayutsya.  Polezno
takzhe,  gde tol'ko  mozhno, ispol'zovat'  tehnologii  tablichnogo  upravleniya.
(Takaya  tehnika  blagodarya  stoimosti  i  razmeru  pamyati v  nastoyashchee vremya
primenyaetsya vse bolee uspeshno.)
     11.12   Dlya  sokrashcheniya  vnosimyh   pri   izmeneniyah   oshibok   sleduet
ispol'zovat' yazyki vysokogo urovnya, operacii vremeni kompilyacii, vstraivanie
ssylok na ob®yavleniya i tehniku samodokumentirovaniya.
     11.13  Vnosite izmeneniya kvantami  v horosho  opredelennye  numerovannye
versii. (Sejchas eto obychnaya praktika.)
     Planirujte organizaciyu dlya izmenenij
     11.14  "Nezhelanie programmistov dokumentirovat'  proekt proishodit ne
stol'ko  ot  leni,   skol'ko  ot  neuverennosti,  stoit  li  svyazyvat'  sebya
otstaivaniem   reshenij,   kotorye,   kak   znaet   proektirovshchik,   yavlyayutsya
predvaritel'nymi" (Kosgrouv).
     11.15 Sozdavat' organizacionnuyu strukturu s uchetom vneseniya  v  budushchem
izmenenij znachitel'no trudnee, chem  proektirovat'  sistemu s uchetom  budushchih
izmenenij.
     11.16  Rukovoditel'  proekta  dolzhen  stremit'sya   k  tomu,  chtoby  ego
menedzhery  i tehnicheskij personal byli nastol'ko  vzaimozamenyaemy, naskol'ko
pozvolyayut  ih  sposobnosti.  V  chastnosti,  nuzhno  imet'  vozmozhnost'  legko
perevodit' lyudej s tehnicheskoj na upravlencheskuyu rabotu i obratno.
     11.17  Prepyatstviya  k podderzhaniyu  effektivnoj  organizacii  s  dvojnoj
sluzhebnoj   lestnicej  yavlyayutsya   sociologicheskimi.   Neobhodimo   postoyanno
bditel'no i energichno borot'sya s nimi.
     11.18   Legko   ustanovit'   sootvetstvuyushchie   razmery   zhalovan'ya  dlya
sootvetstvuyushchih stupenek dvojnoj lestnicy,  no trebuetsya prinyat' mery, chtoby
dat'   im  sootvetstvuyushchij  prestizh:  odinakovye  ofisy,  odinakovye  sluzhby
podderzhki, v znachitel'noj mere kompensiruyushchie upravlencheskuyu deyatel'nost'.
     11.19 Organizaciya po tipu operacionnoj brigady pozvolyaet aktivno reshat'
vse storony etoj  problemy. |to dejstvitel'no dolgosrochnoe reshenie  problemy
gibkoj organizacii.
     Dva shaga vpered, shag nazad: soprovozhdenie programm
     11.20 Soprovozhdenie  programmy  v korne otlichaetsya  ot  soprovozhdeniya
apparatnoj chasti;  ono sostoit, glavnym obrazom, iz izmenenij,  ispravlyayushchih
konstruktivnye  defekty, vklyuchenie  dopolnitel'nyh funkcij ili  adaptaciyu  k
izmeneniyam sredy ispol'zovaniya ili konfiguracii.
     11.21   Stoimost'   pozhiznennogo   soprovozhdeniya  shiroko   ispol'zuemoj
programmy obychno sostavlyaet 40 i bolee procentov stoimosti ee razrabotki.
     11.22 Stoimost'  soprovozhdeniya sil'no  zavisit ot  chisla pol'zovatelej:
chem bol'she pol'zovatelej, tem bol'she oshibok oni nahodyat.
     11.23   Kempbel   otmechaet   interesnuyu   krivuyu   vzleta   i   padenij
obnaruzhivaemyh oshibok v techenie zhizni produkta.
     11.24  Ispravlenie  odnoj  oshibki  s bol'shoj veroyatnost'yu  (ot 20 do 50
procentov) vnosit druguyu.
     11.25 Posle kazhdogo  ispravleniya  nuzhno prognat' ves' nabor kontrol'nyh
primerov, po kotorym sistema proveryalas' ran'she,  chtoby  ubedit'sya, chto  ona
kakim-nibud' neponyatnym obrazom ne povredilas'.
     11.26 Metody razrabotki  programm, pozvolyayushchie isklyuchit' ili po krajnej
mere vyyavit' pobochnye effekty, mogut rezko snizit' stoimost' soprovozhdeniya.
     11.27 To zhe mozhno skazat'  o metodah realizacii proektov men'shim chislom
interfejsov i men'shim kolichestvom oshibok.
     SHag vpered, shag nazad: entropiya sistemy s techeniem vremeni rastet
     11.28 Leman  i Beladi schitayut, chto  obshchee  kolichestvo  modulej rastet
linejno  s  nomerom versii operacionnoj sistemy  (OS/360), no chisli modulej,
zatronutyh  izmeneniyami,  rastet  eksponencial'no  v zavisimosti  ot  nomera
versii.
     11.29  Vse   ispravleniya   imeyut  tendenciyu  k  razrusheniyu   struktury,
uvelicheniyu   entropii   i   dezorganizacii  sistemy.   Dazhe  samoe  iskusnoe
soprovozhdenie  programmy  tol'ko  otdalyaet  moment poverzheniya ee v sostoyanie
neispravimogo haosa, vyhodom iz kotorogo yavlyaetsya povtornoe proektirovanie s
samogo   nachala.   (Inogda   real'naya  neobhodimost'  obnovleniya  programmy,
naprimer,  s  cel'yu  povysheniya  proizvoditel'nosti,  vyzyvaet  neobhodimost'
izmeneniya vnutrennih granic struktur. CHasto ishodnye granicy sluzhat prichinoj
vyyavlyayushchihsya vposledstvii nedostatkov.)
     Glava 12. Ostryj instrument
     12.1 Menedzher proekta  dolzhen  ustanovit' principy i  vydelit' resursy
dlya  razrabotki  obshcheupotreblyaemyh  instrumentov,  v  to zhe vremya  on dolzhen
priznat' neobhodimost' v personalizirovannyh instrumentah.
     12.2 Brigadam, razrabatyvayushchim  operacionnye  sistemy,  neobhodima  dlya
otladki  sobstvennaya  celevaya  mashina.  Dlya  nee trebuetsya  skoree  maksimum
pamyati,  chem  maksimum  skorosti,  i  sistemnyj  programmist  dlya  podderzhki
standartnogo programmnogo obespecheniya.
     12.3 Mashina  dlya otladki  ili  ee programmnoe obespechenie  dolzhny imet'
instrument dlya  avtomaticheskogo podscheta i izmeneniya  vseh  vidov parametrov
programmy.
     12.4  Potrebnost'  v  celevoj mashine opisyvaetsya specificheskoj  krivoj:
posle nizkoj aktivnosti sleduet vzryvnoj rost, kotoryj potom vyravnivaetsya.
     12.5   Sistemnoj   otladkoj,   kak   astronomiej,   vsegda   zanimalis'
preimushchestvenno po nocham.
     12.6  Vopreki teorii, vydelenie  vremeni  celevoj mashiny odnoj  brigade
znachitel'nymi blokami okazalos'  luchshim  variantom planirovaniya vremeni, chem
cheredovanie ispol'zovaniya mashiny brigadami.
     12.7 |tot predpochtitel'nyj pri nehvatke komp'yuterov  metod planirovaniya
vremeni perezhil  20  let  (s 1975 goda) tehnologicheskih izmenenij, poskol'ku
yavlyaetsya naibolee produktivnym. (I ostaetsya im v 1995 godu.)
     12.8  Esli  celevoj komp'yuter yavlyaetsya novym, neobhodim ego  logicheskij
emulyator. Ego mozhno poluchit' ran'she, i on obespechivaet  nadezhnuyu  mashinu dlya
otladki dazhe posle togo, kak postavlyaetsya nastoyashchaya mashina.
     12.9   Glavnuyu  biblioteku  programm  nuzhno  razdelit'  na:   1)  nabor
individual'nyh  "igrovyh ploshchadok", 2)  podbiblioteku  sistemnoj integracii,
prohodyashchuyu sistemnoe testirovanie i 3) versiyu-reliz. Formal'noe razdelenie i
peremeshchenie obespechivayut kontrol'.
     12.10  Instrument,   obespechivayushchij   naibol'shuyu   ekonomiyu   truda   v
programmnom proekte, - eto, navernoe, sistema redaktirovaniya tekstov.
     12.11   Ob®emistost'   sistemnoj   dokumentacii   sozdaet   novyj   tip
nepostizhimosti (sm.,  naprimer Unix),  no  eto znachitel'no predpochtitel'nee,
chem bolee rasprostranennyj krajnij nedostatok dokumentacii.
     12.12 Sozdajte emulyator proizvoditel'nosti snaruzhi vnutr', sverhu vniz.
Nachnite rabotu s nim  kak mozhno ran'she. Prislushajtes' k  tomu,  chto  on  vam
skazhet.
     YAzyki vysokogo urovnya
     12.13 Tol'ko len' i inertnost' prepyatstvuyut povsemestnomu  primeneniyu
yazykov vysokogo urovnya i interaktivnogo  programmirovaniya.  (No segodnya  oni
prinyaty povsemestno.)
     12.14   YAzyk  vysokogo   urovnya  sposobstvuet   ne   tol'ko  uvelicheniyu
proizvoditel'nosti, no i otladke. Men'she oshibok i legche poisk.
     12.15 Prezhnie  vozrazheniya,  svyazannye  s funkcional'nost'yu, razmerom  i
skorost'yu rezul'tiruyushchej  programmy  ustareli  blagodarya  razvitiyu  yazykov i
tehnologii kompilyacii.
     12.16  Segodnya   edinstvennyj  podhodyashchij   kandidat   dlya   sistemnogo
programmirovaniya - PL/I. (Bol'she ne sootvetstvuet dejstvitel'nosti.)
     Interaktivnoe programmirovanie
     12.17  V  nekotoryh  prilozheniyah  paketnye  sistemy  nikogda  ne  budut
vytesneny interaktivnymi sistemami. (Po-prezhnemu verno.)
     12.18 Otladka - eto tyazhelaya i dolgaya chast' sistemnogo programmirovaniya,
i medlennaya oborachivaemost' yavlyaetsya proklyatiem otladki.
     12.19 Est'  svidetel'stva  tomu, chto interaktivnoe  programmirovanie po
krajnej mere udvaivaet skorost' sistemnogo programmirovaniya.
     Glava 13. Celoe i chasti
     13.1  Detal'naya i staratel'naya prorabotka arhitektury soglasno glavam
4, 5 i  6 ne tol'ko uproshchaet ispol'zovanie produkta, no takzhe  oblegchaet ego
razrabotku i delaet menee podverzhennym oshibkam.
     13.2 Vysockij govorit, chto "ochen'  mnogie neudachi svyazany imenno s temi
aspektami, kotorye byli ne vpolne specificirovany".
     13.3 Zadolgo do  vsyakogo napisaniya programmy  specifikaciya  dolzhna byt'
peredana storonnej  gruppe testirovaniya dlya tshchatel'nogo rassmotreniya polnoty
i yasnosti. Sami razrabotchiki sdelat' eto ne mogut.
     13.4 "Nishodyashchee proektirovanie Virta (s poshagovym utochneniem) yavlyaetsya
samoj  vazhnoj  novoj  formalizaciej  programmirovaniya  za desyatiletie (1965-
1975)."
     13.5  Virt propoveduet ispol'zovanie  na kazhdom  shage notacii  vozmozhno
bolee vysokogo poryadka.
     13.6  Horoshee   nishodyashchee  proektirovanie  pomogaet   izbegat'  oshibok
blagodarya chetyrem obstoyatel'stvam.
     13.7 Inogda prihoditsya  vozvrashchat'sya nazad, otbrasyvat'  samyj  verhnij
uroven' i nachinat' vse snachala.
     13.8   Strukturnoe    programmirovanie,   t.e.   razrabotka   programm,
upravlyayushchie struktury kotoryh sostoyat tol'ko iz zadannogo nabora operatorov,
vozdejstvuyushchih na bloki koda (v  protivopolozhnost' besporyadochnym perehodam),
daet vernyj sposob izbezhat'  oshibok i  predstavlyaet  soboj pravil'nyj sposob
myshleniya.
     13.9 |ksperimental'nye  dannye Golda pokazyvayut,  chto vo vremya  pervogo
dialoga kazhdogo seansa dostigaetsya  vtroe  bol'shij progress v  interaktivnoj
otladke, chem pri posleduyushchih dialogah. Vse zhe polezno tshchatel'no splanirovat'
otladku, prezhde chem registrirovat'sya na  mashine. (YA polagayu, chto eto polezno
do sih por, v 1995 godu.)
     13.10 YA  schitayu,  chto  dlya  pravil'nogo  ispol'zovaniya  horoshej sistemy
(interaktivnoj otladki  s bystroj  reakciej)  na  kazhdye dva chasa raboty  za
stolom dolzhno prihodit'sya dva chasa raboty na mashine: odin chas - na podchistki
i  dokumentirovanie  posle pervogo  seansa, i  odin  chas  - na  planirovanie
izmenenij i testov ocherednogo seansa.
     13.11  Sistemnaya otladka  (v otlichie  ot otladki komponentov)  zanimaet
bol'she vremeni, chem ozhidaetsya.
     13.12    Trudnost'    sistemnoj    otladki    opravdyvaet    tshchatel'nuyu
sistematichnost' i planovost'.
     13.13  Sistemnuyu   otladku   nuzhno  nachinat',   tol'ko   ubedivshis'   v
rabotosposobnosti  komponentov,  (v  protivopolozhnost'  podhodu  "svinti   i
poprobuj"  i  nachalu  sistemnoj  otladki pri  izvestnyh,  no ne  ustranennyh
oshibkah v komponentah). (|to osobenno spravedlivo dlya brigad.)
     13.14 Rekomenduetsya sozdat' bol'shoe okruzhenie i mnogo proverochnogo koda
i  "lesov"  dlya  otladki,  vozmozhno,  na   50  procentov  bol'she,   chem  sam
otlazhivaemyj produkt.
     13.15  Neobhodimo kontrolirovat'  izmeneniya  i  versii, pri etom  chleny
komandy pust' igrayut so svoimi kopiyami na "ploshchadkah dlya igr".
     13.16 Vo vremya sistemnogo testirovaniya dobavlyajte komponenty po odnomu.
     13.17 Leman i Beladi  svidetel'stvuyut, chto  kvant izmenenij dolzhen byt'
libo  bol'shim  i vnosit'sya  redko, libo ochen' malen'kim - i chasto. Poslednij
sluchaj  bolee  chrevat  neustojchivost'yu.  (V  Microsoft  rabotayut  malen'kimi
chastymi kvantami. Razrabatyvaemaya sistema sobiraetsya zanovo kazhdye sutki.)
     Glava 14. Nazrevanie katastrofy
     14.1 "Kak okazyvaetsya, chto proekt  zapazdyvaet na odin god? ...Snachala
on zapazdyvaet na odin den'."
     14.2 Otstavanie, rastushchee ponemnogu izo dnya v den', trudnee raspoznat',
trudnee predotvratit', trudnee vypravit'.
     14.3 CHtoby upravlyat' bol'shim proektom po  zhestkomu grafiku, nado prezhde
vsego imet' grafik, sostoyashchij iz veh i sootvetstvuyushchih im dat.
     14.4  Vehi   dolzhny   byt'  konkretnymi,   specificheskimi,   izmerimymi
sobytiyami, opredelennymi s predel'noj tochnost'yu.
     14.5  Programmist  redko  lzhet otnositel'no  dvizheniya  vehi, esli  veha
ocherchena rezko, on ne mozhet obmanyvat' sebya.
     14.6 Issledovaniya povedeniya pravitel'stvennyh podryadchikov po provedeniyu
ocenok  v krupnyh  proektah pokazali,  chto  ocenki  srokov raboty, tshchatel'no
peresmatrivaemye   kazhdye  dve   nedeli,   neznachitel'no  menyayutsya  po  mere
priblizheniya nachala rabot, chto vo vremya rabot pereocenki uverenno snizhayutsya i
chto nedoocenki ne menyayutsya, poka do zaplanirovannogo  sroka  okonchaniya rabot
ne ostaetsya okolo treh nedel'.
     14.7 Hronicheskoe  otstavanie  ot grafika  ubivaet moral'nyj  duh. (Dzhim
Makkarti iz Microsoft govorit: "Esli vy propustili odin krajnij srok, bud'te
uvereny, chto propustite i vtoroj."2)
     14.8 Dlya vydayushchihsya komand programmistov harakterna energiya,  kak i dlya
vydayushchihsya bejsbol'nyh komand.
     14.9 Nichto ne zamenit  grafik s  kriticheskimi putyami, chtoby opredelit',
kakoe otstavanie vo chto obojdetsya.
     14.10 Podgotovka diagrammy kriticheskih putej est' samaya cennaya chast' ee
primeneniya, poskol'ku opredelenie  topologii seti, ukazanie  zavisimostej  v
nej i ocenivanie putej vynuzhdayut osushchestvit' bol'shoj ob®em ochen' konkretnogo
planirovaniya na samyh rannih stadiyah proekta.
     14.11 Pervaya diagramma vsegda uzhasna, i dlya  sozdaniya vtoroj prihoditsya
proyavit' mnogo izobretatel'nosti.
     14.12 Diagramma kriticheskih putej  daet  otpor  demoralizuyushchej ogovorke
"drugaya chast' tozhe zapazdyvaet".
     14.13  Kazhdomu nachal'niku nuzhny  dva  vida  dannyh: informaciya o sryvah
plana, kotoraya  trebuet vmeshatel'stva,  i kartina sostoyaniya del, chtoby  byt'
osvedomlennym i imet' rannee preduprezhdenie.
     14.14  Poluchit'  pravdivuyu kartinu sostoyaniya del  nelegko,  poskol'ku u
podchinennyh menedzherov est' osnovaniya ne delit'sya svoimi dannymi.
     14.15  Nepravil'nymi dejstviyami nachal'nik  mozhet  obespechit'  utaivanie
vsej  kartiny  sostoyaniya  del; naprotiv, tshchatel'noe rassmotrenie otchetov bez
paniki i vmeshatel'stva pooshchryaet chestnyj doklad.
     14.16 Neobhodimo imet' metodologiyu obzora, s pomoshch'yu kotoroj  podlinnoe
polozhenie veshchej  stanovitsya izvestnym vsem  igrokam. Glavnym  dlya  etoj celi
yavlyaetsya grafik s vehami i dokument o zavershenii.
     14.17  Vysockij: "YA nashel, chto udobno  imet' v otchete o sostoyanii rabot
dve  daty -  "planovuyu"  (datu nachal'nika)  i "ocenivaemuyu" (datu  menedzhera
nizshego  zvena). Menedzher  proekta dolzhen ostorozhno otnosit'sya k ocenivaemym
datam."
     14.18  Nebol'shaya  gruppa  planirovaniya  i  kontrolya,  dayushchaya  otchety  o
prohozhdenii veh, neocenima pri rabote nad bol'shim proektom.
     Glava 15. Obratnaya storona
     15.1 Dlya  programmnogo produkta storona, obrashchennaya  k pol'zovatelyu, -
dokumentaciya - stol' zhe vazhna, kak i storona, obrashchennaya k mashine.
     15.2 Dazhe dlya programm, napisannyh isklyuchitel'no dlya sebya, tekstual'naya
dokumentaciya neobhodima: pamyat' mozhet izmenit' avtoru-pol'zovatelyu.
     15.3  V celom, prepodavatelyam i menedzheram ne udalos' vospitat' na  vsyu
zhizn' u  programmistov uvazhenie k dokumentacii,  preodolevayushchee len' i press
grafika rabot.
     15.4  |ta  neudacha   vyzvana   ne   stol'ko  nedostatkom  staraniya  ili
krasnorechiya, skol'ko nesposobnost'yu pokazat', kak provodit' dokumentirovanie
effektivno i ekonomichno.
     15.5 Dokumentaciya chasto  stradaet otsutstviem obshchego obzora. Posmotrite
snachala izdaleka, a potom medlenno priblizhajtes'.
     15.6  Vazhnaya dokumentaciya pol'zovatelya dolzhna byt'  vcherne  napisana do
razrabotki  programmy, poskol'ku v nej soderzhatsya osnovnye planovye resheniya.
V nej dolzhny byt' opisany devyat' predmetov (sm. tekst glavy).
     15.7 Programmu nuzhno postavlyat' s neskol'kimi kontrol'nymi primerami: s
dopustimymi vhodnymi dannymi, dopustimymi  na grani  vozmozhnostej, i s  yavno
nedopustimymi vhodnymi dannymi.
     15.8  Vnutrennyaya  dokumentaciya  programmy,  prednaznachennaya  tomu,  kto
dolzhen  ee  modificirovat',  takzhe  dolzhna  soderzhat' tekstual'nyj obzor,  v
kotorom dolzhny byt' opisany pyat' predmetov (sm. glavu).
     15.9   Blok-shema  chashche   vsego  naprasno  vklyuchaetsya  v  dokumentaciyu.
Podrobnaya poshagovaya blok-shema ustarela blagodarya pis'mennym yazykam vysokogo
urovnya. (Blok-shema - graficheskij yazyk vysokogo urovnya.)
     15.10 Redko trebuetsya blok-shema  bolee chem na odnu stranicu - esli ona
voobshche nuzhna. (Standart MILSPEC zdes' sovershenno ne prav.)
     15.11 CHto dejstvitel'no neobhodimo - eto strukturnyj graf programmy bez
soblyudeniya standartov sostavleniya blok-shem ANSI.
     15.12  CHtoby obespechit' obnovlenie  dokumentacii, vazhno  vklyuchit' ee  v
ishodnyj tekst programmy, a ne derzhat' otdel'nym dokumentom.
     15.13  Dlya  oblegcheniya  truda  vedeniya  dokumentacii  est'  tri  vazhnyh
pravila:  - Kak  mozhno bol'she ispol'zujte dlya dokumentirovaniya  obyazatel'nye
chasti  programmy,  takie  kak  imena  i ob®yavleniya. -  Ispol'zujte svobodnoe
prostranstvo i format, chtoby pokazat' otnosheniya podchinennosti, vlozhennosti i
uluchshit'  chitaemost'.  -   Vstavlyajte  v  programmu  neobhodimuyu   tekstovuyu
dokumentaciyu v vide paragrafov kommentariev, osobenno v zagolovkah modulej.
     15.14  V  dokumentacii,  kotoroj  budut  pol'zovat'sya  pri  modifikacii
programmy, ob®yasnyajte  ne tol'ko "kak", no i "pochemu".  Naznachenie  yavlyaetsya
reshayushchim  dlya  ponimaniya.  Dazhe  yazyki vysokogo  urovnya sovsem  ne  peredayut
znacheniya.
     15.15 Metody samodokumentiruyushchegosya programmirovaniya naibolee polezny i
moshchny pri ispol'zovanii yazykov vysokogo urovnya.
     |pilog k pervomu izdaniyu
     E.1  Programmnye  sistemy  yavlyayutsya,  vozmozhno,  samymi  slozhnymi   i
zaputannymi  (v   smysle  chisla  razlichnyh  tipov  sostavlyayushchih)  sozdaniyami
cheloveka.
     E.2   Smolyanaya   yama  programmnoj  inzhenerii  eshche  dolgoe  vremya  budet
ostavat'sya vyazkoj.
     Glava  19  "Mificheskij  cheloveko-mesyac" dvadcat' let  spustyaYA  ne  znayu
drugogo sposoba sudit' o budushchem, kak s pomoshch'yu proshlogo.
     PATRIK GENRI
     Opirayas' na proshloe, nevozmozhno planirovat' budushchee.
     |DMUND BERK
     Dlya chego ponadobilos' yubilejnoe dvadcatoe izdanie?
     Samolet  gudel  v nochi, napravlyayas' k Lagardii. Oblaka i sumrak skryli
vse interesnoe dlya  glaza.  Dokument,  kotoryj  ya chital,  byl  neinteresnym.
Odnako  mne  ne  bylo  skuchno.  Sidyashchij  ryadom  poputchik  chital  "Mificheskij
cheloveko-mesyac",  i  ya ozhidal,  kogda  slovom  ili  zhestom  on  vydast  svoe
vpechatlenie.  V  konce  koncov, kogda  my uzhe  vyrulivali  k  vyhodu,  ya  ne
vyderzhal:
     - Kak vam eta kniga? Sovetuete prochest'?
     - Hm, v nej net nichego, chego ya ne znal by ran'she.
     YA reshil ne predstavlyat'sya.
     Pochemu  "Mificheskij  cheloveko-mesyac" vyzhil?  Pochemu s  nim do  sih  por
schitayutsya  v sovremennoj praktike  programmirovaniya? Pochemu ego chitatel'skaya
auditoriya vyhodit za predely soobshchestva programmistov-razrabotchikov, a kniga
porozhdaet stat'i, citaty  i  pis'ma ne tol'ko  razrabotchikov  programm, no i
yuristov,  vrachej, psihologov, sociologov? Kakim obrazom kniga, napisannaya 20
let nazad ob opyte razrabotki programm, imevshem mesto 30 let nazad, mozhet do
sih por byt' aktual'noj i dazhe poleznoj?
     Soglasno odnomu  iz  ob®yasnenij,  kotorye  mozhno  uslyshat',  razrabotka
programmnogo  obespecheniya   kak   disciplina   ne  poluchila  normal'nogo   i
pravil'nogo razvitiya. V  podderzhku  etoj  tochki  zreniya  chasto ukazyvayut  na
nesootvetstvie rosta proizvoditel'nosti  truda programmistov i effektivnosti
proizvodstva  komp'yuterov,   vyrosshej  v  tysyachi   raz   za  poslednie   dva
desyatiletiya.  Kak  ob®yasnyaetsya v glave 16, anomaliya sostoit ne v zamedlennom
razvitii programmirovaniya, a v besprecedentnom v istorii chelovechestva vzryve
komp'yuternyh  tehnologij.  V  celom, prichina  etogo v  postepennom  perehode
proizvodstva komp'yuterov  iz  sborochnogo  proizvodstva  v obrabatyvayushchee, iz
trudoemkogo  proizvodstva  v  kapitaloemkoe.  Razrabotka  zhe  apparatnogo  i
programmnogo obespecheniya, v otlichie ot  proizvodstva, ostaetsya po svoej suti
trudoemkoj.
     Vtoroe   chasto   vydvigaemoe   ob®yasnenie   glasit,   chto   "Mificheskij
cheloveko-mesyac" lish' sluchajno kasaetsya razrabotki  programmnogo obespecheniya,
a  v osnovnom on  napisan o gruppovoj razrabotke chego by to  ni  bylo.  Dolya
pravdy  v  etom  est'.  V  predislovii  k izdaniyu  1975  goda  skazano,  chto
upravlenie  programmnym  proektom  imeet  bol'she  shodstva  s  lyubym  drugim
upravleniem, chem iznachal'no schitaetsya bol'shinstvom  programmistov. YA do  sih
por  tak  schitayu.  Istoriya  chelovechestva  -  eto  p'esa,  v  kotoroj  syuzhety
postoyanny,  scenarii  medlenno  menyayutsya  s razvitiem kul'tury,  a dekoracii
menyayutsya nepreryvno. Poetomu  v  HH veke my uznaem sebya v SHekspire, Gomere i
Biblii. Poetomu v  toj mere,  v kakoj  "MCH-M" napisan o lyudyah, on ustarevaet
medlenno.
     Kakovy  by  ni byli prichiny, knigu prodolzhayut  pokupat' i prisylayut mne
zamechaniya, kotorye ya cenyu. Menya chasto sprashivayut: "Kak vy schitaete, v chem vy
togda oshiblis'? CHto ustarelo v nashi dni? CHto dejstvitel'no novoe poyavilos' v
mire razrabotki programm?" |ti chetkie voprosy vpolne zakonny, i ya postarayus'
otvetit' na  nih. Ne v takom,  pravda, poryadke, no po  gruppam  tem.  Prezhde
vsego, posmotrim, chto bylo  vernym v moment napisaniya i ostalos'  takovym do
sih por.
     Central'nyj argument: konceptual'naya celostnost' i arhitektor
     Konceptual'naya  celostnost'. CHistyj  i elegantnyj  programmnyj  produkt
dolzhen  predstavit'   svoim  pol'zovatelyam  soglasovannuyu  ideal'nuyu  model'
prilozheniya, strategij osushchestvleniya  prilozheniya i  taktiki  pol'zovatel'skih
interfejsov, ispol'zuemoj pri  zadanii dejstvij i parametrov. Konceptual'naya
celostnost' produkta v vospriyatii pol'zovatelya  yavlyaetsya vazhnejshim faktorom,
vliyayushchim na prostotu ispol'zovaniya. (Est', konechno, i drugie faktory. Vazhnym
primerom  yavlyaetsya  edinoobrazie pol'zovatel'skogo  interfejsa v prilozheniyah
dlya   Macintosh.  Bolee  togo,   mozhno   sozdat'  soglasovannye  interfejsy,
yavlyayushchiesya tem ne menee, sovershenno neuklyuzhimi. Naprimer MS-DOS.)
     Est' mnogochislennye primery elegantnyh programmnyh produktov, sozdannyh
odnim  ili dvumya lyud'mi. Tak delaetsya bol'shaya  chast' chisto  intellektual'nyh
produktov,  takih kak knigi ili muzykal'nye  proizvedeniya.  Odnako vo mnogih
promyshlennyh oblastyah processy  razrabotki produkta  ne mogut osushchestvlyat'sya
na osnove  stol' prostogo podhoda k  konceptual'noj celostnosti. Konkurenciya
vynuzhdaet  k  speshke. Vo  mnogih  sovremennyh  tehnologiyah  konechnyj produkt
obladaet  bol'shoj  slozhnost'yu,  i proektirovanie  neizbezhno  trebuet  mnogih
cheloveko-mesyacev  truda. Dlya programmnyh produktov harakterny kak slozhnost',
tak i napryazhennost' grafika, obuslovlennaya konkurenciej.
     Takim obrazom, vsyakij dostatochno bol'shoj ili srochnyj produkt, trebuyushchij
usilij  mnogih lyudej,  stalkivaetsya so specificheskoj  trudnost'yu:  rezul'tat
dolzhen konceptual'no  soglasovyvat'sya  s razumom odinochnogo pol'zovatelya i v
to  zhe vremya  proektirovat'sya usiliyami neskol'kih razumov. Kak  organizovat'
proektirovanie,   chtoby   dostich'   takoj  konceptual'noj  celostnosti?  |to
central'nyj  vopros  "MCH-M". Odin iz  ego  tezisov  glasit,  chto  sushchestvuyut
kachestvennye razlichiya  mezhdu upravleniem bol'shimi  i malen'kimi programmnymi
proektami  -  lish'  v silu  chisla rabotayushchih  nad nimi golov. Dlya dostizheniya
soglasovannosti neobhodimy obdumannye i dazhe geroicheskie dejstviya.
     Arhitektor. S chetvertoj po shestuyu glavu ya dokazyvayu, chto samoe vazhnoe -
naznachit'  odnogo cheloveka arhitektorom  produkta, otvetstvennym za  vse ego
storony, vosprinimaemye pol'zovatelem. Arhitektor formiruet i imeet v  svoem
vladenii  obshchedostupnuyu  ideal'nuyu  model'  produkta,  s   pomoshch'yu   kotoroj
pol'zovatelyu budet ob®yasneno  ego  primenenie. V ee sostav  vhodit podrobnoe
ukazanie vseh  ego funkcij i sredstv  vyzova  i upravleniya. Arhitektor takzhe
dejstvuet  v  interesah pol'zovatelya pri poiske kompromissa mezhdu funkciyami,
tehnicheskim harakteristikami,  razmerom,  stoimost'yu i  vypolneniem  grafika
rabot. Vypolnenie etoj zadachi trebuet  polnoj  zanyatosti, i  tol'ko  v ochen'
malen'kih   gruppah   mozhet   byt'  sovmeshcheno  s  dolzhnost'yu   rukovoditelya.
Arhitektora  mozhno  sravnivat'  s  rezhisserom, a  menedzhera  - s  prodyuserom
kinokartiny.
     Otdelenie  arhitektury  ot   razrabotki  i  realizacii.  CHtoby  sdelat'
vozmozhnym  osushchestvlenie  arhitektorom  svoej  glavnoj  zadachi,   neobhodimo
otdelit'  arhitekturu, t.e.  opredelenie produkta v vospriyatii pol'zovatelya,
ot  ego razrabotki.  Arhitektura i  razrabotka opredelyayut chetkuyu gran' mezhdu
raznymi  chastyami zadachi proektirovaniya, i po kazhduyu storonu etoj grani lezhit
bol'shaya rabota.
     Rekursivnost' arhitektury. V ochen'  bol'shih proektah odnomu cheloveku ne
spravit'sya  so  vsej  arhitekturoj,  dazhe  esli on izbavlen  ot vseh  zabot,
svyazannyh s razrabotkoj.  Poetomu glavnyj  arhitektor sistemy dolzhen razbit'
celoe na  podsistemy. Granicy  podsistem dolzhny  byt'  provedeny tak,  chtoby
interfejsy  mezhdu  nimi byli  minimal'ny i  legche  vsego strogo opredelyaemy.
Togda  u kazhdoj  chasti  mozhet byt'  svoj arhitektor, podchinyayushchijsya  glavnomu
arhitektoru sistemy  v otnoshenii  arhitektury. Ochevidno,  pri  neobhodimosti
etot process mozhet byt' prodolzhen rekursivno.
     Segodnya ya  ubezhden  bolee  chem  kogda-libo.  Konceptual'naya celostnost'
yavlyaetsya   vazhnejshim   usloviem   kachestva  produkta.   Nalichie   sistemnogo
arhitektora est' vazhnejshij shag v napravlenii konceptual'noj celostnosti. |ti
principy   ni  v  koej  mere  ne   ogranichivayutsya  razrabotkoj  programmnogo
obespecheniya, a  spravedlivy  pri proektirovanii lyuboj  slozhnoj  konstrukcii,
bud' to  komp'yuter, samolet, strategicheskaya oboronnaya iniciativa ili sistema
global'noj  navigacii.  Posle  prepodavaniya  v  bolee  chem  20  laboratoriyah
razrabotki   programmnogo   obespecheniya  ya  stal  nastaivat',  chtoby  gruppy
uchashchihsya,  dazhe  iz   chetyreh  chelovek,  vybirali  menedzhera  i  otdel'no  -
arhitektora. Razdelenie funkcij v takih  malen'kih gruppah mozhet  pokazat'sya
neskol'ko chrezmernym trebovaniem,  no,  po moim nablyudeniyam, eto opravdano i
sposobstvuet dostizheniyu uspeha.
     |ffekt vtoroj sistemy: funkcional'nost' i ugadyvanie chastoty
     Proektirovanie dlya  bol'shih  grupp pol'zovatelej. Odnim iz  posledstvij
revolyucii,   proizvedennoj   personal'nymi    komp'yuterami,   yavlyaetsya   vse
vozrastayushchee, po krajnej mere v oblasti obrabotki delovyh dannyh, vytesnenie
zakaznyh programm korobochnymi programmnymi paketami. Bolee togo, standartnye
programmnye pakety prodayutsya  sotnyami  tysyach  i dazhe millionami ekzemplyarov.
Sistemnye arhitektory programm, postavlyaemyh vmeste s mashinoj, vsegda dolzhny
byli   sozdavat'   proekt,  orientirovannyj   na  bol'shuyu   amorfnuyu   massu
pol'zovatelej, a ne na otdel'noe  opredelennoe prilozhenie v  odnoj kompanii.
Teper' takaya zadacha vstaet pered ochen' mnogimi arhitektorami.
     Paradoks  sostoit   v   tom,   chto   sproektirovat'  instrument  obshchego
naznacheniya, nezheli specializirovannyj,  gorazdo  trudnee imenno  potomu, chto
nuzhno pridat' ves razlichayushchimsya potrebnostyam raznyh pol'zovatelej.
     V  pogone   za   funkcional'nost'yu.   Arhitektor   instrumenta   obshchego
naznacheniya,   takogo,  naprimer,  kak  elektronnaya   tablica  ili  tekstovyj
redaktor,  podverzhen  sil'nomu  soblaznu   peregruzit'   produkt   funkciyami
predel'noj poleznosti  cenoj  snizheniya  proizvoditel'nosti  i  dazhe prostoty
ispol'zovaniya. Vnachale  privlekatel'nost' predlagaemyh vozmozhnostej  kazhetsya
ochevidnoj.  Rasplata   proizvoditel'nost'yu  stanovitsya  ochevidnoj  lish'  pri
sistemnom testirovanii. Utrata prostoty ispol'zovaniya kovarno podkradyvaetsya
po  mere  togo,  kak  nebol'shimi   porciyami  dobavlyayutsya  novye  funkcii,  a
rukovodstva pol'zovatelya vse bolee razbuhayut.1
     Soblazn osobenno  velik v otnoshenii  dolgozhivushchih  massovyh  produktov,
razvivavshihsya  na  protyazhenii ryada pokolenij. Milliony  pokupatelej  trebuyut
soten novyh vozmozhnostej. Vsyakaya pros'ba svidetel'stvuet o nalichii sprosa na
rynke. CHasto  arhitektor pervonachal'noj sistemy uzhe  ushel  v pohod  za novoj
slavoj,  i arhitektura okazalas' v rukah lyudej  s men'shim opytom vzveshennogo
predstavleniya  obshchih  interesov  pol'zovatelej.   V   nedavnej  recenzii  na
Microsoft Word  6.0 skazano: "Perepolnen vozmozhnostyami; obnovlenie zamedleno
peregruzhennost'yu...  Krome  togo, Word  6.0 zanimaet mnogo mesta  i medlenno
rabotaet."  S neudovol'stviem  otmechaetsya,  chto  Word  6.0 zanimaet  4 Mbajt
pamyati   i  soobshchaetsya,  chto  iz-za  bogatyh  dopolnitel'nyh  funkcional'nyh
vozmozhnostej "dazhe Macintosh IIfx edva prigoden dlya vypolneniya Word 6".2
     Opredelenie  gruppy  pol'zovatelej.  CHem  krupnee  i   amorfnee  gruppa
predpolagaemyh pol'zovatelej, tem bolee neobhodimo yavno ee opredelit',  esli
vy  namereny  dostich'  konceptual'noj  celostnosti.  U kazhdogo  chlena gruppy
proektirovshchikov navernyaka est' neyavnyj myslennyj obraz pol'zovatelya,  i  vse
obrazy budut otlichat'sya drug ot druga. Poskol'ku predstavlenie arhitektora o
pol'zovatele yavno ili podsoznatel'no  okazyvaet vliyanie na vse arhitekturnye
resheniya,  vazhno,  chtoby  komanda  proektirovshchikov  prishla  k  edinomu obshchemu
obrazu. Dlya  etogo  neobhodimo  sostavit'  spisok  priznakov  predpolagaemyh
pol'zovatelej, ukazav v nem:
     - kto oni takie,
     - chto im nuzhno,
     - chto, po ih mneniyu, im nuzhno,
     - chego oni hotyat.
     CHastoty.   Dlya  lyubogo  programmnogo  produkta   kazhdaya  harakteristika
pol'zovatelya  predstavlyaet  soboj  raspredelenie  so   mnozhestvom  vozmozhnyh
znachenij i sootvetstvuyushchimi chastotami. Kak arhitektoru poluchit' eti chastoty?
Izuchenie  etoj  slabo  ocherchennoj  populyacii  predstavlyaetsya somnitel'nym  i
dorogostoyashchim  zanyatiem.3  S godami  ya  prishel k  ubezhdeniyu,  chto arhitektor
dolzhen ugadat'  ili,  esli vam  bol'she nravitsya,  postulirovat' polnyj nabor
priznakov  i  znachenij  vmeste  s  chastotami  dlya sozdaniya polnogo, yavnogo i
obshchego dlya vseh opisaniya gruppy pol'zovatelej.
     Takaya  neprivlekatel'naya  procedura  imeet  ryad  poleznyh  posledstvij.
Vo-pervyh, pri stremlenii  tochno ugadat' chastoty arhitektor  vynuzhden  ochen'
tshchatel'no  obdumat', kakova  vozmozhnaya gruppa pol'zovatelej. Vo-vtoryh,  pri
fiksacii  chastot  voznikaet  obsuzhdenie,  poleznoe  dlya  vseh  uchastnikov  i
vyyavlyayushchee   razlichiya   v   obrazah   pol'zovatelya,   imeyushchihsya   u   raznyh
proektirovshchikov. V-tret'ih,  yavnoe  prisvoenie chastot  sodejstvuyut ponimaniyu
togo, kakie resheniya kakimi svojstvami gruppy pol'zovatelej obuslovleny. Dazhe
takoj   neformal'nyj   analiz   chuvstvitel'nosti   prinosit  pol'zu.   Kogda
obnaruzhivaetsya, chto ochen' vazhnye resheniya zavisyat  ot nekotoryh specificheskih
predpolozhenij, okazyvaetsya umestnym poluchit' bolee tochnye  chislennye ocenki.
(Razrabotannaya  Dzheffom Konklinom (Jeff Conklin) sistema pozvolyaet formal'no
i  tochno  proslezhivat'  prinyatie  proektnyh  reshenij  i  dokumentirovat'  ih
osnovaniya.4 Mne  ne  prihodilos' eyu pol'zovat'sya, no  dumayu, chto  ona dolzhna
byt' ochen' polezna.)
     Podvodya   itogi:    ustanovite    predpolozhitel'nye   priznaki   gruppy
pol'zovatelej.  Gorazdo luchshe oshibat'sya, no vyrazhat'sya  yasno, chem vyrazhat'sya
tumanno.
     Kak naschet effekta vtoroj sistemy?  Odin nablyudatel'nyj uchenyj zametil,
chto "Mificheskij cheloveko-mesyac" rekomendoval  na  sluchaj neudachi dlya  vsyakoj
novoj sistemy planirovat' postavku  vtoroj versii (sm. glava  11), kotoraya v
glave  5  harakterizuetsya kak  tayashchaya  naibol'shie  opasnosti. YA vynuzhden byl
priznat', chto on menya "pojmal".
     Protivorechie skoree  lingvisticheskoe,  chem  real'noe. "Vtoraya" sistema,
opisyvaemaya  v  glave  5,  - eto  vtoraya  sistema,  vypuskaemaya  v  razvitie
predydushchej  s  privlecheniem  dopolnitel'nyh  funkcij i  ukrashenij.  "Vtoraya"
sistema v  glave  11  -  eto  vtoraya popytka razrabotki  pervoj  vypuskaemoj
sistemy.  Ona  razrabatyvaetsya  v  usloviyah  vseh ogranichenij, nakladyvaemyh
grafikom, sposobnostyami  i nevedeniem,  harakternymi  dlya novyh  proektov  -
ogranichenij, navyazyvayushchih disciplinu umerennosti.
     Triumf interfejsa WIMP
     Odnim iz naibolee vpechatlyayushchih yavlenij v programmirovanii za poslednie
dvadcat' let  byl triumf  interfejsa,  sostoyashchego iz  okon, znachkov,  menyu i
ukazatelej (Windows,  Icons,  Menus, Pointers -  WIMP). Segodnya on nastol'ko
shiroko  izvesten,  chto ne  trebuet  opisaniya.  Vpervye etu ideyu  predstavili
publike Dug |nglebart (Doug  Englebart) s  gruppoj kolleg  iz Stendfordskogo
nauchno-   issledovatel'skogo   instituta    na   Ob®edinennoj   komp'yuternoj
konferencii   Zapada    v   1968   godu.5   Ottuda   idei   perekochevali   v
issledovatel'skij  centr  Xerox  v Palo- Al'to,  gde  oni  realizovalis'  na
personal'noj rabochej stancii Alto, razrabotannoj Bobom Tejlorom (Bob Taylor)
s sotrudnikami. Ih podhvatil Stiv Dzhobs dlya komp'yutera  Apple Lisa - slishkom
medlennogo   dlya  osushchestvleniya  svoih  voshititel'nyh   koncepcij  prostoty
ispol'zovaniya.  |ti  koncepcii Dzhobs  zatem voplotil  v kommercheski uspeshnom
Apple Macintosh v  1985 godu. Pozdnee oni  byli prinyaty v Microsoft  Windows
dlya IBM PC i ego klonov. Moj primer budet bazirovat'sya na versii dlya Maka.6
     Konceptual'naya  celostnost'  cherez  metaforu.  WIMP  yavlyaetsya  otlichnym
primerom    pol'zovatel'skogo    interfejsa,    obladayushchego   konceptual'noj
celostnost'yu,  dostigaemoj prinyatiem znakomoj  ideal'noj  modeli -  metafory
rabochego   stola,   i   ee  tshchatel'nogo   posledovatel'nogo   razvitiya   dlya
ispol'zovaniya  voploshcheniya  v  komp'yuternoj  grafike. Naprimer,  iz  prinyatoj
metafory neposredstvenno  sleduet slozhno osushchestvimoe, no pravil'noe reshenie
o perekrytii okon vmesto  raspolozheniya  ih odno ryadom s  drugim. Vozmozhnost'
menyat' razmer i formu  okon yavlyaetsya  posledovatel'nym  rasshireniem,  dayushchim
pol'zovatelyu  novye  vozmozhnosti, obespechivaemye  nositelem  -  komp'yuternoj
grafikoj. U real'nyh bumag  na  stole nel'zya tak zhe legko  menyat'  razmer  i
formu. Buksirovka  neposredstvenno  vytekaet  iz metafory;  vybor  znachkov s
pomoshch'yu kursora yavlyaetsya pryamoj analogiej zahvata  predmetov rukoj. Znachki i
vlozhennye  papki  yavlyayutsya tochnymi  analogami dokumentov  na  stole,  kak  i
musornaya  korzina. Idei vyrezaniya,  kopirovaniya  i vstavki  tochno  imitiruyut
operacii, kotorye  my obychno osushchestvlyaem s dokumentami na stole. Sledovanie
metafore   stol'  bukval'no,  a  razvitie  nastol'ko  posledovatel'no,   chto
pol'zovatelej-novichkov  reshitel'no  korobit,  kogda   peretaskivanie  znachka
diskety v musornuyu korzinu privodit k izvlecheniyu diskety iz diskovoda.  Esli
by  interfejs  ne  byl  stol' edinoobrazno  posledovatel'nym, eta  (dovol'no
nepriyatnaya) neposledovatel'nost' tak by ne razdrazhala.
     V kakih  mestah  interfejs WIMP  vynuzhden  daleko  otojti  ot  metafory
rabochego  stola? Naibolee zametny dva otlichiya: menyu i rabota odnoj rukoj. Na
real'nom rabochem stole s dokumentami osushchestvlyayut dejstviya, a ne prikazyvayut
komu-to  ili  chemu-to  osushchestvit'  ih.  A  kogda  komu-to  daetsya  ukazanie
sovershit' dejstvie, komanda obychno ne vybiraetsya iz spiska,  a pis'menno ili
ustno podaetsya v  vide  glagola  v  povelitel'nom  naklonenii:  "pozhalujsta,
podshejte  eto  v  papku",   "pozhalujsta,  najdite   predydushchie  pis'ma"  ili
"pozhalujsta, peredajte eto Meri dlya prinyatiya mer".
     K  sozhaleniyu,  nadezhnaya  interpretaciya  komand  v svobodnom formate  na
anglijskom yazyke,  bud'  oni  v  ustnom  ili pis'mennom  vide,  nahoditsya za
predelami nashih segodnyashnih vozmozhnostej. Poetomu  proektirovshchiki interfejsa
na dva shaga  otoshli ot neposredstvennyh dejstvij pol'zovatelya s dokumentami.
Oni mudro vzyali imevshijsya  na obychnom  rabochem stole obrazec vybora komand -
otpechatannuyu "soprovodilovku", v  kotoroj  pol'zovatel' proizvodit  vybor iz
ogranichennogo menyu komand so standartnoj semantikoj. |tu ideyu oni prevratili
v gorizontal'noe menyu s vertikal'no opuskayushchimisya podmenyu.
     Podacha komand i problema dvuh kursorov. Komandy yavlyayutsya povelitel'nymi
predlozheniyami,  v nih vsegda  est' i  obychno imeetsya pryamoe  dopolnenie. Dlya
lyubogo  dejstviya nuzhno zadat' glagol i  sushchestvitel'noe.  Metafora  ukazaniya
govorit, chto dlya odnovremennogo zadaniya dvuh predmetov nuzhno imet' na ekrane
dva raznyh kursora, upravlyaemyh svoimi myshami, odnoj - v pravoj ruke, drugoj
-  v  levoj.  V konce koncov, na fizicheskom  stole my  obychno rabotaem dvumya
rukami.  (Odnako  odna  ruka  chasto  priderzhivaet  veshchi  na  meste,  chto  na
komp'yuternom   rabochem  stole  proishodit  po  umolchaniyu.)   Mozg,  konechno,
prisposoblen k dejstviyam dvumya rukami: my sistematicheski ispol'zuem dve ruki
pri vvode s  klaviatury, ezde na avtomobile, prigotovlenii pishchi. Uvy, i odna
mysh'  byla  bol'shim dostizheniem dlya izgotovitelej  komp'yuterov. Kommercheskih
sistem,  podderzhivayushchih odnovremennye dejstviya  s dvumya kursorami myshej,  po
odnomu dlya kazhdoj ruki, net.7
     Razrabotchiki interfejsa smirilis' s realiyami i sdelali proekt dlya odnoj
myshi,  prinyav sintaksicheskoe soglashenie, chto  pervym otmechaetsya (vybiraetsya)
sushchestvitel'noe.  Zatem  ukazyvayut  na  glagol,  punkt  menyu.  Pri   etom  v
znachitel'noj mere utrachivaetsya prostota ispol'zovaniya. Kogda  ya  nablyudayu za
pol'zovatelyami, prosmatrivayu videozapis' ih dejstvij ili  zaregistrirovannye
komp'yuterom  peremeshcheniya  kursora, to  vsegda  obrashchayu vnimanie na  to,  chto
odnomu  kursoru prihoditsya vypolnyat' rabotu dvuh: vybrat' ob®ekt v  okne  na
rabochem stole; vybrat' glagol v menyu; najti drugoj ob®ekt ili vnov' otyskat'
prezhnij; snova opustit'  menyu (chasto, to zhe samoe)  i vybrat' glagol. Kursor
mechetsya vzad-vpered,  ot prostranstva dannyh k prostranstvu menyu, vsyakij raz
teryaya  poleznuyu  informaciyu o tom, gde on nahodilsya  v etom  prostranstve  v
proshlyj raz - v celom, neeffektivnyj process.
     Velikolepnoe reshenie. Dazhe  esli by elektronika i programmy  mogli  bez
truda rabotat' odnovremenno s dvumya aktivnymi kursorami, ostayutsya  slozhnosti
s   topologiej   prostranstva.   Na  rabochem  stole  v   metafore   WIMP   v
dejstvitel'nosti est' pishushchaya mashinka, i v fizicheskom prostranstve real'nogo
stola neobhodimo pomestit' real'nuyu klaviaturu. Klaviatura plyus  dva kovrika
dlya myshej zajmut nemaluyu chast' prostranstva v predelah dosyagaemosti ruk. Tak
pochemu by  problemu  klaviatury  ne  obratit'  sebe  na  pol'zu,  pochemu  ne
ispol'zovat' obe ruki -  odnoj rukoj zadavaya na klaviature glagoly, a drugoj
rukoj vybiraya sushchestvitel'nye s pomoshch'yu myshi? Teper' kursor budet ostavat'sya
v   prostranstve   dannyh   i   pol'zovat'sya   tem,   chto   posledovatel'nye
sushchestvitel'nye vybirayutsya  blizko odno ot drugogo.  Real'naya effektivnost',
real'no bol'shie vozmozhnosti pol'zovatelya.
     Moshchnost' funkcij ili prostota ispol'zovaniya.  Odnako  pri takom reshenii
teryaetsya  to, chto delaet ispol'zovanie menyu takim prostym dlya novichkov: menyu
predstavlyaet spisok al'ternativnyh  glagolov, dopustimyh v kazhdom konkretnom
sostoyanii.  Mozhno  kupit' korobku, prinesti  ee domoj i  nachat' rabotat', ne
chitayu  instrukciyu,  znaya lish',  dlya  chego  ona kuplena  i  eksperimentiruya s
razlichnymi  glagolami v  menyu.  Odna  iz  slozhnejshih  zadach,  stoyashchih  pered
arhitektorami  - eto najti  sootnoshenie  mezhdu moshchnost'yu funkcij i prostotoj
ispol'zovaniya.  Nuzhno li  proektirovat'  programmu  v  raschete na  novichka i
sluchajnogo   pol'zovatelya   ili   stroit'   ee  s  moshchnymi   funkciyami   dlya
professionala? Ideal'noe reshenie -  obespechit' i  to, i drugoe konceptual'no
soglasovannym obrazom, chto  dostigaetsya pri pomoshchi interfejsa  WIMP. U chasto
ispol'zuemyh  glagolov menyu est'  klavishnye  ekvivalenty iz odnoj klavishi  +
komandnoj klavishi,  kotorye obychno legko vvesti levoj rukoj  odnim akkordom.
Naprimer, v Make komandnaya klavisha (^) nahoditsya  kak raz pod klavishami  Z i
X, poetomu samye chastye dejstviya kodiruyutsya kak ^z, ^x, ^c, ^v, ^s.
     Postepennyj  perehod ot novichka  k opytnomu pol'zovatelyu. Takaya dvojnaya
sistema  zadaniya komandnyh glagolov ne tol'ko otvechaet potrebnosti novichka v
legkom  obuchenii   i   potrebnosti  opytnogo   pol'zovatelya  v   effektivnom
ispol'zovanii, no i pozvolyaet kazhdomu pol'zovatelyu plavno perejti  iz odnogo
rezhima v  drugoj. Bukvennye  oboznacheniya,  nazyvaemye klavishami sokrashchennogo
nabora,  pokazyvayutsya   v  menyu  ryadom   s  glagolami,   poetomu  v   sluchae
neuverennosti  pol'zovatel' mozhet raskryt'  menyu, chtoby proverit'  bukvennyj
ekvivalent, vmesto vybora punkta  menyu.  Kazhdyj  novichok zapominaet  snachala
sokrashchennyj nabor dlya  svoih  chastyh  operacij.  On mozhet poprobovat'  lyuboe
sokrashchenie,  v  kotorom  ne  uveren, poskol'ku ^z  otmenyaet lyuboe  oshibochnoe
odinochnoe  dejstvie.   S  drugoj   storony,  on  mozhet  spravit'sya   v  menyu
otnositel'no dopustimyh komand. Novichki ochen'  chasto opuskayut  menyu, opytnye
pol'zovateli -  redko, a tem, kotorye nahodyatsya poseredine, lish' ot sluchaya k
sluchayu  ponadobitsya  vybirat'  iz  menyu, poskol'ku oni  uzhe  znayut  klavishi,
kotorye vyzyvayut bol'shinstvo osushchestvlyaemyh imi operacij. My, proektirovshchiki
programmnogo obespecheniya, slishkom privykli k etomu interfejsu, chtoby ocenit'
ego elegantnost' i moshch'.
     Uspeh pryamogo vklyucheniya kak sredstva navyazyvaniya arhitektury. Interfejs
Maka  primechatelen   eshche  v   odnom  otnoshenii.   Bez   vsyakogo  prinuzhdeniya
razrabotchiki   sdelali  ego  standartom   dlya   raznyh  prilozhenij,  vklyuchaya
bol'shinstvo  iz  teh,  kotorye  opisany  storonnimi  organizaciyami.  Poetomu
pol'zovatel' priobretaet konceptual'nuyu soglasovannost' na urovne interfejsa
ne  tol'ko dlya programm, postavlyaemyh vmeste s mashinoj, no i dlya vseh drugih
prilozhenij.
     |tot  podvig  sozdateli Maka  osushchestvili,  vstroiv interfejs v  PZU, v
rezul'tate chego razrabotchikam proshche i bystree pol'zovat'sya sushchestvuyushchim, chem
sozdavat' svoi idiosinkrazicheskie interfejsy. |to estestvennoe stremlenie  k
edinoobraziyu vozobladalo  nastol'ko  shiroko,  chto stalo standartom de-fakto.
Estestvennye stremleniya byli podderzhany  polnoj  priverzhennost'yu  so storony
menedzherov   i  sushchestvennym  prinuzhdeniem  so  storony  Apple.  Nezavisimye
recenzenty v zhurnalah, ponyav ogromnoe znachenie mezhprogrammnoj konceptual'noj
celostnosti, takzhe podkrepili estestvennye  stremleniya, bezzhalostno kritikuya
produkty, ne udovletvoryayushchie etomu interfejsu.
     |to  otlichitel'nyj primer  tehnologii,  rekomendovannoj v glave  6  dlya
dostizheniya  edinoobraziya  putem  pooshchreniya  drugih  storon   neposredstvenno
vklyuchat' v  svoi  produkty imeyushchijsya  kod vmesto  razrabotki  novyh programm
soglasno imeyushchimsya specifikaciyam.
     Sud'ba WIMP: ustarevanie. Nesmotrya na vse dostoinstva, po moemu mneniyu,
interfejs WIMP cherez pokolenie  stanet dostoyaniem istorii. Ukazanie kursorom
ostanetsya   sposobom   zadaniya   sushchestvitel'nyh   pri   upravlenii   nashimi
komp'yuterami.  Dlya  vyrazheniya  glagolov stanet  ispol'zovat'sya  rech'.  Takie
instrumenty,   kak  Voice  Navigator   dlya  Makov  i  Dragon   dlya  PC,  uzhe
predostavlyayut takuyu vozmozhnost'.
     Ne razrabatyvajte programm na vybros, kaskadnaya model' neverna!
     V  glave  11 daetsya radikal'nyj  sovet: "planirujte vybrosit'  pervuyu
programmu,  vam  vse  ravno  pridetsya  eto  sdelat'".  Sejchas  ya  schitayu eto
oshibochnym  -  ne  v silu  chrezmernogo  radikalizma,  no  v  silu  chrezmernoj
uproshchennosti.
     Samoj  bol'shoj  oshibkoj  etoj  koncepcii  yavlyaetsya  kosvennoe  prinyatie
klassicheskoj  posledovatel'nosti  -  v   vide  kaskada   -  modeli  sozdaniya
programmy.   |ta  model'  proishodit   ot  struktury  diagrammy  Granta  dlya
poetapnogo  processa,  kotoruyu chasto  izobrazhayut,  kak  na  risunke  19.1. V
klassicheskoj  stat'e 1970 goda  Vinton  Rojs (Winton Royce) usovershenstvoval
posledovatel'nuyu model' putem:
     - dobavleniya nekotoroj obratnoj svyazi s predshestvuyushchimi etapami;
     -    ogranicheniya     obratnoj     svyazi     tol'ko    neposredstvennymi
predshestvennikami,  chtoby  isklyuchit'  vyzyvaemye  imi izderzhki  i zaderzhki v
vypolnenii grafika.
     On  predvoshitil  "MCH-M",  rekomendovav  razrabotchikam  "delat'  rabotu
dvazhdy"8. Glava 11 - ne edinstvennaya, na kotoruyu  povliyala kaskadnaya model'.
Ona prohodit  cherez vsyu knigu, nachinaya s pravila planirovaniya v glave 2. |to
prakticheskoe pravilo otvodit 1/3 vremeni na planirovanie, 1/6 - na napisanie
programm,  1/4   -  na  testirovanie  komponentov   i  1/4  -  na  sistemnoe
testirovanie.

     

     Ris. 19.1 Kaskadnaya model' sozdaniya programmy
     Osnovnoe zabluzhdenie  kaskadnoj  modeli sostoit  v  predpolozheniyah, chto
proekt  prohodit cherez ves' process  odin raz, arhitektura horosha i prosta v
ispol'zovanii,   proekt  osushchestvleniya   razumen,   a  oshibki  v  realizacii
ustranyayutsya po mere testirovaniya. Inymi slovami, kaskadnaya model' ishodit iz
togo,  chto  vse  oshibki  budut  sosredotocheny  v  realizacii,  a  potomu  ih
ustranenie  proishodit  ravnomerno  vo  vremya  testirovaniya  komponentov   i
sistemy.
     "Planirujte na vybros" dejstvitel'no rezko napadaet na eto zabluzhdenie.
Oshibka  ne v diagnoze,  a  v  lekarstve.  Sejchas ya  predpolozhil,  chto pervuyu
sistemu mozhno otbrosit'  ili pereproektirovat' ne  vsyu celikom, a po chastyam.
Horosho,  esli  eto  tak, no  pri  etom  ne zatragivaetsya  koren' problemy. V
kaskadnoj  modeli  sistemnoe testirovanie, a  sledovatel'no  i  testirovanie
pol'zovatelem,  otodvigaetsya  v  konec processa sozdaniya programmy.  Poetomu
est' shans  obnaruzhit' krajnie neudobstva  dlya pol'zovatelya, ili nepriemlemye
tehnicheskie   harakteristiki,   ili   opasnuyu   uyazvimost'  k  oshibkam   ili
zlonamerennym dejstviyam pol'zovatelya lish' v samom konce razrabotki. Izuchenie
specifikacij  pri  al'fa-testirovanii  naceleno na rannee obnaruzhenie  takih
oshibok, no nichto ne mozhet zamenit' neposredstvennyh pol'zovatelej.
     Vtorym nedostatkom kaskadnoj modeli yavlyaetsya predpolozhenie, chto sistema
stroitsya srazu vsya  celikom  dlya  testirovaniya s nachala do konca posle togo,
kak  zaversheny vse proektnye razrabotki, bol'shaya chast' napisaniya  programm i
znachitel'naya chast' testirovaniya komponentov.
     K   neschast'yu,  kaskadnaya  model',   eto   preobladavshee  v  1975  godu
predstavlenie  o  programmnyh  proektah,  byla  vklyuchena  v  DOD-STD-2167  -
specifikaciyu   Ministerstva  oborony   dlya  lyubogo   voennogo   programmnogo
obespecheniya. Po etoj prichine ona  prosushchestvovala dolgoe  vremya  posle togo,
kak bol'shaya chast' dumayushchih praktikov osoznala ee neadekvatnost' i otkazalas'
ot nee. K schast'yu, v MO pozdnee ponyali istinu.9
     Neobhodimo   dvigat'sya   protiv  techeniya.  Opyt   i  idei   iz   kazhdoj
raspolozhennoj  nizhe  po  techeniyu  chasti  processa  sozdaniya  programmy,  kak
energichnyj  losos', dolzhny prygat'  vverh  po  techeniyu,  inogda  srazu cherez
neskol'ko etapov, i vozdejstvovat' na deyatel'nost' naverhu.
     Proektnye    razrabotki    pokazhut,   chto   nekotorye   predusmotrennye
arhitekturoj  vozmozhnosti  uhudshayut  tehnicheskie  harakteristiki,  i  potomu
arhitektura  dolzhna   byt'  pererabotana.  Programmirovanie  pri  realizacii
vyyavit,  chto nekotorye funkcii  nepomerno  uvelichivayut  trebovaniya k pamyati,
poetomu nuzhno vnesti izmeneniya v arhitekturu i razrabotku.
     Poetomu vpolne mozhet potrebovat'sya osushchestvit' neskol'ko iteracij cikla
arhitektura-razrabotka, prezhde chem nachat' kakuyu-libo programmnuyu realizaciyu.
     Model' poshagovogo sozdaniya luchshe: posledovatel'noe utochnenie
     Postroenie karkasa s nachala  do  konca.  Garlan Millz  (Harlan  Mills),
rabotayushchij  v  sisteme s razdeleniem vremeni, davno uzhe  rekomenduet stroit'
osnovnoj  cikl  oprosa  sistemy real'nogo  vremeni  s  vyzovami  podprogramm
(zaglushkami)  dlya  vseh  funkcij  (ris. 19.2),  no  pustymi  podprogrammami.
Otkompilirujte ego, protestirujte, i on budet idti cikl za ciklom, bukval'no
nichego ne delaya, no delaya eto bez oshibok.10

     

     Ris. 19.2
     Na sleduyushchem shage my  naveshivaem modul' vvoda (vozmozhno, primitivnyj) i
modul'  vyvoda.  Voila!  Rabotayushchaya  sistema,  delayushchaya   nechto,   vozmozhno,
neinteresnoe. Teper', funkciya za funkciej, my  stroim i dobavlyaem moduli. Na
kazhdom  shage  my  imeem rabotayushchuyu  sistemu. Pri  dostatochnom trudolyubii  na
kazhdom shage  my imeem otlazhennuyu,  protestirovannuyu sistemu. (Po mere  rosta
sistemy rastet i tyazhest'  povtornogo testirovaniya vseh novyh modulej po vsem
prezhnim kontrol'nym primeram.)
     Posle  togo  kak na primitivnom  urovne  kazhdaya  funkciya  rabotaet,  my
uluchshaem ili perepisyvaem odin modul' za drugim, poshagovo narashchivaya sistemu.
Inogda dlya nadezhnosti my perepisyvaem ishodnyj  dvizhushchij cikl, a vozmozhno, i
ego interfejsy s modulyami.
     Poskol'ku v lyuboj moment vremeni u nas est' rabotayushchaya sistema:
     - mozhno ochen' rano nachat' testirovanie pol'zovatelyami;
     -  mozhno  prinyat'  strategiyu  razrabotki  v  sootvetstvii  s  byudzhetom,
polnost'yu zashchishchayushchuyu ot pererashoda vremeni ili  sredstv (vozmozhno,  za schet
sokrashcheniya funkcional'nosti).
     V techenie 22  let  ya  prepodaval  v laboratorii  programmnoj  inzhenerii
Universiteta  shtata Severnaya  Karolina, inogda vmeste s Devidom Parnasom. Na
etih zanyatiyah  brigady,  obychno  sostoyavshie iz  chetyreh  chelovek, v  techenie
odnogo  semestra  dolzhny   byli  postroit'  nekotoruyu  real'nuyu   prikladnuyu
programmnuyu  sistemu. Primerno  poseredine etogo  sroka ya  stal  prepodavat'
inkrementnuyu  razrabotku.  YA  byl  porazhen,  kakoj  vozbuzhdayushchij  effekt  na
moral'nyj duh gruppy  okazyvaet pervaya kartinka na ekrane, pervaya rabotayushchaya
sistema.
     Semejstva   Parnasa.  Devid   Parnas  byl  glavnym  vlastitelem  dum  v
programmotehnike v techenie vsego etogo 20-letnego perioda. Vsem izvestna ego
ideya  skrytiya  informacii.  Menee  izvestna  ochen'  vazhnaya  ideya  Parnasa  o
proektirovanii   programmnogo   produkta   kak   semejstva   vzaimosvyazannyh
produktov.11 On trebuet,  chtoby  proektirovshchik  imel v  vidu  kak dal'nejshee
razvitie, tak  i  novye  versii  produkta i opredelyal ih  funkcional'nye ili
mezhplatformennye  razlichiya tak, chtoby stroit' derevo  rodstvennyh  produktov
(ris. 19.3).

     

     Ris. 19.3
     Fokus pri proektirovanii takogo dereva  sostoit  v tom, chtoby  blizhe k
kornyu pomestit' te resheniya, izmenenie kotoryh naimenee veroyatno.
     Takaya  strategiya   proektirovaniya  povyshaet   povtornuyu  ispol'zuemost'
modulej. Eshche vazhnee, chto ee mozhno rasshirit', vklyuchaya ne tol'ko  postavlyaemye
produkty, no i posledovatel'nye promezhutochnye versii, sozdannye po strategii
inkrementiruemyh  sborok.   V   etom  sluchae   produkt   razvivaetsya   cherez
promezhutochnye stadii s minimumom vozvrata nazad.
     Podhod   Microsoft:  "ezhevechernyaya   sborka".  Dzhejms  Makkarti   (James
McCarthy) opisal mne process, ispol'zovavshijsya im i drugimi v Microsoft. |to
poshagovoe narashchivanie, dovedennoe do logicheskogo konca. On pishet:
     Sdelav  pervuyu  postavku, novye versii my  postavlyaem s dopolnitel'nymi
funkciyami, po  sravneniyu s sushchestvuyushchim rabotayushchim produktom.  Pochemu dolzhen
byt'  inym process  pervonachal'noj sborki? S momenta dostizheniya  nami pervoj
vehi  (u  pervoj  postavki tri promezhutochnyh  vehi)  my  kazhdyj vecher zanovo
sobiraem  razrabatyvaemuyu sistemu  (i progonyaem  kontrol'nye  primery). Cikl
sborki stanovitsya ritmom zhizni proekta. Kazhdyj vecher  odna ili bolee  brigad
programmistov,  provodyashchih   testirovanie,   registriruyut  moduli  s  novymi
funkciyami. Posle  kazhdoj sborki  u  nas est' rabotayushchaya sistema. Esli sborka
okazyvaetsya neudachnoj,  my ostanavlivaem  ves' process, poka oshibka ne budet
najdena i ispravlena. V lyuboj moment vse v gruppe znayut polozhenie del.
     |to dejstvitel'no tyazhelo. Trebuetsya vydelenie bol'shih  resursov, no eto
upravlyaemyj  process,  proslezhivaemyj  i  ponyatnyj. On  vyzyvaet  u  komandy
doverie k sebe. A doverie opredelyaet moral', emocional'noe sostoyanie.
     Takoj  process  udivlyaet  i  dazhe  shokiruet  razrabotchikov  v  drugih
organizaciyah.  Odin  iz nih govorit: "YA vzyal sebe za  pravilo  delat' sborku
kazhduyu  nedelyu,  no  ezhednevnaya  sborka,  ya dumayu, potrebuet  slishkom  mnogo
truda." I eto, vozmozhno, verno.  Naprimer, v Bell Northern Research sobirayut
sistemu, sostoyashchuyu iz 12 millionov strok, raz v nedelyu.
     Inkrementnaya sborka  i  bystroe maketirovanie.  Poskol'ku  inkrementnaya
razrabotka  pozvolyaet rano  nachat' testirovanie real'nymi  pol'zovatelyami, v
chem ee otlichie ot bystrogo maketirovaniya? Mne kazhetsya, chto  oni svyazany,  no
razlichayutsya. Odnim mozhno pol'zovat'sya bez drugogo.
     Harel daet poleznoe opredelenie maketa:
     (versiya programmy, kotoraya) otrazhaet tol'ko proektnye resheniya, prinyatye
v  processe  podgotovki  konceptual'noj  modeli,  a  ne  resheniya,  vyzvannye
soobrazheniyami realizacii.12
     Mozhno  postroit'  maket,  kotoryj  vovse  ne yavlyaetsya chast'yu  produkta,
razvivayushchegosya   v  napravlenii  postavki.  Naprimer,  mozhno  sozdat'  maket
interfejsa,  za  kotorym  stoit  ne real'no  rabotayushchaya  programma,  a  lish'
konechnyj avtomat, zastavlyayushchij ego imitirovat' prohozhdenie  sostoyanij. Mozhno
dazhe  maketirovat'  i  testirovat' interfejsy metodom volshebnika izumrudnogo
goroda,   kogda   spryatannyj   chelovek   imitiruet  otklik   sistemy.  Takoe
maketirovanie mozhet byt'  ves'ma poleznym  dlya bystrogo  polucheniya  obratnoj
svyazi ot pol'zovatelya, no ono nahoditsya sovershenno v storone ot testirovaniya
produkta, kotoryj gotovitsya k postavke.
     Analogichno, razrabotchiki  mogut poprobovat' postroit' vertikal'nyj srez
produkta, v kotorom polnost'yu realizovan  ves'ma ogranichennyj nabor funkcij,
chtoby  zaranee prolit' svet na te  mesta,  gde mogut tait'sya  opasnosti  dlya
proizvoditel'nosti produkta. V chem sostoit razlichie mezhdu sborkoj na  pervoj
vehe v  procedure  Microsoft i bystrym maketom? V funkciyah. Produkt s pervoj
vehi mozhet  imet' takuyu ogranichennuyu funkcional'nost', chto  ni  dlya kogo  ne
budet predstavlyat'  interesa.  Gotovnost' produkta  k postavke  opredelyaetsya
zavershennost'yu v predostavlenii poleznogo nabora funkcij i svoim  kachestvom,
uverennost'yu v nadezhnoj rabote.
     Parnas byl prav, a ya - net v otnoshenii sokrytiya informacii
     V glave 7  ya protivopostavlyayu  dve tochki zreniya na  to,  v  kakoj mere
kazhdyj uchastnik komandy mozhet imet' pravo ili pooshchryat'sya k znaniyu proektov i
tekstov programm, sozdannyh kollegami. Vo vremya proekta Operating System/360
my reshili, chto vse programmisty dolzhny videt'  ves' material, t.e. u kazhdogo
programmista byla rabochaya tetrad' proekta, kotoraya k koncu naschityvala svyshe
10000  stranic.  Harlan  Millz ubeditel'no  dokazyval, chto "programmirovanie
dolzhno  byt' otkrytym processom",  chto  predostavlenie  vsej raboty na obshchee
obozrenie sposobstvuet kontrolyu kachestva kak  blagodarya davleniyu so  storony
kolleg, zastavlyayushchemu rabotat'  horosho, tak  i blagodarya tomu,  chto  kollegi
dejstvitel'no nahodyat promahi i oshibki.
     |tot  vzglyad rezko  protivorechit  mneniyu  Devida  Parnasa  o  tom,  chto
programmnye  moduli  dolzhny  byt' inkapsulirovany,  s  horosho  opredelennymi
interfejsami,   a   vnutrennost'   takih   modulej   dolzhna   byt'   chastnoj
sobstvennost'yu programmista,  nevidimoj  snaruzhi.  Programmisty  effektivnee
vsego rabotayut, buduchi ograzhdeny ot vnutrennostej chuzhih modulej.13
     V glave 7 ya zaklejmil  ideyu Parnasa kak "recept katastrofy". Parnas byl
prav,  a  ya oshibalsya.  Segodnya ya ubezhden, chto ogranichenie  informacii, chasto
osushchestvlyaemoe  teper'   metodami   ob®ektnogo  programmirovaniya,   yavlyaetsya
edinstvennym sposobom podnyat' uroven' programmnyh razrabotok.
     Ispol'zuya drugie  metody, mozhno dejstvitel'no popast'  v bedu. Soglasno
metodike   Millza   programmisty  mogut   poluchit'   podrobnosti   semantiki
interfejsov, s kotorymi oni rabotayut, uznav,  chto nahoditsya "po tu storonu".
Ukryvanie etoj semantiki  mozhet byt' prichinoj  sistemnyh  oshibok.  S  drugoj
storony, metodika Parnasa sposobstvuet ustojchivosti pri vnesenii izmenenij i
bol'she  podhodit  k  strategii  proektirovaniya,  predpolagayushchej izmeneniya  v
budushchem.
     V glave 16 utverzhdaetsya sleduyushchee:
     -   bol'shaya  chast'  rosta  proizvoditel'nosti  razrabotki  programmnogo
obespecheniya  obespechena  ustraneniem  vtorostepennyh trudnostej,  takih  kak
neudobnye  yazyki   programmirovaniya  i  medlennaya  oborachivaemost'  paketnoj
obrabotki;
     - legkih reshenij v etom napravlenii prakticheski ne ostalos';
     -  radikal'nogo  progressa   mozhno   dobit'sya,   razreshiv  sushchestvennye
slozhnosti modelirovaniya slozhnyh konceptual'nyh konstrukcij.
     Samoe ochevidnoe  na etom puti - priznat', chto programmy sostavlyayutsya iz
konceptual'nyh blokov,  znachitel'no bolee  krupnyh, chem otdel'nye  operatory
yazykov  vysokogo  urovnya:  podprogramm, ili  modulej,  ili  klassov. Esli my
sumeem  ogranichit' proektirovanie i postroenie programm  zadachej  soedineniya
vmeste  i  parametrizacii  takih  blokov  iz  ranee  sozdannyh  naborov,  to
radikal'no  povysim konceptual'nyj  uroven'  i izbavimsya ot ogromnogo ob®ema
rabot i shirokih vozmozhnostej dlya  oshibok,  sushchestvuyushchih na urovne  otdel'nyh
operatorov.
     Dannoe Parnasom opredelenie  modulej s sokrytiem informacii bylo pervym
otkrytym  shagom v etoj  kriticheski vazhnoj  programme issledovanij  i idejnym
provozvestnikom  ob®ektno-orientirovannogo  programmirovaniya.  On  opredelil
modul' kak  programmnyj ob®ekt s  sobstvennoj model'yu  dannyh  i sobstvennym
naborom  operacij. Dostup k ego dannym mozhet byt'  osushchestvlen  tol'ko cherez
imeyushchiesya   v   nem  operacii.  Sleduyushchij  shag   yavilsya  vkladom  neskol'kih
issledovatelej:  razvitie  modulej  Parnasa  v  abstraktnyj  tip  dannyh, iz
kotorogo   mozhno   proizvodit'  mnogo  ob®ektov.  Abstraktnyj   tip   dannyh
obespechivaet  edinoobraznyj  sposob  predstavleniya  i  zadaniya   interfejsov
modulej, a takzhe disciplinu dostupa, kotoruyu legko osushchestvlyat'.
     Tretij shag,  ob®ektno-orientirovannoe  programmirovanie,  vvodit vazhnoe
ponyatie nasledovaniya, pri  kotorom  klassy (tipy dannyh) po  umolchaniyu imeyut
atributy  svoih  predkov  v  ierarhii  klassov.14 To,  chto  my  rasschityvaem
poluchit'  ot  ob®ektno-  orientirovannogo  programmirovaniya,  proishodit,  v
sushchnosti,   ot   pervogo  shaga,  inkapsulyacii  modulej,  plyus  ideya  zaranee
podgotovlennyh   bibliotek   modulej   ili   klassov,   sproektirovannyh   i
protestirovannyh  s  cel'yu   povtornogo   ispol'zovaniya.   Mnogie  predpochli
proignorirovat'   tot  fakt,  chto  takie  moduli   ne  prosto  programmy,  a
programmnye produkty v tom smysle,  kotoryj raz®yasnen  v  glave 1.  Naprasno
rasschityvat'  na uspeshnoe  povtornoe  ispol'zovanie  modulej,  ne  oplachivaya
nachal'nye   izderzhki  na  razrabotku   kachestvennyh   programmnyh   modulej:
obobshchennyh,  nadezhnyh,   protestirovannyh  i   dokumentirovannyh.  Ob®ektno-
orientirovannoe programmirovanie  i  povtornoe ispol'zovanie  obsuzhdalis'  v
glavah 16 i 17.
     Naskol'ko mifichen cheloveko-mesyac? Model' i dannye Bema
     V  techenie  ryada let  byli  vypolneny  mnogochislennye  kolichestvennye
issledovaniya  proizvoditel'nosti  truda  programmistov  i  vliyayushchih  na  nee
faktorov, osobenno sootnoshenij  mezhdu  obespechennost'yu personalom i grafikom
rabot.
     Naibolee obstoyatel'noe  issledovanie sdelano Barri  Bemom (Barry Boehm)
na osnovanii primerno 63  proektov, v osnovnom v aerokosmicheskoj oblasti, iz
nih  okolo  25  -  v  TRW.  Ego  rabota  "|konomika razrabotki  programmnogo
obespecheniya" soderzhit ne tol'ko rezul'taty, no i ryad poleznyh modelej zatrat
s  narastayushchej  slozhnost'yu.  Hotya  nesomnenno,  chto  primenyaemye  v  modelyah
koefficienty razlichny  dlya  obychnyh  kosmicheskih  programm  i  dlya programm,
sozdavaemyh  v aerokosmicheskoj oblasti po  pravitel'stvennym standartam, vse
zhe ego modeli podkreplyayutsya ogromnym kolichestvom dannyh. YA dumayu, chto  kniga
budet poleznym klassicheskim trudom i cherez pokolenie.
     Poluchennye im  rezul'taty  uverenno  podkreplyayut  soderzhashcheesya  v  MCH-M
utverzhdenie  o  tom, chto sootnoshenie  mezhdu chislennost'yu  zanyatyh i vremenem
vypolneniya  proekta  daleko  ne linejnoe,  chto  cheloveko-mesyac dejstvitel'no
yavlyaetsya mificheskoj meroj proizvoditel'nosti. V chastnosti, on schitaet:15
     - Sushchestvuet  optimal'noe,  s tochki  zreniya  zatrat,  vremya  vypolneniya
grafika dlya  pervoj postavki:  T =  2,5 (CHM)1/3. To est' optimal'noe vremya v
mesyacah  izmenyaetsya kak  kubicheskij  koren' predpolagaemogo ob®ema  rabot  v
cheloveko- mesyacah - formula, poluchennaya iz  ocenki razmera i drugih faktorov
v  ego modeli.  Sledstviem yavlyaetsya krivaya, dayushchaya  optimal'nuyu  chislennost'
zanyatyh.
     - Krivaya stoimosti medlenno rastet, esli zaplanirovannyj grafik dlinnee
optimal'nogo. Rabota zanimaet vse otvedennoe dlya nee vremya.
     - Krivaya  stoimosti rezko rastet, esli  zaplanirovannyj  grafik  koroche
optimal'nogo.
     - Prakticheski ni  odin proekt nevozmozhno zavershit'  bystree, chem  za  .
raschetnogo optimal'nogo grafika vne zavisimosti ot kolichestva zanyatyh v nem!
|tot  primechatel'nyj rezul'tat  daet menedzheru programmnogo proekta solidnoe
podkreplenie,  kogda  vysshee  rukovodstvo   trebuet  prinyatiya   nevozmozhnogo
grafika.
     Naskol'ko  veren  zakon   Bruksa?  Byli   dazhe   provedeny   tshchatel'nye
issledovaniya  zakona  Bruksa   (namerenno  uproshchennogo),  soglasno  kotoromu
vydelenie  dopolnitel'nyh  lyudej   dlya  otstayushchego   grafika  proekta   lish'
zaderzhivaet   ego  vypolnenie.   Luchshe   vsego  eto  sdelano  Abdel'-Hamidom
(Abdel-Hamid) i Madnikom  (Madnick)  v chestolyubivoj i cennoj knige "Dinamika
programmnogo  proekta:  integrirovannyj  podhod".16  V   knige   razrabotana
kolichestvennaya model' dinamiki proekta. Glava o zakone Bruksa bolee podrobno
vnikaet v  to, chto  proishodit  pri  razlichnyh dopushcheniyah otnositel'no togo,
kogo dobavlyayut, i kogda. CHtoby issledovat' eto, avtory razvivayut sobstvennuyu
tshchatel'nuyu model' programmnogo  proekta srednego razmera, predpolagaya, chto u
vnov'  dobavlyaemyh lyudej  est'  krivaya obucheniya,  i  uchityvaya dopolnitel'nye
izderzhki na obshchenie i obuchenie. Oni prihodyat k vyvodu, chto "dobavlenie novyh
lyudej  k  zapazdyvayushchemu  proektu  vsegda privodit  k ego udorozhaniyu, no  ne
vsegda   k  bolee  pozdnemu  zaversheniyu"   (kursiv  avtorov).  V  chastnosti,
uvelichenie chislennosti rabotnikov v nachale proekta gorazdo bezopasnee, chem v
konce,  poskol'ku  dobavlenie  novyh  lyudej  vsegda  vyzyvaet  otricatel'nyj
effekt, dlya kompensacii kotorogo trebuyutsya nedeli.
     SHtucke  (Stutzke)  predlagaet  bolee  prostuyu  model'   dlya  provedeniya
analogichnyh issledovanij,  i s tem zhe  rezul'tatom.17 On provodit  podrobnyj
analiz processa i izderzhek, svyazannyh s privlecheniem novyh rabotnikov, yavnym
obrazom  uchityvaya  otvlechenie  nastavnikov  ot  neposredstvennoj raboty  nad
proektom. On proveryal svoyu model' na real'nom proekte, v kotorom chislennost'
rabotnikom byla udvoena, blagodarya  chemu  udalos' ulozhit'sya v pervonachal'nyj
grafik,  nesmotrya na  otstavanie v seredine. On  rassmatrivaet  al'ternativy
dobavleniyu   novyh  rabotnikov,  osobenno  sverhurochnuyu  rabotu.  Naibol'shuyu
cennost'  predstavlyayut  ego  mnogochislennye  prakticheskie sovety  o tom, kak
privlekat'  novyh rabotnikov, obuchat'  ih,  obespechivat'  instrumentariem  i
t.d.,  chtoby  minimizirovat'  otricatel'nyj  effekt   uvelicheniya  personala.
Osobenno dostojno vnimaniya ego zamechanie,  chto dopolnitel'no privlekaemye na
pozdnih stadiyah proekta rabotniki dolzhny byt' igrokami komandy, stremyashchimisya
vojti   v  igru  i  vpisat'sya  v  process,  a  ne  pytat'sya   izmenit'   ili
usovershenstvovat' sam process!
     SHtucke schitaet, chto dopolnitel'naya tyazhest' obmena informaciej v krupnom
proekte  imeet vtoroj poryadok  malosti, i  ne vklyuchaet ee  v svoyu model'. Ne
vpolne yasno, uchityvayut li ee Abdel'-Hamid  i Madnik, i esli da, to kak. Ni v
odnoj iz modelej  ne  uchityvaetsya  to obstoyatel'stvo, chto rabota dolzhna byt'
pereraspredelena - process, kotoryj dlya menya chasto okazyvalsya netrivial'nym.
     "Krajne   uproshchennaya"   formulirovka  zakona  Bruksa  stanovitsya  bolee
poleznoj,   buduchi   dopolnena   etimi   tshchatel'no   sdelannymi  nadlezhashchimi
ogovorkami. Podytozhivaya,  ya prodolzhayu priderzhivat'sya  ishodnogo  utverzhdeniya
kak   priblizheniya  k  istine   nulevogo   poryadka,   prakticheskogo  pravila,
preduprezhdayushchego  menedzherov o nerazumnosti  instinktivnoj popytki  vytyanut'
zapazdyvayushchij proekt.
     Kadry reshayut vse (ili pochti vse)
     Nekotorye chitateli  udivlyayutsya,  chto  bol'shaya chast' rassuzhdenij  MCH-M
posvyashchena   administrativnym   storonam   programmnoj   inzhenerii,   a    ne
mnogochislennym  tehnicheskim  problemam. Takoj  perekos  chastichno  vyzvan toj
rol'yu, kotoruyu ya igral  v  IBM Operating System/360  (teper'  MVS/370). Esli
smotret' glubzhe, eto proishodit ot ubezhdeniya, chto kachestvo lyudej,  zanyatyh v
proekte,  ih organizaciya i administrirovanie imeyut gorazdo  bol'shee znachenie
dlya uspeha, chem instrumenty,  kotorymi  oni  pol'zuyutsya, ili primenyaemye imi
tehnicheskie resheniya.
     Posleduyushchie issledovaniya podkrepili moyu uverennost'. Model' COCOMO Bema
priznaet,  chto  kachestvo komandy  yavlyaetsya  vazhnejshim  faktorom  ee  uspeha,
prakticheski  vchetvero  bolee vazhnym,  chem sleduyushchij za  nim  po  znachimosti.
Bol'shinstvo nauchnyh issledovanij po programmnoj inzhenerii sosredotochilos' na
instrumentah. YA lyublyu horoshij  instrument i zhazhdu ego. Tem ne menee  otradno
videt' prodolzhenie issledovatel'skih programm v otnoshenii zaboty o lyudyah, ih
rosta  i  podderzhki,  a takzhe razvitiya upravleniya  razrabotkoj  programmnogo
obespecheniya.
     CHelovecheskij  faktor.  Krupnym dostizheniem  poslednih let  stala  kniga
Demarko  (DeMarco)  i  Listera  (Lister)  "CHelovecheskij faktor: produktivnye
proekty  i  programmy", izdannaya v 1987  godu. V osnove ee lezhit polozhenie o
tom,  chto  "glavnye  problemy  v nashej  rabote  po prirode svoej ne  stol'ko
tehnologicheskie, skol'ko sociologicheskie". Ona izobiluet takimi zhemchuzhinami,
kak "zadacha  menedzhera ne zastavit' lyudej rabotat', a sdelat' tak, chtoby oni
mogli rabotat'". V nej govoritsya o takih prozaicheskih  veshchah, kak pomeshchenie,
mebel',  sovmestnoe  pitanie  komandy. Demarko  i Lister  privodyat  real'nye
dannye  iz   svoego  "Programmirovaniya  voennyh  igr",   kotorye  pokazyvayut
porazitel'nuyu korrelyaciyu mezhdu proizvoditel'nost'yu  programmistov iz odnoj i
toj zhe organizacii, a  takzhe  mezhdu harakteristikami rabochih mest  i urovnem
produktivnosti i nalichiya oshibok.
     V  pomeshcheniyah  naibolee  produktivnyh  programmistov  tishe,  oni  bolee
lichnye, luchshe zashchishcheny  protiv neproshenogo vtorzheniya, i oni prosto bol'she...
Ponimaete li vy, chto pokoj,  prostranstvo i uedinennost' sposobstvuyut luchshej
rabote vashih tepereshnih  rabotnikov  ili  (s  drugoj  storony)  sposobstvuet
privlecheniyu i sohraneniyu luchshih rabotnikov?18
     YA iskrenne rekomenduyu etu knigu vsem moim chitatelyam.
     Peredacha proektov. Demarko i Lister udelyayut bol'shoe vnimanie spayannosti
komandy,  neulovimomu,  no  vazhnomu  kachestvu.  YA   dumayu,  chto  neponimanie
administraciej spayannosti  sluzhit prichinoj toj gotovnosti, s  kotoroj, kak ya
nablyudal,  v  kompaniyah,  raspolozhennyh  na  neskol'kih  ploshchadkah,  proekty
peredayutsya iz odnoj laboratorii v druguyu.
     V svoej praktike ya nablyudal, vozmozhno, s  poldyuzhiny  peredach proekta, i
ni odna iz  nih ne byla uspeshnoj. Mozhno  s uspehom peredavat' zadaniya. No vo
vseh sluchayah  popytki  peredat'  proekt  novaya  komanda fakticheski  nachinala
snachala, nesmotrya  na nalichie horoshej dokumentacii, nekotorogo prodvizheniya v
proekte  i nekotoryh lyudej iz  peredayushchej komandy.  YA dumayu,  chto razrushenie
spayannosti  prezhnej  komandy  privodit  k  vykidyshu proekta, nahodyashchegosya  v
embrional'nom sostoyanii, i osushchestvleniyu ego s nachal'noj tochki.
     Sila otkazat'sya ot vlasti
     Esli soglasit'sya, chto, kak ya neodnokratno dokazyval na protyazhenii etoj
knigi, tvorchestvo ishodit  ot  lichnostej,  a ne organizacionnyh  struktur  i
processov,  togda glavnaya zadacha  menedzhera  programmnogo proekta -  sozdat'
organizacionnuyu  strukturu i rabochij process,  sposobstvuyushchij  tvorchestvu  i
iniciative, a ne  podavlyayushchie  ih. K schast'yu, eta problema prisushcha ne tol'ko
programmnym  organizaciyam, i nad nej  rabotali  mnogie  bol'shie  umy. E.  F.
SHumaher (E. F. Schumacher) v klassicheskoj rabote "Maloe prekrasno: ekonomika
radi  lyudej"  predlagaet  teoriyu  organizacii  predpriyatij,  maksimiziruyushchuyu
tvorcheskuyu aktivnost' i  radost' rabotnikov.  V kachestve pervogo principa on
vydvigaet "princip  vspomogatel'noj  funkcii" iz encikliki Quadragesimo Anno
papy Piya XI:
     Peredacha  bol'shemu i vyshestoyashchemu soobshchestvu  togo,  chto  mogut  delat'
men'shie i nizhestoyashchie organizacii yavlyaetsya nespravedlivost'yu i v to zhe vremya
ser'eznym zlom i narusheniem pravil'nogo  poryadka.  Ibo  vsyakaya  obshchestvennaya
deyatel'nost'  po  suti  svoej dolzhna predostavlyat' pomoshch' chlenam  social'noj
gruppy, a ne  razrushat'  i pogloshchat' ih... Tem, kto upravlyaet, sleduet  byt'
uverennymi,   chto   chem   luchshe   sredi  razlichnyh   soobshchestv   sohranyaetsya
differencirovannyj poryadok v soblyudenii principa vtorostepennoj funkcii, tem
krepche  budet vlast'  i  effektivnost' v  obshchestve,  tem bolee  schastlivym i
procvetayushchim gosudarstvo.19
     SHumaher privodit raz®yasnenie:
     Princip  vtorostepennoj  funkcii  uchit nas, chto vlast' i  effektivnost'
centra uvelichatsya, esli budut tshchatel'no ohranyat'sya svoboda i otvetstvennost'
bolee  nizkih formirovanij,  a  v itoge  organizaciya  v  celom budet  "bolee
schastlivoj i procvetayushchej".
     Kak  mozhno  dobit'sya  takoj organizacii? ... Bol'shaya organizaciya dolzhna
sostoyat'  iz   mnozhestva  poluavtonomnyh   edinic,  kotorye   mozhno  nazvat'
kvazi-firmami.  Kazhdaya iz nih dolzhna obladat'  znachitel'noj  svobodoj, chtoby
predostavit'  nailuchshie  vozmozhnosti  dlya  tvorchestva  i predpriimchivosti...
Kazhdaya  iz  kvazi- firm  dolzhna  imet' svoj uchet pribylej i poter',  a takzhe
balansovyj otchet.20
     K   chislu  naibolee  zamechatel'nyh  dostizhenij  programmnoj   inzhenerii
prinadlezhat pervye etapy prakticheskogo osushchestvleniya  takih  organizacionnyh
idej.  Prezhde vsego,  mikrokomp'yuternaya revolyuciya sozdala novuyu  programmnuyu
industriyu s sotnyami vnov' voznikshih firm, kotorye iznachal'no maly i otmecheny
entuziazmom,  svobodoj  i  tvorchestvom.  Sejchas  industriya menyaetsya  po mere
pogloshcheniya melkih firm krupnymi. Posmotrim, pojmut li krupnye firmy vazhnost'
sohraneniya tvorcheskoj aktivnosti melkih, pogloshchaemyh imi.
     Eshche  bolee primechatel'no,  chto  vysshee  rukovodstvo ryada  krupnyh  firm
predprinyalo mery po  peredache vlasti vniz otdel'nym komandam, rabotayushchim nad
programmnymi  proektami,  chto  sblizhaet  ih  s  kvazi-firmami   SHumahera  po
strukture i otvetstvennosti. Rezul'taty vyzvali udivlenie i udovletvorenie.
     Dzhim Makkarti iz Microsoft opisyval mne svoj opyt emansipacii komand:
     U  kazhdoj  brigady  (30-40 chelovek)  est'  svoj  nabor  razrabatyvaemyh
ob®ektov, svoj grafik i dazhe svoi pravila razrabotki, realizacii i postavki.
V  brigade  est'  specialisty  v  chetyreh  ili pyati  oblastyah, v  tom  chisle
realizacii,  testirovanii  i  dokumentirovanii.   Brigada   sama   ulazhivaet
raznoglasiya  po  pustyakam,  nachal'nik  ne vmeshivaetsya. Ne  boyus' pereocenit'
vazhnost'   peremeshcheniya   vlasti,   kogda   brigada    samostoyatel'no   neset
otvetstvennost' za svoi dostizheniya.
     |rl Uiler (Earl Wheeler), byvshij rukovoditel'  programmnyh  razrabotok
IBM, podelilsya so mnoj svoim opytom  delegirovaniya vniz polnomochij, byvshih v
techenie dolgogo vremeni sosredotochennymi u administracii upravleniya IBM.
     Klyuchevym poryvom poslednih let stalo delegirovanie polnomochij vniz. |to
bylo  chudom!  Uluchshilis'  kachestvo,  produktivnost',  moral'nyj duh.  U  nas
nebol'shie brigady bez centralizovannogo upravleniya. Brigady sami  opredelyayut
pravila proizvodstvennogo processa,  no oni  ispytyvayut  davlenie so storony
rynka. I eto davlenie zastavlyaet ih samih iskat' sposoby resheniya problem.
     Obshchenie   s  otdel'nymi   chlenami   brigad  pokazyvaet,   konechno,  i
udovletvorenie  ot peredachi  polnomochij i svobody, a takzhe bolee  sderzhannuyu
ocenku  togo,  v  kakoj mere kontrol' dejstvitel'no oslablen. Tem  ne menee,
dostignutaya stepen' peredachi polnomochij yavlyaet shag v pravil'nom napravlenii.
Poluchaemye  vygoda tochno te, kotorye predskazyvalis'  Piem XI:  v rezul'tate
delegirovaniya polnomochij centr usilivaet svoyu real'nuyu vlast', a organizaciya
v celom stanovitsya bolee schastlivoj i procvetayushchej.
     Kakoj samyj bol'shoj syurpriz? Milliony komp'yuterov
     Vse komp'yuternye guru,  s kotorymi  ya razgovarival, priznayut, chto dlya
nih  byli  neozhidannost'yu  mikrokomp'yuternaya  revolyuciya  i  ee  porozhdenie -
proizvodstvo  korobochnyh  programmnyh produktov.  Vne  somneniya,  eto  samoe
znachitel'noe  sobytie  za  dva  desyatiletiya  posle  vyhoda  MCH-M.  Ono imeet
mnogochislennye posledstviya dlya programmnoj inzhenerii.
     Mikrokomp'yuternaya    revolyuciya    izmenila    harakter    ispol'zovaniya
komp'yuterov. SHumaher sformuliroval problemu bolee 20 let nazad:
     CHego my dejstvitel'no hotim  ot uchenyh i tehnologov?  YA otvechu tak: nam
nuzhny metody i oborudovanie, kotorye:
     - dostatochno deshevy, chtoby byt' dostupnymi prakticheski kazhdomu;
     - prigodny dlya nebol'shih prilozhenij;
     - sootvetstvuyut potrebnosti cheloveka v tvorcheskoj deyatel'nosti.21
     |to  kak  raz  te  zamechatel'nye  svojstva,  kotorye  mikrokomp'yuternaya
revolyuciya  dala  komp'yuternoj  promyshlennosti i  ee  potrebitelyam,  kotorymi
teper'  stala  shirokaya  publika. Srednij amerikanec mozhet segodnya  pozvolit'
sebe ne tol'ko sobstvennyj komp'yuter,  no i nabor programmnyh  sredstv,  dlya
pokupki kotorogo 20 let nazad potrebovalos' by korolevskoe zhalovan'e. Kazhduyu
iz celej,  postavlennyh SHumaherom,  stoit rassmotret' otdel'no. Predstavlyaet
takzhe  interes, v kakoj mere  oni dostignuty -  osobenno poslednyaya.  V odnoj
oblasti  za drugoj  obychnym  lyudyam i professionalam stanovyatsya dostupny  vse
novye sredstva samovyrazheniya.
     Otchasti, razvitie v drugih oblastyah proishodit tak zhe,  kak  v sozdanii
programm - blagodarya ustraneniyu pobochnyh trudnostej. Pobochnye ogranicheniya na
rukopisi   nakladyvalis'  dlitel'nost'yu  i  stoimost'yu  perepechatyvaniya  dlya
vneseniya ispravlenij.  Rabotu  ob®emom  v  300  stranic  inogda  prihodilos'
perepechatyvat'  kazhdye  tri  ili  shest'  mesyacev,  a  v pereryve  chirkat'  v
rukopisi. Trudno bylo ocenit' vliyanie vnesennyh izmenenij na obshchij hod mysli
i ritm slov. Sejchas chudesnym obrazom rukopisi stali postoyanno menyayushchimisya.22
     Analogichnuyu  izmenchivost' komp'yuter  pridal mnogim  drugim  materialam:
kartinam  hudozhnikov,  planam  postroek,  chertezham  mehanizmov,  muzykal'nym
sochineniyam, fotografiyam, kinofil'mam, slajdovym prezentaciyam, mul'timedijnym
rabotam  i  dazhe elektronnym tablicam.  V kazhdom sluchae pri  ruchnom  sposobe
izgotovleniya  dlya togo,  chtoby  uvidet' izmeneniya v  kontekste,  trebovalos'
kopirovanie bol'shih neizmennyh chastej. Teper',  nezavisimo  ot materiala, my
mozhem pol'zovat'sya takimi zhe  vygodami,  kakie  rabota  v  rezhime razdeleniya
vremeni prinesla v programmirovanie: vozmozhnost' redaktirovaniya i mgnovennoj
ocenki rezul'tata bez poteri hoda mysli.
     Tvorcheskie   vozmozhnosti  usililis'   takzhe  blagodarya   novym   gibkim
vspomogatel'nym instrumentam. Odin primer - sochinenie prozy,  pri kotorom my
pol'zuemsya  proverkoj  orfografii,  grammatiki, stilisticheskimi podskazkami,
sistemami  bibliografii  i  zamechatel'noj  vozmozhnost'yu  odnovremenno videt'
stranicy v  okonchatel'no otformatirovannom vide. My  eshche ne ocenili znacheniya
mgnovennogo  dostupa  k  enciklopediyam  i  bezgranichnym  resursam  vsemirnoj
pautiny dlya ispol'zovaniya pisatelem improvizirovannogo poiska.
     Samoe  glavnoe, obretennaya  izmenchivost'  materiala  uproshchaet  izuchenie
mnogih  v  korne razlichnyh  vozmozhnostej,  kogda  tvorcheskaya  rabota  tol'ko
obretaet formu. Vot drugoj primer, kogda  poryadok velichiny  v kolichestvennom
parametre - v  dannom sluchae, vremeni, neobhodimom dlya vneseniya izmenenij, -
proizvodit kachestvennyj skachok v podhode k zadache.
     Instrumenty  dlya  chercheniya  pozvolyayut  proektirovshchikam  zdanij  za  chas
tvorcheskoj   raboty  issledovat'   gorazdo   bol'she  variantov.  Podklyuchenie
komp'yuterov k sintezatoram i programmy, pozvolyayushchie avtomaticheski zapisyvat'
ili proigryvat' noty, znachitel'no oblegchayut fiksaciyu brenchaniya po  klavisham.
Cifrovaya obrabotka  fotografij, kak  v Adobe Photoshop, pozvolyaet v  techenie
schitannyh minut provesti eksperimenty, dlya kotoryh potrebovalis' chasy raboty
v  fotolaboratorii. |lektronnye tablicy  pozvolyayut legko issledovat' desyatki
al'ternativnyh scenariev tipa "chto, esli".
     Nakonec,  blagodarya  vezdesushchesti  personal'nyh  komp'yuterov  sozdaetsya
sovershenno novyj material. Giperteksty, predlozhennye Vannevarom Bushem v 1945
godu, osushchestvimy tol'ko s pomoshch'yu komp'yuterov.23 Mul'timedijnye prezentacii
i opyty byli  slozhnejshimi zadachami  - slishkom mnogo hlopot  -  do togo,  kak
stalo vozmozhnym  provodit'  ih  s  pomoshch'yu  komp'yuterov  i  sootvetstvuyushchego
bogatogo programmnogo obespecheniya. Sistemy virtual'noj  real'nosti, poka eshche
dorogie i ne  shiroko rasprostranennye, v budushchem  stanut  takimi i  sozdadut
novyj material dlya tvorchestva.
     Mikrokomp'yuternaya revolyuciya izmenila harakter  razrabotki  programmnogo
obespecheniya.  Tehnologii  razrabotki  programmnogo  obespecheniya  1970-h sami
izmenilis'  v  rezul'tate  mikrokomp'yuternoj   revolyucii  i   vyzvavshih   ee
tehnicheskih   dostizhenij.  Ustranena   znachitel'naya   chast'   vtorostepennyh
slozhnostej   tehnologij   razrabotki   programmnogo   obespecheniya.   Bystrye
personal'nye  komp'yutery  stali obychnym  instrumentom razrabotchika, i  vremya
oborachivaemosti stalo  pochti ustarevshim ponyatiem.  Segodnyashnij  personal'nyj
komp'yuter bystree  ne tol'ko  superkomp'yutera  60-go goda, no i Unix-stancii
1985-go.  |to  znachit, chto kompilyaciya bystro osushchestvlyaetsya dazhe na skromnyh
po moshchnosti mashinah, a blagodarya bol'shomu  ob®emu pamyati otpali zaderzhki pri
komponovke s ispol'zovaniem diskov. Bol'shaya pamyat' pozvolyaet takzhe hranit' v
pamyati  tablicy  simvolicheskih imen  vmeste s ob®ektnym kodom, v  rezul'tate
chego stanovitsya obychnoj vysokourovnevaya otladka bez perekompilyacii.
     Za  poslednie  20  let my pochti pokonchili  s  ispol'zovaniem razdeleniya
vremeni kak metodologiej  razrabotki programmnogo  obespecheniya. V 1975  godu
razdelenie vremeni  tol'ko-tol'ko vytesnilo paketnuyu  obrabotku  v  kachestve
naibolee  rasprostranennoj  tehnologii. Set' ispol'zovalas' dlya  togo, chtoby
dat' razrabotchiku programmnogo obespecheniya dostup kak  k obshchim fajlam, tak i
k   bol'shim  vychislitel'nym   moshchnostyam   dlya   kompilyacii,   komponovki   i
testirovaniya.  Segodnya  vychislitel'nuyu  moshchnost'  obespechivaet  personal'naya
rabochaya stanciya,  a set' ispol'zuetsya v osnovnom dlya obespecheniya sovmestnogo
dostupa k fajlam brigady,  razrabatyvayushchej produkt. Klient-servernye sistemy
menyayut  i  uproshchayut   tehnologiyu  obshchego  dostupa  dlya  zagruzki,  sborki  i
vypolneniya kontrol'nyh primerov.
     Shodnyj progress proizoshel s  pol'zovatel'skimi interfejsami. Interfejs
WIMP  obespechivaet  gorazdo  bol'shie  udobstva  pri  redaktirovanii  tekstov
programm  i tekstov na estestvennom  yazyke.  |kran razmerom  24 stroki na 72
kolonki  smenilsya  polnostranichnym ili dazhe dvuhstranichnym  ekranom, poetomu
programmisty mogut videt' izmeneniya, kotorye oni delayut, v znachitel'no bolee
shirokom kontekste.
     Celaya novaya programmnaya otrasl' - korobochnye pakety
     Ryadom s klassicheskoj industriej programmnyh produktov shiroko razvilas'
eshche  odna. Prodazhi  programmnyh  produktov  chislyatsya  sotnyami  tysyach i  dazhe
millionami.  Celye  moshchnye  pakety  mozhno  priobresti  po cene  men'shej, chem
stoimost' oplaty odnogo rabochego dnya programmista. |ti dve otrasli vo mnogom
razlichny i sushchestvuyut parallel'no.
     Klassicheskaya programmnaya industriya. V  1975  godu programmnaya industriya
imela neskol'ko otdel'nyh i do nekotoroj stepeni razlichnyh sostavnyh chastej,
sushchestvuyushchih po sej den':
     - Proizvoditeli komp'yuterov, postavlyayushchie takzhe  operacionnye  sistemy,
kompilyatory i utility dlya svoih produktov.
     -  Pol'zovateli   prilozhenij,  naprimer,  v   informacionno-upravlyayushchih
sistemah,  bankah,   strahovyh   kompaniyah,  pravitel'stvennyh  uchrezhdeniyah,
sozdayushchie pakety programm dlya sobstvennogo upotrebleniya.
     -   Razrabotchiki   zakaznyh   programm,  rabotayushchie   po   kontraktu  s
pol'zovatelem.  Mnogie iz etih  podryadchikov specializiruyutsya  na prilozheniyah
dlya voennoj sfery, gde trebovaniya, standarty i marketingovye procedury nosyat
specificheskij harakter.
     -  Razrabotchiki  kommercheskih paketov, v  to  vremya  razrabatyvavshie, v
osnovnom,  bol'shie  prilozheniya dlya  specificheskih rynkov,  takie  kak pakety
statisticheskogo analiza i avtomaticheskogo proektirovaniya.
     Tom  Demarko otmechaet  fragmentaciyu  klassicheskoj  industrii razrabotki
programmnogo obespecheniya, osobenno v chasti pol'zovatelej prilozhenij:
     YA  ne  ozhidal,  chto eta  oblast' raspadetsya na otdel'nye  nishi.  Priemy
raboty  v  bol'shej stepeni  opredelyayutsya  nishej,  chem  ispol'zovaniem  obshchih
metodov analiza  sistem,  yazykov programmirovaniya i tehnologij testirovaniya.
Ada byl poslednim iz yazykov obshchego naznacheniya, i on stal yazykov nishi.
     V  nishe  obychnyh  kommercheskih  prilozhenij  znachitel'nyj vklad sdelan
yazykami chetvertogo pokoleniya (4GL). Bem pishet, chto "naibolee udachnye iz  4GL
yavilis' rezul'tatom napisaniya kakoj-libo chasti oblasti  prilozhenij na  yazyke
opcij i parametrov". Naibolee shiroko rasprostranennymi  iz etih 4GL yavlyayutsya
generatory prilozhenij i  kombinirovannye pakety baz dannyh i svyazi s yazykami
zaprosov.
     Miry  operacionnyh  sistem  ob®edinilis'.  V  1975  godu  bylo  izobili
operacionnyh sistem - u kazhdogo proizvoditelya komp'yuterov  byla, po  krajnej
mere, odna patentovannaya  operacionnaya sistema dlya  kazhdoj  proizvodstvennoj
serii, a chasto i dve. Naskol'ko  izmenilos' polozhenie segodnya! Lozungom  dnya
stali otkrytye sistemy, i ostalos' lish'  pyat' glavnyh operacionnyh sred, dlya
kotoryh sozdayutsya pakety prilozhenij (v hronologicheskom poryadke):
     - IBM MVS i VM
     - DEC VMS
     - Unix v tom ili inom variante
     - IBM PC, bud' to DOS, OS/2 ili Windows
     - Apple Macintosh.
     Industriya korobochnyh  produktov. |konomicheskie zakony dlya razrabotchikov
v etoj  otrasli sovershenno otlichny ot teh, kotorye  dejstvuyut v klassicheskoj
industrii:   stoimost'   razrabotki  nuzhno  delit'  na  bol'shoe   kolichestvo
ekzemplyarov,  rashody  na  upakovku  i   marketing  vysoki.  V  klassicheskoj
industrii pri vnutrifirmennoj razrabotke  grafik rabot i nabor funkcij mogli
byt' izmeneny, v otlichie ot stoimosti razrabotki. Na otkrytom  rynke zhestkoj
konkurencii sroki i funkcional'nost' polnost'yu dominiruyut nad  zatratami  na
razrabotku.
     Kak  i  sledovalo ozhidat',  stol'  razlichnye  ekonomicheskie  trebovaniya
porodili  ves'ma  razlichayushchiesya kul'tury  programmirovaniya.  V  klassicheskoj
industrii  lidiruyushchee  polozhenie  zanyali  krupnye  firmy  s  ustanovivshimisya
stilyami  upravleniya  i kul'turoj  raboty.  V korobochnoj industrii, naprotiv,
voznikli  sotni nachinayushchih  firm, nichem ne  svyazannyh  i sosredotochennyh  na
konechnoj  celi,  a ne  na  processe.  V  takoj atmosfere  talant  otdel'nogo
programmista  vsegda  cenitsya  znachitel'no  vyshe,  i  sushchestvuet  podspudnoe
oshchushchenie,  chto  vydayushchiesya proekty sozdayutsya vydayushchimisya  arhitektorami.  Vo
vnov'   voznikshej    kul'ture   est'   vozmozhnost'   voznagrazhdat'   "zvezd"
sootvetstvenno  ih vkladu. V klassicheskoj industrii social'naya politika firm
i ih principy oplaty truda vsegda eto zatrudnyali. Neudivitel'no poetomu, chto
mnogie zvezdy novogo pokoleniya byli vtyanuty v orbitu paketnoj industrii.
     Pokupaj  i  sozdavaj:  korobochnye  produkty   v  kachestve   komponentov
Radikal'no uluchshit'  ustojchivost' programmnyh produktov i proizvoditel'nost'
truda pri ih sozdanii mozhno, lish' podnyavshis' na  odin uroven' i izgotavlivaya
programmy  iz  modulej  ili  ob®ektov.  Osobenno  mnogoobeshchayushchej  tendenciej
stanovitsya  ispol'zovanie rynochnyh  paketov  v kachestve platform, na kotoryh
sozdayutsya bolee bogatye  i  specializirovannye produkty. Sistema  upravleniya
dvizheniem   gruzovikov  sozdaetsya  s  pomoshch'yu  korobochnoj   bazy   dannyh  i
kommunikacionnogo  paketa, takzhe kak i informacionnaya sistema dlya studentov.
Ob®yavleniya    v   zhurnalah   predlagayut   sotni   stekov    dlya   Hypercard,
specializirovannyh shablonov dlya Excel, desyatki special'nyh funkcij na Pascal
dlya MiniCad ili funkcij na AutoLisp dlya AutoCad.
     Metaprogrammirovanie.  Steki dlya Hypercard,  specializirovannye shablony
dlya  Excel,  funkcii  dlya   MiniCad  chasto  nazyvayut  metaprogrammirovaniem,
sozdaniem  novogo sloya, prisposablivayushchego  funkcii  k  nuzhdam  opredelennoj
gruppy  pol'zovatelej  paketa.  Ideya   metaprogrammirovaniya  ne   nova,  ona
vernulas'  i  poluchila  svoe nazvanie.  V nachale  60-h mnogie  proizvoditeli
komp'yuterov i vychislitel'nye centry bol'shih informacionno-upravlyayushchih sistem
obrazovyvali   nebol'shie   gruppy  specialistov,   sozdavavshih  celye  yazyki
prikladnogo programmirovaniya s pomoshch'yu makrosov, napisannyh na assemblere. V
vychislitel'nom   centre   Eastman   Kodak  byl   sozdan   yazyk   prikladnogo
programmirovaniya  na  baze  makroassemblera  dlya  IBM  7080.  Analogichno,  v
telekommunikacionnoj  programme Queued Telecommunications  Access Method dlya
IBM OS/360 mozhno bylo na mnogih stranicah koda, napisannogo predpolozhitel'no
na yazyke makroassemblera, ne najti ni odnoj komandy mashinnogo urovnya. Sejchas
bloki,  sozdavaemye  metaprogrammistom,  znachitel'no bol'she,  chem  togdashnie
makroopredeleniya. Takoe razvitie  vtorichnogo  rynka ochen' obnadezhivaet: poka
my zhdali vozniknoveniya aktivnogo rynka  klassov C++, nezametno  voznik rynok
metaprogramm mnogokratnogo ispol'zovaniya.
     |to  dejstvitel'no  nastuplenie  na  sushchnost'.  Poskol'ku  na  srednego
programmista  informacionno-upravlyayushchih sistem fenomen razrabotki  na osnove
paketov eshche ne okazal  vozdejstviya, on  poka ne ochen'  zamechaem  programmnoj
inzheneriej.  Tem  ne  menee,  eto   napravlenie  budet  bystro  razvivat'sya,
poskol'ku zatragivaet  sushchnost'  modelirovaniya  konceptual'nyh  konstrukcij.
Korobochnyj paket predostavlyaet bol'shoj funkcional'nyj modul'  so slozhnym, no
tochnym  interfejsom,  a  ego  vnutrennyuyu  konceptual'nuyu  strukturu vovse ne
trebuetsya proektirovat'. Programmnye produkty  s funkciyami  vysokogo urovnya,
takie kak Excel i  4th Dimension, dejstvitel'no yavlyayutsya bol'shimi  modulyami,
no  sluzhat  ponyatnymi,  dokumentirovannymi, otlazhennymi modulyami,  s pomoshch'yu
kotoryh mozhno sozdavat' zakaznye sistemy. Razrabotchiki prilozhenij sleduyushchego
urovnya poluchayut bogatstvo funkcij, sokrashchenie vremeni razrabotki, otlazhennye
komponenty, uluchshennuyu dokumentaciyu i rezko snizhennuyu cenu.
     Slozhnost',  konechno,  v  tom,  chto korobochnye  pakety  razrabotany  kak
samostoyatel'nye  ob®ekty,  funkcii i interfejsy kotoryh  metaprogrammisty ne
mogut  izmenit'.  Krome   togo,  bolee  sushchestvenno  to,  chto   razrabotchiki
korobochnyh  paketov, kazhetsya,  ne  slishkom stremyatsya  sdelat' svoi  produkty
prigodnymi  v  kachestve  modulej  bolee  krupnyh  sistem. Dumayu,  chto  takoe
ponimanie   neverno,  i  sushchestvuet  neudovletvorennyj  rynok  dlya  paketov,
sposobstvuyushchih ispol'zovaniyu metaprogrammirovaniya.
     Tak  chto  zhe  trebuetsya?  Mozhno  vydelit' chetyre  urovnya  pol'zovatelej
korobochnyh produktov:
     -   Pol'zovatel'  kak   takovoj,  prosto   ispol'zuyushchij   prilozhenie  i
udovletvorennyj funkciyami i interfejsom, predostavlennymi razrabotchikami.
     -   Metaprogrammist,  stroyashchij  shablony  i  funkcii  poverh  otdel'nogo
prilozheniya  s  ispol'zovaniem imeyushchihsya interfejsov,  glavnym  obrazom,  dlya
obespecheniya truda konechnogo pol'zovatelya.
     - Razrabotchik  vneshnih funkcij,  vvodyashchij v  prilozhenie  dopolnitel'nye
funkcii. |to, po  suti, novye primitivy yazyka prikladnogo  programmirovaniya,
obrashchayushchiesya k  otdel'nym modulyam,  napisannym na  yazyke  obshchego naznacheniya.
Neobhodima  vozmozhnost' interfejsa etih  novyh  funkcij  s prilozheniem cherez
perehvatyvaemye komandy, obratnye vyzovy ili peregruzhaemye funkcii.
     -  Metaprogrammist,  ispol'zuyushchij  odno  i,  v  osobennosti,  neskol'ko
prilozhenij  v  kachestve komponentov bolee krupnoj sistemy. |to pol'zovatel',
ch'i nuzhdy segodnya  slabo udovletvoryayutsya. |to tot vid ispol'zovaniya, kotoryj
obeshchaet naibol'shij rost proizvoditel'nosti pri sozdanii novyh prilozhenij.
     Dlya etogo poslednego tipa pol'zovatelej korobochnyj produkt dolzhen imet'
dopolnitel'nyj dokumentirovannyj interfejs - interfejs metaprogrammirovaniya.
On dolzhen predostavlyat' neskol'ko vozmozhnostej.  Prezhde vsego, metaprogramma
dolzhna   upravlyat'  ansamblem   prilozhenij,  nesmotrya  na   to,  chto  kazhdoe
prilozhenie,  kak pravilo, schitaet, chto upravlyaet samim soboj.  |tot ansambl'
dolzhen  upravlyat'  interfejsom  pol'zovatelya,  hotya  obychno  samo prilozhenie
schitaet,  chto delaet  eto.  Ansambl' dolzhen byt'  v sostoyanii vyzvat'  lyubuyu
funkciyu  prilozheniya,   kak  esli   by  ego  komandnaya   stroka  ishodila  ot
pol'zovatelya. Vyhodnye  dannyh  prilozheniya dolzhny peredavat'sya emu, a  ne na
ekran,  prichem  v  vide  logicheskih  blokov  podhodyashchih  tipov dannyh,  a ne
tekstovoj  stroki,  kotoruyu  nuzhno  otobrazit'.  V   nekotoryh  prilozheniyah,
naprimer,  FoxPro,  est' dyrochki, pozvolyayushchie peredat' komandnuyu stroku,  no
vozvrashchayutsya  skudnye i  nerazobrannye dannye. Takaya dyrochka  - zaplatka  na
skoruyu ruku, v to vremya kak trebuetsya obshchee prorabotannoe reshenie.
     Bol'shie vozmozhnosti  dalo  by  nalichie  yazyka scenariev dlya  upravleniya
vzaimodejstviem prilozhenij, vhodyashchih v ansambl'. Takogo roda funkcii vpervye
predostavila  Unix   s   pomoshch'yu  kanalov  i  standarta   fajlov  v  formate
ASCII-strok. Segodnya neplohim resheniem yavlyaetsya AppleScript.
     Sostoyanie i budushchee programmnoj inzhenerii
     Odnazhdy ya poprosil Dzhima Ferrella (Jim Ferrell), predsedatelya  himiko-
tehnologicheskogo fakul'teta universiteta shtata Severnaya Karolina  povedat' o
razvitii  himicheskih  tehnologij vne  svyazi s himiej, na chto  on  ekspromtom
vydal   mne   zamechatel'nyj   rasskaz,   prodolzhavshijsya   chas,   nachinaya   s
sushchestvovavshih s antichnyh  vremen  razlichnyh  proizvodstvennyh processov dlya
mnogih  produktov - ot  stali do hleba i  parfyumernyh izdelij. On rasskazal,
kak professor  Artur  D. Littl (Arthur D.  Little) v 1918 godu osnoval v MTI
fakul'tet prikladnoj  himii  dlya  issledovaniya, razrabotki  i obucheniya obshchim
fundamental'nym  tehnologiyam  vseh   processov.  Snachala  byli  prakticheskie
pravila,  zatem   empiricheskie  nomogrammy,   zatem  recepty  proektirovaniya
otdel'nyh komponentov, zatem  matematicheskie  modeli rasprostraneniya  tepla,
mass, kolichestva dvizheniya v otdel'nyh emkostyah.
     Po   hodu  rasskaza  Ferrella  ya  porazilsya   obiliyu  parallelej  mezhdu
razrabotkoj   himicheskih  tehnologij  i  razvitiem  programmnyh  tehnologij,
proishodivshim pochti polveka  spustya. Parnas utverzhdaet, chto ya  voobshche pishu o
"programmnoj inzhenerii".  On  protivopostavlyaet programmotehniku  kak  nauku
elektrotehniku i schitaet, chto nazyvat' nashe zanyatie inzheneriej samonadeyanno.
Vozmozhno,  on  prav  v  tom, chto  eta  oblast'  nikogda ne stanet inzhenernoj
disciplinoj  s  takoj  tochnoj  i   vseohvatyvayushchej  osnovoj,  kakaya  est'  u
elektrotehniki.  V  konce koncov, programmnaya inzheneriya,  podobno himicheskoj
tehnologii, zanyata nelinejnymi zadachami uvelicheniya masshtabov do promyshlennyh
processov  i,  podobno  organizacii  promyshlennogo  proizvodstva,  postoyanno
stavitsya v tupik slozhnostyami chelovecheskogo povedeniya.
     Tem ne menee harakter i vremennye ramki  razvitiya himicheskoj tehnologii
privodyat  menya  k  mysli, chto  programmnaya  inzheneriya v vozraste 27  let  ne
stol'ko   beznadezhna,   skol'ko    yavlyaetsya   nezreloj,   kakoj   himicheskaya
promyshlennost'   byla  v   1945  godu.   Lish'  posle  Vtoroj  mirovoj  vojny
himiki-tehnologi real'no obratilis' k  vzaimosvyazannym potochnym  sistemam  s
zamknutym ciklom.
     Segodnya harakternye zadachi programmnoj inzhenerii zvuchat tochno  tak  zhe,
kak oni izlozheny v glave 1:
     - Kak proektirovat' i stroit' programmy, obrazuyushchie sistemy.
     - Kak proektirovat' i stroit' programmy i sistemy, yavlyayushchiesya nadezhnym,
otlazhennym, dokumentirovannym i soprovozhdaemym produktom.
     -  Kak  osushchestvlyat'  intellektual'nyj  kontrol'   v  usloviyah  bol'shoj
slozhnosti.
     V  smolyanoj yame programmnoj inzhenerii eshche dolgo pridetsya vyaznut'. Mozhno
ozhidat', chto chelovechestvo prodolzhit opyty s sistemami  kak vnutri,  tak i za
predelami  nashih  vozmozhnostej.  Programmnye  sistemy  yavlyayutsya,   vozmozhno,
naibolee  zaputannymi chelovecheskimi tvoreniyami. |to slozhnoe  remeslo trebuet
nepreryvno  razvivat'  etu  disciplinu, uchit'sya sozdavat'  iz bolee  krupnyh
blokov,  nailuchshim  obrazom  ispol'zovat'  novye   instrumenty,  staratel'no
osvaivat'  oprobovannye  metody  upravleniya  inzheneriej,  shchedro ispol'zovat'
zdravyj  smysl   i  smirenno  soznavat'   svoyu   podverzhennost'   oshibkam  i
ogranichennost' nashih vozmozhnostej.
     |pilog Pyat'desyat  let udivleniya, voshishcheniya i radostiV moej pamyati  vse
eshche zhivy udivlenie i vostorg, s kotorym  ya - mne togda bylo 13  let  - chital
otchet ot 7  avgusta 1944  goda ob osvyashchenii komp'yutera Mark I,  arhitektorom
kotorogo byl Govard Ajken (Howard Aiken), a proektirovshchikami - inzhenery Kler
Lejk (Clair D. Lake), Bendzhamin Durfi (B. M. Durfee) i Frensis Gamil'ton (F.
E. Hamilton). Takoj zhe  vyzyvayushchej oshchushchenie chuda byla stat'ya Vannevara  Busha
(Vannevar Bush) "That We May Think" v aprel'skom 1945  goda nomere "Atlantic
Monthly", v  kotoroj  on  predlozhil  organizovat'  znaniya  v  vide  ogromnoj
gipertekstovoj  pautiny i obespechit' pol'zovatelej mashinami dlya perehodov po
sushchestvuyushchim ssylkam i sozdaniya novyh associativnyh sledov.
     Novyj tolchok  moya strast' k  komp'yuteram poluchila v 1952  godu,  kogda,
rabotaya letom na IBM v |dinkote, shtat N'yu-Jork,  ya poluchil prakticheskij opyt
programmirovaniya dlya IBM 604 i formal'noe  obuchenie programmirovaniyu dlya IBM
701, ih pervoj mashiny s hranimoj programmoj. Aspirantura u Ajkena i Iversona
v Garvarde sdelala real'nost'yu moi mechty o professii,  i ya svyazal s  nej vsyu
svoyu  zhizn'. Nemnogim  Bog daet pravo zarabatyvat' na zhizn' tem, chem  oni  s
radost'yu  zanimalis'  by  po  sobstvennoj  vole,  po uvlecheniyu. YA blagodaren
sud'be.
     Dlya cheloveka,  vlyublennogo v komp'yutery, trudno bylo  by pridumat' inoe
vremya, kogda tak radostno bylo zhit'. Ot mehanicheskih ustrojstv  do vakuumnyh
lamp, tranzistorov  i  integral'nyh  shem  shlo  burnoe razvitie  tehnologii.
Pervyj komp'yuter, na kotorom ya  rabotal srazu posle vypuska iz Garvarda, byl
superkomp'yuter  IBM Stretch. |tot  komp'yuter carstvoval nad mirom  kak samyj
bystryj s 1961 po 1964 gody; bylo izgotovleno 9 ekzemplyarov. Moj segodnyashnij
Macintosh Powerbook ne tol'ko bystree, s  bol'shej pamyat'yu  i bol'shim diskom,
no i v tysyachu raz deshevle  (v pyat'  tysyach raz deshevle s uchetom inflyacii). My
byli  svidetelyami togo,  kak  poocheredno proizoshli  komp'yuternaya  revolyuciya,
revolyuciya  elektronnyh  komp'yuterov, revolyuciya  minikomp'yuterov  i revolyuciya
mikrokomp'yuterov, v rezul'tate kazhdoj iz kotoryh komp'yuterov stanovilos'  na
poryadki bol'she.
     Oblast'  svyazannyh  s  komp'yuterami  znanij  preterpela  vzryv,  kak  i
sootvetstvuyushchaya  tehnologiya.  Buduchi  aspirantom  v  seredine  50-h,  ya  mog
prochest'  vse zhurnaly i trudy  konferencij. YA mog  ostavat'sya na sovremennom
urovne  vo  vsej nauchnoj discipline. Segodnya  zhe mne v moej intellektual'noj
zhizni  prihoditsya s sozhaleniem  rasstavat'sya s interesami to v  odnoj,  to v
drugoj   podoblasti,  poskol'ku   kolichestvo   dokumentov  prevysilo  vsyakuyu
vozmozhnost'  spravit'sya   s  nimi.  Massa  interesov,   massa  zamechatel'nyh
vozmozhnostej dlya ucheby, issledovanij, razmyshlenij. CHudesnoe zatrudnenie!  Ne
tol'ko konca ne vidno, no i shag ne zamedlyaetsya. V budushchem nas ozhidayut mnogie
radosti.


    Primechaniya i ssylki


     Glava 1
     1. A.  P.  Ershov polagaet, chto  eto ne tol'ko  pechal',  no  otchasti  i
radost'. A.  P. Ershov. Aesthetics  and  the human factor in programming  //
CACM. 1972. Vol. 15, N 7. July. P. 501-505
     Glava 2
     1. V. A. Vysockij iz Bell Telephone Laboratories schitaet, chto bol'shoj
proekt mozhet  vyderzhat' do 30% prirosta chisla sotrudnikov v god. Pri bol'shem
uvelichenii zatrudnyaetsya i  dazhe  podavlyaetsya  razvitie  vazhnoj  neformal'noj
struktury i ee kommunikacionnyh svyazej,  o chem govoritsya v  glave 7. F.  Dzh.
Korbato  iz MTI otmechaet, chto v dlitel'nom proekte sleduet ozhidat' ezhegodnoj
smeny 20%  sotrudnikov,  i  novye rabotniki dolzhny  kak poluchit' tehnicheskuyu
podgotovku, tak i vlit'sya v formal'nuyu strukturu.
     2. CH. Portman  iz International  Computers Limited  govorit:  "Esli vse
rabotaet i ob®edineno v sistemu, znachit,  ostalos' raboty na chetyre mesyaca".
Nekotorye drugie sposoby raspredeleniya grafika privedeny v stat'e: Wolverton
R.  W. The  cost  of developing  large-scale  software  //  IEEE  Trans.  on
Computers. 1974. Vol. C-23, N 6. June. P. 615-636.
     3.  Risunkami 2.5-2.8  ya  obyazan  Dzherri Ogdinu,  kotoryj, citiruya  moj
primer  iz  bolee  rannej  publikacii   etoj   glavy,  znachitel'no   uluchshil
illyustracii. Ogdin, J.  L. The  Mongolian  hordes versus superprogrammer  //
Infosystems. 1972. Dec. P. 20-23.
     Glava 3
     1. Sackman H., Erikson W. J., Grant E. E. Exploratory  experimentation
studies comparing  online and offline programming performance // CACM. 1968.
Vol. 11, N 1. Jan. P. 3-11.
     2.  Mills H. Chief  programmer team,  principles, and procedures // IBM
Federal Systems Division Report FSC 71-5108. Gaithersburg, Md., 1971.
     3.  Baker  F.  T.  Chief  programmer  team   management  of  production
programming // IBM Sys. J. 1972. Vol. 11, N 1.
     Glava 4
     1.  Eschapasse M.  Reims Cathedral,  Caisse  Nationale  des Monuments
Histiriques. Paris, 1967.
     2. Brooks F. P. Architectural Philosophy // Buchholz W. (Ed.). Planning
a Computer System. New York: McGraw-Hill, 1962.
     3. Blaauw G. A.  Hardware  requirements  for  the  fourth generation //
Gruenberger F. (ed.). Fourth Generation Computers. Englewood Cliffs, N.  J.:
Prentice-Hall, 1970.
     4. Brooks F.  P.,  Iverson  K. E. Automatic Data Processing, System/360
Edition. New York: Wiley, 1969. Ch. 5.
     5. Glegg G. L. The Design of Design. Cambridge : Cambridge Univ. Press,
1969: "Na  pervyj  vzglyad  kazhetsya,  chto  mysl' o  tom,  chtoby  nalozhit'  na
tvorcheskij um kakie-to pravila ili principy, skoree pomeshaet emu, chem okazhet
pomoshch', no na praktike  eto sovershenno  neverno. Disciplinirovannoe myshlenie
skoree koncentriruet vdohnovenie, chem podavlyaet ego".
     6.  Conway  R. W. The  PL/C  Compiler  //  Proceedings  of  a Conf.  on
Definition and Implementation of Universal Programming Languages. Stuttgard,
1970.
     7.  Horoshee  obsuzhdenie  neobhodimosti  programmnyh   tehnologij   sm.:
Reynolds C. H. Whats wrong with computer programming management? // Weinwurm
G.  F.  (Ed.).  On the  Management of Computer Programming.  Philadelphia  :
Auerbach, 1971. P. 35-42.
     Glava 5
     1. Strachey C.  Review of Planning a Computer System // Comp. J. 1962.
Vol. 5, N 2. July. P. 152-153.
     2. |to  otnositsya  tol'ko k upravlyayushchim programmam.  Nekotorye brigady,
razrabatyvayushchie kompilyatory dlya  proekta OS/360,  sozdavali uzhe  svoj tretij
ili chetvertyj produkt, i otlichnoe kachestvo ih produktov eto podtverzhdaet.
     3. Shell D. L. The Share 709 system: a cooperative effort; Greenwald I.
D., Kane M. The Share 709 system: programming and modification; Boehm E. M.,
Steel T.  B., Jr. The Share 709 system: machine  implementation  of symbolic
programming. Vse stat'i // JACM. 1959. Vol. 6, N 2. Apr. P. 123-140.
     Glava 6
     1. Neustadt R. E. Presidential Power. New York: Wiley, 1960. Ch. 2.
     2.  Backus J. W. The syntax and semantics of the proposed international
algebraic language  // Proc.  Intl.  Conf. Inf. Proc. UNESCO, Paris, 1959 //
Oldenbourg R., Munich  and  Butterworth. (Eds.).  London. Krome  togo, celaya
podborka statej na  etu  temu soderzhitsya v: Steel T.  B.,  Jr. (Ed.). Formal
Language Description Languages for Computer  Programming.  Amsterdam:  North
Holland, 1966.
     3. Lucas P., Walk K. On the formal description of PL/I // Annual Review
in Automatic Programming Language. New York: Wiley, 1962. Ch. 2. P. 2.
     4. Iverson K. E. A Programming Language. New York: Wiley, 1962. Ch. 2.
     5. Falkoff A. D.,  Iverson K. E., Sussenguth E. H. A formal description
of System/360 // IBM Systems Journal. 1964. Vol. 3, N 3. P. 198-261.
     6. Bell  C.  G., Newell A. Computer Structures. New  York: McGraw-Hill,
1970. P. 120- 136, 517-541.
     7. Bell C. G. CHastnoe soobshchenie.
     Glava 7
     1.   Parnas  D.  L.   Information  distribution  aspects  of  design
methodology. Carnegie-  Mellon Univ.,  Dept.  Of Computer  Science Technical
Report. 1971. February.
     2.  Copyright  1939,  1940 Street  &  Smith Publications; Copyright
1950,  1967  Roberta  A.  Hajnlajna (Robert  A.  Heinlein).  Publikuetsya  po
soglasheniyu s Spectrum Literary Agency.
     Glava 8
     1. Sackman  H., Erikson W. J., Grant E. E. Exploratory experimentation
studies comparing online and offline programming performance //  CACM. 1968.
Vol. 11, N 1. Jan. P. 3-11.
     2. Nanus B., Farr L. Some cost contributors to  large-scale programs //
AFIPS Proc. SJCC. Spring 1964. Vol. 25. P. 239-248.
     3. Weinwurm G. F. Research in the management of computer programming //
Report SP-2059, System Development Corp. Santa Monica, 1965.
     4.  Morin  L.  H. Estimation  of  resources  for  computer  programming
projects // M. S. thesis. Chapel Hill: Univ. Of North Carolina, 1974.
     5. Portman C. CHastnoe soobshchenie.
     6.  V  neopublikovannom issledovanii  1964 goda, kotoroe  provel E.  F.
Bardain,  pokazano,  chto  programmisty  produktivno ispol'zuyut 27%  rabochego
vremeni.  (Procitirovano v: Mayer  D.  B.,  Stalnaker  A.  W. Selection  and
evaluation of computer personnel // Proc. 23d ACM Conf., 1968. P. 661.)
     7. Aron J. CHastnoe soobshchenie.
     8. Doklad, sdelannyj na soveshchanii i vklyuchennyj v AFIPS Proceedings.
     9. Wolverton  R. W. The cost of developing large-scale software // IEEE
Trans. On Computers. 1974. Vol. C-23, N 6. June. P. 615-636. V etoj nedavnej
vazhnoj stat'e  soderzhatsya  dannye po mnogim  voprosam,  obsuzhdaemym  v  etoj
glave, takzhe podtverzhdayushchie vyvody o proizvoditel'nosti truda.
     10. Corbato F. J. Sensitive issues in  the design  of multi-use systems
//  Lekciya  na otkrytii Tehnologicheskogo centra elektronnoj obrabotki dannyh
kompanii Honeywell, 1968.
     11. W. M. Taliaffero takzhe soobshchaet o postoyannoj proivoditel'nosti 2400
operatorov v  god na assmblere, Fortran i Cobol. Sm.: Modularity. The key to
system growth potential // Software. 1971. Vol. 1, N 3. July. P. 245-257.
     12. V  otchete  Report TM-3225,  Management  Handbook for Estimation  of
Computer  Programming  Costs  (Nelson  E.  A. iz  System  Development Corp.)
govoritsya o roste  proizvoditel'nosti  3:1 pri ispol'zovanii  yazyka vysokogo
urovnya (str. 66-67), hotya dispersiya vysoka.
     Glava 9
     1. Brooks  F.  P., Iverson K. E. Automatic Data Processing, System/360
Edition. New York: Wiley, 1969. Ch. 6.
     2. Knuth D.  E. The  Art  of Computer  Programming. Vols. 1-3. Reading,
Mass.: Addison-Wesley, 1968. ff.
     Glava 10
     1.  Conway M. E.  How do committees invent?  // Datamation. 1968. Vol.
14, N 4. Apr. P. 28-31.
     Glava 11
     1. Rech' v Ogletorpskom universitete 22 maya 1932 goda.
     2. Pouchitel'nyj otchet ob opyte ispol'zovaniya  MULTICS dlya sozdaniya dvuh
sistem imeetsya v: Corbaty F. J., Saltzer J.  H., Clingen C. T. MULTICS - the
first seven years // AFIPS Proc SJCC. 1972. Vol. 40. P. 571-583.
     3. Cosgrove J.  Needed: a new  planning  framework // Datamation. 1971.
Vol. 17, N 23. Dec. P. 37-39.
     4.  Izmenenie  proekta -  slozhnaya  problema,  i  zdes' ya  ee  chrezmerno
uproshchayu. Sm.: Saltzer J. H. Evolutionary design of complex systems // Eckman
D. (Ed.). Systems  :  Research and Design. New York : Wiley, 1961.  Vse  zhe,
kogda vse skazano  i sdelano,  ya  sovetuyu sozdat' opytnuyu  sistemu,  kotoruyu
planiruetsya vybrosit'.
     5.  Campbell  E. Report to the AEC Computer Information Meeting.  1970.
Dec.  |to  yavlenie  obsuzhdaetsya  takzhe  v:  Ordin J.  L. Designing  reliable
software //  Datamation.  1972.  Vol. 18, N 7.  July. P.  71-78. Mneniya moih
opytnyh  znakomyh  delyatsya  primerno  na  ravnye  chasti  v  otnoshenii  togo,
opuskaetsya li krivaya v konce.
     6. Lehman M., Belady L.  Programming systems dynamics.  Predstavleno na
ACM SIGOPS Third Symposium on Operating Systems Principles v oktyabre 1971 g.
     7. Lewis C. S. Mere Christianity. New York : Macmillan, 1960. P. 54.
     Glava 12
     1. Sm.  takzhe:  Pomeroy  J.  W.  A  guide  to  programming  tools  and
techniques // IBM Sys. J. 1972. Vol. 11, N 3. P. 234-254. 166
     2. Landy B., Needham R. M. Software engineering techniques used  in the
development of the Cambridge Multiple-Access System // Software.  1971. Vol.
1, N 2. Apr. P. 167-173.
     3. Corbato F. J. PL/I as a tool  for system  programming // Datamation.
1969. Vol. 15, N 5. May. P. 68-76.
     4. Hopkins M. Problems of PL/I for  system  programming // IBM Research
Report RC 3489. 1971, August 5. Yorktown Heights, N. Y.
     5.  Corbato  F. J.,  Saltzer J. H.,  Clingen  C. T. MULTICS - the first
seven years  //  AFIPS  Proc SJCC. 1972.  Vol. 40.  P.  571-582. "Lish' okolo
poludyuzhiny kuskov, napisannyh  na PL/I, byli pereprogrammirovany na mashinnom
yazyke, chtoby vyzhat' maksimal'nuyu skorost'. Neskol'ko programm, pervonachal'no
napisannyh na mashinnom yazyke, byli  perepisany  na PL/I, chtoby  oblegchit' ih
soprovozhdenie."
     6. Citiruyu stat'yu Korbato (ssylka 3 nastoyashchej glavy): "PL/I uzhe est',
a  al'ternativy  poka ne  provereny".  Odnako  sovershenno  protivopolozhnyj i
obosnovannyj vzglyad predstavlen v Henricksen J. O., Merwin R. E. Programming
language efficiency in real-time software systems //  AFIPS Proc SJCC. 1972.
Vol. 40. P. 155-161.
     7. Ne vse  s etim soglasny. Garlan Millz otmechaet  v chastnom soobshchenii:
"Opyt nachinaet  podskazyvat'  mne, chto  v  promyshlennom programmirovanii  za
terminal nuzhno posadit'  sekretarya.  Programmirovanie  sleduet sdelat' bolee
obshchestvennym  zanyatiem  pri  obshchem  rassmotrenii uchastnikov  komandy,  a  ne
chastnym zanyatiem".
     8. Yarr J. Programming Experience for the Number 1 Electronic Switching
System. Doklad na SJCC 1969 g.
     Glava 13
     1. Vyssotsky V. A. Common sense in designing testable software. Lekciya
na simpoziume po  metodam otladki komp'yuternyh programm, Chapel Hill, N. C.,
1972. Bol'shaya  chast' lekcii  soderzhitsya v  Hetzel W. C.  (Ed.). Program Test
Methods. Englewood Cliffs, N. J. : Prentice-Hall, 1972. P. 41-47.
     2. Wirth N. Program development by stepwise refinement  // CACM.  1971.
Vol. 14,  N 4.  Apr. P. 221-227. Sm. takzhe: Mills H. Top-down programming in
large  systems //  Rustin R. (Ed.). Debugging Techniques  in  Large Systems.
Englewood Cliffs, N.  J. : Prentice-Hall, 1971. P. 41-55; Baker F. T. System
quality through structured programming // AFIPS Proc FJCC.  1972. Vol. 41-I.
P. 339-343.
     3. Dahl O.  J., Dijkstra E. W., Hoare C. A. R. Structured  programming.
London ; New  York : Academic Press, 1972. V etoj knige soderzhitsya  naibolee
polnoe izlozhenie. Sm. takzhe osnovopolagayushchee pis'mo Dejkstry: GOTO statement
considered harmful // CACM. 1968. Vol. 11, N 3. March. P. 147-148.
     4. Bohm C., Jacopini  A. Flow diagrams, Turing machines,  and languages
with only two formation rules // CACM. 1966. Vol. 9, N 5. May. P. 366-371.
     5. Codd E. F., Lowry E. S., McDonough E., Scalzi C. A. Multiprogramming
STRETCH: Feasibility considerations  //  CACM. 1959. Vol. 2, N  11.  Nov. P.
13-17.
     6. Strachey C. Time sharing in large fast computers // Proc. Int. Conf.
On Info.  Processing. 1959,  June. UNESCO. P.  336-341. Sm. takzhe  zamechaniya
Kodda  na  str. 341, gde on soobshchaet o hode raboty, podobnoj  predlozhennoj v
stat'e Strejchi.
     7.  Corbato  F.  J., Merwin-Daggett M.,  Daley  R. C.  An  experimental
time-sharing   system  //  AFIPS  Proc  SJCC.  1962.  Vol.  2.  P.  335-344.
Perepechatano  v:  Rosen S. Programming Systems and  Languages.  New  York  :
McGraw-Hill, 1967. P. 683- 698.
     8. Gold M. M. A methodology for  evaluating time-shared computer system
usage. Ph. D. dissertation. Carngie-Mellon University, 1967. P. 100.
     9. Gruenberger F. Program  testing  and validating // Datamation. 1968.
Vol. 14, N 7. July. P. 39-47.
     10. Ralston A. Introduction  to  Programming and Computer Science.  New
York : McGraw-Hill, 1971. P. 237-244.
     11.  Brooks  F. P., Iverson K. E. Automatic Data Processing, System/360
Edition. New York : Wiley, 1969, P. 296-299.
     12.  Problemy razrabotki  specifikacij, sozdaniya i  testirovaniya sistem
horosho izlozheny Trapnelom F.  M. v:  Trapnell F. M. A systematic approach to
the  development of  system programs  // AFIPS Proc SJCC. 1969. Vol.  34. P.
411-418.
     13. Dlya  sistemy  real'nogo vremeni potrebuetsya model' okruzheniya.  Sm.,
naprimer: Ginzberg M. G. Notes on  testing  real-time system programs // IBM
Sys. J. 1965. Vol. 4, N 1. P. 58-72.
     14.  Lehman M., Belady  L. Programming systems dynamics. Predstavleno v
oktyabre  1971  g.  na  ACM  SIGOPS  Third  Symposium  on  Operating  Systems
Priciples.
     Glava 14
     1.  Sm.:  Reynolds  C.  H.  Whats  wrong  with  computer  programming
management?  //  Weinwurm  G.  F.  (Ed.).  On  the  Management  of  Computer
Programming. Philadelphia : Auerbach, 1971. P. 35-42.
     2. King W. R., Wilson T. A. Subjective time estimates in  critical path
planning - a preliminary analysis //  Mgt. Sci. 1967. Vol.  13, N 5. Jan. P.
307-320;  King  W. R.,  Witterrongel  M.,  Hezel  K.  D.  On the analysis of
critical path  time estimating  behavior //  Mgt. Sci.  1967. Vol. 14, N  1.
Sept. P. 79-84.
     3. Bolee podrobnoe obsuzhdenie sm. Brooks F. P., Iverson K. E. Automatic
Data Processing, System/360 Edition. New York : Wiley, 1969. P. 428-230.
     4. CHastnoe soobshchenie.
     Glava 15
     1. Goldsteine H. H., Neumann J. von.  Planning and coding problems for
en electronic computing instrument.  Part II. Vol.  1. Otchet, podgotovlennyj
dlya U.S. Army Ordinance Department,  1947. Perepechatano v: Neumann  J.  von.
Collected Works  //  Taub A.  H.  (Ed.).  Vol. V. New  York : Macmillan.  P.
80-151.
     2. CHastnoe soobshchenie,  1957. Dokazatel'stvo opublikovano  v: Iverson K.
E. The use of APL in Teaching. Yorktown, N.Y. : IBM Corp., 1969.
     3. Drugoj spisok priemov dlya PL/I opublikovan v: Walter A.  B., Bohl M.
From  better to best - tips for good programming // Software Age. 1969. Vol.
3, N 11. Nov. P. 46-50.
     |ti  zhe priemy mozhno ispol'zovat' v Algol i dazhe Fortran. U D. E. Langa
iz  universiteta  shtata   Kolorado  est'  napisannaya  na  Fortran  programma
formatirovaniya pod nazvaniem  STYLE, s pomoshch'yu  kotoroj mozhno poluchit' takoj
rezul'tat.  Sm. takzhe: McCracken  D.  D.,  Weinberg G.  M. How  to  write  a
readable FORTRAN program // Datamation. 1972. Vol. 18, N 10. Oct. P 73-77.
     Glava 16
     1.  Ocherk,  ozaglavlennyj "No Silver  Bullet", vzyat  iz:  Information
Processing  1986,  the  Proceedings  of   the  IFIP  Tenth  World  Computing
Conference pod redakciej H.-J. Kuglera, 1986, str. 1069-1076. Perepechatano s
lyubeznogo razresheniya IFIP i Elsevier Science B. V., Amsterdam, Niderlandy.
     2.  Parnas  D.   L.  Designing  software  for  ease  of  extension  and
contraction // IEEE Trans on SE. 1979. Vol. 5, N 2. March. P. 128-138.
     3.  Booch G.  Object-oriented design //  Software Engineering with Ada.
Menlo Park, Calif. : Benjamin/Cummings, 1983.
     4. Special Issue on Artificial Intelligence and Software Engineering //
Mostow J. (Ed.). IEEE Trans. on SE. 1985. Vol. 11, N 11. Nov.
     5.  Parnas  D.  L.  Software  aspects of  strategic defense  systems //
Communications  of  the  ACM. 1985. Vol. 28, N 12.  Dec.  P.  1326-1335. Sm.
takzhe: American Scientist. 1985. Vol. 73, N 5. Sept.-Oct. P. 432-440.
     6.  Balzer R. A 15-year perspective  on automatic programming v Mostow,
cit. soch.
     7. Mostow, sm. primechanie 4.
     8. Parnas, 1985, sm. primechanie 5.
     9.  Raeder G.  A  survey of current graphical programming techniques //
Grafton  R. B., Ichikawa  T.  (Eds.). Special Issue on Visual Programming //
Computer. 1985. Vol. 18, N 8. Aug. P. 11-25.
     10. Tema obsuzhdaetsya v glave 15 nastoyashchej knigi.
     11. Mills  H. Top-down programming in large systems // Rustin R. (Ed.).
Debugging  Techniques   in  Large  Systems.   Englewood   Cliffs,  N.  J.  :
Prentice-Hall, 1971.
     12. Boehm B. W. A spiral model of software development  and enhancement
// Computer. 1985. Vol. 20, N 5. May, P. 43-57.
     Glava 17
     Material, citiruemyj bez ssylki, vzyat iz chastnyh soobshchenij.
     1. Brooks F. P.  No silver bullet -  essence and  accidents of software
engineering //  Kugler H. J.  (Ed.).  Information Processing 86. Amsterdam :
Elsevier Science, North Holland, 1986. P. 1069-1076.
     2. Brooks F.  P. No silver bullet - essence  and accidents  of software
engineering // Computer. 1987. Vol. 20, N 4. Apr. P. 10-19.
     3.  Neskol'ko pisem  v  otvet poyavilis'  v  iyul'skom  1987 goda vypuske
"Computer".
     Osobenno priyatno zametit', chto v to vremya kak "SPN" ne poluchila nagrad,
Bryus  M. Skvirski  (Bruce  M. Skwiersky)  poluchil  nagradu za  luchshij obzor,
opublikovannyj v "Computer Reviews" v 1988 godu. V redakcionnoj stat'e E. A.
Vajsa v "Computer Reviews" (iyun', 1988)  na s. 283-284 ob®yavlyaetsya o nagrade
i perepechatyvaetsya obzor Skvirski. V obzore est' sushchestvennaya oshibka: vmesto
"shestikratno" dolzhno byt' "106".
     4.  "Po Aristotelyu i filosofii sholastikov,  akcidenciya  est' kachestvo,
kotoroe prinadlezhit  veshchi ne blagodarya ee vazhnoj ili sushchestvennoj prirode, a
voznikaet  v  nej  v  rezul'tate   dejstviya  inyh   prichin".   Websters  New
International Dictionary of the English Language, 2d ed., Springfield, Mass.
: G. C. Merriam, 1960.
     5. Sayers  D. L. The Mind of  the Market. New  York : Harcourt,  Brace,
1941.
     6. Glass  R. L., Conger S. A. Research software talks : Intellectual or
clerical? // Information or Management. 1992. Vol. 23, N 4. Avtory soobshchayut,
chto  razrabotka tehnicheskih  trebovanij k programmnomu  obespecheniyu  na  80%
intellektual'naya i na 20% -  kancelyarskaya rabota. Fjelstadt i  Hamlen (1979)
poluchili fakticheski  takie zhe  rezul'taty dlya podderzhki prikladnyh programm.
Mne neizvestny popytki izmenit' etu dolyu dlya vsej zadachi ot nachala do konca.
     7. Herzberg F., Mausner B., Sayderman B. B. The Motivation to Work. 2nd
ed. London : Wiley, 1959.
     8.  Cox B. J. There is a  silver bullet // Byte. 1990. Oct. P. 209-218.
169
     9. Harel D. Biting  the silver bullet :  Toward  a brighter future  for
system development // Computer. 1992. Jan. P. 8-20.
     10.  Parnas  D.  L.  Software aspects of strategic  defense  systems //
Communication of the ACM. 1985. Vol. 28, N 12. Dec. P. 1326-1335.
     11.  Turski  W. M. And no philosophers  stone, either  //  Kugler H. J.
(Ed.).  Information  Processing  86.  Amsterdam  : Elsevier  Science,  North
Holland, 1986. P. 1077-1080.
     12. Glass R. L., Conger S. A. Research software tasks : Intellectual or
clerical? // Information and Management, 1992. Vol. 23, N 4. P. 183-192.
     13.  Review  of Electronic Digital  Computers,  Proceedings  of a Joint
AIEEIRE Computer Conference (Philadelphia,  Dec.  10-12,  1951). New  York :
American Institute of Electrical Engineers. P. 13-20.
     14. Ibid. Pp. 36, 68, 71, 97.
     15. Proceedings of the Eastern Joint  Computer  Conference (Washington,
Dec. 8-10, 1953). New York : Institute of Electrical Engineers. P. 45-47.
     16.  Proceedings  of  the 1955 Western Joint Computer  Conference  (Los
Angeles, March 1-3, 1955). New York : Institute of Electrical Engineers.
     17. Everett  R. R.,  Zraket  C. A.,  Bennington  H.  D. SAGE -  a  data
processing system  for  air  defense  //  Proceedings  of the  Eastern Joint
Computer Conference  (Washington, Dec. 11-13, 1957). New York : Institute of
Electrical Engineers.
     18. Harel D., Lachover H., Haamad A., Pnueli A., Politi M., Sherman R.,
Shtul-Traurig A. Statemate:  A working  environment for  the development  of
complex reactive systems  // IEEE Trans.  on SE. 1990.  Vol.  16,  N  4.  P.
403-444.
     19.  Jones  C.  Assessment  and  Control of  Software  Risks. Engltwood
Cliffs, N. J. : Prentice-Hall, 1994. P. 619.
     20. Coqui H.  Corporate survival : The software  dimension.  Focus  89,
Cannes, 1989.
     21. Coggins J. M. Designing C++ libraries // C++ Journal. 1990. Vol. 1,
N 1. June. P. 25-32.
     22.  V   budushchem  vremeni.  Mne   neizvestny  kakie-libo  soobshcheniya   o
rezul'tatah pyatogo ispol'zovaniya.
     23. Jones, sm. primech. 19. P. 604.
     24. Huang Weigiao.  Industrializing software production //  Proceedings
ACM  1988 Computer  Science Conference. 1988. Atlanta. Boyus', chto pri  takoj
organizacii budet nedostatochnyj lichnyj professional'nyj rost.
     25. Ves' sentyabr'skij 1994 goda nomer IEEE Software posvyashchen povtornomu
ispol'zovaniyu.
     26. Jones, sm. primech. 19. P. 323.
     27. Jones, sm. primech. 19. P. 329.
     28.  Yourdon E. Decline  and Fall of the American Programmer. Englewood
Cliffs, N. J. : Yourdon Press, 1992. P. 221.
     29.  Glass R. L.  Glass (kolonka) // System Development. 1988. Jan.  P.
4-5.
     Glava 18
     1. Boehm B. W. Software Engineering Economics. Englewood Cliffs, N. J.
: Prentice- Hall, 1981. P. 81-84.
     2.  McCarthy J.  21  Rules  for Delivering Great  Software  on Time  //
Software World USA Conference, Washington (Sept. 1994).
     Glava 19
     Material, citiruemyj bez ssylki, vzyat iz chastnyh soobshchenij.
     1. Po etoj boleznennoj teme sm.  takzhe:  Niklaus Wirth. A plea for lean
software // Computer. 1995. Vol. 28, N 2. Feb. P. 64-68.
     2. Coleman D. Word 6.0 packs  in features; update slowed by baggage  //
MacWeek. 1994. Vol. 8, N 38. Sept. 26. P. 1.
     3. Opublikovano mnogo obzorov chastotnyh harakteristik komand  mashinnogo
yazyka  i  yazyka  programmirovaniya,  sdelannyh posle vypuska. Sm.,  naprimer:
Hennessy J., Patterson D. Computer Architecture.  |ti chastotnye dannye ochen'
polezny  dlya sozdaniya  posleduyushchih  produktov, hotya  nikogda  v tochnosti  ne
primenimy.  Mne  neizvestny  publikacii  ocenok,  poluchennyh  do  razrabotki
produkta,  a tem  bolee -  sravnenij apriornyh dannyh  s aposteriornymi. Ken
Bruks polagaet,  chto  doski  ob®yavlenij  v  Internete  predostavlyayut  teper'
deshevyj  sposob  zaprosit'  dannye  u  predpolagaemyh  pol'zovatelej  novogo
produkta, dazhe nesmotrya na to chto otvechayut tol'ko zhelayushchie.
     4. Conklin J.,  Begeman M. gIBIS : A  hypertext  Tool  for  Exploratory
Policy Descussion // ACM Transactions  on  Office Information Systems. 1988.
Oct. P. 303-331.
     5. Englebart  D., English  W. A research  center  for  augmenting human
intellect  // AFIPS Conference  Proceedings, Fall Joint Computer Conference.
San Francisco (Dec. 9-11, 1968). P. 395-410.
     6. Apple  Computer, Inc. Macintosh Human Interface Guidelines. Reading,
Mass. : Addison-Wesley, 1992.
     7. Kazhetsya, shina Apple Desk Top Bus mogla by apparatno podderzhivat' dve
myshi, no operacionnaya sistema takoj vozmozhnosti ne predostavlyaet.
     8. Royce  W. W.  Managing the  development  of large  software systems:
Concepts and techniques  // Proceedings, WESCON (Aug., 1970). Perepechatano v
ICSE  9  Proceedings.  Ni  Rojs, ni drugie ne  schitali, chto mozhno  zavershit'
process  razrabotki, ne  peresmatrivaya  nachal'nyh  dokumentov.  Model'  byla
predlozhena  v  kachestve  ideal'noj.  Sm.: Parnas D.  L.,  Clements  P.  C. A
rational design process :  How and why to  fake it  // IEEE  Transactions on
Software Engineering. 1986. Vol. SE-12, N 2. Feb. P. 251-257.
     9. V rezul'tate znachitel'noj pererabotki DOD-STD-2167 poyavilsya DOD-STD-
2167A  (1988),  kotoryj dopuskaet  novye modeli, naprimer  spiral'nuyu, no ne
obyazyvaet bolee k ih primeneniyu. K sozhaleniyu, MILSPECS, na kotoryj ssylaetsya
2167A, i  privedennye  v  kachestve  illyustracii primery  po-  prezhnemu,  kak
soobshchaet Bem, ispol'zuyut kaskadnuyu shemu. Special'naya gruppa nauchnogo soveta
po oborone  pod rukovodstvom Larri  Druffela  i Dzhordzha Hejlmejera  v otchete
1994 goda  "Report of  the  DSB  task force on  acquiring  defense  software
commercially" rekomendovala povsemestnoe ispol'zovanie novyh modelej.
     10. Mills H. Top-down programming in large systems // Rustin R.  (Ed.).
Debugging   Techniques   in  Large  Systems.  Englewood  Cliffs,  N.   J.  :
Prentice-Hall, 1971.
     11. Parnas D. L. On the design and development of program  families  //
IEEE Trans. on  Software Engineering. 1976. Vol.  SE-2, N 1. March, P.  1-9;
Parnas D. L.  Designing software for ease of  extension and  construction //
IEEE  Trans. on  Software  Engineering.  1979.  Vol. SE-5,  N  2. March.  P.
128-138.
     12. Harel D. Biting the silver bullet // Computer. 1992. Jan. P. 8-20.
     13.  Sleduyushchie  stat'i  yavlyayutsya  osnovopolagayushchimi  v voprose  skrytiya
dannyh: Parnas  D. L. Information distribution aspects of design methodology
// Carnegie- Mellon Univ., Dept. Of Computer Science Technical Report. 1971.
Feb.;  Parnas  D.  L.  A  technique  for software module specification  with
examples //  Comm. ACM. 1972.  Vol. 5,  N 5. May. P.  330-336; Parnas D.  L.
(1972). On the  criteria to be used in decomprosing  systems into modules //
Comm. ACM. 1972. Vol. 5, N 12. Dec. P. 1053-1058.
     14. Ideyu ob®ektov pervonachal'no nabrosali Hoare i Dijkstra, no pervoe i
naibolee vazhnoe razvitie oni poluchili v yazyke Simula-67, kotoryj razrabotali
Dahl i Nygaard.
     15. Boehm B. W. Software Engineering Economics. Englewood Cliffs, N. J.
: Prentice- Hall, 1981. P. 83-94; 470-472.
     16.  Abdel-Hamid  T.,  Madnick  S.  Software   Project  Dynamics  :  An
Integrated Approach. Ch.  19 // Model enhancement and Brookss law. Englewood
Cliffs, N. J. : Prentice- Hall, 1991.
     17.  Stutzke  R. D. A mathematical  expression of  Brookss Law // Ninth
International Forum on COCOMO and Cost Modeling. Los Angeles, 1994.
     18.  DeMarco T., Lister T. Peopleware  : Productive Projects and Teams.
New York : Dorset House, 1987.
     19.  Pius XI.  Encyclical  Quadragesimo  Anno //  Ihm,  Claudia Carlen.
(Ed.). The Papal Encyclicals 1903-1939. Raleigh, N. C. : McGrath. P. 428.
     20. Schumacher E.  F.  Small Is  Beautiful  : Economics  as  if  People
Mattered. Perennian Library Edition.  New  York :  Harper and  Row, 1973. P.
244.
     21. Schumacher, sm. primech. 20. P. 34.
     22.  Navodyashchij  na  mysli  nastennyj  plakat  glasit:  "Svoboda  pechati
prinadlezhit tomu, u kogo on [komp'yuter] est'". 23. Bush V. That we may think
// Atlantic Monthly. 1945. Vol. 176, N 1. Apr. P. 101- 108.
     24.  Ken  Tompson iz  Bell Labs, sozdatel'  Unix,  davno ponyal znachenie
bol'shogo  ekrana  dlya  programmista.  On  pridumal, kak na svoyu  primitivnuyu
elektronnuyu trubku Tektronix  vyvodit' 120  strochek teksta v dve kolonki. On
derzhalsya za  svoj terminal, poka smenilos' celoe pokolenie  bystryh trubok s
malen'kim ekranom.


Last-modified: Sat, 10 Aug 2002 16:33:38 GMT

Ocenite etot tekst: