Analiza problemei

(Problem analysis)
 Puncte de interes

• Analiza problemei este procesul înţelegerii problemelor din lumea

reală şi nevoile utilizatorului şi propunerea de soluţii pentru
satisfacerea acestor nevoi.

• Scopul analizării problemei este de de a înţelege cât mai bine

problema, îniante de a trece la dezvoltare.

• Pentru a identifica problemele din spatele problemei, trebuie

întrebaţi cei direct implicaţi.

• Identificarea actorilor sistemului e un pas cheie în analizarea

problemei.
 Definirea analizei problemei
Analiza problemei este procesul de a înţelege lumea reală şi nevoile
utilizatorului şi de a propune soluţii care să satisfacă aceste nevoi.

Pentru a putea face analiza problemei, definim ce este problema [Gause,

Weinberg, Exploring requirements..., 1989]:
Problema poate fi definită ca diferenţa dintre lucrurile aşa cum sunt
percepute şi lucrurile aşa cum sunt dorite.

Obs. Uneori, cea mai simplă soluţie este un proces revizuit decât un nou
sistem.

Scopul problemei este de a înţelege mai bine problema înainte ca

dezvoltarea să înceapă.
Paşii pe care trebuie să-i urmăm pentru a obţine scopul
problemei sunt următorii:
1. Să ne punem de acord privind definirea problemei.

2. Să înţelegem problema din spatele problemei.

3. Să identificăm stakeholders şi utilizatorii.

4. Să definim frontiera sistemului.

5. Să identificăm constrângerile care se impun soluţiei.

 Pasul 1. Punerea de acord privind definirea
problemei
O cale foarte simplă este de a pune problema pe hârtie şi de a vedea
dacă toată lumea e de acord cu ea. Ca parte a acestui proces, e adesea
de mare ajutor înţelegerea beneficiilor soluţiei propuse (cu mare grijă ca
beneficiile să fie descrise d.p.d.v al utilizatorilor).
Scrierea problemei se va face într-un format standardizat (vezi tabelul de
mai jos). Completerea tabelului e o tehnică simplă care ne asigură că toţi
stakeholders se concentrează spre aceleaşi scopuri.
Element Descriere
Problema e... Se descrie problema.
Afectează... Se identifică stakeholders.
Şi rezultatele în... Se descrie impactul problemei asupra
stakeholders şi asupra activităţii de
business.
Beneficiile soluţiei... Se indică soluţia propusă şi se listează
câteva beneficii
 Pasul 2. Problema din spatele problemei
O tehnică folosită este root cause analysis, care oferă o cale sistematică
de a descoperi cauza unei probleme identificate.
Root cause analysis nu reprezintă o metodologie definită; există multe
procese, instrumente şi filozofii. Totuşi, le putem clasifica în 5 “şcoli”:
• Safety-based RCA descinde din accident analysis şi occupational safety
and health.
• Production-based RCA are originea în controlul calităţii pentru
manufacturarea industrială.
• Process-based RCA al cărei scop s-a extins ca să includă procesele
business.
• Failure-based RCA are rădăcinile în practica failure analysis aşa cum se
foloseşte în inginerie şi mentenanţă.
• Systems-based RCA este un amalgam al şcolilor precedente, împreună
cu idei luate din domenii precum change management, risk management,
şi systems analysis.
Procesul general pentru executarea şi documentarea unei RCA-based
Corrective Action
1. Definirea problemei.
2. Adunarea datelor.
3. Întrebare de ce şi identificarea realţiilor de cauzalitate asociate
problemei date.
4. Identificarea cauzelor care, îndepărtate sau schimbate, vor preveni
recurenţa.
5. Identificarea soluţiilor efective care previn recurenţa, sunt sub controlul
dezvoltatorului, îndeplinesc scopurile şi nu cauzează alte probleme.
6. Implementarea recomandărilor.
7. Observarea soluţiilor recomandate pentru a asigura eficacitatea.
8. Metodologia Variability Reduction pentru rezolvarea şi evitarea
problemelor.
Tehnici root cause analysis
• Barrier analysis
• Bayesian inference
• Causal factor tree analysis
• Change analysis
• Current Reality Tree
• Failure mode and effects analysis
• Fault tree analysis
• 5 Whys
• Ishikawa diagram
• Kepner-Tregoe
• Pareto analysis
• RPR Problem Diagnosis
• Apollo Root Cause Analysis
 Pasul 3. Identificarea stakeholders şi a
utilizatorilor
Stakeholder e oricine poate fi afectat material de implementarea unui nou
sistem sau aplicaţie.
Mulţi stakeholders sunt utilizatori ai sistemului şi nevoile lor sunt uşor de
identificat, deoarece ei sunt direct implicaţi în definirea şi utilizarea
sistemului. Unii stakeholders sunt doar utilizatori indirecţi, deoarece sunt
influenţaţi doar de veniturile sistemului.
Obs. Stakeholders neutilizatori trebuie de asemenea identificaţi.
Următoarele întrebări pot fi de folos pentru identificarea stakeholders:
• Cine sunt utilizatorii sistemului?
• Cine este clientul (cumpărătorul economic) al sistemului?
• Cine altcineva va fi afectat de ceea ce produce sistemul?
• Cine va evalua şi aproba sistemul când este livrat şi funcţional?
• Există alţi utilizatori interni şi externi ai sistemului?
• Cine va asigura mentenanţa noului sistem?
• Mai e cineva care contează?
 Pasul 4. Identificarea frontierei sistemului
Împărţim sistemul în două:
1. Sistemul
2. Lucruri care interacţionează cu sistemul, prin intermediul intrărilor şi
ieşirilor

Obs. Lucrurile care interacţionează cu sistemul pot fi văzute în termeni de

actori (aşa cum s-au definit în cadrul UML), încât sistemul se poate
reprezenta ca în figura de mai jos:
În multe cazuri, frontierele sistemului sunt evidente (de exemplu, la
sistemele cu un utilizator şi o platformă).

În alte situaţii, frontierele sistemului nu mai sunt aşa evidente. De exemplu,

sunt situaţiile în care analistul trebuie să determine dacă datele sunt
împărţite cu alte aplicaţii sau dacă noua aplicaţie va fi distribuită între mai
mulţi clienti etc.

Deşi de multe ori se identifică relativ uşor, actorii pot fi determinaţi

răspunzând unor întrebări de genul (vezi şi cursul despre Diagramele
cazurilor de utilizare):
• Cine va folosi informaţia din sistem?
• Cine va opera sistemul?
• Cine va asigura mentenanţa sistemului?
• Unde va fi folosit sistemul?
• De unde îşi ia sistemul informaţiile?
• Ce alte sisteme (exterioare sistemului considerat) vor interacţiona cu
sistemul?
 Pasul 5. Identificarea constrângerilor
Definim constrângerea ca fiind o restricţie asupra gradului de libertate al
soluţiei.

Fiecare constrângere trebuie considerată cu grijă, ca parte importantă a

procesului de planificare şi unele ar putea să determine reconsiderarea
abordării tehnologice pe care am imaginat-o iniţial.

Se pot lua în calcul diverse surse ale constrângerilor: planificarea (în timp),
return on investment, bugetul pentru muncă şi echipamente, sisteme de
operare, baze de date, software-ul cumpărat, procedurile companiei,
alegerea instrumentelor şi limbajelor, constrângeri legate de personal, de
resurse etc.

În tabelul următor se listează sursele potenţiale ale constrângerilor

sistemului.
Sursă Consideraţii
Economică • Ce constrângeri financiare se aplică?
• Sunt consideraţii legate de preţul produsului?
• Sunt consideraţii legate de licenţiere?
Politică • Sunt soluţiile potenţiale afectate de consideraţii
politice?
• Sunt probleme interdepartamentale?
Sisteme • Soluţia pe care o construim e deja în sistemele
existente?
• Trebuie să menţinem compatibilitatea cu soluţiile
existente?
• Ce S.O. şi medii pot fi suportate?
Tehnologică • Suntem restricţionaţi în alegerea tehnologiilor?
• Suntem restricţionaţi în lucrul cu platformele şi
tehnologiile existente?
• Există interdicţii privind utilizarea altor tehnologii?
• Ne aşteptăm să folosim pachete software cumpărate?
Sursă Consideraţii
Mediu • Sunt constrângeri legate de mediu (environment)?
(environment) • Sunt constrângeri legale?
• Care sunt constrângerile legate de securitate?
• Ce alte standarde ne pot restricţiona?
Planificare şi • Este planificarea definită?
resurse • Suntem restricţionaţi privind resursele existente?
• Putem folosi muncă din afară?
• Putem mări resursele?

Odată identificate, unele dintre aceste constrângeri vor deveni cerinţe

pentru noul sistem. Trebuie determinat impactul fiecărei constrângeri
asupra soluţiei potenţiale.
 Concluzii

După efectuarea analizei problemei, ar trebui să avem încredere că avem:

• O bună înţelegere a problemei şi a eventualelor probleme din spatele

problemei (root causes);

• Identificarea potrivită a stakeholders, a căror analiză (judecată) va

determina în ultimă instanţă succesul sau eşecul sistemului;

• O înţelegere a locului unde se pot găsi frontierele sistemului;

• O înţelegere şi identificare a constrângerilor care pot afecta sistemul