Dezvoltarea de produse software cunoaște multe metodologii demne - cu alte cuvinte, cele mai bune practici stabilite. Alegerea depinde de specificul proiectului, de sistemul de bugetare, de preferințele subiective și chiar de temperamentul managerului. Articolul descrie metodologii pe care le întâlnim în mod regulat la Edison.

1. „Model cascadă” (model în cascadă sau „cascada”)

Una dintre cele mai vechi, implică trecerea secvențială a etapelor, fiecare dintre acestea trebuie finalizată complet înainte de a începe următoarea. Modelul Waterfall facilitează gestionarea unui proiect. Datorită rigidității sale, dezvoltarea se desfășoară rapid, costul și termenul limită sunt predeterminate. Dar aceasta este o sabie cu două tăișuri. Modelul cascadă va da rezultate excelente doar în proiecte cu cerințe clare și predefinite și modalități de implementare a acestora. Nu există nicio modalitate de a face un pas înapoi; testarea începe numai după ce dezvoltarea este completă sau aproape completă. Produsele dezvoltate după acest model fără o alegere justificată pot avea deficiențe (lista de cerințe nu poate fi ajustată în niciun moment), care devin cunoscute abia la sfârșit datorită succesiunii stricte a acțiunilor. Costul efectuării unei modificări este mare, deoarece necesită așteptarea până la finalizarea întregului proiect pentru a-l iniția. Cu toate acestea, costul fix depășește adesea dezavantajele abordării. Corectarea deficiențelor constatate în timpul procesului de creare este posibilă și, din experiența noastră, necesită unul până la trei acorduri suplimentare la contract cu o specificație tehnică mică.

Folosind modelul cascadă, am creat multe proiecte de la zero, inclusiv doar elaborarea specificațiilor tehnice. Proiecte despre care se scrie pe Habré: mediu - microtomografie cu raze X, mic - actualizare automată a serviciului Windows pe AWS.

Când să folosiți metodologia cascadă?

• Doar atunci când cerințele sunt cunoscute, înțelese și înregistrate. Nu există cerințe contradictorii.
• Nu există probleme cu disponibilitatea programatorilor cu calificările necesare.
• În proiecte relativ mici.

2. „V-Model”

A moștenit structura „pas cu pas” din modelul în cascadă. Modelul în formă de V este aplicabil sistemelor pentru care funcționarea neîntreruptă este deosebit de importantă. De exemplu, programe de aplicațieîn clinici pentru monitorizarea pacienților, software integrat pentru mecanismele de control pentru airbag-urile de urgență în vehicule și așa mai departe. O caracteristică specială a modelului este că are ca scop verificarea și testarea minuțioasă a unui produs care se află deja în fazele inițiale de proiectare. Etapa de testare este efectuată simultan cu etapa de dezvoltare corespunzătoare, de exemplu, testele unitare sunt scrise în timpul codificării.

Un exemplu al muncii noastre bazat pe metodologia V - aplicație mobilă pentru european operator de telefonie mobilă, care economisește costurile de roaming atunci când călătoriți. Proiectul se desfășoară conform unei specificații clare, dar include o etapă semnificativă de testare: confortul interfeței, funcțional, încărcarea și inclusiv integrarea, care ar trebui să confirme că mai multe componente de la diferiți producători lucrează împreună stabil, furtul de bani și împrumuturile sunt imposibil.

Când să folosiți modelul V?

• Dacă este necesară testarea amănunțită a unui produs, atunci modelul V își va justifica ideea inerentă: validare și verificare.
• Pentru proiectele mici și mijlocii în care cerințele sunt clar definite și fixate.
• În condiții de disponibilitate a inginerilor cu calificările necesare, în special a testatorilor.

3. „Model incremental” (model incremental)

În modelul incremental, cerințele complete ale sistemului sunt împărțite în diferite ansambluri. Terminologia este adesea folosită pentru a descrie asamblarea pas cu pas a software-ului. Au loc mai multe cicluri de dezvoltare și, împreună, ele constituie ciclul de viață cu mai multe cascade. Ciclul este împărțit în module mai mici, ușor de creat. Fiecare modul trece prin fazele de definire a cerințelor, proiectare, codificare, implementare și testare. Procedura de dezvoltare conform modelului incremental presupune lansarea unui produs cu funcționalitate de bază în prima etapă mare, iar apoi adăugarea secvențială de noi funcții, așa-numitele „incremente”. Procesul continuă până când sistemul complet este creat.

Modelele incrementale sunt utilizate în cazul în care cererile individuale de modificare sunt clare și pot fi formalizate și implementate cu ușurință. În proiectele noastre, l-am folosit pentru a crea cititorul DefView și apoi rețeaua de biblioteci electronice Vivaldi.

Ca exemplu, vom descrie esența unui increment. Rețeaua Vivaldi de biblioteci electronice a înlocuit DefView. DefView s-a conectat la un server de documente și acum se poate conecta la mai multe. Un server de stocare este instalat pe site-ul unei instituții care dorește să-și difuzeze conținutul unui anumit public, care accesează direct documentele și le convertește în formatul necesar. A apărut elementul rădăcină al arhitecturii - serverul central Vivaldi, care acționează ca un motor de căutare unificat pentru toate serverele de stocare instalate în diverse instituții.

Când să folosiți modelul incremental?

• Când cerințele de bază pentru sistem sunt clar definite și înțelese. În același timp, unele detalii pot fi rafinate în timp.
• Este necesară introducerea timpurie a produsului pe piață.
• Există mai multe caracteristici sau obiective riscante.

4. „Model RAD” (model de dezvoltare rapidă a aplicațiilor sau dezvoltare rapidă a aplicației)

Modelul RAD este un tip de model incremental. În modelul RAD, componentele sau funcțiile sunt dezvoltate de mai multe echipe de înaltă calificare în paralel, precum mai multe mini-proiecte. Durata unui ciclu este strict limitată. Modulele create sunt apoi integrate într-un prototip de lucru. Synergy vă permite să oferiți foarte rapid clientului ceva ce funcționează pentru revizuire pentru a primi feedbackși a face schimbări.

Modelul de dezvoltare rapidă a aplicațiilor include următoarele faze:

• Modelarea afacerilor: definirea unei liste de fluxuri de informații între diferite departamente.
• Modelarea datelor: informațiile colectate în etapa anterioară sunt utilizate pentru a determina obiectele și alte entități necesare circulației informațiilor.
• Simularea procesului: fluxurile de informații conectați obiecte pentru a atinge obiectivele de dezvoltare.
• Construiți aplicația: utilizează instrumente de asamblare automate pentru a converti modelele CAD în cod.
• Testare: noi componente și interfețe sunt testate.

Când este utilizat modelul RAD?

Poate fi folosit numai cu arhitecți cu înaltă calificare și înaltă specializare. Bugetul proiectului este mare de plătit pentru acești specialiști, împreună cu costul instrumentelor de asamblare automatizate gata făcute. Modelul RAD poate fi selectat cu cunoștințe sigure despre afacerea țintă și necesitatea producției urgente a sistemului în 2-3 luni.

5. „Model Agile” (metodologie de dezvoltare flexibilă)

În metodologia de dezvoltare „agile”, după fiecare iterație clientul poate observa rezultatul și poate înțelege dacă îl satisface sau nu. Acesta este unul dintre avantajele modelului flexibil. Dezavantajele sale includ faptul că, din cauza lipsei de formulări specifice a rezultatelor, este dificil să se estimeze costurile cu forța de muncă și costurile necesare dezvoltării. Programare extremă(XP) este una dintre cele mai cunoscute aplicații ale modelului agil în practică.

Acest tip se bazează pe întâlniri zilnice scurte - „Scrum” și întâlniri periodice periodice (o dată pe săptămână, o dată la două săptămâni sau o dată pe lună), numite „Sprint”. În întâlnirile zilnice, membrii echipei discută:

• raportează munca depusă de la ultimul Scrum;
• o listă de sarcini pe care angajatul trebuie să le îndeplinească înainte de următoarea întâlnire;
• dificultăți întâmpinate în timpul lucrului.

Metodologia este potrivită pentru proiecte mari sau cele care vizează un ciclu lung de viață, adaptându-se constant la condițiile pieței. În consecință, cerințele se modifică în timpul procesului de implementare. Merită să ne amintim clasa oameni creativi, care tind să genereze, să producă și să încerce idei noi săptămânal sau chiar zilnic. Dezvoltarea agilă este cea mai potrivită pentru acest psihotip de manageri. Dezvoltăm startup-urile interne ale companiei folosind Agile. Un exemplu de proiecte ale clienților este Sistemul Electronic de Examinare Medicală, creat pentru a efectua examene medicale în masă în câteva minute. În al doilea paragraf al acestei recenzii, partenerii noștri americani au descris un lucru foarte important care este fundamental pentru succesul în Agile.

Când să folosești Agile?

• Când nevoile utilizatorilor sunt în continuă schimbare într-o afacere dinamică.
• Schimbările agile sunt implementate la un cost mai mic datorită creșterilor frecvente.
• Spre deosebire de modelul în cascadă, modelul agil necesită doar o mică planificare pentru a începe un proiect.

6. „Model iterativ” (model iterativ sau iterativ)

Un model iterativ de ciclu de viață nu necesită, pentru început, o specificație completă a cerințelor. În schimb, crearea începe cu implementarea unei piese de funcționalitate, care devine baza pentru definirea cerințelor ulterioare. Acest proces se repetă. Este posibil ca versiunea să nu fie perfectă, principalul lucru este că funcționează. Înțelegând obiectivul final, ne străduim să-l atingem astfel încât fiecare pas să fie eficient și fiecare versiune să fie funcțională.

Diagrama arată „dezvoltarea” iterativă a Mona Lisa. După cum puteți vedea, în prima iterație există doar o schiță a Mona Lisei, în a doua apar culorile, iar a treia iterație adaugă detalii, saturație și completează procesul. În modelul incremental, funcționalitatea produsului este construită bucată cu bucată, produsul este alcătuit din piese. Spre deosebire de modelul iterativ, fiecare piesă reprezintă un element complet.

Un exemplu de dezvoltare iterativă este recunoașterea vocii. Prima cercetare și pregătire a aparatului științific a început cu mult timp în urmă, mai întâi în gânduri, apoi pe hârtie. Cu fiecare nouă iterație, calitatea recunoașterii s-a îmbunătățit. Cu toate acestea, recunoașterea perfectă nu a fost încă atinsă, prin urmare, problema nu a fost încă rezolvată complet.

Când este optim să folosiți un model iterativ?

• Cerințele pentru sistemul final sunt clar definite și înțelese în prealabil.
• Proiectul este mare sau foarte mare.
• Obiectivul principal trebuie definit, dar detaliile de implementare pot evolua în timp.

7. „Model în spirală” (model în spirală)

„Modelul spiralat” este similar cu modelul incremental, dar cu accent pe analiza riscului. Funcționează bine pentru rezolvarea problemelor critice de afaceri, atunci când eșecul este incompatibil cu activitățile companiei, în contextul lansării de noi linii de produse, dacă este necesar cercetarea stiintificași teste practice.

Modelul spirală presupune 4 etape pentru fiecare tură:

1. planificare;
2. analiza riscului;
3. proiecta;
4. evaluarea rezultatului și, dacă calitatea este satisfăcătoare, trecerea la o nouă etapă.

Acest model nu este potrivit pentru proiectele mici, este rezonabil pentru cele complexe și costisitoare, de exemplu, cum ar fi dezvoltarea unui sistem de flux de documente pentru o bancă, când fiecare pas următor necesită mai multă analiză pentru a evalua consecințele decât programarea. Într-un proiect de dezvoltare a unui EDMS pentru ODU din Siberia SO UES, două întâlniri privind modificarea codificării secțiunilor arhivei electronice durează de 10 ori mai mult decât combinarea a două foldere de către un programator. Proiectele guvernamentale la care am participat au început cu pregătirea de către comunitatea de experți a unui concept costisitor, care nu este deloc întotdeauna inutil, întrucât se răsplătește la scară națională.

Să rezumam

Slide-ul demonstrează diferențele dintre cele două metodologii cele mai comune.

În practica modernă, modelele de dezvoltare software multivariate. Nu există un model potrivit pentru toate proiectele, condițiile de start și modelele de plată. Nici măcar Agile, atât de îndrăgit de noi toți, nu poate fi aplicat peste tot din cauza nepregătirii unor clienți sau a imposibilității finanțării flexibile. Metodologiile se suprapun parțial ca mijloace și sunt parțial similare între ele. Unele alte concepte au fost folosite doar pentru a-și promova propriile compilatoare și nu au adus nimic nou în practică.

Despre tehnologiile de dezvoltare:
Încă o dată despre cele șapte metodologii principale de dezvoltare.
10 greșeli principale în sistemele de scalare.
8 principii de planificare a dezvoltării care simplifică viața.
5 riscuri principale în dezvoltarea de software personalizat.

Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.

Introducere

Scopul cursului este de a consolida abilitățile în proiectarea sistemelor informaționale.

ÎN munca de curs trebuie rezolvate urmatoarele sarcini:

Analiza tehnologiilor existente pentru crearea sistemelor informatice (IS)

Justificare pentru alegerea tehnologiei pentru crearea IP pentru un proiect de lucru de curs

Dezvoltarea unui proiect IP folosind tehnologia selectată

Pentru rezolvarea problemelor atribuite se vor folosi instrumentele instrumentale de proiectare SI (CASE - tool) Rational Rose, un limbaj vizual orientat pe obiecte. Modelare UML- Limbajul de modelare unificat.

Analiza tehnologiilor software

Tehnologia RAD - Dezvoltare rapidă a aplicațiilor

Acesta este conceptul de a crea instrumente de dezvoltare produse software, acordând o atenție deosebită vitezei și ușurinței programării, creării proces tehnologic, permițând programatorului să creeze cât mai repede posibil programe de calculator. Definiție practică: RAD este un ciclu de viață al procesului de proiectare conceput pentru a obține mai mult de mare viteză dezvoltarea și calitatea software-ului decât este posibilă cu o abordare tradițională de proiectare. De la sfârșitul secolului al XX-lea, RAD a câștigat acceptare și acceptare pe scară largă. Conceptul RAD este adesea asociat cu conceptul de programare vizuală.

Conceptul RAD a fost un răspuns la metodele greoaie de dezvoltare a software-ului din anii 1970 și începutul anilor 1980, cum ar fi modelul Waterfall. Aceste metode implicau un proces atât de lent de creare a unui program, încât adesea chiar și cerințele pentru program au avut timp să se schimbe înainte de sfârșitul dezvoltării. Fondatorul RAD este considerat a fi angajatul IBM James Martin, care în anii 1980 a formulat principiile de bază ale RAD, pe baza ideilor lui Barry Boym și Scott Schultz. Și în 1991, Martin a publicat o carte celebră în care a conturat în detaliu conceptul RAD și posibilitățile de aplicare a acestuia. În prezent, RAD devine o schemă general acceptată pentru crearea instrumentelor de dezvoltare software.

Scop:

RAD presupune că dezvoltarea de software este realizată de o echipă mică de dezvoltatori pe o perioadă de aproximativ trei până la patru luni, folosind prototipuri incrementale folosind unelte modelarea și dezvoltarea vizuală. Tehnologia RAD asigură implicarea activă a clientului în fazele incipiente - supravegherea organizației, dezvoltarea cerințelor de sistem. Ultima dintre aceste proprietăți presupune respectarea deplină a cerințelor clientului, atât funcționale, cât și nefuncționale, ținând cont de posibilele modificări ale acestora în timpul dezvoltării sistemului, precum și obținerea de documentație de înaltă calitate care asigură ușurința în exploatare și întreținere a sistemului. . Aceasta înseamnă că costurile suplimentare de asistență imediat după livrare vor fi semnificativ mai mici. Astfel, timpul total de la începutul dezvoltării până la obținerea unui produs acceptabil la utilizarea acestei metode este redus semnificativ.

Aplicație:

Este recomandabil să se folosească tehnologia RAD atunci când anumite domenii prioritare pentru dezvoltarea proiectelor sunt clar definite.

Proiectul trebuie finalizat într-un interval de timp scurt. Finalizarea rapidă a proiectului vă permite să creați un sistem care să corespundă cerințelor dumneavoastră astăzi. Dacă un sistem este proiectat pentru o perioadă lungă de timp, atunci există o probabilitate foarte mare ca în acest timp prevederile fundamentale care reglementează activitățile organizației să se schimbe semnificativ, adică sistemul să devină învechit chiar înainte de finalizarea proiectării sale.

Cerințele software nu sunt clar definite. În cele mai multe cazuri, clientul are o idee foarte aproximativă despre cum va funcționa viitorul produs software și nu poate formula clar toate cerințele pentru software. Cerințele pot să nu fie definite deloc la începutul proiectului sau se pot schimba pe măsură ce proiectul avansează.

Proiectul se desfășoară sub constrângeri bugetare. Dezvoltarea este realizată de mici echipe RAD într-un timp scurt, ceea ce asigură un minim de costuri cu forța de muncă și îi permite să se încadreze în constrângerile bugetare.

Interfața cu utilizatorul (GUI) este factorul principal. Nu are rost să forțezi utilizatorul să deseneze imagini. Tehnologia RAD face posibilă demonstrarea interfeței într-un prototip și destul de curând după începerea proiectului.

Este posibil să împărțiți proiectul în componente funcționale. Dacă sistemul propus este mare, este necesar ca acesta să poată fi împărțit în părți mici, fiecare dintre ele având o funcționalitate clară. Ele pot fi eliberate secvenţial sau în paralel (în acest din urmă caz ​​sunt implicate mai multe grupuri RAD).

Complexitate de calcul scăzută a software-ului.

Tehnologia RAD nu este universală, adică utilizarea sa nu este întotdeauna recomandabilă. De exemplu, în proiectele în care cerințele pentru un produs software sunt clar definite și nu ar trebui să se schimbe, nu este necesară implicarea clienților în procesul de dezvoltare, iar dezvoltarea ierarhică (metoda cascadă) poate fi mai eficientă. Același lucru se aplică proiectelor, software-ului, a căror complexitate este determinată de necesitatea de a implementa algoritmi complecși și de rolul și domeniul de aplicare interfata utilizator mic.

Principii de bază:

Principiile tehnologiei RAD sunt menite să ofere cele trei avantaje principale ale sale - viteză mare de dezvoltare, cost redus și calitate superioară. Obținerea unui software de înaltă calitate este foarte dificilă, iar unul dintre principalele motive pentru dificultățile care apar este că dezvoltatorul și clientul văd subiectul dezvoltării (software) diferit.

Setul de instrumente ar trebui să aibă ca scop minimizarea timpului de dezvoltare.

Crearea unui prototip pentru a clarifica cerințele clienților.

Ciclul de dezvoltare: fiecare noua versiune a produsului se bazează pe evaluarea de către client a rezultatelor versiunii anterioare.

Minimizarea timpului de dezvoltare a versiunii prin transferul de module gata făcute și adăugarea de funcționalități la o nouă versiune.

Echipa de dezvoltare trebuie să colaboreze strâns, fiecare membru fiind dispus să îndeplinească mai multe responsabilități.

Managementul proiectelor ar trebui să minimizeze durata ciclului de dezvoltare.

Principiile RAD se aplică nu numai implementării, ci se extind și la toate etapele ciclului de viață, în special la etapa de cercetare organizațională, construirea cerințelor, analiză și proiectare.

Alegerea metodelor de dezvoltare a aplicației devine sarcina nr. 1 în condiții creștere rapidă piaţă. Conform studiului În 2015, s-au cheltuit 310 de miliarde de dolari pentru software pentru întreprinderi la nivel mondial. Dezvoltarea conceptuluiRAD (dezvoltare rapidă a aplicațiilor)a devenit baza pentru crearea unui sistem de dezvoltare de aplicații flexibil, adaptiv, care ar fi o contrapondere la modelul rigid „cascada”.

RAD este un model de dezvoltare rapidă a aplicațiilor care se concentrează pe viteza și ușurința de programare.

Apariția RAD

Putem mulțumi imperfecțiunii modelului de familie pentru apariția dezvoltării rapide a aplicațiilor Cascadă la crearea unui software. Chestia este că inițial sistemul de dezvoltare a cascadei s-a bazat pe modelul ingineresc tradițional folosit pentru proiectarea si constructia cladirilor si podurilor.

În timp ce Waterfall s-a bazat pe o structură rigidă a activităților de dezvoltare secvențială, apariția RAD a fost o încercare de a crea un proces flexibil care ar putea folosi cunoștințele acumulate pe parcursul ciclului de viață al proiectului.

Prima versiune a RAD a fost creată de Barry Boehm în 1986, care a numit-o „modelul în spirală”. Fiecare tură a spiralei este împărțită în 4 sectoare și corespunde dezvoltării unui fragment sau a unei versiuni a software-ului. Cu fiecare noua viraj are loc o aprofundare si clarificare a scopurilor si specificatiilor proiectului. Ca urmare, devine posibilă alegerea unei opțiuni informate.

Folosind ideile lui Barry, Britanicul James Martin și-a dezvoltat sistemul RADîn timp ce lucra în anii 80 la IBM și, în cele din urmă, le-a formulat în „ Dezvoltare rapidă aplicații” în 1991

Adevărat, există o oarecare confuzie cu privire la sensul cuvântului „RAD” chiar și în rândul specialiștilor IT. La urma urmei, vorbeam despre două concepte: RAD ca alternativă eficientă la CascadaŞi RAD ca metodă specifică dezvoltată de Martin. Acesta din urmă a fost adaptat la sistemele de afaceri intensive în UI.

Ulterior, ideile au fost dezvoltate și îmbunătățite Pionierii RAD James Kerr și Richard Hunterîn cadrul comunității „Inside RAD”, care a descris călătoria unui manager de proiect în procesul de învățare și implementare a metodologiei de dezvoltare rapidă a aplicațiilor în viata reala pentru un proiect real.

Modelul în spirală este un proces de dezvoltare software care combină proiectarea și prototiparea etapă cu etapă.

Bazele (principiile) dezvoltării rapide a aplicațiilor

Principiile RAD se concentrează pe furnizarea beneficiilor de bază ale dezvoltării rapide a aplicațiilor:

• viteza de dezvoltare crescuta
• cost scăzut
• calitate superioară.

Ultimul punct este locul în care apar cele mai multe probleme, deoarece dezvoltatorul și clientul văd subiectul dezvoltării diferit.

Pentru a elimina aceasta și alte probleme, James Martin și adepții săi au identificat următoarele principii RAD:

• minimizarea costurilor de timp— setul de instrumente ar trebui să vizeze reducerea timpului de dezvoltare
• prototipare— crearea de prototipuri pentru a specifica cerințele clienților
• dezvoltare ciclică— fiecare nouă versiune a produsului se bazează pe evaluarea de către client a rezultatelor versiunii anterioare
• cooperare— echipa de dezvoltare trebuie să interacționeze strâns între ele, fiecare membru trebuie să fie pregătit să îndeplinească mai multe responsabilități
• abordare iterativă la dezvoltare
• combinaţietestarea și dezvoltarea sistemului.

Principiile RAD sunt utilizate nu numai în timpul implementării, ci se extind și la toate etapele ciclului de viață, în special la etapa de cercetare organizațională, construcția cerințelor, analiză și proiectare.

Ciclul de viață al software-ului conform RAD

În timpul procesului RAD, o aplicație trece prin patru faze.

Analiza cerințelor și faza de planificare

Sunt determinate cerințele, funcțiile aplicației și prioritatea acestora, sunt descrise nevoile de informații. Faza este realizată în principal de utilizatori, cu participarea dezvoltatorilor. În această etapă sunt indicate, de asemenea, amploarea proiectului, timpul și cadrul financiar, precum și platformele de lansare a software-ului.

, compania Beverly Flowers are nevoie de o aplicație pentru a comanda online flori la tine acasă. Timpul de creare este de 50 de zile, bugetul este de 3.000 USD.

Faza de proiectare

Unii utilizatori participă la proiectarea tehnică a sistemului sub îndrumarea dezvoltatorilor. Grupurile sau subgrupurile RAD din această fază folosesc de obicei o combinație de tehniciCu Dezvoltare de aplicații în colaborare (JAD) Şi instrumente CASE pentru a traduce nevoile utilizatorilor în modele de lucru.

JAD (Joint Application Development) este un concept de dezvoltare comună a aplicațiilor, în cadrul căruia există o interacțiune strânsă între client și performeri pentru maxim solutie eficienta probleme legate de software-ul dezvoltat.

Case este un set de instrumente și metode de proiectare software pentru a asigura produse software de înaltă calitate, fără erori și ușor de întreținut.

În timpul fazei de proiectare, utilizatorii pot înțelege, modifica și defini un model de lucru al sistemului care se potrivește nevoilor lor. Fiecare proces este luat în considerare în detaliu și, dacă este necesar, creatprototip parțial .

Ca urmare, sunt create fazele:

• general model informativ aplicatii
• modele funcționale ale sistemului și subsistemelor
• prototipuri de lucru ale ecranelor, rapoartelor și dialogurilor.

Dacă instrumentele de dezvoltare a prototipurilor nu erau adecvate în modelele anterioare aplicații reale, și nu au fost folosite mai departe, atunci la RAD, fiecare prototip devine parte a viitorului sistem.

Deci, în aplicația Beverly Flowers, utilizatorii ar trebui să aibă acces la următoarele opțiuni: „Home Page”, „Flower Search”, „View Flower List”.

Ca platformă de dezvoltare a fost aleasă software-ul gratuit SpringToolSuite, pentru care sunt disponibile un număr mare de mostre - bucăți de cod scrise.
Rolul serverului este Apache Tomcat 6.0.

Faza de constructie

În această etapă are loc o dezvoltare rapidă imediată pe baza rezultatelor obținute în fazele anterioare. În același timputilizatorii continuă să participe în dezvoltarea sistemului, sugerând modificări și îmbunătățiri ale aplicației. Testarea aplicației are loc și în timpul dezvoltării.

Aplicația „Beverly Flowers” ​​este asamblată din trei componente funcționale - utilizatorul merge la „Home Page”, „Flower Search” și „View Flower List”.
Pentru dezvoltare model de lucru a durat 1 specialist si 8 zile.

Faza de implementare

Acoperă instruirea utilizatorilor, testarea și înlocuirea vechiului sistem cu unul nou. Pregătirea pentru această fază începe cu faza de proiectare.

Anterior, Beverly Flowers accepta comenzi direct la punctele de vânzare și prin telefon.

Prin înregistrarea unui mesaj despre posibilitatea de a comanda prin aplicație specială iar prin amplasarea de standuri de informatii la punctele de vanzare, in 2 saptamani am reusit sa trecem pe niste cumparatori canal nou vânzări

În același timp, ponderea comenzilor telefonice a scăzut proporțional, ceea ce înseamnă că a fost posibilă reducerea personalului managerilor de servicii clienți.

Este de remarcat faptul că, spre deosebire de Waterfall, ciclul de viață al proiectului conform metodologiei RAD nu este rigid. În funcție de condițiile de pornire, numărul de faze poate scădea, precum și umplerea acestora.

Avantaje și dezavantaje ale dezvoltării rapide a aplicațiilor în compania dumneavoastră

Dacă se utilizează sau nu Rapid Application Development, depinde în mare măsură de condițiile de pornire, cerințele clienților și tipul de aplicație.

Avantajele clare ale RAD includ:

1. calitate superioară. Interacțiunea utilizatorului cu prototipurile îmbunătățește funcționalitatea proiectelor de dezvoltare rapidă a aplicațiilor. Un astfel de software poate răspunde mai bine nevoilor clientului (utilizatorului final) decât utilizarea metodologiilor Agile/Waterfall.
2. controlul riscurilor- în ciuda faptului că partea leului materialele despre RAD se concentrează vitezăŞi implicare utilizatorii ca caracteristici cheie modele, o treime nu poate fi exclusă avantaj important — reducerea riscului. Interesant este că Boehm, care a creat prima versiune a RAD, a descris modelul spirală ca fiind bazat pe risc.
   Utilizarea dezvoltării rapide a aplicațiilor vă permite să vă concentrați pe principalii factori de risc și să vă adaptați la aceștia într-un stadiu incipient.
3. Mai multe proiecte sunt finalizate pe unitatea de timp în limitele bugetului- deoarece RAD presupune model de dezvoltare incrementală, sanse pentru erori critice, care se întâmplă adesea în proiecte mari de cascadă, sunt reduse.
   Dacă în proiectele cu sisteme de cascadă, implementarea proiectului a fost posibilă după șase sau mai multe luni de analiză și dezvoltare, atunci în RAD toate informațiile necesare sunt dezvăluite mai devreme, în timpul procesului de creare a aplicației în sine.

Modelul de dezvoltare incrementală este un format de dezvoltare software care implică împărțirea produsului în componente relativ independente. Acestea din urmă sunt dezvoltate și puse în funcțiune separat.

Nu fără neajunsurile sale.

Dezavantajele dezvoltării rapide a aplicațiilor includ:

1. risc de "noutate"— pentru majoritatea companiilor IT, RAD a fost un produs nou care necesita regândirea metodelor obișnuite de lucru. Rezistența la lucruri noi și nevoia de a învăța instrumente și tehnici de la zero duc la greșeli în timpul primelor implementări ale dezvoltării rapide a aplicațiilor.
2. dacă utilizatorii nu pot participa continuu la procesul de dezvoltare de-a lungul întregului ciclu de viață, acest lucru poate avea un impact negativ asupra produsului final - o caracteristică a RAD este interacțiunea sporită între utilizatori și dezvoltatori, spre deosebire de modelele Waterfall în care rolul utilizatorilor este redus la definirea cerințelor . Apoi, dezvoltatorii creează singuri sistemul.
3. control redus— flexibilitatea, adaptabilitatea proceselor ca unul dintre avantajele RAD înseamnă în mod ideal capacitatea de a se adapta rapid atât la probleme, cât și la oportunități.
   Din păcate, va trebui să acordați preferință unui singur lucru - flexibilitate sau control.În acest din urmă caz, metodologia de dezvoltare rapidă a aplicațiilor nu va fi viabilă.
4. design rar- concentrarea pe prototipuri duce în unele cazuri la o metodologie „hack and test”, în care dezvoltatorii făcând constant mici schimbăriîn elemente individuale și ignoră problemele arhitecturii sistemului.
5. lipsa de scalabilitate— RAD este utilizat în principal de echipele de proiect mici și mijlocii. Neajunsurile metodologiei de dezvoltare rapidă a aplicațiilor sunt deosebit de pronunțate atunci când se utilizează dezvoltarea rapidă a aplicațiilor în lucrul pe proiecte mari.

Metodologia RAD este potrivită pentru proiectul dumneavoastră dacă:

• viteza și ușurința dezvoltării sunt importante pentru el
• domeniile prioritare pentru dezvoltarea proiectului sunt clar definite
• Aplicația trebuie dezvoltată într-un timp scurt
• proiectul se realizează cu un buget limitat
• criteriul principal este interfața cu utilizatorul
• Este posibil să divizați proiectul în componente funcționale.

Metodologia de dezvoltare rapidă a aplicațiilor nu se va potrivi proiectului dumneavoastră dacă:

• calitatea și controlul sunt importante pentru el
• vorbim despre crearea proiect de amploare- presupus timp maxim Dezvoltarea aplicației durează 60-90 de zile, iar când scrieți sute de mii de rânduri codul programului este aproape imposibil să se respecte o astfel de restricție
• critică pentru implementare este nivel înalt planificare şi disciplină strictă de proiectare, respectarea strictă a protocoalelor și interfețelor pre-dezvoltate
• Siguranța oamenilor depinde într-o anumită măsură de aplicație.

Verdict

Conceptul de dezvoltare rapidă a aplicațiilor (abreviat RAD pentru Rapid Application Development) este un tip de modele de dezvoltare software incrementală.

Parametrii cheie pe care RAD operează sunt:
viteza si usurinta in programare.

Metodologia va fi o alegere excelentă pentru implementare proiecte mici cu buget limitat, care trebuie dezvoltate în scurt timp. Pentru sisteme de mari dimensiuni, cu cerințe ridicate Pentru control și planificare, este mai bine să alegeți alte modele de dezvoltare software.

Tehnologia RAD (Rapid Aplicație Dezvoltare) – este o tehnologie pentru crearea rapidă a aplicațiilor bazate pe prototipare și utilizarea unei interfețe grafice cu utilizatorul GUI (Grafic Utilizator Interfață).

Tehnologia RAD nu este capabilă să susțină dezvoltarea de produse complexe care conțin multe fragmente care durează mai mult de două săptămâni pentru a fi programate. Această tehnologie se concentrează mai mult pe dezvoltarea de software personalizat destul de simplu decât pe designul IC industrial.

Soluțiile la aproape toate problemele mici de dezvoltare IC sunt obținute folosind tehnologia RAD de renume mondial. Constă în organizarea unui așa-numit grup RAD de 6-7 persoane, format dintr-un manager, un analist de sistem și 4-5 programatori, cărora li se oferă planuri clare pentru întreaga perioadă de dezvoltare a proiectului cu un interval de timp de la 1 la 2. săptămâni.

Baza acestei tehnologii este modelul spiral al creării IP (Fig. 6.1). După cum se poate observa în figură, dezvoltarea se desfășoară în spirală, trecând în mod repetat prin toate cele 4 etape ale dezvoltării IP.

Figura 6.1 – Model de proiectare în spirală bazat pe tehnologia RAD

În stadiul de analiză utilizatorii efectuează următoarele acțiuni:

determina functiile pe care trebuie sa le indeplineasca sistemul;

evidențiați funcțiile cu cea mai mare prioritate care necesită elaborare mai întâi;

descrie nevoile de informare. Formularea cerințelor de sistem este realizată în principal de utilizatori sub îndrumarea dezvoltatorilor specialiști.

În plus, în această etapă sunt rezolvate următoarele sarcini:

domeniul de aplicare al proiectului este limitat;

se stabilesc intervale de timp pentru fiecare dintre etapele ulterioare;

se determină însăși posibilitatea implementării proiectului în limitele sumelor de finanțare date, folosind hardware-ul disponibil etc. Rezultatul etapei ar trebui să fie:

o listă de funcții prioritare ale viitorului software IS;

modele software preliminare.În faza de proiectare

Unii utilizatori iau parte la proiectarea tehnică a sistemului sub îndrumarea dezvoltatorilor specialiști. Pentru a obține rapid prototipuri funcționale de aplicații, se folosesc instrumente adecvate (instrumente CASE). Utilizatorii, interacționând direct cu dezvoltatorii, clarifică și completează cerințele de sistem care nu au fost identificate în etapa anterioară. În această etapă se efectuează următoarele acțiuni:

procesele sistemului sunt examinate mai detaliat;

dacă este necesar, se creează un prototip parțial pentru fiecare proces elementar: o fișă de ecran, un dialog, un raport care elimină ambiguitățile sau ambiguitățile;

sunt stabilite cerințe pentru restricționarea accesului la date;

După o definire detaliată a compoziției proceselor, se evaluează numărul așa-numitelor puncte funcționale ale sistemului în curs de dezvoltare și se ia decizia de a împărți SI-ul în subsisteme care pot fi implementate de o echipă de dezvoltatori într-un timp acceptabil. pentru proiecte RAD (până la 3 luni).

Punct de funcționare - Asta oricare dintre elementele sistemului în curs de dezvoltare:

element de intrare aplicație (document de intrare sau afișaj);

element de ieșire al aplicației (raport, document, formular de ecran);

cerere (pereche întrebare/răspuns);

fișier logic (colecție înregistrări de date, utilizat în cadrul aplicației);

interfața aplicației (un set de înregistrări de date transmise sau primite de la o altă aplicație).

Proiectul este apoi distribuit între diferite echipe de dezvoltare. Experiența dezvoltării unui SI mare arată că, pentru a crește eficiența muncii, este necesar să se împartă proiectul în subsisteme separate, care sunt slab conectate în ceea ce privește datele și funcțiile. Implementarea subsistemelor ar trebui să fie efectuată de grupuri separate de specialiști. În același timp, este necesar să se asigure coordonarea întregului proiect și să se elimine dublarea rezultatelor muncii din fiecare grup de proiecte, care pot apărea din cauza prezenței datelor și funcțiilor comune.

În cazul utilizării instrumentelor CASE, aceasta înseamnă împărțirea modelului funcțional al sistemului (diagrame de flux de date pentru o abordare structurată sau diagrame de caz de utilizare pentru o abordare orientată pe obiecte.

Rezultatul acestei etape ar trebui să fie:

model informativ general al sistemului;

modele funcționale ale sistemului ca întreg și subsisteme implementate de echipele individuale de dezvoltare;

interfețe precis definite între subsisteme dezvoltate autonom;

a construit prototipuri de formulare de ecran, rapoarte, dialoguri.

Toate modelele și prototipurile trebuie obținute folosind acele instrumente CASE care vor fi folosite în viitor la construirea sistemului. Această cerință se datorează necesității de a evita denaturarea necontrolată a datelor atunci când se transferă informații despre proiect de la o etapă la alta.

Spre deosebire de abordarea anterioară, care folosea instrumente specifice de prototipare care nu sunt concepute pentru construirea de aplicații din lumea reală și prototipuri aruncate după ce au servit scopului de a clarifica ambiguitățile de proiectare, în abordarea RAD fiecare prototip este dezvoltat într-o parte a viitorului sistem. Astfel, informații mai complete și mai utile sunt transferate în etapa următoare.

În etapa de implementare Dezvoltarea rapidă a aplicației în sine se realizează direct:

dezvoltatorii construiesc iterativ un sistem real pe baza modelelor obținute în etapa anterioară, precum și a cerințelor nefuncționale (cerințe de fiabilitate, cerințe de performanță etc.);

utilizatorii evaluează rezultatele obținute și efectuează ajustări dacă, în timpul procesului de dezvoltare, sistemul nu mai îndeplinește cerințele definite anterior. Testarea sistemului este efectuată în timpul procesului de dezvoltare.

După finalizarea lucrărilor fiecărei echipe individuale de dezvoltare, se realizează o integrare treptată a acestei părți a sistemului cu restul, se generează un cod de program complet, se testează funcționarea comună a acestei părți a aplicației și apoi sistemul ca un întreg este testat. Implementarea sistemului se finalizează prin efectuarea următoarelor lucrări:

se analizează utilizarea datelor și se determină necesitatea distribuirii acestora;

produs design fizic baze de date;

sunt formulate cerințele pentru resursele hardware;

sunt stabilite modalități de creștere a productivității;

Elaborarea documentației proiectului este în curs de finalizare.

Mediu de dezvoltare rapidă a aplicațiilor Delphi

Scara modernă a dezvoltării software este de neconceput fără instrumentele RAD.

RAD (din engleză. „dezvoltare rapidă a aplicațiilor”- dezvoltarea rapidă a aplicațiilor) - conceptul de a crea instrumente de dezvoltare software, acordând o atenție deosebită vitezei și ușurinței programării, crearea unui proces tehnologic care să permită programatorului să creeze programe de calculator cât mai rapid posibil. De la sfârşitul secolului al XX-lea. RAD a primit adoptare și acceptare pe scară largă. Conceptul RAD este adesea asociat cu conceptul de programare vizuală.

Principii de bază pentru crearea proiectelor RAD:

· Setul de instrumente ar trebui să vizeze reducerea la minimum a timpului de dezvoltare.

· crearea unui prototip pentru a clarifica cerințele clienților.

· dezvoltare ciclică: fiecare nouă versiune a produsului se bazează pe evaluarea de către client a rezultatelor versiunii anterioare.

· minimizarea timpului de dezvoltare a versiunii prin transferul de module gata făcute și adăugarea de funcționalități la o nouă versiune.

· Echipa de dezvoltare trebuie să lucreze îndeaproape împreună, fiecare membru fiind dispus să-și asume mai multe responsabilități.

· managementul proiectului ar trebui să minimizeze durata ciclului de dezvoltare.

Conceptul RAD a fost un răspuns la practicile greoaie de dezvoltare de software din anii 1970 și începutul anilor 1980. Aceste metode implicau un proces atât de lent de creare a unui program, încât adesea chiar și cerințele pentru program au avut timp să se schimbe înainte de sfârșitul dezvoltării. Fondatorul RAD este considerat a fi angajatul IBM D. Martin, care în anii 1980. a formulat principiile de bază ale RAD, pe baza ideilor lui B. Boym și S. Schultz. În prezent, RAD devine o schemă general acceptată pentru crearea instrumentelor de dezvoltare software. Instrumentele de dezvoltare bazate pe RAD sunt cele mai populare printre programatori.

Medii de dezvoltare folosind principiile RAD:

· Borland Delphi.

· Borland C++ Builder.

· IBM Lotus Domino Designer.

· Microsoft Visual Studio.

· Macromedia Flash etc.

Unul dintre cele mai comune medii RAD este Delphi.

Borland Delphi este un mediu de dezvoltare software integrat de la Borland care folosește limbajul de programare Delphi (începând cu versiunea 7, limbajul din mediu se numește Delphi, anterior Object Pascal), dezvoltat de Borland și implementat inițial în pachetul său Borland Delphi, din care a primit 2003 sub numele actual. Obiectul Pascal este în esență un succesor al lui limbajul Pascal cu extensii orientate pe obiecte.

Delphi este rezultatul dezvoltării limbajului Turbo Pascal, care, la rândul său, s-a dezvoltat din limbajul Pascal. Pascal a fost un limbaj complet procedural, Turbo Pascal din versiunea 5.5 a adăugat proprietăți orientate pe obiecte la Pascal, iar Delphi este un limbaj de programare orientat pe obiecte cu capacitatea de a accesa metadatele clasei (adică descrierea claselor și a membrilor acestora) în compilație. cod, numit și introspecție. De facto, Object Pascal și apoi limbajul Delphi sunt extensii funcționale ale Turbo Pascal.

Printre numeroasele produse software comune realizate în Delphi puteți găsi:

· Produse Borland: Borland Delphi, Borland C++ Builder.

· administrare/dezvoltare baze de date: MySQL Tools (Administrator, Query Browser), TOAD.

· software de inginerie: Altium Designer / Protel (proiectare electronică).

· livrare de informații pe Internet: Skype (VoIP și IM), QIP și QIP Infium, The Bat! (client de e-mail).

În timpul procesului de construire a unei aplicații în Delphi, dezvoltatorul selectează componente gata făcute din paleta de componente. Accentul principal al modelului orientat pe obiecte al componentelor software din Delphi este pus pe utilizare maximă cod. Acest lucru le permite dezvoltatorilor să construiască aplicații foarte rapid din obiecte pre-preparate și, de asemenea, le oferă posibilitatea de a-și crea propriile obiecte pentru mediul Delphi.

Mediul Delphi include un set complet de instrumente vizuale pentru dezvoltarea de aplicații de mare viteză, susținând dezvoltarea interfeței cu utilizatorul și conectarea la bazele de date corporative. VCL este o bibliotecă de componente vizuale, include obiecte standard pentru construirea unei interfețe cu utilizatorul, obiecte de gestionare a datelor, obiecte grafice, obiecte media, dialoguri și obiecte de gestionare a fișierelor, management OLE.

În fig. Figura 7.3 prezintă fereastra principală a mediului Delphi în timpul dezvoltării unui program de modelare pentru procesele de producție LAB.

Orez. 7.3. Fereastra principală a mediului Delphi în timpul dezvoltării unui program de simulare pentru procesele de producție LAB

Obiectele bazei de date din Delphi se bazează pe SQL. Delphi include și Borland SQL Link, astfel încât accesul la bazele de date Oracle, Sybase, Informix și InterBase este foarte eficient. În plus, Delphi include server local Interbase astfel încât să puteți dezvolta aplicații care pot fi extinse la orice server SQL extern. Dezvoltator la Mediul Delphi, proiectarea sistem informatic, poate folosi fișiere *.dbf (ca în dBase sau Clipper) sau *.db (Paradox) pentru a stoca informații.

Aplicația finită poate fi produsă fie ca modul executabil, fie ca bibliotecă dinamică, care poate fi folosit în aplicații scrise în alte limbaje de programare.

Datorită arhitecturii sale componente deschise, aplicațiile construite cu Delphi sunt fiabile și stabile. Delphi acceptă utilizarea obiectelor deja existente, inclusiv DLL-uri scrise în C și C++, servere OLE, VBX, obiecte create folosind Delphi. În plus, deoarece Delphi este complet orientat pe obiecte, dezvoltatorii își pot crea propriile obiecte reutilizabile pentru a reduce costurile de dezvoltare.

Biblioteca de componente vizuale include obiecte standard de interfață utilizator, obiecte de gestionare a datelor, obiecte grafice, obiecte multimedia, dialoguri și obiecte de gestionare a fișierelor, management DDE și OLE.

Delphi permite dezvoltatorilor să personalizeze mediul pentru confort maxim. Este posibil să schimbați cu ușurință paleta componentelor, bara de instrumente și, de asemenea, să personalizați evidențierea sintaxei în culoare.