Brooks omul mitic al lunii pdf. Luna mitică a omului sau cum sunt create sistemele software. Termeni introduși în carte

Cartea lui Frederick Brooks Omul-lună mitică, sau Cum sunt create sisteme software„este o carte de citit obligatoriu pentru fiecare programator. A fost publicat în 1975, dar nu și-a pierdut deloc relevanța.

Am dat peste această carte la momentul potrivit. Tocmai am absolvit facultatea și am început să lucrez ca programator. A fost foarte greu la început. Pe atunci erau puține cărți despre IT. Am citit această carte în bibliotecă, era destul de ponosită. Și am fost uimit de câtă valoare conține. Sfaturile lui Brooks m-au ajutat foarte mult la începutul carierei mele. Și această carte a fost deosebit de utilă atunci când am început să gestionez eu însumi programatorii.

Fredericks Brooks a lucrat la IBM și a condus creația sistem de operare Sistem/360. La acea vreme, era cel mai mare proiect de software din lume. În timpul lucrărilor, au apărut dificultăți neașteptate. Brooks era un om observator și era capabil să înțeleagă natura acestor dificultăți. El a fost capabil să formuleze principiile de bază ale dezvoltării software care disting programarea de alte ramuri de producție.

Care sunt aceste principii?

Concluzia principală, pe care a numit-o legea lui Brooks, spune:

Dacă un proiect de programare este în întârziere, adăugarea mai multor forțe de muncă nu va face decât să întârzie finalizarea acestuia.

Această lege este de obicei ilustrată astfel: „Chiar dacă adunați nouă femei, acestea nu vor putea naște un copil într-o lună.”

De aici și titlul cărții. În alte industrii, creșterea numărului de lucrători permite o muncă mai rapidă. Zece excavatoare lucrează mai repede decât cinci. Dar zece programatori, destul de ciudat, vor lucra mai lent decât cinci.

Metoda Wirth

Potrivit lui Brooks cea mai buna metoda Dezvoltarea software este metoda lui Niklaus Wirth, autorul limbajului Pascal.

Potrivit lui Wirth, designul este considerat ca o secvență de pași care rafinează proiectul. În primul rând, enunțul problemei este schițat aproximativ și se face o propunere metoda bruta soluțiile sale, permițându-ne să obținem un răspuns fundamental. În continuare, descrierea este întocmită mai detaliat, ceea ce vă permite să vedeți că rezultatul diferă de cel dorit. Etapele mari ale soluției sunt împărțite în altele mai mici.

Această metodă de dezvoltare a programelor am adoptat-o ​​și de mulți ani m-a ajutat să scriu programe mai eficient.

Această metodă are o altă caracteristică utilă. Puteți schița rapid un aspect al unui program de lucru și puteți vorbi cu clientul în detaliu. Pentru că clienții programului nu au absolut nicio idee ce se va întâmpla în cele din urmă. Pachet minim rezolvă această problemă.

OOP este o boală

În această carte, am citit mai întâi o opinie critică despre tehnologia de dezvoltare a software-ului orientată pe obiecte la modă.

În opinia mea, metodologiile orientate pe obiecte au un caz deosebit de rău al bolii care afectează multe îmbunătățiri metodologice. Există un cost inițial semnificativ - în principal pentru a-i învăța pe programatori să gândească în moduri complet noi și, de asemenea, pentru a converti funcțiile în clase generice.

A numi OOP o boală gravă era foarte îndrăzneț la acea vreme, dar mai târziu m-am convins în mod repetat de corectitudinea acestui diagnostic. Deoarece costurile programării în stilul OOP sunt de multe ori mai mari decât beneficiile minore.

Corecțiile distrug programul

Când un programator lansează un program, utilizatorii recunoscători încep imediat să ceară noi funcții. S-ar părea că asta e bine. Dar nu este atât de simplu. Oamenii au opinii foarte diferite asupra modului în care ar trebui să se dezvolte programul. Prin urmare, există toate șansele ca programul să se transforme rapid într-un monstru stângaci plin de erori.

Lehman și Beladi au studiat istoria lansărilor succesive ale unui sistem de operare mare. Ei consideră că numărul total de module crește liniar cu numărul versiunii, dar numărul modulelor afectate de modificări crește exponențial cu numărul versiunii. Toate corecțiile tind să distrugă structura, să crească entropia și să dezorganizeze sistemul. Se depune tot mai puțin efort pentru corectarea erorilor din proiectul original și tot mai mult efort se depune pentru eliminarea consecințelor corecțiilor anterioare.

Este mult mai bine să formulați clar cerințele pentru program și să le implementați. Așa că programul face un lucru, dar îl face bine.

Sunt departe de a crede că toate schimbările în scopurile și cerințele clientului pot sau ar trebui luate în considerare în proiect. Evident, trebuie să existe un prag stabilit care trebuie să crească din ce în ce mai sus pe măsură ce dezvoltarea progresează, altfel nu va fi creat vreodată niciun produs.

Productivitatea programatorului variază foarte mult

Prima dată când programatorii au esențial performanță diferită, am aflat din cartea lui Brooks. Nu am crezut atunci. Dar viața a confirmat pe deplin această situație.

Într-un studiu, Sackman, Erikson și Grant au măsurat productivitatea unui grup de programatori experimentați. Numai în cadrul acestui grup, raportul dintre cele mai bune și cele mai proaste rezultate a fost de aproximativ 10:1 pentru productivitatea muncii și 5:1 pentru viteza programelor și memoria necesară pentru acestea! Pe scurt, un programator care câștigă 20.000 USD pe an poate fi de zece ori mai productiv decât un programator care câștigă 10.000 USD.

Acest lucru a fost evident mai ales în exemplul studenților. Când am început să predau programarea la o universitate, am văzut teste că unii studenți citesc problema și scriu rapid codul terminat, în timp ce alții pot petrece câteva minute pentru a depana un program simplu.

Nu există nici un glonț de argint

Cea mai interesantă predicție a lui Brooks este că în viitorul apropiat nu vor exista tehnologii capabile să mărească viteza de dezvoltare cu un ordin de mărime. Au trecut mulți ani, iar predicția lui Brooks s-a adeverit complet. La fel ca acum patruzeci de ani, programatorii scriu programe manual. Nu există nicio tehnologie în care introduceți specificațiile tehnice ale clientului și scuipă codul final.

Desigur, toate ideile lui Brooks nu pot fi repovestite. Recomand sa o citesti pentru a nu calca pe multe greseli.

Nume: Mitica lună a omului sau modul în care sunt create sistemele software.

Această carte este o ediție aniversară (extinsă și corectată) a unui fel de biblie pentru dezvoltatori software peste tot în lume, scrisă de Brooks în 1975. În același timp, cartea a fost publicată în limba rusă și a devenit de multă vreme o raritate bibliografică. În Statele Unite, se crede că fără a citi cartea lui Brooks, nici un singur manager major al unui proiect software nu poate reuși. Dacă nu ați auzit niciodată de această carte, puteți căuta referințe la ea pe Internet (Frederick P. Brooks, The Mythical Man-Month). Totul va deveni clar pentru tine imediat.

Conţinut
Prefață la ediția din 1995
Prefață la prima ediție
Capitolul 1. Groapa de gudron
Capitolul 2. Această mitică „lună-om”
Capitolul 3. Echipa de operare
Capitolul 4. Aristocrație, democrație și ingineria sistemelor
Capitolul 5. Efectul celui de-al doilea sistem
Capitolul 6. Preda cuvântul
Capitolul 7. De ce nu a putut fi construit Turnul Babel?
Capitolul 8. Declararea loviturii
Capitolul 9. Doi într-unul
Capitolul 10. Ipoteza documentară
Capitolul 11: Planul de aruncat
Capitolul 12. Instrument ascuțit
Capitolul 13. Întreg și părți
Capitolul 14. Prepararea catastrofei
Capitolul 15. Cealaltă parte
Capitolul 16. Nu există niciun glonț de argint - esență și accident în inginerie software
Capitolul 17. Noua imagine „Nu există niciun glonț de argint”
Capitolul 18. Afirmații din „Luna-omul mitic”: adevărate sau false?
Capitolul 19. „Luna-omul mitic” douăzeci de ani mai târziu
Epilog
Note și referințe.

Atingerea integrității conceptuale.
Scopul unui sistem de programare este de a face calculatorul mai ușor de utilizat. În acest scop, sunt furnizate limbi și diverse mijloace, care sunt în esență programe numite și controlate de capacitățile limbajului. Dar aceste fonduri costă bani: volum descriere externă sistemele de programare sunt de zece până la douăzeci de ori mai mari decât descrierea reală sistem de calcul. Se dovedește a fi mult mai ușor pentru utilizator să specifice orice funcție selectată, dar alegerea este foarte mare și există mult mai multe opțiuni și formate de reținut.

Utilizarea este mai ușoară numai dacă timpul câștigat în specificarea funcției depășește timpul petrecut învățând, memorând și căutând manuale. Sisteme moderne programarea da un asemenea câștig, dar se pare că în ultimii ani raportul beneficiu-cost a scăzut ca urmare a adăugării din ce în ce mai mult funcții complexe. Îmi amintesc adesea cât de ușor a fost să folosești IBM 650, chiar și fără asamblare sau vreun program.

Descărcare gratuită e-carte V format convenabil, urmăriți și citiți:
Descarcă cartea Mythical Man - luna sau cum sunt create sistemele software - Brooks F. - fileskachat.com, descărcare rapidă și gratuită.

Descărcați pdf
Puteți cumpăra această carte mai jos cel mai bun pret la reducere cu livrare în toată Rusia.

Am recitit recent o carte care a devenit de mult un clasic. Luna mitică a omului sau cum sunt create sistemele software. Acum 25 de ani F. Brooks a descris principalul erori de creare sisteme informatice . Această lucrare este și astăzi relevantă. Mi-am notat punctele principale ale cărții pentru mine.

Principalele puncte ale cărții

Deoarece programatorul lucrează cu idei pure, nu ne așteptăm la multe dificultăți în implementare. Dar ideile noastre în sine pot fi eronate - de aici erorile din programe.

Proiectele software eșuează mai des din cauza lipsei de timp calendaristic decât din cauza tuturor celorlalte motive combinate. Metodele noastre de estimare bazate pe costuri combină costurile cu producția. Luna persoanei este o concepție greșită eronată și periculoasă, deoarece sugerează că lunile și numărul de oameni pot fi inversate. Împărțirea unei sarcini între mai multe persoane introduce costuri suplimentare pentru formare și schimb de informații. În plus, nu toate sarcinile pot fi împărțite. Trebuie să înțelegeți că 9 femei însărcinate nu vor da naștere unui copil într-o lună.

Legea lui Brooks: Dacă un proiect nu își respectă termenul limită, adăugarea mai multor forță de muncă îl va întârzia și mai mult. Adăugarea forței de muncă crește volum total costă în trei moduri: forța de muncă pentru a reproiecta sarcinile și întreruperea muncii care rezultă, formarea de oameni noi, comunicare suplimentară.

Echipa de proiect

Chiar și într-o echipă mare de proiectare, prezentarea rezultatelor ar trebui să fie atribuită uneia sau două persoane pentru a asigura consistența în mini-soluții.

Datele ICL ale lui Portman arată că programatorii cu normă întreagă își petrec doar aproximativ 50% din timp programând și depanând, restul timpului fiind ocupat de diverse sarcini suplimentare.

Fiecare proiect are două poziții de conducere: managerul de proiect și arhitectul ( director tehnic). Funcțiile lor sunt complet diferite și necesită abilități diferite. Orice tip de relație între aceste două poziții (inclusiv o persoană) poate fi destul de eficientă.

Este necesar ca atenția utilizatorului să fie atrasă în mod special asupra modificărilor care au avut loc de la ultima sa lectură, și cu note despre semnificația acestora.

Este important ca arhitectul convorbiri telefonice a răspuns la întrebările interpreților. Este imperativ ca aceste conversații să fie înregistrate într-un jurnal și puse la dispoziția publicului. În prezent, e-mailul este preferat în acest scop.

Reticența programatorilor de a documenta un proiect vine nu atât din lene, cât din incertitudinea dacă să se angajeze să apere deciziile despre care designerul le știe că sunt „preliminare”.

Arhitectura sistemului informatic

Un design detaliat și atent nu numai că face un produs mai ușor de utilizat, dar îl face și mai ușor de dezvoltat și mai puțin predispus la erori.

Integritatea conceptuală este cel mai important aspect la proiectarea sistemelor. Pentru a atinge integritatea conceptuală, un proiect trebuie să fie creat de o persoană sau de un grup de oameni cu gânduri similare.

Separarea arhitecturii de implementare este într-un mod eficient atingerea integrității conceptuale atunci când se lucrează la proiecte foarte mari.

Dacă vrei ca un sistem să aibă integritate conceptuală, cineva trebuie să preia conducerea conceptelor. Aceasta este aristocrația care nu are nevoie de scuze.

Pe parcursul implementării, arhitecții de sistem trebuie să rămână vigilenți în orice moment pentru a asigura integritatea sistemului în orice moment.

Suport sistem informatic

Produsul software este în pericol de a deveni învechit chiar înainte de a fi finalizat. Dacă sistemul nu este dezvoltat, devine învechit.

Toate corecțiile tind să distrugă structura, să crească entropia și să dezorganizeze sistemul. Chiar și cea mai pricepută întreținere a unui program întârzie doar în momentul în care acesta se cufundă într-o stare de haos ireparabil, a cărui cale de ieșire este reproiectarea lui de la bun început.

Uneori, o nevoie reală de a actualiza un program, de exemplu pentru a îmbunătăți performanța, necesită schimbarea limitelor interne ale structurilor. Adesea, granițele inițiale sunt cauza deficiențelor ulterioare.

Corectarea unei erori are o probabilitate mare (de la 20 la 50 la sută) de a introduce alta. (datorita faptului ca arhitectura se pierde in timpul intretinerii).

După fiecare corecție, trebuie să rulați întregul set de cazuri de testare față de care sistemul a fost testat înainte pentru a vă asigura că nu a fost deteriorat într-un mod necunoscut.

„Mitica lună a omului sau cum sunt create sistemele software”- o carte de Frederick Brooks despre managementul proiectelor în domeniul dezvoltării software, a cărei temă centrală a fost aceea că introducerea de noi forțe într-un proiect în stadiile târzii de dezvoltare nu face decât să amâne data de livrare a proiectului. Această idee a devenit cunoscută drept Legea lui Brooks. Cartea a fost publicată pentru prima dată în anul, apoi a fost publicată și în limba rusă. Cartea a fost relansată ca o ediție aniversară în 1995, împreună cu comentariile autorului și un nou eseu „There is no silver bullet”. În Rusia, a doua ediție a fost publicată de editura Symbol-Plus, ISBN 5-93286-005-7.

Observațiile lui Brooks se bazează pe experiența sa la IBM în timp ce gestiona proiectul sistemului de operare OS/360. Pentru a accelera dezvoltarea, s-a angajat încercare nereușită atrăgând Mai mult lucrători pentru un proiect ale cărui termene limită au fost deja ratate. Observând tendința managerilor de a repeta astfel de greșeli, Brooks și-a numit în batjocură cartea „biblia pentru inginerie software”: „toată lumea a citit-o, dar nimeni nu o urmează!”

Brooks a mai susținut că scrierea unui compilator Algol ar dura șase luni, indiferent de numărul de persoane implicate în proiect.

Idei cheie

Omul-lună mitică

Timpul de finalizare a proiectului nu este invers proporțional cu numărul de programatori, din cel puțin 2 motive.

1. În programare, spre deosebire de, de exemplu, culegerea bumbacului, munca nu poate fi împărțită în mod arbitrar în mai multe părți independente. Părți ale unui proiect depind unele de altele, iar unele sarcini pot începe doar după ce altele sunt finalizate.
2. Programatorii ar trebui să-și petreacă o parte din timp interacționând între ei.

Dacă există N programatori, atunci numărul de perechi de programatori este N(N-1)/2, adică pe măsură ce numărul de programatori crește, timpul petrecut pentru interacțiune crește pătratic. Prin urmare, pornind de la niște N, creșterea numărului de programatori încetinește implementarea proiectului.

Dacă termenele limită sunt ratate, angajarea de noi programatori încetinește proiectul din alt motiv: începătorii au nevoie de timp pentru a învăța. Cartea afirmă Legea lui Brooks:

Dacă un proiect nu își respectă termenul limită, adăugarea mai multor forță de muncă îl va întârzia și mai mult.

La foarte număr mare Pentru programatori, proiectul s-ar putea să nu fie finalizat niciodată: din cauza confuziei generale, încercările de a remedia erorile existente generează altele noi, astfel încât sistemul să nu se îmbunătățească.

Program și produs software

Un produs software diferă de un program:

• cel mai generalizat interval și tip de date de intrare
• testare amănunțită, care este un pas neașteptat de dificil
• disponibilitatea documentației detaliate

Un produs software necesită de 3 ori mai mult timp decât un program.

Al doilea efect de sistem

Programator care își dezvoltă propriul doilea sistem, tinde să adauge toate acele caracteristici pe care nu le-a putut adăuga la primul său sistem (din lipsă de timp). Prin urmare, cel de-al doilea sistem se dovedește adesea a fi supraîncărcat cu capacități.

Integritate conceptuală

Pentru a asigura integritatea conceptuală a unui sistem, este necesară separarea arhitecturii de implementare. Un arhitect șef (sau un grup mic), acționând în interesul utilizatorului, decide ce ar trebui și ce nu ar trebui să intre în sistem. O idee „foarte cool” poate fi respinsă dacă caracteristica propusă nu se încadrează în designul general al sistemului. Simplitatea este foarte importantă; Poate fi util să implementați doar o parte din capabilitățile de care este capabil sistemul, deoarece dacă sistemul este prea complex, unele dintre capabilitățile sale vor rămâne neutilizate.

Arhitectul-șef ar trebui să își formuleze deciziile sub forma unui manual de utilizare.

Documente formale

Fiecare manager de proiect ar trebui să scrie un mic set de documente formale care să descrie obiectivele proiectului, cum, de către cine și când vor fi atinse și cât vor costa. Aceste documente pot dezvălui neconcordanțe care altfel ar fi greu de observat.

Fiecare grup de dezvoltare primește un set de cerințe pentru partea sa din sistem, inclusiv o descriere precisă a funcționalității sale și cerințele maxime pentru timpul procesorului, amprenta memoriei, spațiul pe disc etc.

Interacţiune

Pentru a preveni dezastrul, echipele de dezvoltare trebuie să comunice între ele moduri posibile. În loc să facă presupuneri despre funcția pe care o implementează, proiectantul ar trebui să pună arhitectului întrebări clarificatoare, deoarece presupunerile pot fi complet greșite.

Sistem pilot

Înainte ca sistemul final să poată fi dezvoltat, trebuie dezvoltat un sistem pilot. Sistemul pilot va dezvălui erori de proiectare, după care trebuie reproiectat complet.

Grupuri chirurgicale

Este logic ca echipa de dezvoltare să aibă un programator „bun” care implementează cele mai critice părți ale sistemului și alții care îl ajută sau implementează părți mai puțin critice. Așa se fac operațiile chirurgicale. În plus, potrivit lui Brooks, cei mai buni programatori lucrează de 5-10 ori mai repede decât alții.

Utilitati specializate

În loc ca fiecare programator să-și scrie propriile utilități, fiecare grup de dezvoltare ar trebui să aibă un programator responsabil cu scrierea utilităților pentru grupul său (de exemplu, un generator de cod care generează cod conform unor specificații). De asemenea, ar trebui să existe un grup care să creeze utilități pentru toți cei care lucrează la un anumit sistem.

Versiunile și înghețarea sistemului

Pe măsură ce sistemul este creat, cerințele utilizatorului pentru acesta se pot schimba datorită experienței sale cu sistemul neterminat. Aceste dorințe ale utilizatorilor ar trebui să fie luate în considerare, dar numai până la un anumit punct, altfel munca la sistem nu va fi niciodată finalizată. Specificațiile sunt apoi înghețate și toate cererile de modificare ulterioare sunt puse în așteptare până când începe lucrul la următoarea versiune.

Costuri reduse de dezvoltare

Brooks oferă 2 moduri de a reduce costul dezvoltării software:

• Angajați programatori numai după ce arhitectura sistemului a fost construită. În caz contrar, dacă această etapă durează, de exemplu, câteva luni, programatorii nu vor avea ce face.
• Cumpărați niște software de la alți dezvoltatori.