organizarea si planificarea in ingineria sistemelor
DESCRIPTION
-TRANSCRIPT
Organizarea si planificarea in ingineria sistemelor
342A1
Primul pas in managementul proceselor in ingineria sistemelor este de a dezvolta implementarea
anterioara a structurii organizationale care se va baza pe cerintele sistemului.Facand referire la
procesul de analiza,planificarea in ingineria sistemelor incepe cu identificarea nevoilor clientului ,
precum si "definitiile" cerintelor pentru ca un proiect sa poata incepe sa fie
eleborat,dezvoltat,produs si in final sa obtinem un sistem care va fi robust si avand costuri
optime.Desi orice proiect este diferit,planificarea se realizaza cu un plan de management(PMP-
program management plan),sau intr-o forma echivalenta.
Pornind de la nivelul de top al planificarii,planul de management in ingineria sistemelor(SEMP-
systems engineering management plan),sau planul in ingineria sistemelor(SEP-systems
engineering plan) se refera la ghidarea implementarii activitatilor tehnice.
Un SEMP trebuie sa fie pregatit in timpul fazei de design la nivel de concept,ofera suportul
necesar pentru majoritatea planurilor de design necesare pentru proiect.Inclusa in SEMP este
identificarea taskurilor proiectului ,structura proiectului de breakdown(avarii)[WBS-program work
breakdown structure),definirea ordinii taskurilor si costurile de implementare,precum si structura
organizationala necesara dezvoltarii proiectului.
In dezvoltarea unei abordari organizationale,este esential ca un mediu de lucru sa fie stabilit
pentru ca va oferi suport pentru o eficienta sporita si o coordonare si integrare a mai multor
ingineri ,precum si suportul pentru multitudinea de discipline care contribuie la intregul proces de
analiza,dezvoltare,implementare si testare al prdusului final.
De asemenea este necesara stabilirea unei subordonari pe baza de lideri si de manageri pentru a
eficientiza comunicarea intre nivelurile organizationale si pentru a aborda interdisciplinar
dezvoltarea proiectului.
Principalul obiectiv in managementul ingineriei sistemelor este de a facilita integrarea in timp real
a numeroaselor probleme sau constrangeri care trebuie luate in considerare in functionarea unui
sistem care va avea un impact major asupra clientului.
In acest capitol se pune accent pe intelegerea unor planificari de baza in ingineria sistemelor si
necesitatile organizationale pentru un program tipic luand in considerare urmatorii factori:
Necesitatile planificarii programului
Dezvoltarea planului de management-caietul de sarcini, taskurile programului , planificarea
taskurilor,proiectarea si analiza costurilor taskului,interfatarea cu alte activitati de
planificare,etc.
Organizarea pentru ingineria sistemelor-dezvoltarea structurii organizationale,relatiile intre
client,furnizor,producator(managementul de resurse umane)
1. PLANIFICAREA PROGRAMELOR IN INGINERIA SISTEMELOR
Odata nevoia unui nou sistem identificata, planificarea initiala incepe cu pregatirea
managerierii programului (PMP), care, la randul ei , duce la planul de manageriere a ingineriei de
sistem.Aceasta planificare de sistem initiala avansata, duce la o descriere a sarcinilor ce trebuie
indeplinite pentru implementarea sistemului, impreuna cu o planificare practica, necesitati ale
resurselor de program si o abordare organizationala.Aceasta planificare timpurie incepe cu
identificarea necesitatilor manageriale pentru faza de design conceptual, urmata de necesitatile
fazei de design a sistemului preliminar, si asa mai departe.
Cum sistemul evolueaza in faza de design conceptual, necesitatile tehnice ale
sistemului sunt stabilite prin definirea nevoilor operationale, conceptului de intretinere si suport,
identificarea si prioritizarea masurilor de performanta tehnica, analiza functionala, si alocarea
nevoilor de la nivelul sistemului pana la subsistemele majore si elementele sistemului.Aceste
necesitati de la nivelul sistemului sunt apoi incluse intr-o specificatie de sistem (tip A).
Referitor aceste forme de specificatie de nivel inalt reprezinta baza specificatiilor de nivel
inferior (de tip B, C, D si E).
In pregatirea planurilor, dar si a specificatiilor, este important sa se stabileasca relatii
corespunzatoare intre acestea doua si sa se asigure ca documentele planificarii fac referinta la
specificatiile potrivite. Cu alte cuvinte, cele doua zone de activitate trebuie “sa vorbeasca una cu
cealalta” si trebuie sa se sustina reciproc.
2. PLANUL MANAGERIAL AL INGINERIEI DE SISTEM(SEMP)
SEMP este documentul managerial cheie ce acopera toate activitatile, problemele cheie,
organizarea, necesarul cerut de resurse pentru a indeplini functiile/sarcinile discutate de-a lungul
acestui text. Obiectivele SEMP, de obicei dezvoltat in timpul fazei de design conceptual, sunt de a
asigura structura, politicile si procedurile de adoptare a integrarii ingineriei si activitatile suport
pentru designul si dezvoltarea sistemului. SEMP faciliteaza integrarea tuturor planelor de design
orientat si asigura legaturile de comunicare necesare cu alte activitati- cheie de planificare (planul
de manageriere a configuratiei, planul de manageriere a calitatii totale, planul managerierii datelor,
etc.).
In dezvoltarea SEMP, formatul adoptat poate varia in functie de tipul si natura sistemului
cerut, de tinta organizationala ceruta, s.a.m.d.
Pentru orice eveniment, planul trebuie sa fie conceput corespunzator, dupa magnitudinea
sistemului si nivelul efortului anticipat.Partea I include o descriere a nevoilor programului,
declaratia de munca, structura intreruperii lucrului, descrierea sarcinilor ingineriei de sistem,
orarele asociate si proiectii de cost, structura organizationala, si toate functiile manageriale
necesare in ducerea la indeplinire a programului, ca raspuns la obiectivele ingineriei.
Partea a II-a acopera procesele ingineriei de sistem descrise .Scopul este descrierea
procesului care trebuie planificat si indeplinit, sau baza pentru toata planificarea de program si
nevoile manageriale.
Partea a III-a acopera integrarea disciplinelor ingineresti cheie, necesare pentru
implementarea procesului descris in partea a II-a. Aceasta include integrarea activitatilor de
planificare asociate cu ingineria calitatii, ingineria intretinerii , factorii umani si ingineria sigurantei ,
logistica si resursele financiare , si alte discipline ingineresti aplicabile.
Astfel, SEMP include o descriere a nevoilor manageriale pentru un program dat, activitatile
ce necesita atentia, interfetele ce trebuie mantinute si resursele cerute pentru implementarea
programului.
2.1 CAIETUL DE SARCINI (SOW)
Caietul de sarcini este o rescriere narativa a muncii pentru un proiect dat.In ceea ce priveste
SEMP, el trebuie dezvoltat din proiectul complet SOW descris in PMP, si ar trebui sa includa
urmatoarele:
1.O descriere completa a sarcinilor ce trebuie indeplinite.
2.O identificare a nevoilor initiale ale altor sarcini.Acestea pot include rezultate ale altor sarcini
realizate in cadrul proictului, acoperite de client sau realizate de furnizor.
3.Referinte la specificatii aplicabile (care sa includa specificatiile A de sistem), standarde,
proceduri si documente necesare definirii scopului muncii.Aceste referinte ar trebui identificate ca
documentatie cheie in diagrame.
4.O descriere a rezultatelor specifice de trebuie obtinute.Aceasta poate include echipamente
livrabile, software, date de design, rapoarte, sau documenta aditionale, insotite de orarul timpilor
de livrare.
In pregatirea SOW, urmatoarele linii generale sunt de luat in considerare:
1.SOW ar trebui sa fie relativ scurt si la obiect(sa nu depaseasca doua pagini) si trebuie scris intr-
o maniera clara si precisa.
2.Orice efort trebie sa aiba in vedere evitarea ambiguitatilor si a posibilitatii interpretarii gresite de
catre citittor.
3.Descrie necesitatile intr-un detaliu suficient pentru a asigura claritate, luand in consideratie atat
aplicatiile practice cat si interpretarile legale posibile.Nu folosi sub sau supra specificatii.
4.Evita repetitiile inutile si incorporarea materialelor alogene.Aceasta poate duce la costuri inutile.
5.Nu repeta specificatii detaliate si necesitati deja cuprinse in referintele documentelor in vigoare.
SOW va fi citit de persoane cu pregatiri diferite (ingineri, contabili, manageri de contract,
ordonatori de lucrari,avocati) si nu trebuie sa cuprinda intrebari fara raspuns legate de scopul
muncii declarate.Ea reprezinta o baza pentru definirea si costurile sarcinilor detaliate, pentru
stabilirea subcontractorului si a nevoilor furnizorului, s.a.m.d.
2.2 SARCINILE PROGRAMULUI INGINERIEI DE SISTEM
Ingineria de sistem, asa cum apare de-a lungul acestui text, apare un spectru larg de
activitati. Poate chiar parea ca “ingineria de sistem” sau “organizarea ingineriei de sistem” face
totul.Desi nu este intentionat sau practic, indeplinirea obiectivelor ingineriei de sistem impune
implicarea, directa sau indirecta, in aproape fiecare fateta a activitatilor programului.
Provocarea consta in identificarea acelor functii (sau sarcini), care au de-a face cu sistemul privit
ca intreg, si care, odata atins rezultatul final, vor avea un impact pozitiv asupra multor sarcini
subordonate si subiacente ce trebuie indeplinite.Desi difera de la un program la altul, urmatoarele
sarcini au fost identificate acolo unde rolul managerului este esential in cadrul organizarii ingineriei
de sistem(sau unei activitati alternative specifice):
1.Desfasoara o analiza a necesitatilor si creeaza baza unor studii de fezabilitate .
Aceste activitati cad in responsabilitatea organizarii ingineriei de sistem, intrucat ele vizeaza
sistemul ca entitate si sunt fundamentale in interpretarea initiala si definitia subsecventa a
necesitatilor sistemului.
2.Defineste necesitatile operationale ale sistemului si conceptul de intretinere, si identifica si
prioritizeaza masurile de performanta tehnica.
Rezultatele acestor activitati sunt incluse in definirea completa a necesitatilor de la nivelul
sistemului si reprezinta baza design-ului sistemului ca intreg.Se are in vedere studiul
interrelational, necesitand o intelegere comprehensiva a interfetelor sistemului si a obiectivelor
clientului/utilizatorului.
3.Asigura o analiza functionala la nivelul sistemului si aloca necesarul cerut de nivelul consecutiv
inferior.Este esential sa se defineasca o baza functionala, de la care necesarul de resurse
specifice sa poata fi identificat. Aceasta linie de baza serveste ca un cadru comun de referinta
pentru definirea sursei de nevoi pentru multe din activitatile de inginerie si de suport de mai tarziu.
Desi organizarea ingineriei de sistem nu poate realiza o analiza functionala totala, un rol esential il
poate avea managerul in asigurarea unei baze de necesitati la nivelul sistemului.
4.Pregateste specificatiile de sistem, tip A. Acestea reprezinta documentul tehnic de varf pentru
design, si servesc ca baza de dezvoltare pentru toate specificatiile subordonate. Organizarea
ingineriei de sistem ar trebui sa fie responsabila pentru pregatirea acestui document esential, si sa
se asigure de concordanta tuturor specificatiilor subordonate, ca si de suportul mutual.
5.Pregateste testul si planul principal de evaluare. Cum acest document reflecta efortul de validare
a sistemului, organizarea ingineriei de sistem ar trebui sa-si asume rolul conducator in asigurarea
conectivitatii dintre TPM-urile prioritizate, nivelurile de complexitate ale design-ului, riscurile
asociate realizarii design-ului, s.a.m.d.
Cum initial nevoile cantitative specifice sunt definite, trebuie stabilit un plan coerent pentru
validarea acestora. Organizarea ingineriei de sistem trebuie sa asigure un test integrat si un efort
de evaluare, si ca specificatiile de sistem,SEMP, ca si alte planuri de design, “vorbesc” unele cu
altele.
6.Pregateste planul managerial al ingineriei de sistem(SEMP). Cum acest plan constituie
documentul integrat de la nivelul de varf ce asigura realizarea obiectivelor ingineriei de sistem,
trebuie pregatit, revizuit, daca este cazul, si implementat sub conducerea organizarii ingineriei de
sistem.
7.Realizeaza sinteza, analiza si evaluarea. Desi acest domeniu de activitate este continuu si larg
raspandit in cadrul comunitatii designerilor, organizarea ingineriei de sistem trebuie sa aiba o
functie de “supraveghere”, care sa se asigure ca deciziile majore de design de fiecare zi sunt in
acord cu specificatiile sistemului, ca rezultatele studiilor de inter-relatii sunt documentate corect si
ca riscurile de design au fost identificate si adresate corespunzator.
8. Planifica, coordoneaza si condu intalnirile recapitulative privind design-ul formal .Coordonarea
design-ului formal asigura ca procesul ingineriei de sistem este implementat corespunzator; liniile
de baza functionale sunt bine definite;managementul configurarii este implementat si toti memebrii
echipei de design inteleg baza deciziilor trecute si urmaresc aceeasi baza de date pentru
design.Organizarea ingineriei de sistem, sau reprezentantul desemnat, ar trebui sa prezideze
intalnirile de bilant ale design-ului formal.
9.Monitorizeaza testul de bilant al sistemului si activitatile de evaluare. Aceasta constituie o functie
de control a organizarii ingineriei de sistem de a supraveghea rezultatele testului(si astfel de a le
valida), pentru ca necesitatile sistemului sa fie acoperite.Daca nu, problemele trebuie identificate
rapid, si implementata actiunea corectiva corespunzatoare.
10.Coordoneaza si revizuieste toate schimbarile formale de design, ca si modificarile de
imbunatatire. Organizarea ingineriei de sistem, sau reprezentantul desemnat, ar trebui sa
prezideze comitetul de control al schimbarii, identificat, pentru ca: (1) necesitatile sistemului (toate
TPM-urile) in care este nevoie de o ajustare sa poata fi asigurate;(2) toate schimbarile propuse sa
fie evaluate si selectate considerand impactul viziunilor critice, efectivitatii sistemului, costurilor
ciclului de viata, factorilor de mediu; (3) o modificare comprehensiva si un plan de reluare sa se
poata dezvolta;(4) schimbarile aprobate sa fie incorporate eficient si la timp. Aplicatia
managementului unei bune configurari este necesar aici.
11.Initiaza si realizeaza necesarul pentru activitatile de lagatura in intreg procesul de
productie/constructie, utilizare si suport si pentru fazele de dispunere si retragere a materialelor.
Organizarea ingineriei de sistem trebuie sa supravegheze activitatile de productie/constructie
pentru a se asigura ca acestea corespund design-ului definit.Mai departe, supravegherea
operatiunilor consumatorului/utilizatorului este esentiala pentru feed-back-ul necesar validarii
sistemului.
Aceste 11 sarcini din programul de baza constituie un exemplu de program tipic la scara
mare, desi necesitatile pot varia de la o faza la alta.Scopul este identificarea sarcinilor care sunt
orientate catre sistem si sunt critice relativ la intalnirile descrise in capitolele anterioare. Trecerea
in revista a tuturor obiectivelor trebuie sa confirme ca: (1) necesitatile sistemului sunt initial bine
definite; (2) caracteristicile corespunzatoare sunt cuprinse in design; (3) sistemul a fost validat in
termenii necesitatilor specifice initiale.
2.3 STRUCTURA DE INTRERUPERE A LUCRULUI (WBS)
Unul din primii pasi in procesul de planificare a programului, dupa generarea diagramei de
munca (SOW), il reprezinta realizarea WBS. Structura de intrerupere a lucrului este arboricola si
duce la identificarea functiilor, sarcinilor si subsarcinilor, a subactivitatilor,etc., care trebuie
programate pentru a obtine un program complet. Ea arata si defineste sistemul (sau produsul) ca
fiind realizat, produs, operativ si finantat si portretizeaza toate elementele ce concura la acestea.
WBS nu este o harta organizationala in termenii dispunerii de personal si de responsabilitati, ci
reprezinta o organizare a pachetelor de lucru pregatite in scopul planificarii programului,bugetului,
contractarii si raportarii.
In timpul stadiilor timpurii ale planificarii, un sumar al structurii de intrerupere a lucrului ar
trebui pregatit sa includa toate elementele activitatii prin ciclul de viata al sistemului proiectat, de
sus in jos. In timp ce SWBS include adesea doar activitatile de achizitie ale sistemului, incercarea
recomandata aici este de a include toate activitatile (design si dezvoltare, productie, utilizare si
suport), intrucat implementarea principiilor si conceptelor ingineriei de sistem considera intregul
ciclu de viata si toate functiile implicate in proces. In general SWBS include, in general, trei nivele
de activitate:
1. Nivelul 1. Identifica pregatirea total anticipata a muncii legata de design si dezvoltare, productie, distributie, operatii, suport si retragerea sistemului.
2. Nivelul 2. Identifica diverse proiecte, sau categorii de activitati care trebuie realizate ca raspuns la necesitatile programului. El poate include elemente majore ale sistemului sau activitati semnificative ale sistemului (subsisteme, echipament, software, facilitati, date, elemente de suport, managementul programului,etc.). Bugetele programelor sunt , de obicei, pregatite la acest nivel.
3. Nivelul 3. Identifica functiile, activitatile, sarcinile majore, sau componentii sistemului care sunt direct subordonati elementelor nivelului 2. Timpii de executie sunt pregatiti la acest nivel.
Odata progresele planificarii programului si negocierile individuale consumate, SWBS poate fi
dezvoltat mai departe si adaptat la un contract particular, sau la o actiune de achizitie,
rezultand un contract al structurii de intrerupere a lucrului (CWBS). SWBS poate fi
fragmentat dupa cum se vede, CWBS pentru elementele de lucru in faza de design a
sistemului preliminar, un alt CWBS care sa reflecte elementele de lucru in design-ul de
detaliu si faza de dezvoltare, s.a.m.d.
In sumar, WBS asigura un mecanism in scopul atingerii programului de buget si subsecvent
pentru colectarea costurilor si raportarea progresului impotriva pachetelor de munca
individuale. El constituie o excelenta unealta de management al programului si este folosit in
multe situatii de manageriere.
2.4 TIMPII DE LUCRU AI SARCINILOR
Metodele corespunzatoare de programare a timpilor de lucru includ folosirea hartilor cu bare,
a celor cu borne de semnalizare, a hartilor Gantt, a retelelor de program sau a diverselor
combinatii ale acestora. Selectia unei tehnici specifice este dependenta atat de metodele
folosite in PMP peutru un program dat, cat si de natura activitatilor si de faza programului
specific(design conceptual, design de detaliu si dezvoltare, productie). Ca un inceput, se
identifica cateva activitati majore ale ingineriei de sistem, prezentate sub forma unei harti de
bare si indicatori.
Desi aplicatia traditionala cu bare si indicatori este populara, este adesea dificil sa se
asigure astfeladresarea interfetelor corespunzatoare pe masura ce programul deruleaza
fiecare din cele 15 sarcini enuntate. Cu alte cuvinte, cineva poate incerca sa sublinieze , de
exempu, sarcina 10, “Integrarea design-ului de sistem”, in termenii timpilor programati..
Totusi, in indeplinirea activitatilor ingineriei de sistem, pot fi numeroase intrari din diverse
surse, necesare completarii sarcinii intr-un mod satisfacator.Astfel, daca se foloseste o
abordare a timpilor de productie, trebuie sa ne asiguram ca toate intrarile si iesirile sunt
definite corespunzator si pot fi accesate corect.
O metoda preferata a timpilor de productie foloseste retele de program, cum ar fi tehnica
de revizuire si evaluare a programului(PERT), metoda drumului critic(CPM), sau diferite
combinatii ale acestora. PRET si CPM sunt ideale pentru planificari timpurii, unde exista
multe interfete (furnizori cu intrari din diferite parti ale lumii), datele precise ale timpilor
diverselor sarcini nu sunt afisate la vedere, iar aspecte ale probabilitatilor sunt introduse
pentru definirea riscurilor asociate cu multele decizii de design de fiecare zi.
Aplicand timpii de lucru PERT/CPM unui proiect, se pot initial identifica toate activitatile
interdependente si evenimentele pentru fiecare faza a proiectului. Activitatile se refera la
nivele continue de efort, iar evenimentele sunt legate de datele de baza din obiectivele
managementului, in programul cu indicatori.Manageri si programatori lucreaza alaturi de
organizatii de inginerie pentru a defini aceste obiective si a identifica sarcini si subsarcini
specifice. Cand acestea se apropie de nivelul necesar de detaliu. Retelele dezvoltate sunt
cele care incep cu un sumar acoperind activitatile cheie ale ingineriei de sistem, identificate
in WBS.
Atunci cand se realizeaza retelele, se incepe cu obiectivele finale (de exemplu, sistemul
este livrat clientului) si se merge inapoi pana ce evenimentul de inceput este identificat.
Fiecare eveniment este etichetat, codat si verificat in termenii timpilor de lucru. Activitatile
sunt apoi identificate si verificate pentru a se asigura ca sunt corespunzator defalcate.Timpii
activitatii sunt estimate, iar acesti timpi sunt statuati in termenii probabilitatii de aparitie. Unele
activitati se desfasoara pe o baza concurentiala, iar altele trebuie aplicate inseriat. Pentru
fiecare retea comleta, exista un eveniment de inceput si unul de sfarsit, cu toate activitatile
ducand catre cel final. In final, un sumar al retelei poate fi defalcat in retele ale nivelelor
inferioare(reteaua pentru un program de inginerie a calitatii, alta retea pentru un program de
mantenanta,etc.)
Aplicatia timpilor de lucru este potrivita atat pentru proiectele la scara mica cat si la scara
mare si are o valoare anume pentru un tip de efort de dezvoltare a sistemului unde exista
numeroase interdependente, sau pentru acele programe in care sarcinile repetitive nu sunt
predominante. Reteaua este usor adaptabila pentru planificarea adaptata si forteaza definitia
precisa a sarcinii, secventei de sarcini, interrelatiei dintre sarcini. Tehnica permite
managementului si ingineriei sa prevada cu un anumit grad de certitudine timpul probabil
necesar atingerii unui obiectiv. Ea permite, de asemenea, o rapida evaluare a progresului, ca
si detectarea problemelor si a intarzierilor, si este, in particular, adaptabila metodicii de
computer. Aplicatia PERT/CPM a timpilor de lucru este in particular potrivita ingineriei de
sistem unde exista activitati variate si diferite, care trebuie integrate in succesiunea timpilor,
si unde identificarea timpurie a zonei potentiale de risc este critica.
2.5 COSTURILE PROIECTARII SARCINILOR DE PROGRAM
WBS serveste ca baza pentru identificarea initiala a functiilor , activitatilor, sarcinilor si
pentru gruparea sarcinilor in pachete de lucru. Mai departe, WBS asigura un cadru pentru
proiectia costurilor si a bugetului proiectului. Identificarea subsecventa a resurselor materiale
si umane necesare pentru indeplinirea sarcinilor este apoi realizata si reprezinta baza
necesitatilor timpilor de lucru.
In timp ce indicatorul subliniat este elementul “timp”, o retea de cost poate fi suprapusa
pe reteaua PERT/CPM prin estimarea costului total si a functiei cost pentru fiecare linie de
axctivitate. Asemenea functii pot fi generate pentru intreaga retea.
Cand folosim aceasta metoda, exista o optiune timp-cost care permite managementului
sa evaluezealternative relative la alocarea resurselor pentru realizarea activitatii. De multe
ori, timpul se poate comprima prin alocarea mai multor resurse, sau, invers, costurile pot fi
reduse prin extensia timpului alocat activitatii. Timpul si costul alternativ sunt evaluate cu
obiectivul selectiei costurilor celor mai joase, in limita maxima de timp acceptata.
2.6 INTERFATA CU ALTE ACTIVITATI DE PLANIFICARE
Pentru a avea succes, ingineria de sistem reclama un efort atent integrat, atat in interiorul cat si
in afara multor activitati de planificare a programului. Exista numeroase planuri de design
individuale care trebuie sa sprijine direct realizarea activitatilor ingineriei de sistem(planul de
design al ingineriei electice, planul de program al calitatii, planul de program al intretinerii, planul
de inginerie a concurentei,etc.), si exista multe alte planuri de nivel mai inalt, care trebuie sprijinite
in aceeasi masura(planul de management al configurarii, planul de program al manufacturarii,
planul de managenent total al calitatii, planul de suport logistic integrat). SEMP trebuie dezvoltat
aratandu-se legaturile informationale proprii(ruta comunicarii) catre acele planuri externe diverse,
iar acestea din urma trebuie sa reflecte si sa suporte obiective specificate din cadrul SEMP. In
pregatirea acestor planuri externe , este esential ca toate sarcinile, timpii acestora si informatia
costului sa fie compatibile cu ceea ce este specificat in SEMP.
3. ORGANIZATIA INGINERIEI DE SISTEM
Planificarea initiala a ingineriei de sistem incepe in timpul fazelor timpurii ale design-ului
conceptual si evolueaza in timpul dezvoltarii SEMP descris un sectiunea anterioara 2.0.
Implementarea cu succes a acestui plan necesita o structura organizationala care sa promoveze,
sa sprijine si, in general, sa incurajeze aplicarea principiilor si conceptelor ingineriei de sistem in
programe. Mediul organizational specific trebuie creat astfel incat (1) sa permita acoperirea
necesitatilor ingineriei de sistem si (2) sa faciliteze implementarea acestor necesitati in mod efectiv
si eficace.
Organizarea inseamna combinarea resurselor umane astfel incat sa indeplineasca aceste
nevoi. Organizatia este constituita din grupuri de indivizi de diverse nivele de expertize combinate
intr-o structura sociala a unor forme de realizare a functiilor, una cate una. Structurile
organizationale vor varia odata cu desfasurarea functiilor si rezultatele vor depinde de stabilirea
tintelor si obiectivelor, de resursele disponibile, de comunicarea si relatiile de lucru dintre
participantii individuali, de motivarea personalului si de multi alti factori. Obiectivul ultim este
folosirea efectiva si eficienta a materialului uman si a resurselor financiare prin stabilirea
procesului de decizie si comunicare necesar indeplinirii obiectivelor specifice.
Realizarea obiectivelor ingineriei de sistem este in mare parte dependenta de combinarea
eficienta a resurselor, de stabilirea unei comunicari optime si de derularea abilitatilor
interpersonale ale participantilor. Unicitatea sarcinilor diferitele interfete necesita nu doar abilitati
de comunicare, ci si intelegerea sistemului ca entitate si multele discipline care concura la
rezultatul final.
Un exemplu de diagrama Gantt asociata unui proiect software:
3.1 DESFASURAREA STRUCTURII ORGANIZATIONALE
Un pas initial in dezvoltarea oricarui tip de structura organizationala il constituie determinarea
tintelor si obiectivelor companiei/agentiei/institutiei implicate, alaturi de functiile si sarcinile ce
trebuie indeplinite. In functie de complexitatea si marimea programului, structura isi poate asuma
un model pur functional, o orientare a proiectului, o matrice, sau o combinatie a acestora. Mai
departe, structura se poate schimba in care eforturile dezvoltarii sistemului evolueaza de la faza
de design conceptual, trecand prin design-ul de sistem preliminar, design-ul de detaliu si
dezvoltare, productie, s.a.m.d.
In ceea ce priveste ingineria de sistem, un prim obiectiv in timpul stadiului timpuriu al design-
ului conceptual il constituie asigurarea nevoilor de la nivelul sistemului ( primele sase sarcini
descrise in sectiunea 2.2). Aceste activitati sunt , in mare masura , focusate pe client/consumator
, sunt directionate catre sistemul ca entitate, iar indeplinirea lor nu necesita o organizare
avansata.Totusi, selectarea catorva elemente de personal cheie, cu abilitati corespunzatoare,
experienta si pregatire, este esentiala.
Pe masura ce programul evolueaza in fazele de design preliminar si de detaliu, numarul
personalului poate creste, cum necesitatile de design de la nivel de subsistem si mai jos pot dicta
includerea unei expertize din partea multor discipline de design (calitate, maintenanta, factori
umani, logistica,etc.).
In acest context, structura organizationala se poate schimba de la o configuratie de proiect
pur la o combinatie de proiect functional sau o matrice.Odata ce sistemul si elementele sale intra
in faza de productie/constructie, structura organizationala se poate schimba din nou.
In legatura cu termenii organizationali comprehensivi, sublinierea noastra are in vedere
indeplinirea multor sarcini fiverse, descrise in sectiunea 2.2, independent de care elementul
organizational (departament, sectie, grup de personal) isi realizeaza munca. Experienta a indicat
ca exista departamente organizationale sau grupuri localizate in cadrul firmelor industriale sau
agentiilor guvernamentale care au fost desemnate ca „inginerie de sistem”, cu rsponsabilitati
specifice, dar care nu pot realiza sarcinile in vigoare. Invers, exista elemente organizationale cu
identitati diferite, care pot realiza functiile efective in mod eficace. Mai departe, pentru proiectele
mici, in care un singur individ isi poate asuma diverse roluri, responsabilitatile ingineriei de sistem
pot fi realizate de inginerul sef, de inginerul departamentului electric, de inginerul mecanic, sau de
un omolog al acestora. Pe de alta parte, managerul de proiect poate servi pe post de „inginer de
sistem”, sau poate exista un grup de oameni desemnati sa indeplineasca sarcinile cerute.
Obiectivul il constituie atingerea nivelului corespunzator de efort utilizand resursele diverselor
entitati organizationale.
3.2 RELATIILE DINTRE CONSUMATOR, PRODUCATOR SI FURNIZOR
Pentru a accesa corespunzator subiectul „organizatiei pentru ingineria de sistem”, este nevoie
sa intelegem mediul in care functiile ingineriei de sistem se realizeaza. Desi acesta poate varia
cumva dependent de marimea proiectului si de stadiul design-ului si dezvoltarii, aceasta discutie
este in primul rand directionata catre operarea proiectului in termeni largi, caracteristica in achizitia
multor sisteme de scara mare. Vorbind de proiecte mari, este subanteles ca o mai buna intelegere
a rolului ingineriei de sistem intr-un mediu oarecum complex este asigurata. Desigur, cititorul
trebuie sa adapteze si structureze o varianta proprie a programului sau.
Pentru un proiect relativ mare, functia inginerie de sistem poate parea la cateva nivele.
Necesitatile ingineriei de sistem si responsabilitatile implementarii sarcinilor descrise in sectiunea
2.2 se aliniaza consumatorului(sau utilizatorului), caci la acest nivel sistemul actioneaza ca
entitate. Consumatorul poate stabili organizarea ingineriei de sistem care sa duca la indeplinire
sarcinile cerute, sau aceste sarcini pot fi delegate (partial sau total) producatorului prin anumite
forme sau aranjamente contractuale. In fiecare caz, responsabilitatea, ca si autoritatea , realizarii
functiilor ingineriei de sistem trebuie clar definite.
In unele cazuri, clientul isi poate asuma in intregime responsabilitatea intregului design si
desfasurarii, productiei, integrarii si instalarii sistemului pentrul uzul operational. Analiza nevoilor,
studiile de atingere a fezabilitatii, definirea nevoilor operationale si conceptul de mantenanta,
identificarea si prioritizarea TPM-urilor, pregatirea specificatiilor sistemului (tip A), pregatirea
SEMP sunt realizate in cadrul organizatiei clientului. Functiile de la nivelul de varf sunt definite, iar
necesitatile specifice sistemului (sarcinile) sunt alocate producatorilor individuali, subcontractorilor
si furnizorilor de componente.
In alte cazuri, chiar daca clientul prezinta cadrul pentru producerea unui regulament general de
munca (statement of work = SOW), sau un contract sau un alt document echivalent, producatorul
(sau contractorul principal) este responsabil pentru proiectarea, dezvoltarea si realizarea sarcinilor
descrise in Sectiunea 2.2. Cu toate ca ambii – atat clientul, cat si producatorul – au implementat in
organizatie ingineria sistemelor, responsabilitatea de baza pentru atingerea obiectivelor descrise
in acest text o are organizatia producatorului, cu anumite sarcini indeplinite si de catre furnizori
individuali, dupa cum este cazul. Pentru aceasta, clientul trebuie sa delege nu numai
responsabilitatea pentru indeplinirea functiunilor specificate, dar si autoritatea. Mai mult, clientul
trebuie sa permita producatorului accesul la toate datele initiale (input data) pentru ca acesta sa
poata indeplini sarcina de proiectare conceptuala amintita anterior.
Trebuie precizat ca este indicata nu numai o comunicare extensiva, necesara intre fiecare din
organizatiile clientului si ale producatorului, dar si intre diferitele organizatii ale clientului,
producatorului si furnizorului. Liniile pline indica legaturile directe dintre programul de management
formal si cel de natura contractuala, dar trebuie sa existe si suficiente canale de comunicare
informala pentru a stabili dialogul necesar intre numeroasele si variatele entitati implicate in efortul
de dezvoltare al sistemului. Implementarea cu succes a unui parteneriat, impreuna cu promovarea
principiilor de sisteme cooperante discutate anterior, depind in mare masura de existenta unei
bune comunicari (in ambele sensuri, de sus in jos si invers) chiar de la inceputul activitatii.
3.3 ORGANIZAREA SI FUNCTIUNILE PRODUCATORULUI
Un bloc de baza pentru cele mai multe modele organizationale este abordarea functionala, care
implica gruparea specialitatilor sau disciplinelor functionale in entitati distincte, separate. Intentia
este de a face aceeasi munca in cadrul unui singur component. Intr-o structura functionala toata
munca de inginerie este responabilitatea unui singur executant, toata munca de productie este
responsabilitatea altuia si asa mai departe. In acest caz, acelasi grup organizational va realiza
acelasi tip de munca pentru toate tipurile de proiecte.
Functia de inginerie a sistemelor este cuprinsa in ansamblul organizatiei ingineresti si include
sarcinile descrise in Sectiunea 2.2. Organizatia este raspunzatoare pentru realizarea acestor
sarcini, avand in vedere ca se aplica tuturor proiectelor. Aceasta abordare este adesea favorabila
pentru firme mici, deoarece este mai usor de coordonat un grup omogen de functiuni similare si
pesonal cu capacitati asemanatoare. De asemenea, efortul de duplicare este mai mic. Pe de alta
parte, aceasta abordare nu este recomandabila unor operatiuni de amploare datorita centralizarii
nepractice a responsabilitatilor. Astfel, pentru companii mari cu mai multe tipuri de produse,
abordarea functionala poate fi modificata intr-o oarecare masura si organizata in termenii unor
proiecte individuale, cu introducerea unor activitati multidisciplinare, in functie de necesitati.
O organizatie care are in derulare un singur proiect si este singura responsabila pentru
planificarea, proiectarea si dezvoltarea, productia, folosirea si intretinerea unui sistem unic sau de
sine statator. Este limitata in timp, iar utilizarea diferitelor aptitudini si resurse se face strict pentru
atingerea obiectivelor acestui sistem particular. Fiecare organizare a proiectului va include
propriile functiuni de inginerie (proiectare), de testare si suport (intretinere). Astfel, exista un grup
de ingineria sistemelor pentru proiectul A, unul pentru proiectul B si asa mai departe. Fiecare grup
va efectua sarcinile de baza descrise in Sectiunea 2.2. In timp ce organizarea unui singur proiect
aduce unele beneficii legate de timpul de raspuns pentru un anumit client, poate duce si la
anumite surplusuri nedorite intr-o organizatie/agentie, datorita duplicarii resurselor pe mai multe
linii de proiect.
Pentru achizitiile de sisteme unice ample, unde scopul si fondurile sunt adecvate, poate fi folosita
configuratia specifica pe proiect. Totusi, in cazul in care exista mai multe proiecte, care fiecare in
sine nu poate justifica o organizare separata, poate fi preferabila configuratia matriceala. In acest
caz, poate fi mai potrivita rezolvarea anumitor functiuni printr-o structura de proiect, iar altele, prin
folosirea de personal specializat. In acest exemplu, sarcinile de ingineria sistemelor sunt rezolvate
de personal specializat, care lucreaza la diferitele proiecte atunci cand este necesar. Cu toate ca
in acest caz resursele sunt combinate in cadrul structurii functionale, implicarea directa in
activitatile zilnice pe proiect poate fi limitata, din cauza ca activitatea de ingineria sistemelor nu
este de fapt o parte a organizarii proiectului.
Dupa cum s-a aratat anterior, exista numeroase interfete intre grupul de ingineria sistemelor si alte
segmente ale organizatiei producatorului, mai ales atunci cand este implicata achizitia unui sistem
mai dezvoltat. Grupul de ingineria sistemului pentru Proiectul Y(de exemplu) poate sa aiba de
rezolvat numeroase probleme datorate multor altor activitati care apar aproape zilnic. Este nevoie
sa se stabileasca o buna comunicare cu activitatile celorlalte proiecte interne, de exemplu,
ingineria proiectarii (design), ingineria software, unitatile de business, alte organizari de proiect,
functiunile de suport logistic, operatiunile de productie, samd.
Scopul final in proiectarea si dezvoltarea oricarui sistem este stabilirea unei abordari in echipa, cu
canalele de comunicare potrivite, care sa faciliteze aplicarea metodelor de inginerie in paralel, pe
parcursul intregului proiect. Totusi, deseori apar numeroase probleme atunci cand este vorba
despre programe ample, ce implica diferite unitati functionale. Apar bariere ce au tendinta de a
limita relatiile de lucru zilnice, transferul la timp de informatii esentiale si comunicarea discutata
anterior. Deoarece multe companii sunt organizate strict pe linii functionale (fata de configuratia
proiect-angajati arata ), apare nevoia de a asigura si de a mentine nivelul potrivit de comunicare
intre toate unitatile aplicabile proiectului, indiferent daca acestea sunt sau nu locate permanent in
cadrul structurii companiei.
Avand acest obiectiv, Departamentul Apararii (Department of Defense=DOD) a initiat la inceputul
anilor 1990 conceptul de dezvoltare integrata a produsului si procesului (integrated product and
process development=IPPD). IPPD poate fi definit ca „tehnica de management care integreaza in
mod simultan toate activitatile esentiale de achizitie prin folosirea de echipe multidisciplinare,
pentru optimizarea proceselor de proiectare, productie si intretinere.” Acest concept promoveaza
comunicarea si integrarea zonelor functionale cheie, asa cum sunt ele aplicate diferitelor faze din
programul de activitate. Cu toate ca natura specifica a activitatilor implicate precum si gradul de
utilizare se vor schimba intrucatva, in functie de evolutia proiectarii si dezvoltarii sistemului,
structura este mentinuta pentru a canaliza comunicarea necesara intre liniile functionale mai
traditionale de autoritate. In aceasta privinta, conceptul de IPPD este in perfecta concordanta cu
obiectivele ingineriei sistemelor1.
Obligatoriu pentru conceptul IPPD este stabilirea unor echipe pentru produsul integrat (integrated
product teams = IPTs), ce au ca obiectiv rezolvarea anumitor probleme bine definite si specifice. O
IPT, constituita din personal selectat din disciplinele adecvate, poate fi stabilita pentru a investiga
un segment specific al proiectarii, o solutie pentru o problema nerezolvata, pentru proiectarea unor
activitati care au un impact deosebit asupra unor TPM prioritare, samd. Obiectivul este de a crea o
echipa de indivizi calificati care pot efectiv lucra impreuna pentru rezolvarea unei probleme, ca
raspuns al unei anumite cerinte. Mai mult, pot exista mai multe echipe care sa aiba in vedere
probleme la diferite niveluri in structura ierarhica a organizatiei (de exemplu probleme ale
sistemului, ale subsistemului sau la nivelul componentelor).Se poate stabili o IPT pentru a
concentra acele activitati care au un impact semnificativ asupra anumitor factori de performanta,
costul-proprietatii, date integrate si configuratia managementului. Pot exista alte IPT care sa
urmareasca o cerinta specifica a furnizorului. Scopul principal este intarirea atentiei in zonele
critice si adunarea beneficiilor lucrului in echipa, pentru a ajunge la cele mai bune solutii posibile2.
Echipele de lucru integrate sunt adesea stabilite de catre managerul de program sau de catre o
autoritate la nivel inalt din cadrul organizatiei. Membrii echipei trebuie sa aiba calificarea potrivita
in domeniul lor de expertiza, sa aiba autoritatea de a lua decizii pe loc atunci cand este necesar,
sa fie proactivi, sa aiba in permanenta in vedere atingerea scopului si sa rezolve problemele care
le sunt adresate. Managerul de program trebuie sa defineasca in mod clar obiectivele echipei si
asteptarile fata de rezultatele propuse, iar membrii echipei trebuie sa mentina in permanenta
deschis canalul de comunicare. Existenta si longevitatea unei IPT va depinde de natura
problemelor si de eficienta echipei in atingerea obiectivelor. Trebuie totusi evitata stabilirea de
prea multe echipe, deoarece procesele de comunicare si interfetele pot deveni prea complexe. In
plus, pot apare conflicte la stabilirea prioritatilor si la stabilirea problemelor care sunt lasate la
urma. Daca o echipa inceteaza sa mai fie efectiva in atingerea obiectivelor, ar trebui desfiintata. O
echipa care nu mai este folositoare poate fi contraproductiva.
1 Regulamentul DOD 5000.2 ”Proceduri Obligatorii pentru Programele Majore de Achizitie pentru Aparare (MDPAs) si
Programele de Achizitie ale Sistemelor Informatice Majore Automate (MAIS)” (Washington DC, Departamentul Apararii, 1996).
2 Termenul de IPT este folosit si pentru „integrated process team” = echipa de lucru pentru procese integrate
3.4 ALEGEREA PERSONALULUI
n acest punct este important sa discutam despre problema culturala in proiectarea si dezvoltarea
unei organizatii si stabilirea cerintelor de resurse umane, a caracteristicilor leaderului, a
personalului, factorii motivationali, dezvoltarea personalului samd. Cultura tine de personalitatea
organizatiei, de atmosfera, mediu si alti factori asemanatori. Cultura unei organizatii defineste
comportamentul potrivit; poate motiva indivizii, poate conduce modul in care este procesata
informatia si determina relatiile si valorile interne, putand fi fie pozitiva, fie negativa.
In ceea ce priveste ingineria sistemelor, atingerea cu succes a obiectivelor si a sarcinilor specifice
descrise anterior depinde intr-o foarte mare masura de cultura, de suma capacitatilor si de mediul
care a fost creat in cadrul organizatiei. Au existat numeroase cazuri in care au fost stabilite
„Departamentul de Ingineria Sistemelor” sau „Grupul de Ingineria Sistemelor”, in care cerintele de
baza nu au fost atinse. Pe de alta parte, exista si situatii in care astfel de organizatii au avut un
succes deosebit. Factorul cheie este stabilirea unei structuri si a proceselor sale si crearea unui
mediu pozitiv. Acesta are nevoie de promovarea unei comunicari eficiente printr-un
program/structura de proiect, ce va fi respectat din punct de vedere al capabilitatii tehnice si
asumarea unui rol conducator pentru program, fiind de asemenea capabil sa influenteze intr-un
mod continuu proiectarea sistemului si dezvoltarea proceselor. Acesta se poate dovedi o sarcina
relativ dificila, intrucat o organizatie de ingineria sistemelor trebuie sa atinga obiective majore, fara
a avea control direct asupra tuturor resurselor necesare pentru finalizarea proiectului.
Astfel, natura unei organizatii de ingineria sistemelor are nevoie sa indeplineasca urmatoarele
caracteristici in dezvoltarea structurii organizationale:
1. Personalul selectat pentru grupul de ingineria sistemelor trebuie, in general, sa fie persoane
specializate, cu experienta substantiala in domeniu, de formatii diferite si cu o arie mare de
cunoastere – de exemplu, sa inteleaga problemele de cercetare, proiectare, productie si
aplicatiile de intretinere ale sistemului. Accentul se pune pe cunoasterea in ansamblu a
proiectarii sistemului si a tehnologiilor, fiind insa necesare si cunoasterea operatiunilor finale
precum si a intretinerii ciclului de viata al produsului.
2. Un grup de ingineria sistemelor trebuie sa aiba o viziune, sa fie creativ in selectarea
tehnologiilor pentru proiectare, productie si intretinere. Personalul din grup trebuie sa caute in
mod constant noi oportunitati, sa fie inovativ, cercetarea aplicata fiind adesea o cerinta pentru
rezolvarea unor anumite probleme tehnice specifice.
3. In cadrul grupului de ingineria sistemelor trebuie initiata o abordare in echipa. Personalul
desemnat trebuie sa aiba in permanenta in vedere obiectivele organizatiei; este necesar un
anumit grad de independenta, incredere reciproca si respect.
4. Trebuie sa domine o comunicare continua, atat in cadrul grupului de ingineria sistemelor cat si
cea legata de numeroasele functiuni asociate unui anumit proiect. Comunicarea se face in
ambele sensuri, prin mijloace scrise, verabale sau/si nonverable. O buna comunicare este o
cerinta esentiala intr-o organizatie de ingineria sistemelor. Dupa ce aceasta este stabilita, va fi
nevoie de dezvoltarea comunicarii externe in ambele sensuri, folosind atat canalele verticale,
cat si cele orizontale, dupa cum este necesar.
Termenul „mediu” se refera atat la (1) mediul de lucru din cadrul grupului de ingineria sistemelor,
cat si la (2) mediul de lucru extern organizatiei de ingineria sistemelor dar in cadrul structurii
organizationale mai largi a producatorului. Crearea unui mediu de lucru favorabil in organizatia
producatoare trebuie sa inceapa de la varf. Presedintele sau Directorul General trebuie sa fie
primii care „sa creada in…” si „sa sustina” conceptele si obiectivele ingineriei sistemelor. In plus,
nivelul potrivit de responsabilitate si autoritate, precum si resursele potrivite trebuie delegate si
alocate ierarhic, incepand cu Managerul grupului de ingineria sistemelor.
Pentru a facilita atingerea obiectivelor descrise pana aici, caracteristicile si stilul de conducere al
Managerului Grupului de ingineria sistemelor trebuie sa fie „democratic” si „participativ”, fata de o
atitudine mai „autocratica” sau „dictatoriala”. Mediul trebuie sa fie creativ si sa permita initiativa
individuala, creativitatea, flexibilitatea, cresterea personala, samd. Cu toate ca managerul trebuie
sa-si mentina autoritatea, sa indice directiile necesare si sa controleze atingerea obiectivelor si
scopurilor organizatiei, poate introduce practici care sa sustina stilul democratic si abordarea in
echipa a problemelor.
4. CONCLUZII
Acest capitol acopera in principal planificarea si abordarea organizationala in cadrul general al
Managementului Ingineriei Sistemelor.
In acest capitol este inclusa dezvoltarea unui Plan de management pentru ingineria sistemelor
(SEMP), care contine identificarea sarcinilor pentru ingineria sistemelor, un model de structura de
lucru (WBS), mai multe abordari pentru programarea sarcinilor, un model pentru costul
programului si principalele interfete cu alte activitati critice pentru program. Sunt prezentate
exemple de SEMP. Dupa planificarea activitatilor de baza urmeaza dezvoltarea organizatiei de
ingineria sistemelor. Sunt prezentate o varietate de structuri organizationale care includ ingineria
sistemelor, in contextul structurii unei organizatii formale, functionale, a unei structuri pentru un
singur proiect, a unei structuri matriceale si a unei structuri combinate, intre un proiect si o
organizatie formala. Sunt de asemeni discutate aspectele majore ale unei abordari IPPD/IPT. In
final, sunt prezentate unele cerinte specifice pentru personalul unui departament sau grup tipic de
ingineria sistemelor.
Subiectele de sisteme de management, program de management, managementul proiectului si
diferite variatii ale acestora constitue un camp vast de studiu. In acest capitol sunt incluse doar
problemele esentiale, care au legatura cu ingineria sistemelor. Obiectivul este de a prezenta
cateva consideratii in aplicarea principiilor si conceptelor de ingineria sistemelor pentru situatii
reale.
Trebuie subliniat ca ingineria sistemelor este mai degraba o filozofie, „un proces de gandire” si o
abordare de tipul ciclul de viata foflosita in proiectarea si dezvoltarea sistemelor. Nu trebuie vazuta
doar ca o alta disciplina sau domeniu specific ingineriei, ca in cazul ingineriei electrice, ingineriei
mecanice, ingineriei calitatii si altele. O inginerie a sistemelor de calitate se face prin integrarea
coercta si la timp a diferitelor activitati de proiectare pentru a ajunge la un produs eficient, ca
raspuns al unor nevoi identificate ale clientului.
Pentru a atinge obiectivele ingineriei sistemelor nu este nevoie de o organizatie mare, ci doar de
cateva persoane cu inalta calificare, suficienta experienta si cu nivelul potrivit de expertiza. Apoi,
principiile si conceptele de ingineria sistemelor pot fi initiate din orice tip de structura
organizationala, fie functionala, fie pe proiect unic, matrice sau o combinatie a acestora. Este
nevoie doar de o conducere buna de la varf in jos (din perspectiva organizationala), stilul potrivit
de management si o buna comunicare pe ansamblu.
Cu toate ca practicile de ingineria sistemelor dateaza de mai bine de o jumatate de secol, aceste
principii si concepte nu sunt implementate universal nici astazi. Unul din motive este lipsa
intelegerii si acceptarii acestora in multe organizatii. Cu toate ca beneficiile care deriva din ele sunt
numeroase, exista o puternica impotrivire de a gandi in termeni de sisteme, de a gandi
interdisciplinar si de a privi un sistem in contextul intregului sau ciclu de viata. Acesta reiese din
educatia de baza, in care accentul este pus pe termen scurt, pe produse individuale (si nu la
sisteme) si pe specializarea intr-o anumita disciplina sau domeniu al ingineriei. Provocarea pentru
viitor este largirea modului de gandire si o abordare mai ampla, prin educatie – acesta fiind si
abordarea propusa si discutata in acest text, adica ingineria sistemelor.
Descriera cerintelor pentru interfata unui proiect major
Canalul de
comunicare
Organizatia
(Cerintele de interfata)
A 1. Marketing si vanzari – sa obtina si sa sustina comunicarea
necesara cu clientul. Sunt necesare informatii suplimentare cu
privire la cerintele clientului, ale sistemului operational si ale
sistemului de intretinere, schimbari ale cerintelor, competia externa.
Toate acestea sunt deasupra si peste canalul „formal” contractual
de comunicare.
2. Contabilitatea – sa obtina date legate de buget si cost, necesare
pentru analiza economica (de ex. analiza costului ciclului de viata)
3. Achizitii – sa sprijne identificarea, evaluarea si selectia furnizorilor
de componente, in ceea ce priveste implicatiile tehnice, de calitate
si ciclu de viata.
4. Resursele Umane – sa asigure asistenta in recrutarea si angajarea
initiala a personalului pentru ingineria sistemelor si apoi in cursurile
subsecvente si intretinerea calitatilor profesionale ale personalului.
Sa efectueze programe de training pentru tot personalul proiectului,
legate de conceptele de ingineria sistemelor, obiective si
implementarea cerintelor programului.
5. Managementul contractului – sa tina la zi cerintele contractuale (de
natura tehnica) dintre client si contractor. Sa asigure si sa mentina
relatii corecte cu furnizorii, avand in vedere ca de acestia depinde
atingerea nevoilor tehnice pentru proiectarea si dezvoltarea
sistemului.
B Sa stabileasca si sa mentina o legatura continua si o comunicare
apropiata cu alte proiecte, cu obiectivul de a transfera cunostintele ce
pot fi aplicate proiectului Y. Sa solicite asistenta altor laboratoare si
departamente cu functinalitati asemanatoare din cadrul companiei,
pentru aplicarea unor noi tehnologii ca suport pentru proiectarea si
dezvoltarea sistemului.
C Sa furnizeze informatii referitoare la cerintele proiectului pentru
intretinerea sistemului si sa solicite asistenta pentru aspectele
functionale asociate cu proiectarea, dezvoltarea, testarea si evaluarea,
productia si intretinerea, pe intreg ciclul de viata al produsului.
D Sa furnizeze informatii legate de cerintele proiectului pentru productie
(de ex. productie, asamblare, inspectie si testare, asigurarea calitatii) si
sa solicite asistenta pentru proiectarea productivitatii si a cerintelor de
calitate inginereasca pentru sustinerea proiectarii si dezvoltarii
sistemului.
E Sa stabileasca si sa mentina relatiile potrivite si comunicarea necesara
cu activitatile proiectate dupa cum este planificat (monitorizarea
activitatilor critice din program printr-o planificare in retea); configuratia
managementului (definirea diferitelor configuratii si modificarea si
controlul schimbarilor); managementul datelor (monitorizarea,
revizuirea si evaluarea diferitelor pachete de date pentru a asigura
compatibilitatea si eliminarea surplusurilor); si managementul
furnizorilor (monitorizarea progresului si asigurarea integrarii
activitatilor furnizorilor).
F Sa furnizeze informatii legate de cerintele proiectarii nivelului de sistem
si sa monitorizeze, revizuaisca, evalueze si sa asigure integrarea
activitatilor de proiectare a sistemului. Acesta implica conducerea din
punct de vedere tehnic in definirea cerintelor sistemului, asigurarea
analizei functionale, conducerea de studii la diferite nivele ale
sistemului si alte sarcini ale proiectului.