Primele 10 motive din cauza carora esueaza proiectele de Sisteme Informatice

Dr. Paul Dorsey Dulcian, Inc.

Generalitati

Proiectele de Sisteme Informatice esueaza frecvent. Depinzand de statistica pe care o cititi, rata de esec a proiectelor mari ar fi intre 50 % - 6O % . Deoarece natura umana are tendinla de a ascunde vestile proaste, realitatea poate fi chiar mai grava. Aceasta este o catastrofa. Ca industrie, esuam in munca noasra.

Daca ne bazam pe experienta din trecut, in momentul in care se porneste un proiect de sistem mare, complex, asteptarile realiste ar trebui sa fie ca proiectul va esua. In particular proiectele de reproiectare a proceselor de luau (Business Process Reengineering - BPR) au o rata de esec chiar mai mare din cauza scopului lor extins. Angajarea unei societati mari de consultanta nu ofera garantii de succes, nici cumpararea de pachete de software si implementarea lor.

Deseori proiectele sunt construite utilizand o strategie ce aproape ca garanteaza esecul. Ingineria software este un fel de inginerie. Construirea unui sistem informatic mare se aseamana cu construirea unui bloc cu 20 de etaje. Daca un grup de electricieni, instalalori, tamplari si constructori se intalnesc pe un camp, vorbesc cateva ore si apoi incep sa construiasca, constructia va fi instabila, asta daca va fi totusi construita. Intr-una din prezentarile mete, o persoana din audienta a spus ca "Daca inginerii constructori ar cladi constructii cu aceeasi grija cu care inginerii software construiesc sisteme, o ciocanitoare ar pulea produce sfarsitul civilizaliei asa cum o cunoastem noi."

Daca am fi constienti mereu ca a construi software este exact ca si a construi o cladire, atunci cea mai mare parte a problemelor noastre ar disparea. Inainte de a construi o cladire, un arhitect deseneaza planuri detaliate, construieste modele si face machete. In fiecare etapa, planurile sunt revizuite cu grija in mod repetat. In timpul constructiei, fiecare pas este testat si inspectat. In proiectele software, daca nu am inceput sa scriem programul in trei luni, consideram in mod gresit ca nu este bine. Nu putem vedea ca este un nonsens sa ne repezim sa programam fara a avea un plan alcatuit cu grija? Ca exemplu, intr-un protect in care am fost implicat, managerul proiectului a adus echipa de scriere a documentatiei chiar inainte de a avea o interfata grafica stabila. Acest lucru este ca si cum ai aduce zugravii inainte de a construi peretii.

Care este, deci, cauza esecului acestor proiecte? Este vreun secret tehnic pe care cei mai multi ingineri nu-I cunosc? Sunt proiectele software atat de complexe ca numai cele mai talentate echipe au sanse de reusita? Eu personal am fost implicat atat in proiecte reusite, cat si in proiecte ce au esuat sau la care s-a renuntat. Este trist ca proiectele software esueaza din cauza ca nu recunoastem ca principiile ingineresti trebuie sa fie aplicate si proiectelor software exact la fel cum se aplica constructiei de cladiri. Incercam sa ne aparam spunand ca dezvoltarea de software este "diferita".

Cand Peter Koletzke si cu mine am publicat prima oara "The Oesigner/2000 Handbook", am introdus in ea o multime de informatii despre ingineria software. Am incercat sa scriem cum ar trebui sa se construiasca un sistem bun utilizand produsul Designer. Modul in care acest material a fost primit de comunitate este interesant si uneori negativ. Un cititor scria "Stiu deja cum se construiesc sisteme. Ceea ce imi trebuie este cum sa folosesc produsul." Altul se plangea ca in carte nu erau introspectii si ca este numai o carpaceala a "gunoiului SDLC (Software Development Life Cycle-Ciclul de Vista al Dezvoltarii de Software) pe care m-au obligat sa-I citesc la stoats." Inginerii de sistem mai experimentati care au fost implicati in numeroase proiecte au vazut valoarea cartii si au fost destul de receptivi. Dar cred ca cel mat interesant comentariu despre carte a venit de la fratele meu, Walt. Wall este un inginer "adevarat' care a detinut functia de asigurare a calitatii pentm mai multi producatori tehnici mari. Mi-a spus ca i-a placut cartea si ca sfaturile din carte oglindesc modul in care sunt conduse proiectele mari in firmele in care a lucrat el. A fost surprins ca aceasta metoda de dezvoltare nu face parte din modul normal in care se construiesc sistemele informatice.

Am facut multe prezentari la conferintele Oracle. Daca vorbesc despre moduri de imbunatatire a proiectarii bazei de date, pot de obicei sa atrag 30-60 de ascultatori. Daca vorbesc despre modul de imbunatatire al mediului de dezvoltare Java, pot atrage 300-500 ascultatori. Cred ca aceasta lipsa de interes in metodologie este miezul problemelor noastre. Multi dintre noi considera in mod gresit ca singura contributie reala la un project este scrierea programelor. Revenind la exemplul cu cladirea, este ca si cum ai spune ca data nu ai un ciocan sau o bidinea in mana, contributia ta la cladire nu este semnificativa.

Nu va asteptati sa gasiti idei sclipitoare in acest material. Va voi impartasi din succesele, esecurile si aproape catastrofele mele. Concluzia mea finala este ca cel mai bun mod de a face un project sa reuseasca este sa-ti utilizezi capul. Cum putem evita greselile ce duc la esecul unui project? In mod surprinzator raspunsul este de cele mai multe ori bunul simt. Problema noastra este ca bunul simt este deseori ignorat in proiectele de sisteme.

Cele trei chei spre succesul unui project

Par sa existe trei factori pe care toate proiectele reusite le au in comun. Fiecare din acesti factori este cheie a succesului oricarui project. Fiecare project poate fi vazut ca un tripod. Toate cele trei picioare ale tripodului trebuie sa fie bine asezate pentru ca tripodul sa fie stabil. Intr-un project de sistem, aceste "picioare" sau factori critici de succes consista din urmatoarele:

• Sprijin din partea managementului

• O metodologie solida

• Conducere tehnica solida de catre cineva care a reusit cu succes un project similar.

Fara ca acesti factori sa fie bine plasati, tripodul se va rasturna si proiectul va esua.

Sprijin din partea managementului

Toate studiile care s-au facut in legatura cu succesul sau esecul sistemelor au identificat sprijinul din partea managementului ca un factor critic de succes. Fara angajare completa din partea managementului, cand vor sparea probleme in project (si inevitabil acestea vor sparea), proiectul va esua.

In orice organizatie ce realizeaza un project de sistem, managementul trebuie sa fie constient de la inceput ca proiectul va intalni intarzieri serioase. Managerii trebuie sa fie pregatiti sa ramana vizibili si auziti in spalele proiectului in ciuda acestor intarzieri, altfel proiectul este destinat esecului.

Am fost implicat intr-un sistem in care implementarea mergea greu. Utilizatorii erau pe cale sa se revolte. Oricum, managementul a sprijinit proiectul si pana la urma acesta a reusit. Daca managementul nu ar fi fost alat de angajat, proiectul ar fi esuat cu siguranta.

Lucrand la alt sistem, proiectul mergea bine, dar a venit un manager nou si proiectul a disparut efectiv paste noapte. De fapt, cateva din proiectele esuate la care am participat au fost anulate de catre o persoana cu care nu s-a intalnit nici un membru al echipei de dezvoltare. Aceasta conduce la o concluzie importanta: un project nu poate avea succes daca managementul nu considera ca are succes. Managerii trebuie sa fie informati de fond in legatura cu procesul ce se utilizeaza si asteptarile lor trebuie sa fie gestionate.

Exista o diferenta reala intre proiectele de sistem si cladiri. Cand cladirea este pe jumatate terminata, se poate vedea ceva. Cand un project software este pe jumatate terminat, sunt foarte putine lucruri de vazut. Managerii trebuie sa stie ce si cand pot vedea ceva. Daca considera ca ar trebui sa vada ruland 50 % din sisteme atunci cand 50 % din bugel este cheltuit, probabil ca vor incepe sa se gandeasca sa opreasca un project care de fapt se poate desfasura conform programului.

Atentie la dezvoltatorii buni care considers ca sunt conducatori de project. Un dezvoltator cu experienta cu mai multi ani de experienta poate sa nu inteleaga proiectul sistemului. Dar ar pulea sa omoare un project cu o singura opinie bine plasata.

Managerii nu inteleg de obicei proiectul unui sistem. Ei se bazeaza pe opiniile unor consultanti cu experienta. Cheia gestionarii pentru manageri este de a aduce auditori obiectivi de nivel inalt. De unde poate sti managementul ca nu sunt inselati sau ca proiectul nu este condus prost? Acestia nu au cunostintele pentru a pulea evalua situatia. Un project poate fi oprit de manageri pur si simplu din cauza ca nu inteleg actiunile echipei de dezvoltare. In astfel de cazuri, un audit tehnic poate valida actiunile echipei de dezvoltare si furniza managementului informatia ceruta pentru a continua sprijinirea proiectului.

Metodologie de dezvoltare

Multe sisteme sunt construite fara ca procesele sa fie bine gandite. Echipele se intalnesc si incep sa execute activitati. De indata ce este adunata sufcienta informatie, incepe codificarea. Aceasta lipsa de atentie asupra proceselor poate ucide un project. Este usor sa se vada rezultatul unei lipse de atentie asupra procesului dupa esuarea sistemului. De obicei sunt ignorate parti importante din cerintele utilizatorilor. Parti mari din cod trebuie sa fie rescrise, deoarece nu indeplinesc cerintele utilizatorilor de prima data. Daca este terminat, sistemul este implementat fara testare adecvata. Fara a avea un proces bine gandit, sunt putine sanse ca un proiect de sistem sa se termine. Daca proiectul reuseste, aceasta se intampla numai cu rescrieri substantiate si cu depasiri de costuri.

Ar pulea sa para surprinzator faptul ca metodologia selectata nu conteaza, dar aceasta este adevarat. Ceea ce conteaza este sa existe o metodologie. Nu exista studii explicite care sa indice faptul ca o anumita metodologie este mai buna decat alta. Ceea ce este important este mentinerea proiectului organizat intr-un mod consistent si focalizat si gandirea procesului cu grija inca de la inceput.

Diferitele metodologii aduna aceeasi informatie, dar o organizeaza in mod diferit. Una poate avea pasi suplimentari inutili. Alteia pot sa-i lipseasca niste pasi care sa permita dezvoltatorilor sa reia fazele anterioare. Este important de punctat ca trebuie sa se utilizeze cu succes o metodologie. Daca procesul este gresit, de obicei nu este gresit in mod serios. Este posibil ca o metodologie sa fie mai eficienta decat alta, dar orice proces este mai bun decat nici un proces.

Exista mai multe moduri de a aborda dezvoltarea sistemelor-orientata pe obiecte, cu prototip rapid, cascada, etc. Fiecare din ele utilizeaza diverse utilitare pentru a realiza aceeasi sarcina. O abordare orientata pe object ar utiliza cazuri in analiza, in timp ce un profesionist Oracle traditional va uliliza o ierarhie de functii. Daca o anumita organizatie are talente intr-un anumit domeniu, nu exista nici un motiv sa nu fie exploatata aceasta experienta. De exemplu, daca aveti mai multi programatori ce programeaza orientat pe obiecte, o abordare orientata pe object ar fi alegerea clam. De asemenea, un project in care oamenii cunosc Oracle Designer poate utiliza metodologia CADM. Asa cum am spus in alta parte, poafe fi util daca metodologia selectata este integrata cu utililarele de dezvoltare selectate deoarece in acest mod va exista mai putin efort risipit. Oricum, aceasta nu va garanta succesul proiectului. Un project poate fi mai mult sau mai putin scump dar nu va reusi sau esua in functie de metodologia sau utilitarele folosite.

Conducere tehnica

Asa cum o cladire are nevoie de un arhitect, la fel un sistem software are nevoie de un conducator tehnic. Pentru a avea succes, arhitectul sau conducatorul tehnic trebuie sa fie cel care are controlul asupra "arhitecturii" proiectului, asupra modelului de date si proiectarea aplicatiei. Acest nivel de control trebuie sa fie recunoscut si acceptat de catre fiecare participant in project. Altfel, fiecare portiune din sistem poate fi construita independent de catre o parte a echipei si bucatile nu se vor potrivi in final.

Conducatorul tehnic trebuie sa fi construit sisteme similare in domeniul de activitate specific al sistemului ce trebuie sa fe construit. De exemplu, orice sistem ce include functii fnanciare trebuie de obicei sa aiba o interfata cu functionalitate de contabilitate existenta. Aceasta inseamna ca conducatorul tehnic trebuie sa inteleaga practicile de baza ale contabilitatii. In experienta mea, am fost rugat sa revizuiesc proiecte esuate ce includeau functii financiare in care fostii proieclanti ai sistemelor si conducatorii tehnici nu intelegeau nici elementele de baza ale debitelor si creditelor.

Factori interdependenti in succesul unui proiect

Nu este posibil sa avem maxim pe toti cei patru factori. Adica nu puteti avea un sistem construit cu putini bani, cu calitate ridicata, construit repede si cu risc mic de esec. Cele mai multe discutii ale acestor factori ii cuprind numai pe primii trei. Este posibil sa se construiasca un sistem de calitate rapid, cu costuri relaliv mici, taind colturile si facand testari putine sau deloc. Oricum riscul ca un astfel de sistem sa esueze creste dramatic. Din acesti patru factori, in orice proiect, doi pot fi obtinuti cu succes, lasand ca ceilalti doi sa trebuiasca sa fie gestionati.

Din acest patru factori, cei mai importanti sunt riscul si calitatea. Sistemul trebuie sa lucreze si sa indeplineasca cu succes cerintele utilizatorilor. Aceasta face ca timpul si costul sa fie ajustati in mod corespunzator. Daca insistati sa aveti timp de dezvoltare mic sau costuri reduse, calitatea si riscul se vor deplasa corespunzator. Am avut multe discutii cu managerii pe marginea acestui principiu. Mi s-a spus: "Daca utilizam Produsul X si Metodologia V putem construi sistemul rapid cu costuri minime'. Aceasta nu este o pozitie realista. Puteti insista pe risc redus si calitate ridicata, recunoscand ca timpul si banii trebuie sa fie ajustate astfel incat sa se obtina aceste obiective.

Migrarea datelor si implementare

Doi factori aditionali in determinarea succesului sau esecului unui project care sunt adeseori uitati, sunt migrarea datelor si implementarea sistemului. Migrarea datelor trebuie sa fie planificata foarte devreme in orice project. Migrarea datelor trebuie aproape sa fie considerala ca project separat.

Similar, chiar un sistem proiectat cu grija, bine si bine documentat paste totusi sa esueze in 10-20 % din cazuri din cauza ca implementarea nu este gestionata corect. Aceasta se poate datora instruirii necorespunzatoare a utilizatorilor, tranzitia defectoasa de la vechiul la noul sistem si lipsei de suport pentru noul sistem.

Lista celor mai importance 10 moduri de a garanta esecul unui project de sistem. Lista urmatoare a fast inspirata din greseli reale intalnite in proiecte.

1. Nu se utilizeaza o anumita metodologie deoarece codul este singurul important. Utilizarea unei metodologii structurate de dezvoltare a sistemului esle unul din factorii critici de succes intr-un project de dezvoltare de sisteme. Din acest motiv, Peter Koletzke si eu am venit acum cativa ani cu Metoda de Dezvoltare CASE a Aplicatiilor (CADM) ca succesor al metodei traditionale CASE conceputa de Richard Barker. CADM se bazeaza pe cateva concepte de baza. In primul rand, este utilizata o abordare de inginerie de productie a dezvoltarii de software. Aceasta abordare da atentie punctelor de control al calitatii, identificand locul in care aceste puncte sunt intalnite in Ciclul de Vista al Dezvoltarii de Software (SOLC) si tipul de verificari necesare pentru a asigura ca fiecare faza este terminata cu succes inainte ca proiectul sa fie gata de a trece in faza urmatoare. In fiecare project de succes trebuie incluse puncte de control al calitatii explicite. De exemplu, pledoaria modelului formal dupa ce modelul de date este complet este un pas peste care se trece de obicei si apoi se regreta aceasta. lnvers, in cadrul CADM, au fost eliminate punctele de control de calitate care nu sunt necesare deoarece exista controale implicate. De exemplu realizarea migrarii datelor ajuta in validarea unor aspecte ale proiectarii fizice a bazei de date.

O a doua components majors a CADM este inregistrarea pentru audit a cerintelor sistemului. Am inclus posibilitatea de a urmari o cerinta pe intregul SDLC de la inregistrarea sa, prin analiza, pans la impactul sau asupra testarii de catre utilizator la sfarsitul procesului.

A lucra inapoi de la o data fixa de incheiere a proiectului este un mod sigur de a garanta esecul unui proiect si, din nefericire, este o practica prea obisnuita in comunitatea IT. Managerii pot lua o decizie despre momentul in care un sistem nou sau regandit ar fi util in productie fara a avea cunostintele tehnice pentru a determina daca este sau nu posibil sa se realizeze cu succes in perioada de timp data. Nici un proiect nu a mers fara nici o problema de la Strategie la Implementare. Exists multe locuri in SDLC in care programarile pot fi intarziate:

• Analiza incorecta rezultand in cerinte critice neacoperite, aparute tarziu in procesul de dezvoltare;

• Neluarea in calcul a migrarii datelor

Trebuie sa stabiliti un program realist al incheierii proiectului de sistem si sa va asteptati ca unele termene sa fie depasite ca urmare a aparitiei unor probleme inevitabile. Fortarea unui termen limita pentru a pasha programul va produce taierea colturilor, marind astfel mult riscul proiectului. Chiar data sistemul va fi construit, de obicei va fi de calitate redusa deoarece aplicatiile se vor construi una dupa cealalta numai pentru fi terminate la timp.

3. Nefolosirea unui model de date. Construirea tabelelor pe masura ce este nevoie de ele. Modelul de date este nucleul sistemului. Fara un model de date construct cu grija, orice sistem este sortit esecului, sau cel putin neindeplinirii necesitatilor si cerintelor utilizatorilor.

Sunt intotdeauna surprins cand angajez un dezvoltator cu mai multi ani de experienta care nu a vazut niciodata un model de date. Chiar data au lucrat cu modele de date, de obicei acestia nu au vazut pe cineva facand un audit atent al modelului.

Sunt la fel de mirat cand merg intr-un mare institut financiar si vad ca nu exista un model de date pentru un sistem ce are cateva sute de tabele. Cand vad un audit al unui astfel de sistem, gasesc numeroase greseli critice in sistem ce permit datelor proaste sa fie introduse. In astfel de sisteme, migrarea datelor la un nou sistem poate lua mai multe luni deoarece statele date trebuie sa fie clarifcate.

In cea mai rea situatie pe care am avut-o, fiecare dezvoltator isi construia tabelele si aplicaliile de care avea nevoie pe stele tabele. Conducatorul tehnic venea mai tarziu incercand sa faca sa lucreze impreuna partite disparate. Inutil de spus, sistemul nu a fost niciodata terminal.

Modelele de date trebuie sa fie sub controlul direct al unui conducator tehnic. Fiecare subsistem trebuie sa fie integrat in sistem inainte de dezvoltare.

Modelele trebuie sa fie auditate si reauditate pana cand nu se mai descopera alte erori.

Auditul trebuie facut intai de conducatorul tehnic. Apoi trebuie adus un auditor extern pentru un audit aditional.

Persoana cu rolul de conducator tehnic al proiectului trebuie sa aiba experienta. Aceasta trebuie sa fi incheiat cu succes alte proiecte similare. Rolul de conducator tehnic este asemanator cu acela al unui chirug talentat. Nu va asteptati ca un medic de familie sa faca operatie pe creier sau sa administreze anestezii. Este critic ca persoana ce raspunde de aspectele tehnice ale proiedului sa aiba experienta cu tipul de sistem ce se construieste.

Bineinteles, o asttel de resursa este destul de costisitoare dar nu la fel de costisitoare ca un proiect esuat. Trebuie sa recunosc ca este o enigma pentru mine faptul ca unii manageri adauga cu usurinta 5-10 consultanti suplimentari platiti cu 700$/zi la un proiect, dar refuza sa accepte faptul ca un bun conducalor de proiect va costa de cateva ori aceasi suma. Deci au o echipa mare ce genereaza un sistem prost cu bani multi.

Exemplul meu favorit a fost o organizatie mare, cu 80 de dezvoltalori care nu a reusit sa porneasca un sistem. De fapt, conform managerului de project, se facuse un progres mic la sistem. Oricum, aceeasi organizatie nu dorea sa aduca un conducator tehnic bun care ar fi putut asigura un mediu dezvoltare solid, si ar fi putut face cei 80 de dezvoltatori productivi.

5. Angajarea a 40 de dezvoltatori pentru a face codificarea sa mearga mai repede.

Mai mult nu inseamna neaparat mai bun. Aceasta este adevarat in special in cazul echipelor de dezvoltare. Un proied cu cativa dezvoltatori talentati, supravegheati cu atentie de un conducator tehnic corespunzator are mai multe sanse de succes decat unul in care hoarde de dezvoltatori scriu munti de cod in fiecare zi.

Intr-un sistem pentru care am fost angajat conducator tehnic, proiectul avea asignat 40 de oameni. Am fost intrebat ce resurse am nevoie pentru a face proiectul sa reuseasca. Le-am spus "20 de oameni mai putin". Au crezut ca glumesc. Nu glumeam. Oricum, aceasta era o firma de consultanta, in care facturarea era evident mai importanta decat eficienta.

"Scula potrivita pentru sarcina potrivita." Acest motto este la fel de adevarat pentru construirea de sisteme ca si pentru construirea de cladiri. Una din probleme pentru multi arhitecti de sistem este faptul ca utilitarele disponibile influenteaza destul de mult modul in care se construiesc sistemele. Chiar si elementele de baza ale procesului de dezvoltare sunt influentate de utilitarul selectat. Asigurati-va ca exista expertiza necesara pentru utilitarul de dezvoltare selectat. Aceasta presiune spre Java si Web va face sa creasca desigur o intreaga noua categorie de esecuri de sisteme. In caz ca nu ati observat inca, mediul Java este relativ imatur. Cu totii mai avem destule de invatat despre Java si dezvoltarea pe web.

Un client m-a informal recent ca intentia lor este sa dezvolte formele pe web pentru utilizatorii lor. Dar utilizatorii erau 20 toti in aceeasi cladire utilizand doua retele. Un asttel de sistem poate fi suportat cu usurinta de catre un sistem client-server simplu cu mult mai putini bani. Alte companii au stabilit politici formale ca orice noua dezvoltare va fi facuta in Java, independent de costul deciziei sau cunostintele dezvoltatorilor lor.

Faza de migrare a unui project poate consuma pana la 30 % din resursele totale ale proiectului. De obicei, atentia ce se da acestei faze in metodologiile existente este foarte mica. Costul migrarii datelor tinde sa fie imprevizibil pana foarte tarziu in programul proiectului. Cea mai obisnuita problema in planificarea migrarii datelor este faptul ca prea putine resurse sunt investite pentru aceasta. Multe programe de proiect vor afisa migrarea datelor ca o unica sarcina in efortul de dezvoltare. Dar, pana la sfarsitul proiectului va fi evident ca migrarea datelor a fost intr-adevar un proiect separat, dependent de mai multe din produsele proiectului de dezvoltare.

Din aceste motive este foarte importanta planificarea dinainte a migrarii pentru orice proiect. In particular, implementarea structurilor generice de date, care sunt de dorit pentru cresterea timpului de viata al sistemului, poate crea semnificativ mai multe probleme complexe de migrare decat implementarea proiectelor traditionale de sistem.

Dupa ce am fosf martor la un numar de proiecte esuate si am invatat din experienta amara, a astepta pana cu trei luni inainte de a trece in productie pentru a asigna o singura persoana care sa gestioneze migrarea datelor va produce inevitabil esecul sistemului.

8. Sarirea fazei de testare pentru ca proiectul este oricum intarziat

Lansarea unui sistem in productie fara testare adecvata este ca scufundarea intr-o piscina fara a verifica daca aceasta are apa. Nici un sistem nu a fost creat vreodata fara nici un bug. Timpul petrecut pentru a testa cu grija orice sistem inainte de a-I lansa in productie poate salva mult mai mult timp pe termen lung.

In faza de testare, ar trebui sa dezvoltati un plan de testare ce ar frebui sa descrie testele ce vor fi rulate si modul in care vor fi gestionate erorile aparute la testare sau variantele. In special pentru sistemele mari, nu este practic sa se astepte pana la sfarsitul fazei de dezvoltare pentru a incepe dezvoltarea acestui plan de testare. Trebuie sa existe o anumita suprapunere. Pe masura ce fiecare modul este finisat si trece de testarea la nivel de unitate, acesta este sufcient de stabil pentru a planifca teste formale.

Nu este neaparat adevarat ca orice eroare sau varianta de testare duce la modificarea sistemului inainte de productie. In timpul fazei de testare va fi necesar sa se refaca auditul procesului de proiectare, sa se realizeze teste la nivel de sistem si de utilizator, sa se faca audit la calitatea documentatiei, sa se testeze controalele interne si procedurile de backup si recuperare si sa se asigure in orice mod posibil ca sistemul este corespunzator pentru a intra in mediul de productie. Persoana care conduce asigurarea calitalii trebuie sa dezvolle un plan de testare. Utilizatorii trebuie sa fie implicati pentru a identifica cazurile de testare, si ei pot scrie testele si rezultatele asteptate. Exista doua componente ale planului de testare: abordarea si proiectarea. Abordarea include tehnicile de testate, utilitarele de testate, rolurile si responsabilitatile, meloda de selectie si inregistrare a erorilor, procesul de control al schimbarilor, procesul de retestare si mediul de testare. Partea de proiectare a planului de test include obiectivele testului, cazurile si scripturile. Planul de testate este cadrul in care diferite niveluri sau tipuri de testare sunt realizate, de exemplu testarea sistemului si testarea de catre ulilizatori. Ar trebui sa dezvoltati un plan de testare pentru fiecare tip de testare.

Intr-un sistem la care am lucrat, compania a insistat sa faca testarea punand sistemul in productie si lasand utilizatorii sa gaseasca bug-urile. Cand a fost pus in productie un sistem plin de bug-uri, utilizatorii au fost furiosi.

Este important sa preveniti deplasarea scopului unui proiect. Intotdeauna vor exista noi cerinte de suportat, noi moduri putin mai bune de a modifica modelul de date si moduri mai bune de a proiecta aplicatia. Data nu stabilili o regula formala care sa previna majoritatea sugestiilor binevoitoare in legatura cu imbunatatiri ce pot fi aduse in sistem, sistemul nuva fi incheiat niciodata. Odata ce inghetati un produs in once faza a procesului CADM, acesta nu trebuie sa fie alterat. Singura exceptie de la aceasta regula este momentul in care se descopera o greseala in proiectarea sistemului care va preveni sistemul sa intre in productie. Data nu introduceti reguli rapide si solide in legatura cu schimbarile care sunt acceptabile si cand pot fi facute astfel de schimbari, sistemul poats fi intarziat saptamani, luni sau poate sa nu ajunga niciodata in productie.

Cine decide ce va fi facut si cand? Pe intregul ciclu de viata al sistemului, trebuie sa existe o echipa de management facuta din sefi de proiecte, un reprezentant al managementului superior, unul sau mai multi utilizatori si, probabil, un administrator de baze de date (daca in echipa nimeni nu are experienta in administrarea bazelor de date). Aceasta mica echipa de management va controla procesul CADM si fie va realiza toate sarcinile de revizuire, fie le va delega persoanelor potrivite. Procesul de revizuire si asigurare a calitatii este critic pentru succesul procesului CADM si trebuie sa fie gestionat de cea mai talentata persoana disponibila. Bineinteles, un principiu cheie este ca nimeni nu-si poate face revizuirea calitatii pentru propriul sau lucru.

Pe masura ce progresati prin fiecare faza a proiectului, veti evea din ce in ce mai multe griji in legatura cu schimbarile din fazele anterioare. In faze de analiza, va veti teme numai de schimbarile din faze de strategie in timp ce in faze de proiectare, trebuie sa aveti grija la schimbarile in cerintele sislemului si schimbarile de stop din faze de strategie. In fiecare faze, vom identifica toate produsele majore din fazele anterioare si discuta impactul schimbarilor asupra oricaruia din aceste produse. Ideal, aceasta informatie ar trebui sa fie afisata intr-o matrice mare cu toate produsele aliniate pe o axa si toate fazele pe cealalta pentru a vedea clar impactul schimbarilor fiecarui produs in fiecare faza.

Sistemele nu sunt ca lucrarile de arta care odata terminate sunt afisate intr-o galerie. Sunt structuri ce vor evolua inerent si, inevitabil, vor necesita schimbari si versiuni ulterioare. Nu orice cerinta trebuie sa fie inclusa in Versiunea 1. Esfe mult mai bine sa aveti un sistem adecvat care sa ruleze decal un sistem pertect care nu va fi terminal niciodata.

70. Cumpararea unui produs si adaptarea lui... mult

Singurul mod in care o implementare a unui produs comercial poate sa aiba succes este de a decide ca activitatea trebuie sa fie regandita astfel incat sa corespunda limitarilor pachetului cumparat. Aceste pachete implica de obicei o anumita metoda de activitate cu un set corespunzator de posibilitati. Trebuie sa fie luata o decizie manageriala ca orice face pachetul este suficient de bun si ca adaptarea nu este o optiune.

Daca nu uitati acest principiu, implementarea unui pachet cumparat nu este mai ieftina sau mai putin riscanta decat construirea unui sistem nou. Am auzit mai multe povesti de groaza cu privire la implementari de sisteme ERP (Enterprise Resourse Planning-Planificarea Resurselor Intreprinderii) decat pentru orice alt tip de proiect de sistem.

De curand, am zburat cu un manager care isi povestea propria poveste de groaza. Firma sa este un producator ce castiga 30.000.000 $ pe an. Acum doi ani au cumparat un sistem ERP mare, bine cunoscut. Proiectul trebuia sa se desfasoare pe doi ani cu un buget de 2.000.000$. Dupa doi ani si 4.000.000 $ proiectul este terminat cam 10-15%.

Concluzii

Pentru a asigura succesul unui sistem, trebuie sa luati in considerare cativa factori:

In ingineria software nu se da masa gratis. Data insistati sa mentineti costuri mici si sa grabiti proiectul, calitatea va fi scazuta sau riscul de esec va fi mare indiferent cat de bine este condus proiectul.

Despre Autor

Dr. Paul Dorsey ([email protected]) este fondatorul si presedintele frmei Dulcian, Inc. (www.dulcian.com) - firma de consultanta Oracle specializata in data warehouse, dezvoltare de sisteme pe web si client-server, si produse pentru mediul Oracle. Paul este coautor cu Peter Koletzke al cartilor "Oracle Designer Handbook" si "Oracle Developer Forms and Reports: Advanced Techniques and Development Standards" si cu Joseph Hudicka al cartii "Oracle8 Design Using UML Object Modeling". Paul este editor executiv al revistei Select si este presedintele Grupului de Utilizatori Oracle din New York (NYOUG).