Procese software

- introducere -

Proces software

“Because software, like all capital, is embodied knowledge, and because that knowledge is initially dispersed, tacit, latent, and incomplete in large measure, software development is a social learning process. The process is a dialogue in which the knowledge that must become the software is brought together and embodied in the software. The process provides interaction between users anddesigners, between users and evolving tools, and between designers and evolving tools [technology]. It is an iterative process in which the evolving tool itself serves as the medium for communication, with each new round of the dialogue eliciting more useful knowledge from the people involved.”

Howard Baetjer, Jr.

Ce este procesul software?O “hartă” a drumului ce trebuie urmat pentru construirea unui produs sau sistem, de calitate crescută şi într-un timp dat.

Cine face procesul software?Inginerii de sistem (software engineers) şi managerii lor; sunt implicaţi şi cei cărora li se adresează.

De ce este important procesul software?Deoarece dovedeşte stabilitate, control şi organizare.

Care sunt paşii?Depind de software-ul pe care îl construim.

Care este produsul muncii?În ochii inginerului de sistem produsul este format din programe,documentaţie şi datele produse ca urmare a activităţii de inginerie software definită de proces.

Proces software – o tehnologie pe nivele

IEEE defineşte astfel Ingineria software: (1)Aplicarea unei abordări sistematice, disciplinate, cuantificabile

asupra dezvoltării, punerii în funcţiune şi mentenanţei software-ului(2)Studiul abordărilor de la (1).

Nivelul Proces: defineşte un cadru pentru o mulţime de zone cheie de proces (key process areas). Aceste zone formează baza controlului managementului proiectului software şi stabileşte contextul în care sunt aplicate metodele tehnice, sunt obţinute produsele muncii (modele, documente, date, rapoarte, forme etc.), sunt stabilite “pietrele de hotar”(milestones), e asigurată calitatea şi se administrează potrivit schimbările.

Nivelul Metode: răspunde la întrebarea : Cum construim software-ul? şi cuprinde un spectru larg de sarcini, care includ: analiza cerinţelor, designul, construirea programului şi testarea. Metodele de inginerie software includ activităţi de modelare şi alte tehnici descriptive.

Nivelul Instrumente: furnizează suport automat pentru proces şi metode. Când instrumentele sunt integrate, astfel încât informaţiile create de un instrument să fie folosite de altul, se creează CASE (Computer Aided Software Engineering), care combină software, hardware şi o bază de date a ingineriei software (ce conţine informaţii importante despre analiză, design, construcţia programului şi testare).

Modele de procese software

1) Modelul secvenţial liniar

2) Modelul prototipului (prototyping model)

3) Modelul RAD

4) Modele pentru procese software evolutive

a) Modelul incremental

b) Modelul spirală

c) Modelul spiral WINWIN

d) Modelul de dezvoltare concurentă

1) Modelul secvenţial liniar (cascadă)

Presupune activităţile:

i) Ingineria de sistem şi modelarea: stabilirea cerinţelor pentru elementele sistemului

ii) Analiza cerinţelor software: trebuie înţelese comportarea software-ului, interfaţa, performanţele dorite etc.

iii) Design: e de fapt un proces în mai mulţi paşi, ce se concentrează pe : structura datelor, arhitectura software-ului, reprezentarea interfeţei şi detaliul procedural (algoritmic).

iv) Generarea codului: care translatează design-ul în program.

v) Testarea: depistarea eventualelor erori (errors), defecte (faults) şi eşecuri (failures)

Obs. Modelul cascadă e cel mai vechi; apar însă problemele:• Proiectele reale urmează rar acest model• E foarte dificil pentru client să stabilească cu exactitate cerinţele• O versiune care să poate fi prezentată poate veni după mult timp

• Natura liniară a modelului poate conduce la stări de blocaj, când o echipă implicată în proiect este nevoită să aştepte rezultatele altor echipe

Obs. Modelul secvenţial liniar e cunoscut în literatură sub denumirea classic life cycle.

2) Modelul prototipului

Adesea, un client defineşte o serie de obiective pentru software, dar nu identifică în detaliu cerinţele de input, de procesare sau de ieşire. În alte cazuri, dezvoltatorul poate să aibă îndolieli cu privire la eficienţa algoritmului, adaptabilitatea la un SO sau la forma de interacţiune om/calculator. Pentru aceste e indicat acest model.

Clientul şi dezvoltatorul se întâlnesc pentru a stabili obiectivele de ansamblu şi a identifica oricare dintre cerinţele care sunt cunoscute şi a stabili zonele unde e obligatorie definirea lor ulterioară.

Se conturează astfel un “quick design”, care se axează pe reprezentarea acelor aspecte ale software-ului care care sunt vizibile clientului (ex: ce anume se aşteaptă la input şi formatul output-ului).

Apare un prototip. Prototipul e evaluat de client şi folosit pentru a rafina cerinţele.

Apare iteraţia, care pune în acord cerinţele clientului cu proiectul şi ajută pe dezvoltator să înţeleagă mai bine ce se doreşte.

Ce facem cu prototipul dacă îndeplineşte condiţiile?

“In most projects, the first system built is barely usable. It may be too slow, too big, awkward in use or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved . . . When a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers . . .” (Brooks, F., The Mythical Man-Month, Addison-Wesley, 1975.)

Concluzie. Deşi pot apărea probleme, modelul prototipului poate fi paradigma eficientă pentru ingineria software.

3) Modelul RAD

Rapid application development (RAD) e un model de proces de dezvoltare software incrementală, care pune accentul pe ciclul de dezvoltare extrem de scurt.

Modelul RAD e o adaptare “high-speed” a modelului secvenţial liniar.

Modelul RAD cuprinde următoarele etape:

i) Business modeling. Fluxul informaţiilor printre funcţiile business e modelat într-un mod ce răspunde la întrebările:

• Ce informaţii conduc procesul de business?• Ce informaţii sunt generate?• Cine le generează?• Unde se duc informaţiile?• Cine le procesează?

ii) Data modeling. Fluxul informaţiilor ca parte a etapei de business modeling sunt rafinate într-o mulţime de obiecte de date necesare pentru a susţine business-ul.

iii) Process modeling. Obiectele de date obţinute în etapa anterioară sunt transformate pentru a obţine fluxul de informaţii necesar pentru a implementa o funcţie business. Descrierile de proces sunt create pentru adăugarea, modificarea, ştergerea şi găsirea unui obiect de date.

iv) Generarea aplicaţiei. RAD presupune folosirea 4GT (fourth generation technique). Procesul RAD lucrează pentru a refolosi componentele existente ale programului (unde se poate) sau pentru a crea componente reutilizabile.

v) Testarea şi predarea. Deoarece RAD încurajează reutilizarea componentelor, multe dintre ele sunt deja testate, aşa încât timpul total de testare este redus considerabil. Totuşi noile componente trebuie testate şi toate interfeţele trebuie atent verificate.

Fiecare funcţie majoră e acoperită separat de o echipă şi apoi e integrată în întreg.

Concluzii

• Pentru proiecte mari, dar scalabile, RAD necesită resurse umane importante pentru a crea numărul corect de echipe RAD.

• RAD necesită dezvoltatori şi clienţi care se obligă la activităţi rapide necesare pentru a obţine un sistem complet într-un timp redus

• Nu toate aplicaţiile sunt potrivite pentru RAD. Dacă un sistem nu poate fi modularizat, construirea componentelor necesare pentru RAD devine problematică.

• RAD nu e potrivit când riscurile tehnice sunt mari. Acest lucru apare când o nouă aplicaţie foloseşte intens o nouă tehnologie sau când un software nou cere un grad înalt de interoperabilitate cu programele existente.

Business modelingScopul business process engineering (BPE) este să definească arhitectura ce va permite business să utilizeze eficient informaţiile.

Se analizează şi se specifică design-ul pentru

Arhitectura datelorArhitectura aplicaţiilorInfrastructura tehnologică

1) Arhitectura datelor are ca blocuri constitutive obiectele de date (data object). Un obiect de date conţine o mulţime de atribute care descriu un anumit aspect, calitate, caracteristică a datelor ce sunt descrise.

Exemplu: obiectul Customer

O relaţie (relationship) indică cum sunt conectate obiectele unul cu altul. Exemplu: pentru obiectele Customer şi produsA, o relaţie poate fi cumpără.

2) Arhitectura aplicaţiei cuprinde acele elemente ale sistemului care transformă obiectele în cadrul arhitecturii datelor pentru un anumit scop de business.

3) Infrastructura tehnologică asigură fundaţia pentru arhitecturile datelor şi aplicaţiei. Cuprinde hardware-ul şi software-ul care sunt folosite: computere, SO, reţele, legături de telecomunicaţii, tehnologii de stocare şi arhitectura (ex: client – server).

Pentru a modela arhitecturile descrise, se defineşte o ierarhie a activităţilor ingineriei proceselor business.

World view e obţinută prin Information strategy planning (ISP). ISP vede întreg întregul business ca o entitate şi izolează domeniile business-ului (ex: inginerie, manufacturare, marketing etc.). ISP defineşte obiectele de date care sunt vizibile la nivelul întreprinderii şi relaţiile dintre ele .

Domain view se obţine cu o activitate a BPE numită business area analysis (BAA), care identifică în detaliu datele (sub forma tipurilor entităţilor, adică a obiectelor de date) şi cerinţele funcţiilor (sub forma proceselor) ale domeniilor de business în timpul ISP şi stabileşte interacţiunile dintre ele.

Odată un information system izolat, BPE face o tranziţie spre ingineria software. Invocând pasul business system design (BSD), sunt modelate cerinţele de bază ale unui information system şi aceste cerinţe sunt translatate în arhitectură de date şi de aplicaţie şi infrastructură tehnologică.

Data modeling

Răspunde la un set de întrebări specifice:

• Care sunt obiectele de date primare procesate iniţial de sistem?• Care e compoziţia fiecărui obiect de date şi ce atribute descriu obiectul?• Unde “stau” în mod curent obiectele?• Care sunt relaţiile dintre obiecte?• Care sunt relaţiile dintre obiecte şi procesele care le transformă?

Apelează la diagrama relaţiilor dintre entităţi (ERD – Entity Relationship Diagram)

4GT (Fourth Generation Techniques)Termenul 4GT cuprinde o gamă largă de instrumente software care au un lucru în comun: fiecare permite inginerului software să specifice anumite caracteristici ale software-ului la un nivel înalt. Instrumentul (tool) generează apoi automat cod sursă bazat pe specificaţiile dezvoltatorului.

Paradigma 4GT pentru ingineria software pune accentul pe abilitatea de a specifica software folosind forme de limbaj specializat sau notaţii grafice ce descriu problema propusă spre rezolvare în termeni pe care clientul poate să-i înţeleagă.

În mod curent, un mediu de dezvoltare software ce suportă paradigma 4GT include o parte dintre următoarele instrumente (tools): • limbaje neprocedurale pentru interogările bazei de date;• capabilităţi grafice de nivel înalt;• capabilităţi de tip spreadsheet;• generare automată a HTML şi a limbajelor similare folosite pentru crearea site-urilor Web utilizând instrumente software avansate.

4GT (Fourth Generation Techniques) (continuare)

Concluzii privind paradigma 4GT:1) Folosirea 4GT e o abordare viabilă pentru multe zone de aplicaţii. Combinată cu alte instrumente CASE şi generatoare de cod, 4GT reprezintă o soluţie de încredere pentru multe probleme software.

2) Folosind 4GT, timpul necesar pentru producerea software-ului e mult redus pentru aplicaţii mici şi mijlocii şi de asemenea efortul pentru design şi analiză pentru aplicaţiile mult e mult redus..

3) Folosirea 4GT pentru dezvoltarea unui software complex necesită la fel de multă sau chiar mai multă muncă pentru analiză, design şi testări, în ciuda timpului salvat obţinut din eliminarea codului.

4) Modele pentru procese software evolutive: sunt iterative, adică permit dezvoltarea crescătoare a unor versiuni din ce în ce mai complete ale software-ului.a) Modelul incremental: combină elemente ale modelului cascadă (aplicat repetat) cu filozofia iterativă a modelului prototipului.

Fiecare secvenţă liniară produce un “increment” livrabil al software-ului.

Exemplu : Software pentru editor de texte, poate livra managementul de bază al fişierelor şi editarea la primul increment; editare mai sofisticată la al doilea increment; spelling şi verificare gramaticală în al treilea increment şi capabilităţi avansate de proiectare a paginii la al patrulea increment.

Obs. Primul increment e adesea un miez al produsului (core product), adică cerinţele de bază sunt îndeplinite, dar mai multe capabilităţi (unele cunoscute, altele necunoscute) rămân nepredate.Acest core product e folosit de client. Ca rezultat al utilizării sau al evaluării, se dezvoltă un plan pentru următorul increment, care stabileşte modificarea core product-ului pentru îndeplinirea mai bună a cerinţelor clientului şi furnizarea funcţionalităţilor adiţionale. Acest proces e repetat după livrarea fiecărui increment, până se conturează întregul produs.Concluzii.• Modelul incremental e iterativ (ca şi modelul prototipului), dar se concentrează pe livrarea unui produs operaţional la fiecare increment. Versiunile iniţiale nu se regăsesc în produsul final, dar furnizează capabilităţi nesecare utilizatorului.• Modelul incremental e util când echipa de dezvoltatori nu e disponibilă toată perioada. Core product-ul poate fi realizat cu mai puţini oameni.

b) Modelul spirală: combină natura prototipului cu aspectele sistematice controlate ale modelului cascadă. Software-ul e dezvoltat într-o serie de livrări incrementale. În timpul primelor iterări, livrarea poate fi un model pe hârtie sau un prototip. În timpul iterărilor ulterioare, sunt produse versiuni don ce în ce mai complexea sistemului.

Sunt între 3 şi 6 task regions într-un proiect tipic.

Cele 6 regiuni reprezentate în figură sunt:

• Comunicarea cu clientul: tasks pentru stabilirea unei comunicări efective între dezvoltator şi client

• Planificarea: tasks pentru definirea resurselor, a planificărilor temporale şi a altor informaţii în legătură cu proiectul

• Analiza riscurilor: tasks pentru stabilirea în egală măsură a riscurilor ehnice şi manageriale

• Tehnologia (engineering): tasks pentru construirea uneia sau a mai multor reprezentări ale aplicaţiei

• Construirea şi livrarea: tasks pentru construirea, testarea, instalarea şi asigurarea suportului utilizatorului (ex: documentaţie şi training)

• Evaluarea clientului: tasks pentru obţinerea unui feed-back din partea clientului, bazat pe evaluarea reprezentărilor software create în timpul etapei de engineering şi implementate în timpul etapei de instalare

Echipa de dezvoltatori se mişcă în spirală în sensul acelor de ceasornic, începând din centru.

Primul circuit în jurul spiralei ajută la dezvoltarea specificaţiilor produsului.

Următoarele circuite ajută la dezvoltarea prototipului şi apoi, progresiv, la versiuni mai sofisticate ale software-ului.

Fiecare trecere prin dreptul zonei de planificare (planning region) produce rezultate în ajustarea planului proiectului.

Costul şi planificarea temporală sunt ajustate pe baza feedback-ului derivat din evaluarea clientului.

Managerul proiectului ajustează numărul de iteraţii necesare pentru a completa software-ul.

Obs. Spre deosebire de modelele clasice, care se termină cu livrarea software-ului, modelul spirală poate fi adaptat pentru a fi folosit pe întreaga durată de viaţă a software-ului.

O privire alternativă asupra modelului spirală se obţine examinând axele punctelor de intrare în proiect (project entry point axis).

Fiecare cub plasat de-a lungul axelor poate fi utilizat pentru a reprezenta punctul de plecare pentru diferite tipuri de proiect.Un “concept development project” porneşte de la miezul spiralei şi continuă până ce devine completă dezvoltarea conceptului.

Concluzii

• Modelul spirală e o abordare potrivită pentru sistemele de maridimensiuni.• Modelul spirală foloseşte prototipul ca un mecanism de reducere a riscurilor dar, mai important, permite dezvoltatorului să aplice abordarea prototipului la orice etapă din evoluţia proiectului.

• Modelul spirală menţine abordarea sugerată de ciclul de viaţă clasic, dar o incorporează într-un cadru iterativ care reflectă mai realist lumea.

• Modelul spirală cere luarea în calcul a riscurilor tehnice în toate etapele proiectului şi, dacă se aplică corect, ar trebui să reducă riscurile înainte să devină problematice.

• Modelul spirală nu este folosit aşa cum se folosesc modelul liniar secvenţial şi modelul prototipului.

c) Modelul WINWIN

“Eliciting software requirements demands negociation. Successful negotiation occurs when both sides « win ».”

Stakeholder = cineva din organizaţie care are un interes de afaceri direct în construirea sistemului sau produsului şi care va fi recompensat pentru succes şi criticat pentru un eşec.

Modelul spiral al lui Boehm (Boehm, B., “Using the WINWIN Spiral Model: A Case Study,” Computer, vol. 31, no. 7, July 1998, pp. 33–44) defineşte o serie de activităţi de negociere la începutul fiecărei treceri în jurul spiralei:

1. Identificarea stakeholders ai sistemului sau subsistemului.

2. Determinarea condiţiilor de câştig (“win conditions”) ale stakeholders.

3. Negocierea acestor condiţii pentru a le reconcilia într-un set de condiţii win-win pentru toţi cei implicaţi (inclusiv pentru echipa proiectului software).

În afară de cele 3 activităţi de negociere menţionate, modelul spirală mai introduce 3 anchor points:• Life cycle objectives (LCO): defineşte un set de obiective pentru

fiecare activitate majoră de inginerie software.• Life cycle architecture (LCA): defineşte obiectivele de trebuie

îndeplinite când se defineşte arhitectura software-ului.• Initial operational capability (IOC): defineşte obiective în legătură cu

pregătirea pentru instalarea / distribuirea software-ului şi asistenţă.

d) Modelul de dezvoltare concurentă (numit şi concurrent engineering)“Most software development process models are driven by time; the later it is, the later in the development process you are. A concurrent process model is driven by user needs, management decisions, and review results.” (Davis, A., P. Sitaram, 1994)

Modelul concurent se foloseşte ca paradigmă pentru dezvoltarea aplicaţiilor client-server.

Toate activităţile există concurent, dar se găsesc în diferite stări.