Efectele implementarii SSADM ("Structured System Analysis and

Design Methodology" - Sistemul Structurat de Analiză şi Proiectare

Metodologică) în procesul de management din instituţiile publice
europene - experienţa britanică în utilizarea SSADM
conf.univ.dr. Iulia CHIVU, prof.univ.dr. Dan POPESCU

1. Introducere
Prezentul studiu vizează eficienţa şi eficacitatea utilizării metodologiei SSADM în practică.
Aceste sisteme structurate de analiză şi proiectare metodologică sunt folosite de Guvernul Marii
Britanii şi au fost examinate pentru a le determina valoarea, ca proiecte de software. Rezultatele
cercetării se bazează pe interviurile cu 17 manageri de proiect, discuţiile cu participanţii la 3
mari proiecte SSADM şi pe observaţiile a 90 utilizatori finali ai acesteia.

Concluziile arată că metodologiile (sistemelor de informaţii prescriptive) nu fac foarte bine faţă
situaţiilor de incertitudine, comunicării cu utilizatorii sau dezvoltării managementului superior.
Recomandările vizează orientarea mai atentă asupra soft-ului organizaţional şi utilizarea unor
soluţii adaptate specificului fiecărui proiect.
Scopul acestei metodologii constă în:
- formalizarea cerinţelor procesului de obţinere/extragere a informaţiilor şi reducerea
situaţiilor de neînţelegere a cerinţelor
- introducerea celor mai bune tehnici de analiză şi proiectare de soluţii.

2. Istoric
SSADM a fost realizată, la începutul anilor 1980, pentru guvernul britanic, de către compania
LBMS (Learmonth & Burchett Management Systems) în colaborare cu CCTA (Central
Computer Telecommunications Agency). În 1983, SSADM a fost declarată drept standard de
aplicare pentru toate departamentele guvernamentale.

„SSADM este utilizată de guvernul britanic încă de la lansarea sa, în anul 1981. Ea a fost
încredinţată de CCTA guvernului britanic în încercarea de a standardiza multitudinea şi
varietatea de proiecte IT dezvoltate de departamentele guvernamentale. CCTA a analizat multe
variante, până să accepte varianta Learmonth & Burchett Management Systems” (SSADM
Version 4 - A Users Guide).

Din anul 1981, SSADM a fost actualizată permanent, iar în anul 1990 a fost lansată versiunea
4. SSADM are un standard deschis şi, de exemplu, este disponibil gratuit pentru utilizare în
industrie, multe organizaţii oferind sprijin, formare şi instrumente CASE pentru utilizarea lui.

Aplicaţia SSADM vizează dezvoltarea sistemului informatic al unei organizaţii pe baza unui
sistem de date şi nu pe baza unei dezvoltări a software-urilor orientate pe timp real.
Metodologia se concentrează pe fluxuri de date, modele de date, precum şi pe cicluri de viaţă
cronologice ale unor „entităţi” (în prezentarea metodologiei vom detalia definirea acestora).

Spre deosebire de separarea strictă a procedurilor de metodologie, în metodologia SSADM a

fost integrat un model bazat pe ciclul de viaţă al unui produs sau serviciu. Acesta răspunde
ambelor proceduri şi instrucţiuni pentru analiză şi proiectare, în concordanţă cu generaţiile de
software (de la SD1 - System Requirements Analysis la SD5 SW - Detailed SW Design), în
următoarele domenii:
 ce activităţi trebuie realizate şi unde (o structură realizată pe trei nivele în faze, paşi şi
sarcini),
 cum trebuie realizate activităţile (cu ce metode, tehnici şi instrumente) şi unde şi în ce
formă vor fi înregistrate documentele.

SSADM, la fel ca alte metodologii structurate, adoptă o abordare prescriptivă a dezvoltării

sistemului informatic, în cadrul căreia sunt specificate, în avans, module, etape, sarcini şi
servicii care trebuie realizate şi, mai mult, precizând tehnicile utilizate pentru producerea
serviciilor. SSADM adoptă modelul dezvoltării sistemelor „în cascadă”, în care fiecare fază
trebuie să fie finalizată înainte ca următoarea fază (subsecventă) să înceapă. SSADM este un
exemplu de metodologii structurate, incluzând o varietate de alte metodologii utilizate in
sistemele informatice, respectiv:
- STRADIS: (Structured Analysis, Design and Implementation of Information Systems) o
metodologie realizată de Gane şi Sarson (1979), bazată pe filosofia descompunerii
funcţionale top-down şi utilizarea Data Flow Diagrams.
- YSM: (Yourdon Systems Method,Yourdon, 1993). YSM este similară STRADIS în
utilizarea descompunerii funcţionale, abordarea sa fiind concentrată asupra importanţei
structurilor de date.
- MERISE: (Quang and Chartier-Kastler, 1991). Metodologia este larg utilizată in
ingineria sistemelor informatice din Franţa, Spania şi Elveţia. MERISE conţine trei
cicluri: ciclul decizional, ciclul de viaţă şi ciclul de abstractizare. Ciclul de abstractizare
este cheia metodologiei, în cadrul acestuia, atât datele, cât şi procesele fiind
identificate, în primul rând, la nivel conceptual, apoi, la nivel logic sau organizaţional
şi, finalmente, la nivel operaţional.
- EUROMETHOD: (CCTA, 1994) Euromethod poate fi descrisă ca un cadru pentru
integrarea metodologiilor existente la nivel european.

3. Ce este SSADM?
SSADM (Structured Systems Analysis and Design Methodology) este o metodologie („a
system of ways of doing things especially regular and orderly procedures” - un sistem de
realizare a unor proceduri regulate şi sistematice) utilizată pentru analiza şi proiectarea etapelor
de dezvoltare a unui sistem. SSADM nu acoperă/interferează cu elementele SITP sau cu
construcţia, testarea şi implementarea software-urilor.

SSADM porneşte de la definirea strategiei sistemului informaţional, apoi dezvoltă module de

studii de fezabilitate. Acestea sunt urmate de o serie de analize, cerinţe de specificaţii,
specificaţii de sisteme logice şi, finalmente, de proiectarea sistemului fizic.

3.1. Simbolurile utilizate în SSADM

3.2. Exemplu de diagramă SSADM

3.3. De ce este utilizat SSADM în Marea Britanie?
În primul rând pentru că toate departamentele guvernamentale îl utilizează. De asemenea,
pentru că organizaţiile sau companiile britanice sunt dornice să folosească o abordare
inginerească, ordonată, care poate creşte calitatea activităţilor lor. Pe aceste considerente, multe
companii s-au arătat dornice să cheltuiască mult pentru implementarea SSADM.

3.4. Cum este controlat în Marea Britanie SSADM?

SSADM este gestionat de CCTA, dar responsabil pentru menţinerea şi dezvoltarea sa sunt
Design Authority Board (DAB) şi NCC (National Computing Centre). În cadrul acestuia din
urmă, se produce documentaţia definitivă a SSADM.

4. Care sunt instrumentele de lucru ale SSADM?

SSADM are la bază trei tehnici cheie: Logical Data Modelling, Data Flow Modelling and
Entity/Event Modelling.
 Logical Data Modelling – este un proces de identificare, modelare şi documentare a
datelor necesare sistemului informaţiilor de afaceri (business information system). Un
model Logical Data Model constituie o structură logică de date (LDS este o
terminologie SSADM pentru a defini modelul de intrare „entităţi – relaţii”) şi cel de
documentaţie asociate acestora. LDS este reprezentat de entităţi (lucrurile de care o
persoană/o afacere are nevoie pentru ca să înregistreze o informaţie) şi relaţii
(asocierile necesare între entităţi).
 Data Flow Modelling – este un proces de identificare, modelare şi documentare a
modului în care datele circulă în cadrul sistemului de informaţii. Un model Data Flow
Model conţine un set de diagrame integrate - Data Flow Diagrams – susţinute de o
documentaţie aferentă. DFD este reprezentat de procesele (activităţile care transformă
datele de la un model la altul), locurile de stocare a datelor, entităţile externe (lucrurile
care trimit date în sistem sau primesc date de la sistem) şi fluxurile de date.

 Entity/Event Modelling – este procesul de identificare, modelare şi documentare a

evenimentelor externe (persoane, afaceri) care afectează fiecare identitate şi fiecare
secvenţă în care apar acestea. Un model „entitate-eveniment” constă într-un set de
„istorii a vieţii” entităţii – ELH (câte una pentru fiecare intrare) şi o documentaţie
aferentă acesteia.
Succesul metodologiei SSADM este datorat faptului că nu se bazează pe o singură tehnică, ci
pe trei. Fiecare dintre acestea vine cu un punct de vedere diferit al aceluiaşi sistem, însă fiecare
este solicitat să completeze modelul sistemului. În cadrul SSADM, fiecare dintre cele trei
tehnici se suprapune peste alta pentru a asigura completitudinea şi acurateţea modelului.

5. De către cine şi cum poate fi utilizat SSADM?

 dezvoltatorii de software - pentru aplicaţiile software care utilizează Unified Modeling
Language (UML)
 dezvoltatorii de software - pentru a ilustra şi interpreta aplicaţii software pentru
relaţionare, acţiune sau conexiune
 managerii de programe – pentru a arăta nivelul ridicat de structuri software statice în
prezentarea şi specificarea documentaţiilor
Spre deosebire de Unlike rapid application, care derulează paşi în paralel, SSADM construieşte
fiecare pas pe baza activităţii care a fost realizată în paşii anteriori, fără nicio abatere de la
model. Datorită structurii rigide a metodologiei, SSADM este apreciat pentru modalitatea sa de
control a proiectelor şi abilitatea sa de a dezvolta sisteme calitativ superioare.

6. Cum este structurat SSADM?

SSADM conţine cinci module principale, care sunt divizate într-o ierarhie complexă de etape,
paşi şi sarcini, aşa cu reiese şi din figura alaturată:
1. Feasibility Study; acest modul constituie etapa 0 – studii de fezabilitate şi implică
realizarea unor analize detaliate a ariei implicate (mediul de afaceri, cetăţeni) pentru a
determina gradul în care costurile sistemului justifică cerinţele ariei (mediului de
afaceri, cetăţenilor). În această etapă, este realizat un model DFD care să reprezinte
„harta” sistemului informatic existent.
2. Requirements Analysis; acest modul necesită realizarea unor analize, în două etape: 1
– analiza mediului actual şi 2 – analiza opţiunilor sistemului de afaceri (Business
System Options - BSO).
 În cadrul primei etape, sunt identificate cerinţele sistemului şi este modelat
mediul de afaceri existent, în termeni de procese derulate şi structuri de date
implicate. Tot aici, sunt utilizate DFD şi LDS pentru a realiza modele logice
detaliate ale sistemului actual.
 În cea de-a doua etapă, sunt produse şi prezentate 2-6 opţiuni de sisteme de
afaceri. Ca rezultat, numai una dintre ele este aleasă şi implementată. Pe
parcursul acestei etape, sunt produse DFD şi LDS ca suport pentru fiecare
opţiune a sistemului şi, evident, pentru cea finală. Trecerea de la prima etapă la
cea de-a doua constituie un element-cheie al SSADM, respectiv partea în care
se trece de la modelul logic al sistemului informatic existent la modelul logic al
sistemului dorit.
3. Requirements Specification; acest modul conţine o singură etapă (3), care include
dezvoltări viitoare a activităţii realizate în cel de-al doilea modul. Aici sunt identificare
cerinţele funcţionale şi non-funcţionale şi sunt introduse noi tehnici pentru a definini
structurile de date şi procesele dorite. În această etapă, sunt revizuite şi validate,
înscrucişat, DFD şi LDS în vederea alegerii opţiunii sistemului dorit. LDS este
mărit/dezvoltat prin folosirea normalizării (utilizarea analizelor de date relaţionale).
DFD şi LDS sunt validate în conformitate cu ELH – istoria de viaţă a entităţii, produsă,
de asemenea, pe parcursul acestei etape. DFD, LDS şi ELH sunt utilizate ca inputuri
ale etapei subsecvente a SSADM.
4. Logical System Specification; acest modul conţine două etape: 4 – opţiunile sistemului
tehnic şi 5 – proiectarea logică. În etapa a patra sunt realizate 2-6 opţiuni tehnice
(specificându-se mediile de dezvoltare şi implementare) şi se alege una dintre ele. În
etapa a cincea, se realizează proiectarea logică a actualizărilor şi dialogurile şi
procesele de interfaţă (meniuri etc.).
5. Physical Design; acest modul conţine o singură etapă – 6: proiectarea fizică, în care
sunt utilizate specificaţiile sistemului logic şi tehnic pentru a crea o bază de date fizică
şi un set de specificaţii ale programului.
7. Evaluarea diferitelor abordări ale metodologiilor similare SSADM
OPM: The Organisation Process Modelling method (Warboys, 1999) vizează aspecte ale
sistemelor de hard şi soft.
SSADM: The Structured Systems Analysis and Design Method (SSADM, version 4, 1990) este
o metodă detaliată, acoperind aproape toate elementele ale sistemului informatic (Duncan,
Rackley and Walker, 1995).
UML: The Unified Modelling Language (UML, version 1.3, 1998) este un limbaj de modelare
expresivă care vizează toate aspectele procesului de dezvoltare a sistemului informatic (Booch,
1999). UML poate fi adaptat cu Business-Oriented Software Engineering process (BOE
Process) pentru a acoperi mai complet procesele de modelare din cadrul unei firme.
Unified Process: Metoda Unified Process a aparut în anul 1999 (Rational Software
Corporation, 2000) şi vizează majoritatea elementelor sistemului hard. Este suportul tehnicilor
orintate pe obiect, deoarece modelele sale sunt bazate pe concepte de obiect, clasă sau relaţie. O
diagramă de activitate modelează procesele de afaceri.
SSM: În timp ce majoritatea metodologiilor vizează numai aspecte de soft, Soft Systems
Methodology (SSM) se ocupă şi de sistemul hard. SSM (Checkland and Scholes, 1990) susţine
activităţile şi procesele prin utilizarea unui model conceptual de reprezentare a activităţilor din
sursă.
Workflow (WFMS): Workflow Management System (Jablonski and Bussler, 1996) introduce
calităţi noi în sarcinile sistemului de a combina oameni, organizaţii şi procese pentru a forma
„lanţul valorii”. Un asemenea lanţ este o terminologie managerială utilizată pentru o serie de
organizaţii care lucreză împreună pentru a satisface cererile pieţei. Lanţul valorii constă dintr-
unul sau mai mulţi furnizori de valori primare (produse sau servicii) şi mulţi alţii care adaugă
plus-valoarea care este prezentată cumpărătorului publi/final.

8. Comparaţii între metodologiile enunţate

Tabelul prezintă comparativ metodologii diferite, atât în termeni de soft, cât şi de hard.
Taxonomia a fost realizată pornind de la analiza sistemelor workflow systems (Al-Humaidan
and Rossiter, 2001). Tabelul face referire la aspecte ale sistemelor de hard precum: date (1),
evenimente (2), procese (3) interfaţă (4) (Longworth, 1992a; Longworth, 1992b) şi de aspecte
ale sistemlor de soft, precum: resurse (5), calitate (6), detalii despre afaceri (7), identificarea
problemei (8), implicarea utilizatorului (9), structură organizatorică, obiective şi politici (10),
satisfacţia angajatului (11), vizitatori (12), valorile angajaţilor (13), acceptabilitatea sistemului,
utilizarea sistemului (14) (Checkland and Scholes, 1990). Calitatea problemelor include aspecte
privind folosirea incorectă a cerinţelor, neglijarea mărimii organizaţiei sau analiza incorectă.
Productivităţi reduse pot rezulta urmare a schimbării cerinţelor utilizatorilor, impactului
evenimentelor externe asupra cerinţelor modificate, implementării unei soluţii inadecvate, sau
controlului slab al proiectului. Abordarea sistemului de soft încearcă să rezolve o parte dintre
aceste probleme prin acordarea unei atenţii speciale investigării situaţiilor problemă şi utilizarea
unor tehnici diverse pentru determinarea politicilor şi a obiectivelor organizaţionale. În plus,
abordarea soft se concentrează pe elemente sociale care ar putea influenţa natura soluţiilor la
problemele apărute, precum: structura organizatorică, satisfacţia angajatului, valorile
angajatului, utilizarea sistemului şi acceptabilitatea acestuia, inclusiv implicarea utilizatorilor.
(Flynn, 1998).

9. Avantaje şi dezavantajele utilizării SSADM

Structured Systems Analysis and Design Method (SSADM) este o metodă detaliată care
acoperă aproape toate elementele sistemului informatic. Ea vizează fiecare aspect al sistemului
hard, dar numai o parte dintre cele specifice sistemului soft.
SSADM este unul dintre cele mai vechi sisteme concepute pentru proiecte la scală mare. De
aceea, trebuie să fim foarte atenţi dacă acesta este potrivit sistemului informatic pe care trebuie
să îl dezvoltăm, evident, în funcţie de scopul şi mărimea sistemului vizat.
 Method

System
OPM SSADM UML Unified Process SSM WFMS
elements
A. Form-based workflow:
Logical Data A. The class diagram fields connected to database.
1. Data Not supported The class diagram Not supported
Model (LDM) B. Databases B. Engine-based workflow:
data stored in database
Two types of events: internal
Goal model
Entity Life History The Behaviour The Behaviour and external. They trigger the
2. Events (Conceptual Not supported
(ELH) (interaction) diagrams (interaction) diagrams starting and execution of
Model CM)
process instances.
A. Form-based workflow:
Method model
Data Flow logic of process.
3. Processes (Role Activity The activity diagram The activity diagram Conceptual models
Diagram (DFD) B. Engine-based workflow:
Diagram)
process information held.
A, User screen Five types of interfaces can
Modelled in class and sketches/prototypes. be used with engine-based
4. Interfaces Not supported Dialogue Design Not supported
component diagrams. B. Internal interfaces: systems. In form-based
classes and components. systems form is interface.
In root definition,
Project manager plans
Requirements Modelled by using the activities related to
5. Resources Not supported and schedules process Information and human.
Catalogue (RC). stereotype feature. resources in conceptual
resources.
models.
A. In analysis A. Inception and Measures for activities in Identifying rules followed to
explorative elaboration phases: conceptual models. Some perform specific process.
Requirements prototypes. explorative prototypes. activities monitor these Improve supported process
6. Quality Not supported
Catalogue (RC). B. In design B. Tests: Integration, measures taking control by identifying weaknesses
experimental configuration, negative action to improve matters and reducing time to perform
prototypes and stress. in proposed system. tasks.
A. Data Flow Combination of different
Method model Activity diagrams Developing business
7. Business Diagrams (DFD). perceptions in conceptual Support for business
(Role Activity describe and model model that defines
issues B. Entity Life models that specify processes.
Diagram) business process. business processes.
History (ELH). business system options.
8. Identify the The system The strategic The strategic planning Rich picture presents
The strategic planning Identified in enterprise
problem or model is used to planning defines defines the problem problem situation
defines the problem that planning and business area
problem define the the problem that that needs to be including different people
needs to be solved. analysis.
objectives problem scope. needs to be solved. solved. perceptions.
 A. Gathering info- A. Gathering info- A. Gathering information
A. Gathering A. Gathering
rmation about system rmation about system in about problem situation.
information information about
in use case models, use cases, business or B. Choosing activities to Encourage involvement of
9. User involve- about system. system.
CRC and tech. domain models, suppl. construct consensus users in implementing
ment B. Validating B. Reviewing
dictionary. requirements. primary task model. workflow system.
models and final products of each
B. Review/check B. Check/validate arte- C. Debating to define
system. stage.
prototypes. facts of iteration//phases. required changes.
Strategic planning Presented in Present organisational
10. Organi- OPM analyses Activity diagram Documented in the
looks at organi- A) A) Rich picture structure and population.
sational process to define models organisational business model and
sational structure model. Goals specified in enterprise
structure, goals organisation structure and supplementary
giving Project B) B) Primary task planning and business area
and policies values. integration. requirements.
Initial Document. model. analysis.
Project feasibility, risk A. System offers tasks to
User may choose
Allowing employees management, team employees who are free to
Business System
11. Employee to choose suitable way structure, project User involvement in accept them or not.
Not supported Option (BSO) that
job satisfaction to perform assigned schedule, project under- stages of SSM. B. System-delivered model
defining impact on
job. standability and sense of enabling users to reject or
users and training.
accomplishment delegate responsibilities.
A. Consider
process owner’s Different views are
Different views of
view or change Analyst considers modelled in conceptual
the system are Different views are Define several process paths
12. Different process. different views of models and combined in
documented in integrated to reach best to support different views of
point of views B. Use dialectic system and resolves ways to accommodate
Requirements answer. process.
concept contradictions. them and reconcile
Catalogue.
C. Rich picture to conflicts.
represent views.
Recommends use
Documented in Analysis
13. Employee of SSM to define Stored in organisational
Not Supported. Not Supported. Not supported Two that specifies roles,
values emp-loyee population.
norms and values.
goals/views
A. User involve- A. Involving user in Acceptance of workflow
OPM attempts to Involvement of users Achievement of user
ment in developing developing system. systems increases if workers’
14. System match users’ task in experi-mental requirements and user
system. B. Performing and business problems are
acceptability and structure of prototypes to verify involvement promotes
B. Use prototype. acceptance test. solved. Services relating to
and usability the software usability/accepta- acceptance/ usability of
C. Study of system C. Providing users with user requests must be
system. bility of system. delivered system.
impact on staff. doc/help line. efficient to satisfy their users.
Comparison of Methodologies in Terms of both Hard (1-4) and Soft (5-14) System Aspects.
SSADM specifică, foarte exact, sarcinile şi etapele dezvoltării unui proiect şi realizează documentaţia
detaliată a acestuia. 4 Avantajele utilizării acestei metodologii pot fi considerate următoarele 5:

a) oportunitatea: d.p.d.v. teoretic, SSADM permite planificarea, conducerea şi controlul proiectelor.

Aceste elemente sunt esenţiale pentru realizarea, la timp, a produselor sau a serviciilor.
b) utilitatea: în cadrul SSADM sunt reliefate analize ale nevoilor utilizatorilor. În acelaşi timp, este
dezvoltat modelul sistemului şi este realizată o analiză comprehensivă a cererii. Ambele sunt
concepute astfel încât să se poată preciza dacă sunt potrivite una alteia.6
c) răspund schimbărilor produse în mediul de afaceri: Deoarece în documentaţia SSADM
procesele de derulare a proiectului sunt foarte atent analizate, elemente precum obiective de afaceri
sau nevoi de afaceri sunt luate în considerare pe măsură ce se dezvoltă proiectul. Aceasta oferă
posibilitatea adaptării planificării proiectului la nevoile actuale ale utilizatorilor (persoane sau afaceri).
d) utilizarea eficientă a abilităţilor: SSADM nu necesită abilităţi speciale şi poate fi învăţat cu
uşurinţă de către angajaţi. În mod normal, sunt utilizate tehnici de modelare şi diagrame. De asemenea,
tehnicile Commercial CASE sunt oferite pentru a permite instalarea cât mai uşoară a SSADM.
e) calitate ridicată: SSADM reduce rata de eroare a sistemului informatic prin definirea unui anumit
nivel al calităţii încă de la început şi prin verificarea constantă a sistemului.
f) creşterea productivităţii: SSADM îmbunătăţeşte calitatea productivităţii proiectelor specifice şi
eficienţa activităţii organizaţiei prin încurajarea răspunsului în timp real, prin îmbinarea cererilor din
mediul de afaceri, prin utilizarea eficace a resurselor umane, precum şi prin reducerea birocraţiei.
g) reducerea costurilor: SSADM separă proiectarea sistemului fizic de cel logic. Astfel, sistemul nu
este nevoit să să fie implementat „împotriva” unui hard sau a unui soft nou. 7

Pentru organizaţiile de dimensiuni mari, uneori, SSADM are anumite dezavantaje:

SSADM pune mare accent pe analiza sistemului şi documentaţia acestuia. Aceasta poate genera riscul
unor super-analize care pot fi consumatoare de timp şi bani8. Datorită diverselor tipuri de metode
descriptive, verificarea consistenţei nu poate fi urmărită. În special, în cadrul sistemlor mari, diagrama
cadru devine neclară deoarece toate fluxurile de date trebuie să fie incluse9. Însă, organizaţiile mari
care au în derulare proiecte variate, pot profita de SSADM datorită faptului că aceasta le dă
posibilitatea să reutilizeze anumite tehnici şi instrumente pentru alte proiecte. Aceasta reduce, pe
termen lung, costurile şi timpul. Deci, pericolul cheltuirii prea multor bani pe analizele necesare poate
fi compensat prin reutilizarea sistemului realizat şi a experienţei câştigate.

10. Oportunitatea SSADM pentru cultura organizaţională şi pentru structurile organizatorice

Termenul „cultură organizaţională” poate fi definit drept „...un sistem de scopuri împărtăşite de toţi
membrii ei, scopuri care diferenţiază o organizaţie de alta”22. Acestea includ reguli nescrise, valori
împărtăşite şi cutume specifice unei organizaţii. Fiecare tip de cultură organizaţională apare, în mod
normal, împreună cu un anumit tip de structură organizatorică.
Elementele organkizatorice asupra cărora aplicarea SSADM are efect sunt: controlul, conducerea,
toleranţa la risc şi comunicarea.23 Dintre acestea, cel mai afectat este extinderea controlului datorită
creşterii numărului de reguli, reglementări şi supervizări. Spre exemplificare, o organizaţie care are o
cultură şi o structură de tip ierarhic, va avea cele mai mici probleme prin adoptarea SSADM şi va reuşi
să îşi familiarizeze rapid angajaţii cu metodologia specifică. Însă, în organizaţiile în care angajaţii sunt
încurajaţi să îşi asume mai multe responsabilităţi decât cele prevăzute, şi care, în general, sunt mai
dinamice şi mai puţin birocratice, aplicarea SSADM va genera o serie de dificultăţi.

Avantajele şi dezavantajele introducerii SSADM sunt strâns legate de stabilitatea situaţiei organizaţiei
în mediul în care îşi desfăşoară activitatea. Putem afirma că o organizaţie poate profita de avantajele
pe care SSADM le oferă (o claritate mai bună a solicitărilor – datorită verificărilor realizate la fiecare
etapă, sau o satisfacere mai exactă a solicitărilor – datorită evidenţierii analizei solicitărilor în fiecare
etapă), respectiv:
- în primul rând, volumul activităţii şi timpul disponibil trebuie să fie suficient de mari pentru a
permite derularea întregului proces de dezvoltare a metodologiei.
- în al doilea rând, situaţiile din mediul extern organizaţional trebuie să fie relativ stabile,
deoarece SSADM nu permite schimbări ale specificaţiilor, odată ce o etapă a fost realizată şi
 verificarea stadiului de realizare a acesteia a fost completă. Acest fapt poate genera probleme
de genul în care rezultatul final oferit nu corespunde solicitărilor utilizatorilor 24
Analizând situaţia pe termen lung, SSADM a dovedit că determină creşterea calităţii generale a
sistemului informatic din cadrul organizaţiei. Dovada: faptul că SSADM a devenit metodologia
dezvoltată de departamentele guvernului britanic şi de furnizorii de sisteme infomatice ai acestuia.
Însă, trebuie să ţinem cont că SSADM a fost realizată, în special, pentru organizaţiile şi proiectele
guvernamentale care dispuneau de suficiente resurse temporale, financiare şi umane pentru a se îmbina
cu natura birocratică specifică instituţiilor publice.

Referinţe

1. Bocij, P., Chaffey, D., Greasley, A., Hickie, S., (1999) Business Information Systems,
Prentice Hall, England
2. The Government of the Hong Kong special Region (1998) An introduction to Structured Systems
Analysis & Design Methodology (SSADM) [S3a] Version 2.0 [Internet] Available from:
<http://www.itsd.gov.hk/itsd/textmode/quality/download/s3a.pdf> [Accessed 20 December, 2001]
3. Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England
4. Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet] Pontypridd,
University of Glamorgan. Available from:
http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html
5. Krallmann, H., (1994) Systemanalyse im Unternehmen: Geschäftsprozessoptimierung,
partizipative Vorgehensmodelle, objektorientierte Analyse, Oldenbourg Verlag, München
6. Robbins, S. P (1991) Organizational Behaviour: concepts, controversies and applications. 5/e.
Prentice-Hall, England
7. Sandhill Consultants, (2001) SSADM Process Library [Internet]. Available from:
<http://www.sandhill.co.uk/pware/ssadm.htm>
8. Chaffey, D., et. al. (1999) Business Information Systems, Prentice Hall, England, p.262
9. Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet]
10. Sandhill Consultants, (2001) SSADM Process Library [Internet]
11. Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England, p. 489
12. The Government of the Hong Kong special Region (1998) An introduction to SSADM,
Version 2.0 [Internet]
13. Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England, p. 491
14. The Government of the Hong Kong special Region (1998) An introduction to SSADM,
Version 2.0 [Internet]
15. Sandhill Consultants, (2001) SSADM Process Library [Internet]
16. Krallmann, H., (1994) Systemanalyse im Unternehmen, Oldenbourg Verlag, München, p.73
17. Sandhill Consultants, (2001) SSADM Process Library [Internet]
18. Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England, p. 489
19. Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet]
20. Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet]
21. Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England, p. 491
22. Krallmann, H., (1994) Systemanalyse im Unternehmen, Oldenbourg Verlag, München, p.65
23. Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet]
24. Krallmann, H., (1994) Systemanalyse im Unternehmen, Oldenbourg Verlag, München, p.68
25. Longworth, G., (1992a), Introducing SSADM, Version 4, NCC Blackwell Limited
26. Longworth, G., (1992b), A users Guide to SSADM, Version 4, NCC Blackwell Limited
27. Rational Software Corporation, (1999, June), OMG Unified Modelling Language
Specification, version 1.3, www.rational.com.
28. Rational Software Corporation, (2000, October), The Unified Process, www.rational.com.
29. Stark, H. and Lachal, L., (1995), Ovum Evaluates: Workflow, Ovum, London, UK.
30. Warboys, Brian, Kawalek, Peter, Robertson, Ian, and Greenwood, Mark, (1999), Business
Information Systems-A Process Approach, McGraw-Hill Publishing Company