Arhitectura telematică

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Arhitectura telematică este proiectul executiv care descrie întreaga structură a informațiilor și a componentelor și echipamentelor de informare și comunicație care le gestionează [1] .

Definirea arhitecturii telematice a unei realități înseamnă crearea unui document de proiectare care grupează și unifică descrierile arhitecturilor hardware și software cu analizele și soluțiile operaționale și cu regulile și strategiile de gestionare a informațiilor și comunicațiilor. [2] [3] [4] [5] [6] [7] [8] Acest proiect are drept scop obținerea rezultatelor stabilite prin coordonarea strategică a procedurilor și documentelor altfel independente [9] .

Istorie

Studiul sistemelor telematice a început ca o ramură a tehnologiei informației care avea ca scop înțelegerea și raționalizarea administrării TIC în companii pentru a finaliza computerizarea sistemului informațional al companiei. Odată cu convergența tehnologiei informației și a telefoniei în sistemul telematic mai larg, subiectul a evoluat într-un domeniu superior de studiu în cadrul principalelor facultăți de administrație și management al afacerilor din lume.

Inițiat de analiza formulărilor planului de reglementare pentru CED (denumit Masterplan IT ), studiul metodologiilor de reprezentare a intrat prin lege în cursurile de studiu care vizează formarea personalului managerial, făcând esențială identificarea CIO să asiste consiliul.directiva cu privire la aceste chestiuni.

Scopul care trebuie atins cu cele mai recente studii este îmbunătățirea tehnicilor de proiectare pentru a îmbunătăți controlul, planificarea și gestionarea activităților și creșterea vitezei în procesarea datelor , informațiilor și comunicațiilor.

Ciclu de viață

Realizarea arhitecturii telematice se răspândește rapid în Italia și urmează aceste faze:

  • Identificarea nevoii : compania simte nevoia de a-și înțelege pe deplin structura tehnică pentru a urmări obiectivele instituționale;
  • Studiu de fezabilitate : consultantul este responsabil de definirea, de comun acord cu compania, a alternativelor posibile și efectuează o analiză inițială menită să stabilească o propunere pentru o cale critică pentru realizarea diferitelor componente ale arhitecturii.
  • Analiza cerințelor : constă în verificarea dacă premisele care au apărut în timpul studiului de fezabilitate sunt susținute de date. Această etapă necesită interacțiune cu utilizatorii
  • Analiza contextuală : urmărește să înțeleagă situația actuală și să colecteze documentația existentă.
  • Proiectare : în această fază se efectuează analiza funcțională și proiectarea arhitecturală și sunt definite procesele de afaceri care stau la baza vieții de zi cu zi în companie.
  • Dezvoltarea documentației : constă în crearea de documente de management în funcție de structura și caracteristicile definite în faza de proiectare; se preocupă, de asemenea, de dezvoltarea strategiilor de guvernanță TIC, oferind, pe cât posibil, toate condițiile de funcționare.
  • Validare : este momentul în care se întocmește lista componentelor de achiziționat pentru a aduce arhitectura la viteză. În acest pas, apare situația administrativă.
  • Instruire : sunt oferite cursuri de instruire și diferitele componente sunt activate în timp ce personalul este instruit cu privire la modul de utilizare a acestora.
  • Producție : în această fază arhitectura telematică devine operațională. Dacă nu apar defecțiuni sau revizuiri ale funcționalității, această activitate necesită doar operațiuni de gestionare și întreținere.
  • Întreținere : cu întreținerea corectivă sistemul este consolidat, în timp ce cu întreținerea evolutivă este completat și îmbogățit cu funcții care nu au fost identificate inițial.

Ciclul de viață menționat anterior provine din formalizarea sistemelor informaționale , diferențându-se în funcție de nevoile legate de arhitecturile de comunicare și de nevoile de studiu ale proceselor de afaceri; este bine să ne amintim că această cale trebuie adaptată la situațiile existente și se poate întâmpla ca în timpul executării unei activități să fie revizuite deciziile sau documentele anterioare.

Componente

Arhitectura telematică este compusă din setul de sisteme informaționale , tehnologice și de comunicații ale companiei și conține indicațiile referitoare la gestionare, întreținere, siguranță , rezolvarea problemelor , recuperarea în caz de dezastru și informațiile administrative necesare unui management adecvat [10] .

Analiza cerințelor

  • Lista obiectivelor care trebuie atinse
  • Verificarea imaginii generale care a apărut în timpul ședințelor introductive

Analiza contextului

  • Fotografie a situației actuale

Analiza funcțională

  • Descrierea fluxurilor de lucru IT interne
  • Reprezentarea sistemului intern de partajare a informațiilor IT
  • Formalizarea scării ierarhice și a sarcinilor individuale
  • Analiza proceselor
    • Reprezentarea proceselor de management obișnuite și extraordinare de către personalul IT
    • Reprezentarea proceselor de funcționare ale arhitecturii IT
    • Reprezentarea ciclului de viață al informației

Proiect arhitectural

Documentația de gestionare

  • Politica de atribuire și eliminare a numelui de utilizator
  • Liniile directoare pentru utilizarea parolelor și jetoanelor
  • Schema metodologică de rezervă
    • Plan intern și extern de protecție împotriva sabotajului
  • Reglementări de siguranță
  • Reglementări pentru actualizări hardware și software
    • Procedura de dezafectare și demontare a materialului învechit
  • Formalizarea listelor de verificare pentru operațiuni obișnuite și extraordinare
    • Planul de instruire a personalului
  • Reguli pentru gestionarea documentelor

Guvernarea TIC

Analiza nevoilor de ajustare

  • Descrierea oricăror componente care trebuie adăugate la arhitectura contextuală pentru a ajunge la soluția tehnologică
  • Estimarea posibilă a costurilor pentru adaptarea arhitecturii

Situația administrativă

  • Contracte de furnizare și întreținere.
  • Echilibrarea licenței software

Metodologii de proiectare, dezvoltare și descriere

De-a lungul timpului, s-au dezvoltat diferite metode pentru a reprezenta tot ceea ce se învârte în jurul CED și, mai general și în ultima vreme, departamentul TIC.

Reprezentarea blocului aferent

Prima metodologie de reprezentare a arhitecturilor telematice datează din anii 70 , născută din necesitatea de a face distincția între calculul concentrat și cel distribuit [11] . Inițial, utilizatorii la distanță se conectau la un singur computer centralizat (de exemplu, mainframe ) în care se afla toată puterea de procesare; odată cu apariția computerului personal, au fost ridicate întrebări cu privire la posibilitatea de a crea rețele complexe de mai multe computere conectate împreună într-un model tricotat, astfel încât informațiile să poată călători de la sursă la destinație urmând căi distincte. Deși primele proiecte au fost dezvoltate în scopuri militare în SUA , astăzi avem aplicații civile în multe medii, dintre care cel mai cunoscut este reprezentat de internet [12] .

Este o metodologie care are ca unic scop descrierea conexiunilor fizice și logice ale dispozitivelor care identifică nodurile și disting între diferitele tipuri de conexiuni: linii telegrafice , comutator telefonic și dedicat, poduri radio , sateliți pentru telecomunicații etc. [13]

Este o tehnică care a fost abandonată când s-a realizat că arhitectura telematică trebuia să se abstragă la un nivel mai înalt decât conexiunile fizice pentru a descrie corect complexitatea crescândă a sistemelor. Rămâne încă valabil ca tehnică de reprezentare pentru plantele fizice (nivelurile 1, 2 și 3 ale stivei ISO / OSI ).

Reprezentați lista

Metodologia istorică pentru descrierea situației tehnice este structurată ca o listă de echipamente și o listă de corelații; cele două liste sunt strâns legate între ele prin specificațiile proiectului sau conform regulilor de utilizare.

Este o metodologie care are ca scop principal inventarierea materialului prezent și controlul aprofundat al resurselor utilizate, atât tehnice, cât și economice; produce documentație foarte detaliată care vizează optimizarea cheltuielilor și TCO .

Este o tehnică născută înainte de convergența voce-date și nu permite ca cele două servicii să fie gestionate în același timp; infrastructura IT trebuie deci descrisă separat de infrastructura telefonică și combinația celor două descrieri oferă un cadru telematic complet.

Reprezentarea obiectelor

Cea mai acreditată metodologie de reprezentare a arhitecturii telematice se bazează pe conceptul de obiect și, prin urmare, ia numele de arhitectură de obiecte telematice ( ATO ).
Este o metodologie de reprezentare care integrează realitatea TIC în structura companiei, deoarece se bazează pe datele existente și pe situația actuală și o optimizează treptat: construiește documentația astfel încât fiecare clasă de obiecte să fie autoreferențială și să conțină atât informațiile și procedurile de operare pentru astfel de informații, structurate sau nu.

Obiectivul principal al implementării sale în companie este îmbunătățirea căilor de informare dintre clase și a relațiilor dintre obiecte în conformitate cu pași predefiniți și prealabili [14] . De asemenea, permite evaluarea și compararea scenariilor multiple pentru fiecare resursă, facilitând redactarea planurilor necesare pentru fiecare unitate funcțională, atât tehnică, cât și administrativă.

Este o tehnică relativ nouă, prevăzută cu documentație limitată, care îi obligă pe cei care o folosesc deja să învețe în domeniu, dar permite chiar și modificări radicale fără a pierde contactul cu realitatea companiei, produce toată documentația necesară pentru o mai bună exploatare a resurselor și garantează răspunsuri rapide și integrate în procesele de afaceri.

Acordarea

Reglarea înseamnă optimizarea arhitecturii formalizate anterior în funcție de parametrii de utilizare zilnică.

Pașii principali care trebuie urmați după punerea în producție a arhitecturii sunt verificarea conformității cu nevoile, rezolvarea problemelor evidențiate și adaptarea documentației pentru aceste patru clase de criticitate:

  1. Necesități zilnice de prim impact
  2. Răspunzând nevoilor pe termen scurt
  3. Analiza impactului pe termen mediu
  4. Raportarea notelor de amploare

Legislația italiană

Notă

  1. ^ Jessup, Leonard M.; Joseph S. Valacich (2008). Information Systems Today (ediția a 3-a). Editura Pearson. Glosar p. 416
  2. ^ Timothy Davis, Robert Geist, Sarah Matzko și James Westall, τ´εχνη: Un prim pas, în Simpozionul tehnic de educație în informatică , martie 2004, pp. 125-129 , ISBN 1-58113-798-2 .
    "În 1999, Universitatea Clemson a stabilit un program de absolvire (absolvent) care leagă artele și științele ... Toți studenții din program sunt obligați să finalizeze lucrări de nivel absolvent atât în ​​artă, cât și în informatică . "
  3. ^ Ken Hoganson, Modele alternative de curriculum pentru integrarea informaticii și analiza sistemelor informaționale, recomandări, capcane, oportunități, acreditări și tendințe , în Journal of Computing Sciences in Colleges , vol. 17, n. 2, decembrie 2001, pp. 313-325, ISSN 1937-4771 ( WC ACNP ) .
    „Domeniul sistemelor informaționale ca disciplină separată este relativ nou și este în continuă schimbare pe măsură ce tehnologia evoluează și domeniul se maturizează” .
  4. ^ Peter Denning, Ubiquity un nou interviu cu Peter Denning despre marile principii de calcul , vol. 2007, iunie, iunie 2007, pp. 1–1.
    "Oamenii din alte domenii spun că au descoperit procesele informaționale în structurile lor cele mai profunde și că colaborarea cu computerul este esențială pentru ei". .
  5. ^ Pearson Custom Publishing & West Chester University, Custom Program for Computer Information Systems (CSC 110), (Pearson Custom Publishing, 2009) Glosar p. 694
  6. ^ Jennifer Polack, Planificarea unei educații CSI într-un cadru CS , în Journal of Computing Sciences in Colleges , vol. 25, nr. 2, decembrie 2009, pp. 100–106, ISSN 1937-4771 ( WC ACNP ) .
  7. ^ CSTA Committee, Allen Tucker, și alții, A Model Curriculum for K-12 Computer Science (Raport final), (Association for Computing Machinery, Inc., 2006) Abstraction & p. 2
  8. ^ Peter Freeman și David Hart, A Science of Design for Software-Intensive Systems Informatica și ingineria au nevoie de un proces de proiectare riguros din punct de vedere intelectual, analitic, învățabil, pentru a asigura dezvoltarea sistemelor cu care putem trăi cu toții. , în Comunicări ale ACM , vol. 47, nr. 8, august 2004, pp. 19-21, ISSN 0001-0782 ( WC ACNP ) .
    „Deși conexiunile celorlalte componente la software și rolul lor în proiectarea generală a sistemului sunt esențiale, considerația de bază pentru un sistem intensiv în software este software-ul în sine, iar alte abordări ale sistematizării proiectării încă nu au rezolvat„ software-ul ” problema "- care nu va fi rezolvată până când nu se înțelege științific proiectarea software-ului" .
  9. ^ Sue Kelly, Nicola Gibson, Christopher Holland și Ben Light, Focus Issue on Legacy Systems Systems and Business Process Engineering: a Business Perspective of Legacy Information Systems , în Communications of the AIS , vol. 2, nr. 7, iulie 1999, pp. 1-27.
  10. ^ Shrader, CB, L. Taylor și DR Dalton (1984), „Planificarea strategică și performanța organizațională: o evaluare critică”, Journal of Management, 10, 149-171.
  11. ^ Michele Naso, ATLAS, Arhitecturi hardware și sisteme de calculatoare , 2007, ISBN 88-268-1014-1 .
  12. ^ Douglas E. Comer, The Internet Book , 2001, ISBN 0-13-030852-8 .
  13. ^ Andrew S. Tanenbaum, Rețele de calculatoare , 2000.
  14. ^ DJ Power, O scurtă istorie a sistemelor de asistare a deciziilor , la dssresources.com . Adus la 1 noiembrie 2010 .

Elemente conexe