Proiectare (inginerie software)

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

În ingineria software , proiectarea (uneori numită și proiect sau desen , din engleză design ) este o fază a ciclului de viață al software-ului . Pe baza specificației cerințelor produse de analiză , proiectul definește modul în care aceste cerințe vor fi satisfăcute, intrând în meritele structurii care trebuie acordată sistemului software care urmează să fie creat.

Descriere

Cu toate acestea, proiectarea rămâne o fază distinctă de programare sau codificare, care corespunde traducerii într-un anumit limbaj de programare a deciziilor luate în timpul fazei de proiectare, adică, prin urmare, faza de implementare .

Distincțiile dintre activitățile menționate până acum nu sunt întotdeauna la fel de clare pe cât ar dori teoriile clasice ale ingineriei software. În special, proiectarea poate descrie funcționarea internă a unui sistem la diferite niveluri de detaliu, fiecare dintre acestea fiind plasat într-o poziție intermediară între analiză și codificare.

Proiectarea arhitecturii (sau proiectarea arhitecturală ) se referă de obicei la proiectarea „la un nivel foarte ridicat”, în care doar structura generală a sistemului este definită în funcție de modulele principale din care este compus și de relațiile macroscopice dintre acestea. Formulele precum client-server sau trei niveluri aparțin acestui nivel de proiectare sau, mai general, deciziile privind utilizarea anumitor arhitecturi hardware , sisteme de operare , SGBD , protocoale de rețea și așa mai departe.

Un nivel intermediar de detaliu definește încă defalcarea sistemului în module, dar de această dată cu referire mai mult sau mai puțin explicită la modalitățile de defalcare oferite de limbajul de programare special cu care va avea loc dezvoltarea; de exemplu, într -un design orientat pe obiecte , proiectul ar putea descrie sistemul în funcție de clasele principale și de relațiile lor.

În cele din urmă, proiectul detaliat reprezintă o descriere a sistemului foarte apropiată de codificare, adică o leagă în mod substanțial (de exemplu, descriind nu numai clasele în abstract, ci și atributele și metodele lor, cu tipuri conexe și " semnătură ").

Datorită naturii „intangibile” a software-ului și în funcție de instrumentele utilizate în proces, granița dintre proiectare și codificare poate fi, de asemenea, practic imposibil de identificat. De exemplu, unele instrumente CASE sunt capabile să genereze cod din diagrame UML care descriu grafic structura unui sistem software.

fundal

Necesitatea de a înțelege dificultățile de creare a software-ului a apărut la sfârșitul anilor șaizeci , conștientizând că o bună bază de programare nu înseamnă a avea sisteme bune disponibile.

Dezvoltarea a avut loc în anii cincizeci și șaizeci când problema a fost activitatea de programare prin alte studii legate de algoritmi, structuri de date, programare structurată, limbaje de programare. Programarea a fost văzută ca „punând împreună” o succesiune de instrucțiuni. În Adunarea anilor 1950, a apărut un limbaj de nivel scăzut, iar la sfârșitul anilor 1950 au apărut primele limbaje „de nivel înalt” ( Cobol , Fortran ). În această perioadă, programarea s-a bazat pe abilitățile programatorilor, pe dezvoltarea de aplicații mici sau mijlocii (calcul centralizat) și pe metodologia „cod și fix”. Dar odată cu creșterea complexității, apariția rețelelor și aplicațiilor client-server, este nevoie de o metodologie care să ghideze procesul de dezvoltare.

În acest moment am asistat la introducerea de noi limbaje care au făcut programarea mai ușoară și răspândirea PC-urilor a permis să se nască figura profesională a programatorului, nu ca utilizator final al aplicației, ci ca dezvoltator de aplicații.

Spre sfârșitul anilor 1960, s-au născut primele proiecte software în scopuri comerciale, dar tehnicile bune de programare dobândite până atunci nu au fost suficiente pentru evoluția unui software puternic. Proiectele au fost mai scumpe decât se așteptau și au rămas întotdeauna în urmă cu perioadele de dezvoltare. Într-o conferință din 1968 am început să vorbim despre criza software - ului , unde se subliniază că problema nu mai era „scrierea secvențelor de instrucțiuni”, ci comunica cu oamenii implicați în dezvoltare. Cauzele crizei trebuie să fie legate de schimbarea cerințelor din timpul dezvoltării, de schimbările care implică întregul sistem, de cifra de afaceri a personalului.

Un nou scenariu a apărut din conferință, care prevedea o abordare structurată a dezvoltării, cu introducerea consecventă a managementului, organizării, teoriilor și tehnicilor, instrumentelor și metodologiilor adecvate. Am început să vorbim despre ciclul de viață al software-ului , destinat ca o descriere a activităților care conduc la crearea și gestionarea unui sistem.

În 1984, James Martin , expert în inginerie software , a publicat „An Information Systems MANIFESTO” (sic), un adevărat manifest provocator destinat să scuture letargia și lipsa de înclinație a managementului timpului pentru a vedea riscurile și oportunitățile din tehnologia informației. Laitmotivul lucrării poate fi rezumat ca „ IT nu este un detaliu tehnic încredințat specialiștilor EDP, ci o resursă strategică care merită atenția continuă a managementului de vârf ”. În același timp, James Martin pune bazele pentru noi tehnici de dezvoltare precum CASE și RAD .

În 1994, „Standish Group International”, ca parte a unui proiect de cercetare, a încercat să ofere răspunsuri în contextul eșecurilor proiectelor software.

Proiectele au fost clasificate în trei categorii distincte:

  1. Proiecte de succes: finalizate la timp și fără a depăși bugetul stabilit și cu toate caracteristicile și funcțiile stabilite în specificațiile inițiale.
  2. Proiecte întârziate: proiectul este finalizat și operațional, dar a necesitat mai mult timp și bani decât s-a estimat și oferă mai puține caracteristici
  3. Proiecte șterse: Proiectul a fost șters în timpul ciclului de dezvoltare, înainte de a fi terminat.

Deși diferite proiecte eșuează în moduri diferite, cauza principală a majorității eșecurilor de dezvoltare software se dovedește a fi o metodologie inadecvată.

Alte cauze par a fi:

  • birocratizarea excesivă a dezvoltării
  • dificultate în contabilizarea modificărilor cerințelor
  • software greu de întreținut sau de evoluat
  • descoperirea târzie a erorilor grave de proiectare
  • teste insuficiente
  • calitate slabă a software-ului
  • performanțe inacceptabile ale software-ului.

Din acest motiv, au fost introduse diferite tipuri de dezvoltare software care au servit la îmbunătățirea limitărilor întâlnite.

Alte proiecte