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 DescriereProblema 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 problemeiO 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. Sistemul2. 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ţiiEconomică • 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ţiiMediu (environment)

• Sunt constrângeri legate de mediu (environment)?• Sunt constrângeri legale?• Care sunt constrângerile legate de securitate?• Ce alte standarde ne pot restricţiona?

Planificare şi resurse

• Este planificarea definită?• 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