Sistem de management al ciclului de viață. ALM - Managementul ciclului de viață al aplicației

etc..

"Control ciclu de viață»Se reduce la necesitatea de a stăpâni practicile familiare inginerii sistemelor:

  • administrarea informației(„Informațiile necesare ar trebui să fie disponibile părților interesate potrivite la timp și într-o formă accesibilă pentru utilizarea lor”),
  • managementul configurației(„Informațiile de proiectare trebuie să corespundă cerințelor, informațiile „cum este construit” trebuie să corespundă proiectului, inclusiv justificările de proiectare, sistemul fizic trebuie să corespundă informațiilor „cum este construit”, iar diferitele părți ale proiectului trebuie să corespundă cu reciproc”, uneori o parte a acestei practici se numește „managementul schimbării”).

PLM vs PLM

LCM nou formulat nu folosește PLM ca clasa necesară de software în jurul căreia este construit un astfel de sistem. În proiectele mari de inginerie, mai multe PLM-uri (cel mai adesea semnificativ „subdezvoltate”) de la diferiți furnizori sunt de obicei utilizate simultan, iar atunci când se creează un sistem de management al ciclului de viață, vorbim de obicei despre integrarea lor interorganizațională. Desigur, aceasta abordează și problemele modului de integrare a informațiilor în sistemul de management al ciclului de viață al acelor sisteme care nu au încă o conexiune cu unele dintre sistemele PLM ale întreprinderii extinse. Termenul „întreprindere extinsă” se referă de obicei la o organizație creată printr-un sistem de contracte din resurse (oameni, instrumente, materiale) care participă la un proiect de inginerie specific de diverse entitati legale... În întreprinderile extinse, răspunsul la întrebarea în ce fel de PLM sunt integrate datele în care sisteme CAD / CAM / ERP / EAM / CRM / etc. devine nebanal: proprietarii diferitelor întreprinderi nu pot fi comandați. să utilizeze software de la același furnizor.

Și întrucât sistemul PLM este încă un instrument software, iar „sistemul de management” din sistemul de management al vieții este clar înțeles, printre altele, ca un „sistem de management”, termenul de sistem de management al vieții implică clar aspectul organizațional, și nu doar aspectul tehnologiei informaţiei. Astfel, expresia „utilizarea PLM pentru a susține un sistem de management al ciclului de viață” este destul de semnificativă, deși poate fi confuză atunci când traduceți literal „PLM” în rusă.

Cu toate acestea, înțelegerea „managementului ciclului de viață” atunci când este abordată de personalul IT este imediat redusă la „numai software”, ceea ce amintește în mod suspect de software-ul PLM. Și după această simplificare excesivă, încep dificultăți: un sistem PLM „cutie” de la un furnizor de software CAD este de obicei prezentat imediat constructiv, ca un set de module software din catalogul acestui furnizor, fără legătură cu funcțiile de inginerie și management suportate, și este considerată un triplu din următoarea componentă:

  • depozit centrat pe date al datelor ciclului de viață,
  • „Motor de flux de lucru” pentru a sprijini „management”,
  • „Portal” pentru vizualizarea conținutului depozitului și a stării fluxului de lucru.

Scopul ciclului de viață

Scop principal: LCLM detectează și previne coliziunile care sunt inevitabile în dezvoltarea colaborativă. Toate celelalte funcții LCLM sunt derivate care suportă această funcție principală.

Ideea principală a oricărui ciclu de viață modern este utilizarea unei reprezentări precise și consecvente a sistemului și a lumii din jurul acestuia în sisteme informatice inevitabil eterogene și inițial incompatibile ale unei organizații extinse. Utilizarea machetelor virtuale, a modelelor de informații, a depozitelor centrate pe date de informații de proiectare oferă detectarea coliziunilor în timpul „construcției într-un computer”, „asamblarii virtuale”, și nu atunci când se realizează desenele și alte modele ale proiectului în timpul unei construcții reale. „în metal și beton” și punerea în funcțiune.

Ideea PLM nu este astfel legată de o varietate de „automatizare a designului”, în primul rând - de „proiectare generativă” și „producție generativă”. LPLC nu mai este preocupat de sinteză, ci de analiză: detectează și/sau previne coliziunile în rezultatele de proiectare ale subsistemelor individuale atunci când acestea sunt asamblate împreună folosind o varietate de tehnologii:

  • îmbinarea datelor de proiect într-un singur depozit,
  • rulează un algoritm de verificare a integrității pentru datele de inginerie distribuite în mai multe depozite,
  • efectuarea de „asamblare virtuală” și simulare actualizată pentru un subset special selectat al datelor de proiectare.

Abordare bazată pe model

Utilizarea LML implică refuzul nu numai de la hârtie în design, ci și de la „hârtia electronică”(.tiff sau alte formate raster) și trecerea la reprezentarea centrată pe date a informațiilor. Compararea a două modele care există pe hârtie într-o anumită notație și găsirea inconsecvențelor în ele este mult mai dificilă și mai lungă decât prevenirea coliziunilor în structura structurată. documente electronice care nu folosesc grafică raster, ci modele de date de inginerie.

Modelul de date poate fi proiectat în funcție de un anumit limbaj, de exemplu:

  • în ceea ce privește standardul de descriere a metodei de dezvoltare ISO 24744),
  • metamodel (în ceea ce privește consorțiul de standardizare OMG),
  • model de date/date de referință (în ceea ce privește standardul de integrare a datelor ciclului de viață ISO 15926).

Această tranziție la modele reprezentabile structural există deja în etapele incipiente ale proiectării și se numește Inginerie a sistemelor bazate pe modele (MBSE). Devine posibilă eliminarea coliziunilor utilizând prelucrarea datelor computerizate deja în primele etape ale ciclului de viață, chiar înainte de apariția modelelor 3D cu drepturi depline ale structurii.

PLM ar trebui să:

  • furnizați un mecanism de transfer de date de la un CAD / CAM / ERP / PM / EAM / etc. altcuiva- în plus, într-o formă electronică structurată, și nu sub forma unui „pachet de hârtie electronică”. Transferul de date dintr-un sistem informatic de inginerie (cu o înțelegere clară a unde, unde, când, ce, de ce, cum) face parte din funcționalitatea oferită de LMS. Astfel, LCLM trebuie să susțină fluxul de lucru (progresul de lucru care este parțial efectuat de oameni și parțial de sisteme informatice).
  • versiuni de control, adică să ofere o funcție de management al configurației - atât modele, cât și părți fizice ale sistemului. LCLM susține o taxonomie a cerințelor la diferite niveluri și oferă un mijloc de a verifica coliziunea diferitelor niveluri de decizii de proiectare și justificarea acestora cu aceste cerințe. În cursul dezvoltării ingineriei, orice descriere a sistemului, oricare dintre modelele acestuia este schimbată și completată de mai multe ori și, prin urmare, există în multe versiuni alternative de diferite grade de corectitudine și în grade diferite care corespund între ele. PLM trebuie să se asigure că pt munca curenta se folosește doar combinația corectă a acestor versiuni.

Arhitectura PLM

Pot exista multe soluții arhitecturale pentru LCLM, una și aceeași funcție poate fi susținută de diferite modele și mecanisme de operare. Se pot distinge trei tipuri de arhitectură:

  1. Încercările tradiționale de a crea un sistem de management al ciclului de viață Este de a oferi transferuri critice de date punct la punct între diferite aplicații. În acest caz, poate fi utilizat orice sistem specializat de suport al fluxului de lucru (motor BPM, „motor de management al proceselor de afaceri”) sau un motor complex de procesare a evenimentelor. Din păcate, volumul de muncă pentru a asigura schimburile punct la punct se dovedește a fi pur și simplu enorm: de fiecare dată sunt necesari specialiști care să înțeleagă atât sistemele conectate, cât și metoda de transfer al informațiilor.
  2. Utilizarea standardului de integrare a datelor ciclului de viață ISO 15926 conform metodei „ISO 15926 exterior”, atunci când pentru fiecare aplicație de inginerie un adaptor este dezvoltat într-o reprezentare neutră care este conformă cu standardul. Astfel, toate datele se pot întâlni într-o anumită aplicație și poate fi detectată o coliziune între ele - dar aplicația trebuie să dezvolte un singur adaptor de transfer de date și nu mai multe astfel de adaptoare (în funcție de numărul de alte aplicații cu care este necesar). a comunica).
  3. PLM(Teamcenter, ENOVIA, SPF, NET Platform etc.) - este utilizată o arhitectură standardizată, cu singura excepție că modelul de date utilizat în fiecare dintre aceste PLM-uri este mai puțin universal în ceea ce privește reflectarea oricărui domeniu de inginerie și, de asemenea, nu este neutru și accesibil tuturor formatelor. Deci, utilizarea ISO 15926 ca reprezentare de bază la transferul de date către LCLM poate fi considerată o dezvoltare ulterioară a ideilor, de fapt, implementată în PLM modern.

Conform arhitecturii de management al configurației, LCLM poate fi împărțit în trei tipuri:

  • "Repertoriu"(stocarea reală a tuturor datelor de proiect într-un singur depozit PLM, unde datele sunt copiate de unde au fost dezvoltate),
  • "Inregistreaza-te"(LCL menține o listă de adrese de date ciclului de viață în numeroase depozite de alte CAD, sisteme de modelare inginerească, PLM, ERP etc.)
  • „Arhitectură hibridă”- când o parte a datelor este copiată în depozitul central al LCL, iar o parte a datelor este disponibilă din alte locuri prin link-uri.

Arhitectul PLM ar trebui să descrie, de asemenea:

  • "portal"(inclusiv „portal web”), funcțiile acestuia și metoda de implementare. Însăși prezența portalului vă permite să liniștiți managerii de top demonstrând absența coliziunilor. Sunt impuse cerințe specifice soluțiilor arhitecturale pentru „portalul ciclului de viață”.
  • algoritmi de verificare a integrității/coerenței datelor ciclul de viață, precum și o descriere a funcționării acestor algoritmi:
    • un modul standard într-o aplicație separată care lucrează pe date din depozitul acelei aplicații - fie că este CAD sau PLM;
    • un instrument software de verificare a coliziunilor dezvoltat special pentru LCLM, care are acces la date din diferite aplicații situate în depozitul central LCLC;
    • un instrument software special dezvoltat care accesează Internetul printr-un canal securizat către diferite stocări de date situate în diferite organizații;
    • verificări special programate cu control al coliziunilor la încărcarea diferitelor seturi de date de inginerie în depozitul central al LCL;
    • o combinație a tuturor metodelor enumerate - diferite pentru tipuri diferite coliziuni; etc.
  • mod de interacțiune între utilizatorii PLM(Ingineri de proiectare, Cumpărători, Instalatori, Manageri de proiect pentru instalații etc.) și cum exact software-ul PLMS susține această interacțiune într-un mod care previne coliziunile. Standardele de inginerie a sistemelor (în special, standardul de practică de inginerie a sistemelor ISO 15288) necesită selectarea unui tip de ciclu de viață pentru obiectele complexe de inginerie și o indicație a opțiunilor de practică de inginerie a sistemelor care vor fi utilizate. Modelul ciclului de viață este unul dintre artefactele primare care servesc ca aranjamente organizaționale pentru a coordona activitatea unei organizații extinse de proiect de inginerie. Munca coordonată în cursul ingineriei colaborative este o garanție a unui număr mic de coliziuni de proiectare. Cum va susține modelul ciclului de viață exact modelul ciclului de viață? De exemplu, sistemele PLM de obicei nu găsesc loc pentru modelele de ciclu de viață, cu atât mai puțin pentru modelele de organizare. Prin urmare, pentru LCLM este necesar să se caute alte soluții de suport software al acestor modele.
  • Aspectul organizatoric al trecerii la utilizarea sistemului de management al ciclului de viață... Trecerea la utilizarea sistemelor de management al ciclului de viață poate provoca o schimbare semnificativă în structura și chiar în personalul unei companii de inginerie: nu toți excavatoarele sunt angajați ca excavatoare, nu toți taximetriștii sunt angajați ca șoferi de taxi.

Principalul lucru pentru LCLM este în ce măsură soluția propusă contribuie la detectarea timpurie și chiar la prevenirea coliziunilor. Când vine vorba de altceva (alegerea semnificativă a tipului de ciclu de viață în conformitate cu profilul de risc al proiectului, managementul îmbătrânirii, managementul costurilor și reforma sistemului bugetar, stăpânirea proiectării axiomatice, structura de livrare just-in-time care generează proiectare și construcție, cât și mult, mult mai mult, de asemenea extrem de util-modern-interesant), atunci este vorba de alte sisteme, alte proiecte, alte metode, alte abordări. LMLC ar trebui să-și facă treaba bine și nu rău să rezolve un set imens de probleme ale altor persoane alese aleatoriu.

Astfel, un arhitect PLM are două sarcini principale:

  • generează o serie de arhitecturi candidate mai bune și hibrizii acestora
  • faceți o alegere cu mai multe criterii din aceste arhitecturi.
    • considerație semnificativă (semnificația criteriilor de selecție)
    • prezentarea rezultatului (justificarea).

Criterii de alegere a unei soluții arhitecturale pentru un sistem de management al ciclului de viață

  1. Calitatea performanței sistemului de management al ciclului de viață a scopului său principal: detectarea și prevenirea coliziunilor Criteriul principal: cât de mult poate fi accelerat progresul lucrărilor de inginerie prin accelerarea detectării sau prevenirii coliziunilor atunci când se utilizează arhitectura LCLM propusă? Și dacă timpul de muncă nu poate fi redus, atunci cât de mult poate fi mărit volumul de muncă în același timp folosind aceleași resurse? Se recomandă următoarele metodologii:
    • Teoria constrângerilor lui Goldratt(TOC, teoria constrângerilor) - arhitectura ar trebui să indice ce constrângeri de sistem înlătură pe calea resurselor critice a unui proiect de inginerie (a nu fi confundată cu calea critică).
    • ROI(rentabilitatea investițiilor) pentru investiții în managementul ciclului de viață în etapa de oficializare a rezultatului unei analize semnificative a arhitecturilor candidate.
    Este important să alegeți limitele de considerare: viteza globală de execuție a unui proiect de inginerie poate fi măsurată numai la limita sistemului organizațional luat în considerare. Granițele unei singure entități juridice pot să nu coincidă cu granițele unei întreprinderi extinse care desfășoară un proiect de inginerie la scară largă, iar o întreprindere care participă doar la o etapă a ciclului de viață poate să-și evalueze incorect utilitatea și criticitatea pentru întregul ciclu de viață. a sistemului și alege modul greșit de integrare a acestuia în ciclul de viață. Atunci se poate dovedi că crearea unui sistem de management al ciclului de viață nu afectează termenii și bugetele generale ale proiectului, deoarece cele mai neplăcute coliziuni vor continua să nu fie abordate de noul sistem de management al ciclului de viață.
  2. Posibilitatea adoptării unui ciclu de viață incremental pentru dezvoltarea unui sistem de management al ciclului de viațăÎn ISO 15288, un ciclu de viață incremental se numește ciclu de viață în care funcționalitatea nu este dată utilizatorului dintr-o dată, ci pas cu pas - dar și investițiile în dezvoltare nu au loc simultan, ci pas cu pas. Desigur, în acest caz, trebuie să se țină cont de legea scăderii utilității: fiecare creștere a speranței de viață a ciclului de viață (fiecare nou tip de coliziuni detectat în prealabil) este mai costisitoare, iar beneficiile de pe urma acesteia sunt în scădere până la dezvoltare. a ciclului de viață ciclul de viață continuă de la sine. Dacă se dovedește că pentru una dintre arhitecturile propuse este necesar să se investească o mulțime de bani în crearea unui sistem de management al ciclului de viață dintr-o dată, dar beneficiul poate fi obținut imediat în valoare de 100% și numai după cinci ani. o bază la cheie, atunci aceasta este o arhitectură proastă. Dacă se dovedește că este posibil să se dezvolte și să pună în funcțiune un fel de miez LCLM compact, apoi multe, multe module de același tip pentru diferite tipuri de coliziuni cu un mecanism de înțeles pentru dezvoltarea lor (de exemplu, bazat pe utilizarea ISO 15926), atunci acest lucru este foarte bun. Nu este atât de mult despre aplicarea metodologiilor agile, ci despre imaginarea unei arhitecturi LCLM modulare și propunerea unui plan pentru implementarea unei liste prioritizate de module - mai întâi cele mai urgente, apoi cele mai puțin urgente și așa mai departe. A nu se confunda cu ICM (model de angajament incremental), deși semnificația este aceeași: arhitectura este mai bună în care poți obține un fel de plată în rate pentru sistem și să obții funcționalitatea necesară cât mai curând posibil - pentru pentru a obține beneficiul (cel puțin unul mic) devreme și pentru a plăti beneficiile cu întârziere mai târziu.
  3. Abilitatea financiară și intelectuală fundamentală de a stăpâni și menține tehnologia Dacă socotiți cheltuielile nu numai pe ciclul de viață în sine, ci și pe tot personalul și alte infrastructuri necesare pentru implementarea proiectului, atunci trebuie să înțelegeți cât de mult din aceste investiții în educație, computere și eforturile organizaționale vor rămâne. pentru plătitorul și proprietarul sistemului de management al ciclului de viață și cât de mult se va stabili în afara - cu numeroși contractori, care, desigur, vor fi recunoscători mai întâi pentru că au primit o „bursă” pentru a stăpâni noua tehnologie și apoi pentru sprijinirea sistemului pe care îl a creat. Noul este de obicei extrem de costisitor și nu pentru că este scump în sine, ci pentru că provoacă o avalanșă de schimbări pe care le provoacă. Acest punct ia în considerare costul total de proprietate al unui ciclu de viață ciclului de viață și acest punct include, de asemenea, luarea în considerare a întregului ciclu de viață al unui sistem de inginerie cu coliziunile sale evitabile, ci a ciclului de viață în sine.
  4. Scalabilitate a arhitecturii LCLM Acest criteriu este relevant pentru proiecte mari de inginerie. Deoarece doriți ca sistemul să fie utilizat de toate miile de oameni din organizația dumneavoastră extinsă, va trebui să crească rapid la această scară. În ce măsură poate un „pilot” sau „loc de testare” al sistemului de control al ciclului de viață să crească rapid fără modificări arhitecturale fundamentale? Cel mai probabil, nu vor putea crește. Prin urmare, din punct de vedere arhitectural, nu este nevoie de „pilot” sau de „gamă de testare”, ci de „prima etapă” deodată. Cerința criteriului de scalare se intersectează îndeaproape cu cerința criteriului de incrementalitate, dar atinge un aspect ușor diferit - nu atât întinderea în timp a creării sistemului de management al ciclului de viață, cât și posibilitatea de întindere peste volumul acoperit. . Experiența arată că toate sistemele fac față unor volume de testare de date de proiectare, dar nu pot face față celor industriale. Cum va crește costul hardware-ului și software-ului neliniar odată cu creșterea volumelor/vitezei? Cât timp vor fi elaborate regulamentele când se va dovedi că după câteva la locul de muncă sunt mai multe date prin care pot fi vizualizate în mod semnificativ de către o singură persoană? Scalabilitatea slabă poate sta în așteptare nu numai din partea tehnică a arhitecturii soluției software și hardware, ci și din partea arhitecturii sale financiare. Așadar, un preț mic pentru o licență pentru fiecare stație de lucru a sistemului de management al ciclului de viață, sau chiar un preț mic pentru fiecare nouă conexiune pe un server de depozit, poate transforma o soluție mai mult sau mai puțin atractivă pentru zece locuri de muncă în absolut inaccesibilă financiar pentru o mie țintă. a locurilor de munca.
  5. Capacitatea de a lua în considerare problemele organizatorice inevitabile inclusiv relația cu sistemele moștenite preferate din organizația extinsă. Cât de mult necesită arhitectura centralizată sau distribuită propusă pentru a „da funcții altor departamente”, „a da datele noastre” și în general ceva „a da” în comparație cu situația actuală fără sistem de management al vieții? Mainframe-urile au pierdut masiv concurența în fața mini-calculatoarelor, iar cele în fața computerelor personale. Înapoi la sisteme centralizate, care inevitabil pare a fi un sistem de management al ciclului de viață), aproape că nu există nicio modalitate, deoarece toate datele se află în aplicații separate, iar tragerea acestor date în sisteme noi pare să fie cea mai dificilă sarcină organizațională. Cum funcționează arhitectura LCLM: ​​înlocuiește aplicațiile de inginerie moștenite actuale, este construită pe deasupra infrastructurii IT actuale, este instalată gratuit de diverse servicii? Cât de mult efort organizațional / managerial / de consultanță va fi nevoie pentru a promova noua tehnologie? Câți oameni să concedieze, câți să găsească și să angajeze noi specialiști? Acest criteriu de acceptabilitate organizațională este strâns legat nu numai de centralizare/descentralizare, ci și de luarea în considerare a sistemului de motivare în întreprinderea extinsă, i.e. Evaluarea arhitecturii LCLM după acest criteriu depășește cu mult luarea în considerare doar a LCLM, dar necesită o analiză aprofundată a principiilor construirii unei organizații extinse - până la o revizuire a principiilor care stau la baza contractelor în baza cărora este creată. Dar aceasta este esența abordării sistematice: orice sistem țintă (în acest caz, speranța de viață ciclului de viață) este considerat, în primul rând, nu „în profunzime, din ce părți”, ci „în exterior, parte din care” - nu designul și mecanismul său de funcționare sunt interesante în primul rând, dar LMS suportat este funcția de prevenire a coliziunilor în supersistemul extern - și prețul pe care supersistemul extern este dispus să-l plătească pentru această nouă funcție. Prin urmare, posibilele arhitecturi LCLM sunt considerate în primul rând nu din punctul de vedere al „tehnologiilor utilizate decent, de exemplu, de la furnizorul de software XYZ” (aceasta este implicit: toate opțiunile de arhitectură propuse sunt de obicei decente din punct de vedere tehnologic, altfel nu sunt opțiuni). !), Dar din punctul de vedere al celor cinci criterii de mai sus.

Funcțiile PLM

  1. Prevenirea coliziunilor
    1. Managementul configurației
      1. Identificare (clasificări, codificări)
      2. Contabilitatea configurației (toate liniile de bază posibile - ConOp, Arhitectură, design, așa cum a fost construit), inclusiv transferul de date către depozitul LCLC, inclusiv suport pentru modificări ale fluxului de lucru, inclusiv suport pentru inginerie paralelă (lucrare în condiții de referință incompletă)
      3. Versiune (inclusiv furci)
    2. Lipsa transferului manual de date (transferul datelor de intrare și de ieșire între insulele de automatizare existente, inclusiv transferul de date de pe insulele de „creștere la figura” dezvoltărilor de design vechi)
    3. Configurație NSI
    4. Sistem colaborativ de suport de inginerie (videoconferințe, sesiuni de proiecte la distanță etc. - poate nu cel folosit pentru a crea sistemul LCM în sine)
  2. Detectarea coliziunii
    1. Suport pentru un registru al tipurilor de coliziuni de verificat și tehnologii de verificare corespunzătoare registrului
    2. Transfer de date pentru verificarea coliziunilor între insulele de automatizare (fără asamblare în depozitul PLMS, dar prin intermediul tehnologiei PLMS integrate)
    3. Verificați rularea fluxului de lucru tipuri diferite ciocniri
      1. în depozitul PLM
      2. nu în depozit, ci prin intermediul tehnologiei de integrare a sistemului de management al ciclului de viață
    4. Lansarea fluxului de lucru de eliminare a coliziunii găsite (trimiterea de notificări despre coliziuni, deoarece fluxul de lucru de eliminare nu este preocuparea PLM)
    5. A sustine lista curenta coliziuni nerezolvate
  3. Dezvoltare(aici ciclul de viață ciclului de viață este considerat un sistem autopoietic, deoarece „incrementalitatea implementării” este una dintre cele mai importante proprietăți ale ciclului de viață ciclului de viață însuși - deci aceasta este o funcție a ciclului de viață ciclului de viață însuși, și nu este o funcție a sistemului suport pentru ciclul de viață ciclului de viață)
    1. Asigurarea comunicarii despre dezvoltarea sistemului de management al ciclului de viata
      1. Planificarea dezvoltării sistemului de management al ciclului de viață (foaia de parcurs, elaborarea unui plan de acțiune)
      2. Funcționarea biroului de proiecte al PLMS,
      3. Menținerea unui registru de tipuri de controale de coliziune (registrul propriu-zis al „dorințelor” și foaia de parcurs pentru implementarea controalelor)
      4. Modelare organizatorică (Arhitectura întreprinderii) pentru LCLM
      5. Infrastructura de comunicații pentru dezvoltatorii LCLM (conferințe pe internet, comunicare video, managementul cunoștințelor etc. - poate nu cea folosită în inginerie colaborativă folosind LCM)
    2. Consecvența tehnologiei de integrare a datelor (de exemplu, tehnologia ISO 15926)
      1. Folosind un model de date neutru
        1. Suport bibliotecă de date de referință
        2. Dezvoltarea datelor de referință
      2. Tehnologie pentru suportarea adaptoarelor la modelul de date neutru
    3. Uniformitatea fluxului de lucru / tehnologie de integrare BPM (în întreaga întreprindere extinsă)
  4. Securitatea datelor(la scara sistemelor informatice care opereaza in cadrul sistemului de management al ciclului de viata)
    1. Asigurarea unității de acces (o singură autentificare și parolă pentru toate sistemele informatice care participă la fluxul de lucru)
    2. Controlul drepturilor de acces la elementele de date
    3. Backup

Managementul ciclului de viață al aplicației ( Ciclul de viață al aplicației Management, ALM) se dezvoltă rapid. Aceasta este o abordare promițătoare pentru îmbunătățirea procesului de creație. software(PE). Cu toate acestea, procesul ALM „tradițional” nu este capabil să-și atingă întregul potențial de profit pentru organizație. De ce? Deoarece furnizorii împing în mod agresiv pe piață soluții limitate ALM end-to-end, care au scopul de a lega clienții de platforme tehnologice închise. Clienții constată în curând că aceste soluții nu se integrează cu procesele, instrumentele și platformele lor de dezvoltare existente. Din păcate, acest lucru lasă echipele de dezvoltare cu procese fragmentate și o mizerie de date ALM, ceea ce, la rândul său, 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 folosind un mediu de dezvoltare mixt. Cu soluțiile Borland Open ALM, organizațiile își pot folosi resursele și instrumentele de dezvoltare existente. Acest lucru va ajuta la obținerea transparenței, controlului și disciplinei pe tot parcursul ciclului de dezvoltare a software-ului. Clienții pot beneficia acum de o platformă ALM optimizată și de un proces de dezvoltare software unificat, gestionabil și măsurabil.

Dezvoltare software previzibilă: misiune imposibilă?

Dezvoltarea de software este în esență o activitate complexă. Crearea unui produs software cu caracteristici destul de clar definite, realizat cu o calitate acceptabila, in limita bugetului alocat si la timp, necesita coordonarea constanta a unui numar mare de actiuni intre numerosi specialisti.

Complexitatea gestionării și urmăririi proiectelor software crește atunci când organizațiile decid să utilizeze modele de dezvoltare distribuite (de exemplu, programare offshore sau utilizarea de angajați temporari și subcontractanți). Ca urmare, eșecurile sau rezilierile proiectelor devin omniprezente. Suprabugetarea, programele ratate, calitatea slabă și fiabilitatea slabă au devenit norma în industria software. În consecință, din ce în ce mai multe abordări inteligente sunt cerute de la organizațiile de dezvoltare de software. Ei 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 standardizarea tot mai mare și utilizarea platformelor de dezvoltare a întreprinderilor, provocările cu care se confruntă industria au devenit mai puțin tehnice. Capacitatea de a genera valoare consistentă ș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 considerente, 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 ale industriei, cum ar fi adoptarea accelerată a cadrului de îmbunătățire a proceselor CMM / CMMI și utilizarea sporită a modelelor de dezvoltare terță parte sunt strâns legate de această transformare aparentă a industriei software.

Apariția ALM

Pe măsură ce industria dezvoltării de aplicații răspunde nevoii de dezvoltare software previzibilă, și-a concentrat eforturile pe mai mult decât instrumente pentru dezvoltatorul individual. Producătorii și-au extins ofertele și au integrat atât capabilitățile existente, cât și cele noi în produsele lor. Soluțiile lor îndeplinesc acum sarcini asociate cu alte roluri în procesul de dezvoltare a software-ului. Aceste pachete de produse, adesea comercializate și comercializate ca platforme de dezvoltare colaborativă, au introdus tehnologia Application Lifecycle Management (ALM). A devenit o categorie nouă pe piață și o disciplină separată în dezvoltarea de software. Platformele ALM sunt concepute special pentru a răspunde provocărilor de creștere a predictibilității și integrității procesului de dezvoltare software. Aceștia abordează aceste provocări oferind integrare și automatizare pentru fiecare rol major care participă la proces și automatizarea unui număr de funcții.

Măsurabilitate

Capacitatea 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ă.

Armonizare

Alinierea specializării afacerii și a priorităților IT.

Alinierea rezultatelor proiectului cu așteptările utilizatorilor finali.

Disciplina

Consecvența definirii, implementării și urmăririi cu procesele software.

Creșterea severității procesului de schimbări în management și previziunea consecințelor acestora.

Aceste capabilități le permit liderilor IT să echilibreze și să prioritizeze portofoliile lor de proiecte software. Ei pot atinge un nivel mai înalt de management al echipelor lor și mult mai multă transparență în implementarea proiectelor. Cu ALM, directorii pot obține, de asemenea, mult mai mult control asupra procesului de dezvoltare software. Acest lucru oferă cele mai bune oportunități pentru guvernanța corporativăși ajută organizația să demonstreze conformitatea cu diverse coduri și ordonanțe.

Industria ALM

Inițial, unii dintre puținii inovatori care au înțeles importanța tendinței ALM și și-au schimbat strategiile de lansare a produselor spre sprijin explicit pentru aceasta au fost 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 a software-ului. Aceste instrumente depășesc cu mult instrumentele tradiționale de productivitate ale dezvoltatorului individual. Acestea au ca scop 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 participă la procesul mai larg.

Barele de instrumente la nivel de portofoliu sunt furnizate pentru nevoile managerilor, acoperind metrici importante proiect: risc, progres și calitate.

Pentru nevoile managerilor de proiect sunt furnizate instrumente pentru planificarea si controlul proiectului, analizarea alternativelor posibile si alocarea resurselor.

Pentru nevoile analiștilor, sunt furnizate instrumente pentru definirea cerințelor, interacțiunea cu utilizatorii finali și alte părți interesate ale proiectului. Acest nivel oferă, de asemenea, instrumente pentru gestionarea cerințelor de-a lungul 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 design și arhitecturii corporative.

Pentru nevoile dezvoltatorilor sunt furnizate o varietate de medii de programare și instrumente de asigurare a calității la nivel de cod (cum ar fi profilere de rulare, testare unitară și auditare automată a codului).

Pentru nevoile inginerilor de calitate, sunt furnizate instrumente pentru crearea și gestionarea testelor, pentru testarea regresiei și funcționale, 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, managementul proceselor, managementul 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 managementului cerințelor. De asemenea, li se oferă oportunități de a face schimb de informații cu privire la cerințe, de a raporta defectele observate ș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 că cel mai recent „Raport Chaos” 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 atribuită parțial și ALM. Cu toate acestea, un studiu mai aprofundat al nevoilor clienților dezvăluie că, deși ALM are beneficii clare, este încă dificil să se realizeze întregul potențial al tehnologiei. 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 al ALM este în mare parte nerealizat

Pentru a înțelege mai bine de ce soluțiile actuale fac dificilă dezlănțuirea completă a valorii de afaceri a ALM, să aruncăm o privire mai atentă la mediile de operare și de dezvoltare software tipice. Vom examina modul în care software-ul este produs și implementat în ceea ce privește procesele, instrumentele de dezvoltare și platformele 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 eșuează - darămite automatizarea - în mod constant și previzibil.

Mediul IT corporativ: problema eterogenității

Creșterea Internetului și proliferarea sa 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 cerințe ridicate de flexibilitate. Problema acestor schimbări are de-a face cu evoluția arhitecturală. Acesta își propune să îmbunătățească capacitatea de răspuns IT și nivelurile de servicii și eficiența prin trecerea de la tehnologiile moștenite la platforme de aplicații noi și moderne. Acestea sunt domeniile cheie ale acestei evoluții.

Migrați de la aplicații specializate 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 împachetate, construite pe arhitecturi vechi, pentru a procesa și a combina aplicații de rulare, cum ar fi SAP NetWeaver și Oracle Fusion.

Utilizarea platformelor specializate pentru nevoi specifice. Acestea sunt, de exemplu, limbaje de scripting 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 diferiți furnizori). Aceste instrumente acoperă analiza, proiectarea, codificarea, controlul calității, controlul versiunilor și gestionarea configurației.

Este rezonabil să presupunem, în special pentru corporațiile mijlocii și mari, că, în viitorul apropiat, fiecare mediu IT al întreprinderii va include cel puțin trei dintre platformele enumerate pentru implementare: mainframe, mediu distribuit (J2EE sau .NET) și sistem de automatizare a afacerilor. -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 platformele .NET. 2

Programe conflictuale

Este interesant de observat că, din motive evidente, unii furnizori de IT încearcă să influențeze natura eterogenă a mediului IT al întreprinderii pe cât posibil. Acești furnizori caută să „preia” pe deplin organizarea mediului IT prin împingerea pe piață a soluțiilor complete „pe viață”. Acestea conțin instrumente de dezvoltare software, un mediu de aplicații și instrumente pentru gestionarea rețelelor și sistemelor. Producătorii majori includ și 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ă servicii profesionale.

În ciuda acestei eforturi masive pentru soluții atotcuprinză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 cresc 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ă anumitor utilizatori finali. 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 împachetate și aplicații distribuite dezvoltate de sine.

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

o Hibrizi Flash / J2EE. Ele combină oportunitățile Adobe flash ca platformă pentru streaming video și aplicații Internet bogate cu beneficiile tehnologiei J2EE pentru servere. Acest lucru permite un grad ridicat de scalabilitate și o interfață multimedia bogată.

Costuri de dezvoltare reduse. Organizațiile încearcă să reducă costurile de dezvoltare și implementare a software-ului combinând atât instrumentele și programele cu sursă deschisă, cât și cele proprietare. În acest sens, merită menționat popularitatea tot mai mare a suitei LAMP (Linux, Apache, MySQL, PHP) și utilizarea tot mai mare a acesteia în organizații.

Reducerea timpului 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 realizate. 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 o platformă poate duce la un risc semnificativ de afaceri, mai ales dacă acel furnizor este (sau va deveni) un concurent în viitor.

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

Eterogeneitatea IT: cea mai mare provocare pentru ALM

Pe scurt, multe organizații din industria IT văd eterogenitatea ca singura alternativă, deoarece există multe beneficii de afaceri asociate cu aceasta. Foarte des, echipele de dezvoltare folosesc o varietate de instrumente care nu sunt menite să lucreze împreună. Nu există un singur furnizor care să furnizeze instrumentele pentru toate acțiunile necesare în contextul unui singur proiect software. Mai mult, nu există un singur furnizor care să poată acoperi pe deplin cele trei domenii principale: suport și modernizare a sistemului moștenit, extinderea și personalizarea aplicațiilor pachetate și dezvoltarea de noi aplicații distribuite. Prin urmare, este foarte probabil ca organizațiile să continue să folosească instrumente de dezvoltare disparate în cadrul aceluiași proiect și în diferite domenii tehnologice. Din acest motiv, 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, aliniere și disciplină automate. Cu toate acestea, într-un mediu foarte eterogen, aceste calități ale procesului de fabricație a software-ului sunt mult mai dificil de atins.

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

Alinierea necesită urmărirea acțiunilor și a rezultatelor pe tot parcursul procesului, de la strategiile IT până la modulele implementate. Acest grad de control este foarte dificil de atins atunci când resursele și activitățile de proces sunt împrăștiate în instrumente și depozite disparate. Nu există instrumente standard care să ofere identificarea, colectarea, gestionarea și utilizarea automată a informațiilor din pista de audit.

Disciplina necesită implementarea, acceptarea și controlul diferitelor procese generale pentru a gestiona producția de software. Acest lucru devine mult mai complex atunci când subprocesele curg ca „insule de proces” între o varietate de instrumente de proces. Nu există un mecanism standard pentru asigurarea coregrafiei unor astfel de sub-procese (în conformitate cu procesul de nivel superior) sau pentru implementarea componentelor de proces pentru aceste instrumente. De asemenea, nu există o terminologie unică pentru descrierea proceselor într-un mediu de instrumente disparate. Toți folosesc propriile limbi pentru „articole”, „artefacte”, „proiecte” și așa mai departe. Un alt aspect al disciplinei necesită schimbări semnificative în management și analiza impactului. Aceste capabilități, totuși, necesită implementarea adecvată a controlului operațional de la capăt la capăt. După cum sa discutat mai devreme, controlul de la capăt la capăt este mult mai dificil de realizat într-un mediu de dezvoltare eterogen.

Pentru a aborda aceste provocări, organizațiile care practică ALM deseori încetează să dezvolte numeroasele integrări punct-la-punct specializate, care completează de obicei golurile tehnologice dintre diferitele instrumente de dezvoltare utilizate. Astfel de integrări sunt nesigure. Acestea se sparg la modernizarea sau schimbarea instrumentelor și sunt costisitoare de construit și întreținut. În plus, ele duc la apariția unor procese software care nu pot fi ușor măsurate și controlate și care sunt incomod de gestionat. Evident, această abordare este inacceptabilă și neprofitabilă.

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 de software care să le ofere stabilitatea și predictibilitatea de care au nevoie. Cu toate acestea, clienții ALM își doresc 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 de aplicații comerciale și open source optimizate pentru obiectivele de implementare dorite.

Utilizarea gratuită a unei varietăți de procese de dezvoltare software comerciale sau specializate, 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 numită Open ALM. Această abordare abordează direct această provocare. Este singura soluție ALM concepută inițial pentru a permite organizațiilor IT să livreze software în mod previzibil în propriul timp.

Depășirea eterogenității: ultima frontieră a ALM

Abordarea Open ALM implementează viziunea și strategia de produs stabilite de Borland. Această abordare reprezintă o schimbare arhitecturală semnificativă unică pentru piața comercială ALM. De fapt, dacă sunt implementate pe deplin, platforma Borland Open ALM și aplicațiile asociate ar putea oferi beneficii semnificative chiar și clienților care nu folosesc deloc instrumente de dezvoltare a aplicațiilor Borland. Fără îndoială, Borland consideră că afacerea sa cu scule este vitală. Compania va continua să le dezvolte și să ofere cele mai bune instrumente din clasă pentru o echipă extinsă de dezvoltare de software. Instrumentele 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 înțeleg rostul, cu orice produs care să le susțină cerințele de dezvoltare. Poate fi fie un produs terță parte, fie open source. Acest nivel de modularitate și flexibilitate diferențiază strategia de produs Borland de alți furnizori ALM, mulți dintre care încearcă 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 în funcție de prioritățile de afaceri sau de adecvarea pentru proiect.

Libertatea de a alege cele mai bune instrumente de dezvoltare pentru platformele alese pe baza unor considerente economice, productivitate crescută și adecvare tehnică.

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

cultura organizațională și cerințele de time-to-market.

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 capabilități.

O vizualizare excelentă multidimensională și personalizabilă a progresului, calității și măsurătorilor de risc ale proiectelor și portofoliilor pentru a sprijini managementul proiectelor și inițiativele de îmbunătățire a proceselor.

„Sfântul Graal”: plin control operationalși urmărirea ciclului de viață. Acest lucru va permite alinierea reală a obiectivelor și activităților de afaceri pe tot parcursul 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 proiectelor printr-o analiză de impact precisă și cuprinzătoare.

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


Aceste capabilități oferă o eficiență excelentă a echipei, sprijină inițiativele de îmbunătățire a calității și ușurează sarcina conformării cu reglementările interne și externe. Acestea vor fi livrate ca un set de componente de infrastructură și instrumente de management ALM corporative. În plus, clienții pot folosi și cele mai bune instrumente integrate de la Borland pentru dezvoltarea de aplicații și managementul 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 managementul cerințelor (RDM). Un set de instrumente și bune practici care asigură că cerințele proiectului sunt exacte și complete, pot fi urmărite eficient până la obiectivele de afaceri și sunt acoperite în mod optim de testele software.

Managementul calității ciclului de viață (LQM). Procedura și instrumentele de gestionare a definiției și măsurării calității în toate etapele dezvoltării software. Aceste instrumente sunt concepute pentru a detecta și a preveni problemele de calitate la începutul unui proiect, atunci când costul remedierii lor 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ării. De asemenea, ajută la gestionarea resurselor și a activităților de schimbare a ciclului de viață atât în ​​modelele cu mai multe noduri, cât și în modelele cu un singur nod.

Soluția Borland Open ALM

După cum sa menționat mai devreme, obiectivul principal al ALM este de a realiza un proces de dezvoltare software previzibil și gestionabil prin măsurabilitate, aliniere și disciplină automate. Am văzut că fiecare dintre cele trei dimensiuni ale ALM într-un mediu de dezvoltare de aplicații eterogen 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 zone de soluții, fiecare special concepută pentru a răspunde provocărilor unuia dintre domeniile majore 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 comerciale sau open source, indiferent de furnizor sau de tehnologia mediului așteptat. Diagrama de pe pagina următoare prezintă o diagramă conceptuală a soluției Borland ALM.


Arhitectura soluției Borland Open ALM


Deschide Business Intelligence pentru ALM

Open 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, a îmbunătăți calitatea muncii sau orice altă măsură specială a proiectelor software într-un mediu de dezvoltare de aplicații eterogen. OBI4ALM furnizează infrastructura pentru colectarea discretă de date distribuite și maparea și analiza metricilor din orice instrument de dezvoltare a aplicațiilor care este înregistrat pentru a face acest lucru. Prin extragerea unor valori predefinite din sursele de date, cadrul OBI4ALM reunește informații disparate împrăștiate de-a lungul ciclului de dezvoltare a software-ului. Această consolidare oferă mari oportunități. De exemplu, puteți crea o vizualizare agregată a valorilor proiectului și puteți defini noi valori de proiect care combină mai multe valori de nivel inferior. Infrastructura OBI4ALM utilizează un depozit de date. Acest depozit conține informații actuale și istorice colectate de la acele instrumente care sunt implicate în diferite etape ale procesului de dezvoltare a software-ului. Utilizează o structură care este optimizată pentru interogarea și analiza datelor. Aplicațiile OBI4ALM pot traduce valorile colectate în informații utile pentru luarea deciziilor pe baza acestora. Aceasta oferă suport pentru luarea deciziilor și notificarea timpurie a problemelor.

Barele de instrumente de date în timp real sunt vizualizări KPI personalizabile care arată tendințele de-a lungul timpului.

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

Instrumentele de luare a deciziilor sunt instrumente analitice care utilizează informații istorice despre un proiect (sau mai multe proiecte) pentru a vă ajuta să luați decizii cu privire la managementul proiectelor.

Deschideți controlul procesului pentru ALM

În ultimă analiză, procesul devine el însuși concept important, care pătrunde în întregul ciclu de viață al software-ului. Un proces înseamnă mai mult decât împărtășirea structurilor de informații cu instrumente care sunt utilizate de diferite roluri sau furnizarea de integrare a capabilităților la nivel de interfață cu utilizatorul. Procesul are un potențial real de coordonare a acțiunilor oamenilor și sistemelor care sunt implicate în procesul de creare a software-ului. În același timp, procesul asigură conformitatea cu politicile stabilite și controlul calității implementării.

Open Process Management for ALM (OPM4ALM) oferă componente de infrastructură și un set de aplicații care sunt utilizate pentru a modela, implementa și implementa diferite procese software într-un mediu de dezvoltare de aplicații eterogen. OPM4ALM merge mult mai departe decât furnizarea de conducere și atribuirea de sarcini părților interesate. Această metodă folosește, de asemenea, un nivel de automatizare a procesului care servește ca lipici principal pentru integrarea clientului, serverului și metodologiei în conformitate cu regulile capturate în modelele de proces. Din acest punct de vedere, integrarea între instrumentele de dezvoltare a aplicațiilor este asigurată de fapt de procese de nivel inferior. Aceasta devine baza fundamentală pentru munca eficienta colectiv.

Infrastructura OPM4ALM este construită pe un nucleu distribuit de procese. Oferă modelarea, personalizarea, implementarea, orchestrarea și coregrafia 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 Open ALM se pot abona și asculta aceste evenimente și pot fi notificate când apar. Process Engine oferă, de asemenea, definirea și evaluarea flexibilă a regulilor. Ajută la descrierea și aplicarea politicilor de dezvoltare a aplicațiilor.


Aplicațiile OPM4ALM oferă valoare de la nivelul infrastructurii de proces. Ele oferă următoarele capacități.

Instrumente pentru procese de modelare, tuning, potrivire și reutilizare. Acestea permit proiectarea eficientă a proceselor software comerciale sau personalizate folosind un model de dezvoltare software bogat în funcții.

Consola Enterprise Processes care oferă o vedere generală consolidată. Această vizualizare conține toate procesele software care sunt implementate în diferite proiecte cu participarea instrumentelor de dezvoltare disparate.

Tabloul de bord pentru evaluarea conformității procesului. Acesta arată abaterile procesului și consecințele lor potențiale și oferă capabilități de raportare utile pentru implementarea inițiativelor de conformitate.

Măsurare și raportare pe baza unor metrici specifice pentru fiecare proces.

Deschideți controlul pentru ALM

Controlul proceselor de la capăt la capăt sprijină multe dintre beneficiile importante ale ALM. Unele dintre ele sunt: ​​Este un instrument esențial pentru implementarea dezvoltării bazate pe cerințele de afaceri, dezvoltarea și testarea bazate pe cerințe și analiza precisă a impactului schimbărilor. Open Traceability for ALM (OT4ALM) oferă o infrastructură pentru crearea și clasificarea legăturilor între resursele create în timpul dezvoltării software. De asemenea, creează un program flexibil pentru conectarea resurselor conexe. Nu contează în ce instrumente se află aceste resurse. Această tehnologie oferă, de asemenea, un mijloc pentru a naviga într-o diagramă a relațiilor dintre resurse, precum și pentru a crea interogări optime și pentru a extrage datele 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ă, analiza impactului schimbărilor, costuri precise și previziuni bugetare.

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

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

TraceView - Vizualizatori interactiv 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ă platformă comună

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

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

Stratul de integrare ALM. Motor de integrare extensibil și încorporabil și SDK. Acesta definește modul standard de funcționare a instrumentelor ALM, colectează valori ALM și creează diagrame pentru monitorizarea resurselor. Pentru a sprijini și a participa la platforma ALM, instrumentul trebuie să furnizeze un plugin de platformă care să satisfacă standardul Open ALM API. De asemenea, puteți utiliza un adaptor personalizat care conectează instrumentul la restul mediilor de dezvoltare a aplicațiilor prin procese care sunt orchestrate de platforma Open ALM.


Drumul spre Open ALM

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

Managementul portofoliului de proiecte (PPM);

Definirea și managementul cerințelor (RDM);

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

Managementul schimbării (CM).

Aceste soluții sunt furnizate printr-o integrare strânsă între produsele Borland și instrumentele terțelor părți. Acest lucru oferă clienților flexibilitatea de care au nevoie și le crește semnificativ capacitățile de gestionare a proiectelor software în prezent.

De ce Borland?

De-a lungul istoriei sale lungi, Borland a lucrat constant cu clienții săi pentru a se asigura că aceștia creează software în cel mai convenabil mod. Borland se angajează în dezvoltarea bazată pe standarde și sprijinul pe mai multe platforme. Ea a oferit organizațiilor IT flexibilitatea și libertatea de alegere de care au nevoie. Odată cu introducerea 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 inițiative ALM non-profit.

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

Spre deosebire de această abordare, Borland a insistat întotdeauna să accepte 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 de la Microsoft. Borland a investit enorm în susținerea celor mai recente tehnologii Microsoft. De exemplu, CaliberRM, prima soluție complet integrată de management al cerințelor pentru Team System, este recomandată de Microsoft pentru a extinde funcționalitatea de bază de management al cerințelor oferită de instrumentul VSTS. Borland va continua să extindă interoperabilitatea platformelor Java și .NET. Sunt planificate capabilități suplimentare, cum ar fi generarea de cod UML-to-C # și suportul pentru Microsoft Domain Specific Languages ​​(alternativa Microsoft la înlocuirea UML).


Trecerea către sursa deschisă este, de asemenea, asociată cu provocările pe care le reprezintă eterogenitatea pentru ALM. Scopul mai multor inițiative Eclipse (Application Lifecycle Framework (ALF), Corona și Eclipse Process Framework (EPF)) este similar cu cel al 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ă ofere doar componente de infrastructură Open ALM. Cu toate acestea, Open ALM este o abordare mai holistică. Această abordare le permite, de asemenea, clienților să obțină valoare de afaceri din infrastructurile disponibile, printr-o suită de aplicații complementare. Borland merge mai departe decât alți furnizori ALM în trecerea sa către Open ALM. Compania și-a extins recent orizonturile și își propune să atingă domenii suplimentare de dezvoltare a aplicațiilor. Borland caută, de asemenea, cea mai bună abordare pentru a susține proiecte de dezvoltare de aplicații pachetate pe platformele SAP NetWeaver și Oracle Fusion.

Concluzie

Borland este unic în a ajuta utilizatorii ALM să creeze software în propriile lor proprii termeni... Abordarea Open ALM și strategia de produs îl deosebesc în mod clar pe Borland de alți furnizori ALM și inițiative open source. Borland este singurul furnizor important de ALM care recunoaște pe deplin realitatea eterogenității IT. Compania încearcă să ajute utilizatorii ALM să folosească instrumentele existente în procesele, mediile și instrumentele lor de dezvoltare. Abordarea Borland cu privire la integrarea bazată pe proces separă și mai mult compania de concurenți. Acest lucru permite Borland să ofere transparență, control și ordine în întreaga strategie 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.

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 trebuie privit doar ca un instrument de monitorizare și impunere a conformității, avertizează analiștii. Aceste sisteme sunt concepute nu atât pentru control, cât pentru automatizarea procesului de dezvoltare și integrarea diverselor instrumente.

Cea mai mare provocare în implementarea instrumentelor ALM este că oamenii nu înțeleg procesul de dezvoltare. Adesea, conducerea crede că ALM poate fi folosit pentru a face lucrurile într-un mod bine definit. Cu toate acestea, este imposibil să planificați totul în avans. În dezvoltarea aplicației, de multe ori trebuie să treceți prin mai multe iterații la fiecare pas, să eliberați versiuni intermediare și să creșteți treptat funcționalitatea aplicației. Sistemul ALM nu ar trebui să restrângă acțiunile dezvoltatorilor, ci mai degrabă 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 sistem imprudent.

Luați în considerare, de exemplu, unul dintre cele mai controversate și aprins dezbateri subiecte din IT astăzi - metodologia DevOps și tot ceea ce este legat de aceasta. Ca o scurtă descriere a tuturor acțiunilor asociate cu transferul aplicației dezvoltate către serviciul IT pentru funcționare reală, aceste cuvinte sună suficient de inofensive. Dar, în general, există un zid de confuzie între dezvoltatorii de aplicații pentru întreprinderi și specialiștii care gestionează infrastructura IT a întreprinderii. Programatorii dau vina adesea pe IT pentru lipsa de flexibilitate, iar cei care gestionează operațiunile IT de zi cu zi dau vina pe IT pentru că ignoră constrângerile și cerințele infrastructurii de producție în care trebuie să ruleze aplicațiile pe care le creează.

Această tensiune determină 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 dezvoltate și a infrastructurii în care trebuie să ruleze aplicația. .. Ideea principală este că facilitarea colaborării între dezvoltatori și profesioniștii IT va duce la o funcționare mai eficientă a întregului mediu informațional al întreprinderii. Problema este că implementarea ALM are șanse mici într-o situație în care două părți, între care cooperarea este necesară pentru a asigura succesul proiectului, încep să-și transfere responsabilitatea pentru dificultățile care apar.

Pentru implementarea cu succes a metodologiei ALM, integratorul de sistem trebuie să se ridice peste nivelul acuzațiilor reciproce din departamentul IT. Potrivit Gina Poole, vicepreședinte de marketing, IBM Rational Software, aceasta înseamnă găsirea și angajarea unui CIO sau CFO capabil să realizeze câți bani pierde clientul din cauza lipsei de muncă coordonată a tuturor serviciilor departamentului IT. Remedierea erorilor dintr-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, iar aceste ipoteze sunt în cele din urmă incorecte, atunci costul întregului proiect crește semnificativ sau clientul va fi obligat să să-și modernizeze infrastructura în consecință.

Desigur, poate fi nevoie de o sumă semnificativă de bani pentru a elimina astfel de contradicții din infrastructura IT a unei organizații. Totuși, singurul obiectivul final această activitate ar trebui să constea în crearea și implementarea unui set de tehnologii de management care să permită programatorilor și specialiștilor în operațiuni IT să nu mai interfereze reciproc în munca celuilalt. Cu cât programatorii petrec mai mult timp discutând despre colaborarea cu profesioniștii IT, cu atât mai puțin timp au la dispoziție direct pentru dezvoltare. Cu cât se creează mai multe aplicații, cu atât va fi nevoie de 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 este să nu te lași prins în conflicte interne asociate cu dorința de a realiza prea multe proiecte IT în paralel. Dacă clientul nu acceptă însuși conceptul de ALM, acesta este de fapt un indicator foarte bun al lipsei sale de maturitate și al competenței slabe în managementul IT. Acest lucru în sine sugerează că revânzătorului este mai bine să stea departe de un astfel de client, deoarece șansele sunt mari ca un astfel de client să aducă mult mai multe probleme decât profit.

Se știe că mulți utilizatori (și, să fiu sincer, unii specialiști IT), când vorbesc despre dezvoltare software, se referă în primul rând la crearea și depanarea codului aplicației. A fost o vreme când astfel de idei s-au dovedit a fi suficient de aproape de adevăr. Dar dezvoltarea aplicațiilor moderne constă nu numai și nu atât în ​​scrierea codului, cât și în alte procese, atât imediat premergătoare programării, cât și după ea. De fapt, vom vorbi mai departe despre ele.

Ciclul de viață al dezvoltării aplicațiilor: Vise și realitate

Nu este un secret faptul că multe produse de succes comercial, atât în ​​Rusia, cât și în străinătate, au fost implementate folosind doar instrumente de dezvoltare a aplicațiilor și, chiar și în acest caz, datele au fost adesea 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 de aplicații sunt acum populare și, într-o măsură oarecum mai mică, instrumentele de proiectare a datelor (aceasta se referă în primul rând la proiecte cu un buget mic și termene strânse de implementare). Toată documentația de proiect, de la atribuirea tehnică până la manualul de utilizare, este creată folosind editori de text, iar faptul că o parte din aceasta este informația inițială pentru programator înseamnă doar că o citește pur și simplu. Și asta în ciuda faptului că, pe de o parte, instrumentele de management al cerințelor, modelarea proceselor de afaceri, instrumentele de testare a aplicațiilor, instrumentele de management de proiect și chiar instrumentele pentru generarea documentației de proiect există de mult timp, iar pe de altă parte, orice proiect. managerul dorește în mod natural să faciliteze viața pentru mine ș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. Prima dintre ele este că instrumentele folosite de companie de foarte multe ori nu se integrează bine între ele. Să luăm în considerare un exemplu tipic: Rational Rose este folosit pentru modelare, Delphi Professional este folosit pentru codare, CA AllFusion Modeling Suite este folosit pentru proiectarea datelor; instrumentele de integrare pentru aceste produse fie sunt complet absente pentru o anumită combinație 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 părți atât de simple ale aplicației, cum ar fi echivalentele rusești ale numelor câmpurilor 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 cu utilizatorul ș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 suport pentru ciclul de viață al software-ului este că, din nou, din cauza absenței sau a 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 se formulează mai întâi cerințele, apoi se realizează modelarea și proiectarea, apoi dezvoltarea și, în final, implementarea (puteți citi despre această schemă și alte metodologii de implementare a proiectelor din seria de recenzii ale Liliei Hough, publicate în revista noastră) este mai mult un vis decât o realitate - în timp ce se scrie codul, clientul va avea timp să schimbe unele dintre procese sau să-și dorească funcționalități suplimentare. Ca urmare a execuției proiectului, se obține adesea o aplicație care este foarte departe de ceea ce a fost descris în termeni de referinta, și o bază de date care are puține î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 peste tot acolo unde ar putea fi util este că are o opțiune extrem de limitată. Pe piața rusă sunt promovate activ în principal două linii de produse: instrumentele IBM / Rational și instrumentele Computer Associates (în principal linia de produse AllFusion Modeling Suite), care sunt concentrate în mare parte pe anumite tipuri de modelare, și nu pe procesul constant de sincronizare cod, baze de date și modele.

Mai există un motiv care poate fi atribuit categoriei factorilor psihologici: există dezvoltatori care nu se străduiesc deloc să-și formalizeze și să documenteze pe deplin aplicațiile - pentru că în acest caz devin indispensabile și personal valoros, iar o persoană care este forțată să înțeleagă după demiterea unui astfel de dezvoltator în codul său sau pur și simplu își menține produsul se va simți ca un complet idiot pentru foarte mult timp. Astfel de dezvoltatori, desigur, nu sunt în niciun caz în majoritate, cu toate acestea, cunosc cel puțin cinci directori de companie care au fost răsfățați de astfel de foști angajați mult sânge.

Desigur, mulți manageri de proiect, în special proiecte cu un buget mic și intervale de timp limitate, ar dori să aibă un instrument cu care să formuleze cerințele pentru produsul software în curs de dezvoltare... și ca rezultat, să obțină un gata făcut. distribuirea unei aplicații de lucru. Acesta, desigur, este doar un ideal, la care până acum nu se poate decât să viseze. Dar dacă cobori din cer pe pământ, atunci poți formula dorințe mai specifice, și anume:

1. Instrumentele de management al 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 codul client, ci și codul serverului).

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ă, codul ar trebui să fie generat automat.

5. Codul scris de mână nu ar trebui să dispară atunci când se modifică modelul.

6. Apariția unei noi cerințe ale clientului nu ar trebui să provoace probleme serioase asociate cu modificările de modele, cod, bază de date și documentație; în acest caz, 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 sfârșit, 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 ele 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 suplimentar al schimbării cerințelor clienților sau al 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 – tehnologiile se dezvoltă, apar produse noi, iar 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 atât de ideală pe cât ar părea la prima vedere.

Produse Borland din perspectiva unui manager de proiect

Borland este unul dintre cei mai populari furnizori de instrumente de dezvoltare, cu o dragoste binemeritată pentru dezvoltatori de douăzeci de ani. Până de curând, această companie oferea în principal o gamă largă de instrumente destinate direct creatorilor de cod de aplicație - Delphi, JBuilder, C ++ Builder, Kylix (am scris despre toate aceste produse de multe ori în revista noastră). Cu toate acestea, succesul unei companii pe piață este determinat în mare măsură de cât de bine urmărește tendințele în dezvoltarea sa și cât de mult înțelege nevoile celor care sunt consumatori ai produselor sale (în acest caz, companii și departamente specializate în dezvoltarea de aplicații).

Acesta este motivul pentru care strategia de dezvoltare a instrumentelor de dezvoltare a Borland include acum suport pentru managementul 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 către Borland de anul trecut a unui număr de companii - BoldSoft MDE Aktiebolag (un furnizor de top al celei mai recente tehnologii de dezvoltare a aplicațiilor Model Driven Architecture), Starbase (un furnizor de instrumente de management al configurației pentru proiecte software), TogetherSoft Corporation (un furnizor de soluții de proiectare software). De la achiziționarea acestor companii, s-a depus multă muncă în ceea ce privește integrarea acestor produse între ele. Drept urmare, aceste produse răspund deja nevoilor managerilor de proiect pentru capacitatea de a organiza dezvoltarea colaborativă iterativă. Mai jos vom discuta despre ceea ce Borland oferă în prezent directorilor și altor colaboratori la proiectele de dezvoltare software (multe dintre produsele și tehnologiile de integrare descrise mai jos au fost prezentate de Borland la conferințele pentru dezvoltatori organizate î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 normal munca la un proiect, fie să înțelegi dacă clientul a dorit 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 reelaborarea aplicației (și personal cred că această cifră este mult subestimată). Mai mult, mai mult de 80% din această muncă este asociată cu cerințe formulate incorect sau incorect, iar repararea 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 managementul cerințelor, arsenalul Borland include Borland CaliberRM, care este în esență o platformă de automatizare a managementului cerințelor care oferă urmărirea modifică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 prin tragerea unei pictograme de cerințe în editorul de cod. În plus, 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 a acestuia în industria auto pentru a gestiona cerințele pentru diferite componente ale vehiculelor (inclusiv vehicule Jaguar). În plus, conform lui Jon Harrison, manager de linie de produse pentru JBuilder, utilizarea CaliberRM pentru a crea Borland JBuilderX a simplificat foarte mult procesul de dezvoltare a acestui produs.

Și, în sfârșit, prezența unui instrument convenabil de gestionare a cerințelor simplifică foarte mult crearea documentației de proiect, și nu numai la începutul etapele proiectului, dar și pe toate cele ulterioare.

Proiectarea aplicațiilor și a datelor

Designul este o parte la fel de importantă a creării unei aplicații și ar trebui să se bazeze pe cerințele declarate. Rezultatul designului sunt 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, inclusiv Microsoft. Produsul specificat permite modelarea și proiectarea aplicațiilor și 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 în modelul de date duc la modificări automate ale codului aplicației, precum și modificările codului duc 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 folosit ca instrument pentru a combina sarcinile de gestionare a cerințelor și de modelare cu sarcini de dezvoltare și testare pentru a înțelege care ar trebui să fie cerințele produsului.

Generarea codului aplicației

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

Testare și optimizare

Testarea este o parte absolut esențială a construirii unui software de calitate. În această etapă se verifică dacă aplicația îndeplinește cerințele formulate pentru aceasta și se fac modificări corespunzătoare codului aplicației (și adesea modelului și bazelor de date). Faza de testare necesită de obicei instrumente de analiză și optimizare a performanței aplicațiilor, 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).

Implementarea

Implementarea software este una dintre cele mai importante componente ale succesului unui proiect. Ar trebui să fie efectuat în așa fel încât, în etapa de funcționare de probă a produsului, să se poată face modificări fără costuri și pierderi serioase, este 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ă tehnologii și platforme diferite și folosesc un anumit număr de aplicații existente, capacitatea de a integra o nouă aplicație cu sistemele vechi poate fi importantă în timpul implementării. În acest scop, Borland oferă o serie de tehnologii de integrare multiplatformă (cum ar fi Borland Janeva, care permit integrarea aplicațiilor .NET cu aplicațiile bazate pe CORBA și J2EE).

Managementul schimbării

Managementul modificărilor se realizează în toate etapele creării 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 pe această etapă si ceea ce a fost deja implementat in proiect, altfel risca sa nu finalizeze proiectul la timp.

Pentru a rezolva această problemă, puteți folosi 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 de diverse sarcini. Acest produs oferă echipei de proiect o varietate de instrumente pentru publicarea cerințelor, gestionarea sarcinilor, programarea, lucrul, discutarea modificărilor, controlul versiunilor, organizarea fluxului de lucru.

Caracteristicile acestui produs sunt integrarea strânsă cu alte produse Borland, suport pentru echipele de dezvoltare distribuite care interacționează prin 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 Kit-ului de dezvoltare software (SDK) StarTeam, care este API pentru crearea de soluții bazate pe StarTeam, instrumente de protecție a datelor pe partea client și server, instrumente pentru accesarea la depozitele Merant PVCS Version Manager și Microsoft Visual SourceSafe, instrumente de integrare cu Microsoft Project, instrumente pentru prezentarea vizuală a datelor, raportare și suport decizional.

În loc de o concluzie

Ce înseamnă apariția pe piața rusă a setului de produse de mai sus de la un producător binecunoscut, 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 diverși participanți la proiect, ci și o platformă integrată pentru implementarea întregului ciclu de viață al dezvoltării - de la definirea cerințelor și terminând cu implementarea și întreținerea (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 va permite integrarea componentelor sale în acestea la nivel de sincronizare completă a codului cu modele, cerințe și modificări. Și sperăm că managerii de proiect vor răsufla ușurați, eliberându-se și angajații lor de multe sarcini obositoare și de rutină...

Analizând evoluția pieței instrumentelor de dezvoltare în ultimii 10-15 ani, se remarcă o tendință generală de schimbare a accentului față de tehnologiile de scriere efectivă a programelor (care, de la începutul anilor 90, au fost marcate de apariția Instrumente RAD - „dezvoltare rapidă a aplicațiilor”) la necesitatea 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 acestora cresc brusc. Acest lucru este cu atât mai important astăzi, când dezvoltatorii de software sunt implicați în aproape toate aspectele muncii întreprinderilor și numărul acestor specialiști este în creștere. În același timp, datele cercetării în acest domeniu sugerează că rezultatele a cel puțin jumătate dintre proiectele de dezvoltare de software „in-house” nu se ridică la nivelul așteptărilor lor. În aceste condiții, sarcina de optimizare a întregului proces de creare a software-ului devine deosebit de urgentă, acoperind toți participanții săi - designeri, dezvoltatori, testeri, servicii de suport și manageri. Managementul ciclului de viață al aplicației (ALM) vede procesul de lansare a software-ului ca un ciclu care se repetă mereu de etape interconectate:

· Definirea cerintelor (Cerinte);

· Design si analiza (Design & Analysis);

· Dezvoltare (Dezvoltare);

· Testare (Testing);

· Implementare și întreținere (Deployment & Operations).

Fiecare dintre aceste etape trebuie atent monitorizată și monitorizată. Un sistem ALM organizat corespunzător vă permite să:

· Reduceți timpul de lansare a produselor pe piață (dezvoltatorii nu trebuie decât să se îngrijoreze de conformitatea programelor lor cu cerințele formulate);

· Îmbunătățiți calitatea, asigurându-vă în același timp că aplicația răspunde nevoilor și așteptărilor 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 ea documentatia proiectului;



· Profitați la maximum de investiția dvs. în competențe, procese și tehnologie.

Strict vorbind, însuși conceptul de ALM, desigur, nu este ceva fundamental nou - o astfel de înțelegere a problemelor dezvoltării software 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 etapa cea mai consumatoare de timp. Și abia în anii 80, din cauza complicațiilor 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 cu fiecare.

Multe companii au fost angajate în aceste sarcini, dar lider 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. produse software... La un moment dat, ea a devenit unul dintre pionierii utilizării pe scară largă tehnici vizuale designul software (și practic autorul UML, care este de facto acceptat ca standard în acest domeniu), a creat o metodologie generală ALM și un set corespunzător de instrumente. Putem spune că până la începutul acestui secol, Rational era singura companie care avea în arsenal întreaga gamă de produse pentru a susține ALM (de la proiectarea afacerii până la întreținere), cu excepția, însă, a unei clase de instrumente - convenționale. instrumente de codificare. 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.

Mai recent, Rational a fost practic singurul producător de instrumente complexe de dezvoltare din clasa ALM, deși au existat și sunt încă instrumente concurente de la alți furnizori pentru anumite etape de dezvoltare software. Totuși, î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 stau de fapt la baza complexul ALM al corporației, a cărui extindere a trecut prin achiziția altor companii care produc produse similare. Aceasta este diferența fundamentală dintre modelele de afaceri ale celor două companii, ceea ce deschide potențiale oportunități de concurență reală. După ce Rational a devenit parte a IBM, Borland se poziționează ca singurul furnizor independent al unei platforme ALM integrate în prezent (adică nu își promovează propriile sisteme de operare, limbi etc.). La rândul lor, concurenții notează că Borland nu a formulat încă o metodologie ALM clară care să ofere o bază pentru combinarea instrumentelor sale existente.

Un alt jucător important în domeniul instrumentelor de dezvoltare este Microsoft. Până acum, ea nu își propune să-și creeze propria platformă ALM; progresul în această direcție este 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 de dezvoltare de bază al Microsoft, Visual Studio .NET, își extinde constant funcționalitatea prin utilizarea unor instrumente de modelare și management de proiect la nivel înalt, inclusiv integrarea cu Microsoft Visio și Microsoft Project.

Trebuie remarcat faptul că astăzi aproape toate companiile de top - dezvoltatori de tehnologii și produse software (cu excepția celor enumerate mai sus, se pot 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 intenționează să-și creeze încă propria platformă ALM, instrumentele CASE produse de aceste companii sunt utilizate pe scară largă în anumite etape ale ciclului de viață al software-ului.

 

Ar putea fi util să citiți: