Integrarea a Doua Sisteme de Cloud Windows Azure Si Office 365
Cuprins
Capitolul 1
1. Introducere
1.1. Descrierea temei
1.2. Organizarea lucrării
Capitolul 2
2. Concepte teoretice și prezentarea generală a tehnologiilor folosite
2.1. Cloud computing
2.1.1. Caracteristici
2.1.2. Avantaje și dezavantaje
2.1.3. Servicii
2.1.4. Mutarea în cloud?
2.2. Windows Azure
2.2.1. Trăsături
2.2.2. Servicii
2.2.3. Implementare
2.3. Microsoft Office 365
2.3.1. Istoric
2.3.2. Caracteristici
2.3.2.1. Servicii cloud
2.3.2.2. Aplicații Office
2.3.2.3. Securitate
2.3.2.4. Ediții
2.4. Sharepoint
2.4.1. Generalitați
2.4.2. Sharepoint 2013
2.4.3. SharePoint Online
2.5. JavaScript
2.5.1. Istoric
2.5.2. Avantaje și dezavantaje
2.5.3. Versiuni
2.6. AJAX
2.7. jQuery
2.7.1. Caracteristici
2.7.2. Extensii
Capitolul 3
3. SCRUM
3.1. Pași
3.2. Istoric
3.3. Terminologie
Capitolul 4
4. Implementarea soluției
4.1. Cerințe funcționale
4.2. Arhitectura aplicației
4.3. Baza de date
4.4. Utilizarea Microsoft Office 365 și Windows Azure
4.4.1. Integrarea celor două cloud-uri
4.5. Ghidul aplicației
Capitolul 5
5. Posibilități de dezvoltare
Bibliografie
Capitolul 1
Introducere
Descrierea temei
Majoritatea companiilor au un sistem de gestiune a delegațiilor pentru angajați, însa puține firme folosesc un sistem automat, care să optimizeze și să faciliteze procesul parcurs pentru obținerea unei delegații. Tema lucrarii pornește de la această idee și propune o soluție pentru automatizarea sistemului de gestiune a delegațiilor în marile companii. Soluția propusă este o aplicație web, implmentată în Sharepoint 2013, folosind integrarea a două cloud-uri, Windows Azure cu Microsoft Office 365.
Am ales să folosesc cloud computing, deoarece reduce vizibil costurile și aduce optimizari pentru companii.
Această tema a fost propusă, aleasă și supevizată de compania iQuest deoarece folosește tehnologii actuale, tema este de interes practic pentru firma, iar integrarea de cloud-uri poate fi folosită cu succes și în alte contexte.
Situația actuală de gestionare a delegațiilor are anumite neajunsuri. Pentru a obține aprobarea unei delegații, un angajat crează o cerere în care precizeaza orașul, hotelul și perioadă în care dorește să plece în delegație. Această cerere o trimite managerului de proiect și departamentului de resurse umane și asteaptă să fie aprobata. Dacă primește aprobarea, pleaca în delegație și la întoarcere trimite mail la departamentul de resurse umane pentru a i se deconta cheltuielile. Acest proces este unul anevoios, iar refuzarea unei cereri, duce la reluarea acestui proces. Mai mult angajatul nu are nici o informație despre starea în care se afla cererea pe care a trimis-o pana la raspunsul final, iar numarul mare de cereri crește timpul de așteptare.
Soluția mea de gestionare a delegațiilor presupune optimizarea acestei situații. Folosind această aplicație, angajatul își alege țara și orașul în care dorește să plece în delegație și este afisată harta cu hotelurile din orașul selectat. Angajatul alege un hotel avand posibilitatea să vizualizeze detaliile și imaginile de prezentare ale hotelului și specifica perioadă delegației. Se verifica automat dacă mai sunt locuri în acel hotel, în acea perioadă, pentru ca cererea să fie validă. Astfel s-a creat o cerere, care poate fi salvată, editată sau trimisă spre aprobare prin pornirea unui workflow de aprobare. În momentul pornirii workflow-ului, cererea este trimisă automat managerului de proiect. Dacă aprobă cererea, aceasta este trimisă automat departamentului de resurse umane, iar prin aprobarea de catre acest departament, raspunsul pozitiv este trimis automat angajatului. Dacă managerul de proiect respinge cererea, aceasta se intoarce la angajat care o poate modifica și retrimite din nou.
Organizarea lucrării
Lucrarea este structurată în 4 capitole pe care le voi prezenta succint în cele ce urmează:
Capitolul 1 prezintă în amanunt conceptele teoretice folosite în dezvoltarea aplicației. Capitolul cuprinde informații despre cele două cloud-uri: Office 365 și Azure, inclusiv avantajele, dezavantajele și restrictiile integrarii celor două cloud-uri.
Capitolul 2 descrie metodologia Agile SCRUM pe care am folosit-o în dezvoltarea aplicației. Metodele Agile sunt gandite să faca fața unor proiecte cu cerințe ce se schimbă des pe parcursul ciclului de dezvoltare. Prin mod iterativ și incremental de dezvoltare se ințelege atat revizuirea cerintelor clientului cât și mecanisme de participare ale acestuia în luarea deciziilor. Prin dezvoltarea acestui proiect, am simulat folosirea metodologiei SCRUM, fiind susținută de managerul meu de proiect.
Capitolul 3 specifica pasii urmați în implementarea și dezvoltarea soluției. Sunt urmarite aici cerințele aplicației, integrarea celor două cloud-uri prin descrierea proiectelor care alcatuiesc soluția și ghidul de folosire al aplicației.
Capitolul 4 indică cateva direcții în care ar putea fi dezvoltată aplicația.
Capitolul 2
Concepte teoretice și prezentarea generală a tehnologiilor folosite
Cloud computing
Cloud computing (se traduce literal „calculare în nor”, concret „calcul în Internet”) este un concept modern în domeniul computerelor și informaticii, reprezentând un ansamblu distribuit de servicii de calcul, aplicații, acces la informații și stocare de date, fără ca utilizatorul să aibă nevoie să cunoască amplasarea și configurația fizică a sistemelor care furnizează aceste servicii. O altă definiție a cloud-ului ar fi: o soluție de utilizare a resurselor informatice externe (servere, spațiu de stocare, aplicații și servicii) prin intermediul Internetului [1].
Cuvântul „cloud”, fără nici o îndoială, este unul dintre cuvintele cele mai ambigue în industria de tehnologie informatica de astăzi. Dacă sunt întrebate zece persoane cu privire la modul în care ele definesc cuvântul „cloud” se vor observa zece raspunsuri diferite. Ceea ce constituie lumea „cloud” este însa o întrebare destul de complexă. Cu toate acestea, există un factor comun care răspunde la această intrebare: Cloud-ul este „ceva” care poate fi oferit ca un serviciu pentru care grijile cu privire la modul în care este pus în aplicare și menținut, dispar. De asemenea, pentru utilizarea serviciilor cloud este nevoie de acces la Internet, fără internet conceptul de cloud nu există. Cloud computing se referă la o gamă variată de servicii scalabile care sunt disponibile la cerere.
În scopul de a utiliza aceste servicii, este nevoie de o conexiune la Internet, de preferat una cu lățime de bandă cât mai mare și latență scăzută. Furnizori, cum ar fi Microsoft, IBM, Oracle oferă diverse servicii bazate pe cloud pentru care companiile plătesc, deoarece consumă serviciile lor. Ofertele de servicii din lumea internetului nu sunt o noutate. De exemplu, bine cunoscuții furnizori de e-mail (cum ar fi AOL, Yahoo și Microsoft), ei oferă servicii gratuite (POP, IMAP și așa mai departe), precum și alte servicii (cum ar fi expediere de e-mail și filtrele de spam) și de depozitare la un cost suplimentar. Acest lucru înseamnă ca toți consumatorii sunt de acord în aceste zile cu dinamică din spatele acestui model de serviciu. Ce lipsește însă, este o imagine detaliată a diferitelor abordări ale furnizoriilor care oferă servicii de cloud [2].
Expresia cloud computing derivă dintr-o reprezentare grafică simbolică a Internetului des întâlnită în formă de nor („the cloud”), folosită atunci când detaliile tehnice ale Internetului pot fi ignorate, ca în urmatoarea imagine [1].
De ce cloud acum?
De ce cloud-ul a câștigat atât de multă atenție în ultimii ani? Unul dintre raspunsuri este ca se reduce mult costul de software și astfel se pot utliza economiile de costuri pentru dezvoltarea afacerii. Dificultațile întampinate în actualizările de hardware și software sunt facute de cloud pentru voi. Din ce în ce mai multe întreprinderi bazate pe Internet încep să crească, iar creșterea lor necesită un model de lucru în care companiile pot plăti și extinde pe masura ce cresc, decât să faca investiții pentru capacitatea de care e posibil să nu aiba nevoie. Pentru intreprinderi medii și mari, servicile de cloud oferă soluții chiar mai variate. De exemplu, companiile pot utiliza serviciile de cloud în principal pentru scopuri SDLC și de asigurare a calității și poate totuși să păstreze mediul lor de producție local. În schimb, în cazul în care se dorește disponibilitate ridicată și toleranță la erori, serviciile de cloud oferă o modalitate de a reduce riscurile în caz de dezastru [2].
Aplicațiile economice tradiționale necesita foarte multe condiții, ceea ce le face mult prea greu de gestionat și prea scumpe pentru companiile mici. Ele au nevoie pentru a functiona de servere, spatii pentru ele, retele, latime de bandă, capacitați de stocare, etc. mai fiind nevoie și de o echipă pentru a le instala, configura și pentru a le intretine [3].
Cu cloud computing, gestionarea unei afaceri devine mult mai usoara. În loc de o echipă care să gestioneze rețeaua de calculatoare și servere pe care sunt instalate aplicațiile, se poate folosi doar un centru de date unde aceste aplicații sunt stocate [3].
Soluțiile cloud scutesc companiile de cheltuieli pentru servere, licente software, hosting, mentenanța sau personal tehnic specializat. În plus, aplicațiile cloud beneficiaza de upgrade automat, asa ca aplicația va fi sigură, performanța și va avea functionalitați noi fără nici un efort din partea companiilor care folosesc soluții cloud [3].
Chiar și modul de plată pentru aceste aplicații poate fi diferit. Totul se rezuma la un abonament lunar, care include absolut tot ce e nevoie pentru funcționarea aplicațiilor [3].
Extinderea conceptului de cloud computing a dus și la extinderea unui alt fenomen: cel de SaaS. Asta înseamna ca zilele “licentei” , asa cum le stim noi, sunt pe sfarsite și ca a livra functionalitatile unei aplicații prin browser catorva mii de utilizatori va fi privit ca și un serviciu efectuat în baza unui abonament lunar. Pentru client, această înseamna lipsa unei investiții initiale în infrastructură sau software, iar pentru producator costuri reduse de dezvoltare și intretinere a unor astfel de aplicații[3].
Caracteristici
Conexiunea permanentă a utilizatorului la Internet a devenit foarte răspândită, astfel încât acum aproape toate resursele disponibile se pot plasa în Internet și partaja uneori chiar între utilizatori, complet independenți unii fată de alții: software (programele) și datele/informațiile sunt aduse din Internet pe calculatorul utilizatorului la cerere (on demand), ca și cum ar fi vorba de servicii publice banale precum apa sau energia electrică [1].
Executarea aplicațiilor de computer online în Internet și nu pe stația de lucru (workstation) proprie, reprezintă o nouă schimbare de paradigmă, urmașă a celei din anii 1980, când s-a trecut de la mainframes la conceptul client-server. Dacă interfața pusă la dispoziție de furnizorul de cloud computing este de bună calitate, atunci utilizatorul e eliberat de sarcina de a fi un expert în tehnologia și infrastructură folosite. De exemplu, el nu mai trebuie să-și actualizeze software-ul, deoarece aceasta se face central, la furnizor [1].
Cloud computing folosește noi metode de oferire și consumare a serviciilor IT în Internet, servicii care de obicei pot fi dimensionate dinamic și care includ resurse virtualizate. Este de fapt doar o posibilitate secundară, urmare a ușurinței cu care se pot acum accesa toate serverele și centrele de calcul interconectate prin intermediul Internetului [1].
Furnizorii tipici de cloud computing pun la dispoziție, de exemplu, aplicații comerciale standard; utilizatorul are acces la acestea doar prin intermediul unui browser local, deoarece atât aplicația cât și datele proprii ale utilizatorului sunt găzduite în cloud, pe serverul furnizorului de servicii. În aceste condiții asigurarea confidențialității și drepturilor de acces la date în contextul Internetului atotprezent joacă un rol primordial [1].
Deseori furnizorii de cloud prevăd și servicii suplimentare, consolidând toate ofertele lor, pentru toți clienții, într-un singur loc (pagină sau site web). Ofertele comerciale trebuie în general să îndeplinească standardele de calitate cerute de clienți, ca exemplu, așa numitele SLA și altele. Cei mai mari furnizori din acest domeniu sunt companiile Microsoft, Salesforce, Skytap, HP, IBM, Amazon și Google [1].
Avantaje și dezavantaje
Avantaje:
Sincronizarea datelor utilizatorului care folosește mai multe dispozitive legate la cloud (de ex. un smartphone, o tabletă, un notebook, dar și un PC) este simplificată;
Documentele online din cloud se pot prelucra cu ajutorul unor aplicații web;
Viteza de calcul și capacitate de stocare sporite, dar fără investiții în propria configurație;
Datele nu pot fi furate
Purtătorul de date nu se poate defecta etc [1].
Dezavantaje:
E necesară o legătură la Internet rapidă și stabilă;
Securitatea necesară a datelor din cloud poate prezenta probleme și poate produce neîncrederea utilizatorilor;
Situația legală este de obicei complexă, deoarece utilizatorul nu află nici măcar în ce țară sau în ce țări se află serverele care îi găzduiesc datele sale [1].
Servicii
Astăzi, există un spectru larg de servicii disponibile în cloud, inclusiv soluții de mesagerie, soluții colaborative, soluții de management al identitatii, soluții de stocare, relația de management cu clienții și multe altele. De exemplu, Microsoft a lansat Office 365, care oferă o versiune on-line a SharePoint Server, Exchange Server și Lync Server. Microsoft oferă, de asemenea și platforma Windows Azure, ceea ce face ca sistemul de operare Windows Server alături de alte caracteristici să fie disponibile ca servicii [2].
Se observa ca modul în care sunt furnizate: sistemul de operare Windows (oferit de platforma Azure) și Microsoft Office Server cu produsele client (oferite de Office 365), sunt fundamental diferite. Un sistem de operare oferă un set de bază, de funcționalitate și poate fi folosit, practic pentru orice: de la un site de e-commerce pana la software-ul complex de procesare video. Pentru a aborda acest lucru în lumea de cloud computing, există trei abordări diferite pentru serviciile bazate pe cloud:
➤ Infrastructură ca un Serviciu (IaaS)
➤ Platforma ca un Serviciu (PaaS)
➤ Software ca un Serviciu (SaaS) [1].
Infrastructură ca un serviciu (IaaS)
Cu o infrastructură ca serviciu (IaaS), se pot externaliza practic elemente tipice de infrastructură, cum ar fi de virtualizare, stocare, networking, de load-balancing și așa mai departe, de la un furnizor, la alegere. Furnizorul care ofera IaaS taxează, pentru utilizarea serviciilor de infrastructură, conform acordului la nivel de servicii (SLA). Unul dintre cele mai mari beneficii de la IaaS este ca acestă oferă un control granular, în care puteți alege componentele de bază pentru infrastructură. Odată cu lansarea VM Role pe Azure, Microsoft a intrat în spațiul IaaS, împreună cu furnizorii: Amazon EC2, GoGrid și OpSource, care deja sunt pe piață IaaS [1].
Platforma ca un serviciu (Paas)
Platforma ca un Serviciu (PaaS) oferă o platformă de bază unde se pot implementa aplicații personalizate. Cu PaaS nu trebuie să se lucreze cu elemente la nivel de infrastructură și de configurare de networking și de securitate, toate aceste lucruri fiind făcute de către furnizor. Astfel sunt furnizate cu un sistem de operare complet funcțional și cu software-ul necesar. De exemplu, platforma Microsoft Azure oferă suport pentru cea mai recentă versiune a cadrului .NET. Folosind acest tip de serviciu înseamnă ca toată concentrarea este canalizată pe implementarea aplicațiilor personalizate pe platformă iar configurarea se face cu ușurință pentru aplicații. Unul dintre avantajele cheie ale PaaS este ca toate grijile cu privire la rularea sistemului de operare sau la actualizările de platformă, precum și upgrade-uri hardware, dispar. Furnizorul de patch-uri în mod regulat actualizază sistemul de operare, indiferent de caracteristicile platformei (cum ar fi de . NET sau motor de baze de date SQL) și face actualizări hardware, la cerere, pentru a satisface nevoile clientului. Microsoft oferă platforma Azure ca PaaS, pentru ca suportă diferite tipuri de Worker Roles și diferite tipuri de aplicații. De exemplu, se pot rula aplicații web cu Web Roles, precum și aplicații de host middle tier (nivel de mijloc gazdă), cum ar fi fluxul de lucru, în Worker Roles. De asemenea, SQL Azure furnizează baza de date relaționala Microsoft ca un serviciu de platformă [1].
Software as a Service (SaaS)
Cu Software as a Service (SaaS), ca furnizor acesta gestionează tot, de la infrastructură, inclusiv echilibrul de încărcare, firewall-uri, platforme, cum ar fi sisteme de operare și medii virtuale (.Net și Java). SaaS ofera servicii provizionate în totalitate și terminate cu un set de caracteristici bine definite, care pot fi personalizate mai târziu, într-o anumită măsură. Furnizorii oferă de obicei interfețe bazate pe browser, astfel încât utilizatorii pot accesa și personaliza cu ușurință aceste servicii. API-urile sunt de asemenea, disponibile pentru dezvoltatori. Microsoft Office 365 oferă, aceste tipuri de servicii, care includ în prezent, SharePoint Online, Exchange Online, Lync Online și Office Professional Plus. Cele mai multe dintre aceste servicii on-line au un subset de caracteristici asemanatore cu spațiile comerciale [1].
Mutarea în cloud?
Se stie ca un sistem cloud are beneficii majore, dar fiecare organizație ar trebui să ia în calcul alți factori pentru a determina dacă cloud-ul este o alegere bună. Avantajele de economii de cost și scalabilitate la cerere sunt ispite evidente pentru a trece la cloud, dar o organizație trebuie să ia în considerare, de asemenea, dezavantajele cloud, cum ar fi probleme de conectare în rețea și lipsa legilor globale de protecție a informațiilor. Deși este imposibilă acoperirea tuturor aspectelor care intră în decizia mutarii în cloud, următoarelele aspecte trebuie luate în considerare:
➤ problemele de conectivitate de rețea sunt tolerabile? Acest lucru implică probleme cum ar fi lipsa lățimii de bandă și latență scăzută.
➤ mutarea în cloud are impact asupral IP-ului de organizare al companiei (protectia informatiilor) politici? Nu fiecare țară/regiune urmează aceleași practici și politici, informațiile stocate în cloud (stocate la centrul de date de furnizori) pot fi supuse unor audituri guvernamentale sau de alte politici. În plus, în cazul în care furnizorul de cloud găzduiește datele în centre de date în afara țării companiei, există dreptul executarii legilor din legislație.
➤ Ce se întâmplă dacă serviciul devine indisponibil? Ce impact va avea asupra productivitatii?
➤ Ce se întâmplă cu pierderile de informații? E nevoie de un plan de acțiune în cazul în care informațiile importante sunt în mod intenționat/accidental pierdute din cloud. Pierderile de informații pot include, adrese de e-mail și prognoza financiară a companiei.
➤ Mutarea în cloud ce impact are asupra proceselor, politicilor și procedurilor? Service Level Agreement-furnizorul trebuie întotdeauna să alinieze în totalitate necesitățile operaționale ale organizației și a politicilor juridice [1].
Windows Azure
Platforma Windows Azure oferă o platformă intuitivă, fiabilă și puternică pentru crearea de aplicații și servicii Web. Windows Azure a devenit disponibil la data de 1 Februarie 2010. Platforma Windows Azure este alcătuită din:
Windows Azure: un sistem de operare, ca serviciu
SQL Azure: o bază de date relațională completă în Cloud
AppFabric: servicii de tip Web orientate spre consumator care oferă conectivitate sigură și control al accesului federalizat pentru aplicații [4].
Platforma Windows Azure este creata de Microsoft, pentru construirea, implementarea și gestionarea aplicațiilor și serviciilor prin intermediul unei rețele globale gestionate de Microsoft. Acesta oferă platformă ca serviciu (PaaS), infrastructură ca serviciu (IaaS) și suportă urmatoarele limbaje de programare: .NET, PHP, Ruby, Java și Python . Windows Azure este produsul Microsoft care concurează cu AWS platforma Amazon cloud computing, Google App Engine și alte sisteme [4].
Windows Azure vă permite să dezvoltati ușor aplicațiile la orice dimensiune. Este o platforma self-service complet automată care pune la dispoziție resursele în câteva minute. Se plăteste numai pentru resursele folosite [4].
Trăsături
In iunie 2012, Windows Azure a lansat următoarele caracteristici noi:
Site-uri web care permit dezvoltatorilor să construiască site-uri folosind ASP.NET, PHP, sau Node.js și pot fi implementate folosind FTP, Git, sau Team Foundation Server.
Masini virtuale care permite dezvoltatorilor să migreze aplicațiile și infrastructură fără a schimbă codul existent, putând rula atât pe Windows Server cât și pe masini virtuale cu Linux.
Servicii de cloud – Platforma Microsoft ca (PaaS) mediu de servicii, care este folosit pentru a crea aplicații și servicii scalabile. Suporta scenarii multi-nivel și implementările automate.
Data Management – Baza de date SQL, cunoscut anterior ca SQL Azure baze de date, lucrează pentru a crea, scala și extinde aplicațiile în cloud folosind tehnologia Microsoft SQL Server. Integrează cu Active Directory și Microsoft System Center și Hadoop.
Servicii mass-media – PaaS care pot fi utilizate pentru codificarea conținutului, protecția conținutului, streaming și/sau pentru analiză [4].
Platforma Windows Azure oferă un API bazat pe REST, HTTP și XML care permite unui dezvoltator să interacționeze cu serviciile oferite de această platformă. Microsoft oferă, de asemenea, client-side class library care incapsulează funcțiile care facilitează interacționarea cu serviciile. De asemenea, se integrează cu Microsoft Visual Studio, Git și Eclipse [4].
Servicii
Site-uri Web – Densitate mare degăzduire. Această caracteristică a fost anunțată în iunie 2012 la evenimentul Meet Windows Azure. Clienții pot crea site-uri web în PHP, .NET și Node.js, sau să selecteze din mai multe aplicații open source [4].
Mașinile virtuale – Anunțat la Meet Windows Azure în iunie 2012, Azure Windows Virtual Machines cuprinde ca infrastructură serviciul (IaaS), oferit de Microsoft pentru cloud-urile lor publice. Clienții pot crea mașini virtuale, pentru care au control complet, pentru a rula Microsoft Data Centers [4].
Serviciile de cloud – (denumite anterior "servicii de găzduite"), pentru Windows Azure cuprind PaaS din platforma Windows Azure. Serviciile Cloud sunt recipiente de găzduire pentru aplicații. Aceste aplicații pot fi expuse pe Internet ca aplicații web publice (cum ar fi site-uri web și soluții de comert electronic), sau pot fi motoare de procesare private pentru alte activități, cum ar fi procesarea comenzilor sau analiza datelor [4].
Dezvoltatorii pot scrie cod pentru servicii de cloud într-o varietate de limbaje de programare. Cu toate acestea, există chituri de dezvoltare de software specifice (SDK), creat de Microsoft pentru Python, Java, node.JS și NET [3]. Alte limbaje pot avea sprijin prin proiecte open source. Microsoft a publicat codul sursa pentru clientii lor pe GitHub [4].
Data Management [4]
Baze de date SQL
Tabele
Stocare BLOB
Analizele de afaceri [4]
Rapoarte SQL
Datele de piata
Hadoop
Identitate [4]
Active Directory
Access Control Service
Mesaje [4]
Windows Azure Service Bus
Cozi
Servicii Media [4]
Servicii pentru Telefonie Mobilă [4]
Implementare
Windows Azure folosește un sistem de operare de specialitate, denumit Windows Azure, pentru a rula "fabric layer" – un grup găzduit în centrele de date Microsoft, care gestionează resursele de calcul și de stocare ale calculatoarelor și pregatesc resursele (sau un subset al lor) aplicațiilor care ruleaza pe Windows Azure.
Windows Azure a fost descris ca un "cloud layer", în fruntea unui număr de sisteme Windows Server, care utilizează Windows Server 2008 și o versiune personalizată de Hyper-V, cunoscută sub numele de Windows Azure Hypervisor pentru a oferi virtualizare de servicii. Scalarea și fiabilitatea sunt controlate de Windows Azure Controller, astfel serviciile și mediul nu pațesc nimic în cazul în care unul dintre servere se opreste brusc în centrul de date Microsoft și asigură gestionarea cererii web a utilizatorului cu resursele de memorie și load balancing-ul [4].
Microsoft Office 365
Office 365 este un serviciu pe baza de abonament, care oferă acces la diverse servicii și programe existente în platforma Microsoft Office. Servind ca un succesor pentru Business Productivity Suite Microsoft Online, aceasta a inclus primul versiuni găzduite pentru Exchange, Lync, SharePoint, Office Web Apps, împreună cu acces la aplicațiile desktop Microsoft Office 2010 pe plan Enterprise. Odată cu apariția Office 2013, Office 365 a fost extins pentru a include diferite tipuri de afaceri, împreună cu un plan care vizează utilizatorii de acasă. După un proces de testare beta, care a început în octombrie 2010, Office 365 a fost lansat oficial la 28 iunie 2011 [4].
Istoric
Microsoft a anuntat prima data apariția Office 365 în octombrie 2010, începând cu o versiune beta privata pentru diferite organizații, care duce la apariția unei versiuni beta publice în aprilie 2011, și ajungând la disponibilitatea generală pe 28 iunie 2011. Confruntandu-se cu o concurența Google care este în creștere si care a lansat un serviciu similar denumit Google Apps, Microsoft a proiectat platforma Office 365 pentru "a aduce împreună" serviciile sale online existente (cum ar fi Business Productivity Online Suite) într-o „an always-up-to-date cloud service", care încorporează Exchange Server (e-mail), SharePoint (pentru crearea de rețele sociale interne, colaborare, servicii web) și Lync (pentru comunicare, VoIP, conferințe). Planul inițial a fost lansarea unui pachet pentru afaceri mici și întreprinderi. Pachetul pentru afaceri mici, oferea: Exchange e-mail, SharePoint Online, Lync Online, gazduire web prin intermediul SharePoint și Office Web Apps, cu planul de întreprindere de asemenea, adăugarea de licențe pentru fiecare utilizator pentru Office 2010 Software Plus Professional și suport 24/7 prin telefon [5].
Odată cu lansarea Office 2013, în februarie 2013, componentele de server au fost actualizate la versiunile de 2013, iar Microsoft a extins serviciile pentru Office 365 cu noi pachete, cum ar fi Premium Small Business, Premium mijlocii și ProPlus. De asemenea, a introdus un nou pachet: Office 365 Home Premium, destinat utilizatorilor care lucrează de acasă. Noul pachet oferă acces la Office 2013 pe un numar de până la cinci calculatoare, împreună cu stocare pe SkyDrive și 60 de minute de apeluri Skype lunar. Pachetul este destinat consumatorilor “mainstream”, mai ales cei care doresc să instaleze Office pe mai multe computere. De asemenea, Microsoft a inceput să ofere abonamente Office 365 prepaid prin intermediul unor puncte [5].
La 19 martie 2013, Microsoft a detaliat planurile sale de a oferi integrare cu retele sociale, platforma Yammer (dobândita în 2012) pentru Office 365: cum ar fi capacitatea de a folosi un singur sign-on între cele două servicii, feed-uri împărtășite și agregare documente și capacitatea de a înlocui în totalitate News Feed SharePoint și funcționalitatea socială cu Yammer. Aceste caracteristici sunt așteptate să fie lansate în cursul acestui an [5].
Caracteristici
Câteva lucruri despre Office 365, care este unul dintre serviciile Microsoft cloud:
Microsoft, servicii cloud – Office 365 este cloud-based și se integrează bine cu SkyDrive pentru a salva toate documentele on-line. Se pot salva documentele ca o copie locală pe hard disk [6].
Sunt incluse programele: Access, Word, Excel, PowerPoint, OneNote, Publisher, Outlook și InfoPath. Toate aplicațiile sunt incluse în abonament [6].
Ofera 25GB de spațiu pe SkyDrive și Office 365, dar vă puteți aștepta la mai mult spațiu de stocare liber decat este scris pe abonament [6].
Există o opțiune de a utiliza minute Office gratuit, atunci când aplelezi numere internaționale și câteva minute gratuite la numerele de telefonie fixă în funcție de tipul de abonament [6].
Elevii pot obține gratuit acces în Office 365 (pentru anumite regiuni), sau la un preț redus [6].
Office 365 funcționează pentru dispozitivele cu ecran tactil, precum tablete, smartphone-uri pe care rulează Windows 8 [6].
Office 365 funcționează bine cu rețea de mare viteză sau conexiune de bandă largă. Funcționează bine chiar și pentru rețelele cu viteza mica, dar transferul pe SkyDrive poate să înregistreze perioade mai mari de timp [6].
Se integrează bine cu PC, Mac și alte dispozitive mobile [6].
Servicii cloud
Prin funcționalitatea SkyDrive SharePoint Pro (oficial cunoscut sub numele MySites SharePoint și separat de serviciul SkyDrive orientat spre consumator), fiecare utilizator primește, de asemenea, 7 GB de stocare online. Sunt prevăzute și actualizări pentru software-ul lor. La lansare, au fost utilizate versiunile 2010 ale fiecărei componente din pachet și-au fost actualizate automat la versiunile de 2013 în februarie 2013. În loc de software-ul Microsoft enterprise, pachetul Home Premium pentru Office 365 include 20 GB de spațiu de stocare suplimentar pentru SkyDrive, împreună cu 60 de minute de apeluri telefonice pe lună pe Skype [5].
Aplicații Office
Unele pachete pentru Office 365 includ, de asemenea, accesul la versiunile curente ale aplicațiilor desktop Office, atât pentru Windows cât și pentru OS X pentru perioadă de subscriere. Office 2013 pe Windows, este instalat cu ajutorul unui sistem de "click-to-Run", care permite utilizatorilor să înceapă utilizarea aplicațiilor aproape instantaneu în timp ce fișierele sunt transmise în fundal. Actualizările sunt instalate automat, acoperind atât actualizări de securitate cât și versiuni noi de Office. O caracteristică cunoscută sub numele de "Office on Demand" este de asemenea disponibila, care permite utilizatorilor să foloseasca temporar o aplicație Office 2013 de pe orice calculator compatibil, fără a fi nevoie să-l instaleze [5].
Securitate
În decembrie 2011, Microsoft a anunțat ca platforma Office 365 este acum compatibila cu standardele de securitate ISO / IEC 27001, Directiva Uniunii Europene pentru Protecția Datelor (prin semnarea de clauze model), Asigurari de Sanatate portabilitate și responsabilitate Act pentru medii de ingrijire a sanatatii în Statele Unite ale Americii. În același timp, Microsoft a lansat, de asemenea, un nou portal "Trust Center", care conține informații suplimentare cu privire la politicile de confidențialitate și practicile de securitate pentru servicii. În luna mai 2012, Microsoft a anunțat ca Office 365 este acum compatibil cu Federal Information Security Management Act: respectarea legii ar permite acum ca Office 365 să fie utilizat de către agențiile guvernamentale din SUA [5].
Ediții
Office 365 este disponibil în diferite pachete de abonament destinate diferitelor segmente de piață și care conțin servicii și caracteristici diferite:
Office 365 Home Premium: Destinat consumatorilor mainstream și familiilor; include accesul la cele mai multe aplicații Office la domiciliu / uz non-comercial (cu excepția InfoPath și Lync), care poate fi folosit de maxim cinci dispozitive, 20 GB de spațiu de stocare suplimentar SkyDrive și 60 de minute de Skype pentru apeluri internaționale pe lună [5].
Office 365 University: o versiune speciala, redusa de Home Premium destinata utilizatoriilor din instituțiile post-secundare. Este similar cu Home Premium, cu excepția faptului ca este cumpărat pe patru ani cu o anumita reducere și utilizata numai pentru două dispozitive de un utilizator [5].
Office 365 Small Business: Oferă acces numai pentru serviciile: Exchange, SharePoint și Lync [5].
Office 365 Small Business Premium: vizeaza companiile cu 1-10 angajați și experiență limitata IT. Oferă acces la aplicațiile Office de până la cinci dispozitive pentru fiecare utilizator, plus serviciile: Exchange, SharePoint, Lync [5].
Office 365 ProPlus: oferă acces la aplicațiile Office 2013 Professional Plus de până la 25 de utilizatori fiecare putând să folosească până la cinci dispozitive [5].
Office 365 Midsize Business: dedicat întreprinderilor cu 10-250 de angajați, oferă acces la aplicațiile Office 2013 de la ProPlus, plus serviciile: Exchange, SharePoint, Lync [5].
Office 365 Enterprise: destinate utilizării în medii enterprise, oferă acces la toate aplicațiile Office, Exchange, SharePoint, Lync și sprijin [5].
Sharepoint
Generalitați
Microsoft SharePoint este o platformă de aplicații web dezvoltată de Microsoft aparuta în 2001 [7].
SharePoint cuprinde un set multifuncțional de tehnologii Web susținute de o infrastructură tehnică comună. În mod implicit, SharePoint are interfata asemanatoare cu Microsoft Office și este strâns integrat cu suita Office. Instrumentele de web sunt concepute pentru a fi folosite de către utilizatorii non-tehnici. SharePoint pot fi folosit pentru a oferi portaluri intranet, gestionare de documente și fișiere, colaborare, rețele sociale, extranet, site-uri web, căutare în întreprindere și business intelligence. Deci, ea are de integrare de sistem, procesul de integrare, fluxul de lucru și capabilități de automatizare [7].
Software-ul Enterprise Application (de exemplu, ERP sau pachete CRM) oferă de multe ori capacitatea de integrare SharePoint dar și SharePoint incorporează o stiva completă de dezvoltare bazata pe tehnologii web și API-uri bazate pe standarde. În ceea ce privește platforma de aplicații, SharePoint asigură conducerea centrală, gestionarea și securitatea pentru punerea în aplicare a cerințelor lunei aplicații [7].
În 2008, Grupul Gartner pune SharePoint în cadranul "liderilor" în trei dincre cadranele din Magic Quadrants (pentru căutare, portaluri și Enterprise Content Management) [6. Între 2006-2011, Microsoft a vandut peste 36.5 milioane de licențe pentru utilizatori. Microsoft are două versiuni ale SharePoint-ului disponibile gratuit, dar de asemenea sunt vandute și edițiile premium cu funcționalitate suplimentară și oferă o ediție cu servicii cloud, ca parte a platformei de Office 365 ( în BPOS anterior) [7].
Organizațiile utilizează SharePoint pentru a crea site-uri web. Îl puteți utiliza ca pe un loc sigur pentru a stoca, a organiza, a partaja și a accesa informațiile de pe aproape orice dispozitiv. Nu vă trebuie decât un browser web, cum ar fi Internet Explorer, Chrome sau Firefox [8].
„SharePoint” se poate referi la unul sau mai multe dintre produsele sau tehnologiile Microsoft SharePoint, cum ar fi:
SharePoint Online: Un serviciu în cloud, găzduit de Microsoft, pentru firme de toate dimensiunile. În loc să instaleze și să implementeze local SharePoint Server, acum orice firmă se poate abona, pur și simplu, la un plan Office 365 sau la serviciul SharePoint Online individual și angajații acesteia pot crea site-uri pentru a partaja documente și informații cu colegii, partenerii și clienții [8].
SharePoint Foundation: Este tehnologia de bază pentru toate site-urile SharePoint. SharePoint Foundation este disponibil pentru implementare locală gratuită, în versiunile anterioare se numea Windows SharePoint Services. Puteți să utilizați SharePoint Foundation pentru a crea rapid multe tipuri de site-uri în care puteți colabora la pagini web, documente, liste, calendare și date [8].
SharePoint Server: Organizațiile pot implementa și gestiona SharePoint Server local. Acestă include toate caracteristicile SharePoint Foundation, plus caracteristici și capacități suplimentare, cum ar fi Gestionare de conținut la nivel de întreprindere, business intelligence, căutare la nivel de întreprindere, site-uri personale și flux de știri [8].
SharePoint Designer: Un program gratuit destinat proiectării, construirii și particularizării site-urilor web care rulează în SharePoint Foundation și SharePoint Server. Cu SharePoint Designer, puteți să creați pagini web bogate în date, să construiți soluții puternice care permit fluxuri de lucru și să proiectați aspectul și stilul site-ului dvs. Gama de site-uri pe care le creați se poate extinde de la site-uri mici de echipă pentru gestionarea proiectelor, până la soluții de portal pe bază de tablouri de bord, pentru întreprinderi mari [8].
SharePoint Workspace: Un program desktop pe care îl utilizați pentru a trece offline conținutul de site SharePoint și a colabora la conținut împreună cu alte persoane, în timp ce nu sunteți deconectat de la rețea. În timp ce dumneavostra și alți membri din echipă sunteți offline, puteți efectua modificări în conținutul SharePoint care se vor sincroniza ulterior cu site-ul SharePoint. În SharePoint 2013, SharePoint Workspace a fost înlocuit cu sincronizarea folderelor SkyDrive Pro [8].
Sincronizarea folderelor SkyDrive Pro: Un program desktop pe care îl puteți utiliza pentru a sincroniza o versiune offline a unui site de echipă sau o bibliotecă SkyDrive Pro cu un folder de pe computer [8].
Sharepoint 2013
Ce aduce nou Sharepoint 2013?
SharePoint 2013 introduce Cloud App Model care permite crearea de aplicații App. Apps pentru SharePoint sunt piese de sine stătătoare, iar funcționalitatea lor extinde capabilitățile unui site SharePoint. O aplicație App poate include componente: cum ar fi liste SharePoint, fluxuri de lucru și pagini web, dar se pot crea aplicații care folosesc de la distanță o aplicație web și date de la distanță în SharePoint. O aplicație App are sau nu puține dependențe de orice alt software de pe dispozitiv sau platforma pe care este instalat, altele decât cele construite în platforma. Această caracteristică permite aplicațiilor App să fie instalate simplu și dezinstalate la fel de simplu. Aplicațiile Apps nu au cod personalizat care ruleaza pe serverul SharePoint. În schimb, toată logica personalizată poate fi „urcata” pe cloud și „coborâta” pe calculatoarele client. În plus, SharePoint 2013 introduce modelul de livrare inovatoare pentru aplicații App în SharePoint, care includ componentele: Office Store și App catalog [9].
Modelul de programare familiar folosind standardele web
In SharePoint 2013 este usor pentru orice dezvoltator web, inclusiv pentru cei care nu lucrează în platforma Microsoft, să creeze aplicații SharePoint. Ceea ce face acest lucru posibil este faptul că SharePoint 2013 se bazează pe standardele web comune, cum ar fi HTML, CSS și JavaScript. Mai mult, implementarea se bazează pe protocoalele stabilite, cum ar fi OData și OAuth [9].
Instrumente de dezvoltare
Versiunea curentă reflectă progrese în optimizarea instrumentelor de dezvoltare existente, cum ar fi Visual Studio și SharePoint Designer. În plus a fost dezvoltat un nou instrument bazat pe web "Napa" (unelte de Dezvoltare pentru Office 365) pentru dezvoltarea de aplicații App. Noul sistem unificat de proiect în Visual Studio permite dezvoltarea de aplicații SharePoint pentru aplicații Office, aplicații pentru SharePoint care includ aplicații pentru Office, sau aplicații Office sunt găzduite de către SharePoint. În plus pentru template-urile de proiect din SharePoint din versiunile anterioare, Visual Studio 2012 include acum un nou șablon de proiect App în Apps folder numit Apps pentru SharePoint 2013. Mai multe proprietați noi au fost adăugate la fereastra Proprietați și pagini Proprietăți pentru a sprijini App pentru proiectele SharePoint. Alte îmbunătățiri includ suport complet pentru dezvoltarea de aplicațiilor App Cloud Model, inclusiv OData și suport OAuth și suport complet pentru dezvoltarea de flux de lucru Client Manager platforma 1.0 [9].
Imbunătățiri platforma Core
Pe o scară mai largă, SharePoint 2013 a fost îmbunătățit și extins pentru a sprijini noua arhitectură cloud-based și noul cadru de dezvoltare app-driven. Din API-urile SharePoint la cel mai mic nivel de conectivitate la integrarea social media, SharePoint 2013 este proiectat și executat pentru a sprijini o experiență bogată de dezvoltare a aplicațiilor. În plus față de utilizarea de Representational State Transfer (REST) obiective pentru servicii Web, există un API nou atât pentru dezvoltare server cât și pentru dezvoltare client. Receptoare evenimente de la distanță și acum sprijinit pentru randare pe partea de client [9].
Mobilitate
Cu SharePoint 2013, se pot combina aplicații Windows Phone 7 cu servicii și aplicații SharePoint, sau cu serviciile SharePoint de la distanță și aplicațiile care ruleaza în cloud, pentru a crea aplicații care extind funcționalitatea dincolo de aplicațiile desktop tradiționale și într-un mediu cu adevărat portabil și mult mai accesibil. Caracteristicile noi de mobilitate din SharePoint 2013 sunt construite pe instrumente și tehnologii Microsoft existente, precum SharePoint, Windows Phone 7, Visual Studio și Microsoft Silverlight. Se pot crea aplicații mobile SharePoint pentru Windows Phone folosind noua aplicație SharePoint de telefon în Visual Studio, care permite crearea de aplicații mobile pe bază de liste. Se pot integra noile caracteristici din SharePoint 2013, cum ar fi geolocalizarea și notificările "push" din SharePoint Server în aplicații mobile [9].
Sociale și de colaborare
Caracteristicile sociale și de colaborare noi și îmbunătățite, facilitează comunicarea pentru utilizatori.
Social Feed-ul site-ului a fost imbunătățit și îi ajută pe utilizatori să fie la curent cu ce se întâmplă cu persoanele și conținutul pe care il urmaresc. Noua caracteristica Community Site permite utilizatorilor să găsească și să împărtășească cu ușurință informații și să gasească persoane care au interese similare [9].
Funcția de căutare
SharePoint 2013 include mai multe îmbunătățiri printre care procesarea de conținut personalizat cu serviciul Content Enrichment și noul cadru pentru prezentarea tipurilor de rezultate de căutare [9].
Fluxuri de lucru
Client Manager 1.0 este o infrastructură pentru flux de lucru reproiectata, care este construită pe Windows Workflow Foundation 4 și aduce mai multă flexibilitate pentru dezvoltatorul de flux de lucru în SharePoint 2013. Un mediu de creație complet declarativ permite dezvoltatorilor să utilizeze SharePoint Designer 2013 pentru a crea fluxuri de lucru și un nou set de Visual Studio 2012 template-uri, care permite dezvoltatorilor să creeze acțiuni particularizate. Probabil cel mai important este Workflow Client Manager 1.0 care este complet integrat pentru aplicațiile Apps în SharePoint. În plus, fluxurile de lucru care se executa în cloud, nu în SharePoint, oferă o mare flexibilitate [9].
Enterprise Content Management
În SharePoint 2013, există acum posibilitatea utilizarii Client NET, Silverlight, Windows Phone și JavaScript API-uri. În plus a fost introdus un nou set de API-uri din .Net pentru a personaliza experiențele și comportamentul Enterprise Content Management (ECM) [9].
Business Connectivity Services (BCS)
Permite SharePoint-ului să acceseze sistemele de date externe cum ar fi SAP, ERP, CRM, serviciile WCF și OData. BCS în SharePoint 2013 a fost îmbunătățit în mai multe feluri, inclusiv conectivitatea OData, evenimente externe, date externe în aplicații, sortare și filtrare, suport pentru REST și altele [9].
Servicii pentru aplicații
SharePoint Server 2013 include mai multe servicii pentru lucrul cu datele din site-urile SharePoint. Nou pentru SharePoint este Machine Translation Service, care traduce site-uri, documente și fluxuri cu suport multilingv. SharePoint Server 2013 include servicii de acces și prin urmare, un nou model de acces la date. Pentru conversia fișierelor în alte formate și fluxuri, SharePoint Server 2013 are Word Automation Services și PowerPoint Automation Services (o caracteristică nouă pentru SharePoint). Deci, SharePoint furnizează instrumente de analiză a datelor, cum ar fi PerformancePoint Services și Visio Services, care activează business intelligence și alte caracteristici noi în Excel Services [9].
SharePoint Online
SharePoint Online (SPO) reprezinta evoluția unui portal și aspectelor de colaborare ale Business Productivity Online Services Microsoft, care include cele mai multe dintre capacitățile oferite de cea mai recentă versiune de SharePoint. O mare parte din SPO va fi imediat familiar pentru oricine are ceva experienta cu SharePoint 2010 [9].
În dezvoltarea acestei aplicații am folosit SharePoint Online (SPO), din acest motiv, voi vorbi în detaliu despre această platformă [1].
La un nivel ridicat, SPO este SharePoint, cu excepția următoarelor:
➤ Toate aplicațiile care conțin cod server-side rulează în aplicații Sandbox [1].
➤ Central Administration (Administrare centrală) locală nu este disponibilă. Mai degrabă, în această versiune multitenant, aveți acces la "Administrare Tenant." [1].
➤ companii multiple coexistă în același farm din SharePoint [1].
➤ Fiecarui dezvoltator care folosește SharePoint Online i se acordă una sau mai multe colecții de site-uri, în funcție de planul achiziționat [1].
➤ Interacțiunea cu SPO, inclusiv toate personalizarile administrative se realizează prin intermediul browser-ului sau instrumentului: SharePoint Designer [1].
SharePoint SharePoint Online versus local
Privind la SPO, primul beneficiu este lipsa efortului necesar pentru a configura servererul, instala aplicația, cererea de patch-uri și toate celelalte detalii necesare pentru a construi un mediu SharePoint de la zero [1].
Caracteristicile și funcționalitatea care este disponibila în SharePoint local (on-premises) dar nu e disponibila în SharePoint Online:
➤ Securitate Claims-based [1];
➤ Timer job-uri personalizate [1];
➤ Cautare rapida [1];
➤ Serviciul Secure Store [1];
➤ Web Analytics [1];
➤ PowerPivot pentru SharePoint [1];
➤ Servicii PerformancePoint [1];
➤ Imbunătățiri specifice de căutare, sociale, business intelligence, securitate [1].
JavaScript
JavaScript este limbajul de programare folosit pentru dezvoltarea aplicațiilor Web. Marea majoritate a site-uri moderne folosesc JavaScript. Toate browserele web moderne, de pe desktop-uri, console de jocuri, tablete și telefoane inteligente, includ interpreți JavaScript, făcândul limbajul de programare cel mai omniprezente în istorie. JavaScript este parte din triada de tehnologii pe care toți dezvoltatorii web trebuie să o învețe: HTML pentru a preciza conținutul paginilor web, CSS pentru a specifica prezentarea de pagini web și JavaScript pentru a specifica comportamentul de pagini web. JavaScript este un limbaj de programare de nivel înalt, dinamic, netipizat interpretat ca limbaj de programare care este bine-potrivit pentru stiluri de programare orientate-obiect și funcționale [10].
JavaScript este o sintaxă ce provine de la Java, funcțiile sale fiind derivate din Schema, iar moștenirea ei prototip din Self. Numele de "JavaScript" este de fapt înșelător. Deși cu asemănare superficială sintactica, JavaScript este complet diferit de limbajuli de programare Java. Dezvoltarea JavaScript a dus la depășirea limbajului Scripting pentru a deveni un limbaj de uz general solid și eficient. Cea mai recentă versiune a limbajului definește noi caracteristici pentru dezvoltarea de software pe scară largă [10].
Istoric
JavaScript a fost creat în 1995 de Brendan Eich (Netscape). Numele initial al limbajului a fost LiveScript și a fost creat cu scopul de a oferi un limbaj simplu de scripting pentru a aduce modificãri dinamice paginilor web html pe partea de client (de unde și „Live” ). Deoarece înainte de lansarea limbajului, Java era la apogeul popularitãtii, s-a decis schimbarea numelui din LiveScript în JavaScript din motive comerciale. Totuși, Java și JavaScript au puține lucruri în comun [10].
Faptul cã browserul este responsabil de interpretarea codului JavaScript a adus unele dezavantaje. În primii ani utilizarea JavaScript era foarte dificilã, datoritã lipsei unui standard, datoritã evolutiei rapide în lumea browserelor și mai ales datoritã evolutiei pe drumurile divergente a principalilor lor producãtori (Microsoft, Netscape și Opera). Codul scris în JavaScript pentru Internet Explorer, Netscapes și Opera nu producea decât rareori același rezultat. Existau deseori diferente mari și între rezultatele produse de versiuni succesive ale aceluiași browser. Din aceste motive, majoritatea script-urilor trebuiau scrise în mai multe variante similare ceea ce era deosebit de neplãcut pentru dezvoltatori. De asemenea, a durat mult timp pânã au apãrut unele medii de dezvoltare și depanare avansate. Astfel a durat destul de mult pânã când tehnologia a ajuns la maturitate și a devenit destul de avansatã pentru a fi folositã pe scarã largã [10].
Odatã cu apariția Web 2.0 și AJAX, JavaScript a crescut în popularitate și astãzi, o gamã largã de aplicaþii web precum: Google Mail, Yahoo Mail, folosesc aceastã tehnologie [10].
Scripturile se executã de cãtre browser și sunt incluse deci în pagina HTML ce se afiseazã pe calculatorul clientului [10].
Avantaje și dezavantaje
Avantajele folosirii Javascript în paginile unui sit web sunt: un plus de interactivitate cu utilizatorul, posibilitatea de a actualiza informatiile de pe paginã în timp real fãrã a o reîncãrca (folosind Ajax).
Printre dezavantajele folosirii Javascript s-ar putea numãra: posibilã comportare neasteptatã în unele browsere, probleme cu motoarele de cãutare care nu indexeazã întotdeauna paginile generate folosind Ajax [10].
În general este bine sã se foloseascã Javascript având grijã:
• sã se testeze paginile în cele mai importante browsere de pe piatã și sã fie informat utilizatorul în cazul în care aplicația dezvoltatã nu este compatibilã cu browserul lor[10]
• sã nu se actualizeze folosind Javascript și Ajax zonele de continut ale site-ului ce se doresc a fi indexate de motoarele de cãutare[10]
Versiuni
JavaScript a fost creat de Netscape, dar de la inceputul dezvoltarii aplicațiilor Web din punct de vedere tehnic, "Java-Script" a fost licențiat de Sun Microsystems (numit acum Oracle), folosit pentru a descrie implementarea aplicațiilor Netscape (în prezent Mozilla). Netscape a prezentat limbajul pentru standardizarea ECMA- European Computer Manufacture și din cauza unor probleme de marcă, versiunea standard a limbajului a fost blocata cu numele ciudat "ECMAScript." Din aceleași motive, versiunea Microsoft a limbajului este în mod oficial cunoscută sub numele de "JScript." [10].
În practică, aproape toată lumea numește limbajul JavaScript. În ultimul deceniu, toate browserele web au implementat versiunea 3 a standardului ECMAScript și nu a fost nevoie de versionare: limbajul standard, a fost stabil și limbajul de implementare, pentru browsere este în cea mai mare parte, interoperabil [10].
Recent, o versiune noua a limbajului a fost definita ca ECMAScript versiunea 5 și în acest moment, browserele au început să-l pună în aplicare. Când vorbim de limbaj în sine, doar ECMAScript versiunile 3 și 5 sunt relevante (ECMAScript 4 a fost în curs de dezvoltare ani de zile, dar s-a dovedit a fi prea ambițios și nu a fost niciodată lansat). Uneori, cu toate acestea, apar numere de versiuni JavaScript, cum ar fi: JavaScript 1.5 sau JavaScript 1.8. Acestea sunt numerele atribuite browser-ului Mozilla: versiunea 1.5 care în principiu contine ECMAScript 3. Există, de asemenea, versiuni de JavaScript atasate la anumite "motoare de căutare" [10].
De exemplu Google folosește apelurile JavaScript cu interpret V8 și versiunea curentă a motorului V8 este 3.0. Pentru a fi util, fiecare limbaj trebuie să aibă o bibliotecă sau platformă standard sau API cu funcții pentru efectuarea de lucruri cum ar fi de intrare și ieșire din bază. Nucleul limbajului de activare a JavaScrip-tului definește un API minim pentru lucrul cu text, tablouri, date și expresii regulate, dar nu include nici o intrare sau funcționalitate de ieșire [10].
AJAX
AJAX – Asynchronous Javascript and XML este o tehnicã de programare web care permite efectuarea unor cereri http cãtre serverul web, prin intermediul cãrora se poate actualiza o paginã web fãrã a se efectua reîncãrcarea să completã [10].
AJAX folosește o combinație de :
CSS, pentru stilul de afsare al elementelor [10].
Document Object Model accesat prin intermediului unui limbaj de scripting client-side precum JavaScript pentru o interacțiune și afișare dinamicã a paginilor si informațiilor [10].
Obiectul XMLHttpRequest pentru schimbul asincron de date cu serverul web[10].
XML ca format de transfer al datelor trimise în comunicația client-server (nu este însã unicul format suportat) [10].
Cum funcționează?
La anumite evenimente din paginã sau la un anumit interval de timp, se apeleazã un obiect de tip XMLHttpRequest care va cere anumite date de la server iar la primirea acestora, le va trimite pentru a fi afisate în paginã fãrã ca această sã se reîncarce, doar prin modificarea unor elemente ale paginii. Formatul în care sunt primite și trimise datele poate fi XML, JSON sau chiar text [10].
Posibilitatea de a reîncãrca datele din paginã oferã utilizatorului o experientã mult îmbunãtãțitã prin minimizarea timpului de așteptare [10].
jQuery
jQuery este o platformă de dezvoltare JavaScript, concepută pentru a ușura și îmbunătăți procese precum traversarea arborelui DOM în HTML, managementul inter-browser al evenimentelor, animații și cereri tip AJAX. jQuery a fost gândit să fie cât mai mic posibil, disponibil în toate versiunile de browsere importante existente și să respecte filosofia "Unobtrusive JavaScript". Biblioteca a fost lansată în 2006 de către John Resig [11].
Caracteristici
jQuery se poate folosi pentru a rezolva următoarele probleme specifice programării web:
selecții de elemente în arborele DOM folosind propriul motor de selecții open source Sizzle, un proiect născut din jQuery [11].
parcurgerea și modificarea arborelui DOM (incluzând suport pentru selectori CSS 3 și XPath) [11].
înregistrarea și modificarea evenimentelor din browser [11].
manipularea elementelor CSS [11].
efecte și animații [11].
cereri tip AJAX [11].
utilități-versiunea browser-ului, funcția each [11].
Extensii
Plugin-urile sau extensiile sunt unele dintre cele mai interesante aspecte ale jQuery. Arhitectură sa permite programatorilor să dezvolte subaplicații bazate pe biblioteca principală care extind funcțiile de bază jQuery cu funcții specifice plugin-ului. În acest fel biblioteca principală poate ocupa foarte puțin spațiu, iar extensiile necesare în anumite pagini web pot fi încarcate la cerere, doar când este nevoie de ele. Există un set de extensii principal numit jQuery UI( jQuery User Interface) [3]. jQuery UI ofera un set de extensii pentru interactivitate de bază, efecte mai complexe decât cele din biblioteca de bază și teme de culori. Avantajul jQuery UI față de alte extensii este ca dezvoltarea și testarea acestor componente se face în paralel cu dezvoltarea bibliotecii principale, minimizând riscul de incomptibilitate [11].
Orice programator poate crea o extensie și jQuery oferă publicare în catalogul de pe pagina proiectului în diversele categorii disponibile [11].
Capitolul 3
SCRUM
In dezvoltarea acestei aplicații, am folosit o metodologie algila de dezvoltare, metodologia SRUM. În continuare voi prezenta mai multe detalii despre SCRUM.
Cuvântul Scrum înseamna: un cadru în care oamenii își pot adresa probleme complexe de adaptare, livrând în același timp, în mod productiv și creativ produse de cea mai mare valoare posibilă. Scrum este:
Ușor [13].
Simplu de înțeles [13].
Extrem de dificil de stapânit [13].
Scrum este un cadru al proceselor utilizate pentru a gestiona dezvoltarea de produse complexe încă de la începutul anilor 1990. Scrum nu este un proces sau o tehnică de construire a produselor ci mai degrabă este un cadru în care poți folosi diferite procese și tehnici. Scrum clarifică eficacitatea relativă a managementului produsului și practicile de dezvoltare astfel încât se pot face îmbunătățiri [13].
Pași
Cadrul Scrum
Constă în Echipele Scrum și în rolurile, evenimentele, artefactele și regulile asociate acestora. Fiecare componentă din cadru servește un anumit scop și este esențială în succesul și utilizarea Scrum-ului. Strategiile specifice de utilizare a cadrului Scrum variază și vor fi descrise în altă parte. Regulile Scrum leagă împreună evenimentele, rolurile și artefactele, guvernând relațiile și interacțiunea dintre ele. Regulile Scrum sunt descrise în interiorul acestui document [13].
Teoria Scrum
Scrum este bazat pe o teorie empirică de control a proceselor sau empirism. Empirismul afirmă faptul ca sursa cunoștințelor este experiența și luarea deciziilor se bazează pe ceea ce este știut. Scrum folosește o abordare iterativă, incrementală cu scopul de a optimiza predictibilitatea și de a controla riscul. Trei piloni susțin orice implementare a controlului procesului empiric: transparența, inspecția și adaptarea [13].
Transparența
Aspecte semnificative ale procesului trebuie să fie vizibile celor responsabili de rezultate [13].
Transparența necesită ca aceste aspecte să fie definite de un standard comun astfel încât observatorii să împărtășească puncte de vedere comune asupra a ceea ce văd [13].
De exemplu:
Un limbaj comun referitor la proces trebuie să fie împărtășit de către toți participanții [13];
Definiția comună a statusului “Finalizat” trebuie împărtășită de către cei care efectuează munca și cei care acceptă munca rezultată [13].
Inspecția
Utilizatorii Scrum trebuie să inspecteze în mod firesc progresul făcut către îndeplinirea obiectivului, astfel încât să detecteze abaterile nedorite. Inspecția lor nu trebuie să fie atât de frecventă încât să afecteze modul de lucru. Inspecțiile sunt cele mai benefice atunci când sunt efectuate în mod sârguincios la locul de muncă [13].
Adaptarea
Dacă un inspector stabilește ca unul sau mai multe aspecte ale procesului deviază în afara unor limite acceptabile și ca produsul rezultat va fi inacceptabil, procesul sau materialul procesat trebuie să fie ajustat [13].
Scrum recomandă patru oportunități formale pentru inspecție și adaptare, așa cum este descris în secțiunea Evenimentele Scrum ale acestui document [13].
Ședința de Planificare a Sprint-ului [13].
Ședința Scrum Zilnică [13].
Revizuirea Sprint-ului [13].
Retrospectiva Sprint-ului [13].
Echipa Scrum
Este alcătuită din Product Owner, echipă de Dezvoltare și Scrum Master. Echipa Scrum se auto-organizează și este inter-funcțională. Echipele auto-organizate mai degrabă aleg cât de bine să-și facă munca decât să fie direcționați de alții din afara echipei. Echipele inter-funcționale au toate competențele necesare pentru a-și îndeplini munca fară a depinde de alții care nu fac parte din echipă. Echipa model în Scrum este proiectată astfel încât să optimizeze flexibilitatea, creativitatea și productivitatea [13].
Echipa Scrum livrează produsele în mod iterativ și incremental, maximizând oportunitățile de feedback. Livrările incrementale de produse cu statusul “Finalizat” asigură ca o versiune potențial folositoare a produsului în lucru să fie mereu disponibilă [13].
Product Owner
Este responsabil de maximizarea valorii produsului și a muncii Echipei de Dezvoltare. Modul în care acest lucru este făcut poate varia pe scară largă în funcție de organizație, Echipa Scrum sau indivizi. Product Owner-ul este singura persoană responsabilă de Product Backlog. Managementul Product Backlog-ului include:
Exprimarea clară a elementelor din Product Backlog [13];
Ordonarea elementelor din Product Backlog pentru a realiza cel mai bine obiectivele și misiunile [13];
Garantarea valorii muncii produse de către Echipa de Dezvoltare [13];
Garantarea faptului că Product Backlog-ul este vizibil, transparent, clar pentru toți și ca arată la ce va lucra Echipa Scrum în continuare [13];
Garantarea faptului ca Echipa de Dezvoltare înțelege toate elementele din Product Backlog până la nivelul necesar [13].
Product Owner-ul poate să facă activitățile de mai sus sau poate delega o Echipă de Dezvoltare să facă acest lucru. Totuși, Product Owner-ul rămâne responsabil. Product Owner-ul este o persoană, nu un comitet. Product Owner-ul poate reprezenta interesele unui comitet în Product Backlog, dar cei care vor să schimbe prioritatea elementelor din backlog trebuie să îl convingă pe Product Owner [13].
Pentru ca Product Owner-ul să reușească, întreaga organizație trebuie să-i respecte deciziile. Deciziile Product Owner-ului sunt vizibile în conținutul și ordinea elementelor din Product Backlog. Nimănui nu îi este permis să îi spună Echipei de Dezvoltare să lucreze pe baza unui alt set de cerințe, iar Echipei de Dezvoltare nu îi este permis să acționeze la ceea ce spune oricine altcineva [13].
Echipa de Dezvoltare
Este construita din profesioniști care fac din activitatea de livrare un potențial Increment, lansabil pe piață, al produsului “Finalizat”, la sfârșitul fiecărui Sprint. Echipa de Dezvoltare este structurată și împuternicită de către organizație să-și organizeze și să-și gestioneze munca. Sinergia rezultată optimizează la nivel global eficiența și eficacitatea Echipei de Dezvoltare. Echipele de Dezvoltare au următoarele caracteristici:
Ele se auto-organizează. Nimeni (nici măcar Scrum Master-ul) nu spune Echipei de Dezvoltare cum să transforme elementele din Product Backlog în potențiale Incrementuri ale funcționalității ce pot fi lansate pe piață [13];
Echipele de Dezvoltare sunt inter-funcționale și au toate competențele necesare ca echipă pentru a crea un Increment al produsului [13];
Scrum nu recunoaște nici un titlu pentru membrii Echipei de Dezvoltare altul decât Dezvoltator, indiferent de munca care a fost efectuată de persoana respectivă; nu există excepții de la această regulă [13];
Diferiți membri ai Echipei de Dezvoltare pot avea competențe specializate și zone de focalizare, dar responsabilitatea aparține Echipei de Dezvoltare ca un întreg [13];
Echipa de Dezvoltare nu conține sub-echipe dedicate unui domeniu particular cum ar fi testarea sau analiza afacerii [13].
Dimensiunea Echipei de Dezvoltare
Echipa de Dezvoltare optimă este destul de mică încât să rămână agilă și destul de mare încât să execute o muncă semnificativă. Un număr mai mic de trei membri în Echipa de Dezvoltare scade interacțiunea și rezultă în câștiguri mici de productivitate. Echipele de Dezvoltare mai mici pot întâlni constrângeri legate de competențe pe parcursul unui Sprint, cauzând ca Echipa de Dezvoltare să fie incapabilă să livreze un potențial Increment lansabil pe piață. Când sunt mai mult de nouă membri este necesară prea multă coordonare. Echipele de Dezvoltare mari generează prea multă complexitate de gestionat pentru un proces empiric. Rolurile de Product Owner și Scrum Master nu sunt luate în calcul decât dacă ei execută și lucrări din Product Backlog [13].
Scrum Master
Este responsabil ca Scrum să fie înțeles și adoptat. Scrum Master-ul face acest lucru prin asigurarea că Echipa Scrum aderă la teoria, practicile și rolurile Scrum. Scrum Master-ul este un servitor-conducător pentru Echipa Scrum [13].
Acesta îi ajută pe cei din afara Echipei Scrum să înțeleagă care din interacțiunile lor cu Echipa Scrum sunt folositoare și care nu. Scrum Master-ul ajută pe toată lumea să schimbe aceste interacțiuni astfel încât să maximizeze valoarea creată de Echipa Scrum [13].
Serviciile Scrum Master-ului pentru Product Owner
Scrum Master-ul îl ajută pe Product Owner în mai multe moduri, incluzând:
Găsirea tehnicilor de gestionare eficace a Product Backlog-ului [13];
Comunicarea clară a viziunii, obiectivelor și a elementelor din Product Backlog către Echipa de Dezvoltare [13];
Instruirea Echipei Scrum în crearea clară și concisă a elementelor din Product Backlog [13];
Înțelegerea planificării pe termen lung într-un mediu de dezvoltare empiric [13];
Înțelegerea și practicarea metodelor agile [13];
Facilitarea evenimentelor Scrum după cum este cerut sau necesar [13].
Serviciile Scrum Master-ului pentru Echipa de Dezvoltare
Scrum Master-ul ajută Echipa de Dezvoltare în mai multe moduri, incluzând:
Antrenarea Echipei de Dezvoltare să folosească auto-organizarea și inter-funcționalitatea [13];
Instruirea și direcționarea Echipei de Dezvoltare în așa fel încât să creeze produse de valoare mare [13];
Eliminarea impedimentelor din calea progresului Echipei de Dezvoltare [13];
Facilitarea evenimentelor Scrum după cum este cerut sau necesar [13];
Instruirea Echipei de Dezvoltare în mediile organizaționale unde Scrum nu a fost pe deplin adoptat sau înțeles [13].
Serviciile Scrum Master-ului pentru Organizație
Scrum Master-ul ajută organizația în mai multe moduri, incluzând:
Direcționarea și pregătirea organizației în procesul de adoptare Scrum [13];
Planificarea implementărilor Scrum în cadrul organizației [13];
Ajutarea angajaților și a celor implicați să înțeleagă precum și să adopte Scrum și dezvoltarea empirică a produselor [13];
Cauzarea schimbărilor ce duc la creșterea productivității Echipei Scrum [13];
Colaborarea cu alți Scrum Master-i pentru a crește eficacitatea aplicării Scrum-ului în cadrul organizației [13].
Evenimentele Scrum (Scrum Events)
Evenimentele prestabilite în mod regulat din Scrum sunt utilizate pentru a minimiza necesitatea unor reuniuni ocazionale. În Scrum acestea sunt evenimente limitate în timp, astfel încât fiecare are o durată maximă. Aceasta asigură o cantitate adecvată de timp dedicată planificării, fără a permite pierderi în procesul de planificare [13].
În afara Sprint-ului propriu-zis, care este un container pentru toate celelalte evenimente, fiecare eveniment în Scrum reprezintă o oportunitate formală de a inspecta și a adapta ceva. Aceste evenimente sunt concepute special pentru a permite o transparență decisivă și inspecție. Omiterea includerii oricăruia dintre aceste evenimente duce la o transparență redusă și de asemenea este o ocazie pierdută de a inspecta și a adapta [13].
Sprint-ul (The Sprint)
Inima Scrum-ului este un Sprint, cu o durată de maxim o lună, în timpul căruia este creat un Increment al produsului, cu statusul "Finalizat" ("Done"), utilizabil și potențial livrabil. Sprint-urile au durate consistente pe toată durata efortului de dezvoltare. Un Sprint nou începe imediat după aflarea concluziilor Sprint-ului anterior [13].
Sprint-urile conțin și constau din Ședința de Planificare a Sprint-ului (Sprint Planning
Meeting), Ședința Scrum Zilnică (Daily Scrums), activitatea de dezvoltare, Revizuire a Sprint-ului (Review Meeting) și Retrospectiva Sprint-ului (Sprint Retrospective) [13].
În timpul Sprint-ului:
Nu se aduc modificări care ar putea afecta obiectivul Sprint-ului [13];
Componența echipei de dezvoltare rămâne constantă [13];
Calitatea obiectivelor nu scade [13];
Posibilitățile (scope) pot fi clarificate și re-negociate între Product Owner și echipa de Dezvoltare (Development Team) pe masură ce se progresează [13].
Fiecare Sprint poate fi considerat un proiect cu un orizont de timp nu mai mare de o lună. La fel ca și proiectele, Sprint-urile sunt folosite pentru a realiza ceva. Fiecare Sprint are o definiție a ceea ce urmează să fie construit, un design și un plan flexibil, care îl vor ghida în procesul de realizare cât și în produsul rezultat [13].
Sprint-urile se limitează la o lună calendaristică. Atunci când orizontul de timp al Sprint-ului este prea lung, definirea a ceea ce este în curs de a fi construit se poate modifica și pot crește atât complexitatea cât și riscul. Sprint-urile aduc predictibilitate prin asigurarea inspecției și adaptarea a ceea ce se realizează spre un scop cel puțin în fiecare lună calendaristică. De asemenea Sprint-urile limitează riscurile de cost la cel mult o lună calendaristică [13].
Anularea unui Sprint
Un Sprint poate fi anulat înainte de expirarea duratei limitate în care se încadrează Sprint-ul respectiv. Numai Product Owner-ul are autoritatea de a anula Sprint-ul, deși el sau ea pot face acest lucru sub influența celor implicați, Echipei de Dezvoltare sau a Scrum Master-ului [13].
Un Sprint ar putea fi anulat și în cazul în care ținta Sprint-ului devine perimată. Acesta s-ar putea întâmpla în cazul în care compania își schimbă direcția sau în cazul în care condițiile de piață sau de tehnologie se schimbă. În general, un Sprint ar trebui să fie anulat în cazul în care nu mai are sens, date fiind circumstanțele. Dar anularea acestora are foarte rar sens, din cauza duratei reduse a Sprint-urilor [13].
Atunci când un Sprint este anulat, toate activitățile din Product Backlog completate și "Finalizate" ("Done") sunt verificate. Dacă o parte a lucrărilor realizate sunt potențial livrabile, de obicei Product Owner-ul le va accepta. Toate părțile incomplete din Product Backlog sunt re-evaluate și readuse în Product Backlog. Lucrările efectuate asupra lor se depreciază rapid și trebuie să fie frecvent re-evaluate [13].
Anulările Sprint-urilor consumă resurse, deoarece toată lumea trebuie să se regrupeze într-o altă Ședință de Planificare a Sprint-ului (Sprint Planning Meeting) pentru a începe un alt Sprint. Anulările Sprint-urilor sunt adesea traumatizante pentru Echipa Scrum și sunt foarte rar întâlnite [13].
Ședința de Planificare a Sprint-ului (Sprint Planning Meeting)
Activitatea care urmează să fie efectuată în Sprint este planificată la Ședința de Planificare a Sprint-ului. Acest plan este creat de munca coroborată a întregii Echipe Scrum [13].
Ședința de Planificare a Sprint-ului este o întâlnire limitată la opt ore pentru un Sprint de o lună. Pentru Sprint-uri mai scurte, evenimentul este proporțional mai scurt. De exemplu, un Sprint de două săptămâni va avea o Ședință de Planificare a Sprint-ului de patru ore [13].
Ședința de Planificare a Sprint-ului este formată din două părți, fiecare fiind jumătate din durata întregii întâlniri. Cele două părți trebuie să răspundă la următoarele întrebări, respectiv:
Ce va fi livrat în Incrementul care rezultă din Sprint-ul viitor?
Cum va fi efectuată munca necesară pentru ca acest Increment să poată fi realizat?
Partea Întâi: Ce se va realiza în acest Sprint?
În această secțiune, Echipa de Dezvoltare (Development Team) lucrează pentru prognozarea funcționalității care va fi dezvoltată pe parcursul Sprint-ului. Product Owner-ul prezintă elementele ordonate din Product Backlog Echipei de Dezvoltare și întreaga Echipă Scrum colaborează la înțelegerea a ceea ce trebuie realizat în cadrul Sprint-ului [13].
Datele de intrare la această întâlnire sunt Product Backlog, cel mai recent Increment al produsului, capacitatea proiectată a Echipei de Dezvoltare în timpul Sprint-ului și performanțele anterioare ale Echipei de Dezvoltare. Numărul de activități (items) selectate din Product Backlog pentru Sprint este numai la latitudinea Echipei de Dezvoltare. Numai Echipa de Dezvoltare poate evalua ce poate realiza în Sprint-ul următor [13].
După ce Echipa de Dezvoltare previzionează elementele din Product Backlog pe care le va livra în Sprint, întreaga Echipă Scrum definește obiectivul Sprint-ului. Ținta Sprint-ului este un obiectiv care va fi îndeplinit în cadrul Sprint-ului prin implementarea Product Backlog-ului și care furnizează îndrumări Echipei de Dezvoltare despre motivul construirii Incrementului [13].
Partea a doua: Cum se vor realiza activitățile alese?
După selectarea a ceea ce este de făcut în cadrul Sprint-ului, Echipa de Dezvoltare decide cum va implementa pe durata Sprint-ului această funcționalitate într-un Increment al produsului având statusul “Finalizat” (“Done”). Elementele din Product Backlog selectate pentru acest Sprint, plus planul pentru livrarea lor se numește Sprint Backlog [13].
Echipa de Dezvoltare începe de obicei cu proiectarea sistemului și a activităților necesare convertirii Product Backlog-ului într-un Increment funcțional al produsului. Activitatea poate varia în funcție de dimensiuni sau efort estimat. Cu toate acestea, o activitate suficientă este planificată în cursul Planificării Sprint-ului pentru ca Echipa de Dezvoltare să previzioneze ceea ce este posibil de realizat în următorul Sprint. Activitățile planificate pentru primele zile ale Sprint-ului de către Echipa de Dezvoltare sunt descompuse în unități de o zi sau mai puțin până la sfârșitul acestei reuniuni. Echipa de Dezvoltare se auto-organizează pentru îndeplinirea activităților preluate din Backlog-ul Sprint-ului, așa cum este necesar, atât în timpul Planificării Sprint-ului cât și pe parcursul Sprint-ului. Product Owner-ul poate fi prezent în a două parte a Ședinței de Planificare a Sprint-ului (Sprint Planning Meeting) pentru a clarifica activitățile selectate din Product Backlog și pentru ajuta să se facă compromisuri. În cazul în care Echipa de Dezvoltare determină ca e prea mult sau prea puțin de lucru, se pot renegocia elementele din Sprint Backlog cu Product Owner-ul. De asemenea, Echipa de Dezvoltare poate invita alte persoane să participe, cu scopul de a oferi consultanță tehnică sau de specialitate [13].
Până la sfârșitul Planificării Sprint-ului, Echipa de Dezvoltare ar trebui să fie capabilă să explice Product Owner-ului și Scrum Master-ului cum intenționează să lucreze ca o Echipă auto-organizată pentru a îndeplini obiectivul Sprint-ului și de a crea Incrementul anticipat [13].
Obiectivul Sprint-ului
Oferă Echipei de Dezvoltare un anumit grad de flexibilitate în ceea ce privește funcționalitatea implementată în cadrul Sprint-ului. Pe măsură ce Echipa de Dezvoltare lucrează, aceasta se va ghida după acest obiectiv. În scopul de a îndeplini obiectivul Sprint -ului, aceasta implementează funcționalitatea și tehnologia. În cazul în care Echipa de Dezvoltare descoperă ca activitatea de dezvoltare se dovedește a fi altfel decât s-ar fi așteptat, atunci ea colaborează cu Product Owner-ul pentru a negocia obiectivul Sprint Backlog-ului, în cadrul Sprint -ului. Obiectivul Sprint-ului poate fi un jalon (milestone) în cadrul scopului mai mare al planului de produs [13].
Ședința Scrum Zilnică (Daily Scrum)
Ședința Scrum Zilnică este un eveniment de 15 minute pentru ca Echipa de Dezvoltare să își sincronizeze activitățile și pentru a crea un plan pentru următoarele 24 de ore. Acest lucru se face prin inspectarea activităților desfășurate de la ultima întâlnire și prognozarea activităților ce ar putea fi realizateînainte de următoarea întâlnire [13].
Ședința Scrum Zilnică se desfașoară în aceeași locație și la aceeași oră în fiecare zi pentru a reduce complexitatea. În timpul întâlnirii, fiecare membru al Echipei de Dezvoltare, detaliază:
Ce s-a realizat de la ultima întâlnire?
Ce va fi făcut până la următoarea întâlnire?
Ce obstacole sau piedici au apărut pe parcurs?
Echipa de Dezvoltare utilizează întâlnirea zilnică pentru a evalua progresul realizat spre Obiectivul Sprint-ului cât și pentru a evalua tendința progresului spre finalizarea lucrărilor din Sprint Backlog. Întâlnirea optimizează probabilitatea ca Echipa de Dezvoltare să realizeze Obiectivul Sprint-ului. Adesea, Echipa de Dezvoltare se întâlnește după această Ședință Scrum zilnică pentru a replanifica restul lucrărilor din cadrul Sprint-ului. În fiecare zi, Echipa de Dezvoltare trebuie să fie capabilă să explice Product Owner-ului și Scrum Master-ului modul în care intenționează să lucreze împreună ca o echipă auto-organizată pentru a realiza scopul propus și pentru a realiza Incrementul anticipat în perioadă care a rămas din Sprint [13].
Scrum Master-ul se asigură ca Echipa de Dezvoltare se reunește, dar această este responsabilă pentru desfașurarea Ședinței Scrum Zilnice. Scrum Master-ul instruiește Echipa de Dezvoltare să țină Ședința Scrum Zilnică în cadrul duratei de 15 minute [13].
Scrum Master-ul impune ca regula că numai membrii Echipei de Dezvoltare să participe la Ședința Scrum Zilnică. Ședința Scrum Zilnică nu este o întâlnire de reportare ci este adresată persoanelor care transformă elementele din Product Backlog într-un Increment. Ședința Scrum Zilnică îmbunătățește comunicarea, elimină alte întâlniri, identifică și îndepărtează obstacolele, evidențiază și promovează luarea rapidă a deciziilor și îmbunătățește nivelul de cunoaștere a proiectului de către Echipa de Dezvoltare. Această întâlnire cheie este una de inspecție și de adaptare [13].
Ședința de Revizuire a Sprint-ului (Sprint Review)
Această Ședință de Revizuire a Sprint-ului (Sprint Review Meeting) este ținută la sfârșitul Sprint-ului cu scopul de a se inspecta Incrementul și dacă este necesar, se adaptează Product Backlog-ul. În timpul Ședinței de Revizuire a Sprint-ului, Echipa Scrum și cei implicați colaborează cu privire la ceea ce s-a realizat în Sprint. Pornind de la această dezvoltare și de la orice altă modificare adusă Product Backlog-ului în timpul Sprint-ului, participanții conlucrează la acțiunile următoare care ar putea fi realizate. Această este o întâlnire informală, iar prezentarea Incrementului este destinată solicitării de feedback și încurajează colaborarea [13].
Aceasta este o ședință limitată la 4 ore pentru Sprint-urile de o lună. Pentru Sprint-urile mai scurte va fi alocat mai putin timp, în mod proporțional. De exemplu, Sprint-urile de două săptămâni au Ședințe de Revizuire a Sprint-ului de două ore [13].
Ședința de Revizuire a Sprint-ului cuprinde următoarele elemente:
Product Owner-ul identifică ceea ce a fost "Finalizat" și ceea ce nu a fost "Finalizat";
Echipa de Dezvoltare discută despre ceea ce a mers bine în timpul Sprint-ului, problemele de care s-a lovit și modul în care acele probleme au fost soluționate;
Echipa de Dezvoltare demonstrează lucrările care au fost "Finalizate" și răspunde la întrebări cu privire la Increment;
Product Owner-ul discută Product Backlog-ul așa cum se prezintă la momentul respectiv. El sau ea preconizează datele posibile de finalizare bazate pe progresele înregistrate până în present;
Întregul grup colaborează asupra a ceea ce urmează să facă în continuare, astfel încât această întâlnire asigură o contribuție valoroasă pentru ulterioarele Ședințe de Planificare ale Sprint-ului (Sprint Planning Meeting).
Rezultatul Ședinței de Revizuire a Sprint-ului este un Product Backlog revizuit care definește elementele probabile din cadrul acestuia pentru următorul Sprint. De asemenea, Product Backlog-ul poate fi revizuit pe ansamblu pentru a satisface noi oportunități.
Retrospectiva Sprint-ului (Sprint Retrospective)
Reprezintă o oportunitate pentru Echipa Scrum de a se auto-inspecta și de a crea un plan pentru îmbunătățiri care urmează să fie adoptate în cadrul Sprint-ului următor. Retrospectiva Sprint-ului are loc după Ședința de Revizuire a Sprint-ului (Sprint Review Meeting) și înainte de Ședința de planificare a Spint-ului următor (Sprint Planning Meeting). Aceasta este o ședință limitată la 3 ore pentru Sprint-urile de o lună. În mod proporțional se alocă mai puțin timp Sprint-urilor mai scurte [13].
Scopul Retrospectivei Sprint-ului este:
De a inspecta modul în care ultimul Sprint a funcționat cu privire la oameni, relații, proce instrumente;
De a identifica și ordona elementele majore care au mers bine și îmbunătățirile potențiale;
De a crea un plan pentru punerea în aplicare a îmbunătățirilor în modul în care Echipa Scrum își desfășoară activitatea.
Scrum Master-ul încurajează Echipa Scrum să-și îmbunătățească, în cadrul contextului Scrum, procesul său de dezvoltare și practicile sale, pentru ca acestea să devină mai eficiente și mai plăcute în Sprint-ul următor. În timpul fiecărei Ședințe Retrospective a Sprint-ului (Sprint Retrospective Meeting), Echipa Scrum planifică moduri de creștere a calității produselor prin adaptarea Definiției "Finalizat", după caz. La sfârșitul Retrospectivei Sprint-ului, Echipa Scrum trebuie să fi identificat îmbunătățirile pe care le va implementa în următorul Sprint. Punerea în aplicare a acestor îmbunătățiri în următorul Sprint reprezintă adaptarea la auto-inspecție a Echipei Scrum însăși. Deși îmbunătățirile pot fi puse în aplicare în orice moment, retrospectiva Sprint-ului este un eveniment formal, axat pe inspecție și adaptare [13].
Artefacte Scrum
Reprezintă munca sau valoarea sub diverse forme care sunt folosite în asigurarea transparenței și a oportunităților pentru inspecție și adaptare. Artefactele definite de Scrum sunt special concepute pentru a maximiza transparența informației, cheie necesară să asigure Echipelor Scrum succesul în livrarea unui Increment considerat "Finalizat" [13].
Product Backlog
Este o listă ordonată cuprinzând tot ce poate fi necesar în produs și este singura sursă de cerințe conținând toate schimbările care trebuie făcute produsului. Proprietarul Produsului (Product Owner) este responsabil de Product Backlog, incluzând conținutul său, disponibilitatea și ordinea sarcinilor [13].
Product Backlog nu este niciodată complet. Cea mai timpurie dezvoltare a sa prezintă cerințele inițiale, cunoscute și cel mai bine înțelese. Product Backlog evoluează odată cu produsul și mediul în care acesta evoluează. Product Backlog este dinamic, se schimbă constant pentru a identifica ceea ce are nevoie produsul pentru a fi adecvat, competitiv și folositor. Atâta timp cât un produs există, va există și Product Backlog-ul acestuia. Product Backlog listează toate caracteristicile, facilitățile, funcțiile, cerințele, îmbunătățirile și remediile/reparațiile care constituie schimbări necesare de a fi facute produsului în release-urile viitoare. Elementele din Product Backlog au atribute precum descrierea, ordinea și estimarea.
Product Backlog este adesea ordonat după valoare, risc, prioritate și necesitate [13].
Elementele cu cea mai mare prioritate vor fi dezvoltate imediat transformându-se în activități de dezvoltare. Cu cât mai mare este prioritatea, cu atât elementul din backlog este mai urgent, cu atât mai mult a fost analizat și există mai mult consens privind valoarea sa.
Elementele din Product Backlog cu prioritate mai mare sunt mai clare și mai detaliate decât cele de prioritate mai mică. Estimările mai bune se fac atunci când elementul este definit clar și detaliat. Cu cât prioritatea elementului este mai mică, cu atât acesta este mai puțin detaliat, până când devine foarte vag. Elementele din Product Backlog care vor ocupa Echipele de Dezvoltare pentru următoarele câteva Sprint-uri conțin elemente prelucrate în amănunt, descompuse astfel încât orice element să poată fi “Finalizat” (“Done”) în cadrul duratei unui Sprint. Elementele din Product Back-log care pot fi “Finalizate” de Echipa de Dezvoltare în cadrul unui Sprint sunt considerate “pregătite” (“ready”) sau “gata de acțiune” (“actionable”) pentru selectarea făcută la Planificarea Sprint-ului [13].
Pe măsură ce un produs este folosit și capătă valoare, răspunsul (feedback-ul) oferit de piață crește iar Product Backlog-ul devine o listă mai cuprinzătoare și mai completă (exhaustivă). Sarcinile se modifică în continuu astfel ca Product Backlog-ul este un artefact viu. Schimbările în cerințele de afaceri, condițiile de piață sau cele tehnologice pot cauza schimbări în Product Backlog.
Adesea mai multe Echipe Scrum lucrează împreună la același produs. Un Product Backlog este utilizat pentru a descrie munca ce trebuie făcută pe produs. Un atribut al Product Backlog-ului care grupează elementele este în acest caz utilizat [13].
Întreținerea Product Backlog-ului reprezintă activitatea de adăugare de detalii, estimări și ordonare a elementelor din Product Backlog. Acesta este un proces în continuă desfășurare în care Product Owner-ul și Echipa de Dezvoltare colaborează asupra stabilirii detaliilor din Product Backlog. În timpul întreținerii Product Backlog-ului, elementele sunt reexaminate și revizuite. Totuși, acestea pot fi actualizate la orice moment de timp de către Product Owner sau la discreția acestuia.
Întreținerea este o activitate împărțită în Sprint-ului între Product Owner și Echipa de Dezvoltare. Adesea, Echipa de Dezvoltare are cunoștințele de domeniu necesare pentru a realiza această întreținere de una singură. Cum și când întreținerea este facută se decide de către Echipa Scrum. Această întreținere nu consumă de regulă mai mult de 10% din capacitatea Echipei de Dezvoltare [13].
Echipa de Dezvoltare este responsabilă de toate estimările. Product Owner-ul poate influența Echipa de Dezvoltare prin a o ajuta să înțeleagă și să selecteze compromisurile, dar membrii echipei care vor lucra efectiv fac estimările finale.
Monitorizarea Progresului către un Obiectiv
La orice moment de timp, volumul de muncă rămas pentru a atinge obiectivul poate fi însumat. Product Owner-ul urmărește acest volum de muncă rămas cel puțin la fiecare Revizuire a Sprintului (Sprint Review). Product Owner-ul compară acest volum de muncă rămas cu volumul de muncă rămas de la Ședințele de Revizuire Sprint anterioare (Sprint Reviews) cu scopul de a evalua progresul făcut spre finalizarea activității planificate în funcție de timpul dorit pentru atingerea obiectivului. Această informație este transparentă pentru toate părțile interesate.
Diverse diagrame burndown, burnup și alte practici de proiecție au fost folosite pentru a se previziona progresul. Acestea s-au dovedit folositoare. Totuși, acestea nu înlocuiesc importanța empirismului. În mediile complexe, ceea ce se va întâmpla este necunoscut. Numai ceea ce s-a întâmplat deja poate fi utilizat în viitoarele luări de decizii.
Sprint Backlog
Sprint Backlog-ul reprezintă un set de elemente/activități ale Product Backlog-ului selectate pentru Sprint, plus un plan de livrare al Incrementului cu scopul de a realiza Obiectivul Sprint-ului. Sprint Backlog-ul reprezintă o prognoză dată de Echipa de Dezvoltare cu privire la funcționalitatea cuprinsă în următorul Increment precum și de munca necesară pentru a livra această funcționalitate. Sprint Backlog-ul definește activitatea Echipei de Dezvoltare ce se va efectua pentru a transforma elementele din Product Backlog într-un Increment ”Finalizat”. Sprint Backlog-ul asigură transparența muncii pe care Echipa de Dezvoltare o identifică ca fiind necesară pentru a îndeplini Obiectivul Sprint-ului.
Sprint Backlog-ul este un plan cu detalii suficiente, astfel încât modificările survenite pe parcurs pot fi înțelese în Sedințele Zilnice de Scrum. Echipa modifică Sprint Backlog-ul de-a lungul Sprint-ului și astfel se conturează Sprint Backlog-ul. Această definire apare pe măsură ce Echipa parcurge activitățile din Sprint și își dă seama de munca necesară pentru a atinge Obiectivul Sprint-ului. Pe măsură ce activitățile sunt efectuate sau finalizate, estimarea muncii rămase este actualizată. Elementele planului considerate inutile vor fi eliminate. Numai Echipa de Dezvoltare poate schimba Sprint Backlog-ul în timpul unei iterații. Sprint Backlog-ul este vizibil, reprezintă o imagine în timp real al muncii pe care Echipa de Dezvoltare intenționează să o realizeze în timpul Sprint-ului și aparține exclusiv Echipei de Dezvoltare [13].
Monitorizarea Progresului într-un Sprint
În orice moment din Sprint se poate însuma munca totală rămasă a activităților din Sprint Backlog. Echipă de Dezvoltare monitorizează această muncă zilnic, cu ajutorul Ședințelor Zilnice de Scrum. Echipă monitorizează munca rămasă zilnic cu scopul de a estima cât mai realist probabilitatea de realizare a Obiectivului din Sprint dar și pentru a-și gestiona progresul. Scrum-ul nu ia în considerare timpul consumat pentru lucrul la elementele din Product Backlog. Timpul de lucru rămas și data sunt singurele variabile de interes [13].
Incrementul
Incrementul reprezintă suma tuturor elementelor din Product Backlog finalizate de-a lungul unui Sprint alături de toate Sprint-urile anterioare. La sfârșitul unui Sprint, noul Increment trebuie să fie în stadiul de “Finalizat”, ceea ce înseamnă ca trebuie să fie utilizabil și în concordanță cu ceea ce Echipa Scrum identifică ca fiind definiția stării “Finalizat”. Incrementul trebuie să fie utilizabil indiferent de decizia Product Owner-ului de a-l livra sau nu.
Definiția stării “Finalizat”
Când un element din Product Backlog sau un Increment este descris ca “Finalizat”, toți trebuie să înțeleagă această stare. Deși definiția stării “Finalizat” diferă de la o Echipă Scrum la altă, membrii trebuie să aibă o înțelegere comună a ceea ce înseamnă lucrul care urmează să fie terminat, pentru a asigura transparență. Această este definiția stării “Finalizat” folosită de Echipă Scrum pentru a determina când munca este completă pentru Increment [13].
Aceeași definiție îndrumă Echipa de Dezvoltare în a ști câte activități din Product Backlog poate selecta în cadrul Ședinței de Planificare a Sprint-ului. Scopul fiecărui Sprint este de a obține Incrementuri potențial livrabile, în starea “Finalizat” conform cu definiția Echipei Scrum.
Echipa de Dezvoltare furnizează un Increment de Produs în fiecare Sprint. Acest Increment este utilizabil, deci Product Owner-ul poate decide să îl livreze imediat. Fiecare Increment se adaugă la toate Incrementurile anterioare și este testat amănunțit pentru a verifica dacă toate Incrementurile din care este compus funcționează împreună [13].
Pe măsură ce Echipă acumulează experiență este de așteptat ca definiția stării “Finalizat” să se extindă pentru a include criterii mai stricte, cu scopul de a asigura o calitate superioară a Incrementului [13].
Istoric
Prima abordare a metodei SCRUM a fost descrisă de Takeuchi și Nonaka în „The New Product Development Game” (Harvard Business Review, Jan-Feb 1986). Ei au scris ca de-a lungul timpului proiectele care folosesc echipe mici care au posibilitatea de a transfera una de la alta sarcini, produc cele mai bune rezultate. De asemenea ei au asemănat aceste echipe performante cu grămada folosită în rugby (în engleză „scrum”), referindu-se la această metodă de organizare a proiectelor ca Scrum [12].
În 1991, DeGrace și Stahl, în „Wicked Problems, Righteous Solutions”, fac referire la această abordare a gestionării de proiecte. Ken Schwaber a folosit această abordare în compania lui, Advanced Development Methods, la începutul anilor 1990. În același timp, Jeff Sutherland, John Scumniotales și Jeff McKenna au dezvoltat o abordare similară în Easel Corporation, fiind primii care au numit-o Scrum. Jeff Sutherland și Ken au prezentat împreună o lucrare care descria Scrum la OOPSLA'96 în Austin, lucrarea fiind prima de acest fel prezentată publicului. Ken și Jeff au colaborat în următorii ani la contopirea lucrărilor pe această temă, a experiențelor lor și a celor mai bune practici din industrie ajungând astfel la ceea ce numim noi astăzi Scrum.
Deși Scrum a fost menită să fie o metodă de gestionare a proiectelor de dezvoltare a programelor, ea poate fi folosită și în echipe de mentenanță sau ca o abordare de gestionare a programului: Scrumul scrumului [12].
Ken Schwaber și Jeff Sutherland au fost primii care au co-prezentat Scrum la conferința OOPSLA în 1995. Această prezentare a documentat în mod esențial învățăturile pe care Ken și Jeff le-au dobândit în cei câțiva ani de aplicare a Scrum-ului. Istoria Scrum este deja considerată lungă. Pentru a onora primele locuri unde a fost încercat și perfecționat, menționăm Individual, Inc., Fidelity Investments și IDX (astăzi GE Medical) [12].
Terminologie
Următoarea terminologie este folosită în Scrum:
Scrum Team (Echipă Scrum): Product Owner, Scrum Master și Development Team [14].
Product Owner (Proprietar de produs): Persoana responsabilă de menținerea Backlog-ului de produs prin reprezentarea intereselor părților interesate și asigurarea valorii muncii echipei de dezvoltare [14].
Scrum Master: Persoana responsabilă de procesul de Scrum, asigurându-se ca este folosit corect și se maximizează beneficiile sale [14].
Development Team (Echipa de dezvoltare): Un grup funcțional de persoane responsabile pentru dezvoltarea și livrarea incrementului la sfârșitul fiecărui Sprint [14].
Sprint burn down chart (Diagramă Sprint): Progresul în fiecare zi, pe parcursul unui Sprint [14].
Release burn down chart: Progresul pe nivelul de sprint pe user story-urile finalizate din Backlog-ul Produsului [14].
Product backlog: O listă de priorități de cerințe la nivel înalt [14].
Sprint backlog: O listă de priorități de sarcini care urmează să fie finalizate în sprint [14].
Sprint: O perioadă de timp (de obicei 1-4 săptămâni) în care dezvoltarea are loc pe o serie de elemente pe care echipă s-a angajat să le creeze [14].
User story: Se adaugă la backlog și este denumit în mod obișnuit „poveste” și are o structură specifică propusă. Acest lucru este realizat, astfel încât echipă de dezvoltare poate identifica utilizatorul, acțiunile necesare, rezultatul și este un mod simplu de a scrie cereri pe care oricine le poate înțelege. Exemplu: Ca un utilizator Wiki vreau un meniu de instrumente pe ecranul de editare, astfel încât să pot aplica cu ușurință formatare de font [14].
Theme (Temă): O temă este un obiectiv de nivel superior, care pot cuprinde proiecte și produse. Temele pot fi divizate în sub-teme, care sunt mult mai specifice. Temele pot fi utilizate atât în program cât și la nivel de proiect cu scopul de a conduce strategic și de a comunica o direcție clară [14].
Epic: Un epic este un grup de povești legate, utilizate în principal în foile de backlog, precum și în caracteristicile care nu au fost încă analizate suficient pentru a fi divizate în user story-uri, care ar trebui să fie făcute înainte de a porni un sprint [14].
Spike: O perioadă de timp folosită pentru a cerceta un concept și / sau de a crea un prototip simplu. Spikes poate fi planificat să aibă loc între sprinturi sau, pentru echipe mai mari, ca un sprint [14].
Tracer Bullet: este un spike cu arhitectură actuală, set de tehnologii actuale, set de bune practici care sunt calități ale producției. Această ar putea fi doar o implementare foarte scurta de funcționalitate [14].
Point Scale/Effort/Story points: Se referă la un sistem de puncte abstracte, folosite pentru a discuta despre dificultatea user story-ului, fără atribuirea de ore efective. Cea mai comuna scara utilizată este o secvență Fibonacci (1,2,3,5,8,13,20,40,100), cu toate ca unele echipe utiliza scala liniară (1,2,3,4 …), puteri de două (1,2,4,8 …), și dimensiunea (XS, S, M, L, XL) [14].
Tasks (Sarcini): Adăugate la user story-uri de la începutul unui sprint și divizate în ore. Fiecare sarcina nu trebuie să depășească 12 de ore, dar unele echipe insista că o sarcină durează mai mult de o zi [14].
Capitolul 4
Implementarea soluției
In acest capitol voi prezenta pașii pe care i-am urmat în implementarea acestei aplicații, cerințele funcționale, conținutul bazei de date, arhitectura aplicației, integrarea celor două sisteme de cloud și în final voi descrie cum funcționează aplicația.
Pentru evidențierea modului în care se integrează două sisteme de cloud, am ales dezvoltarea unei aplicații web pentru automatizarea unui sistem de gestiune a delegațiilor într-o companie.
Prin această aplicația de automatizare a unui sistem de gestiune a delegațiilor, am dorit să pun în practica integrarea a două sisteme de cloud, astfel accentul nu cade pe automatizarea cererilor de delegații, ci pe modul în care am implementat această automatizare, cum am integrat funcționalitatea folosind cele două sisteme de cloud, ce anume se află în Office 365 și ce se află în Azure.
Așa cum am menționat în capitolul 1, în crearea proiectului meu de licență am fost susținută de compania IQuest. Deși am dezvoltat singură aplicația, managerul meu de proiect, m-a ajutat să folosesc metodologia de dezvoltare SCRUM. Scopul a fost să învăț care sunt pașii și cum se folosește această metodologie în dezvoltarea unui proiect.
După stabilirea temei, am creat user-story-urile din product backlog:
Ca un angajat mi-ar plăcea să pot crea o cerere de delegație, astfel încât să pot urmări procesul de aprobare al cererii mele.
Ca un angajat mi-ar plăcea să am o listă cu toate cererile mele de delegații, astfel încât să am o privire de ansamblu cu toate delegațiile mele.
Ca manager, aș dori să primesc cererile de delegații și să le pot aproba sau respinge, printr-un proces automatizat astfel încât să fie minimizată comunicarea prin e-mail.
Ca un membru al echipei de resurse umane aș dori să primesc notificări pentru a aproba cererile de delegații, în scopul de a avea acest proces automatizat astfel încât să fie minimizată comunicarea prin e-mail.
Am creat două sprint-uri de 3 săptămâni fiecare cu cate două user story-uri din product backlog și am divizat user story-urile în task-uri astfel:
Sprint 1
Ca un angajat mi-ar plăcea să pot crea o nouă cerere de delegație, astfel încât să pot urmări procesul de aprobare al cererii mele.
Task-uri:
Crearea paginii pentru înregistrarea delegației.
Crearea bazei de date cu informațiile necesare pentru crearea unei cereri.
Adăugarea informațiilor pe pagina.
Gestionarea zoom-ului de pe hartă.
Crearea conținutului și listei cu cereri de delegații.
Adăugarea datelor din cerere în cloud-ul de Office 365.
Ca un angajat mi-ar plăcea să am o listă cu toate cererile mele de delegații, astfel încât să am o privire de ansamblu cu toate delegațiile mele.
Task-uri:
Crearea meniului de navigare dintr-un cloud în altul.
Crearea butoanelor de adăugare și editare a unei cereri.
Navigarea cu butoanele create anterior dintr-un cloud în altul cu transmiterea de informații.
Sprint 2
Ca manager, aș dori să primesc cererile de delegații și să le pot aproba sau respinge, printr-un proces automatizat astfel încât să fie minimizată comunicarea prin e-mail.
Crearea workflow-lui de aprobare
Crearea unui cont cu mai mulți utilizatori
Gestionarea de email-uri.
Ca un membru al echipei de resurse umane aș dori să primesc notificări pentru a aproba cererile de delegații, în scopul de a avea acest proces automatizat astfel încât să fie minimizată comunicarea prin e-mail.
Gestionarea de email-uri.
Tot la început, a stabilit care este condiția ca un task să fie finalizat și anume: „Un task este finalizat, dacă este implementat, testat și i se face code review.”
User story-urile le-am pus în JIRA și le-am împărțit pe taskuri, pe care mi le-am aproximat singură. Pentru ca am lucrat pe o tehnologie noua și mai mult, a fost prima dată când am făcut aproximări, am estimat mai puțin decât aveam nevoie. La sfârșitul fiecărui Sprint am primit feedback și am învățat astfel, că trebuie să caut mai multe informații înainte de a aproxima un task (mai mult research), să nu pierd mult timp pe anumite task-uri
4.1. Cerințe funcționale
Am prezentat în capitolele anterioare care sunt motivele pentru care sunt folosite din ce în ce mai mult sistemele de cloud, ajungând la concluzia că decizia unei companii de a adopta sau nu o soluție în cloud, depinde în mare parte de necesitățile ei.
Scopul acestui proiect este de a oferi o soluție pentru integrarea a două sisteme de cloud. În dorința de a reprezenta această soluție, am ales să implementez automatizarea unui sistem de gestiune de delegații. Se dorește ca acest sistem de gestiune să fie eficient, dinamic, flexibil și ușor de folosit.
Proiectul implică existența a trei tipuri de utilizatori: angajatul care dorește să plece în delegație, managerul de proiect care trebuie să aprobe plecarea în delegație a angajatului respectiv și departamentul de resurse umane care aloca bugetul necesar delegației (HR).
Pentru a pleca într-o delegație, un angajat trebuie să creeze o cerere de delegație, pe care trebuie să o aprobe managerul său de proiect și departamentul de resurse umane HR.
Folosind această aplicație, angajatul își creează ușor această cerere, pentru ca are posibilitatea vizualizării pe harta a țărilor și orașelor în care se află sediile companiei. Pe hartă sunt reprezentate de asemenea, sediile companiei și hotelurile aprobate de aceasta. Astfel, angajatul poate vizualiza hotelurile cele mai apropiate de sediul la care vrea să meargă, detaliile și imaginile de prezentare ale hotelurilor pe aceeași pagină în care se creează cererea, fără a fi nevoie să caute singur pe internet. Astfel cererea creată, poate fi salvată, editată sau trimisă spre aprobare prin pornirea unui workflow de aprobare. În momentul pornirii workflow-ului, cererea este trimisă automat managerului de proiect. Dacă aprobă cererea, această este trimisă automat departamentului de resurse umane, iar prin aprobarea de către acest departament răspunsul pozitiv este trimis automat angajatului. Contrar, dacă managerul de proiect respinge cererea, această se întoarce la angajat care o poate modifica și retrimite din nou. În momentul în care cererea este aprobată și de managerul de proiect și de departamentul de resurse umane, poate pleca în delegație.
Angajatul are posibilitatea să monitorizeze toate cererile de delegație și care este starea lor, dar primește și email cu statusul cererii sale curente.
Managerul de proiect și departamentul de resurse umane, primesc un email cu cererea angajatului și un link care îl redirecționează către cerere pentru a putea confirma sau respinge cererea.
4.2. Arhitectura aplicației
Pentru a folosi cele două cloud-uri, am creat o aplicație Sharepoint 2013 Autohosted, iar soluția conține 3 proiecte: BusinessTrip, BusinessTripWeb si BusinessTripDatabase.
Ce este o aplicație autohosted?
O aplicație Autohosted, este o aplicație SharePoint în care pot fi incluse componente externe. Componentele externe ale unei aplicații autohosted se instalează automat când aplicația în sine pentru SharePoint este instalata, astfel încât să nu fie nevoie să se creeze nici o logică personalizată pentru instalarea aplicației autohosted. Cu o aplicație autohosted, fiecare instanță a aplicației este izolata automat de toate celelalte instanțe. Aplicațiile autohosted pot utiliza toate tipurile de site-uri web ASP.NET și aplicații web. Componenta de baza de date, într-o aplicație autohosted trebuie să fie o bază de date SQL Azure. Site-urile externe din aplicațiile autohosted pot fi utilizate doar pentru un Windows Web Site Azure și componenta de baze de date poate fi utilizată numai pentru SQL Azure. Dezvoltatorii SharePoint Online pentru Windows Azure au și un cont ascuns SQL Azure. Cu o aplicație autohosted, nu este nevoie de înregistrare cu OAuth conform serverului (STS), și nici nu trebuie creată o aplicație principală și înregistrată cu STS. Aceste sarcini sunt efectuate automat când se instalează aplicația [1].
Aplicațiile Autohosted pentru SharePoint sunt găzduite pe Windows Azure Web Sites. Ca și o aplicație SharePoint hosted, o aplicație SharePoint autohosted interacționează cu SharePoint 2013, dar de asemenea, folosește resurse și servicii care se află pe un site la distanță, care este găzduit de către Windows Azure Web Sites[16].
Beneficii:
Când se implementează o aplicație autohosted pentru SharePoint, toate componentele Windows Azure și Windows Azure SQL Database sunt găzduite, atunci când este instalată aplicația SharePoint [15].
Infrastructura Windows Azure Web Sites se ocupă de load balancing, multi-hosting și alte sarcini importante de întreținere [15].
Dacă se utilizează autohosting pentru o aplicație, fiecare instalare găzduiește propriul site pe Azure [15].
În momentul în care rulez aplicația, ea se instalează pe cloud, astfel primul proiect își instalează funcționalitatea SharePoint în Office 365, iar al doilea proiect cu funcționalitate web se instalează pe Azure.
Primul proiect BusinessTrip include funcționalitatea Sharepoint, în care creez o listă numită BusinessTripRequestList. În acesta listă se înregistrează cererile de delegații.
Al doilea proiect BusinessTripWeb include funcționalitatea web, în care am construit pagina unde se înregistrează cererile de delegații. Astfel, datele pentru cererile de delegații se aleg în pagina din Azure, și sunt trimise folosind limbajul JavaScript în lista Sharepoint din cloud-ul Office 365. Navigarea dintr-un cloud în altul se face pe baza url-urilor AppWebUrl și HostUrl. Astfel că AppWebUrl este url-ul pentru aplicația din Azure, iar HostUrl este url-ul folosit pentru aplicația din Office 365.
Al treilea proiect este folosit pentru a crea baza de date Azure în care rețin datele folosite pentru prima pagina.
Pentru a lega cele trei proiecte în aceeași soluție, a fost nevoie sa fac următoarele setări:
Primul proiect BusinessTrip, a fost legat cu cel de al doilea, BusinessTripWeb prin crearea proiectului de tip Autohosted. Această soluție leagă automat cele doua proiecte pentru a putea folosi funcționalitatea din Sharepoint în Azure și invers.
Legarea primelor două proiecte cu proiectul BusinessTripDatabase care creează baza de date SQL Azure se face:
Pentru proiectul BusinessTrip se setează în proprietăți SQL Database ca în imagine:
Pentru proiectul BusinessTripWeb se adaugă în Web.config în <configuration> <appSettings> linia de cod:
<add key="SqlAzureConnectionString" value="Data Source=localdb\Projects; Initial Catalog=CompanyDataBaseIntegrated; Security=True; Connect Timeout=30;Encrypt=False;TrustServerCertificate=False" />
Web.config va arata astfel:
4.3. Baza de date
Pentru pagina din Azure în care se creează cererile de delegații, folosesc baza de date SQL Azure în care rețin țările, orașele, unde sunt situate sediile companiei și hotelurile care sunt avizate de companie pentru delegații. Baza de date se află pe cloud-ul Azure. Avantajul folosirii unei baze de date SQL Azure este faptul ca aceasta este găzduită pe Azure în momentul instalării aplicației. Componența bazei de date este ilustrată folosind o diagramă:
Baza de date conține 4 tabele în care rețin țările și orașele în care se găsesc sediile companiei și hotelurile aprobate de aceasta pentru o delegație.
4.4. Utilizarea Microsoft Office 365 și Windows Azure
Microsoft Office 365 este un SaaS oferit de Microsoft care oferă versiunile online ale SharePoint-ului 2010, Exchange 2010, și Lync 2010, toate găzduite și întreținute de către Microsoft la centrele lor de date. Astfel, Office 365 include Microsoft Office Professional Plus, o aplicație desktop și Office Web Apps, o versiune online bazata pe browser de Word 2010, Excel 2010 și PowerPoint 2010. Microsoft a lansat Office 365 beta privat în noiembrie 2010 și în cele din urmă o face publică pe 28 iunie 2011. Office 365 este următoarea versiune de Business Productivity Online Services (BPOS), care a oferit versiunile online ale Exchange 2007 și SharePoint 2007.[carte]
Microsoft a dezvăluit prima platforma Windows Azure pentru participanții de la Developers Conference Microsoft (PDC), în 2008. La aceeași conferință, Microsoft a lansat un Technology Preview (CTP) versiune comunitară a Windows Azure, destinată numai pentru testare și scopuri de feedback. La acel moment, toate serviciile Windows Azure au fost oferite gratuit. Inițial, ea a lansat un model de tarifare și un proces de înscriere obligatorie pentru noi clienți Windows Azure Platform, dar a renunțat la taxele pentru luna ianuarie 2010. Începând din februarie 2010, Microsoft a lansat o versiune publică a Windows Azure. De atunci, Microsoft ocazional adăugă și actualizează seturile componentelor platformei Azure. Aceste actualizări în primul rând țin pasul cu schimbările tehnologice care au loc în lumea cloud computing.
4.4.1. Integrarea celor două cloud-uri
Integrarea celor două cloud-uri se face prin crearea unei soluții hibride. O aplicație autohosted este o soluție hibrida.
Ce sunt soluțiile hibride?
Având în vedere limitările SharePoint Online, pot exista momente când aveți nevoie să construiți o soluție hibridă pentru a include atât SharePoint Online cât și SharePoint on-premises. Mai mult, pentru aplicații care au nevoie de extindere pe două medii când se folosește scrierea de cod client-side, cum ar fi: Silverlight și aplicații JavaScript, soluțiile hibride pot fi folosite alegerea potrivită atât timp cât se pot depăși problemele de conectivitate și de identitate. Un alt tip util de soluție hibridă implică atât Office 365 și Windows Azure. Prin combinarea celor două cloud-uri, se pot construi soluții mai complexe care să cuprindă cele două medii [108 carte].
4.5. Ghidul aplicației
In momentul în care este rulata aplicația, apare următoarea imagine, în care se cer permisiuni pentru a folosi diferite elemente din SharePoint. Aceste permisiuni le-am setat eu în proiect și le folosesc în aplicație. Pentru a rula aplicația trebuie apăsat butonul „Trust it”.
Dacă aplicația a fost deja instalata pe cloud, pagina anterioara nu mai apare.
Pentru ca aplicația mea folosește funcționalitate instalata pe 2 cloud-uri, am ales să folosesc interfețe diferite pentru a face distincție intre ce se afla pe un cloud și ce se afla pe celălalt.
Pagina de start a aplicației reprezintă pagina în care se creează cererea de delegație. Această pagina se afla în Azure.
Se poate observa că pe hartă sunt reprezentate atât sediile din orașul respectiv cât și hotelurile din apropiere, astfel, angajatul poate găsi cel mai apropiat hotel pentru ca drumul pana la sediu să nu necesite mult timp.
Din imaginea următoare, se observa că angajatul poate vedea mai multe detalii despre hoteluri prin mutarea mouse-ului pe pin-ul care îl reprezintă pe hartă. Se poate vedea adresa, iar link-ul duce direct pe pagina hotelului respectiv.
După ce sunt completate toate câmpurile cu *, angajatul poate adăuga cererea prin apăsarea butonului „Submit”. în momentul în care este apăsat butonul „Submit”, se transfera toată datele din pagina aflată în Azure și cererea este adăugată în lista Sharepoint „BusinessTripRequestList” din Office 365, iar angajatul primește un mesaj ca în imaginea următoare:
Meniul de pe această pagina conține:
B.T. Request: pagina curenta în care se creează cererile de delegații;
B.T. History: lista din SharePoint în care sunt înregistrate toate cererile de delegații;
About: pagina în care se găsesc mai multe informații despre aplicație;
Contact: date de contact;
Lista în care sunt înregistrate delegațiile, la care se ajunge din meniu pe „B.T. History” este afișată în următoarea imagine:
Această listă este o listă SharePoint și are funcționalitate SharePoint. În următoarea imagine avem meniul din lista:
Prin apăsarea butonului „New Business Trip Request”, se face navigarea pe pagina de creare a unei cereri, adică pagina descrisa anterior.
Se poate observa că butonul de Edit nu poate fi accesat deoarece nu s-a selectat nici o cerere din lista. Butonul „Edit Business Trip Request”, navighează pe pagina prezentata anterior, dar pentru editarea cererii, astfel ca toate câmpurile sunt completate cu datele existente în cererea respectiva.
Se observa că avem în meniu „Workflow” care se traduce ca „Flux de lucru”, în detaliu pe o lista SharePoint se poate porni un Workflow sau mai multe cu diferite acțiuni asupra elementelor din lista.
Pentru a trimite cererea spre aprobare, trebuie să navigam pe butonul de Workflow și să ne alegem ApprovalWorkflow. Acest workflow este creat de mine în proiectul de Office 365 și este responsabil de toți pașii din procesul de aprobare, adică de trimitere de email-uri, asignarea task-ului care așteaptă aprobarea sau respingerea managerului de proiect și a departamentul de resurse.
La pornirea acestui workflow, trebuie să adăugam managerul de proiect pentru a ști cui anume se trimite cererea de aprobare:
În momentul în care se apasă pe butonul „Start”, este creat automat un task și se trimite un email cu linkul către acel task, care deține informațiile despre cererea de delegație și așteaptă să fie aprobat sau respins.
Emailul primit de managerul de proiect arata ca în imaginea următoare:
După navigarea pe linkul din email, managerul de proiect are posibilitatea să aprobe sau să respingă cererea folosind unul dintre butoanele de mai jos:
Dacă cererea este respinsa, angajatul care a creat cererea primește un email în care este înștiințat că cererea lui a fost respinsa și Workflow-ul se termina. Se poate vedea un exemplu în următoarea imagine:
Dacă cererea este aprobată, atunci se asignează un task pentru departamentul de resurse umane, se trimite către acest departament emailul următor:
Tot la acest pas se trimite către angajat emailul următor:
Dacă cererea a fost aprobată și de departamentul de resurse umane, atunci se trimite un email către angajat și către managerul de proiect cu următorul mesaj:
Pentru a exemplifica această automatizare a aprobării unei cereri de delegație, am ales să simulez momentul în care ar trebui să plec într-o delegație. Utilizatorii din acest exemplu: Andreea Tocanie – eu (angajat), Tibor Molnar – managerul meu de proiect și HR Department – departament de resurse umane.
Capitolul 5
Posibilități de dezvoltare
Soluția oferită pentru automatizarea unui sistem de gestiune a delegațiilor, a fost bazata pe integrarea de cloud-uri. Facilitățile oferite de cloud computing pot fi extinse în mai multe direcții.
Una dintre posibilitățile de dezvoltare ar fi prin integrarea funcționalității Sharepoint prin web-part-uri în pagini din Windows Azure. Acest lucru este posibil și ar însemna uniformizarea interfeței aplicației.
O altă posibilitate ar fi prin crearea unei baze de date cu toți angajații, proiectele curente și echipele care lucrează în cadrul unei companii astfel ar fi posibilă identificarea automată a managerului de proiect.
Se poate dezvolta această aplicație prin crearea unui întreg portal al unei companii, folosind integrarea celor două cloud-uri.
În concluzie, cloud computingul este o inovație care oferă companiilor o altă variantă de utilizare a produselor soft de care au nevoie, cu o reducere a costurilor, timpului și personalului necesar pentru întreținerea locală a serverelor și programelor. Integrarea de cloud-uri poate înlocui pe deplin nevoia de a achiziționa soft-uri locale pentru ca în acest mod, serviciile oferite de unele cloud-uri se completeaza cu serviciile oferite de alte cloud-uri, construind un întreg necesar dezvoltării anumitor aplicații.
Consider ca dezvoltarea acestei aplicații a fost benefica pentru mine, ca a fost exact ce aveam nevoie pentru a înțelege, învăța și aplica o parte din noutățile oferite de SharePoint 2013 și cloud computing.
Bibliografie
[1] http://ro.wikipedia.org/wiki/Cloud_computing
[2] Programming Microsoft's Clouds – Windows Azure and Office 365, autor Tom Rizo, editura Wrox, 2013
[3] http://www.asw.ro/cloud-computing
[4] http://en.wikipedia.org/wiki/Windows_Azure
[5] http://en.wikipedia.org/wiki/Microsoft_Office_365
[6] http://howtotechguru.com/microsoft-cloud-services-office-365/1157
[7] http://en.wikipedia.org/wiki/Microsoft_SharePoint
[8] http://office.microsoft.com/ro-ro/sharepoint-foundation-help/ce-este-sharepoint-HA010378184.aspx
[9] http://msdn.microsoft.com/en-us/library/sharepoint/jj163091.aspx
[10] The definitive Guide Java Script –autor Daniel Flanagan, editura O’Reilly
[11] http://ro.wikipedia.org/wiki/JQuery
[12] http://ro.wikipedia.org/wiki/Scrum_(programare)
[13]http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20RO.pdf
[14] http://en.wikipedia.org/wiki/Scrum_(software_development)
[15] http://jonathanvanderoost.com/2013/06/03/create-an-auto-hosted-apps-sharepoint-using-sql-azure-database/
[16] http://msdn.microsoft.com/en-us/library/fp179885.aspx
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Integrarea a Doua Sisteme de Cloud Windows Azure Si Office 365 (ID: 149929)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.