Dezvoltarea sistemelor și tehnologii noi

Modelul cascadă parcurge etapele, precum o cascadă, de la amonte spre aval, fixând livrabilul fiecărei etape înainte de a trece la următoarea. Construirea prin iterații scurte este dezvoltarea agilă, fixarea cerințelor cu ajutorul unui prototip este modelul de prototipare, iar combinarea serviciilor existente descrie mashup-ul.

Modelul de prototipare urmărește ca, prin crearea timpurie a unui prototip pe care utilizatorii îl pot încerca, să se elimine din primele etape ambiguitățile cerințelor și decalajele de percepție dintre client și dezvoltator. Nu urmărește reducerea numărului de linii de cod și nu realizează omiterea testării sau eliminarea mentenanței.

Dezvoltarea agilă este o abordare care acumulează software funcțional la fiecare iterație scurtă, adaptându-se flexibil, cu premisa modificării specificațiilor; Scrum și XP sunt metodele reprezentative. Fixarea tuturor cerințelor înainte de dezvoltarea unitară, începerea abia după finalizarea documentației sau implicarea utilizatorului doar la final se apropie de modul de lucru al modelului cascadă și nu sunt caracteristici ale abordării agile.

Sprintul este perioada fixă și scurtă care constituie unitatea de dezvoltare în metoda Scrum, în care se repetă ciclul de planificare pe perioadă, dezvoltare, obținerea unui software funcțional și retrospectivă. Nu este termenul folosit pentru etapa de definire a cerințelor sau pentru perioada testului de acceptare și nu este nici doar perioada corectării erorilor.

Deoarece modelul cascadă avansează cu premisa că nu se revine în urmă, atunci când o eroare de cerințe sau de proiectare este descoperită într-o etapă din aval precum testarea, costul revenirii la amonte pentru refacere este foarte mare. Fiindcă fiecare etapă fixează livrabile precum specificațiile și documentele de proiectare, urmărirea progresului este de fapt un punct forte, iar modelul este potrivit pentru dezvoltări la scară mare. Nici documentarea cerințelor nu este imposibilă.

Modelul incremental împarte sistemul pe unități funcționale și acumulează treptat dezvoltarea și lansarea, având, alături de dezvoltarea iterativă, avantajul de a permite utilizarea unor funcții încă din primele etape. Modelul cascadă dezvoltă totul dintr-o dată, în ordine, metoda de analiză structurată este o metodă de analiză bazată pe DFD, iar mashup-ul este combinarea unor servicii existente — niciunul nu corespunde.

Ordinea de bază a dezvoltării începe cu analiza cerințelor, care structurează cerințele utilizatorului, urmată de proiectarea externă (partea vizibilă utilizatorului), proiectarea internă (modul de realizare internă), programare și testare. O ordine care face proiectarea înaintea analizei cerințelor sau care plasează testarea înaintea programării nu este posibilă având în vedere dependențele dintre livrabile.

Proiectarea externă stabilește specificațiile ecranelor, ale rapoartelor și interfețele cu alte sisteme — părțile vizibile utilizatorului sau exteriorului. Stabilirea algoritmilor interni sau a modului fizic de stocare aparține proiectării interne/proiectării programului, iar verificarea funcționării unui modul izolat este o activitate de testare unitară.

Testarea unitară este prima etapă a procesului de testare, prin care se verifică, la nivel de modul, dacă acesta funcționează conform proiectării detaliate. Combinarea modulelor pentru a verifica interfața este testarea de integrare, decizia de recepție luată de client este testul de acceptare, iar verificarea performanței sub sarcină ridicată este testul de sarcină/performanță.

Testarea se acumulează pornind de la cea mai mică unitate: mai întâi testul unitar pentru fiecare modul, apoi testul de integrare care combină modulele, testul de sistem care verifică întregul sistem și, la final, testul de acceptare efectuat de client/utilizatori. O ordine în care verificarea de ansamblu sau recepția are loc mai întâi nu este rațională, întrucât ar însemna efectuarea testelor superioare cu defecte încă prezente în componente.

Testul de acceptare este etapa finală de testare, în care sistemul livrat este verificat de client/utilizatori din perspectiva activității, iar aceștia decid dacă acceptă recepția. Verificarea logicii interne revine testului unitar (test cutie albă) efectuat de dezvoltator, verificarea fără executare este testul static, iar verificarea conectării dintre module este testul de integrare — niciuna nu descrie testul de acceptare.

Testul cutie neagră tratează interiorul programului ca pe o „cutie neagră” și verifică doar dacă relația dintre intrare și ieșire corespunde specificației. Testul cutie albă este o tehnică ce urmărește acoperirea ramurilor și a traseelor interne, testul static este o metodă de verificare prin revizuire fără executarea programului, iar testul de regresie verifică dacă o corecție nu a stricat alte funcționalități.

Aplicarea unei sarcini ridicate, precum accesări simultane numeroase sau un volum mare de date, pentru a verifica dacă sistemul rezistă și dacă performanța se menține, este testul de sarcină, efectuat în etapa testului de sistem alături de testul de performanță, care verifică timpul de răspuns. Testul unitar verifică la nivel de modul, testul static este o verificare fără executare, iar testul cutie albă este o tehnică axată pe structura internă.

Caietul de sarcini este documentul care, ca rezultat al analizei cerințelor, reunește funcțiile, performanțele și constrângerile pe care trebuie să le îndeplinească sistemul și asupra căruia convin clientul și dezvoltatorul; el devine reperul pentru proiectarea, testarea și recepția ulterioare. Manualul de utilizare este documentul destinat modului de folosire de către utilizatori, raportul testului unitar este înregistrarea rezultatelor de testare, iar diagrama de configurație a rețelei este o schemă de proiectare a configurației — niciunul nu este documentul-reper al acordului.

WBS este o metodă care descompune ierarhic livrabilele proiectului și activitățile necesare acestora, prevenind omisiunile de activități și clarificând unitățile pentru estimare și alocarea responsabililor. Reprezentarea programului prin bare orizontale este diagrama Gantt, gestionarea pe baza valorii realizate este EVM, iar evaluarea riscurilor este analiza de risc.

Diagrama Gantt reprezintă prin bare orizontale începutul și sfârșitul planificat al fiecărei activități și este larg folosită pentru vizualizarea programului și a progresului. Diagrama fluxului de date arată circulația datelor, diagrama E-R relațiile dintre entități, iar diagrama cazurilor de utilizare interacțiunea dintre sistem și utilizatori — niciuna nu este o diagramă de gestionare a programului.

Există două trasee: A→B→D→F (3+5+4+2=14 zile) și A→C→E→F (3+4+6+2=15 zile); cum F trebuie să aștepte finalizarea ambelor trasee, durata minimă totală este cea mai lungă, adică 15 zile. Acest traseu cel mai lung, A→C→E→F, este drumul critic. 14 zile este valoarea obținută luând în calcul doar traseul A→B→D→F, iar 12 și 13 zile nu corespund sumei niciunui traseu.

Există trei trasee: A→B→D→F (2+4+3+1=10 zile), A→C→D→F (2+6+3+1=12 zile) și A→C→E→F (2+6+4+1=13 zile); cel mai lung, A→C→E→F = 13 zile, este drumul critic. 10 și 12 zile reprezintă suma altor trasee, iar 14 zile nu corespunde niciunui traseu. O întârziere a activităților de pe drumul critic (A, C, E, F) devine direct o întârziere a întregului proiect.

Metoda punctelor de funcție evaluează numeric numărul și complexitatea funcțiilor precum intrările/ieșirile, interogările și fișierele interne, pentru a estima dimensiunea software-ului, permițând o estimare încă din primele etape ale dezvoltării, independent de numărul de linii de program. LOC este un alt indicator de estimare bazat pe numărul de linii, metoda Delphi obține convergența opiniilor experților prin chestionare repetate, iar metoda KJ este o tehnică de generare de idei prin organizarea și gruparea informațiilor pe fișe.

Managementul riscului avansează astfel: mai întâi identificarea riscului, care le inventariază, apoi analiza riscului (calitativă/cantitativă), care evaluează probabilitatea de apariție și impactul, urmată de planul de răspuns la risc, care stabilește măsurile, și, în cursul execuției, monitorizarea și controlul riscului, care urmăresc situația. O ordine în care planul de răspuns sau monitorizarea preced identificarea nu este posibilă, întrucât riscul vizat nu este încă stabilit.

Modificarea specificațiilor urmează procedura de management al schimbărilor, iar comitetul de control al schimbărilor (CCB) decide aprobarea sau respingerea, după evaluarea impactului asupra programului, costului și calității. Acceptarea necondiționată provoacă întârzieri de livrare și scăderea calității, respingerea totală pierde chiar și modificările necesare, iar corectarea pe loc de către responsabil, fără procedură, creează neconcordanțe cu configurația și documentația, ducând la pierderea controlului.

Părțile interesate (stakeholder) desemnează, generic, persoanele fizice sau organizațiile — clientul, utilizatorii, dezvoltatorii, conducerea etc. — care au un interes legat de rezultatul proiectului; identificarea și armonizarea așteptărilor lor este o activitate importantă de management de proiect. Diagrama programului este diagrama Gantt, descompunerea ierarhică a activităților este WBS, iar lista riscurilor corespunde registrului de riscuri.

SLA este acordul prin care furnizorul și utilizatorul unui serviciu convin asupra nivelului calității serviciului — rata de disponibilitate, timpul de recuperare în caz de incident, intervalul orar de suport etc. —, devenind reperul de evaluare al serviciului de exploatare. Protejarea dreptului de autor este contractul de licență, diagrama de descompunere a activităților este WBS, iar închirierea echipamentelor este contractul de leasing — niciunul nu este SLA.

ITIL (Information Technology Infrastructure Library) este un ansamblu de documente care sistematizează cele mai bune practici privind managementul exploatării serviciilor IT, fiind larg folosit ca un cadru de management al serviciilor care acoperă managementul incidentelor, managementul schimbărilor, serviciul de asistență (service desk) etc. Standardul unui limbaj de programare, teoria normalizării și standardul rețelelor fără fir aparțin altor domenii.

Rata de disponibilitate se calculează ca MTBF÷(MTBF+MTTR). 570÷(570+30)=570÷600=0,95. MTBF este timpul mediu de funcționare de la o defecțiune la următoarea, iar MTTR este timpul mediu necesar reparației. 0,90 și 0,98 nu corespund unei inversări a numărătorului și numitorului, iar nici 0,93 nu se potrivește calculului.

Managementul capacității este activitatea de management prin care se prognozează consumul viitor — volumul de date, numărul de accesări etc. — și se asigură, respectiv se extinde planificat, capacitatea serverelor, a stocării și a rețelei, prevenind astfel scăderea performanței sau insuficiența capacității. Sistemul de contact în caz de incident ține de managementul incidentelor/intervenția de urgență, gestionarea parolelor de administrarea utilizatorilor, iar gestionarea numărului de licențe de managementul resurselor software.

Virtualizarea serverelor este tehnologia prin care, cu ajutorul unui software de virtualizare, mai multe mașini virtuale rulează pe un singur server fizic, obținându-se o mai bună eficiență a utilizării resurselor prin consolidarea serverelor, precum și flexibilitate în modificarea configurației și în recuperare. Amplasarea fizică distribuită sau miniaturizarea carcasei țin de hardware, iar păstrarea pe hârtie nu are legătură cu virtualizarea.

SaaS (Software as a Service) este forma prin care aplicația în sine este furnizată ca serviciu prin rețea, utilizatorul putând-o folosi fără a o instala. IaaS furnizează infrastructura precum serverele, PaaS furnizează chiar mediul de execuție al aplicațiilor, iar on-premise este exploatarea cu echipamente deținute în organizația proprie — nu o formă de furnizare cloud.

Societatea 5.0 este un concept care urmărește o societate în care, prin IoT și alte tehnologii, datele din lumea reală sunt colectate și analizate în spațiul cibernetic, iar rezultatul este redat lumii reale — o fuziune la nivel înalt a spațiului cibernetic cu cel fizic, care îmbină dezvoltarea economică cu rezolvarea problemelor sociale. Suprapunerea informației peste realitate este realitatea augmentată (AR), împărțirea calculelor este procesarea distribuită, iar ansamblul de cunoștințe de management de proiect este PMBOK.

Învățarea supravegheată este metoda prin care, folosind date însoțite de o etichetă cu răspunsul corect, se antrenează un model care prezice răspunsul corect pornind de la intrare, fiind folosită pentru clasificarea imaginilor sau predicția valorilor numerice. Descoperirea structurii sau a grupării datelor fără a furniza răspunsul corect este învățarea nesupravegheată. Instruirea persoanelor nu este învățare automată, iar generarea unei ieșiri aleatorii prin numere aleatoare nu are legătură cu învățarea.