Inginerie Software

Fazele dezvoltării unui produs software

1 Ce este ingineria programării?

2. Fazele ingineriei programării

2.1. Faza de analiză

2.2. Faza de proiectare

2.3. Faza de implementare

2.4. Faza de testare

2 Concluzii

1. Ce este ingineria programării?

Ştiinţa calculatoarelor este un domeniu relativ nou. Primele calculatoare au fost construite la mijlocul anilor 1940 şi de atunci au avut loc dezvoltări spectaculoase. În anul 1946 Goldstine şi von Neumann apreciau că1000 de instrucţiuni reprezintă o limită superioară rezonabilă pentru complexitatea problemelor ce pot fi concepute ca rezolvabile cu ajutorul calculatorului. După ce a prevăzut în 1981 că nici un program pentru calculatoare personale nu va necesita vreodată mai mult de 640 KB de memorie RAM, Bill Gates admite în 1995 că lucrurile s-au schimbat în ultimele două decenii.

Următoarele exemple oferă o imagine asupra gradului de complexitate la care au ajuns programele în zilele noastre:

• sistemul de rezervare a biletelor pentru compania aeriană KLM conţinea, în anul 1992, două milioane de linii de cod în limbaj de asamblare;

o sistemul de operare System V versiunea 4.0 (UNIX) a fost obţinut prin compilarea a

o 3.700.000 linii de cod;

• programele scrise pentru naveta spaţială NASA au circa 40 de milioane de linii de cod;

• pentru realizarea sistemului de operare IBM OS360 au fost necesari 5000 de ani-om.

Creşterea programelor în dimensiune şi complexitate a depăşit cu mult progresele făcute în domeniul tehnicilor de programare. De aceea, programarea a devenit şi a rămas mai mult o artă decât o meserie.

O paralelă cu ingineria construcţiilor este atractivă. Dacă dorim să construim o cuşcă pentru câine, putem să mergem prin grădină, să căutam lemne şi cuie, să luăm un ciocan şi să începem să lucrăm. Avem şanse destul de bune să reuşim, mai ales dacă suntem îndemânatici. Dacă totuşi nu reuşim, putem încerca a doua zi din nou cu alte lemne şi alte cuie. Iar dacă câinele nu încape în cuşcă, putem putem încerca a treia zi din nou cu mai multe lemne.

Lucrurile stau radical diferit atunci când dorim să construim o casă pentru familia noastră. Atunci va trebui sau să angajăm un arhitect care să ne facă un proiect, sau să cumpărăm un proiect standard de casă. Va trebui să negociem cu o firmă de construcţii preţul, durata de realizare, calitatea finisajelor. Nu ne permitem să riscăm economiile familiei pe o construcţie care se va dărâma la a doua rafală de vânt. În plus, dacă membrilor familiei nu le place orientarea ferestrelor sau peisajul, nu îi putem schimba cu alţii (în cel mai rău caz, ne schimbă ei pe noi).

Cu atât mai mult, dacă o firmă plăteşte câteva milioane de dolari pentru a ridica un zgârie nori, reprezentanţii acesteia vor fi foarte atenţi cu cine şi în ce condiţii vor lucra. Ei vor dori garanţii că proiectul este viabil, vor angaja mai multe firme de arhitectură pentru a-l verifica. De asemenea, studii geologice, de fizică a pământului sau meteorologie vor fi obligatorii. Vor fi folosite cele mai performante materiale şi se vor angaja cei mai competenţi şi cu experienţă constructori. Eşecul nu mai este o opţiune pentru contractantul proiectului.

Ştim că inginerii constructori întocmesc planuri, construiesc machete, studiază proprietăţile materialelor folosite şi fac rapoarte privind progresul operaţiunilor. Construcţii de o complexitate foarte mare au fost realizate în acest fel într-un mod raţional şi economic. Inginerii de programe ar trebui să procedeze similar pentru ca dezvoltarea programelor să nu mai fie un proces impredictibil.

Pe măsură ce complexitatea programelor creştea, la sfârşitul anilor ’60 începea să se prefigureze deja o criză a programării. Un raport prezentat de către o companie, în care erau analizate câteva proiecte şi stadiile lor de finalizare, a constatat că:

• 2% din sistemele software contractate au funcţionat de la predare;

• 3% din sistemele software au putut funcţiona după câteva modificări;

• 29% au fost predate dar n-au funcţionat niciodată;

• 19% au fost folosite dar au fost abandonate;

47% au fost plătite dar niciodată predate.

Pentru a contracara aceste tendinţe, la conferinţa organizată de comitetul ştiinţific al NATO în anul 1968, a fost propus termenul de ingineria programării (engl. „software engineering”), într-un mod oarecum provocator. Se dorea ca arta programării să împrumute din rigoarea ştiinţelor inginereşti pentru a putea livra programe la timp şi în mod economic. Prima definiţie dată ingineriei programării a fost enunţată astfel (F. L. Bauer):

Ingineria programării este stabilirea şi utilizarea de principii inginereşti solide pentru a obţine în mod economic programe sigure şi care funcţionează eficient pe maşini de calcul reale.

În IEEE Standard Glossary of Software Engineering Technology (1983) ingineria programării este definită după cum urmează:

Ingineria programării reprezintă abordarea sistematică a dezvoltării, funcţionării, întreţinerii, şi retragerii din funcţiune a programelor.

Remarcăm că a doua definiţie este mai vagă decât prima, întrucât nu face referire la cost şi la eficienţă. Mai mult, se pare că experienţa în general negativă acumulată a făcut să se renunţe la formularea „principii inginereşti solide”, întrucât se pare că acestea nu pot fi identificate fără a fi supuse contestaţiilor. A doua definiţie adaugă însă referiri la perioade importante din viaţa unui program, ce urmează creării şi funcţionării, şi anume întreţinerea şi retragerea din funcţionare.

Considerăm că ingineria programării are următoarele caracteristici importante:

• este aplicabilă în producerea de programe mari;

• este o ştiinţă inginerească;

• scopul final este îndeplinirea cerinţelor clientului.

Programele mici se pot scrie relativ uşor, de către un singur programator, într-o perioadă destul de scurtă de timp. Un program de 100 de instrucţiuni este cu siguranţă un program mic. Nu putem identifica precis graniţa dintre un program mic şi unul mare, însă pe măsură ce dimensiunea programului creşte, apar provocări noi, calitativ diferite.

Întrucât un singur sau câţiva programatori nu pot avea timpul fizic pentru terminarea programului, este necesară crearea uneia sau mai multor echipe de lucru. Este necesară coordonarea şi comunicarea între echipe. Complexitatea sistemului software şi a organizaţiei care realizează sistemul software devine importantă, putând depăşi capacitatea de înţelegere a unui singur individ.

Apare ca dezirabilă o abordare riguroasă a acestor probleme, ce include stilul de lucru, modul de scriere a codului etc.