1 / 49

Sisteme socio-tehnice

Sisteme socio-tehnice. Obiective. Definirea unui sistem socio-tehnic şi diferenţa dintre acesta şi un sistem bazat pe calculator (computer-based system) ‏ Introducerea conceptului de proprietăţi emergente ale sistemelor, cum ar fi fiabilitatea şi securitatea

hiero
Download Presentation

Sisteme socio-tehnice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sisteme socio-tehnice

  2. Obiective • Definirea unui sistem socio-tehnic şi diferenţa dintre acesta şi un sistem bazat pe calculator (computer-based system)‏ • Introducerea conceptului de proprietăţi emergente ale sistemelor, cum ar fi fiabilitatea şi securitatea • Explicarea proceselor pentru ingineria sistemelor şi pentru procurarea sistemelor • Explicarea modului în care contextul organizaţional al unui sistem afectează proiectarea şi utilizarea sa • Discuţie asupra sistemelor legacy şi de ce acestea sunt critice pentru multe sisteme economice

  3. Subiecte tratate • Proprietăţile emergente ale sistemelor • Ingineria sistemelor • Organizaţii, persoane şi sisteme de calcul • Sisteme legacy

  4. Ce este un sistem? Def. Colecţie semnificativă (cu un anume scop) de componente inter-relaţionate care lucrează împreună pentru a realiza un obiectiv comun. Poate include componente: • Software • Hardware: mecanic, electric, etc. Poate fi operat de persoane • Componentele sistemului sunt interdependente. • Proprietăţile şi comportamentul componentelor sistemului sunt sunt strâns corelate

  5. Categorii de sisteme • Sisteme tehnice bazate pe calculatoare • includ hardware şi software; • operatorii şi procesele operaţionale nu sunt considerate ca parte a sistemului; • sistemul nu este “conştient” se sine (self-aware). • Sisteme socio-tehnice • includ sisteme tehnice; • includ procesele operaţionale şi persoanele care utilizează şi interacţionează cu sistemul tehnic; • sunt guvernate de politici şi reguli organizaţionale.

  6. Caracteristicile sistemelor socio-tehnice • Are proprietăţi emergente • Proprietăţi de ansamblu ale sistemului care depind de componentele sistemului şi de relaţiile dintre acestea. • Non-deterministic • Nu produce întotdeauna aceeaşi ieşire pentru acelaşi set de intrare deoarece comportamentul sistemului este parţial dependent de operatorii umani. • Relaţii complexe cu obiectivele organizaţionale • Gradul în care sistemul sprijină obiectivele organizaţionale nu depinde doar de acesta.

  7. Proprietăţi emergente • Proprietăţi de ansamblu (globale) ale sistemului • Sunt consecinţă a relaţiilor dintre componentele sistemului • Pot fi evaluate şi măsurate doar după ce componentele au fost integrate în sistem

  8. Exemple de proprietăţi emergente

  9. Tipuri de proprietăţi emergente • Proprietăţi emergente funcţionale • Apar atunci când toate părţile sistemului lucrează împreună pentru a realiza un obiectiv. De exemplu, o bicicletă, odată ce a fost asamblată din componentele sale, are proprietatea funcţională de a fi un dispozitiv de transport. • Proprietăţi emergente non-funcţionale • Exemple: fiabilitatea, performanţa, siguranţa, securitatea. • Sunt corelate cu comportamentul sistemului în contextul său operaţional. • Sunt deseori critice pentru sistemele bazate pe calculatoare deoarece eşuarea în a realiza un nivel minim definit pentru aceste proprietăţi poate face ca sistemul să nu poată fi utilizat.

  10. Ingineria fiabilităţii sistemului • Defectele se pot propaga în sistem datorită inter-dependenţei între componente. • Defectele sistemului apar deseori din cauza inter-relaţiilor neprevăzute între componente. • Este probabilistic imposibil de anticipat toate relaţiile posibile între componente. • Rezultatele măsurătorilor asupra fiabilităţii software-lui pot da o imagine falsă a fiabilităţii sistemului.

  11. Influenţe asupra fiabilităţii • Fiabilitate hardware • Probabilitatea ca o componentă hardware să de defecteze şi durata reparării acesteia. • Fiabilitate software • Probabilitatea ca o componentă software să producă o ieşire incorectă. • Fiabilitate operator • Probabilitatea ca un operator al sistemului să facă o greşeală.

  12. Relaţii de fiabilitate • Un defect hardware poate genera semnale false care se află în afara domeniului intrarilor aşteptate de către software. • Erori software pot produce activarea de alarme care cauzează stresarea unui operator şi conduc la erori produse de acesta. • Contextul în care este instalat un sistem poate afecta fiabilitatea sa.

  13. Proprietăţi de tip interdicţie • Există proprietăţi care se exprimă ca interdicţii: • Siguranţă – sistemul nu trebuie să se comporte în manieră nesigură; • Securitate – sistemul nu trebuie să permită utilizare neautorizată. • Este dificil de măsurat sau evaluat aceste proprietăţi. Spre deosebire de acestea, • Proprietăţi ca performanţa şi fiabilitatea pot fi măsurate mai simplu.

  14. Ingineria sistemelor Se referă la: • Specificarea, proiectarea, implementarea, validarea, repartizarea şi întreţinerea sistemelor socio-tehnice; Se ocupă cu: • Serviciile oferite de sistem; • Constrângerile asupra construirii şi operării sistemului; • Modurile în care este utilizat sistemul.

  15. Procesul ingineriei sistemelor • Urmează în mod uzual modelul ‘waterfall’ datorită necesităţii de a dezvolta în paralel diferite părţi ale sistemului • Condiţii restrânse pentru realizare de iteraţii ale fazelor deoarece modificările hardware sunt foarte costisitoare. Software-ul poate avea sarcina de a compensa problemele hardware. • Implică în mod inevitabil ingineri din discipline diferite care trebuie să lucreze împreună • Posibilitate mare să apară înţelegeri greşite. Diferite discipline utilizează vocabulare diferite deci este necesară negociere îndelungată. De asemenea, inginerii pot avea agende proprii de realizat.

  16. Procesul ingineriei sistemelor

  17. Implicare inter-disciplinară

  18. Definirea cerinţelor sistemului • În acest stadiu se definesc trei tipuri de cerinţe: • Cerinţe funcţionale abstracte. Funcţiile sistemului sunt definite în manieră abstractă; • Proprietăţile sistemului. Sunt definite proprietăţile de ansamblu non-funcţionale ale sistemului; • Caracteristici indezirabile. Este specificat comportament inacceptabil pentru sistem. • Obiective organizaţionale globale ale sistemului.

  19. Obiectivele sistemului • Trebuie să definească motivul procurării sistemului pentru un context particular. Exemplu: • Obiective funcţionale • Oferirea unui sistem de alarmă incendii şi intruşi pentru o clădire, care va realiza averizare internă şi externă a incendiilor şi intruziunilor neautorizate. • Obiective organizaţionale • Să asigure faptul că desfăşurarea normală a activităţilor din clădire nu este afectată serios de evenimente ca incendii şi intruziune neautorizată.

  20. Cerinţe sistem: problematică • Sistemele complexe sunt de obicei dezvoltate pentru a adresa probleme dificile: • Probleme care nu sunt complet înţelese; • Probleme care se modifică pe măsură ce sistemul este specificat. • Trebuie anticipată evfoluţia hardware-lui/comunicaţiilor pe perioada de viaţă a sistemului. • Este dificil de definit cerinţele non-funcţionale (în particular) fără cunoaşterea structurii sistemului la nivel de componente.

  21. Procesul proiectării sistemului • Partiţionarea cerinţelor • Organizarea cerinţelor în grupuri pe bază de relaţii. • Identificarea sub-sistemelor • Identificarea unui set de sub-sisteme care pot realiza, în colectiv, cerinţele sistemului. • Alocarea cerinţelor pe sub-sisteme • Produce probleme specifice când sunt integrate componente COTS (Commercial, Off-the-Shelf). • Specificarea funcţionalităţii la nivel de sub-sistem. • Definirea interfeţelor sub-sistemelor • Activitate critică în cazul dezvoltării de sub-sisteme în paralel.

  22. Procesul proiectării sistemului

  23. Proiectarea sistemului: problematică • Partiţionarea cerinţelor între hardware, software şi componente umane poate implica negociere intensă. • Deseori se presupune că problemele dificile de proiectare sunt solvabile prin utilizare de software. • Platformele hardware pot fi nepotrivite pentru cerinţele software, lucru ce trebuie compensat de software.

  24. Cerinţe şi proiectare • Ingineria cerinţelor şi proiectarea sistemului sunt strâns legate. • Constrângerile impuse de contextul sistemului şi de alte sisteme limitează variantele de proiectare astfel încât poate deveni o cerinţă chiar utilizarea unui anume proiect. • Pentru a structura cerinţele poate fi necesară o etapă iniţială de proiectare. • Pe măsura desfăşurării proiectării se află lucruri noi referitoare la cerinţe.

  25. Modelul spirală pentru cerinţe/proiectare

  26. Modelarea sistemului • Un model arhitectural prezintă o perspectivă abstractă a sub-sistemelor ce formează un sistem • Poate include fluxuri majore de informaţii între sub-sisteme • Este prezentată de obicei ca diagramă bloc • Poate identifica diferite tipuri de componente funcţionale în model

  27. Sistem de alarmă anti-furt

  28. Descriere sub-sistem

  29. Arhitectură sistem (ATC) pentru control trafic aerian

  30. Dezvoltare sub-sistem • Proiecte (tipic) paralele pentru dezvoltare de hardware, software şi comunicaţii. • Poate implica procurare de sisteme COTS (Commercial Off-the-Shelf). • Lipsă de comunicare între echipele de implementare. • Mecanism birocratic şi lent pentru propunerea de modificări la sistem  orarul de dezvoltare poate necesita extindere datorită nevoii de relua unele activităţi.

  31. Integrare sistem • Procesul de a pune împreună hardware, software şi persoane pentru a construi un sistem. • Trebuie abordat incremental astfel încât sub-sistemele sunt integrate pe rând. • În acest stadiu apar în mod uzual problemele de interfaţă între sub-sisteme. • Pot să apară probleme cu furnizări necoordonate ale componentelor sistemului.

  32. Instalare sistem • După finalizare, sistemul trebuie instalat în contextul clientului • Premizele asupra contextului pot fi incorecte; • Poate să apară rezistenţă umană la introducerea unui nou sistem; • E posibil ca sistemul să fie nevoit să coincidă cu sisteme alternative pentru o anumită perioadă de timp; • Pot să apară probleme de instalare fizică (ex. probleme de cablare); • Trebuie identificate necesităţile de instruire a operatorilor.

  33. Evoluţie sistem • Sistemele mari au durate de viaţă lungi. Ele trebuie să evolueze pentru a îndeplini cerinţe în schimbare. • Evoluţia este în mod inerent costisitoare • Modificările trebuie analizate din perspectivă tehnică şi din perspectivă economică; • Pot să apară probleme neanticipate datorate interacţiunii sub-sistemelor; • Rareori există o raţiune fundamentată pentru deciziile originale de proiectare; • Structura sistemului este coruptă pe măsură ce apar modificări la ea. • Sistemele existente ce trebuie păstrate sunt numite uneori sisteme legacy.

  34. Dezafectarea sistemului Def. Scoaterea din funcţiune a sistemului la sfârşitul duratei de viaţă utilă. • Poate necesita îndepărtare de materiale (ex. chimicale periculoase) care poluează mediul • Trebuie pregătită în proiectarea sistemului prin încapsulare. • Poate necesita restructurarea şi conversia datelor pentru a fi utilizate în alt sistem.

  35. Organizaţii/persoane/sisteme • Sistemele socio-technice sunt sisteme organizaţionale destinate realizării unui scop organizaţional sau aplicativ (al afacerii). • Dacă nu este înţeles contextul organizaţional în care este utilizat sistemul, este mai puţin probabil ca acesta să îndeplinească cerinţele reale ale afacerii şi ale utilizatorilor lui.

  36. Factori umani şi organizaţionali • Modificări proces • Necesită sistemul modificări ale proceselor de lucru din contextul său? • Modificări job • Sistemul decalifică utilizatorii sau le impune să-şi modifice modul în care lucrează? • Modificări organizaţionale • Sistemul modifică structura puterii politice dintr-o organizaţie?

  37. Procesele organizaţionale • Procesele ingineriei sistemelor se suprapun şi interacţionează cu procesele organizaţionale pentru procurări. • Procesele operaţionale sunt procesele implicate în utilizarea sistemului pentru scopul căruia îi este destinat. Pentru sistemele noi, acestea trebuie definite ca parte a proiectării sistemului. • Procesele operaţionale trebuie proiectate astfel încât să fie flexibile şi să nu forţeze realizarea operaţiilor într-un mod particular. Este important ca operatorii umani să-şi poată utiliza iniţiativa atunci când apar probleme.

  38. Procesele de procurare/dezvoltare

  39. Procurare sistem Def. Achiziţionarea unui sistem pentru a îndeplini o cerinţă a organizaţiei. • De obicei este necesară specificare sistem şi proiectare arhitecturală înainte de procurare • Este nevoie de specificare pentru a lansa un contract de dezvoltare a sistemului • Specificarea poate permite cumpărarea unui sistem COTS (aproape întotdeauna mai ieftin decât dezvoltarea integrală a sistemului). • Sistemele mari şi complexe constau din combinaţii de componente COTS şi componente special proiectate. Procesele pentru procurarea acestor tipuri diferite de componente sunt în mod uzual diferite.

  40. Procesul pentru procurare sistem

  41. Problematica procurării • Cerinţele ar putea necesita modificare pentru a se potrivi capabilităţilor componentelor off-the-shelf. • Specificaţiile cerinţelor pot fi parte a contractului pentru dezvoltarea sistemului. • După ce a fost ales contractorul ce va construi sistemul, există de obicei o perioadă de negociere în cadrul contractului pentru acordul asupra modificărilor.

  42. Contractori şi sub-contractori • Procurarea de sisteme mari hardware/software gravitează de obicei în jurul unui contractor principal. • Sunt realizate sub-contracte cu alţi furnizori pentru a furniza părţi din sistem. • Clientul ţine legătura cu contractorul principal şi nu tratează direct cu sub-contractorii.

  43. Modelul contractor/sub-contractor

  44. Sisteme legacy • Sisteme socio-tehnice care au fost dezvoltate utilizând tehnologii vechi, depăşite. • Cruciale pentru operarea unei anumite afaceri şi uneori este prea riscant să fie dezafectate • Sistem de contabilizare pentru client bancar; • Sistem de întreţinere a avioanelor. • Sistemele legacy impun constângeri noilor procese economice (business) şi consumă o proporţie însemnată din bugetele companiilor.

  45. Sisteme legacy

  46. Componentele sistemelor legacy • Hardware – poate fi hardware depăşit de tip mainframe. • Suport software – se pot baza pe suport software de la furnizori care nu mai există. • Software de aplicaţie – pot fi scrise în limbaje de programare depăşite. • Data ale aplicaţiei – deseori incomplete şi inconsistente. • Procese economice – pot fi constrânse de structura şi funcţionalitatea software-lui. • Politici şi reguli economice – pot fi implicite şi încapsulate în software-ul sistemului.

  47. Arhitectura unui sistem socio-tehnic

  48. Puncte cheie • Sistemele socio-tehnice includ hardware, software şi persoane şi sunt proiectate pentru a realiza un anume scop economic. • Proprietăţile emergente sunt proprietăţi care sunt caracteristice sistemului în ansamblu şi nu părţilor lui componente. • Procesul ingineriei sistemelor include specificare, proiectare, dzvoltare, integrare şi testare. Integrarea sistemului este în mod deosebit critică.

  49. Puncte cheie • Factorii umani şi organizaţionali au un efect semnificativ asupra modului în care operează sistemele socio-tehnice. • Există interacţiuni complexe între procesele pentru procurarea, dezvoltarea şi operarea sistemelor. • Un sistem legacy este un sistem vechi care continuă să ofere servicii esenţiale. • Sistemele legacy includ procese economice, software de aplicaţii, software support şi hardware.

More Related