Remedierea Modulelor Itsm

Cuprins

Capitolul I Alcatel-Lucent

Istorie și cronologie

Organizare

Segmente de operare

Cercetare și dezvoltare. Premii și distincții

Capitolul II. BMC ITSM Remedy

Sistemul de tichete ITSM Remedy

Managementul configurației și CMDB

Date de configurare

Consola locală de administrare

Interfață și orientări de mediu

Autentificarea în Remedy ITSM

Structura organizațională

Console de navigare, formulare și module

Bune practici

Capitolul III Remedierea modulelor ITSM.

Modulul de management al schimbărilor

Modulul de management al incidentelor

Modulul de management al problemelor

Erori cunoscute

Capitolul IV Proiectarea bazelor de date

Procesul de proiectare logica al bazei de date

Ciclul de viata. Durata de viata (lifecycles)

Necesitatea unei metodologii de dezvoltare a sistemelor axate pe date

Abordarea cu trei scheme

Ciclul de viata al unui proiect bazat pe date (data-driver)

Integrarea si schema conceptuala

Planificarea pentru un mediu baze de date

Capitolul V. Prezentarea aplicației

Capitolul VI. Concluzii

Capitolul I

Alcatel-Lucent S.A.

Alcatel-Lucent este o companie globală franceză de echipamente de telecomunicații, cu sediul în Boulogne-Billancourt, Franța. Alcatel-Lucent este specialistul de vârf în rețelistică IP, acces ultra-broadband și tehnologii cloud. Suntem dedicați în a face comunicațiile globale mai inovatoare, sustenabile și accesibile pentru oameni, companii și guverne din toată lumea. Misiunea este să inventăm și să livrăm rețele de încredere pentru a ajuta clienții să-și dezlănțuiască valoarea.

„Fiecare succes își are propria rețea”

Compania se concentrează pe echipamente de rețelistică fixe, mobile și convergente, tehnologii IP, software și servicii, cu operațiuni în peste 130 de țări. A fost numit Liderul Grupului Industrial pentru sectorul de Hardware și Echipamente Tehnologice în revizia Indicilor de Sustenabilitate Dow Jones 2014[2] și a fost listat în Tip 100 Inovatori Globali Thomson Reuters 2014 pentru al patrulea an consecutiv.[3] .

Alcatel-Lucent deține și Bell Laboratories, una dintre cele mai mari facilități de cercetare și dezvoltare din industria comunicațiilor, ai căror angajați au fost premiați cu opt Premii Nobel și compania deține peste 29.000 de brevete.

Directorul General al Alcatel-Lucent este Michel Combes și președintele neexecutiv al consiliului de administrație este Philippe Camus. Camus s-a alăturat companiei în al treilea trimestru al anului 2008, alături de Ben Verwaaven ca CEO, după ce primul CEO al Alcatel-Lucent, Patricia Russo, și primul președinte, Serge Tchuruk au demisionat.

[4] Pentru anul 2010, compania a realizat venituri de 16 miliarde EUR și o pierdere netă raportată de 334 milioane EUR.[5] Pentru 2011, veniturile au însumat 15 miliarde EUR, pierderea netă 1,1 miliarde EUR. Pentru anul 2012, veniturile au însumat 14,4 miliarde EUR iar pierderea netă 1,4 miliarde EUR.[6] După șapte ani consecutivi de flux negativ, în octombrie 2013 compania a anunțat planuri de concediere a 10.000 de angajați, sau 14% din forța de muncă totală curentă de 72.000, ca parte din eforturi de reducere a costurilor cu 1 miliard EUR.[7]

În iunie 2013, Michael Combes a anunțat „Planul de tranziție”,[8] un plan pe trei ani ce include reconcentrarea portofoliului pe rețelistică IP, acces ultra-broadband și cloud; 1 miliard de euro economii; vânzări de active selective cu scopul de a genera cel puțin 1 miliard de euro pe durata planului și restructurarea debitelor Grupului. La 1 octombrie 2014, a anunțat că a închis vânzarea subsidiarei sale Alcatel-Lucent Enterprise către China Huaxin Post & Telecommunication Economy Development Center.

Formarea Alcatel-Lucent în 2006 a creat primul real furnizor din lume de soluții de comunicații, cu cel mai complet portofoliu de soluții și servicii din industrie.

Pe 15 aprilie 2015, Nokia a anunțat că va achiziționa Alcatel-Lucent pentru suma de 15,6 miliarde EUR.[9]

Cum lucrăm

Planul de Tranziție este strategia noastră industrială. Acesta ne ghidează și ne inspiră operațiunile. În primul capitol al Planului de Tranziție, ne-am reconcentrat afacerea pentru a deveni specialiști în rețelistică IP, acces ultra-broadband și tehnologii cloud. Inventăm și livrăm rețelele inovatoare de mâine.

O nouă etapă începe cu capitolul 2 al Planului de tranziție. Suntem o companie revitalizată concentrată pe inovare, transformare și creștere. Vom merge mai departe cu transformarea noastră livrând servicii și software prin noi modele de afaceri de tip cloud. Și ne vom modela viitorul prin creștere, ajungând în noi segmente de piață și industrii.

Segmentul de rețelistică de bază

Segmentul nostru de rețelistică include trei divizii comerciale: IP Routing, IP Transport, și Platforme IP.

IP Routing 

Suntem lider mondial în IP routing și un partener de încredere pentru furnizori de servicii, întreprinderi și guverne ce doresc să-și transforme rețelele într-o arhitectură IP completă. Obiectivul nostru central este axat pe piața inteligentă de routere IP, piețele de rețelistică definite de softurile emergente (SDN) și servicii profesionale conexe. Tehnologia noastră permite clienților noștri să creeze o valoare sustenabilă prin construirea unei infrastructuri de rețea mai eficiente, capabile să sprijine noi servicii și experiențe mai bogate.

IP Transport 

Lider în rețelistica optică, ajutăm peste 1.000 de clienți să-și transforme infrastructurile de transmisie optică. Tehnologia noastră asigură transportul fiabil al datelor la cel mai mic cost pe bit și permite servicii și aplicații noi generatoare de venituri. Noi proiectăm, producem și comercializăm echipamente de rețea optice care transportă informațiile prin conexiuni de fibră optică pe distanțe lungi pe uscat (terestre) sau sub ape (submarine), precum și pe distanțe scurte în regiunile metropolitane și regionale. Portofoliul nostru include și servicii profesionale conexe și echipamente de transmisie wireless prin microunde.

Platforme IP 

Portofoliul nostru de platforme IP prezintă oferte software și de servicii care permit furnizorilor de servicii, jucătorilor web și întreprinderilor foarte mari să livreze, gestioneze, tarifele și optimizeze serviciile de comunicații voce și date. Produsele și serviciile noastre ajută furnizorii de servicii să creeze afaceri profitabile pe bază de date care respectă cererea în creștere, îmbunătățesc experiența utilizatorilor și accelerează inovația și creșterea veniturilor. Oferim softuri și servicii care permit furnizorilor de servicii să întrunească nevoile de evoluție din rețelele fixe și mobile. Produsele și soluțiile noastre se concentrează pe cele mai relevante domenii pentru clienții noștri: comunicații avansate, virtualizarea funcțiilor de rețea (NFV), experiența clienților, plata, politica și tarifarea, inteligența rețelei, sisteme de suport în operațiuni și servicii profesionale asociate.

Segmentul de acces

Segmentul nostru de acces include 4 divizii comerciale: Servicii Wireless, Acces Fix, Licențiere și Servicii Gestionate.

Wireless

Suntem unul dintre principalii furnizori din lume de infrastructură de comunicații wireless într-o varietate de tehnologii. Livrăm acces de nouă generație, de mare capacitate, care permite clienților noștri să își capitalizeze rapid și rentabil cererea în creștere pentru servicii mobile de bandă largă. Portofoliul nostru de acces wireless servește nevoilor operatorilor care caută o tranziție rapidă și decisivă la 4G/LTE. Ca atare, principalele noastre activități se concentrează pe livrarea soluțiilor de acoperire 4G/LTE, 3G/4G și soluțiilor mobile multistandard, și furnizarea serviciilor profesionale aferente. Portofoliul nostru de acces wireless include și produse wireless 3G (UMTS/HSPA/EV-DO) și 2G (GSM/GPR/EDGE/CDMA) și servicii profesionale asociate, precum și portofoliul de sisteme de radio-frecvență (RFS).

Acces fix

  Suntem lider mondial pe piața de acces fix de bandă largă, și sprijinim cele mai vaste implementări de servicii video, voce și date pe bandă largă. Suntem cel mai mare furnizor la nivel global al tehnologiei DSL (Digital Subscriber Line), al doilea cel mai mare furnizor al tehnologiei GPON și lider în vectoring VDSL2. Familia noastră de produse de acces fix IP și serviciile profesionale asociate asigură suport pentru DSL și fibră. Aceasta permite furnizorilor de servicii să extindă accesul ultra-broadband la spațiile clienților indiferent de tehnologie și să combine unitar tehnologiile de acces pe cupru și fibră și modelele de implementare FTTx. Inovațiile și expertiza noastră ajută furnizorii de servicii să atingă cel mai rapid profit din investiție și timp de lansare pe piață.

Licențiere 

Suntem unul dintre cei mai mari deținători de brevete din industria de telecomunicații. Deși avem puncte forte speciale în segmentele de rețea wireless, optică și date, brevetele noastre acoperă o gamă diversă de tehnologii. Grupul nostru de afaceri pe proprietate intelectuală lucrează pentru monetizarea portofoliului nostru de brevete prin licențiere și vânzări de brevete în același timp cu menținerea și continuarea brevetelor.

Servicii Gestionate

  Suntem furnizorul de top în materie de soluții inovatoare de servicii gestionate pentru piețele industriilor strategice și ale transportatorilor. Soluțiile noastre ajută clienții prin livrarea unui timp rapid de lansare pe piață, îmbunătățirea continuă a calității serviciului și un cost total redus sustenabil de exploatare. Portofoliul nostru de servicii gestionate include soluții BOMT (Built-Operate-Manager-Transfer), soluții de transformare a operațiunilor și servicii de operațiuni în rețea. Aceste servicii pot fi livrate într-o gamă largă de tehnologii de rețea, inclusiv acces în rețea (FTTx), rețele wireless de nouă generație (LTE, celule mici, 4G) și rețele IP.

Funcții transversale

Vânzări

Păstrând o abordare unică față de clienți, organizația de Vânzări este responsabilă pentru relația cu clienții. Echipele noastre de Vânzări dezvoltă și aplică noi oportunități de afaceri pentru toți clienții.

Operațiuni 

Grupul de Operațiuni este responsabil pentru executarea Planului de Tranziție, pentru tehnologia informației și pentru managementul și calitatea lanțului de aprovizionare.

Strategie și inovare

  Grupul de Strategie și Inovare supraveghează strategia și direcția tehnologică a Alcatel-Lucent, inclusiv Bell Labs. De asemenea, grupul administrează linia noastră de licențiere a proprietății intelectuale.

Calitate

Politica de Calitate Alcatel-Lucent păstrează grija față de client și satisfacția clientului pe primul loc în fiecare activitate pe care o întreprindem. Sistemul nostru de Management al Calității (QMS) – care include procesele, măsurile și uneltele pe care le folosim pentru a întâmpina așteptările de calitate ale clienților noștri – trece printr-un audit anual efectuat de o companie externă de certificare. De asemenea, sistemul trece printr-un audit extensiv de recertificare la fiecare 3 ani. Aceste audituri ne verifică îmbunătățirile continue și asigură respectarea standardelor de calitate ISO 9001 și TL 9000.

Funcții corporative

Resurse Umane

Echipa noastră de resurse umane asigură managementul, dezvoltarea și angajarea de personal pentru toți cei 62.000 de angajați ai Alcatel-Lucent.

Marketing

Echipele noastre de Marketing sunt responsabile pentru eforturile noastre globale de marketing, comunicări, relații publice, strategia de sustenabilitate corporativă și strategia de diversificare. Acestea conduc și dezvoltarea afacerii noastre în segmentele furnizorilor de servicii, industriilor și sectorului public.

Finanțe și Juridic

Echipa de Finanțe și Juridic este responsabilă cu finanțele corporative, guvernarea financiară, relația cu investitorii și aspectele legale.

Inovație și tehnologie

Angajamentul nostru pentru inovație este fundația a tot ceea ce facem pentru a ne ajuta clienții să-și dezlănțuiască valoarea și să conste certificare. De asemenea, sistemul trece printr-un audit extensiv de recertificare la fiecare 3 ani. Aceste audituri ne verifică îmbunătățirile continue și asigură respectarea standardelor de calitate ISO 9001 și TL 9000.

Funcții corporative

Resurse Umane

Echipa noastră de resurse umane asigură managementul, dezvoltarea și angajarea de personal pentru toți cei 62.000 de angajați ai Alcatel-Lucent.

Marketing

Echipele noastre de Marketing sunt responsabile pentru eforturile noastre globale de marketing, comunicări, relații publice, strategia de sustenabilitate corporativă și strategia de diversificare. Acestea conduc și dezvoltarea afacerii noastre în segmentele furnizorilor de servicii, industriilor și sectorului public.

Finanțe și Juridic

Echipa de Finanțe și Juridic este responsabilă cu finanțele corporative, guvernarea financiară, relația cu investitorii și aspectele legale.

Inovație și tehnologie

Angajamentul nostru pentru inovație este fundația a tot ceea ce facem pentru a ne ajuta clienții să-și dezlănțuiască valoarea și să construiască un succes sustenabil.

Folosind practica Bell Labs Consulting pentru a ne ajuta clienții să adreseze aspecte strategice și comerciale importante și să-și dezlănțuiască valoarea în rețea.

Inventăm viitorul prin unirea minților de top în Bell Labs cu o cultură de start-up care se extinde în toată compania. Echipele noastre rezolvă provocările majore de astăzi și dau formă viitorului industriei noastre. Transformăm modul în care ne conectăm, comunicăm și colaborăm.

Sfidăm status quo-ul lucrând în strânsă colaborare cu clienții și partenerii. Prin această colaborare, împingem limitele rețelelor de comunicare cu tehnologii revoluționare și ne ajutăm clienții să creeze noi modele de afaceri.

Angajamentul nostru poate fi văzut în cele 2,2 miliarde de Euro pe care le-am investit în cercetare și dezvoltare în anul 2014, reprezentând aproximativ 17% din vânzările noastre. Se poate vedea asta și în portofoliul nostru global de peste 33.000 de brevete active care cuprind o gamă largă de tehnologii.

Alte segmente

La 1 octombrie 2014, Alcatel-Lucent a anunțat că a încheiat vânzarea subsidiarei sale Alcatel-Lucent Enterprise către China Huaxin Post & Telecommunication Economy Development Center. Venitul rezultat pentru Alcatel-Lucent a fost de 202 milioane EUR.

Alcatel-Lucent va păstra un capital minoritar de 15% în întreprinderea vândută, precum și relații comerciale care să-i sprijine ambițiile de creștere sub noua structură de acționariat.

Cedarea Alcatel-Lucent Enterprise face parte din angajamentele Alcatel-Lucent din Planul de Tranziție. Lansat în iunie 2013, Planul de Tranziție reconcentrează Alcatel-Lucent ca specialist în acces IP, cloud și ultra-broadband în același timp cu realinierea balanței companiei. Planul va permite Alcatel-Lucent să implementeze economii de cost de 1 miliard de Euro și să genereze minim 1 miliard de Euro prin vânzări selective de active până la finele anului 2015.

Alcatel-Lucent Enteprise este lider mondial în soluții de comunicații și rețelistică pentru întreprinderi de toate mărimile, servind peste 500.000 de clienți din toată lumea.

China Huaxin Post & Telecommunication Economy Development Center ("China Huaxin" ) este o companie de investiții care caută oportunități de creștere comercială pe termen lung în sectorul Tehnologiilor Informației și Comunicațiilor (ICT).

Istoric

Fostul sediu Alcatel-Lucent până în 2009

Alcatel-Lucent a combinat două entități – Alcatel și Lucent Technologies – care au avut o descendență comună încă din anul 1983, anul în care compania-mamă a Alcatel, CGE (la Compagnie Generale d'Electricite), a cumpărat pachetul european de telecomunicații al ITT. Cu aproape 60 de ani mai devreme, ITT a achiziționat mare parte din operațiunile de producție AT&T din afara Statelor Unite. Lucent Technologies s-a născut din AT&T.

Alcatel-Lucent a luat naștere când Alcatel (prescurtarea de la Société Alsacienne de Constructions Atomiques, de Télécommunications et d'Électronique, o companie mică din Mulhouse absorbită de CGE în 1966) a fuzionat cu Lucent Technologies pe 1 decembrie 2006. Cu toate a cestea, predecesorii companiei au fost parte din industria de telecomunicații încă din secolul 19. Compania își are rădăcinile în două companii anterioare de telecomunicații: La Compagnie Générale d'Electricité (CGE) și Western Electric Manufacturing Company.[10]

Western Electric a început în 1869 când Elisha Gray și Enos N. Barton au organizat o mică firmă de producție în Cleveland, Ohio. Până în 1880, compania s-a relocat în Chicago, Illinois, și a devenit cea mai mare companie producătoare de energie electrică din Statele Unite. În 1881, American Bell Telephone Company, fondată de Alexander Graham Bell predecesor al American Telephone & Telegraph (AT&T), a achiziționat pachetul de control în Western Electric și s-a făcut dezvoltator și producător exclusiv de echipamente pentru companiile Bell Telephone.[10]

CGE a fost fondată în anul 1898 de inginerul francez Pierre Azaria în regiunea Alsace din ceea ce a fost apoi Germania și a fost un conglomerat implicat în industrii precum cea a transporturilor, electronicelor și telecomunicațiilor. CGE avea să devină lider în comunicații digitale și avea să devină cunoscut și pentru producerea trenurilor de mare viteză TGV (train à grande vitesse) în Franța.[10]

Alcatel One Touch 535, vedere frontală. (lansat în iulie 2003)

Bell Telephone Laboratories a fost creat în 1925 din consolidarea organizațiilor de cercetare și dezvoltare ale Western Electric și AT&T. Bell Labs avea să facă progrese științifice semnificative, inclusiv: tranzistorul, laserul, bateria solară, cipul de procesare a semnalelor digitale, sistemul de operare Unix și conceptul de celular al serviciului de telefonie mobilă. Cercetătorii Bell Labs au câștigat 7 premii Nobel.[10]

De asemenea, în 1925, Western Electric și-a vândut subsidiara International Western Electric Company către ITT Corporation. CGE a achiziționat partea de telecomunicații a ITT la jumătatea anilor 80.[10]

AT&T a reintrat pe piața de telecomunicații europeană în 1984 în urma cesiunii Bell System. Philips a promovat asocierea parțial deoarece tehnologia sa de comutație publică PRX era în curs de depășire și a vizat un partener pentru a finanța costurile de dezvoltare în switching digital. Compania comună a folosit facilitățile existente de producție și dezvoltare din Haga, Hilversum, Bruxelles, și Malmesbury precum și resursele SUA pentru a adapta sistemul 5ESS la piața europeană. Asocierea dintre AT&T și Philips Telecommunications BV și-a dublat cifra de afaceri anuală între 1984 și 1987, câștigând contracte majore de comutație și transmisie, în principal pe piața olandeză efectiv captivă. În 1987, AT&T și-a crescut acționariatul la 60% și în 1990 a achiziționat restul pachetului deținut de Philips.

În 1998, Alcatel Alsthom s-a reorientat spre industria de telecomunicații, schimbându-și activitățile Alsthom și denumirea companiei în Alcatel. AT&T a scindat Lucent Technologies în aprilie 1996 cu o licitație publică inițială.[10]

Regiuni ale lumii pe care Alcatel-Lucent le deservește.

În aprilie 2004, TCL Corporation și Alcatel au anunțat crearea unei asocieri pentru producția de telefoane mobile: Alcatel Mobile Phones.

Campusul Alcatel-Lucent în Germania.

Confruntându-se cu o intensă concurență în industria de telecomunicații, Alcatel și Lucent Technologies au fuzionat la 30 noiembrie 2006.[11]

Pe 5 aprilie 2006, Alcatel a anunțat că își va schimba acțiunile din Alcatel Alenia Space și Telespazio pentru 673 milioane EUR și un interes de 12,1% în Thales, jucător cheie în industria de apărare franceză. Aceasta a crescut participația Alcatel în Thales la 20,8%.[10]

Alcatel-Lucent a achiziționat întreprinderea de acces radio UMTS a Nortel la finele anului 2006. În anul 2007, compania a achiziționat furnizorul de rețelistică WDM metropolitan canadian Tropic Networks, Inc.; dezvoltatorul de produse gateway pentru servicii enterprise NetDevices; compania de softuri Tamblin; și cabinetul de consultanță în telecomunicații Thompson Advisory Group, Inc. Alcatel-Lucent a achiziționat Motive, Inc., furnizor de software pentru management servicii de date mobile și de bandă largă în 2008.[10] Aceștia au avut anterior o asociere cu compania olandeză Draka Holding N.V. pentru producția de fibră optică, dar Draka a cumpărat pachetul de 49,9% al Alcatel-Lucent pentru 209 milioane EUR în decembrie 2007.[12]

În mai 2009, participația Alcatel-Lucent în Thales a fost achiziționată de Dassault Aviation.[13] Alcatel-Lucent a anunțat achiziția OpenPlug pe 1 septembrie 2010.[14]

În octombrie 2011, Alcatel-Lucent și-a vândut întreprinderea de servicii call center Genesys către Permira, un grup privat, pentru 1,5 miliarde USD – aceeași sumă cu care compania a cumpărat afacerea în 2000. Alcatel-Lucent avea nevoie de finanțare pentru afacerea franco-americană, care a produs pierderi anuale între 2007 și 2011[15]

Pe 15 aprilie 2015, firma finlandeză de telecomunicații Nokia și-a anunțat intenția de a achiziționa Alcatel-Lucent pentru suma de 15,6 miliarde EUR într-o tranzacție pe bază de capital. Achiziția are scopul de a crea un competitor mai puternic față de firmele rivale Ericsson și Huawei, pe care Nokia și Alcatel-Lucent le-a depășit în ceea ce privește venitul total combinat în 2014. Achiziția se așteaptă să fie finalizată la începutul lui 2016 și face obiectul aprobării de reglementare. Divizia Bell Labs va fi păstrată, dar brandul Alcatel-Lucent va fi înlocuit cu Nokia.[9][16][17]

Cronologie

Alcatel

1898 – Inginerul francez Pierre Azaria înființează Compagnie Générale d'Électricité (CGE).

1925 – CGE devine parte din Compagnie Générale des Câbles de Lyon. Este creată Bell Telephone Laboratories.

1928 – Alsthom este înființată de Société Alsacienne de Constructions Mécaniques and Compagnie Française Thomson-Houston.

1950 – Vezi ITT Kellogg > ITT Telecommunications > Alcatel http://www.encyclopedia.chicagohistory.org/pages/2736.html

1970 – Ambroise Roux devine președintele CGE. Devine apoi președinte de onoare până la moartea sa în 1999.

1982 – Jean-Pierre Brunet devine președintele CGE.

1984 – Georges Pebereau devine președintele CGE. Thompson Telecommunications este absorbită de CGE.[18] Cables de Lyon cumpără Thompson Jeumont Cables și Kabelmetal.

1985 – Alsthom Atlantique devine Alsthom. Alcatel este înființată la fuziunea dintre CIT-Alcatel și Thompson Telecommunications.[19]

1986 – ITT Corporation își vinde întreprinderea de telecomunicații din Europa către CFE în baza acordului său cu Alcatel NV. Cables de Lyon devine subsidiară a Alcatel NV.[20] Pierre Suard devine președintele CGE.

1987 – CGE este privatizată.[21] Alsthom câștigă contractul pentru TGV Atlantique pentru rețeaua TGV din nord.

1989 – CGE și General Electric Company formează GEC Alsthom. Aceasta permite Alsthom să-și vândă produsele în afara Franței. CGEE-Alsthom devine Cegelec. AT&T Technologies se reorganizează cu următoarele unități de afaceri: Sisteme de rețea, Comunicații comerciale globale, Microelectronică și Produse de consum.

1991 – CGE își schimbă denumirea în Alcatel Alsthom. Achiziționează divizia de echipamente de transmisie a Rockwell Technologies.[22][23][24] Cables de Lyons este redenumită în Alcatel Cable și preia AEG Kabel.

1991 – Alcatel achiziționează Telettra, companie a Italian Telecommunication Systems.

1992 – Alcatel Alsthom achiziționează AEG Kabel.

1993 – Alcatel Alsthom achiziționează STC Submarine systems, denumită de acum Nortel Networks.

1995 – Serge Tchuruk este numit în funcția de președinte și director general al Alcatel Alsthom. Acesta a restructurat compania pe echipamente de telecomunicații.[25]

1998 – Alcatel Alsthom a scindat. Aslthom GEC devine Alstom prin IPO (Alcatel păstrând 24%). Alcatel vinde Cegelec la noul Alstom. Alcatel achiziționează DSC Communications pentru suma de 4,4 miliarde USD[26] și Packet Engines[27]

1999 – Alcatel achiziționează Xylan, Assured Access și Internet Devices. Alcatel își crește participația în Thomson CSF la 25,3% și o scade în Framatome la 8,6%.

2000 – Alcatel achiziționează Newbridge, Genesys și Innovative Fibers. Alcatel scindează unitatea de cabluri în Nexans.[28] Lucent scindează Avaya Inc.

2001 – Alcatel își vinde participația în Alstom. Alcatel cumpără înapoi Alcatel Space de la Thales și își reduce participația în Thales la 20,3%. Alcatel își vinde participația de 2,2% în Areva. Alcatel vinde întreprinderea de modemuri DSL către Thomson Multimedia. Lucent scindează unitatea de microelectronică în Agere Systems prin IPO.

2002 – Alcatel achiziționează Astral Point Communications Inc., Telera Corporation, și controlul asupra Alcatel Shanghai Bell. Alcatel își vinde unitatea de microelectronică către STMicroelectronics, participația în Thomson, 10,3 mil. acțiuni în Thales și 1,5 mil. acțiuni în Nexans.

2003 – Alcatel achiziționează iMagicTV, și TiMetra Inc. It vinde o participație de 50% în Atlinks și unitatea sa optică către Avanex.

2004 – Alcatel achiziționează eDial Inc. Alcatel și TLC formează o asociere în participațiune: Alcatel Mobile Phones, Alcatel având o participație de 45%. Alcatel și Draka Holdings formează o asociere în participațiune: Draka Comteq B.V. cu Alcatel având o participație de 49,9%.[29] Alcatel își finalizează achiziția Spatial Wireless dar vinde 7,1 mil. acțiuni din Avanex.

2005 – Alcatel își vinde participația de 45% din asocierea Alcatel Mobile Phones înapoi către TCL.[30]

AT&T, Lucent Technologies

1869 – Elisha Gray și Enos N. Barton au înființat Western Electric Company.

1927 – Bell Labs realizează prima transmisie de televiziune pe distanță lungă din America, între New York și Washington DC.[31]

1937 – Dr. Clinton Davisson devine primul dintre cei 11 câștigători ai Premiului Nobel de la Bell Labs pentru confirmarea sa experimentală a naturii undei electronilor.

1946 – Western Electric produce peste 4 milioane de telefoane.[32]

1947 – Bell Labs inventează tranzistorul. Douglas H. Ring și W. Rae Young de la Bell Labs scriu un memorandum intitulat Telefonia mobile – Acoperire pe suprafețe vaste – Cazul 20564, folosind celule „hexagonale” pentru frecvență radio.[33]

1948 – Claude Shannon, de la Bell Labs, publică o lucrare privind Teoria Informației.

1954 – Bell Labs inventează bateria solară.

1956 – AT&T este implicată în eforturile TAT-1, primul cablu de telefonie submarin trans-atlantic, ce administrează până la 36 de canale. Au fost folosite amplificatoare electrice create de Bell Labs. Pentru soluționarea procesului anti-trust, Western Electric (anterior AT&T) vinde întreprinderea de echipamente non-rețea.[34]

1957 – Laserul este inventat la Bell Labs.

1962 – Bell Labs construiește și lansează Telstar1, primul satelit de comunicații activ de pe orbită.

1969 – Este inventat sistemul de operare Unix de către Ken Thompson și Dennis Ritchie.

1978 – Bell Labs conduce prima probă a unui serviciu comercial de telefonie mobile în Chicago.

1980 – Bell Labs anunță procesorul de semnal digital.[35]

1983 – AT&T instalează primul sistem de transmisie de mare capacitate pe distanțe lungi între NYC și Washington DC.[36]

1996 – Lucent Technologies lansează IPO, cel mai mare la acel moment.

1998 – Lucent achiziționează Yurie Systems de la Jeong Kim pentru suma de 1,1 miliarde USD.[37][38]

2002 – Patricia Russo devine directorul general al Lucent.

2003 – Patricia Russo devine președintele Lucent.

2004 – Lucent raportează primul an profitabil și o creștere a veniturilor din 2000.

2005 – Jeong Kim devine al 11-lea președinte al Bell Labs.

Alcatel-Lucent

2006 – Alcatel își vinde satelitul, domeniul de securitate critică și semnalizare feroviară către Thales. Pe 30 noiembrie, Alcatel și Lucent fuzionează. Se formează Alcatel-Lucent. Alcatel-Lucent achiziționează întreprinderea de acces radio UMTS de la Nortel.

2007 – Alcatel-Lucent achiziționează Tropic Networks, NetDevices, Thompson Advisory Group, și Tamblin.

2008 – Alcatel-Lucent achiziționează Motive Inc. Ben Verwaayen devine al doilea director general al Alcatel-Lucent.

2009 – Alcatel-Lucent își vinde participația rămasă în Thales și își externalizează activitățile IT către HP.

2011 – Wim Sweldens conduce un grup wireless pentru dezvoltarea lightRadio, o tehnologie pentru reducerea dimeniunii turnurilor celulare la mici cuburi.[39]

2012 – Alcatel-Lucent vinde Genesys Labs către Permira[40]

2015 – Nokia Corporation achiziționează Alcatel-Lucent pentru 16,6 miliarde USD[41][42]

Organizare

Sediul global al companiei se află în Boulogne-Billancourt, Franța.[43] Și-a avut sediul anterior în al 7-lea arondisment din Paris, Franța , și în al 8-lea arondisment dinParis, Franța.[44] Sediul său anterior, din al 8-lea arondisment din Paris, a fost construit între 1912 și 1929 și a fost renovat în 1998. În timpul renovării, clădirea a fost decorată cu o temă a cosmosului și timpului.[45]

Există grupuri regionale pentru cele două Americi, Asia Pacific și China, Europa, Orientul Mijlociu și Africa.[46] Sediul pentru orientul Mijlociu și Africa se află la Smart Village, Giza, Egipt.[47] Alcatel a fost prezentă în Italia cu diferite centre de cercetare: Vimercate (în Lombardia), Rieti, Battipaglia, Trieste, Genova, Bari, Napoli, Roma și Sesto Fiorentino. Începând cu 2014, este prezentă doar în Vimercate (în Lombardia), Trieste, Roma.

Consiliul de Administrație

[48]

Philippe Camus (Președinte)

Michel Combes (Director General)

Stuart Eizenstat

Louis Hughes

Carla Cico

Jean Monty

Olivier Piou

Jean-Cyril Spinetta

Kim Crawford Goodman

Véronique Morali

– Francesco Caio

Echipa de conducere

[49]

Michel Combes, Director General

Basil Alwan, IP routing & IP transport

Bhaskar Gorti, platforme IP

David Geary, Wireless

Federico Guillen, Rețele fixe

Philippe Guillemot, Operațiuni

Philippe Keryer, Strategie și Inovare

Jean Raby, Director Financiar

Nicole Gionet, Resurse Umane

Tim Krause, Director de Marketing

Segmente de operare

Segmentul de rețelistică include trei divizii comerciale: IP Routing, IP Transport, și Platforme IP. Segmentul de acces include 4 divizii comerciale: Servicii Wireless, Acces Fix, Licențiere și Servicii Gestionate.

Cercetare și dezvoltare

Bell Labs este organizația de cercetare și dezvoltare a Alcatel-Lucent .[50]

In 1876, Alexander Graham Bell a primit primul brevet pentru telefon și ulterior a înființat AT&T.[51] Bell Labs este denumită în onoarea sa.

În 1937, Clinton Davisson a câștigat Premiul Nobel pentru fizică pentru demonstrarea naturii undelor materiei. Munca sa fundamentală este parte din fundația pentru mare parte dintre electronicele solide de astăzi.

În 1947, John Bardeen, Walter Brattain, William Shockley de la Bell Labs au inventat tranzistorul. În 1956, aceștia au primit Premiul Nobel pentru invenția lor. Tranzistorul a condus la o revoluție a electronicelor în perioada postbelică. Tranziția de la lămpi la tranzistori a permit construirea tuturor tehnologiilor la o scală mai mică și la un consum mai mic de electricitate. Lucruri care anterior aveau nevoie de spații mari dedicate se puteau încadra acum într-o casă sau chiar pe un blat de bucătărie.[52]

În 1954, Gerald Pearson, Darryl Chapin, și Calvin Fuller au inventat celula solară. Telstar, primul satelit activ de comunicații, de asemenea dezvoltat de Bell Labs și lansat în 1962, a folosit bateriile cu celulă solară ca sursă externă regenerabilă de energie imediat ce a fost lansat. A fost primul care a transmis semnalul TV în timp real peste ape, între Anglia și SUA.

Spre sfârșitul anilor 50, Charles Townes și Arthur Shawlow de la Bell Labs au inventat laserul, care are numeroase aplicații, inclusiv măsurare și tăiere în industria producției și cercetare/ chirurgie în industria medicală. Bell Labs a primit brevetul pentru laser în 1960.

În 1964, Arno Allan Penzias și Robert Woodrow Wilson au descoperit radiația cosmică de microunde de fond. Aceștia au primit Premiul Nobel pentru Fizică în 1978.

În 1969, Dennis Ritchie și o echipă de angajați Bell Labs au inventat sistemul de operare UNIX și limbajul de programare C.

În 2006, Willard S. Boyle șiGeorge E. Smith au câștigat premiul Academiei Naționale de Inginerie, pentru lucrul asupra dispozitivelor CCD care transformă tipare de lumină în informații digitale utile. În 2009, aceștia au primit Premiul Nobel pentru invenția lor. Dispozitivul este folosit pe scară largă în camere digitale, camere video și astronomie modernă.

În 2013, s-a realșizat o investiție netă în cercetare și dezvoltare de 2,3 miliarde EUR (aprox. 16% din vânzări). Sunt peste 32.000 de brevete active, peste 3.000 obținute în 2013 și 14.900 de cereri în așteptare.

Premii și distincții

Iulie 2013 – într-untest condus în campusul Alcatel-Lucent din Villarceaux (lângă Paris), cercetătorii Bell Labs au realizat cu succes o transmisie de date de la o viteză de 31 terabiți pe secundă (T-bps) la o distanță de 7.200 km, o capacitate de peste trei ori mai mare decât cele mai avansate cabluri comerciale submarine care există astăzi.

Investigatorii au putut obține o capacitate mai mare ca oricând în transmisia datelor sub ape cu o singură fibră. Acest experiment s-a bazat pe pionieratul Bell Labs în canale de date pe un singur purtător de 200 gigabiți pe secundă (Gbit/s). Deoarece vitezele și distanțele la asemenea distorsiuni de semnal și zgomot fac recuperarea datelor o reală provocare, cercetătorii au folosit tehnici inovatoare de detectare și au aplicat un nou set de tehnologii de modulare, transmisie și procesare împreună cu o codificare avansată a corecțiilor de eroare.[53]

Martie 2012 – Alcatel-Lucent a fost selectată de Technology Review în lista sa TR50 pe 2012 cu cele mai inovatoare companii din lume. Revista a recunoscut tehnologia lightRadio de la Alcatel-Lucent ca o „inovație cheie”.[54]

Februarie – martie 2012 – Alcatel-Lucent câștigă Premiul Congresului Mondial Mobil pentru cea mai Bună Tehnologie de Infrastructură, pentru rețeaua lightRadio.[55]

Capitolul II

BMC ITSM Remedy

ITSM Remedy

ITSM înseamnă sau provine de la „Information Technology Service Management” (Managementul Serviciilor din Tehnologia Informației). Acesta este un concept preluat din ITIL sau IT Infrastructure Library și este definit ca bună practică pentru gestionarea serviciilor. BMC a scris o suită de aplicații în familia Remedy care furnizează o serie de funcții sau procese ITIL predefinite.

BMC Remedy ITSM eficientizează și automatizează procesele din centrul de servicii IT, operațiuni de management al patrimoniului și managementul schimbărilor. De asemenea, vă permite să vă corelați serviciile comerciale cu infrastructura IT pentru a putea gestiona impactul schimbărilor tehnologice asupra afacerilor și schimbărilor comerciale asupra tehnologiei – în timp real și în viitor. În plus, puteți înțelege și optimiza experiența utilizatorului, echilibra investițiile actuale și viitoare în infrastructură și vedea eventualul impact asupra afacerii folosind un model de servicii în timp real Toate acestea vă ajută să gestionați ceea ce contează pentru a livra un Management al Serviciilor Comerciale (BSM).

Fiecare aplicație BSM conține consolele, formele, legăturile active, escaladările, flashboard-uri și așa mai departe, necesare pentru executarea funcțiilor sale de bază. Aplicațiile folosesc și mai multe module integrate și aplicații de suport care extind și îmbunătățesc aceste funcții de bază.

BMC Remedy ITSM eficientizează și automatizează procesele din centrul de servicii IT, operațiuni de management al patrimoniului și managementul schimbărilor. De asemenea, vă permite să vă corelați serviciile comerciale cu infrastructura IT pentru a putea gestiona impactul schimbărilor tehnologice asupra afacerilor și schimbărilor comerciale asupra tehnologiei – în timp real și în viitor. În plus, puteți înțelege și optimiza experiența utilizatorului, echilibra investițiile actuale și viitoare în infrastructură și vedea eventualul impact asupra afacerii folosind un model de servicii în timp real Toate acestea vă ajută să gestionați ceea ce contează pentru a livra un Management al Serviciilor Comerciale (BSM). Fiecare aplicație BSM conține consolele, formele, legăturile active, escaladările, flashboard-uri și așa mai departe, necesare pentru executarea funcțiilor sale de bază. Aplicațiile folosesc și mai multe module integrate și aplicații de suport care extind și îmbunătățesc aceste funcții de bază.

În Alcatel-Lucent, ITSM este principalul Sistem de Ticketing pentru Proiecte de Servicii Gestionate și un sistem conform cu procesul ITIL. Pentru folosirea Proiectelor de Servicii Gestionate, sistemul urmează Procesul Trouble 2 Resolve (T2R) pentru Managementul Incidentelor, Problemelor și Schimbărilor.

Mai jos se află o descriere a aplicațiilor din suită:

Service Desk

Service Desk conține Managementul Incidentelor și Managementul Problemelor. Aceste două unelte arată și se comportă similar dar deservesc funcții diferite.

Managementul incidentelor este cel mai bine definit ca fiind procesul prin care operațiunile normale de servicii sunt restaurate cât mai rapid posibil și pentru minimalizarea impactului asupra operațiunilor comerciale, astfel asigurând cel mai ridicat nivel posibil de calitate și disponibilitate a serviciului.

Managementul Problemelor este cel mai bine definit ca fiind efortul de rezolvare a cauzei de bază a incidentelor și astfel de minimalizare a impactului advers al incidentelor și problemelor asupra activității, acestea fiind cauzate de erori ale infrastructurii IT.

Managementul configurației și CMDB

Managementul Configurației este un proces care monitorizează toate elementele de configurare (CI – Configuration Items) dintr-un sistem. Acest proces este îndeplinit în mod normal prin fuzionarea datelor dintr-o serie de unelte de descoperire și surse de date existente într-o singură sursă de date denumită Configuration Management Database sau CMDB.

Folosind CMDB, puteți elabora relații și dependențe de date între Servicii, sisteme, hardware, rețea, persoane și alte componente ale infrastructurii.

Managementul Schimbărilor

Scopul Managementului Schimbărilor este să asigure că sunt folosite metode și proceduri standardizate pentru gestionarea eficientă a tuturor schimbărilor din infrastructură, pentru a minimaliza impactul incidentelor legate de schimbare și îmbunătăți operațiunile de zi cu zi.

Managementul calității serviciilor

Managementul calității serviciilor asigură identificarea, monitorizarea și analiza continuă a nivelurilor serviciilor IT specificate în acordurile privind calitatea serviciilor (SLAs). Managementul calității serviciilor asigură că există aranjamente cu furnizorii de suport IT interni și furnizorii externi în forma Acordurilor privind Nivelul Operațional (OLA) și Contractelor de Bază (UC). Procesul implică evaluarea impactului schimbării asupra calității serviciului și SLA. Procesul de management al calității serviciului este în strânsă relație cu procesele operaționale pentru controlul activităților. Rolul central al managementului calității serviciilor îl face locul central pentru stabilirea și monitorizarea valorilor contra unei valori de referință.

Managementul calității serviciului Remedy este foarte strâns integrat cu Managementul Incidentelor, Problemelor și Schimbării pentru a vă ajuta să definiți, gestionați și să raportați cu privire la Acordurile privind calitatea serviciului (acordurile cu clientul) și Acordurile privind Nivelul Operațional (obiective interne de servicii).

Managementul cunoștințelor

Managementul cunoștințelor este o unealtă BMC care se integrează unitar cu suita ITSM. Aceasta permite furnizorilor de suport să aducă soluții în baza de cunoștințe din Managementul Incidentelor, Problemelor sau Schimbărilor. Partajarea cunoștințelor în tot campusul va fi o unealtă foarte puternică.

Date de configurare

Datele de Configurare este o componentă esențială în proiectul centrului de servicii Remedy și toate aplicațiile Remedy ITSM. Folosind unelte administrative, se poate crea o secțiune izolată sau o „ocupație temporară” în sistem pentru organizația dvs. Echipa de suport Remedy a făcut deja asta pentru dvs.

Fiecare ocupare temporară este denumită drept o companie. Fiecare companie conține organizații de suport și grupuri de suport. Fiecare grup de suport are membri sau „furnizori de suport”. Ca și conducere funcțională a companiei dvs., veți fi responsabili pentru administrarea acestor date.

Consola locală de administrare

Consola locală de administrare este o aplicație personalizată pe care Alcatel a conceput-o pentru a permite unităților din toată compania să-și administreze propriile date de configurare. Contul Remedy va primi permisiuni speciale pentru ca dvs. să puteți accesa această consolă.

Figura 2.1

Interfață și orientări de mediu

Mediul de producție

Mediul de producție Remedy este folosit doar pentru satisfacerea nevoilor ITSM în stare constantă. Acesta nu este folosit pentru testarea schimbărilor și configurațiilor. Sistemul de producție procesează sute de mii de Incidente și alte date critice în fiecare an. Este folosit de sute de furnizori de suport din toată întreprinderea pentru monitorizarea și partajarea activității lor.

Pentru a putea accesa serverul de producție, se foloseste un navigator web cu acest URL, ca cel de mai jos:

http://global-itsm-css.de.alcatel-lucent.com:8080/arsys/shared/login.jsp?/arsys/home

Mediul de test

Mediul de test Remedy este pus la dispoziția tuturor partenerilor din campus în scopul testării. Acesta este accesat ușor ca și mediul de producție dar nu deține date în timp real sau date critice. Mediul de test este configurat în hardware și software să fie identic în majoritatea modurilor cu mediul de producție.

Schimbările aduse la datele de configurație pentru producție nu sunt mutate automat la test. Dacă doriți să aveți un mediu de test curent, este necesar să faceți modificări în ambele locuri. De două ori pe an, echipa de suport va programa o „reîmprospătare” a testului pentru a se asigura că acesta rămâne utilizabil în sincronizare cu producția.

Pentru a putea accesa serverul de test, se foloseste un navigator web cu acest URL, ca cel de mai jos:

http://149.204.78.16:8080/arsys/shared/login.jsp?/arsys/

Mediul de dezvoltare

Doar personalul de suport Remedy folosește mediul de dezvoltare Remedy. Funcția sa este să permită personalului de suport să dezvolte schimbări în sistem. Acesta nu este disponibil în prezent pentru comunitate.

Autentificarea în Remedy ITSM

Când vă autentificați pentru prima dată în sistem vi se va prezenta pagina de plecare – Home. Această pagină vă furnizează o serie de legături care vă duc la diferite componente ale suitei ITSM.

Deși sunt multe componente pe care le puteți accesa din pagina Home, acest document va folosi doar două aplicații: Consola locală de administrare și Consola de management al incidentelor.

Structura organizațională

Compania

Domeniul companiei este un container care definește o nouă „ocupare temporară” în suita de aplicații Remedy ITSM. Există multe setări, filtre și date de configurare specifice companiei.

În cadrul companiilor, definim două divizii logice (seturi de containere) care sunt folosite în două scopuri diferite, Organizații și Organizații de Suport. În fiecare dintre acestea există Departamente și Grupuri de Suport.

Înțelegerea Organizațiilor de Suport și Grupurilor de Suport

În mod tipic, ne „ridicăm” entitățile la nivel departamental, precum „Tehnologia Informației” atunci când creăm Organizații de Suport (vezi Figura 2.2). Aceasta ne permite să creăm un număr nelimitat de grupuri de suport în acea organizație de suport.

Grupurile de suport joacă un rol major în definiția companiei dvs. Când domeniul Companiei și domeniile Organizațiilor de Suport sunt containere organizaționale, Grupurile de Suport sunt singurul loc unde pot fi atribuite Incidente. Nu puteți atribui incidente la o Organizație de Suport sau Companie.

Crearea Organizațiilor și Departamentelor

Pentru a crea o nouă organizație sau departament:

Deschideți Consola locală de administrare și în dreapta Organizației faceți click pe Create. Apare o fereastră cu titlul „Organization”.

Pentru a crea o nouă organizație, tastați numele în a doua căsuță etichetată cu Organization.

Pentru a crea un nou departament, tastați numele în a treia căsuță etichetată cu Department.

Revizuiți datele și prezentarea valorilor pe care le-ați introdus manual. Imediat ce aceste valori sunt aplicate la evidențe, realizarea modificărilor devine dificilă.

Faceți click pe butonul Add pentru a crea Organizația/ Departamentul introdus.

Dacă doriți să creați mai multe, repetați acești pași. Dacă nu, faceți click pe butonul Close.

Figura 2.2

Crearea Organizațiilor de Suport și Grupurilor de Suport

Deschideți Consola locală de administrare și în dreapta Grupului de Suport faceți click pe Create. Apare o fereastră cu titlul „Support Group”.

Figura 2.3

Pentru a crea o nouă organizație de suport, tastați numele în a doua căsuță etichetată cu Support Organization.

Pentru a crea un nou grup de suport, tastați numele în a treia căsuță etichetată cu Support Group.

În final, selectați cel mai potrivit nivel de suport pentru acest grup de suport din meniul derulant Support Group Role.

Revizuiți datele și prezentarea valorilor pe care le-ați introdus manual. Imediat ce aceste valori sunt aplicate la evidențe, realizarea modificărilor devine dificilă.

Faceți click pe butonul Add pentru a crea Organizația/ Departamentul introdus.

Dacă doriți să creați mai multe, repetați acești pași. Dacă nu, faceți click pe butonul Close.

Categorii operaționale

Categoriile operaționale sunt folosite pentru a vă îmbogăți datele de incident, cu scop în a vă ajuta să construiți rapoarte mai bune și a permite căutări mai detaliate. Funcțional, OpCats apare ca un meni pe trei niveluri, condus ierarhic cu fiecare conținut de meniu în funcție de meniul dinaintea sa.

Exemplu:

Cerere de Servicii

Cerere Standard

Cerere de Suport

Aceste valori sunt folosite pentru a vă întâmpina nevoile de raportare. Dacă nu aveți nevoi de raportare sau sunteți în curs de elaborare, cel mai bine așteptați și vedeți abordarea pentru crearea OpCats.

Notă: Dacă ștergeți un OpCat, acesta nu va mai fi disponibil pentru raportare

Adăugarea de noi categorii operaționale

Din pagina de plecare, deschideți consola locală de administrare.

Faceți click pe link-ul ce se găsește în partea dreaptă a etichetei Operation Categories. Apare o fereastră etichetată Operation Catalog.

Tier 1, 2 or 3? Decideți de nivel (tier) veți crea. Dacă creați un OpCat de nivel 3, puteți selecta nivelul corespunzător 1 și 2 din meniurile derulante.

Figura 2.4

În mod tipic, lăsați starea la enabled, dar mai bine o schimbați la proposed până când sunteți gata să începeți folosirea noii categorii operaționale.

Adăugați o scurtă descriere.

Faceți click pe butonul Add.

Dacă doriți să creați mai multe, repetați acești pași. Dacă nu, faceți click pe butonul Close.

Persoane

Date despre clienți

Gestionarea persoanelor în Remedy este împărțită în două categorii majore, furnizori de suport și clienți. Mare parte din munca de definire a clienților este efectuată de Remedy printr-un import lunar din serverele director Alcatel. Toate persoanele noi cu intrare în director sunt importate în tabelul cu persoane Remedy în fiecare noapte. Importul se face o singură dată pe înregistrare astfel încât orice modificări la tabelul de persoane vor rămâne neschimbate și nu vor fi suprascrise de intrarea în director.

Datele clienților nu conțin compania în care se află aceștia. Dacă doriți ca clienții dvs. să apară în compania dvs., atunci trebuie să editați fiecare tabel de persoane pe rând. Din acest motiv, nu este recomandabil să adoptați această abordare la administrarea clienților.

Datele furnizorilor de suport

Adăugarea drepturilor de acces pentru un nou angajat

Evidența cu angajați trebuie să fie prezentă în directorul LDAP înainte de importul tabelului de persoane Remedy din seara anterioară.

Procesul de adăugare a furnizorilor de suport la grupurile dvs. de suport are loc în cinci minute imediat ce vă familiarizați cu acesta.

Există setări mai avansate pentru furnizorii de suport tehnic, care nu sunt acoperite în această secțiune. Aceste instrucțiuni acoperă practicile comune pentru setarea unui cont standard TSP.

Din consola de management incidente, faceți click pe My Profile în meniul din stânga.

Schimbați modul la căutare:

Dacă folosiți aplicații pe servere, faceți click pe binoclul din bara de meniu.

Dacă folosiți Midtier, faceți click pe butonul New Search din bara de unelte gri din partea de sus a formularului.

Căutați angajatul folosind una dintre următoarele metode:

a) Completați câmpurile First și Last Name sau folosiți parțiale. Amintiți-vă că Remedy ia în considerare majusculele și că prima literă a numelui și prenumelui trebuie capitalizată la căutare În fila de Login/ Access Details puteți căuta după NetID folosind câmpul Login ID.

Figura 2.5

Editați compania și organizația

În fila General, schimbați compania cu numele companiei dvs.

Selectați organizația și departamentul în care trebuie să fie situat utilizatorul dacă acesta aparține de configurația dvs.

Adăugați permisiuni

În fila Login/ Access Details, faceți click pe butonul Update Permission Groups.

Adăugați următoarele permisiuni:

Foundation – Contact people User

Incident – Incident User – floating

Problem – Problem User – floating

Task – Task User

Rezultatele trebuie să se potrivească cu captura de ecran din figura 2.6.

Fig 2.6

Adăugați accesul companiei

În fila Login/ Access Details, faceți click pe butonul Update Access Restrictions.

Adăugați-vă compania.

Fig 2.7

Rezultatele trebuie să fie similare cu captura de ecran din figura 2.8.

Dacă vedeți oricare altă companie în această căsuță, eliminați-o.

În fila Login/ Access Details, setați tipul License la Floating. Lăsați setul Full Text License Type la None.

Deasupra filelor, schimbați valoarea câmpului Support Staff de la No la Yes.

Adăugați Grupuri de Suport

În final Support Groups, faceți click pe Update Support Groups and Roles.

Figura 2.10

Selectați Organizația urmată de grupul de suport pe care doriți să îl adăugați. primul grup pe care îl adăugați va deveni grupul implicit al furnizorilor de suport.

Selectați Rolul Relației Membrului.

Faceți click pe Add.

Repetați procesul până când toate grupurile dorite sunt adăugate.

După ce ați adăugat grupurile, închideți butonul de la baza ferestrei Update Support Groups and Roles.

Salvați intrările

Ați terminat configurarea utilizatorului pentru un cont standard TSP. Faceți click pe butonul Save din bara de unelte gri din partea de sus a formularului înainte de a închide sau reveni la modul de căutare.

Informații suplimentare

Există unelte suplimentare pentru adăugarea utilizatorilor, inclusiv un tabel de permisiuni și o listă de verificări ce poate fi regăsită la finalul acestei secțiuni.

Eliminarea drepturilor de acces ale unui Angajat

Din consola de management incidente, faceți click pe My Profile în meniul din stânga.

Schimbați modul la căutare:

Dacă folosiți aplicații pe servere, faceți click pe binoclul din bara de meniu.

Dacă folosiți Midtier, faceți click pe butonul New Search din bara de unelte gri din partea de sus a formularului.

Căutați

Completați câmpurile First și Last Name sau folosiți parțiale. Amintiți-vă că Remedy ia în considerare majusculele și că prima literă a numelui și prenumelui trebuie capitalizată la căutare

În fila de Login/ Access Details puteți căuta după NetID folosind câmpul Login ID.

Editați compania și organizația

În fila General, schimbați compania cu Alcatel-Lucent. Trebuie să tastați această valoare. Aceasta nu poate fi selectată din meniu. Asigurați-vă că ștergeți câmpul Values din câmpurile Department și Organization.

Eliminați statusul Support Provider

În fila Login/ Access Details, copiați valoarea Login ID (NetID).

Deasupra filelor, localizați câmpul Support Staff și modificați această valoare la NO. Aceasta va șterge câmpul Login ID.

Lipiți sau tastați NetID înapoi în câmpul Login ID.

Faceți click pe butonul Save din bara de unelte gri din partea de sus a formularului înainte de a închide sau reveni la modul de căutare.

Figura 2.12

CONSOLELE REMEDY

Consolele reprezintă principala interfață cu utilizatorul a aplicațiilor BMC Remedy ITSM. Sunt asigurate două tipuri de console: consolele de aplicații care asigură funcționalitate specifică aplicației și console comune care sunt folosite în rândul aplicațiilor. Consolele comune includ o consolă Overview care combină activitățile atribuite din toate aplicațiile într-un singur ecran și o consolă Requested concentrată pe utilizatori.

Când porniți suita BMC Remedy IT Service Management, pagina de plecare IT afișează consola Overview implicit. Cu toate acestea, puteți configura ceea ce doriți să vedeți în pagina de plecare IT. Dacă sunteți administrator de sistem, puteți configura pagina pentru toți utilizatorii. În caz contrar, puteți configura propriul utilizator pentru a vedea ecranele.

Consola Overview

Consola Overview furnizează o vedere asupra activităților atribuite prin multiple aplicații. De exemplu, dacă utilizatorii doresc să vadă toate cererile de incident, investigațiile problemelor și sarcinile ce le sunt atribuite, aceștia le pot vedea în consola Overview. Implementarea consolei Overview folosește un plug-in ARDDBC al sistemului AR BMC Remedy pentru a furniza o vedere consolidată a tuturor activităților atribuite din sursele de date din multiple aplicații fără a folosi replicarea datelor sau vederi SQL complexe care deviază de la API-uri. Arhitectura plug-in-ului este determinată de date. Formularele de configurație definesc modul în care este setat plug-in-ul, inclusiv ce formulare trebuie interogate, ce câmpuri trebuie selectate în câmpul tabelar și un formular ARDBC care efectuează interogarea.

Următoarea figură ilustrează zonele funcționale ale paginii de plecare IT.

Consolele de aplicație

BMC Remedy Asset Management, BMC Remedy Change Management, și BMC

Remedy Service Desk furnizează una sau mai multe console.

Aplicația BMC Remedy Asset Management furnizează mai multe console:

■ Asset Management

■ Contract Management

■ Purchasing

■ Software Asset Management (SAM)

■ Receiving

BMC Remedy Change Management furnizează o consolă de management al schimbărilor și

o consolă de management al versiunilor.

Consola de management al schimbărilor are două ecrane: una concentrată pe tehnicianul de suport și una pe manager. Consola Change Manager asigură și capacitatea de a schimba consola de suport să se concentreze pe sarcini sau cereri de schimbare.

BMC Remedy Service Desk asigură o consolă de management al incidentelor și o consolă de management al problemelor. Fiecare dintre aceste console furnizează un singur ecran pentru folosire de către analiști și manageri ai centrului de servicii.

Consola Requester

Pentru organizațiile care nu instalează BMC Service Request Management, consola Requester este o interfață prin care utilizatorii își pot crea și vizualiza cererile. Din consola Requester, utilizatorii pot crea o cerere care se depune la BMC Remedy Change Management sau BMC Remedy Incident Management. În funcție de modul în care este configurată aplicația, consola poate afișa cereri de incident și cereri de schimbare introduse în numele utilizatorului de către personalul de suport, în plus la cererile create de utilizator. Utilizatorii pot vizualiza cereri și răspunde la chestionare după ce cererea a fost rezolvată. Utilizatorii consolei Requester sunt în mod tipic angajați care au nevoie de asistență de la personalul de suport IT pentru implementarea unei schimbări sau rezolvarea unui incident. Cu toate acestea, utilizatorul poate să nu fie un angajat. Cei care nu sunt angajați pot fi utilizatori deoarece utilizatorii neînregistrați pot depune cereri de servicii. Tradiționat, după ce utilizatorul face un apel la un centru de asistență, un membru al personalului de suport înregistrează cererea. BMC Remedy Incident Management și BMC Remedy Change Management asigură auto-aprovizionarea utilizatorilor. Folosind consola Requester, utilizatorii pot depune, monitoriza și (în unele cazuri) rezolva cererile proprii. BMC Remedy Change Management și BMC Remedy Incident Management sunt pre-configurate să lucreze cu consola Requester. Cu toate acestea, o organizație poate decide să pună în indisponibilitate consola Requester.

Console de navigare, formulare și module

În majoritatea cazurilor, când deschideți console, formulare și module din pagina Home IT,

acestea se deschid în pagina Home IT. În mod similar, când deschideți un formular dintr-o consolă,

formularul înlocuiește consola în ecran. Dacă deschideți o înregistrare dintr-un formular, înregistrarea se deschide în ecranul care a fost ocupat de formular. De exemplu, dacă lucrați cu investigarea unei probleme („înregistrarea” inițială) și din înregistrarea inițială deschideți o cerere

de incident asociată, cererea de incident înlocuiește înregistrarea inițială în ecran. Dacă apoi deschideți o cerere de schimbare din cererea de incident, cererea de schimbare înlocuiește cererea de incident în ecran, și așa mai departe. Pentru a vă ajuta să monitorizați înregistrările pe care le vedeți și pentru a facilita navigarea, există o bară de marcaje în partea de sus a câmpului de vizualizare.

Bara de marcaje conține legături la înregistrările deschise din înregistrarea inițială. Dacă deschideți o înregistrare, coada de marcaje se extinde de-a lungul barei spre dreapta cu următoarea legătură. Dacă sunt peste șase legături în bara de marcaje, apar săgeți la unul sau ambele capete ale barei, care vă permit să derulați și să mergeți înainte în bară pentru a vedea legăturile care nu sunt încadrate.

Prima legătură din șirul de marcaje indică locul din care ați plecat. Acesta poate fi o consolă sau un formular. De exemplu, dacă deschideți o cerere de schimbare direct din pagina Home IT, prima legătură din bara de marcaje vă duce la cererea de schimbare. Ultima legătură corespunde cu înregistrarea aflată în prezent pe ecran. Dacă deschideți o legătură din stânga înregistrării afișate curent, sistemul trunchiază șirul de marcaje la acea legătură. Cu toate acestea, istoricul este reținut pentru a putea folosi săgețile înainte și înapoi din controalele de navigare pentru a merge printr-o înregistrare pe rând în bară. Există și un istoric al celor mai vizualizate înregistrări, pe care îl puteți folosi pentru a merge direct la o înregistrare. Faceți click pe săgeata orientată în jos pentru a deschide lista de istoric.

Dacă vizualizați o înregistrare din mijlocul șirului de marcaje și apoi mergeți la o altă înregistrare de tip inițial, sistemul șterge șirul de marcaje înainte din punctul în care ați scindat și începe un nou istoric de acolo, folosind noua înregistrare inițială ca punct de plecare. De exemplu: Deschideți investigația unei probleme, apoi deschideți o cerere de incident asociate și din cererea de incident deschideți o cerere de schimbare asociată. Dacă mergeți înapoi la înregistrarea cererii de incident și apoi deschideți o altă investigație, bara de marcaje nu va mai conține legătura

la cererea de schimbare. Șirul de marcaje arată acum investigația problemei inițială, cererea de incident și a doua investigație. Apoi arată orice înregistrări relevante pe care le deschideți ulterior din a doua investigație.

Bune practici

BMC Remedy ITSM prezintă o vedere de bune practici și o vedere clasică pentru formularele cheie. Ecranul de bune practici este o versiune îmbunătățită a formularului. În acest ecran, câmpurile cel mai folosite devin imediat vizibile. Puteți accesa funcționalități folosite mai puțin frecvent din secțiunile tabelare ale formularului sau din legăturile panoului de navigare. De exemplu, din formularul de cerere Incident, câmpul Templates este inclus în ecranul de bune practici pentru a încuraja folosirea șabloanelor.

Ecranul clasic este o vizualizare a formularelor similară cu cea prevăzută în versiunile anterioare. Acest ecran este furnizat pentru clienții care fac upgrade de la versiunile anterioare ale aplicațiilor BMC Remedy ITSM și care nu au adoptat încă ecranul de bune practici.

Ecranul de bune practici rămâne disponibil pentru fiecare dintre următoarele formulare:

■ Cerere de schimbare

■ Cerere de incident

■ Eroare cunoscută

■ Investigarea problemei

■ Cerere de eliberare

Capitolul III

Module ISTM

BMC Remedy Change Management – Managementul Schimbărilor

Folosind bunele practici ale biblioecii de infrastructură IT (ITIL – IT Infrastructure Library), BMC Remedy Change Management oferă organizațiilor IT capabilitatea de a gestiona schimbările, permițându-le acestora să:

■ Evalueze impactul, riscul și cerințele de resurse

■ Creeze planuri și să automatizeze funcții de aprobare pentru implementarea schimbărilor

■ Facilizeze distribuția corectă a versiunilor software și hardware, în timp ce minimalizează impactul asupra activității

Obiectivele de management al schimbării ITIL sunt să facă schimbările într-un mod controlat, să reducă riscurile la livrarea la termen a serviciilor IT și să alinieze obiectivele IT cu cele de activitate. Unele bune practici se concentrează pe aprobarea schimbării prin consiliul de aprobare a schimbărilor (CAB). BMC Remedy Change Management automatizează bunele practici descrise de ITIL, precum înregistrarea tuturor cererilor de schimbare, clasificându-le după posibilul risc la furnizarea serviciilor IT, direcționând cererile de schimbare, urmărind aprobările și respingerile, și comunicând detaliile și starea cererilor de schimbare. BMC Remedy Change Management asigură programarea și atribuirea sarcinilor și capabilități de raportare pentru revizuirea performanței și îmbunătățirea proceselor. Deoarece BMC Remedy Change Management este integrat cu BMC Atrium CMDB, acesta vă permite să corelați schimbările cu alte înregistrări, precum elemente de configurație (inclusiv servicii) și incidente.

Folosind BMC Remedy Change Management în combinație cu aceste aplicații, puteți aprecia sfera schimbării, puteți analiza costurile asociate cu schimbarea (în materie de timp și cheltuieli), efectua analiza de impact și de risc și puteți programa resursele necesare pentru ducerea la îndeplinire a schimbării. Folosind aplicația BMC Service Level Management, puteți defini țintele serviciului și măsura eforturile personalului de suport pe măsură ce aceștia implementează schimbările.

BMC Remedy Change Management vă oferă acces la Task Management

System (sistemul de management al sarcinilor), care este instalat și integrat ca parte din aplicație. BMC Remedy Change Management are următoarele caracteristici suplimentare:

■ Dependințe între cererile de schimbare, și o secvență ce poate fi definită, cu executare

■ Procese de aprobare pentru cererile de schimbare

■ Analiza riscurilor și impactului

■ Analiza costurilor și funcționalitatea managementului

■ Set extins de rapoarte predefinite

Procesele Management al Schimbărilor

Inițiere și înregistrare:

Inițierea și înregistrarea este etapa inițială a procesului de management al schimbărilor. Aceasta se concentrează pe înregistrarea scopului cererii de schimbare și pe obținerea informațiilor

suplimentare necesare pentru clasificarea și direcționarea cererii.

Principalele surse ale cererilor de schimbare sunt:

■ BMC Remedy Problem Management, inclusiv funcția de erori cunoscute

■ BMC Remedy Incident Management

■ BMC Service Request Management

Caracteristicile cheie din BMC Remedy Change Management create să sprijine această etapă a procesului includ:

■ Consola Requester

■ Atribuire automată sau cereri de schimbare la nivel de grup sau individual

■ Managementul versiunilor

■ Suport pentru clasificare pe multiple niveluri folosind cataloagele de produs și operaționale

■ Șabloane de schimbare de bune practici

Revizuire și autorizare

După ce cererea inițială a fost depusă, următoarea etapă logică este revizuirea și autorizarea.

Scopul acestei etape este ca managerul schimbării să analizeze cererea de schimbare, să furnizeze informații suplimentare pentru a adăuga mai mult context și, dacă este necesar, să inițieze procesul corespunzător de aprobare. Această etapă acționează ca un filtru inițial pentru a determina dacă cererea de schimbare trebuie să continue la următoarea etapă din proces.

Caracteristicile din BMC Remedy Change Management menite să sprijine această etapă a

procesului includ:

■ Consola de schimbare

■ Evaluarea riscurilor

■ Suport pentru corelarea CI-urilor din BMC Atrium CMDB

■ Analiza impactului schimbării

■ Integrare cu serverul BMC Remedy Approval Server

■ Confirmarea cererii

Planificare și programare

După ce cererea de schimbare a fost aprobată pentru începerea lucrării, următoarea etapă este să se planifice resursele și programele pentru a asigura un impact minim asupra mediului

de producție. După ce planificarea și programarea sunt finalizate, cererea de schimbare trece

printr-un alt proces de aprobare.

Implementare

Etapa de implementare constă din executarea planului și îndeplinirea

lucrării. Caracteristicile disponibile în BMC Remedy Change Management care sunt create să

sprijine această etapă a procesului includ:

■ Sistemul de management al sarcinilor

■ Managementul etapei sarcinilor

■ Automatizarea sarcinilor

■ Monitorizarea eforturilor

■ Costuri (reale)

■ Informații despre lucrare

Finalizare și închidere

Finalizarea și închiderea este etapa finală a unei cereri de schimbare. Această etapă indică dacă cererea de schimbare a fost finalizată cu succes sau dacă a fost anulată. Toate elementele de date (timp, cost și așa mai departe) sunt încheiate și înregistrate.

Procese de aprobare implicite

BMC Remedy Change Management vine cu procese implicite de aprobare create

out-of-the-box pentru utilizare globală. Aceste procese de aprobare bazate pe bune practici sunt

deja definite implicit pentru dvs. Aceste procese specifică ce stare apare în continuare

dacă o cerere este aprobară sau respinsă sau dacă nu sunt identificați factori de aprobare.

Procesul pre-configurat de aprobare pentru BMC Remedy Change Management

Câmpul read-only Next or Current Approval Phase afișează în ce fază de aprobare

este schimbarea. Fila Approvers afișează următoarele informații importante:

■ Starea de aprobare

■ Semnăturile grupurilor și persoanele care trebuie să aprobe cererea de schimbare

■ Factori alternativi de aprobare

Aprobările pot fi generate automat, pe baza informațiilor captate în cererea de schimbare. Acestea pot fi si generate manual în cazuri speciale.

Formularul de schimbare – fila Approvers

Dacă este necesar, administratorul aplicației poate configura fluxul de aprobare

a cererilor de schimbare conform cu modelul de afaceri al organizației dvs. Aceasta determină ce

cereri de schimbare necesită aprobare și prin ce tip de proces de aprobare trec acestea.

Managementul versiunilor este de asemenea instalat cu procese implicite de aprobare

out-of-the-box pentru utilizare globală.

Multipli factori de aprobare și multiple niveluri de aprobare

Poate exista mai mult de un nivel de aprobare și pot fi mai mulți factori de aprobare

pe fiecare nivel. Cel puțin un factor de aprobare pe fiecare nivel trebuie să aprobe cererea de schimbare înainte de a fi revizuită de următorul nivel de aprobare. Factorii de aprobare pot revizui acțiunile factorilor anteriori prin vizualizarea comentariilor acestora și șirului de audit.

Puteți configura procesul de aprobare ca unul sau toți factorii de aprobare pe fiecare

nivel de aprobe cererea de schimbare înainte ca aceasta să fie revizuită de următorul nivel

de factori de aprobare. Modificați setarea If Multiple Approvers pentru configurarea acestei opțiuni.

Administratorul aplicației are și posibilitatea de a configura procesul de aprobare (parent-child) al lanțului de management al schimbărilor. Dacă o schimbare este configurată pentru procesul de aprobare din lanțul de management, managerul solicitantului este notificat.

Dacă schimbarea este aprobată de toți factorii de aprobare, procesul de aprobare este complet și schimbarea trece la următoarea stare. Dacă schimbarea este respinsă de orice factor de aprobare, aceasta este oprită. Managerul schimbării sau coordonatorul poate anula ulterior schimbarea sau o poate actualiza și redepune spre aprobare. Aprobarea cererii de schimbare poate finaliza aprobarea sau declanșa următorul pas din procesul de aprobare. Dacă există mai multe niveluri de factori de aprobare, aprobarea dvs. poate trimite cererea de aprobare la următorul factor de aprobare sau dacă respingeți cererea, procesul de aprobare este finalizat, indiferent dacă sunt definiți mai mulți factori de aprobare. Semnătura de aprobare nu poate fi modificată după ce cererea a fost respinsă, iar procesul de aprobare este finalizat. Dacă cererea de schimbare va fi implementată, managerul schimbării trebuie ca mai întâi să repornească procesul de aprobare.

BMC Remedy Service Desk

BMC Remedy Service Desk acționează ca singur punct de contact pentru cererile utilizatorilor, incidentele depuse de utilizatori și incidentele generate de infrastructură. O organizație trebuie să adreseze zilnic incidentele imediate pentru a-și întreprinde activitatea. Aceste incidente imediate sunt punctul central al procesului de management al incidentelor. În plus, este esențial să se detecteze, analizeze și rezolve problemele din infrastructură.

BMC Remedy Service Desk constă din două aplicații:

■ BMC Remedy Incident Management – managementul incidentelor

■ BMC Remedy Problem Management – managementul problemelor

Aceste aplicații conforme ITIL automatizează procesele de management al incidentelor și al problemelor pentru a permite echipei IT să răspundă eficient și rapid la condiții care interferează cu serviciile critice.

Procesul de management al incidentelor se concentrează pe restabilirea utilizatorilor după întreruperi.

Procesul de management al problemelor se concentrează pe determinarea cauzei de bază a unei probleme și pe folosirea procesului de management al schimbărilor pentru corectarea acestei cauze.

Relația dintre procesele de management al incidentelor, problemelor și schimbărilor

BMC Remedy Incident Management

Misiunea procesului de management al incidentelor este să rezolve cererile de incidente cât mai rapid posibil într-un mod prioritizat. Modulul de management al incidentelor BMC Remedy Incident Management este conceput să sprijine în realizarea acestui scop. La tratarea cererilor de incident, BMC Remedy Incident Management este inițiat tipic la un apel de client, o cerere de servicii sau un eveniment automat. Un exemplu de eveniment automat poate fi alerta sistemului de monitorizare, precum BMC Service Impact Manager (BMC SIM). Principalul obiectiv al procesului de management al incidentelor, conform cu standardele ITIL, este să „restaureze serviciul normal cât mai rapid posibil cu o minimă întrerupere a activității, astfel asigurând menținerea celor mai bune niveluri realizabile de disponibilitate și serviciu”.

La tratarea cererilor de incident, următoarele bune practici sunt critice pentru succes:

■ Prioritizare, astfel încât incidentele care cauzează organizației cele mai multe probleme, precum pierderi din vânzări sau oprirea lucrului, să fie remediate primele. Această abordare vă conservă resursele și le folosește acolo unde sunt cel mai necesare.

■ Înregistrarea consistentă a detaliilor cererii de incident. Aceste detalii sunt apoi puse la dispoziția altor aplicații, precum BMC Remedy Change Management. Aceasta înseamnă că intrările pot fi căutate, analizate și comunicate prin toată organizația.

■ Integrare cu BMC Atrium Configuration Management Database (BMC Atrium CMDB). Aceste informații pot fi folosite atât pentru rezolvarea incidentelor imediate cât și pentru a stabili dacă și alte sisteme pot fi afectate.

Procesul de management al incidentelor gestionează și cereri de servicii de la clienți, precum „Am nevoie de un nou laptop” sau „Am nevoie de acces la această resursă de rețea”. Clienții pot folosi BMC Service Request Management pentru a introduce cereri de servicii. Dacă BMC Service Request Management nu este disponibil, organizația dvs. poate folosi BMC Remedy Incident Management.

Înregistrarea cererilor de servicii

Când un utilizator contactează centrul de asistență cu o cerere de incident, mai întâi determinați natura cererii. Dacă cererea este cu privire la o cerere înregistrată anterior, interogați cererea și actualizați utilizatorul cu starea curentă. Dacă cererea privește un incident ce a fost rezolvat, dar pentru care soluția nu a fost eficientă, redeschideți înregistrarea cererii de incident și atribuiți incidentul la un specialist.

Dacă aceasta este o cerere nouă ce incident, creați o nouă înregistrare de cerere de incident prin captarea informațiilor cheie despre utilizator și incident. Dacă este posibil, soluționați incidentul imediat și apoi finalizați cererea de incident, în caz contrar vă asigurați că cererea de incident este atribuită grupului corespunzător. Următoarea figură furnizează un plan general al procesului de înregistrare a

cererilor de incident, descris de SMPM.

Înregistrarea cererilor de incident

BMC Remedy Problem Management

Misiunea procesului de management al problemelor este să minimalizeze numărul incidentelor. Modulul BMC Remedy Problem Management sprijină acest obiectiv prin gestionarea investigațiilor, erorilor cunoscute și intrărilor în baza de date cu soluții. Managementul problemelor poate preveni în mod activ apariția incidentelor, erorilor și problemelor suplimentare.

Investigarea problemelor

Un important obiectiv ITIL este investigarea și rezolvarea problemelor într-un

efort continuu de tăiere a costurilor și îmbunătățire a serviciilor. Investigarea unei probleme ajută o organizație IT să determine cauza de bază a incidentelor. Aceasta inițiază acțiuni care să ajute la îmbunătățirea sau corectarea situației, prevenind reapariția incidentului. De exemplu, dacă computerele rămân fără spațiu pe disc, în mod ideal problema poate fi rezolvată înainte de a deveni un incident.

Investigațiile sunt declanșate de obicei printr-o analiză a incidentului sau printr-o aplicație precum BMC Event Manager. BMC Event Manager poate genera un eveniment la apropierea de un prag de capacitate. Aceasta poate determina coordonatorul problemei să creeze o investigație a problemei pentru a preveni întreruperile cauzate de lipsa de capacitate.

După ce investigarea problemei prezintă cauza, aceste informații pot rezulta în:

■ O eroare cunoscută, care descrie atât cauza de bază cât și soluția structurală propusă pentru eliminarea cauzei de bază

■ O intrare de soluție care descrie modul de abordare a problemei

Procesul de revizuire a cererii de incident

Revizuirea cererii de incident este primul proces din ciclul de management al problemelor. Efectuați analize ale cererilor de incident periodic, conform cu programul organizației. La efectuarea unei analize a cererii de incident, analizați informațiile cererii de incident pentru a identifica potențiale probleme din servicii pentru care sunteți responsabil. Aceste informații sunt cel mai adesea obținute din aplicația BMC Remedy Incident Management. Cu toate acestea, informațiile despre incident pot veni și de la specialiști care au rezolvat cereri de incident cu o metodă și care consideră că incidentul poate reapărea dacă cauza de bază nu este eliminară rapid. După ce identificați o problemă, creați o nouă investigație de problemă. Corelați investigația problemei cu cererile de incident ce au fost cauzate de problemă. De asemenea, puteți crea o investigație dintr-o cerere de incident în Incident.

Crearea unei investigații dintr-o cerere de incident creează automat o relație între cererea de incident și problema nou-creată. Apoi atribuiți noua investigație la un specialist pentru analiză. La atribuirea investigației, alegeți un specialist care are competențele, disponibilitatea și drepturile de acces necesare pentru efectuarea analizei. Dacă găsiți o cerere de incident în timpul analizei pentru care a fost deja înregistrată o investigație, trebuie să corelați cererea de incident cu investigația.

Revizuirea cererii de incident

Analiza cauzei de bază

După ce investigația problemei este atribuită la dvs. pentru investigare, efectuați o analiză a cauzei de bază pentru a determina cauza problemei. Dacă problema a cauzat unul sau mai multe incidente, mai întâi încercați să găsiți o soluție temporară pentru restaurarea serviciului cât mai rapid posibil. Dacă este disponibilă o soluție temporară, actualizați înregistrarea investigației cu detalii despre soluție, inclusiv modul de implementare. Aceste informații pot fi folosite ulterior pentru a rezolva alte incidente cauzate de aceleași probleme sau probleme similare până când este găsită și implementată o soluție structurală.

După evaluarea soluțiilor temporare, începeți să investigați cauza de bază a problemei. După găsirea cauzei de bază, actualizați investigația cu o descriere a cauzei de bază.

După determinarea cauzei, investigați posibile soluții structurale. Asigurați-vă că adăugați o descriere a fiecărei opțiuni la investigația problemei alături de o recomandare pentru soluția preferată.

Dacă puteți aplica o soluție structurală, implementați soluția și apoi actualizați investigația problemei cu aceasta. Dacă procesul de management al schimbării este necesar pentru soluționarea sau rezolvarea permanentă a cauzei de bază, trebuie să informați coordonatorul problemei că managementul schimbărilor trebuie implementat în analiză.

Dacă nu puteți determina cauza de bază a problemei sau nu puteți propune o soluție structurală, atunci înregistrați asta în investigația problemei alături de o explicație.

Când terminați analiza cauzei de bază, indiferent de rezultat, trebuie să informați coordonatorul problemei asupra faptului că sarcina dvs. a fost îndeplinită.

Analiza cauzei de bază

Închiderea investigației

Când sunteți notificat de specialist că problema este rezolvată, verificați acest fapt. După ce ați verificat rezolvarea, închideți problema în investigație și orice erori cunoscute asociate. Dacă schimbarea a fost propusă dar nu a fost implementată sau dacă schimbarea nu a rezolvat problema, stabiliți dacă există o soluție diferită pentru problemă. Dacă există, atunci puteți atribui investigația problemei înapoi specialistului pentru analize suplimentare sau o puteți reatribui la un alt specialist.

Dacă investigația și analiza detaliată arată că nu există actualmente mijloace practice de rezolvare sau abordare a cauzei de bază a problemei, actualizați investigația pentru indicarea unui impas. După aceea, trebuie să reatribuiți periodic investigația problemei pentru a determina dacă o nouă tehnologie sau dacă o abordare diferită la cauza de bază a problemei poate furniza o soluție structurală.

Închiderea problemei

Erori cunoscute

O eroare cunoscută este o problemă care a fost diagnosticată cu succes și pentru care a fost propusă o soluție permanentă. După analiza cauzei de bază și propunerea unei soluții structurale, este creată o eroare cunoscută pentru solicitarea implementării soluției propuse. Implementarea soluției propuse face parte din procesul de management al schimbării. Procesul erorii cunoscute poate avea unul dintre următoarele rezultate:

■ O cerere de schimbare pentru implementarea soluției necesare

■ Închiderea erorii cunoscute ca problemă acceptată, cu actualizări la baza de cunoștințe ce conține măsuri de evitare a problemei

Baza de date cu soluții

Baza de date cu soluții este un simplu depozit cu potențiale soluții sau abordări la probleme de infrastructură. O intrare în baza de date cu soluții conține informații ce pot fi necesare pentru furnizarea sau restaurarea unui serviciu.

Datele din baza de date cu soluții devin aport la un sistem complet de management al cunoștințelor cu folosirea aplicației BMC Remedy Knowledge Management.

Cele mai bune instrucțiuni ITSM și Depanare

Arhitectură:

Comenzi utile pe nivelurile medii:

/opt/apache/tomcat/bin ./shutdown.sh 2x

/opt/apache/tomcat/bin ./startup.sh

Vizualizare procese:

ps -ef | grep tomcat

root 17960 1 1 Jan23 ? 08:03:57 /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java -Djava.util.logging.config.file=/opt/apache/tomcat/conf/logging.properties -Xms1024m -Xmx2048m -XX:MaxPermSize=256m -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/opt/apache/tomcat/endorsed -classpath :/opt/apache/tomcat/bin/bootstrap.jar -Dcatalina.base=/opt/apache/tomcat -Dcatalina.home=/opt/apache/tomcat -Djava.io.tmpdir=/opt/apache/tomcat/temp org.apache.catalina.startup.Bootstrap start

Comenzi SSH utile:

restartare ITSM: /opt/bmc/ARSystem/bin ./arsystem stop

./arsystem start

restartare servet Email : /opt/bmc/ARSystem/AREmail ./emaild.sh stop

will be restarted automatically by armonitor process

Capitolul IV

Proiectarea bazelor de date

Procesul de proiectare logica al bazei de date

Succesul unui mediu de baze de date este puternic determinat de cat de bine a fost structurat logic baza de date. Acest capitol introduce concepte de baza in proiectarea bazelor de date.

Ciclul de viata. Durata de viata (lifecycles)

Sintagma „ciclu de viata” este folosita ca loc comun in analiza sistemelor si in prelucrarea datelor pentru o secvența de faze in evoluția software-ului. Concepte de „ciclu de viata” sunt folosite pentru a explica dezvoltarea sistemelor, pentru a organiza proiecte de sisteme, pentru a standardiza documentația si pentru a comunica progresul sistemelor.

In general, nu exista concordanta asupra ceea ce înseamnă faza in ciclul de viata al sistemului. Unii vorbesc de 17 faze pentru a descrie dezvoltarea sistemului, alții nu folosesc mai mult de trei faze. Multe propuneri cad pe undeva intre aceste limite.

Următoarele faze descriu percepția tipica a procesului de dezvoltare a sistemului:

Definirea problemei: recunoașterea faptului ca este nevoie de un sistem nou, identificarea scopurilor si a obiectivelor, redactarea (întocmirea) costurilor si a restricțiilor de livrare.

Studiul de fezabilitate decizia asupra magnitudinii efortului de dezvoltare,urmărirea disponibilității resurselor, estimarea costurilor si planificării preliminare, evaluarea costurilor versus beneficii.

Analiza sistemului existent: revederea documentației de sistem, a soft-ului si a

procedurilor existente si identificarea deficientelor si insuficientelor sistemelor existente.

Proiectarea preliminară: identificarea subsistemelor majore, a funcțiilor lor, a interfețelor subsisteme, descrierea fișierelor de baza si a fluxului in sistem, analizarea mediilor de calculator

gazda si de comunicații precum si a formelor de baza pentru intrări si ieșiri.

Proiectarea detaliata: identificarea modulelor de codificat, dezvoltarea algoritmilor detaliați, a procedurilor , a fișierelor, a organizării rapoartelor si a formelor de intrare.

Programarea: scrierea codului pentru a implementa modulele identificate in faza de proiectare detaliata si testarea unităților.

Testarea : dezvoltarea datelor de test pentru integrarea sistemului, testarea sistemului, evaluarea performantei sistemului si obținerea acceptării pentru sistem.

Conversia: transferarea sistemului in starea de producție; convertirea fișierelor in noile formate, conducerea operațiilor paralele si realizarea despărțirii de cel vechi.

Operarea: gestionarea sistemului, colectarea de rapoarte de probleme, oferirea de

rapoarte si de date operaționale , proiecția încărcărilor de lucru.

Figura. 4.1 Durata de viata convenționala pentru dezvoltarea de sisteme:

Aceasta este o vedere tradiționala a dezvoltării sistemelor, care statuează dezvoltarea sistemelor pe instrucțiuni precise de cerințe funcționale si apoi o prelucrează de la proiectarea preliminară la cea detaliata pana când sistemul terminat este livrat utilizatorilor săi. Ea presupune ca sistemele se nasc, trăiesc si apoi, eventual, se îmbolnăvesc si mor, după care sunt înlocuite cu mai „tinere” si imbunatatite generări de cod. Ciclul de viata al codului aplicațiilor sistem este de aproximativ 10 ani, dar in scădere. Datele, ca si sistemele au ciclu de viata. Când datele se nasc, ele sunt personale, căci sunt proprietatea persoanei care le-a creat si sunt complet sub controlul persoanei. Daca datele persoanei se dovedesc utile, exista opresiune care le face cunoscute din ce in ce mai multor persoane, așa ca datele personale devin date partajate. Datele nu mor niciodată. Datele istorice pot fi arhivate, dar ele nu dispar. Ele nu sunt înlocuite de date noi, cu toate ca pot primi roluri diferite atunci când noi date sunt achiziționate. Noile sisteme de aplicații nu sunt create pentru a înlocui date vechi cu date noi ci pentru a imbunatati modul de prelucrare si gestionare a datelor. Atunci când datele sunt partajate, calitatea lor trebuie sa fie mai bine controlata. Cu cat o data se maturizează, nevoia de control creste. Cu cat oamenii se încred mai mult in data, cu atât devine mai important ca datele sa fie protejate, accesibile si de o înalta calitate. Recunoașterea unui ciclu de viata a datelor conduce la intelegerea faptului ca datele au vieți distincte de cele ale sistemului construit pentru a le manipula si accesa.

Necesitatea unei metodologii de dezvoltare a sistemelor axate pe date

Daca bazele de date sunt implementate folosind orientarea tradiționala pe aplicații , atunci proiectele de baze de date vor urma ciclul de viata tradițional. Din nou, acest ciclu presupune ca bazele de date vor muri

si lucrul acesta este pregătit inca din start.

O alternativa este de a lăsa resursa de date sa evolueze, fara a o constrânge la limitele da astăzi ale aplicațiilor si organizațiilor. Intr-adevăr anumite companii muta oamenii pentru a imbunatati comunicarea in cadrul organizației si intelegerea de către angajați a afacerii companiei. Marginile naturale ale aplicației au tendința de a mișca mai încet decât cele ale organizației, dar totuși ele se mișca.

O modalitate de a implementa un mediu efectiv orientat predate este de adopta un cadru care:

explica tipurile de relații de date pertinente in mediile de baze de date;

accentuează independenta aspectelor utilizator si implementare in gestionarea datelor;

este independent de orice abordare de modelare date particulara unui vânzător de DBMS.

Un astfel de cadru este abordarea cu trei scheme . O definiție de dicționar a schemei este „diagrama, plan, proiect, schita”. Intr-un context de gestionare de date, cuvântul schema înseamnă insa o structura de date care este formalizata in concordanta cu o mulțime de reguli. O schema este un model, pictat uzual in diagrame si câteodată insotit de descrieri in cuvinte. Abordarea cu trei scheme are trei tipuri de scheme, fiecare cu un scop specific. In plus, abordările alternative pot fi mapate pe abordarea cu trei scheme.

Abordarea cu trei scheme

Abordarea cu trei scheme se bazează pe presupunerile ca:

calculatoarele si utilizatorii au nevoie de a vedea aceleași date in moduri diferite;

diferiți utilizatori au nevoie de a vedea diferite parți ale ansamblului de date;

este de dorit pentru calculatoare si utilizatori sa fie posibil a schimba modul in care vad ei datele;

nu este de dorit ca un calculator sa dicteze sau sa restrângă modurile in care utilizatorii vad datele;

Astfel, este necesar sa fim in stare sa oferim diferitele vederi ale resursei de date.

Separarea vederilor utilizator de vederile de implementare. Utilizatorii au nevoie sa lucreze cu reprezentări de date care sunt independente de modurile in care datele sunt memorate si gestionate in calculator. Utilizatorul vede datele ca entitati la nivel înalt, de exemplu instrumente, vehicule, clienți. Deocamdată, facilitatile calculatorului sunt in stare sa lucreze cu reprezentări fizice. Ele vad datele in termeni de înregistrări si fișiere, cu structuri index, B-arbori, liste inlantuite, pointeri, adrese, pagini, etc. In concluzie, exista doua tipuri diferite de vederi asupra datelor, vederi utilizator si vederi implementare. Vederile utilizator sunt modelele lumii reale; ele comunica cu utilizatorii. Vederile de implementare, pe de alta parte, sunt orientate spre calculator.

Folosind terminologie abordării cu trei scheme, scheme externe sunt vederi utilizator asupra datelor așa cum sunt văzute de una sau mai multe aplicații , iar schemele interne sunt vederi de implementare ale bazelor de date. Schemele conțin metadate, adică date despre date. Metadatele dau semnificații ; valorile de date dau fapte; semnificațiile si faptele dau împreuna datele.

Mapări interscheme. Obiectivul gestionarii datelor este de a permite utilizatorilor sa acceadă date computerizate. Astfel, trebuie sa existe mapări sau transformări intre vederile utilizator si vederile de implementare. Aceste mapări ar putea fi simple daca exista numai o schema externa si numai o schema interna. Exista o multitudine de scheme externe, dar si numărul schemelor interne in întreprindere poate fi mai mare. Fiecare schema externa poate fi mapata direct pe baza de date. Aceasta soluție suferă, totuși, atunci când oricare din tipurile de schema se modifică. De exemplu, dacă o bază de date fizică este restructurată pe disc pentru a oferi o performantă mai mare, atunci maparea pe fiecare schemă externă care referă baza de date poate fi afectată. Dacă o schemă externă este revizuită pentru a prezenta datele intr-o manieră oarecum diferită, atunci maparea pe fiecare din bazele de date poate fi afectată. Folosirea mapării directe schema internă – schema externă previne independenta intre aplicații si implementare. Factorii de calculator fizic restricționează astfel modurile in care utilizatorii văd datele lor. Pentru a permite diferiților utilizatori să-și partajeze resursa de date care poate fi implementată pe mai multe baze de date fizice, abordarea cu trei scheme inserează o vedere neutră, integrată intre schemele externe si cele interne. In termenii abordării cu trei scheme, aceasta vedere este schema conceptuală sau vederea intreprinderii sau vederea comunității.

Figura. 4.2. Maparea directă a vederilor utilizator pe vederile de implementare

Figura 4.3 Arhitectura cu trei scheme: O schemă conceptuală oferită pentru integrarea si independența multitudinii de scheme externe și interne

Schema conceptuala. O schema conceptuală este extensibilă, consistentă, accesibilă si partajabilă si ea permite ca resursa de date să evolueze după cum se modică și se maturizează nevoile. Figura 4.3 ilustrează relațiile intre cele trei tipuri de scheme. Schemele si mapările între ele permit atât independența datelor cât și suportul pentru vederi multiple. O schemă internă poate fi modificată pentru a îmbunătății performanța și pentru a profita de noile dezvoltări tehnice, fara a altera schema conceptuala sau schemele externe .Schemele externe pot fi modificate pentru a reflecta schimbări in vederea unei aplicații sau folosirea datelor , fara a afecta schema conceptuala sau schemele interne. Schema conceptuala reprezintă cunostinte pentru date partajabile. Pot exista controale de acces si restricții de securitate asupra acestor date comune, dar ele nu sunt restricționate la a fi cunoscute numai de un utilizator. Schema conceptuala nu descrie date personale ci, mai degrabă, date partajate controlate de întreprindere. Domeniul schemei conceptuale se expandeaza in timp. Abordarea bazata pe date a proiectelor baze de date expandeaza continuu schema conceptuala pentru a include cunostinte despre tot mai multe date partajate. Un proiect baza de date in abordarea bazata pe date nu redefineste resursa de date si nici nu creează o noua baza de date de sine stătătoare. In loc de acestea, fiecare proiect trebuie sa determine modul in care datele din domeniul sau se leagă de ceea ce este deja cunoscut din schema conceptuala. Rezultatul este o resursa de date al cărui domeniu este expandat gradat. Resursele de date ale unei organizații nu pot fi integrate toate deodată, sarcina trebuie executata pe bucati, iar schema conceptuala este interogatorul.

Ciclul de viata al unui proiect bazat pe date (data-driver)

Obiectivul primar al ciclului de viata al unui proiect bazat pe date este de a implementa bazele de date si software-ul utilizator pe baza unei scheme conceptuale integrate.

Modelul de mai jos nu este singurul ciclu de viata posibil pentru un proiect bazat pe date, dar este unul care a fost testat si s-a arata de succes intr-o varietate de medii. Ciclul de viata al proiectului bazat pe date nu este același cu cel convențional pentru dezvoltarea sistemelor. Abordarea convenționala construiește baze de date si fișiere separate, pe când abordarea bazata pe date construiește baze de date integrate. Abordarea convenționala se bizuie pe declarații complete si corecte de cerințe înainte de a oferi ceva concret utilizatorului. Abordarea bazata pe date promovează prototiparea pentru a ajuta la descoperiră de cerințe, iar utilizatorii contribuie activ si esențial in acest proces de prototipare. Prototipurile oferă posibilitati de cost relativ scăzut pentru a determina care ar trebui sa fie funcția sistemului obiectiv, căci ele permit experimentarea înainte ca proiectarea sa fie realizata in forma finala.

Fazele. Fazele dintr-un proiect de date sunt:

– Examinarea: a stabili domeniul si planificarea proiectului, a colecta si analiza informații despre datele din domeniul proiectului, a dezvolta modele de date logice de nivel înalt, a idenifica posibilitati de imbunatatire.

– Proiectarea: a dezvolta modele de date logice detaliate pentru noul mediu, a planifica procesul de prototipare, a redacta schita cu specificațiile tranzacțiilor bazei de date.

Prototipare: a proiecta structura bazei de date fizice pentru prototipul inițial al bazei de date, a încarcă prototipul, a folosi prototipul pentru a rafina si valida vederile utilizator si a defini tranzacțiile cerute, a dezvolta tranzacțiile si a transfera prototipul in starea de lucru.

Integrare: a integra modele de date prototip cu schema conceptuala si a ajusta mapările interscheme.

Reglaj: a rafina structurile bazei de date fizice si a optimiza software-ul.

Revizie: a monitoriza calitatea ieșirilor proiectului si a transfera prototipul din starea de pregătire in starea de producție.

Aceasta abordare a proiectării se bazează puternic pe construcția modelelor de date care reprezintă resursele de date di diferite perspective. Accentul, in fazele de examinare, proiectare, prototipare si integrare cade pe modelele de date logice, care reprezintă semnificația datelor.

Prototiparea bazei de date. Sa notam buclele de feedback din ciclul de viata din figura 4.4. Buclele de feedback din faza de prototipare permit modificare vederilor utilizator si a acestor contribuții la schema conceptuala înainte de a muta baza de date in starea de producție. Utilizatorii sunt puternic implicați in faza de prototipare, înainte ca baza de date sa devină o declarație completa de cerințe. Acesta este in contrast cu ciclul de viata al dezvoltării sistemelor convenționale, care asteapta pana când toate cerințele

sunt cunoscute si abia apoi începe proiectarea. Folosind acest ciclu de viata al proiectului, se pot construi prototipuri si se pot pune in lucru rapid, de ordinul zilelor. Ciclul de viata lucreza, de asemenea, cu prototipuri de domeniul larg, in care trebuiesc luni de zile pentru a ajunge in stadiul de inițiere al proiectului la o baza de date in lucru. Structura fizica prototip a bazei de date poate fi modificata astfel incat ea sa acopere mai eficient performantele de producție cerute. Modelul sau de date logice, totuși, nu este abandonat ci este integrat in schema conceptuala si mapat pe structura fizica, adică pe versiunea de producție a schemei interne.

Echipele proiectului. Abordarea bazata pe date in dezvoltarea bazelor de date cere echipe de proiect compuse atât din personal de prelucrare date cat din utilizatori. Decât sa-si trimită cerințele lor departamentului de prelucrare date si apoi sa vadă ce primesc de acolo, utilizatorii (end-users) ajut ala determinarea relațiilor si tranzacțiilor de date. Ei sunt implicați in sistem ca I creatorii si numai după ce acest a fost dezvoltat, ca si indivizi ce trebuiesc sa trăiască cu el.

Integrarea si schema conceptuala

Una dintre cele mai importante caracteristici ale acestui ciclu de viata al dezvoltării este aceea ca fiecare proiect nu trebuie sa-si recreeze propria sa baza de date separata. Mai degrabă, fiecare proiect trebuie sa examineze cum se leagă datele din domeniul sau cu datele din schema conceptuala existenta. Schema conceptuala evoluează cum apar proiecte adiționale bazate pe date. Fiecare proiect isi poate creea propria baza de date fizica, prototip separata, dar se urmareste integrarea acestor baze de date. Câteodată initiaza un proiect si apoi se descoperă ca datele necesare pentru a-l susține sunt deja disponibile si descrie in schema conceptuala. Se poate dezvolta atunci o noua schema externa si ea se poate mapa pe schema conceptuala care este mapata pe una sau mai multe scheme interne.

Cele de mai sus nu implica crearea unei baze de date uriașa pentru a conține toate informațiile de producție necesare, deoarece in concordanta cu abordarea cu trei scheme, schema conceptuala poate fi mpata pe oricâte scheme interne, fiecare reprezentând o baza de date fizica. Aceste baze de date fizice pot fi rezidente pe mai multe calculatoare si pot fi distribuite geografic pe tot cuprinsul unei intreprinderi. Schema conceptuala integrează aceste concepte distribuite. Astfel, schema conceptuala integrează vederile orientate pe aplicație, reprezentate pe schemele externe, sau dintr-o alta perspectiva, ea integrează vederile orientate pe implementare, reprezentarea de scheme interne.

Figura 4.4 Ciclu de viata al unui proiect bazat pe date, cu prototipuri.

Schema conceptuala externa

Scheme conceptuale pasive si active. Datele nu sunt integrate pana când legătura ermetica dintre schemele interne si externe nu este sparta. Schema conceptuala trebuie sa controleze accesul la manipularea resurselor de date, si nu aplicațiile program. Spargerea legăturii intre schemele interne si externe nu este simpla. Exista doi pași intermediari care superimpun, la început o schema conceptuala pasiva si apoi o vedere completa cu trei scheme in vârful legăturii directe intern – extern . Moștenirea majorității mediilor de aplicații baze de date este arătata in figura 4.5.a schemele interne si externe sunt unite prin codul aplicației program. Nu exista nici o vedere intreprindere a resursei de date. Notația cu “punct mare” folosita in figura 4.5 arata tipul de relație posibila intre entitățile din cutii. Un “punct mare” înseamnă mai multe. Figura 4.5a spune ca o schema interna poate suporta direct mai multe scheme externe si ca o schema externa poate fi suportata direct de mai multe scheme interne.

In pasul 1 (fig. 4.5.b) se introduce schema conceptuala, iar schemele interne si externe continua sa fie legate direct. O schema conceptuala descrie toate datele disponibile in toate schemele interne , intr-o vedere integrata, neutra si pasiva a resurselor de date. Orice control pe care il are schema conceptuala asupra resurselor de date depinde complet de politicile, procedurilor si administrarea resurselor. Schema conceptuala rezida intr-un dicționar de date si este scrisa ca un model de date logice.

Pasul 2 arata o schema conceptuala activa. Atunci când se folosește o schema conceptuala activa, software-ul de gestionare date relizeaza operațiile necesare pentru a prelua o cerere utilizator in forma din schema externa si a o mapa pe schema conceptuala si apoi pe cele interne. Aplicațiile program se confrunta numai cu schemele externe. O aplicație program sau o tranzacție particulara poate accesa date din mai multe baze de date, fără a se preocupa de locul unde se găsesc datele. Baza de date poate sa fie distribuita pe mai multe calculatoare ale rețelei. Transformările interscheme nu se realizează in codul aplicației program ci in software-ul de gestionare date care oferă controlul activ al schemei conceptuale. Logica poate fi astfel partajata de mai mulți utilizatori si de mai multe aplicații.

Cu toate ca software-ul de gestionare date care sa realizeze transformările interscheme in medii de date distribuite nu exista inca forma de producție , prototipuri au fost construite de către mai multe proiecte de cercetare. Eforturile depuse in construcția schemelor conceptuale pasive astăzi vor fi răsplătite atât pe distanta scurta cat si pe distanta lunga prin planificarea si implmentarea imbunatățită a sistemelor informatice

Figura. 4.5. Pașii in controlul schemei conceptuale

Planificarea pentru un mediu baze de date

Probabilitatea de a implementa cu succes un mediu baze de date poate fi mărita daca se urmează sugestiile:

Recunoaște ca un DBMS reprezintă un instrument pentru gestionarea resursei de date si nu o metoda extravaganta de acces la fișiere.

Formează un comitet adecvat de gestionare a resurselor.

Păstrează domeniul fiecărui proiect de implementare rezonabil si realizabil rezultatele vor fi disponibile in sase luni.

Planifică procesul de dezvoltare si stabilește puncte de revizie.

Fazeaza implementarea (si evoluția schemei conceptuale) in incremente realiste de atins cu un plan de fazare conservator.

Deplasează responsabilitățile spre experți si fi sigur ca utilizatorii isi definesc cerințele lor si validează posibilitățile sistemului.

Antrenează o echipă tehnică in tehnologia bazelor de date, devreme și continuu.

Stabilește o funcție de administrare date.

Când este potrivit, folosește prototipuri pentru a defini cerințe.

Cere și accepta ajutor de la un distribuitor de baze de date

Ferște-te de încurcături, inclusiv de supradependența de distribuitorul DBMS.

Planificarea pentru un mediu baze de date înseamnă înțelegerea abordării bazate pe date în gestionarea datelor. O baza de date trebuie proiectată pentru generalitate, flexibilitate si extensibilitate. După ce baza de date a fost proiectată, programele orientate pe aplicații și tranzacții care depind de acea bază de date pot fi specificate. Mai important pentru succesul pe termen lung al proiectului este neutralitatea și calitatea proiectării bazei de date logice decât programarea.

Planificarea pentru un mediu baze de date înseamnă de asemenea recunoaștera faptului ca un DBMS este un instrument pentru acel mediu și nu un obiectiv.

Capitolul V

Prezentarea aplicației „Controlul Inventarului”

Aplicația gestionează informațiile tehnice și economice legate de activitatea de stocuri, urmărind toate aspectele specifice acestei activități.

Aplicația poartă denumirea de “Controlul inventarului” și, după cum sugerează și titlul, este destinată firmelor mari și mijlocii pentru ținerea evidenței stocurilor și deci a inventarelor.

Dintre avantajele aplicației se pot enumera următoarele: gestionarea produselor firmei reținând informațiile cele mai importante și sugestive despre produsele cu care se lucrează, cu alte cuvinte produsele se stochează într-un nomenclator de produse; se rețin informații angajații firmei (informații minime, adică nu se includ informațiile contabile, cum ar fi salariu, concediile de odihnă și cele medicale etc.); informații despre furnizori, cum ar fi numele furnizorului, persoana de contact, adresa, numărul de telefon, număr de fax; categorii de produse, fiecare produs trebuie să facă parte dintr-o categorie de produse (de exemplu alimente, detergenți, papetărie, gablonțuri etc.); informații legate de firma curentă, adică cea care utilizează aplicația; informații legate de transportul mărfii, cu ce anume se realizează transportul (numărul autoturism, prin poștă etc.). Aplicația mai prezintă și o serie de rapoarte care cuprind informații legare de produsele achiziționate, raport detaliat pentru produse cu care firma lucrează și rapoarte cu tranzacțiile efectuate.

După cum se poate observa din sumara prezentare aplicația este un mare ajutor pentru orice firmă mică sau mijlocie; acest lucru este accentuat de o interfață accesibilă oricărei categorii de utilizatori. Aplicația prezintă un meniu principal de unde se pot alege una din opțiunile referitoare la vizualizarea sau modificarea informațiilor stocate referitoare la produse, alte informații (adică informațiile legate de angajați, furnizori, categoriile de produse, transport și informațiile firmei utilizator) și vizualizarea sau listarea la imprimantă a rapoartelor. În figura 5.1 se poate observa fereastra principală a aplicației.

Figura 5.1

Aplicația este bazată pe o bază de date care conține toate informațiile necesare stocărilor de informații. Baza de date este alcătuită din șapte tabele, fiecare cu specificul ei. Tabelele cele mai simple ale bazei de date sunt cele care reține informațiile legate de categoriile de produse cu care firma lucrează și tabela în care se reține informațiile legate de efectuarea transportului.

Tabela care stochează informațiile legate de categoriile produselor se numește tblCategori și conține două câmpuri: ID_categorie și strDenumire. Cheia primară a acestei tabele este reprezentată prin câmpul ID_categorie, câmp de tip AutoNumber și care are proprietatea New Values setată pe Increment, adică pentru fiecare nouă înregistrare acest câmp se autocompletează cu valoarea ultimei înregistrări la care se adaugă 1 (se inclementează valoarea precedentă). Aceste proprietăți au fost setate în modul de vizualizare Datasheet View și se pot observa în figura 5.2, figură care reprezintă tabela de categori în modul de vizualizare Datasheet View. Câmpul ID_categorie nu acceptă valori duplicate, deoarece este cheie primară, acest fapt se poate observa tot în figura 5.2 în dreptul proprietății Indexed, deci această tabelă este indexată după câmpul ID_Categorie.

Figura 5.2

Tabela care conține categoriile de produse se numește tblTransport și prezintă două câmpuri: ID_transport și strDenumire. Ca în tabela prezentată mai sus, tblCategori, câmpul care păstrează ID-ul este de tip AutoNumber și care are proprietatea New Values setată pe Increment, adică pentru fiecare nouă înregistrare acest câmp se autocompletează cu valoarea ultimei înregistrări la care se adaugă 1 (se inclementează valoarea precedentă) și nu acceptă valori duplicate, deoarece este cheie primară, deci acest câmp este indexat.

Tabela care conține informații legate de angajați se numește tblAngajati și are următoarele câmpuri în componență: ID_Angajat, strNume, strPrenume, strFunctie, strDepartament și strTelefon. Cheia primară a acestei tabele este dată de câmpul ID_Angajat, câmp de tip AutoNumber și care are proprietatea New Values setată pe Increment. Structura tabelei se poate observa mai bine în figura 5.3, unde este reprezentată tabela tblAngajati în modul de vizualizare Datasheet View.

Figura 5.3

O altă tabelă este cea care stochează informațiile referitoare la produse, acestea sunt următoarele: ProductID (cheia primară a tabelei), ProductName, ProductDescription, CategoryID, SerialNumber, UnitPrice, ReorderLevel și LeadTime.

Este de subliniat faptul că deși câmpul CategoryID este de tip numeric dacă ne uităm în tabelă, sau dacă introducem date legate de produse în acest câmp vom vedea, respectiv vom putea alege, informații legate de categoria produselor, dar nu vom vedea ID-ul, ci denumirea categoriei asociată CategoryID-ului respectiv. Acest lucru este posibil cu ajutorul unor proprietăți înrudite Display Control, Row Source Type și Row Source. Cu ajutorul proprietății Display Control specificăm de unde se ia informația; în cazul tabelei noastre dintr-un Combo Box; proprietatea Row Source Type ne permite să specificăm sursa de unde se iau informații, adică din Table/Query (din tabelă sau query), iar în Row Source specificăm tabela sau query-ul sursă. În exemplul nostru, cu tabela tblCategori, sursa este un query și anume:

SELECT DISTINCTROW [tblCategori].* FROM [tblCategori] ORDER BY [tblCategori].[strDenumire];

Acest query „se uită” în tabela tblCategori și pentru ID-ul de categorie selectat completează în loc denumirea categoriei.

O altă tabelă este cea care reține informațiile degate de firma utilizatoare. Pentru fiecare informație care se dorește stocată există un câmp care reține această informație, și anume există un câmp pentru numele firmei, unul pentru adresă, altul pentru oraș, județ, codul județului, țara, numărul de telefon, numărul de fax și un ID de firmă.

Informațiile legate de furnizori se rețin într-o altă tabelă care prezintă câmpuri pentru fiecare tip de informație ce se păstrează pentru fiecare furnizor (numele furnizorului, persoana de contact, titlul persoanei de contact, adresa furnizorului, orașul, județ, cod poștal, țară, număr de telefon, număr de fax și se pot reține și câteva notițe legate de fiecare furnizor în parte).

Cam acestea ar fi în mare tabelele care păstrează informațiile care se doresc stocate de către firma utilizator. Mai există încă o tabelă care nu poate fi modificată prin intermediul aplicației și utilizatori nici nu cunosc existența ei. Această tabelă se numește Switchboard Items și conține informații legate de meniu.

În momentul în care utilizatorul alege una din opțiunile care se pot vizualiza în figura 5.1, cu excepția ultime, cea de ieșire, nu se deschide altă formă, ci în interiorul aceleiași forme se schimbă meniul. Pentru a înțelege mai bine cum funcționează această schimbate de meniu, în figura 5.4 este prezentat conținutul tabelei Switchboard Items.

Acesta este un avantaj, deoarece dacă se dorește modificarea aplicației, și anume se dorește introducerea unor noi opțiuni, aceste modificări se pot foarte ușor include în aplicație fără a modifica formele, ci doar prin adăugarea noilor opțiuni în tabela Switchboard Items.

Figura 5.4

Dar doar această tabelă nu este suficientă pentru a se realiza modificarea meniului; pentru realizarea acestei modificări de meniu din interiorul formei s-a folosit cod de Visual Basic. Pentru a minimiza fereastra principală s-a scris următorul cod Visual Basic:

' Minimize the database window.

DoCmd.SelectObject acForm, "Switchboard", True

DoCmd.Minimize

DoCmd.Hourglass False

Set dbs = CurrentDb()

Set rst = dbs.OpenRecordset("My Company Information")

If rst.RecordCount = 0 Then

rst.AddNew

rst![Address] = Null

rst.Update

MsgBox "Before using this application, you need to enter your company name, address and related information."

DoCmd.OpenForm "My Company Information", , , , , acDialog

End If

rst.Close

dbs.Close

Procedura care face update-ul la schimbarea meniului se numește Form_Current și face refrash-ul pentru lista opțiunilor din noul meniu.

Private Sub Form_Current()

' Update the caption and fill in the list of options.

Me.Caption = Nz(Me![ItemText], "")

FillOptions

End Sub

O cheie străină este o submulțime de atribute (câmpuri) ale tabelei astfel încât valoarea acesteia (a tuturor câmpurilor care o compun) este egală cu valoarea unei chei candidate din tabelul referențiat, sau are valoarea null. O tabelă poate să aibe zero sau oricât de multe chei străine. Câmpurile corespondente din cheia străină și cheia candidată referențiată trebuie să fie compatibile ca tip, dar nu este neapărat nevoie să aibă aceeași denumire. Prin intermediul cheilor se pot defini toate tipurile de asocieri între tabele.

Asocierea 1:1 se realizează între două tabele dacă cheia primară dintr-o tabelă este, de asemenea, cheie primară și în cealaltă tabelă.

Asocierea 1:N se realizează prin intermediul unei chei străine: o cheie străină (definită într-o tabelă) care referențiază o cheie primară dintr-o altă tabelă, realizează asocierea 1:N între tabela care conține cheie primară și tabela care conține cheia străină.

Asocierea M:N nu se poate defini direct între două (sau mai multe) tabele, ci numai prin intermediul unei alte tabele (numită tabelă de asocieri), definită astfel încât fiecare din tabelele date realizează o asociere de tipul 1:N cu tabela de asociere. Pentru aceasta, tabela de asociere conține o cheie străină care referențiază cheia primară corespunzătoare din fiecare din tabelele date.

În figura 5.5 se pot observa relațiile definite în baze de date pe care se bazează această aplicație.

În Access, cheia primară a unei tabele se definește la proiectarea tabelei. Cheile candidate nu se definesc explicit, ci pot fi testate doar la introducerea datelor. Cheile străine permit stabilirea de asocieri între tabele și se definesc în două etape. Legarea tabelelor și extragerea datelor implică legarea mai multor prin relații între date, în vederea creării unor tabele temporale, stocarea în memoria calculatorului sau în fișiere temporale pe disc, care conțin datele alese de utilizator. Access folosește interogări pentru legarea tabelelor și alegerea datelor care trebuie stocate într-un tabel temporal numit obiect recordset. Un obiect recordset cuprinde datele care rezultă din executarea interogării; obiectele recordset se numesc tabele virtuale pentru că ele sunt stocate în memoria calculatorului, nu în fișiere de tip baze de date

Formularele din Access creează interfața cu utilizatorul pentru tabele. Deși se poate folosi modul de afișare Table și modul de afișarea Query pentru a efectua un număr mare din funcțiile procesate de formulare, formularele prezintă avantajul prezentării datelor într-un mod organizat și atrăgător. Se pot rearanja pozițiile câmpurilor într-un formular în așa fel încât introducerea datelor sau operațiilor de editare pentru o singură înregistrare să urmeze ordinea de la stânga la dreapta și de sus în jos. Formularele permit crearea unor selecții cu opțiuni multiple pentru câmpurile care folosesc coduri abreviate pentru reprezentarea unui set de valori permise. Un formular bine configurat mărește viteza de introducere a datelor și reduce erorile de culegere.

Microsoft Access oferă posibilitatea creării de rapoarte care sunt niște obiecte special concepute pentru a tipării informații. Orice raport poate fi vizualizat în trei moduri:

modul design, în care programatorul stabilește sursa de date a raportului, forma sa, elemente de design, informații legate de antetul de raport, antetul de pagină etc. Se pot aplica grupări ale informațiilor, calcula sume, medii, se pot număra înregistrări, se pot ordona informații.

modul preview, în care se poate vizualiza raportul în forma în care va fi tipărit. În acest moment datele din sursa de date ale raportului vor figura în acesta.

modul tipărit, în care informațiile vor fi tipărite la imprimantă. Raportul va arăta ca în modul preview.

Aplicația are definite niște rapoarte și o procedură numită Preview_Click, procedură care se execută la evenimentul de click.

Private Sub Preview_Click()

If IsNull([BeginDate]) Or IsNull([EndDate]) Then

MsgBox "You must enter both beginning and ending dates."

DoCmd.GoToControl "BeginDate"

Else

If [BeginDate] > [EndDate] Then

MsgBox "Ending date must be greater than Beginning date."

DoCmd.GoToControl "BeginDate"

Else

Me.Visible = False

End If

End If

End Sub

Figura 5.6

Un alt avantaj folosit în această aplicație și foarte important este cel referitor la posibilitatea de a ascunde unele câmpuri din tabelă, iar la vizualizarea tabelei în Design View aceste câmpuri nu sunt vizibile

Din meniul Format Hide și Unhide Column se poate face acest artificiu. În Figura 5.6 este prezentată fereastra de Unhide Column; din această fereastră se pot seta ca coloanele ascunse să fie vizibile din nou

În final voi prezenta una din ferestrele aplicației și anume cea de vizualizare și modificare a informațiilor referitoare la produse. În această fereastră se pot vizualiza produsele deja existente în tabela care reține informațiile legate de produse cu ajutorul bării de navigare din josul ferestrei. Această fereastră poate fi vizualizată mai pe larg în figura 5.7.

Figura 5.7

Pentru a introduce informații noi în tabelă, utilizatorul trebuie să se poziționeze pe ultima înregistrare, înregistrare care este goală, și să completeze informațiile care trebuiesc reținute despre produsul care se dorește a fi adăugat în nomenclatorul de produse.

Capitolul V

Concluzii

Principalul obiectiv al mediului baze de date este de a oferi o mulțime de date consistente, exacta, accesibila , sigura, controlabila si extensibila pentru a servi nevoile de informație ale unei comunități de utilizatori in creștere. Investiția inițiala in software DBMS, efortul de proiectare baza de date logica si fizica, persoanele superpregătite, toate își vor avea justificarea deși poate nu imediat evidența. Beneficiul real al mediului de baze de date este calitatea îmbunătățită a datelor, precum si disponibilitatea si costurile reduse pentru suportarea in continuare a nevoilor de date a utilizatorilor.

Succesul tehnicilor de modelare de date comerciale certifica recunoașterea crescânda a importantei modelarii datelor in comunicații si in descoperirea datelor. Modelarea datelor este folosita rutinier pentru :

a creste înțelegerea datelor si a semnificației lor de către o organizație

a documenta resursele de date

a evalua din exterior pachete software

a planifica sisteme informatice

a proiecta sistemele informatice

a integra resursele de date

a proiecta si implementa baza de date fizice.

Modelarea datelor logice este o parte esențiala a ciclului de viata al proiectului baza de date si este folosita pentru a documenta mediile existente si pentru a planifica viitoarele resurse de date. Modelarea datelor este folosita, de asemenea, pentru a dezvolta proiecte modele de date si pentru a integra aceste modele intr-o schema conceptuala de dezvoltare, care este un scop special al modelului de date logice. Rezultatul modelarii datelor pot fi apoi transformate in proiectări de baze de date fizice.

Din punct de vedere fizic, exista o varietate de abordări pentru a implementa baze de date relaționale. Cele doua alternative inițiale sunt de a folosi un software relațional sau un hardware specializat pentru gestionarea bazelor de date relaționale. Aceste alternative pot fi combinate pentru a distribui relațiile pe mai multe calculatoare, ca o baza de date distribuita. Toate DBMS-urile relaționale software disponibile oferă in general același nivel de suport end – user. Ele diferă, totuși, in abordările lor pentru a localiza datele in memorie si in gestionarea accesului la date. Abordările introduse in text includ o relație de baza pe fișier , mai multe relații de baza pe fișier, mai multe relații de baza in mai multe fișiere si mai multe fișiere pentru o relație de baza.

Mașinile baza de date sunt calculatoare specializate pentru a gestiona bazele de date. Astăzi ele suporta toate modelul relațional si deci sunt candidate pentru implementarea bazelor de date relaționale.

Obiectivele lor sunt de a reduce cerințele de prelucrare pentru calculatoarele cu scop general si de a îmbunătății performanța sistemelor de baze de date.

Bazele de date distribuite memorează partițiile relațiilor pe mai multe calculatoare, conectate printr-o rețea de comunicații. O baza de date este distribuita fizic pentru a imbunatatii performantele sistemelor baze de date in medii descentralizate.

Dezvoltarea modelului relațional a construit o secvența de jaloane in cercetarea gestionarii datelor. Simplitatea modelului relațional si separarea vederilor de implementare si de utilizator l-au făcut atractiv pentru cel puțin 15 ani, in primul rând in comunitatea cercetătorilor si apoi pe piața.

Cele mai bune caracteristici ale modelului relațional sunt :

viziunea sa simpla, tabelara asupra datelor;

mulțimea completa de operatori de manipulare date;

separarea modelului logic de implementare fizica;

Dezavantajele de baza ale modelului relațional sunt:

suprareîncărcarea semantica, intr-o singura structura tabelara se reprezintă o varietate de construcții de modelare de date logice;

demonetizarea, prin caracterizarea DBMS-urilor comerciale ca „relaționale” chiar daca ele nu utilizează anumite restricții ale modelului relațional, ca de exemplu integritatea referențială;

operatorii relaționali care sunt la un nivel procedural, de programator si trebuie acoperiți prin comenzi de nivel înalt, care sunt mai ușor de folosit de către nespecialiști;

implementarea ineficienta, relativ la alte proiectări , pentru anumite tipuri de structuri de date.

Prima problema poate fi ameliorata prin folosirea unei tehnici de modelare a datelor logice in modelul relațional. A doua problema nu tine chiar de modelul relațional ci de folosirea de către industrie a terminologiei. La a treia problema este mai mult de lucru, iar a patra se rezolva prin specializarea hard-ului si soft-ului baze de date. DBMS-urile relaționale comerciale continua sa aibă probleme de performanta in mediile baze de date mari si complexe.

Bibliografie

Titus Slavici, Conducerea cu calculatoare, Politehnică 1996

Titus Slavici, Elemente fundamentale ale proiectarii si fabricarii asistate pe calculator, Eurobit 1999

Gheorghe Petrov, Ioan Despi, Robert Reisz, Aurel Stepan, Teoria generala a bazelor de date, Editura MIRTON Timișoara 2000.

Győrödi Cornelia, Pecherle George, “Baze de date relaționale. Teorie și aplicații în Oracle“, Editura Universitati, 2008

Győrödi Cornelia, Győrödi Robert, Baze de date relationale. Concepte avansate ,Editura Treira, 2000.

Aurel Stepan , G. Priboi, Sisteme informatice distribuite, Universitatea din Timișoara, 1985.

Tsichritzis, D.;Klug, A. The ANSI/X3/SPARC DBMS frame work report of the study group of database management system, Info System, 1978.

Astrahan, M.M. e.a. (1976) Sistem R: relational approach to data base management, ACM Trans. Database Systems 1 (1976).

Brodie, M.L; Schmidt, J.W. (ed.) (1982) Final report of the relational database task group ANSI/X3/SPARC/DBSSG, ACM SUGMOD Record 12 (1982).

Chamberlin, D.D. e.a. (1976) SEQUEL 2 : An unifiedapproach to data definition, manipulation and control, IBM J. of. Res. And Developement 20 (1976).

Codd, E.F. (1979) Extending the database relational model to capture more meaning, ACM Trans. Database System 4 (1979)

Date, C.J. (1982) A formal definition of the relational model, ACM SIGMOD Record 13 (1982).

Cohen, J. (1981) Garbage collection of linked data structures, ACM Computing Surveys, 13.

Comer, D. (1979) The ubiquitous B-tree, ACM Computing Surveys,11.

Knuth, D.E. (1973) The Art of Computer Programming, Vol 3: Sorting and Searching, , Addison Wesley, Reading, Mass.

Loomis, M.E.S.(1983) Data Management and File Processing, Prentice Hall, Englewood Cliffs, N.J.

Tannenbaum, A.M.; Augestein, M.S. (1981) Data Structures Using Pascal, Prentice Hall, Englewood Cliffs.

Hsiao, D. (1983) Advanced Database Machine Architecture, Prentice Hall, Englewood Cliffs, NJ.

Neches, P.M. (1984) Hardware support for advanced data management system, Computer, 17.

RDMS Design Principles. RDMS Reference Guide, MIT, Cambridge, Mass.

Stonebraker, M. e.a. (1974) The design of implementation of INGRES, ACM Transaction on Database Systems, 1.

Todd, S. (1975) An efficient implementation for large relational databases, Proc. International Conf. on Very Large Databases, Framigham Mass.

Alcatel-Lucent :

http://www3.alcatel-lucent.com/wps/DocumentStreamerServlet?LMSG_CABINET=Docs_and_Resource_Ctr&LMSG_CONTENT_FILE=Financial_Info/Income_Statements/IR-2013-ALU-20-F.pdf

http://www.sustainability-indices.com/images/140911-djsi-review-2014-en-vdef.pdf

"Thomson Reuters Names the 2014 Top 100 Global Innovators". Retrieved 18 April 2015.

"Alcatel-Lucent announces Chairman Serge Tchuruk and CEO Pat Russo to step down" (Comunicat de presa). Alcatel-Lucent. 2008-07-29. Accesat 2009-04-28.

"Alcatel-Lucent fourth quarter 2010 earnings" (Press release). Alcatel-Lucent. 2011-02-10.

2012 Annual Report on Form 20-F

"Alcatel-Lucent reportedly to reduce workforce by 10,000 jobs". Accesat October 9, 2013.

"Alcatel-Lucent Builds Future Around IP". Light Reading. Retrieved 18 April 2015.

"Nokia agrees to buy Alcatel-Lucent for $16.6 billion". The Verge. Retrieved 15 April 2015.

lucent.com/wps/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnMz0vM0Y_QjzKLd4w3sfQGSYGYRq6m-pEoYgbxjggRX4_83FT9IH1v_QD9gtzQiHJHR0UAdXXZMA!!/delta/base64xml/L3dJdyEvd0ZNQUFzQUMvNElVRS82X0FfNUxJ "Alcatel-Lucent History". Company Overview. Alcatel-Lucent. 2009. Retrieved 2009-04-28.

"Alcatel-Lucent Merger Timeline". News Features. Alcatel-Lucent. 2006. Retrieved 2010-04-25.

Leers, Kaj (2007-12-18), "Draka to pay 209 mln eur to Alcatel-Lucent for 49.9 pct stake in Comteq JV", Forbes, retrieved 2010-07-28

"Dassault Aviation completes the acquisition of Alcatel-Lucent's stakes in Thales". Press Release. Alcatel-Lucent. 2009. Retrieved 2010-04-25.

"Alcatel-Lucent acquires OpenPlug, a cross-platform mobile software development tool provider". Press Release. Alcatel-Lucent. 2010. Retrieved 2010-11-04.

"Alcatel-Lucent sells Genesys for $1.5bn". October 19, 2011.

"NOKIA AND ALCATEL-LUCENT TO COMBINE TO CREATE AN INNOVATION LEADER IN NEXT GENERATION TECHNOLOGY AND SERVICES FOR AN IP CONNECTED WORLD". Nokia. Retrieved 15 April 2015.

"Merger of Nokia With Alcatel-Lucent Could Put Pressure on Prices". Wall Street Journal. 14 April 2015. Retrieved 15 April 2015. (subscription required)

"Thomson part of CGE".

"Alcatel is formed" (PDF).

"Cables dy Lyon subsidiary of Alcatel".

"CGE privatized".

"Alcatel-Lucent Company History".

"New York Times coverage of Rockwell unit sale". The New York Times. 1991-07-13.

"CGE acquires Rockwell".

"Alcatel and Lucent Talks".

Schiesel, Seth (1998-06-05). "Alcatel acquires DSC for $4.4 billion". NY Times.

"Alcatel Buys Packet Engines". Wired. 1998-10-13.[dead link]

"Nexans Press Release". Oct 9, 2000.

"Draka Press Release" (PDF). May 17, 2004.

"TCL Unit to Buy 45% Stake of Mobile-Phone Venture From Alcatel". Bloomberg. 2005-05-16.

"History of AT&T and Television". AT&T.

1947 Western Electric Annual Report. Western Electric. 1947. p. 5.

"coversheet for technical memoranda" (PDF). Retrieved 2012.

"AT&T Milestones".

Bell Laboratories Record. June 1980. p. 189.

"Long-Haul Lightwave Transmission System".

Lucent Technologies to Acquire Yurie Systems for $1 Billion – New York Times. Nytimes.com (1998-04-28). Retrieved on 2013-08-22.

Jeong Kim Biography – Academy of Achievement. Achievement.org (2008-08-18). Retrieved on 2013-08-22.

Ben Rooney (February 7, 2011). "Alcatel-Lucent Shrinks Cell Tower". The Wall Street Journal: Technology. Retrieved 2012-01-25.

Alcatel-Lucent sells Genesys for $1.5bn Financial Times, 19 October 2011

"Nokia just bought Alcatel-Lucent for $16.6 billion". Engadget. 15 April 2015. Retrieved 15 April 2015.

"Nokia to buy Alcatel-Lucent to grow in telecom". Reuters. 15 April 2015. Retrieved 15 April 2015.

"[1]." Alcatel-Lucent Fast Facts. Retrieved on 31 July 2014 "Headquarters 148/152 route de la Reine 92100 Boulogne-Billancourt, France"

"[2]." Alcatel-Lucent Fact Sheet. Retrieved on 17 August 2011 "Headquarters 3 av. Octave Gréard 75007 Paris, France"

"la tête dans les étoiles." Le Journal du Net. Retrieved on 8 July 2010.

"Regional Groups". Company Overview. Alcatel-Lucent. 2009. Retrieved 2009-04-28.

"ALU MEA". Alcatel-Lucent. Retrieved 2009-06-02.

Alcatel-Lucent's board of directors http://www.alcatel-lucent.com/about/governance

Leadership team, Alcatel-Lucent's website

"Innovation". Alcatel-Lucent. 2009. Retrieved 2009-04-28.

"AT&T History".

"IEEE Global History Network: Transistors".

31 Terabits por segundo: Alcatel-Lucent bate récord mundial de transmisión de datos submarina. Businesscol.com (2013-07-23). Retrieved on 2013-08-22.

"Technology Review 2012". Technology Review. 2012.

"Global Mobile Awards 2012". Global Mobile Congress. March 2012.

FCPA Blog (28 December 2010). "Alcatel-Lucent Settles Bribery Case". FCPA Blog.

U.S. Securities and Exchange Commission (27 December 2010). "SEC Charges Alcatel-Lucent with FCPA Violations". U.S. Securities and Exchange Commission.

United States District Court for the Southern District of Florida (27 December 2010). "Securities and Exchange Commission v Alcatel-Lucent, S.A." (PDF). U.S. Securities and Exchange Commission.

Department of Justice, Office of Public Affairs (27 December 2010). "Alcatel-Lucent S.A. and Three Subsidiaries Agree to Pay $92 Million to Resolve Foreign Corrupt Practices Act Investigation". The United States Department of Justice.

Pleading Paper

"Microsoft faces $1.5bn MP3 payout". BBC News. 2007-02-22. Retrieved 2010-04-23.

"Microsoft hit with $1.5 billion patent verdict". CNET. CBS Interactive. Retrieved 18 April 2015.

Bangeman, Eric (2007-08-06). "Judge tosses verdict, $1.52 billion award in Microsoft MP3 patent case". arstechnica. Archived from the original on 29 August 2007. Retrieved 2007-08-07.[dead link]

Broache, Anne (2007-03-02). "Microsoft wins in second Alcatel-Lucent patent suit". CNET News.com. Archived from the original on 5 March 2007. Retrieved 2007-03-04.

Montalbano, Elizabeth (2007-03-03). "One Patent Claim Against Microsoft Dropped". Retrieved 2007-03-04.

"Newegg nukes "corporate troll" Alcatel in third patent appeal win this year". Ars Technica. Retrieved 18 April 2015.

Bibliografie

Titus Slavici, Conducerea cu calculatoare, Politehnică 1996

Titus Slavici, Elemente fundamentale ale proiectarii si fabricarii asistate pe calculator, Eurobit 1999

Gheorghe Petrov, Ioan Despi, Robert Reisz, Aurel Stepan, Teoria generala a bazelor de date, Editura MIRTON Timișoara 2000.

Győrödi Cornelia, Pecherle George, “Baze de date relaționale. Teorie și aplicații în Oracle“, Editura Universitati, 2008

Győrödi Cornelia, Győrödi Robert, Baze de date relationale. Concepte avansate ,Editura Treira, 2000.

Aurel Stepan , G. Priboi, Sisteme informatice distribuite, Universitatea din Timișoara, 1985.

Tsichritzis, D.;Klug, A. The ANSI/X3/SPARC DBMS frame work report of the study group of database management system, Info System, 1978.

Astrahan, M.M. e.a. (1976) Sistem R: relational approach to data base management, ACM Trans. Database Systems 1 (1976).

Brodie, M.L; Schmidt, J.W. (ed.) (1982) Final report of the relational database task group ANSI/X3/SPARC/DBSSG, ACM SUGMOD Record 12 (1982).

Chamberlin, D.D. e.a. (1976) SEQUEL 2 : An unifiedapproach to data definition, manipulation and control, IBM J. of. Res. And Developement 20 (1976).

Codd, E.F. (1979) Extending the database relational model to capture more meaning, ACM Trans. Database System 4 (1979)

Date, C.J. (1982) A formal definition of the relational model, ACM SIGMOD Record 13 (1982).

Cohen, J. (1981) Garbage collection of linked data structures, ACM Computing Surveys, 13.

Comer, D. (1979) The ubiquitous B-tree, ACM Computing Surveys,11.

Knuth, D.E. (1973) The Art of Computer Programming, Vol 3: Sorting and Searching, , Addison Wesley, Reading, Mass.

Loomis, M.E.S.(1983) Data Management and File Processing, Prentice Hall, Englewood Cliffs, N.J.

Tannenbaum, A.M.; Augestein, M.S. (1981) Data Structures Using Pascal, Prentice Hall, Englewood Cliffs.

Hsiao, D. (1983) Advanced Database Machine Architecture, Prentice Hall, Englewood Cliffs, NJ.

Neches, P.M. (1984) Hardware support for advanced data management system, Computer, 17.

RDMS Design Principles. RDMS Reference Guide, MIT, Cambridge, Mass.

Stonebraker, M. e.a. (1974) The design of implementation of INGRES, ACM Transaction on Database Systems, 1.

Todd, S. (1975) An efficient implementation for large relational databases, Proc. International Conf. on Very Large Databases, Framigham Mass.

Alcatel-Lucent :

http://www3.alcatel-lucent.com/wps/DocumentStreamerServlet?LMSG_CABINET=Docs_and_Resource_Ctr&LMSG_CONTENT_FILE=Financial_Info/Income_Statements/IR-2013-ALU-20-F.pdf

http://www.sustainability-indices.com/images/140911-djsi-review-2014-en-vdef.pdf

"Thomson Reuters Names the 2014 Top 100 Global Innovators". Retrieved 18 April 2015.

"Alcatel-Lucent announces Chairman Serge Tchuruk and CEO Pat Russo to step down" (Comunicat de presa). Alcatel-Lucent. 2008-07-29. Accesat 2009-04-28.

"Alcatel-Lucent fourth quarter 2010 earnings" (Press release). Alcatel-Lucent. 2011-02-10.

2012 Annual Report on Form 20-F

"Alcatel-Lucent reportedly to reduce workforce by 10,000 jobs". Accesat October 9, 2013.

"Alcatel-Lucent Builds Future Around IP". Light Reading. Retrieved 18 April 2015.

"Nokia agrees to buy Alcatel-Lucent for $16.6 billion". The Verge. Retrieved 15 April 2015.

lucent.com/wps/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnMz0vM0Y_QjzKLd4w3sfQGSYGYRq6m-pEoYgbxjggRX4_83FT9IH1v_QD9gtzQiHJHR0UAdXXZMA!!/delta/base64xml/L3dJdyEvd0ZNQUFzQUMvNElVRS82X0FfNUxJ "Alcatel-Lucent History". Company Overview. Alcatel-Lucent. 2009. Retrieved 2009-04-28.

"Alcatel-Lucent Merger Timeline". News Features. Alcatel-Lucent. 2006. Retrieved 2010-04-25.

Leers, Kaj (2007-12-18), "Draka to pay 209 mln eur to Alcatel-Lucent for 49.9 pct stake in Comteq JV", Forbes, retrieved 2010-07-28

"Dassault Aviation completes the acquisition of Alcatel-Lucent's stakes in Thales". Press Release. Alcatel-Lucent. 2009. Retrieved 2010-04-25.

"Alcatel-Lucent acquires OpenPlug, a cross-platform mobile software development tool provider". Press Release. Alcatel-Lucent. 2010. Retrieved 2010-11-04.

"Alcatel-Lucent sells Genesys for $1.5bn". October 19, 2011.

"NOKIA AND ALCATEL-LUCENT TO COMBINE TO CREATE AN INNOVATION LEADER IN NEXT GENERATION TECHNOLOGY AND SERVICES FOR AN IP CONNECTED WORLD". Nokia. Retrieved 15 April 2015.

"Merger of Nokia With Alcatel-Lucent Could Put Pressure on Prices". Wall Street Journal. 14 April 2015. Retrieved 15 April 2015. (subscription required)

"Thomson part of CGE".

"Alcatel is formed" (PDF).

"Cables dy Lyon subsidiary of Alcatel".

"CGE privatized".

"Alcatel-Lucent Company History".

"New York Times coverage of Rockwell unit sale". The New York Times. 1991-07-13.

"CGE acquires Rockwell".

"Alcatel and Lucent Talks".

Schiesel, Seth (1998-06-05). "Alcatel acquires DSC for $4.4 billion". NY Times.

"Alcatel Buys Packet Engines". Wired. 1998-10-13.[dead link]

"Nexans Press Release". Oct 9, 2000.

"Draka Press Release" (PDF). May 17, 2004.

"TCL Unit to Buy 45% Stake of Mobile-Phone Venture From Alcatel". Bloomberg. 2005-05-16.

"History of AT&T and Television". AT&T.

1947 Western Electric Annual Report. Western Electric. 1947. p. 5.

"coversheet for technical memoranda" (PDF). Retrieved 2012.

"AT&T Milestones".

Bell Laboratories Record. June 1980. p. 189.

"Long-Haul Lightwave Transmission System".

Lucent Technologies to Acquire Yurie Systems for $1 Billion – New York Times. Nytimes.com (1998-04-28). Retrieved on 2013-08-22.

Jeong Kim Biography – Academy of Achievement. Achievement.org (2008-08-18). Retrieved on 2013-08-22.

Ben Rooney (February 7, 2011). "Alcatel-Lucent Shrinks Cell Tower". The Wall Street Journal: Technology. Retrieved 2012-01-25.

Alcatel-Lucent sells Genesys for $1.5bn Financial Times, 19 October 2011

"Nokia just bought Alcatel-Lucent for $16.6 billion". Engadget. 15 April 2015. Retrieved 15 April 2015.

"Nokia to buy Alcatel-Lucent to grow in telecom". Reuters. 15 April 2015. Retrieved 15 April 2015.

"[1]." Alcatel-Lucent Fast Facts. Retrieved on 31 July 2014 "Headquarters 148/152 route de la Reine 92100 Boulogne-Billancourt, France"

"[2]." Alcatel-Lucent Fact Sheet. Retrieved on 17 August 2011 "Headquarters 3 av. Octave Gréard 75007 Paris, France"

"la tête dans les étoiles." Le Journal du Net. Retrieved on 8 July 2010.

"Regional Groups". Company Overview. Alcatel-Lucent. 2009. Retrieved 2009-04-28.

"ALU MEA". Alcatel-Lucent. Retrieved 2009-06-02.

Alcatel-Lucent's board of directors http://www.alcatel-lucent.com/about/governance

Leadership team, Alcatel-Lucent's website

"Innovation". Alcatel-Lucent. 2009. Retrieved 2009-04-28.

"AT&T History".

"IEEE Global History Network: Transistors".

31 Terabits por segundo: Alcatel-Lucent bate récord mundial de transmisión de datos submarina. Businesscol.com (2013-07-23). Retrieved on 2013-08-22.

"Technology Review 2012". Technology Review. 2012.

"Global Mobile Awards 2012". Global Mobile Congress. March 2012.

FCPA Blog (28 December 2010). "Alcatel-Lucent Settles Bribery Case". FCPA Blog.

U.S. Securities and Exchange Commission (27 December 2010). "SEC Charges Alcatel-Lucent with FCPA Violations". U.S. Securities and Exchange Commission.

United States District Court for the Southern District of Florida (27 December 2010). "Securities and Exchange Commission v Alcatel-Lucent, S.A." (PDF). U.S. Securities and Exchange Commission.

Department of Justice, Office of Public Affairs (27 December 2010). "Alcatel-Lucent S.A. and Three Subsidiaries Agree to Pay $92 Million to Resolve Foreign Corrupt Practices Act Investigation". The United States Department of Justice.

Pleading Paper

"Microsoft faces $1.5bn MP3 payout". BBC News. 2007-02-22. Retrieved 2010-04-23.

"Microsoft hit with $1.5 billion patent verdict". CNET. CBS Interactive. Retrieved 18 April 2015.

Bangeman, Eric (2007-08-06). "Judge tosses verdict, $1.52 billion award in Microsoft MP3 patent case". arstechnica. Archived from the original on 29 August 2007. Retrieved 2007-08-07.[dead link]

Broache, Anne (2007-03-02). "Microsoft wins in second Alcatel-Lucent patent suit". CNET News.com. Archived from the original on 5 March 2007. Retrieved 2007-03-04.

Montalbano, Elizabeth (2007-03-03). "One Patent Claim Against Microsoft Dropped". Retrieved 2007-03-04.

"Newegg nukes "corporate troll" Alcatel in third patent appeal win this year". Ars Technica. Retrieved 18 April 2015.