Cinci principii de gestionare a ciclului de viață al aplicațiilor. Conceptul metodologiei de gestionare a ciclului de viață al aplicației - ALM (Application Lifecycle Management)

Managementul ciclului de viață al aplicațiilor (ALM) evoluează rapid. Aceasta este o abordare promițătoare pentru îmbunătățirea procesului de dezvoltare software. Cu toate acestea, procesul „tradițional” ALM nu este capabil să-și atingă întregul potențial de profit pentru organizație. De ce? Deoarece vânzătorii împing în mod agresiv soluții ALM limitate de la un capăt la altul pe piață, care vizează legarea clienților de platformele tehnologice închise. Clienții constată în curând că aceste soluții nu se integrează cu procesele, instrumentele și platformele de dezvoltare existente. Din păcate, acest lucru lasă echipelor de dezvoltare procesele fragmentate și o mizerie de date ALM, ceea ce, la rândul lor, le împiedică să realizeze pe deplin capacitățile ALM.

Este necesară o nouă abordare pentru a rezolva această problemă. O abordare care permite clienților să creeze software utilizând un mediu mixt de dezvoltare. Cu soluțiile Borland Open ALM, organizațiile își pot folosi resursele și instrumentele de dezvoltare existente. Acest lucru va ajuta la realizarea transparenței, controlului și disciplinei pe tot parcursul ciclului de dezvoltare software. Clienții pot beneficia acum de o platformă ALM optimizată și de un proces de dezvoltare software unic, gestionabil și măsurabil.

Dezvoltare software previzibilă: misiune imposibilă?

Dezvoltarea de software este în esență o întreprindere complexă. Crearea unui produs software cu caracteristici destul de clar definite, realizată cu o calitate acceptabilă, în limita bugetului alocat și la timp, necesită coordonarea constantă a unui număr mare de acțiuni între numeroși specialiști.

Complexitatea gestionării și urmăririi proiectelor software crește atunci când organizațiile decid să utilizeze modele de dezvoltare distribuite (de exemplu, programarea offshore sau utilizarea angajaților temporari și a subcontractanților). Ca urmare, eșecul sau încetarea proiectului devine omniprezent. Depășirile de costuri, programările ratate, calitatea slabă și fiabilitatea slabă au devenit norma în industria software-ului. În consecință, se solicită din ce în ce mai multe abordări inteligente din partea organizațiilor de dezvoltare software. Aceștia trebuie să adopte abordări bine gestionate, structurate și orientate spre proces, care urmează pașii disciplinelor de inginerie mai tradiționale. 1

Odată cu creșterea standardizării și utilizarea platformelor de dezvoltare corporativă, provocările cu care se confruntă industria au devenit mai puțin tehnice. Abilitatea de a genera valoare stabilă și previzibilă din dezvoltarea de software a devenit o prioritate semnificativă pentru mulți profesioniști în tehnologia informației (IT). Au nevoie de încrederea că echipele lor vor fi eficiente în crearea de software. Având în vedere aceste considerații, Borland a dezvoltat platforme pentru ALM. Acestea sunt concepute pentru a rezolva problema stabilității și predictibilității procesului de dezvoltare software.

1 Tendințele cheie din industrie, cum ar fi adoptarea accelerată a cadrului de îmbunătățire a proceselor CMM / CMMI și utilizarea sporită a modelelor de dezvoltare ale terților sunt strâns legate de această transformare aparentă a industriei software.

Apariția ALM

Întrucât industria de dezvoltare de aplicații răspunde la nevoia de dezvoltare software previzibilă, și-a concentrat eforturile pe mai mult decât instrumente destinate dezvoltatorului individual. Producătorii și-au extins ofertele și au integrat atât capacitățile existente, cât și cele noi în produsele lor. Soluțiile lor îndeplinesc acum sarcini asociate cu alte roluri în procesul de dezvoltare software. Aceste suite de produse, adesea comercializate și comercializate ca platforme de dezvoltare colaborativă, au introdus tehnologia Application Lifecycle Management (ALM). A devenit o nouă categorie pe piață și o disciplină separată în dezvoltarea de software. Platformele ALM sunt concepute special pentru a aborda provocările legate de creșterea predictibilității și integrității procesului de dezvoltare software. Acestea abordează aceste provocări oferind integrare și automatizare pentru fiecare rol major care participă la proces și automatizând o serie de funcții.

Măsurabilitate	Abilitatea de a defini sisteme de măsuri pentru a evalua calitatea, productivitatea, progresul și riscul.
	Analizați aceste valori și generați rapoarte pe măsură ce proiectul progresează.

Acord	Alinierea specializării în afaceri și a priorităților IT.
	Alinierea rezultatelor proiectului cu așteptările utilizatorului final.

Disciplina	Coerența definiției, implementării și urmăririi cu procesele software.
	Creșterea severității procesului de schimbări în management și prezicerea consecințelor acestora.

Aceste capabilități permit liderilor IT să-și echilibreze și să-și prioritizeze portofoliile de proiecte software. Aceștia pot atinge un nivel mai ridicat de management al echipelor lor și mult mai multă transparență în implementarea proiectelor. ALM poate ajuta, de asemenea, directorii să câștige mult mai mult control asupra procesului de dezvoltare software. Acest lucru oferă oportunități mai bune pentru guvernanța corporativă și ajută organizația să demonstreze conformitatea cu diferite reguli și reglementări.

Industria ALM

Inițial, unul dintre puținii inovatori care au înțeles importanța tendinței ALM și și-au schimbat strategiile de lansare a produsului către un sprijin explicit pentru aceasta Borlandși IBM Rational... Alte companii, Microsoft, IBM Rational / Telelogic, Mercury și Serena, au răspuns la posibilitățile evidente și s-au alăturat conceptului ALM câștigător. ALM astăzi este o tendință stabilită și o industrie în creștere recunoscută de analiști. Furnizorii ALM oferă o varietate de instrumente și tehnologii pentru a sprijini procesul de dezvoltare software. Aceste instrumente depășesc cu mult instrumentele tradiționale de productivitate ale dezvoltatorului individual. Acestea vizează furnizarea de metodologii și instrumente axate pe munca în echipă pentru a crea software. Pentru a crea o soluție ALM viabilă, furnizorii trebuie să răspundă nevoilor grupului de dezvoltare software „extins” și să includă roluri în produsele lor care sunt implicate în procesul mai larg.

Pentru nevoile managerilor, există tablouri de bord la nivel de portofoliu de proiecte care acoperă valori importante ale proiectului: risc, progres și calitate.

Pentru nevoile managerilor de proiect, sunt furnizate instrumente pentru planificarea și controlul proiectului, analiza posibilelor alternative și alocarea resurselor.

Pentru nevoile analiștilor, sunt furnizate instrumente pentru a defini cerințele, a interacționa cu utilizatorii finali și cu alte părți interesate ale proiectului. De asemenea, oferă instrumente pentru gestionarea cerințelor pe tot parcursul ciclului de viață al proiectului, inclusiv modificările ulterioare.

Pentru nevoile arhitecților, există instrumente pentru modelarea vizuală a diferitelor aspecte ale aplicației (componente, date, proces), precum și instrumente pentru descrierea modelelor de proiectare și a arhitecturii corporative.

O varietate de medii de programare și instrumente de asigurare a calității la nivel de cod (cum ar fi profileri de execuție, testare unitară și audit automat de cod) sunt furnizate pentru nevoile dezvoltatorilor.

Pentru nevoile inginerilor de calitate, există instrumente pentru crearea și gestionarea testelor, pentru regresie și testare funcțională, precum și instrumente pentru testarea automată a performanței.

O infrastructură colectivă servește la rezolvarea problemelor comune ale întregului grup. Oferă instrumente pentru colaborare, gestionarea proceselor, gestionarea schimbărilor și controlul versiunilor.

Pentru nevoile managerilor procesului de dezvoltare software, există instrumente pentru modelarea și aplicarea unui set de standarde tehnologice corporative.

Pentru nevoile utilizatorilor finali și ale altor părți interesate din organizație, sunt furnizate instrumente pentru automatizarea gestionării cerințelor. De asemenea, li se oferă posibilitatea de a face schimb de informații despre cerințe, de a raporta defecte și de a urmări starea întrebărilor ridicate.

Tehnologia ALM este recunoscută pe scară largă ca un pas major înainte în dezvoltarea industriei de dezvoltare a aplicațiilor și a clienților săi. Interesant este faptul că cel mai recent „raport Haos” de la Standish Group arată că numărul proiectelor software eșuate a scăzut la jumătate în ultimul deceniu. Această îmbunătățire poate fi parțial atribuită și ALM. Cu toate acestea, un studiu mai aprofundat al nevoilor clienților relevă faptul că, deși ALM are beneficii clare, este totuși dificil de realizat întregul său potențial. Pentru a face acest lucru, trebuie să schimbați abordarea fundamentală care este utilizată pentru a integra procesele și instrumentele implicate în ciclul de viață al software-ului.

Potențialul de afaceri ALM este în mare parte nerealizat

Pentru a înțelege mai bine de ce soluțiile actuale îngreunează dezlănțuirea completă a capacităților de afaceri ale ALM, să aruncăm o privire mai atentă asupra dezvoltării software tipice și a mediilor de operare. Vom examina modul în care software-ul este produs și implementat în termeni de procese, instrumente de dezvoltare și platforme de lucru. În cele din urmă, această discuție explică de ce producția de software rămâne unul dintre ultimele procese de afaceri care nu reușesc - să nu mai vorbim de automatizare - în mod consecvent și previzibil.

Mediul IT corporativ: provocarea eterogenității

Creșterea internetului și proliferarea acestuia ca platformă principală pentru comerț a adus schimbări semnificative în organizațiile IT convenționale. Acest lucru a fost facilitat și de munca constantă forțată în condiții de lipsă de resurse și cereri mari de flexibilitate. Problema acestor schimbări are legătură cu evoluția arhitecturală. Acesta își propune să îmbunătățească capacitatea de reacție și nivelurile de servicii IT și eficiența prin trecerea de la tehnologii vechi la platforme de aplicații noi și moderne. Acestea sunt domeniile cheie ale acestei evoluții.

Migrați de la aplicații specializate pentru mainframe monolitice la noi instrumente de dezvoltare pentru platforme distribuite pentru întreprinderi, și anume J2EE și .NET.

Migrați de la aplicații de întreprindere ambalate, construite pe arhitecturi vechi, pentru a procesa și a compune timpii de execuție a aplicațiilor, cum ar fi SAP NetWeaver și Oracle Fusion.

Utilizarea platformelor specializate pentru nevoi specifice. Acestea sunt, de exemplu, limbaje de script pentru aplicații web care utilizează baze de date (PHP, Ruby etc.) sau platforme pentru dezvoltarea de aplicații cu o varietate de funcții Internet și multimedia (de exemplu, Adobe® Flash® / Flex ™).

Fiecare dintre aceste tehnologii este asociată cu instrumente specifice de dezvoltare a aplicațiilor (deseori oferite de diverși furnizori). Aceste instrumente acoperă analiza, proiectarea, codificarea, controlul calității, controlul versiunilor și gestionarea configurației.

Este rezonabil să presupunem, în special pentru medii și corporații mari, că pentru viitorul previzibil, fiecare mediu IT al întreprinderii va include cel puțin trei dintre platformele listate pentru implementare: mainframe, mediu distribuit (J2EE sau .NET) și sistem de automatizare a afacerii. -procese (SAP sau Oracle). De asemenea, se pare (și devine din ce în ce mai evident) că unele organizații implementează software atât pe platformele J2EE, cât și pe platforma .NET. 2

Programe conflictuale

Este interesant de observat că, din motive evidente, unii furnizori de IT încearcă să influențeze cât mai mult natura eterogenă a mediului IT al întreprinderii. Acești vânzători caută să „preia” pe deplin organizarea mediului IT, împingând pe piață soluții complete „pe toată durata vieții”. Acestea conțin instrumente de dezvoltare software, un mediu de aplicații și instrumente pentru gestionarea rețelelor și sistemelor. Producătorii importanți includ, de asemenea, un sistem de operare sau chiar hardware în soluțiile lor. Este de la sine înțeles că astfel de soluții implică și o componentă semnificativă a serviciilor profesionale.

În ciuda acestui impuls masiv pentru soluții cuprinzătoare dintr-o singură sursă, realitatea este că, pentru mulți clienți, această abordare pur și simplu nu funcționează. Astfel de organizații sporesc eterogenitatea la toate nivelurile. Prin urmare, au un set de priorități diferite care fac ca anumite obiective să fie importante pentru client (nu pentru furnizor).

Maximizarea competitivității. Organizațiile care încearcă să ofere cel mai bun produs sau serviciu aleg de obicei cea mai bună platformă și instrument de dezvoltare din perspectiva proiectului. Această abordare îi ajută să obțină beneficiile pe care fiecare platformă le oferă utilizatorilor finali specifici. Acest lucru se întâmplă adesea în proiecte separate, dar se poate întâmpla și în același proiect. Acest lucru duce în cele din urmă la aplicații „hibride” care acoperă mai multe domenii tehnologice. Iată câteva exemple relevante.

o Aplicații sau servicii compozite, care includ mainframe, aplicații ambalate și aplicații distribuite auto-dezvoltate.

o Hibrizi J2EE / .NET care valorifică capacitățile clientului și interfața cu utilizatorul .NET. Pe partea de server, acestea valorifică scalabilitatea, capacitatea de gestionare și securitatea tehnologiei J2EE. Acest model arhitectural este deosebit de comun în verticală financiară. Este utilizat pentru platformele de tranzacționare de înaltă performanță, deoarece Windows este standardul de facto pentru desktop de pe Wall Street.

o Hibrizi Flash / J2EE. Acestea combină puterea Adobe Flash ca o platformă pentru streaming video și aplicații Internet bogate cu beneficiile tehnologiei J2EE pentru servere. Acest lucru permite o scalabilitate ridicată și o interfață multimedia bogată.

Costuri reduse de dezvoltare. Organizațiile încearcă să reducă costurile de dezvoltare și implementare a software-ului, combinând atât instrumente și programe open source, cât și proprietare. În acest sens, merită menționat popularitatea crescândă a suitei LAMP (Linux, Apache, MySQL, PHP) și utilizarea crescândă a acesteia în organizații.

Timp redus de comercializare a produselor. Organizațiile pot prefera anumite instrumente de dezvoltare din cauza beneficiilor specifice pe care le oferă. Acest lucru are potențialul de a reduce semnificativ timpul de comercializare a produselor.

Utilizarea eficientă a investițiilor deja efectuate. Orice abordare „distruge și înlocuiește” se confruntă cu obstacole semnificative. Acest lucru se datorează faptului că majoritatea organizațiilor nu doresc să renunțe la investiții semnificative în programe și instrumente vechi.

Reducerea riscului. Mai mulți furnizori din industria IT oferă suport nativ personalizat pentru platformele lor. Acest lucru este văzut ca un risc în ochii clienților lor. Legarea unui anumit furnizor IT de platformă poate duce la un risc comercial semnificativ, mai ales dacă acel furnizor este (sau va deveni) un concurent.

2 Tendințele cheie din industrie, cum ar fi adoptarea accelerată a cadrului de îmbunătățire a proceselor CMM / CMMI și utilizarea sporită a modelelor de dezvoltare ale terților sunt strâns legate de această transformare aparentă a industriei software. Raportul de utilizare J2EE și .NET al lui IDC Insight de Steve McClure afirmă următoarele. 10,4% din utilizatorii actuali .NET se așteaptă să utilizeze J2EE / J2ME în următoarele 12 luni; 11,9% dintre utilizatorii J2EE / J2ME se așteaptă să fie implicați în dezvoltarea .NET în următoarele 12 luni.

Eterogenitatea IT: cea mai mare provocare pentru ALM

Pe scurt, multe organizații din industria IT consideră heterogenitatea ca singura alternativă, deoarece există multe avantaje de afaceri asociate cu aceasta. Foarte des, echipele de dezvoltare folosesc o varietate de instrumente care nu sunt concepute pentru a lucra împreună. Nu există un singur furnizor care furnizează instrumentele pentru toate acțiunile necesare în contextul unui proiect software. Mai mult decât atât, nu există un singur furnizor care să poată acoperi pe deplin cele trei domenii principale: suport și modernizare a sistemului vechi, extinderea și personalizarea pachetelor de aplicații și dezvoltarea de noi aplicații distribuite. Prin urmare, este foarte probabil ca organizațiile să continue să utilizeze instrumente de dezvoltare disparate în cadrul aceluiași proiect și în diferite domenii tehnologice. Din această cauză, cea mai mare provocare în implementarea ALM este eterogenitatea instrumentelor de dezvoltare. Ca o reamintire, ALM se străduiește să obțină predictibilitate și integritate în procesul de fabricație a software-ului prin măsurabilitate automată, aliniere și disciplină. Cu toate acestea, într-un mediu extrem de eterogen, aceste calități ale procesului de fabricare a software-ului sunt mult mai dificil de realizat.

Deoarece măsurabilitatea necesită colectarea de informații metrice din diferite instrumente și depozite de dezvoltare a aplicațiilor, nu există un standard universal acceptat pentru o astfel de colectare de date. Deoarece nu există o schemă comună de informații pentru toate instrumentele implicate în proces, devine, de asemenea, necesar să „normalizăm” valorile colectate și cumva să le comparăm în contextul anumitor proiecte.

Alinierea necesită urmărirea acțiunilor și a rezultatelor pe tot parcursul procesului, de la strategiile IT la modulele implementate. Acest grad de control este foarte dificil de realizat atunci când resursele și activitățile de proces sunt împrăștiate în instrumente și depozite diferite. Nu există instrumente standard care identifică, colectează, gestionează și utilizează automat informațiile de audit.

Disciplina necesită desfășurarea, acceptarea și controlul diferitelor procese generale pentru gestionarea producției de software. Acest lucru devine mult mai complex atunci când subprocesele curg ca „insule de proces” printre o varietate de instrumente de proces. Nu există un mecanism standard pentru a se asigura că astfel de subprocese sunt coregrafiate (în conformitate cu un proces de nivel superior) sau pentru implementarea componentelor procesului pentru aceste instrumente. De asemenea, nu există o terminologie unică pentru descrierea proceselor într-un mediu de instrumente disparate. Toți își folosesc propriile limbi pentru „obiecte”, „artefacte”, „proiecte” etc. Un alt aspect al disciplinei necesită schimbări semnificative în management și analiza impactului. Cu toate acestea, aceste capacități necesită implementarea corectă a controlului operațional de la un capăt la altul. După cum sa discutat, controlul end-to-end este mult mai dificil într-un mediu de dezvoltare eterogen.

Pentru a aborda aceste provocări, organizațiile care practică ALM deseori încetează să dezvolte numeroasele integrări specializate punct-la-punct care umple de obicei golurile tehnologice dintre diferitele instrumente de dezvoltare utilizate. Integrări ca acestea nu sunt fiabile. Se rup la actualizarea sau schimbarea instrumentelor și sunt costisitoare de construit și întreținut. În plus, acestea conduc la apariția proceselor software care nu pot fi ușor măsurate și controlate și care sunt incomode de gestionat. Evident, această abordare este inacceptabilă și nerentabilă.

Prin urmare, majoritatea organizațiilor IT prezintă provocări majore pentru furnizorii de ALM. Aceste organizații ar dori să obțină mai multă valoare de la ALM, și anume îmbunătățiri semnificative în procesul de producție a software-ului, care să le ofere stabilitatea și predictibilitatea de care au nevoie. Cu toate acestea, clienții ALM doresc și mai mult decât atât.

Capacitatea de a utiliza un amestec de platforme de lucru în cel mai optim mod în ceea ce privește obiectivele lor de afaceri.

Utilizarea gratuită a unei varietăți de instrumente de dezvoltare a aplicațiilor comerciale și open source optimizate pentru obiectivele lor de implementare dorite.

Utilizarea gratuită a unei varietăți de procese comerciale sau specializate de dezvoltare de software care sunt optimizate pentru cultura, tipurile de proiecte și tehnologia de bază a organizației.

Este necesară o nouă abordare a ALM pentru a îndeplini acest set complex de cerințe. O abordare care permite clienților să valorifice pe deplin puterea ALM într-un mediu IT eterogen. Borland și-a anunțat recent abordarea și strategia de produs denumită Open ALM. Această abordare are drept scop direct abordarea acestei probleme. Este singura soluție ALM concepută de la bază pentru a permite organizațiilor IT să livreze software în mod previzibil în cadrul propriei cronologii.

Depășirea eterogenității: frontiera finală a ALM

Abordarea Open ALM implementează viziunea stabilită a Borland și strategia de produs. Această abordare reprezintă o schimbare arhitecturală semnificativă, unică pe piața comercială ALM. De fapt, dacă este complet implementat, Borland Open ALM și aplicațiile sale asociate ar putea oferi beneficii semnificative chiar și clienților care nu folosesc deloc instrumente de dezvoltare a aplicațiilor Borland. Borland consideră, fără îndoială, afacerea sa cu instrumente ca fiind vitală. Compania va continua să le dezvolte și să ofere cele mai bune instrumente din clasă pentru o echipă extinsă de dezvoltare software. Instrumentele lui Borland vor evolua treptat pentru a sprijini strategia Open ALM. Acest lucru le-ar permite să participe la orchestrarea producției de software bazate pe Open ALM. Cu toate acestea, instrumentele Borland ar putea fi înlocuite, dacă clienții văd ideea, cu orice produs care să le susțină cerințele de dezvoltare. Poate fi un produs de la un furnizor terț sau open source. Acest nivel de modularitate și flexibilitate diferențiază strategia produsului Borland de alți furnizori de ALM, mulți dintre aceștia încercând să preia întregul lanț de aprovizionare cu software.

Beneficiile Open ALM

Open ALM oferă funcționalitatea ALM, oferind în același timp o flexibilitate de neegalat la nivel de proces, instrument și platformă. Mai exact, utilizatorii Open ALM beneficiază de următoarele caracteristici.

Libertatea de a alege orice combinație de platforme și medii de lucru în contextul unui proiect software sau pentru mai multe proiecte diferite simultan. În acest caz, alegerea se face pe baza priorităților de afaceri sau a adecvării proiectului.

Libertatea de a alege cele mai bune instrumente de dezvoltare pentru platformele alese pe baza considerentelor economice, a productivității sporite și a adecvării tehnice.

Libertatea de a alege sau de a proiecta procese de dezvoltare care se potrivesc cel mai bine proiectelor lor și platformelor alese, și, de asemenea, se potrivesc

cultura organizațională și cerințele privind timpul de introducere pe piață.

Pentru prima dată, Open ALM și instrumentele sale de asistență vor oferi organizațiilor IT care implementează medii eterogene de dezvoltare a aplicațiilor cu următoarele funcții.

O frumoasă imagine multidimensională și personalizabilă a progresului, calității și valorilor de risc ale proiectelor și portofoliilor pentru a sprijini managementul proiectelor și inițiativele de îmbunătățire a proceselor.

„Sfântul Graal”: control operațional complet și urmărirea ciclului de viață. Acest lucru va permite alinierea reală a obiectivelor și activităților de afaceri în timpul procesului de dezvoltare, va oferi o legătură mai bună între așteptările utilizatorilor finali și rezultatele proiectului și va oferi oportunități mai bune pentru managementul proiectului printr-o analiză de impact precisă și cuprinzătoare.

Un nou nivel de gestionare a procesului de dezvoltare software cu ajutorul coordonării automate a acțiunilor specialiștilor și instrumentelor implicate în ciclul de viață, bazat pe procese.

Aceste capabilități oferă o eficiență excelentă a echipei, susțin inițiative de îmbunătățire a calității și ușurează povara respectării reglementărilor interne și externe. Acestea vor fi livrate ca un set de componente de infrastructură și instrumente corporative de gestionare a ALM. În plus, clienții pot utiliza, de asemenea, cele mai bune instrumente integrate Borland pentru dezvoltarea aplicațiilor și gestionarea proiectelor. Acest lucru le va permite să câștige valoare în patru domenii principale de proces.

Managementul portofoliului de proiecte (PPM). Instrumente și procese automatizate pentru a gestiona dezvoltarea întregii strategii software, precum și pentru a gestiona execuția unui portofoliu de proiecte de dezvoltare software.

Definirea și gestionarea cerințelor (RDM).Un set de instrumente și cele mai bune practici care asigură că cerințele proiectului sunt exacte și complete, pot fi urmărite în mod eficient la obiectivele de afaceri și sunt acoperite în mod optim de testele software.

Managementul calității în ciclul de viață (Lifecycle Quality Management, LQM).Procedura și instrumentele pentru gestionarea definiției și măsurării calității la toate etapele dezvoltării software-ului. Aceste instrumente sunt concepute pentru a detecta și preveni problemele de calitate la începutul unui proiect, atunci când costul remedierii acestora este relativ scăzut. De asemenea, echipele de control al calității trebuie să se asigure că testele lor sunt complete și se bazează pe cerințele utilizatorului final.

Managementul schimbării (CM).Infrastructură și instrumente pentru a ajuta la prezicerea impactului schimbărilor. De asemenea, acestea ajută la gestionarea resurselor și a activităților de schimbare a ciclului de viață atât în \u200b\u200bmodelele cu mai multe noduri, cât și cu modelele cu un singur nod.

Soluția Borland Open ALM

După cum sa menționat, obiectivul principal al ALM este de a realiza un proces de dezvoltare software previzibil și gestionabil prin măsurabilitate automată, aliniere și disciplină. Am văzut că fiecare dintre cele trei dimensiuni ale ALM într-un mediu eterogen de dezvoltare a aplicațiilor devine mult mai dificil de implementat și, prin urmare, prezintă o serie de provocări specifice pentru utilizatorii ALM. Arhitectura platformei Borland Open ALM este un set de trei domenii de soluții, fiecare conceput special pentru a aborda provocările unuia dintre principalele domenii ALM. Fiecare zonă a soluției Open ALM se bazează pe un strat de infrastructură extrem de modular și extensibil și este un set de aplicații specializate. Scopul stratului de infrastructură este de a permite platformei Open ALM să funcționeze cu orice combinație de instrumente și procese de dezvoltare comercială sau open source, indiferent de furnizor sau de tehnologia de mediu așteptată. Diagrama de pe pagina următoare prezintă o diagramă conceptuală a soluției Borland ALM.

Borland Open ALM Solution Architecture

Deschideți Business Intelligence pentru ALM

Open Business Intelligence pentru ALM (OBI4ALM) se bazează pe infrastructură și aplicații standard pentru a crește măsurabilitatea progresului, pentru a îmbunătăți performanța sau orice altă metrică specială a proiectelor software într-un mediu eterogen de dezvoltare a aplicațiilor. OBI4ALM oferă infrastructura pentru colectarea discretă de date distribuite și cartografierea și analiza metrică de la orice instrument de dezvoltare a aplicațiilor înregistrat pentru a face acest lucru. Prin extragerea valorilor predefinite din sursele de date, cadrul OBI4ALM reunește informații disparate împrăștiate pe tot parcursul ciclului de dezvoltare software. Această consolidare oferă oportunități excelente. De exemplu, puteți crea o vizualizare agregată a valorilor de proiect și definiți valori de proiect noi care combină mai multe valori de nivel inferior. Infrastructura OBI4ALM utilizează un depozit de date. Acest depozit conține informații curente și istorice colectate din acele instrumente care sunt implicate în diferite etape ale procesului de dezvoltare software. Folosește o structură care este optimizată pentru interogarea și analiza datelor. Aplicațiile OBI4ALM pot transforma valorile colectate în informații utile pentru luarea deciziilor pe baza acesteia. Aceasta oferă asistență pentru luarea deciziilor și notificarea timpurie a problemelor.

Tablourile de bord în timp real sunt vizualizări KPI personalizabile care arată tendințele în timp.

Alertele bazate pe valori sunt alerte personalizate care sunt declanșate atunci când apar anumite condiții (de exemplu, atunci când o tendință trece o anumită limită). Alertele ajută la îmbunătățirea flexibilității de gestionare pentru o varietate de probleme ale proiectului: progres lent, calitate slabă, performanță insuficientă sau orice altă problemă care poate fi cuantificată utilizând valori.

Instrumentele de luare a deciziilor sunt instrumente analitice care utilizează informații istorice despre un proiect (sau mai multe proiecte) pentru a facilita luarea deciziilor despre managementul proiectului.

Deschideți controlul procesului pentru ALM

În analiza finală, procesul devine cel mai important concept care pătrunde întregul ciclu de viață al software-ului. Un proces este mai mult decât partajarea structurilor de informații cu instrumente utilizate de diferite roluri sau furnizarea integrării capabilităților la nivelul interfeței cu utilizatorul. Procesul are un potențial real de coordonare a acțiunilor oamenilor și sistemelor implicate în procesul de creare a software-ului. În același timp, procesul asigură respectarea politicilor stabilite și controlul calității implementării.

Gestionarea proceselor deschise pentru ALM (OPM4ALM) oferă componente de infrastructură și un set de aplicații care sunt utilizate pentru modelarea, implementarea și implementarea diferitelor procese software într-un mediu eterogen de dezvoltare a aplicațiilor. OPM4ALM merge mult mai departe decât să ofere leadership și să atribuie sarcini părților interesate. Această metodă folosește, de asemenea, un strat de automatizare a proceselor care servește drept adeziv principal pentru integrarea partea clientului, a serverului și a metodologiei conform regulilor cuprinse în modelele de proces. Din acest punct de vedere, integrarea între instrumentele de dezvoltare a aplicațiilor este de fapt asigurată de procese de nivel inferior. Aceasta devine baza fundamentală pentru o muncă de echipă eficientă.

Infrastructura OPM4ALM este construită pe un nucleu de proces distribuit. Oferă modelare, personalizare, implementare, orchestrare și coregrafie a mai multor procese de dezvoltare software într-un mediu de dezvoltare eterogen. O parte importantă a infrastructurii OPM4ALM este gestionarea și definirea evenimentelor de proces. Instrumentele ALM deschise se pot abona și asculta la aceste evenimente și pot fi notificate când apar. Motorul de proces oferă, de asemenea, o definiție flexibilă și o evaluare a regulilor. Ajută la descrierea și aplicarea politicilor de dezvoltare a aplicațiilor.

Aplicațiile OPM4ALM oferă valoare din stratul de infrastructură de proces. Acestea oferă următoarele funcții.

Instrumente pentru modelarea, reglarea, montarea și refolosirea proceselor. Acestea permit proiectarea eficientă a proceselor software comerciale sau personalizate utilizând un model de dezvoltare software bogat în caracteristici.

Enterprise Processes Console, care oferă o vedere consolidată. Această vizualizare conține toate procesele software care sunt desfășurate în diferite proiecte, cu participarea unor instrumente de dezvoltare disparate.

Bara de instrumente de evaluare a conformității procesului. Acesta arată abaterile de proces și consecințele lor potențiale și oferă capacități de raportare utile pentru implementarea inițiativelor de conformitate.

Măsurarea și raportarea pe baza valorilor specifice pentru fiecare proces.

Control deschis pentru ALM

Controlul procesului de la un capăt la celălalt suportă multe dintre beneficiile importante ale ALM. Unele dintre acestea sunt: \u200b\u200bEste un instrument esențial pentru implementarea dezvoltării bazate pe cerințele afacerii, a dezvoltării și testării bazate pe cerințe și a analizei exacte a impactului schimbărilor. Trasabilitatea deschisă pentru ALM (OT4ALM) oferă o infrastructură pentru crearea și clasificarea legăturilor între resursele create în timpul dezvoltării software-ului. De asemenea, creează un program flexibil pentru conectarea resurselor conexe. Nu contează în ce instrumente sunt localizate aceste resurse. Această tehnologie oferă, de asemenea, un mijloc pentru navigarea în diagrama relațiilor dintre resurse, precum și pentru crearea de interogări optime și pentru extragerea datelor pe care le conține această diagramă.

OT4ALM oferă aplicații care convertesc datele de control colectate în informații pentru luarea deciziilor.

Planificare automată, analiză a impactului modificărilor, costuri exacte și previziuni bugetare.

Controlul limitelor - avertizare timpurie a abaterilor de la limitele definite (de exemplu, resurse care nu îndeplinesc cerințele) și cerințele neîndeplinite.

Reuse Analyzer - Vă permite să reutilizați copaci întregi de resurse (de la cerințe și modele la cod și teste) în loc să refolosiți pur și simplu modulele de cod.

TraceView - Vizualizatoare interactive de urmărire pentru diverse proiecte. Acest lucru vă ajută să găsiți toate resursele proceselor și să le comparați cu alte resurse.

Infrastructură comună a platformei

Infrastructura Open ALM conține două componente care sunt utilizate în toate domeniile soluției.

ALM metamodel.Un limbaj comun pentru descrierea proceselor software, a relațiilor dintre resursele procesului (controlabilitate) și unitățile de măsură (metrici). Metamodelul ALM oferă un model conceptual bogat în caracteristici pentru domeniul dezvoltării software-ului. Aceasta este pentru a descrie un vocabular standard pe care trebuie să îl înțeleagă toate instrumentele compatibile Open ALM. Această înțelegere va asigura o comunicare eficientă în cadrul platformei Open ALM.

Strat de integrare ALM.Motor de integrare extensibil și încorporabil și SDK. Acesta definește o modalitate standard pentru ca instrumentele ALM să funcționeze, să colecteze valori ALM și să creeze diagrame pentru a monitoriza resursele. Pentru a susține și a participa la platforma ALM, instrumentul trebuie să furnizeze un plugin pentru platformă care să satisfacă API-ul Open ALM standard. De asemenea, puteți utiliza un adaptor personalizat care conectează instrumentul la restul mediilor de dezvoltare a aplicațiilor prin procese orchestrate de platforma Open ALM.

Drumul către Open ALM

În următoarele 24 de luni, Borland va continua să extindă infrastructura, aplicațiile și instrumentele care alcătuiesc platforma Open ALM. Borland intenționează, de asemenea, să completeze acest produs cu o gamă largă de programe de servicii profesionale concepute pentru a accelera implementarea și pentru a asigura succesul implementărilor de întreprindere ale Open ALM. Clienții pot profita astăzi de unele dintre beneficiile Open ALM. Organizațiilor care doresc să îmbunătățească calitatea și să-și îmbunătățească schimbarea și gestionarea proiectelor vor găsi soluția actuală a Borland foarte atractivă. Această soluție oferă suport extrem de automatizat și integrat pentru patru domenii importante ale proceselor de dezvoltare a aplicațiilor:

Managementul portofoliului de proiecte (PPM);

Definirea și gestionarea cerințelor (RDM);

Managementul ciclului de viață al aplicațiilor (LQM);

Managementul schimbării (CM).

Aceste soluții sunt livrate printr-o integrare strânsă între produsele Borland și instrumentele de la terți. Acest lucru oferă clienților flexibilitatea de care au nevoie și își mărește dramatic capacitățile de gestionare a proiectelor software de astăzi.

De ce Borland?

De-a lungul istoriei sale îndelungate, Borland a lucrat în mod constant cu clienții săi pentru a se asigura că aceștia creează software în cel mai convenabil mod. Borland este angajat în dezvoltarea bazată pe standarde și în sprijinul pe mai multe platforme. Ea a oferit organizațiilor IT flexibilitatea și libertatea de alegere de care au nevoie. Odată cu apariția Open ALM, Borland își duce valorile tradiționale la un nivel cu totul nou. Acest lucru diferențiază în mod clar compania de alți furnizori ALM și de inițiativele ALM non-profit.

Pentru cei mai mari furnizori de ALM, IBM Rational și Microsoft, serviciul pentru clienți este cu greu prioritatea lor principală. Ambele companii încearcă continuu să își valorifice instrumentele de dezvoltare pentru a lega clienții de platformele lor de middleware și de gestionare a sistemelor.

Spre deosebire de această abordare, Borland a insistat întotdeauna să susțină standardele Java și J2EE și a oferit suport puternic și integrat pentru platformă, limbaje și instrumente de dezvoltare. Microsoft... Borland continuă să extindă în mod explicit soluția ALM a Microsoft. Borland a investit mult în sprijinirea celor mai noi tehnologii Microsoft. De exemplu, CaliberRM, prima soluție de gestionare a cerințelor complet integrată pentru Team System, este recomandată de Microsoft pentru a extinde funcționalitatea de gestionare a cerințelor de bază oferită de instrumentul VSTS. Borland va continua să extindă interoperabilitatea platformelor Java și .NET. Sunt planificate capacități suplimentare, cum ar fi generarea de cod de la UML la C # și suport pentru limbaje specifice domeniului Microsoft (alternativa Microsoft la înlocuirea UML).

Trecerea către open source este, de asemenea, asociată cu provocările pe care heterogenitatea le pune pentru ALM. Scopul mai multor inițiative Eclipse (Application Lifecycle Framework (ALF), Corona și Eclipse Process Framework (EPF)) este similar cu obiectivele Borland Open ALM. În timp ce Borland înțelege motivațiile din spatele acestor proiecte, compania consideră că abordarea lor este insuficientă. Atât ALF, cât și Corona încearcă să furnizeze numai componente de infrastructură Open ALM. Cu toate acestea, Open ALM este o abordare mai holistică. Această abordare permite, de asemenea, clienților să obțină valoarea afacerii din infrastructuri de tip raft printr-o suită de aplicații complementare. Borland merge mai departe decât alți furnizori de ALM în mișcarea sa către Open ALM. Compania și-a extins recent orizonturile și dorește să se extindă la domenii suplimentare de dezvoltare a aplicațiilor. Borland caută, de asemenea, cea mai bună abordare pentru a sprijini proiecte de dezvoltare de aplicații ambalate pe platformele SAP NetWeaver și Oracle Fusion.

Concluzie

Borland este unic în a ajuta utilizatorii ALM să creeze software în propria cronologie. Abordarea Open ALM și strategia de produs diferențiază în mod clar Borland de alți furnizori de ALM și de inițiativele open source. Borland este singurul furnizor major de ALM care recunoaște direct realitatea eterogenității IT. Compania încearcă să ajute utilizatorii ALM să folosească instrumentele existente în procesele, mediile și instrumentele de dezvoltare. Abordarea Borland față de integrarea bazată pe procese separă și mai mult compania de concurenții săi. Acest lucru permite Borland să ofere transparență, control și ordine pe tot parcursul strategiei ALM.

Borland începe să construiască infrastructură, aplicații și instrumente de dezvoltare aferente pentru Open ALM. Prin urmare, pentru prima dată, clienții vor putea utiliza pe deplin capacitățile ALM. Ei vor putea profita de un proces de dezvoltare software complet coeziv, gestionabil și măsurabil.

Analizând dezvoltarea pieței instrumentelor de dezvoltare în ultimii 10-15 ani, se poate observa o tendință generală de schimbare a accentului de la tehnologiile de scriere a programelor (care de la începutul anilor 90 au fost marcate de apariția Unelte RAD - „dezvoltarea rapidă a aplicațiilor”) la nevoia unui sistem integrat gestionarea întregului ciclu de viață al aplicațiilor - ALM (Application Lifecycle Management) .

Pe măsură ce complexitatea proiectelor software crește, cerințele pentru eficiența implementării lor cresc brusc. Acest lucru este cu atât mai important astăzi, când dezvoltatorii de software sunt implicați în aproape toate aspectele operațiunilor întreprinderii și numărul acestor specialiști este în creștere. În același timp, datele de cercetare din acest domeniu sugerează că rezultatele a cel puțin jumătate din proiectele de dezvoltare software „interne” nu sunt la înălțimea așteptărilor lor. În aceste condiții, sarcina de a optimiza întregul proces de creare a instrumentelor software devine deosebit de urgentă, acoperind toți participanții săi - designeri, dezvoltatori, testeri, servicii de asistență și manageri. Managementul ciclului de viață al aplicației (ALM) consideră procesul de lansare a software-ului ca un ciclu mereu repetat de etape corelate:

· Definirea cerințelor (Cerințe);

· Proiectare și analiză (Design & Analysis);

· Dezvoltare (Dezvoltare);

· Testare (Testare);

· Implementare și întreținere (Implementare și operațiuni).

Fiecare dintre aceste etape trebuie monitorizată și controlată cu atenție. Un sistem ALM organizat corespunzător vă permite să:

· Pentru a reduce timpul de lansare a produselor pe piață (dezvoltatorii trebuie să se îngrijoreze doar de conformitatea programelor lor cu cerințele formulate);

· Îmbunătățiți calitatea, asigurându-vă în același timp că aplicația va satisface nevoile și așteptările utilizatorilor;

· Creșterea productivității muncii (dezvoltatorii au posibilitatea de a împărtăși cele mai bune practici în dezvoltare și implementare);

· Accelerează dezvoltarea prin integrarea instrumentelor;

· Reduceți costurile de întreținere prin menținerea constantă a coerenței între aplicație și documentația de proiectare a acesteia;

· Profitați la maximum de investițiile dvs. în abilități, procese și tehnologie.

Strict vorbind, însăși conceptul ALM, desigur, nu este ceva fundamental nou - această înțelegere a problemelor dezvoltării software-ului a apărut acum patruzeci de ani, în zorii formării metodelor de dezvoltare industrială. Cu toate acestea, până relativ recent, principalele eforturi de automatizare a sarcinilor de dezvoltare software au vizat crearea de instrumente direct pentru programare ca etapă care consumă mult timp. Și abia în anii 80, datorită complicației proiectelor software, situația a început să se schimbe semnificativ. În același timp, relevanța extinderii funcționalității instrumentelor de dezvoltare (în sensul larg al acestui termen) în două domenii principale a crescut brusc: 1) automatizarea tuturor celorlalte etape ale ciclului de viață al software-ului și 2) integrarea instrumentelor între ele.

Multe companii au fost implicate în aceste sarcini, dar liderul incontestabil aici a fost compania Rational, care de mai bine de douăzeci de ani, de la înființare, s-a specializat în automatizarea proceselor de dezvoltare software. La un moment dat, ea a devenit una dintre pionierii utilizării pe scară largă a metodelor vizuale pentru proiectarea programelor (și practic autorul UML, care a fost de facto acceptat ca standard în acest domeniu), a creat o metodologie generală ALM și un set corespunzător de instrumente. Putem spune că la începutul acestui secol, Rational era singura companie care avea în arsenalul său întreaga gamă de produse pentru a sprijini ALM (de la proiectarea afacerii până la întreținere), cu excepția, totuși, a unei clase de instrumente - instrumentele de codare convenționale. Cu toate acestea, în februarie 2003, a încetat să mai existe ca organizație independentă și a devenit o divizie a corporației IBM, numită IBM Rational.

Până de curând, Rational era practic singurul producător de instrumente complexe de dezvoltare pentru clasa ALM, deși existau și există instrumente concurente de la alți furnizori pentru anumite etape de dezvoltare software. Cu toate acestea, în urmă cu câțiva ani, Borland Corporation și-a anunțat public intenția de a concura cu aceasta, care a avut întotdeauna o poziție puternică doar în domeniul instrumentelor tradiționale de dezvoltare a aplicațiilor (Delphi, JBuilder etc.), care sunt de fapt baza complexului ALM al corporației, a cărui extindere a trecut prin achiziție. alte companii care produc produse similare. Aceasta este diferența fundamentală între modelele de afaceri ale celor două companii, ceea ce deschide oportunități potențiale pentru o concurență reală. După ce Rational a devenit parte a IBM, Borland se poziționează ca singurul furnizor independent al unei platforme ALM integrate astăzi (adică nu își promovează propriile sisteme de operare, limbi, etc.). La rândul lor, concurenții observă că Borland nu a formulat încă o metodologie clară ALM care oferă o bază pentru combinarea instrumentelor sale existente.

Un alt jucător important în domeniul instrumentelor de dezvoltare este Microsoft. Până în prezent, ea nu își propune să își creeze propria platformă ALM; progresul în această direcție se face doar în cadrul cooperării cu alți furnizori, același Rational și Borland (amândoi au devenit primii participanți la programul Visual Studio Industry Partner). În același timp, instrumentul principal de dezvoltare Microsoft, Visual Studio .NET, își extinde în mod constant funcționalitatea prin utilizarea instrumentelor de modelare la nivel înalt și de gestionare a proiectelor, inclusiv integrarea cu Microsoft Visio și Microsoft Project.

Trebuie remarcat faptul că astăzi aproape toate companiile de vârf - dezvoltatorii de tehnologii și produse software (cu excepția celor enumerate mai sus, se poate numi Oracle, Computer Associates etc.) au dezvoltat tehnologii pentru crearea de software, care au fost create atât pe cont propriu, cât și prin achiziționarea de produse și tehnologii create de companii mici, specializate. Și, deși, la fel ca Microsoft, nu au planificat încă să creeze propria lor platformă ALM, instrumentele CASE produse de aceste companii sunt utilizate pe scară largă în anumite etape ale ciclului de viață al software-ului.

Sistemele ALM vă permit să oferiți transparență, o înțelegere clară a procesului de dezvoltare a aplicațiilor și să îl prezentați ca unul dintre procesele de afaceri. Cu toate acestea, ALM nu ar trebui privit doar ca un instrument pentru monitorizarea și aplicarea conformității, avertizează analiștii. Aceste sisteme sunt concepute nu atât pentru control, cât pentru automatizarea procesului de dezvoltare și integrarea diferitelor instrumente.

Cea mai mare provocare în implementarea instrumentelor ALM este neînțelegerea oamenilor cu privire la procesul de dezvoltare. Adesea, conducerea consideră că ALM poate fi folosit pentru a face lucrurile într-un mod bine definit. Cu toate acestea, este imposibil să planifici totul în avans. În dezvoltarea aplicației, trebuie să parcurgeți adesea mai multe iterații la fiecare pas, să eliberați versiuni intermediare și să măriți treptat funcționalitatea aplicației. Sistemul ALM nu ar trebui să restricționeze acțiunile dezvoltatorilor, ci să faciliteze procesul.

Industria IT adoră să vorbească despre barierele dintre IT și afaceri, dar în cadrul structurii IT în sine, există multe bariere mai puțin vizibile care pot sta în calea unui integrator de sisteme neatent.

Luați în considerare, de exemplu, unul dintre cele mai controversate și mai dezbătute subiecte din IT în prezent - metodologia DevOps și tot ceea ce este legat de aceasta. Ca o scurtă descriere a tuturor acțiunilor legate de transferul aplicației dezvoltate către serviciul IT pentru operare reală, aceste cuvinte sună destul de inofensive. În general, există un perete de confuzie între dezvoltatorii de aplicații pentru întreprinderi și specialiștii care gestionează infrastructura IT a întreprinderii. Programatorii dau vina pe IT pentru lipsa de flexibilitate, iar cei care gestionează operațiunile IT de zi cu zi dau vina pe IT pentru ignorarea constrângerilor și cerințelor infrastructurii de producție în care trebuie să ruleze aplicațiile pe care le creează.

Această tensiune generează un interes tot mai mare pentru tehnologia Application Lifecycle Management (ALM), care este un set de instrumente de management concepute pentru a oferi programatorilor și personalului IT o înțelegere mai clară a aplicației în curs de dezvoltare și a infrastructurii în care trebuie să ruleze aplicația. ... Ideea principală este că facilitarea colaborării dintre dezvoltatori și profesioniștii IT va duce la o funcționare mai eficientă a întregului mediu informațional corporativ. Problema este că implementarea ALM are puține șanse într-o situație în care cele două părți, a căror cooperare este necesară pentru a asigura succesul proiectului, încep să își schimbe responsabilitatea pentru dificultățile care apar.

Pentru a implementa cu succes metodologia ALM, integratorul de sistem trebuie să se ridice peste nivelul acuzațiilor reciproce din departamentul IT. Potrivit Gina Poole, vicepreședinte de marketing pentru IBM Rational Software, aceasta înseamnă găsirea și angajarea unui CIO sau director financiar care poate înțelege câți bani pierde un client din cauza lipsei de coordonare în departamentul IT. Remedierea erorilor într-o aplicație târziu în proiectul de dezvoltare înseamnă costuri extrem de mari. Dacă necesitatea unei astfel de remedieri este cauzată de ipotezele anterioare ale dezvoltatorului cu privire la mediul în care va funcționa aplicația și aceste ipoteze sunt în cele din urmă incorecte, atunci costul întregului proiect crește semnificativ sau clientul va fi obligat să-și modernizeze infrastructura în consecință.

Desigur, poate fi nevoie de o sumă semnificativă de bani pentru a rezolva astfel de conflicte în infrastructura IT a unei organizații. Cu toate acestea, singurul obiectiv final al acestei lucrări ar trebui să fie crearea și implementarea unui set de tehnologii de gestionare care să permită programatorilor și operațiunilor IT să nu mai interfereze cu munca celuilalt. Cu cât programatorii petrec mai mult timp discutând colaborarea cu profesioniștii din IT, cu atât au mai puțin timp la dispoziție direct pentru dezvoltare. Cu cât sunt create mai multe aplicații, cu atât va fi necesară o infrastructură mai dezvoltată și aceasta este, desigur, o veste bună pentru revânzători.

În general, dezbaterea DevOps este cu siguranță benefică pentru revânzători și integratori. Problema nu este să te prinzi în conflicte interne asociate cu dorința de a realiza prea multe proiecte IT în paralel. Dacă clientul nu acceptă însăși conceptul ALM, acesta este de fapt un indicator foarte bun al lipsei sale de maturitate și a competenței slabe în managementul IT. Acest lucru sugerează în sine că revânzătorul este mai bine să stea departe de un astfel de client, deoarece sunt mari șanse ca un astfel de client să aducă mult mai multe probleme decât profit.

Se știe că mulți utilizatori (și, sincer să fiu, unii specialiști IT), atunci când vorbesc despre dezvoltarea de software, înseamnă în primul rând crearea și depanarea codului aplicației. A fost un moment în care astfel de idei s-au dovedit a fi suficient de apropiate de adevăr. Dar dezvoltarea modernă a aplicațiilor constă nu numai și nu atât din scrierea codului, cât și din alte procese, atât înaintea programării, cât și în urma acestuia. De fapt, vom vorbi despre ele mai departe.

Ciclul de viață al dezvoltării aplicațiilor: Visele și realitatea

nu este un secret faptul că multe produse de succes comercial atât în \u200b\u200bRusia, cât și în străinătate au fost implementate folosind doar instrumente de dezvoltare a aplicațiilor și chiar și datele au fost deseori concepute pe hârtie. Nu va fi o exagerare să spunem că dintre toate instrumentele posibile pentru crearea de software în Rusia (și în multe țări europene), instrumentele de dezvoltare a aplicațiilor sunt acum populare și, într-o oarecare măsură mai mică, instrumentele de proiectare a datelor (în primul rând, acest lucru se referă la proiecte cu un buget redus și termenii de implementare). Toată documentația proiectului, de la atribuirea tehnică până la manualul utilizatorului, este creată folosind editori de text, iar faptul că o parte din aceasta reprezintă informațiile sursă pentru programator înseamnă doar că îl citește pur și simplu. Și asta în ciuda faptului că, pe de o parte, instrumentele de gestionare a cerințelor, modelarea proceselor de afaceri, instrumentele de testare a aplicațiilor, instrumentele de gestionare a proiectelor și chiar instrumentele pentru generarea documentației de proiect au existat de mult timp și, pe de altă parte, orice manager de proiect dorește în mod natural să faciliteze viață pentru tine și pentru restul interpreților.

Care este motivul neîncrederii multor manageri de proiect în instrumentele care permit automatizarea multor etape ale muncii echipelor pe care le conduc? În opinia mea, există mai multe motive pentru aceasta. Primul este că instrumentele folosite de companie nu se integrează foarte bine între ele. Să luăm în considerare un exemplu tipic: Rational Rose este utilizat pentru modelare, Delphi Professional este utilizat pentru codificare, CA AllFusion Modeling Suite este utilizat pentru proiectarea datelor; instrumentele de integrare pentru aceste produse sunt fie complet absente pentru o combinație dată a versiunilor lor, fie nu funcționează corect cu limba rusă, fie pur și simplu nu sunt achiziționate. Drept urmare, diagramele de caz de utilizare și alte modele create cu Rose nu devin altceva decât imagini în documentația de proiectare, iar modelul de date servește în principal ca sursă de răspunsuri la întrebări precum: „De ce este acest câmp în acel tabel? Și chiar și astfel de părți simple ale aplicației precum echivalentele rusești ale numelor de câmpuri ale bazei de date sunt scrise de participanții la proiect de cel puțin trei ori: o dată când se documentează modelul de date sau aplicația, a doua oară când se scrie codul interfeței utilizator și a treia oară când se creează un fișier de ajutor. și manuale de utilizare.

Al doilea motiv, nu mai puțin serios, pentru neîncrederea în instrumentele de asistență pentru ciclul de viață al software-ului este că, din nou, din cauza absenței sau funcționalității slabe a instrumentelor de integrare pentru astfel de produse, în multe cazuri este posibil să nu fie posibilă sincronizarea continuă a tuturor părților proiectului între ele: modele de proces , modele de date, codul aplicației, structura bazei de date. Este clar că un proiect care implementează schema clasică a unei cascade (Fig. 1), în care sunt formulate mai întâi cerințele, apoi se realizează modelarea și proiectarea, apoi dezvoltarea și, în cele din urmă, implementarea (puteți citi despre această schemă și alte metodologii de implementare a proiectului în seria de recenzii de Lilia Hough, publicat în revista noastră) este mai mult un vis decât o realitate - în timp ce codul este scris, clientul va avea timp să schimbe unele dintre procese sau să dorească funcționalități suplimentare. Ca rezultat al execuției proiectului, se obține adesea o aplicație care este foarte departe de ceea ce a fost descris în termenii de referință și o bază de date care are puțin în comun cu modelul original, iar sincronizarea tuturor acestora între ele în scopul documentării și transferului către client se transformă într-o sarcină destul de laborioasă.

Al treilea motiv pentru care suportul pentru ciclul de viață al software-ului nu este utilizat oriunde ar putea fi util este pentru că are o alegere extrem de limitată. În principal, două linii de produse sunt promovate activ pe piața rusă: instrumentele IBM / Rational și instrumentele Computer Associates (în principal linia de produse AllFusion Modeling Suite), care sunt în prezent concentrate în mare parte pe anumite tipuri de modelare și nu pe procesul constant de sincronizare a codului, bazele de date și modele.

Există încă un motiv care poate fi atribuit categoriei factorilor psihologici: există dezvoltatori care nu se străduiesc deloc să-și formalizeze și să documenteze complet cererile - la urma urmei, în acest caz, devin angajați de neînlocuit și valoroși și o persoană care este forțată să înțeleagă după demiterea unui astfel de dezvoltator în codul său, sau doar produsul însoțitor, se va simți ca un idiot complet pentru o perioadă foarte lungă de timp. Astfel de dezvoltatori, desigur, nu sunt în niciun caz majoritari, totuși, știu cel puțin cinci directori de companii care au fost răsfățați de astfel de foști angajați cu mult sânge.

Desigur, mulți manageri de proiecte, în special proiecte cu un buget redus și perioade limitate de timp, ar dori să aibă un instrument cu ajutorul căruia să poată formula cerințele pentru produsul software care se dezvoltă ... și, ca rezultat, să obțină o distribuție gata făcută a unei aplicații de lucru. Acesta, desigur, este doar un ideal, la care până acum se poate doar visa. Dar dacă coborâți din cer pe pământ, puteți formula dorințe mai specifice, și anume:

1. Instrumentele de gestionare a cerințelor ar trebui să simplifice crearea modelului de aplicație și a modelului de date.

2. Pe baza acestor modele, ar trebui generată o parte semnificativă a codului (de preferință nu numai client, ci și cod server).

3. O parte semnificativă a documentației ar trebui să fie generată automat și în limba țării pentru care este destinată această aplicație.

4. Când creați codul aplicației în modele, ar trebui să apară modificări automate, iar când modelul se modifică, ar trebui să existe generarea automată de cod.

5. Codul scris manual nu trebuie să dispară atunci când modelul se schimbă.

6. Apariția unei noi cerințe a clienților nu ar trebui să cauzeze probleme serioase asociate cu modificări ale modelelor, codului, bazei de date și documentației; cu toate acestea, toate modificările trebuie făcute sincron.

7. Instrumentele de control al versiunilor pentru toate cele de mai sus ar trebui să fie convenabile în ceea ce privește găsirea și urmărirea modificărilor.

8. În cele din urmă, toate aceste date (cerințe, cod, modele, documentație) ar trebui să fie disponibile participanților la proiect în măsura în care au nevoie de aceștia pentru a-și îndeplini responsabilitățile - nici mai mult, nici mai puțin.

Cu alte cuvinte, ciclul de dezvoltare a aplicațiilor ar trebui să permită dezvoltarea colaborativă iterativă fără costul adăugat al schimbării cerințelor clienților sau a modului în care acestea sunt implementate.

Nu vă voi asigura că toate aceste dorințe sunt absolut imposibil de îndeplinit cu ajutorul instrumentelor IBM / Rational sau CA - se dezvoltă tehnologii, apar noi produse și ceea ce era imposibil astăzi va deveni disponibil mâine. Dar, după cum arată practica, integrarea acestor instrumente cu cele mai populare instrumente de dezvoltare, din păcate, este încă departe de a fi la fel de ideală pe cât ar putea părea la prima vedere.

Produsele Borland din perspectiva managerului de proiect

borland este unul dintre cele mai populare instrumente pentru dezvoltatori din lume și se bucură de o binemeritată dragoste pentru dezvoltatori timp de douăzeci de ani. Până de curând, această companie oferea în principal o gamă largă de instrumente destinate direct dezvoltatorilor de coduri de aplicații - Delphi, JBuilder, C ++ Builder, Kylix (despre aceste produse am scris de mai multe ori). Cu toate acestea, succesul unei companii pe piață este în mare măsură determinat de cât de bine urmărește tendințele dezvoltării sale și de cât de mult înțelege nevoile celor care sunt consumatori ai produselor sale (în acest caz, companiile și departamentele specializate în dezvoltarea aplicațiilor).

Acesta este motivul pentru care strategia de dezvoltare a Borland pentru instrumentele de dezvoltare include acum suport pentru gestionarea completă a ciclului de viață al aplicațiilor (ALM), care include definirea cerințelor, proiectarea, dezvoltarea, testarea, implementarea și întreținerea aplicațiilor. Acest lucru este dovedit de achiziția de anul trecut de către Borland a mai multor companii - BoldSoft MDE Aktiebolag (un furnizor de vârf al celei mai recente tehnologii de dezvoltare a aplicațiilor Model Driven Architecture), Starbase (un furnizor de instrumente de gestionare a configurației software), TogetherSoft Corporation (un furnizor de soluții de proiectare software). De la achiziționarea acestor companii, s-a făcut multă muncă în ceea ce privește integrarea acestor produse între ele. Ca rezultat, aceste produse satisfac deja nevoile managerilor de proiect pentru capacitatea de a organiza dezvoltarea iterativă colaborativă. Mai jos vom discuta despre ceea ce Borland oferă în prezent directorilor și altor participanți la proiectele de dezvoltare software (multe dintre produsele și tehnologiile de integrare descrise mai jos au fost prezentate de companie la conferințele pentru dezvoltatori desfășurate în noiembrie la San Jose, Amsterdam și Moscova) ...

Managementul cerințelor

Managementul cerințelor este una dintre cele mai importante părți ale procesului de dezvoltare. Fără cerințe formulate, de regulă, este practic imposibil fie să organizezi munca la un proiect în mod normal, fie să înțelegi dacă clientul dorea cu adevărat să obțină exact ceea ce a fost implementat.

Potrivit analiștilor, cel puțin 30% din bugetul proiectului este cheltuit pentru ceea ce se numește refacerea aplicației (și personal cred că această cifră este foarte subestimată). Mai mult, peste 80% din această lucrare este asociată cu cerințe formulate incorect sau inexact, iar remedierea unor astfel de defecte este de obicei destul de costisitoare. Și măsura în care clienților le place să schimbe cerințele atunci când aplicația este aproape gata este probabil cunoscută de toți managerii de proiect ... Din acest motiv, managementului cerințelor ar trebui să li se acorde cea mai mare atenție.

Pentru gestionarea cerințelor, arsenalul Borland include Borland CaliberRM, care este în esență o platformă pentru automatizarea procesului de gestionare a cerințelor și furnizarea urmăririi schimbărilor (Figura 2).

CaliberRM se integrează cu multe instrumente de dezvoltare atât de la Borland, cât și de la alți producători (de exemplu, Microsoft), până la încorporarea unei liste de cerințe în mediul de dezvoltare și generarea de fragmente de cod atunci când trageți o pictogramă de cerință în editorul de cod. În plus, vă puteți crea propriile soluții pe baza acestuia - pentru aceasta există un set special de instrumente CaliberRM SDK.

Rețineți că acest produs este utilizat pentru a gestiona cerințele nu numai pentru software, ci și pentru alte produse. De exemplu, există cazuri de aplicare cu succes în industria auto pentru a gestiona cerințele pentru diferite componente ale vehiculului (inclusiv vehiculele Jaguar). În plus, potrivit lui Jon Harrison, manager de linie de produse pentru JBuilder, utilizarea CaliberRM pentru a crea Borland JBuilderX a simplificat mult procesul de dezvoltare pentru acest produs.

În cele din urmă, disponibilitatea unui instrument convenabil de gestionare a cerințelor simplifică în mare măsură crearea documentației proiectului, nu numai în primele etape ale unui proiect, ci și în toate etapele ulterioare.

Aplicarea și proiectarea datelor

Proiectarea este o parte la fel de importantă în crearea unei aplicații și ar trebui să se bazeze pe cerințele declarate. Rezultatul designului este modelele utilizate de programatori în etapa de creare a codului.

Pentru proiectarea aplicațiilor și a datelor, Borland oferă Borland Together (Figura 3), o platformă de analiză și proiectare a aplicațiilor care se integrează cu o varietate de instrumente de dezvoltare Borland și non-Borland (Microsoft în special). Produsul specificat permite modelarea și proiectarea aplicațiilor și a datelor; în același timp, gradul de integrare a acestuia cu instrumentele de dezvoltare în acest moment este de așa natură încât modificările modelului de date conduc la modificări automate ale codului aplicației, precum și modificările codului conduc la modificări ale modelelor (această tehnologie de integrare a instrumentelor de modelare și a instrumentelor de dezvoltare se numește LiveSource).

Borland Together poate fi utilizat ca instrument pentru integrarea sarcinilor de gestionare și modelare a cerințelor cu sarcinile de dezvoltare și testare și vă permite să înțelegeți care ar trebui să fie cerințele produsului.

Generarea codului aplicației

Scrierea codului aplicației este o zonă în care Borland s-a specializat de peste 20 de ani. Borland realizează astăzi instrumente de dezvoltare pentru Windows, Linux, Solaris, Microsoft .NET și o gamă largă de platforme mobile. Am scris deja despre instrumentele de dezvoltare ale acestei companii de multe ori și nu ne vom repeta în acest articol. Reținem doar că cele mai recente versiuni ale instrumentelor de dezvoltare ale acestei companii (Borland C # Builder, Borland C ++ BuilderX, Borland JBuilderX), precum și noua versiune așteptată în curând a unuia dintre cele mai populare instrumente de dezvoltare din țara noastră, Borland Delphi 8 pentru Microsoft .NET Framework permit integrarea strânsă a instrumentelor de modelare Together și a instrumentelor de gestionare a cerințelor CaliberRM cu mediile lor de dezvoltare. Cu siguranță vom vorbi despre Delphi 8 într-un articol separat în numărul următor al revistei noastre.

Testare și optimizare

Testarea este o parte absolut esențială a construirii unui software de calitate. În acest stadiu se verifică dacă aplicația îndeplinește cerințele formulate pentru aceasta și se fac modificări corespunzătoare codului aplicației (și deseori modelului și bazelor de date). Faza de testare necesită de obicei instrumente de analiză și optimizare a performanței aplicației, iar Borland Optimizeit Profiler este utilizat în acest scop. Astăzi, acest produs, împreună cu acesta, este integrat în mediul de dezvoltare al celor mai recente versiuni ale instrumentelor de dezvoltare Borland, precum și în mediul Microsoft Visual Studio .NET (Fig. 4).

Implementare

Implementarea software-ului este una dintre cele mai importante componente ale succesului unui proiect. Ar trebui să se realizeze în așa fel încât, în etapa de funcționare de încercare a produsului, să se poată face modificări fără costuri și pierderi grave, să fie ușor să creșteți numărul de utilizatori fără a compromite fiabilitatea. Deoarece aplicațiile sunt implementate în prezent cu companii care utilizează diferite tehnologii și platforme și care utilizează un anumit număr de aplicații existente, capacitatea de a integra o nouă aplicație cu sisteme vechi poate fi importantă în timpul implementării. În acest scop, Borland oferă o serie de tehnologii de integrare pe mai multe platforme (cum ar fi Borland Janeva, care permit integrarea aplicațiilor .NET cu aplicațiile bazate pe CORBA și J2EE).

Managementul schimbării

Gestionarea schimbărilor se realizează în toate etapele de creare a aplicației. Din perspectiva lui Borland, aceasta este cea mai importantă parte a proiectului - la urma urmei, pot apărea modificări în cerințe, în cod și în modele. Este dificil să gestionezi un proiect fără a urmări modificările - managerul de proiect trebuie să fie conștient de ceea ce se întâmplă exact în această etapă și de ceea ce a fost deja implementat în proiect, altfel riscă să nu finalizeze proiectul la timp.

Pentru a rezolva această problemă, puteți utiliza Borland StarTeam (Figura 5) - un instrument scalabil de gestionare a configurației software care stochează toate datele necesare într-un depozit centralizat și optimizează interacțiunea angajaților responsabili pentru diferite sarcini. Acest produs oferă echipei de proiect o varietate de instrumente pentru publicarea cerințelor, gestionarea sarcinilor, programarea, lucrul, discutarea modificărilor, controlul versiunilor și organizarea fluxului de lucru.

Caracteristicile acestui produs sunt integrarea strânsă cu alte produse Borland, suport pentru echipele de dezvoltare distribuite care interacționează pe internet, prezența mai multor tipuri de interfețe client (inclusiv interfața web și interfața Windows), suport pentru multe platforme și sisteme de operare, prezența kitului de dezvoltare software StarTeam (SDK), care este API pentru crearea de soluții bazate pe StarTeam, instrumente de protecție a datelor pe partea de client și server, instrumente pentru accesarea depozitelor Merant PVCS Version Manager și Microsoft Visual SourceSafe, instrumente pentru integrarea cu Microsoft Project, instrumente pentru prezentarea vizuală a datelor, crearea rapoarte și sprijin pentru decizie.

În loc de o concluzie

Ce înseamnă apariția pe piața rusă a setului de produse de mai sus de la un cunoscut producător, ale cărui instrumente de dezvoltare sunt utilizate pe scară largă într-o mare varietate de proiecte? Cel puțin, faptul că astăzi vom putea obține nu doar un set de instrumente pentru diferiți participanți la proiect, ci și o platformă integrată pentru implementarea întregului ciclu de viață al dezvoltării - de la definirea cerințelor la implementare și întreținere (Fig. 6). În același timp, această platformă, spre deosebire de seturile de produse concurente, va garanta suport pentru toate cele mai populare instrumente de dezvoltare și vă va permite să vă integrați componentele în acestea la nivelul sincronizării complete a codului cu modelele, cerințele și modificările. Și sperăm că managerii de proiect vor răsufla ușurați, ușurându-se pe ei înșiși și pe angajații lor de multe sarcini obositoare și de rutină ...

Ar putea fi util să citiți: