UNITATE - VI

Organizatii de Proiect si Responsabilitati: Organizatii pe Linia de Afaceri, Organizatii de Proiect,

evoluț ia Organizaț iilor.
Automatizarea proceselor: Blocuri de construcț ie pentru automatizare, Mediul de proiect.

Organizaț ii ș i responsabilităț i ale proiectului:

Organiza ț iile implicate în software-ul Liniei de Afaceri trebuie să sprijine proiectele cu
infrastructura necesară pentru a utiliza un proces comun.
Organizaț iile de proiect trebuie să aloce artefacte ș i responsabilităț i în cadrul echipei de proiect pentru a asigura o
echilibrulîntre îngrijorările globale (arhitectură) ș i cele locale (componentă).
Organizaț ia trebuie să evolueze odată cu preocupările legate de WBS ș i ciclul de viaț ă.
Echipele de afaceri software ș i echipele de produs au motivaț ii diferite.
liniile de afaceri software sunt motivate de returnarea investiț iei (ROI), afaceri noi
discriminatori, diversificarea pieț ei ș i rentabilitatea.
Echipele de proiect sunt motivate de cost, program ș i calitatea livrabilelor specifice

1) Organizaț ii de Linia de Afaceri:

Principalele caracteristici ale organizaț iei implicite sunt următoarele:
Responsabilitatea pentru definirea și întreținerea procesului este specifică unei linii de afaceri coerente.
Responsabilitatea pentru automatizarea proceselor este un rol organizațional și este egal în importanță cu
rolul de definire a procesului.
Rolul organizațional poate fi îndeplinit de o singură persoană sau de mai multe echipe diferite.

Fig: Roluri implicite într-o organizaț ie de software pentru afaceri.

___________________________________________________________________________________
[Link] 1
 Autoritatea Procesului de Inginerie a Software-ului (SEPA)
SEPA facilitează schimbul de informaț ii ș i îndrumarea procesului atât către, cât ș i dinspre proiect
practicieni
Această funcț ie este responsabilă în faț a Directorului General pentru menț inerea unui statut actual evaluarea
maturitatea procesului organizaț iei ș i planul său pentru îmbunătăț irea viitoare
Autoritatea de Revizuire a Proiectului (PRA)
PRA este persoana unică responsabilă pentru a se asigura că un proiect software este conform cu cerinț ele
cu toate politicile, practicile ș i standardele software-ului organizaț ional ș i ale unităț ii de afaceri

Un Manager de Proiect Software este responsabil pentru îndeplinirea cerinț elor unui contract sau a unor
alte standarde de conformitate a proiectului

Autoritatea pentru Mediul de Inginerie a Software-ului (SEEA)

SEEA este responsabil pentru automatizarea procesului organizaț iei, menț inând
mediu standard al organizaț iei, Proiecte de formare pentru utilizarea mediului ș i întreț inerea acestuia
active reutilizabile la nivel de organizaț ie
Rolul SEEA este necesar pentru a obț ine un ROI semnificativ pentru procesul comun.
Infrastructură
Infrastructura unei organizaț ii oferă suport pentru resurse umane, independent de proiect.
cercetare ș i dezvoltare, ș i alte software-uri de capital active de inginerie.

2) Organizaț iile de proiect:

Gestionarea software-ului
Artefacte Activităț i

Caz de afaceri Interfaț a clientului, interfaț a PRA

Plan de dezvoltare a software-ului Planificare, monitorizare
Evaluări ale statutului Managementul riscurilor

Definiț ia procesului software

Îmbunătăț irea proceselor

Inginerie de sistem Administraț ie

Arhitectura Software Software Development Evaluarea software-ului

Figura 11-2. Organizarea ș i responsabilităț ile implicite ale proiectului

•Imaginea de mai sus arată o organizare implicită a proiectului și mapează rolurile la nivel de proiect.
responsabilităț i.
•Principalele caracteristici ale organizației implicite sunt următoarele:
•Echipa de management al proiectului este un participant activ, responsabil pentru producerea de asemenea

___________________________________________________________________________________
[Link] 2
 ca gestionare.
Echipa de arhitectură este responsabilă pentru artefactele reale și pentru integrarea acestora.
componente, nu doar pentru funcț ii de personal.
•Echipa de dezvoltare deține activitățile de construcție și întreținere a componentelor.
•Echipa de evaluare este separată de dezvoltare.
•Calitatea este implicarea tuturor în toate activitățile și punctele de control.
Fiecare echipă își asumă responsabilitatea pentru o perspectivă diferită asupra calității.

EVOCAȚIA ORGANIZAȚIILOR:
Software Software
Management Management
50% 10%

Software Software Software Software Software Software

Arhitectură Dezvoltare Assessment Arhitectură Dezvoltare Evaluare
20% 20% 10% 50% 20% 20%

Incepț ie Elaborare

Software Software
Management Management
10% 10%

Software Software Software Software Software Software

Arhitectură Dezvoltare Evaluare Arhitectură Dezvoltare Evaluare
5% 35% 50% 10% 50% 30%

Tranziț ie Construcț ie

Iniț ierea Elaborare:

Software management:50% Managementul software-ului: 10%
Arhitectura software: 20% Software Architecture:50%
Dezvoltarea software-ului: 20% Dezvoltare software: 20%
Evaluarea software-ului Evaluarea software-ului
(measurement/evaluation):10% (measurement/evaluation):20%
Construction: Tranziț ie:
Gestionarea software-ului: 10% Gestionarea software-ului: 10%
Arhitectura software: 10% Arhitectura software: 5%
Software development:50% Dezvoltare software: 35%
Evaluarea software-ului Software Assessment
(measurement/evaluation):30% (measurement/evaluation):50%

Automatizarea Proceselor:
Remarci introductive:

___________________________________________________________________________________
[Link] 3
 Mediul trebuie să fie artefactul de primă clasă al procesului.
Automatizarea proceselor ș i managementul schimbărilor sunt esenț iale pentru un proces iterativ. Dacă schimbarea este costisitoare
atunci organizaț ia de dezvoltare va rezista.
Ingineria de tip round-trip ș i mediile integrate promovează libertatea de schimbare ș i evoluț ia efectivă a
artefacte tehnice.
Automatizarea metricilor este crucială pentru controlul eficient al proiectului.
Părț ile externe au nevoie de acces la resursele de mediu pentru a îmbunătăț i interacț iunea cu dezvoltarea
echipă ș i adăugaț i valoare procesului.
Cele trei niveluri de proces care necesită un anumit grad de automatizare a procesului pentru corespunzătoarea
proces care trebuie efectuat eficient.
Metaproces (Linie de afaceri): Suportul pentru automatizare la acest nivel se numeș te infrastructură.
Macroproces (proiect): Suportul de automatizare pentru procesul unui proiect se numeș te mediu.
Microproces (iterare): Suportul pentru automatizarea generării artefactelor este în general numit un instrument.

Unelte: Blocuri de automatizare:

Multe instrumente sunt disponibile pentru a automatiza procesul de dezvoltare a software-ului. Majoritatea software-ului de bază
instrumentele de dezvoltare se mapă strâns pe una dintre fluxurile de lucru ale procesului

Fluxuri de lucru Instrumente de mediu ș i automatizarea proceselor

Management Workflow automation, Metrics automation
Mediu Change Management, Document Automation
Cerinț e Managementul cerinț elor
Design Modelare Vizuală
Implementare -Editors, Compilers, Debugger, Linker, Runtime
Evaluare - Automatizarea testelor, urmărirea defectelor
Desfăș urare defect Tracking

Mediul de proiect:
Artefactele mediului de proiect evoluează prin trei stări discrete.
(1)Prototyping Environment.(2)Development Environment.(3)Maintenance Environment.
___________________________________________________________________________________
[Link] 4
 Mediul Prototype include o platformă de testare a arhitecturii pentru prototiparea arhitecturii proiectului.
evaluaț i compromisurile în timpul fazei de început ș i elaborare a ciclului de viaț ă.
Mediul de dezvoltare ar trebui să includă un set complet de instrumente de dezvoltare necesare pentru a sprijini diverse
Procesează fluxurile de lucru ș i ingineria de întoarcere în cea mai mare măsură posibilă.
Mediul de întreț inere ar trebui să coincide în mod tipic cu versiunea matură a dezvoltării.
Există patru discipline importante de mediu care sunt critice pentru contextul managementului ș i succesul unei
procesul modern de dezvoltare iterativă.
Inginerie inversă
Managementul schimbărilor
Comenzi de Schimbare a Software-ului (SCO)
Baza de configurare Consiliul de control al configurării
Infrastructură
Politica organizaț iei
Mediul organizaț ional
Mediul părț ilor interesate.

Mediu de călătorie dus-întors

Uneltele trebuie să fie integrate pentru a menț ine consistenț a ș i trasabilitatea.
Ingineria Round-Trip este termenul folosit pentru a descrie această cerinț ă cheie pentru medii care susț in
dezvoltare iterativă.
Pe măsură ce industria software-ului trece la menț inerea diferitelor seturi de informaț ii pentru artefactele de inginerie,
este nevoie de mai mult suport pentru automatizare pentru a asigura o tranziț ie eficientă ș i fără erori a datelor dintr-un artefact în altul
altul.
Ingineria de întoarcere este suportul de mediu necesar pentru a men ț ine coeren ț a între
artefacte inginerie.

Managementul schimbării
Managementul schimbării trebuie să fie automatizat ș i impus pentru a gestiona multiple iteraț ii ș i pentru a facilita schimbarea
libertate.
Schimbarea este principiul fundamental al dezvoltării iterative.

___________________________________________________________________________________
[Link] 5
 I. Comenzi de Schimbare a Software-ului
Unitatea atomică de lucru software care este autorizată să creeze, să modifice sau să facă obsolescente componentele în cadrul unei
baseline de configurare se numeș te ordine de schimbare a software-ului (SCO)
Câmpurile de bază ale SCO sunt Titlu, descriere, metrici, rezolvare, evaluare ș i dispoziț ie

Managementul schimbării
II. Configurare de bază
O bază de configurare este o Colec ț ie numită de componente software ș i suport
documentaț ie care este supusă gestionării schimbărilor ș i este actualizată, întreț inută, testată, statii
& obsolesce o unitate
Există în general două clase de linii de bază
Lansare Externă a Produsului
Testare internă Lansare
Trei niveluri de versiuni de bază sunt necesare pentru cele mai multe sisteme

___________________________________________________________________________________
[Link] 6
 1. Versiune majoră (N)
2. Lansare minoră (M)
3. Eliberare provizorie (temporară) (X)
Majorrelease reprezintă o nouă generaț ie a produsului sau proiectului
Un release minor reprezintă acelaș i produs de bază, dar cu caracteristici, performanț ă sau
quality.
Lansările Majore ș i Minore sunt destinate a fi lansări externe de produse care sunt persistente ș i
susț inut pentru o perioadă de timp.
O versiune interimară corespunde unei configuraț ii de dezvoltare care este destinată să fie temporară.
Odată ce software-ul este plasat într-o bază de control, toate modificările sunt urmărite astfel încât trebuie să existe o distincț ie.
a fi realizat pentru cauza schimbării. Categoriile de schimbare sunt
Type 0:Critical Failures (must be fixed before release)
Tip1: O eroare sau defect care fie nu afectează (dăunează) utilitatea sistemului, fie poate fi
s-a descurcat
Tip2: O schimbare care este o îmbunătăț ire mai degrabă decât un răspuns la un defect
Tip3: O schimbare care este necesară din cauza actualizării mediului
Tip4: Schimbări care nu sunt accommodate de celelalte categorii.
Gestionarea schimbărilor
III Consiliul de Control al Configuraț iei (CCB)
Un CCB este o echipă de oameni care funcț ionează ca decizia
Autoritate asupra conț inutului reperele de configurare
Un CCB include:
1. Manageri de software
2. Manageri de arhitectură software
3. Manageri de dezvoltare software
4. Manageri de evaluare a software-ului
5. Alte părț i interesate care sunt esenț iale pentru întreț inerea software-ului controlat
sistem de livrare?
Infrastructură
Infrastructura organizaț iei oferă activele de capital ale organizaț iei, inclusiv două chei
artifacts - Policy & Environment
Politica Organizaț iei:
O politică capturează standardele pentru procesele de dezvoltare a software-ului în proiecte
Politica organizaț iei este de obicei prezentată sub forma unei manuale care defineș te ciclurile de viaț ă ș i
primitivii de procesare, cum ar fi
Puncte importante
Artefacte intermediare
Repositarii de inginerie
Metrice
Roluri ș i responsabilităț i

___________________________________________________________________________________
[Link] 7
 Infrastructură
II Mediul Organizaț iei
Mediul care capturează un inventar de instrumente care sunt blocuri de construcț ie din care se realizează proiectul
mediile pot fi configurate eficient ș i economic

Mediul părț ilor interesate

Multe proiecte de mari dimensiuni includ persoane din organizaț ii externe care reprezintă alț i actori interesaț i
participating in the development process they might include
Monitorii contractelor agenț iei de achiziț ii
Personal de suport pentru inginerie utilizator final
Contractori de întreț inere terț i
Contractori independenț i de verificare ș i validare
Reprezentanț ii agenț iilor de reglementare ș i alț ii.
Aceș ti reprezentanț i ai părț ilor interesate au nevoie, de asemenea, de acces la resurse de dezvoltare, astfel încât să poată
contribuie la efortul general. Aceș ti părț i interesate vor avea acces prin intermediul on-line
Un mediu online accesibil părț ilor interesate externe le permite să participe în
procesul urmează
Acceptaț i ș i folosiț i incrementele executabile pentru evaluarea practică.
Foloseș te aceleaș i instrumente online, date ș i rapoarte pe care organizaț ia de dezvoltare le foloseș te pentru a gestiona ș i
monitorizaț i proiectul
Evitaț i călătoriile excesive, întârzierile de schimb de hârtie, traducerile de format, costurile de expediere pe hârtie ș i
alte costuri indirecte

___________________________________________________________________________________
[Link] 8
___________________________________________________________________________________
[Link] 9