Scurte rezumate din cartea „The Mythical Man-Month, or How Software Systems are Created. Luna mitică a omului sau cum sunt create sistemele software

Dedicat celor doi oameni care au făcut ca anii mei la IBM să fie deosebit de împliniți:

Thomas J. Watson, Jr., a cărui preocupare profundă pentru oameni continuă să pătrundă în firma sa și Bob O. Evans, a cărui conducere curajoasă a făcut din muncă o aventură.

Dedicarea ediției din 1995

Dedicat lui Nancy, darul lui Dumnezeu pentru mine.

Spre surprinderea și plăcerea mea,” Omul-lună mitică„ rămâne popular la 20 de ani de la lansare. Tirajul a depășit 250.000 de exemplare. Sunt adesea întrebat care dintre evaluările și recomandările făcute în 1975 le consider încă corecte, care s-au schimbat și în ce moduri. Deși această problemă este atinsă din când în când în prelegerile mele, am așteptat de mult ocazia să o prezint în formă tipărită.

Peter Gordon, acum coproprietar al Addison-Wesley, a fost un colaborator răbdător și util cu mine din 1980. El a sugerat pregătirea unei ediții aniversare. Am decis să nu corectăm originalul, ci să-l retipărim intact, cu excepția greșelilor de scriere obișnuite, și să îl completăm cu gânduri apărute mai târziu.

Capitolul 16 retipărește articolul „Nu există un glonț de argint: esență și accident în Inginerie software", publicată de IFIPS (Federația Internațională a Societăților de Procesare a Informației) în 1986 și rezultată din experiențele pe care le-am dobândit în timpul conducerii unui studiu privind utilizarea softwareîn domeniile militare, condus de Comitetul de știință militară. Co-autorii mei din acest studiu, precum și secretarul nostru executiv, Robert L. Patrick, mi-au oferit asistență neprețuită în revenirea la proiectele de software ample, practice. Articolul a fost retipărit în IEEE Computer în 1987, datorită căruia a devenit cunoscut pe scară largă.

Articolul „Nu există glonț de argint” a fost sfidător. Acesta a prezis că în următorul deceniu nu vor exista metode de programare care să permită creșterea productivității dezvoltării software cu un ordin de mărime, toate celelalte lucruri fiind egale. Cu un an rămas până la sfârșitul acestui deceniu, se pare că predicția mea s-a împlinit. Articolul a generat mai multe dezbateri în presă decât The Mythical Man-Month, așa că capitolul 17 răspunde la unele dintre criticile publicate și detaliază, de asemenea, opiniile exprimate în 1986.

Pregătind o analiză retrospectivă și o rafinare a lui The Mythical Man-Month, am fost surprins de cât de puține dintre afirmațiile sale au fost criticate, fie dovedite, fie infirmate de experiența și cercetările ulterioare în dezvoltarea de software. Mi s-a părut util să organizez aceste afirmații în formă pură, fără dovezi și date justificative. Am inclus acest eseu în capitolul 18 în speranța că aceste afirmații pure vor declanșa o căutare de argumente și fapte pentru a dovedi, infirma, revizui sau clarifica.

Capitolul 19 este de fapt o încercare de a revizui declarațiile originale. Cititorul trebuie avertizat că noile puncte de vedere prezentate nu sunt atât de susținute de „experiența de luptă” precum au fost în prima parte a cărții. Ideea este că în În ultima vreme Am lucrat mai degrabă într-un mediu universitar decât în ​​industrie, și la proiecte la scară mai mică decât la mare. Din 1986, m-am angajat doar în predarea în domeniul dezvoltării software, dar nu și în cercetarea în acesta. Ale mele cercetare mai preocupat medii virtualeși aplicațiile acestora.

Earl Wheeler și Edward Yordon. Fay Ward a făcut o treabă grozavă munca tehnica asociat cu publicarea de noi capitole.

Sunt recunoscător colegilor mei din Grupul de software militar al Comitetului de știință a apărării, Gordon Bell, Bruce Buchanan, Rick Hayes-Roth și, în special, lui David Parnas, pentru ideile lor perspicace și Rebekah Bierly pentru pregătirea articolului publicat în această carte ca capitolul 16. Analiza problemelor de programare din categoriile „esență” și „accident” a apărut datorită lui Nancy Greenwood Brooks, care a folosit o astfel de analiză într-un articol despre învățarea să cânte la vioară folosind metoda Suzuki.

Obiceiurile editurii Addison-Wesley m-au împiedicat să exprim recunoștința personalului său pentru rolul important pe care l-au jucat în introducerea ediției din 1975. Trebuie remarcate contribuțiile a două persoane în special: Norman Stanton, care a fost redactor executiv, și Herbert Boes, care a fost redactor artistic. Bowes a creat un stil elegant, remarcat în special de un recenzent: „margini largi și utilizarea creativă a tipului și a aspectului materialului”. Mai important, a dat sfat important Puneți fotografia la începutul fiecărui capitol. (Pe atunci aveam doar poze cu Gropile de gudron și cu Catedrala din Reims.) Mi-a luat un an întreg să găsesc toate pozele, dar sunt veșnic recunoscător pentru sfaturi.

Soli Deo gloria - Slavă numai lui Dumnezeu!

F.P.B., Jr. Chapel Hill, Carolina de Nord, martie 1995

În multe privințe, managementul mare proiect Dezvoltarea software este ca orice alt efort major - mai mult decât își dau seama de obicei programatorii. Cu toate acestea, este diferit în multe privințe - mai mult decât presupun de obicei managerii profesioniști.

Procesul de acumulare a cunoștințelor profesionale în acest domeniu este în derulare. Au fost organizate mai multe conferințe, sesiuni la conferințele AFIPS și au fost publicate mai multe cărți și articole. Dar cunoașterea nu s-a conturat încă într-o formă în care să poată fi prezentate sistematic într-un manual. Cu toate acestea, mi se pare oportun să ofer această carte scurtă, care reflectă în principal părerile mele personale.

Dezvoltarea mea profesională în tehnologia calculatoarelor a fost asociat inițial cu programarea, dar în perioada 1956-1963, când au fost dezvoltate programe și limbaje de control autonom nivel inalt, am fost implicat în principal în arhitectura computerelor. Când am devenit manager de proiect pentru dezvoltarea Sistemului de operare/360 în 1964, am constatat că lumea programării a fost complet schimbată de progresele realizate în ultimii ani.

Conducerea dezvoltării OS/360 a fost o experiență foarte iluminatoare, deși frustrantă. Echipa de dezvoltare, inclusiv succesorul meu, F. M. Trapnell, are multe de care să fie mândru. Sistemul conține multe soluții excelente în proiectare și funcționare și a fost adoptat pe scară largă. Unele idei, în special I/O independent de dispozitiv și managementul bibliotecii externe, au devenit inovații tehnice care sunt acum utilizate pe scară largă. Acum acest sistem este destul de fiabil, destul de productiv și foarte flexibil.

Cu toate acestea, proiectul nu poate fi numit complet reușit. Devine rapid clar pentru orice utilizator OS/360 cât de mai bun ar putea fi sistemul. Erorile de proiectare și implementare sunt deosebit de vizibile în program de control, și nu în compilatoarele de limbi. Cele mai multe dintre aceste calcule greșite datează din perioada 1964-65 și, prin urmare, trebuie atribuite mie. Mai mult, sistemul a ieșit cu întârziere și a cerut mai multa memorie decât era de așteptat, costul de dezvoltare a fost de câteva ori mai mare decât era planificat, iar primele versiuni nu au funcționat prea bine.

Cartea lui Frederick Brooks „The Mythical Man-Month, or How 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ță 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ția acestuia, 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, dar și 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 din ce în ce mai puțin efort pentru corectarea erorilor din proiectul original și tot mai mult efort este depus 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 obiectivele ș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țiale 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 să o citești pentru a nu călca pe multe greșeli.

Tema centrală a fost că introducerea de noi forțe într-un proiect în etapele ulterioare de dezvoltare nu face decât să îndepărteze data de livrare a proiectului. Această idee a devenit cunoscută drept Legea lui Brooks.

YouTube enciclopedic

1 / 2

10 cele mai bune cărțiîn programare

Cum să devii un programator tare? Niste sfaturi!

Subtitrări

Istoria scrisului și a publicațiilor

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.

Cartea a fost publicată pentru prima dată în 1975, în același timp a fost publicată și în limba rusă. Cartea a fost relansată ca ediție aniversară în 1995, cu capitole suplimentare: eseul „There Is No Silver Bullet”, publicat în 1986 (Capitolul 16), o revizuire a celor spuse în acest eseu 10 ani mai târziu (Capitolul 17). ) și comentariile autorului despre aceeași carte la 20 de ani de la prima ei publicare (capitolele 18 și 19). În Rusia, a doua ediție a fost publicată de editura Symbol-Plus în 2000, ISBN 5-93286-005-7.

Idei cheie

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 (Capitolul 1).

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 incetineste 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 un numar mare Pentru programatori, proiectul s-ar putea să nu fie finalizat niciodată: din cauza confuziei generale, încercările de a remedia erorile existente în software generează noi erori, astfel încât sistemul să nu se îmbunătățească (Capitolul 2).

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 (Capitolul 3).

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 benefic 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 trebuie să își formuleze deciziile sub forma unui manual de utilizare (Capitolul 4).

Al doilea efect de sistem

Programator care își dezvoltă propriul al doilea sistem, tinde să adauge toate caracteristicile pe care nu le-a putut adăuga la primul său sistem (din cauza lipsei de timp). Prin urmare, cel de-al doilea sistem ajunge adesea să fie supraîncărcat cu capabilități (Capitolul 5).

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. „Presumarea este mama eșecului.”

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 produs. următoarea versiune(Capitolul 11).

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 creează utilități pentru toți cei care lucrează la sistem (Capitolul 12).

Costuri de dezvoltare reduse

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.

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

Această carte este o ediție comemorativă (extinsă și revizuită) a unui fel de Biblie pentru dezvoltatorii de software din întreaga 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. Anunţarea 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 ingineria 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 sistemului de calcul în sine. 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 anul trecut 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 The 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 preț 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 de informare . 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 este la timp, adăugarea mai multă forță de muncă îl va întârzia și mai mult. Adăugarea forței de muncă crește volumul 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 să înregistrați aceste conversații într-un jurnal și să le aduceți la cunoștință Informații generale. În prezent, e-mailul este preferat în acest scop.

Reticența programatorilor de a documenta un proiect provine nu atât din lene, cât și 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 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 nu face decât să întârzie momentul prăbușirii acestuia î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.