Procesul de dezvoltare software. Proiectare software

Evidențiat și caracterizat principalele etape de dezvoltare software... Pentru fiecare etapă sunt date și descrise mijloacele care pot fi folosite pentru atingerea obiectivelor etapei.

1. Terminologie

Înainte de a trece la considerarea instrumentelor de dezvoltare care pot fi folosite pentru a crea programe, este necesar să se determine conceptele de bază, termenii care vor fi folosiți în articol. Conform subiectului articolului termen de bază pentru noi, desigur, este „instrumente de dezvoltare software”. În ceea ce privește domeniul dezvoltării software, această definiție poate suna după cum urmează:

Instrumente de dezvoltare software- un set de tehnici, metode, tehnici, precum și un set de instrumente (compilatoare, biblioteci de aplicații/sistem etc.) utilizate de dezvoltator pentru a crea codul programului Program care îndeplinește cerințele specificate.

Tinand cont această definiție termenul „dezvoltare software” ar suna astfel:

Dezvoltare de software – complicat un proces al cărui scop principal este crearea și menținerea unui cod de program care oferă nivelul necesar de fiabilitate și calitate. Pentru a atinge scopul principal al dezvoltării software, se folosesc instrumente de dezvoltare software.

2. Mijloace fixe utilizate în diferite etape de dezvoltare a programului

În funcție de tematica și sarcinile atribuite dezvoltatorilor, dezvoltarea de software poate fi un proces destul de complex, pas cu pas, care implică un numar mare de participanți și o varietate de mijloace. Pentru a determina când și în ce cazuri ce instrumente sunt utilizate, să evidențiem principalele etape ale dezvoltării software-ului. Următoarele etape de dezvoltare prezintă cel mai mare interes pentru problemele problemei luate în considerare:

1. Proiectarea aplicației.
2. Implementarea codului de program al aplicației.
3. Testarea aplicației.

Etapele asociate scrisului sunt omise aici în mod deliberat termeni de referinta, termene de programare, bugetare etc. Motivul pentru aceasta este că în aceste etape, cu rare excepții, practic nu sunt utilizate instrumente de dezvoltare specifice.

2.1 Instrumente de proiectare a aplicațiilor

În faza de proiectare a aplicației, în funcție de complexitatea dezvoltată produs software, direct în funcție de cerințe, se realizează următoarele sarcini de proiectare:

1. Analiza cerințelor.
2. Dezvoltarea arhitecturii viitorului software.
3. Dezvoltarea dispozitivelor sunt componentele principale ale software-ului.
4. Dezvoltarea layout-urilor interfețelor utilizator.

Rezultatul designului este de obicei un document de proiectare software sau un document de arhitectură software. Sarcina de analiză a cerințelor este de obicei efectuată folosind metodele de sistemologie (analiza și sinteza), ținând cont de experiența expertă a proiectantului. Rezultatul analizei este de obicei un model semnificativ sau formalizat al procesului de funcționare al programului. În funcție de complexitatea procesului, pentru construcția acestor modele, metode diferite si ajutoare. În general, următoarele notații sunt de obicei folosite pentru a descrie modele (în paranteze sunt software care poate fi folosit pentru a genera modele):

• BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
• Diagrame bloc (Vision 2003 și multe altele).
• Diagrame ER (Visio 2003, ERWin, Sybase Power Designer și multe altele).
• Diagrame UML (Sybase Power Designer, Trandafir raționalși multe altele).
• amenajări, modele-mat etc.

Uneori, când produsul software dezvoltat este destinat să automatizeze orice activitate complexă, sarcina de analiză (modelare) este efectuată înainte de compilare. cerinte tehnice la viitorul produs. Rezultatele analizei fac posibilă formarea unor cerințe rezonabile pentru o anumită funcționalitate a programului dezvoltat și calcularea beneficiului real din implementarea produsului dezvoltat. Mai mult decât atât, se dovedește diferit că, pe baza rezultatelor analizei, scopurile și obiectivele inițiale ale automatizării se schimbă radical sau, pe baza rezultatelor evaluării eficacității dezvoltării și implementării, se ia decizia de a nu dezvolta un produs. .

Scopul celei de-a doua și a treia sarcini din lista de sarcini de mai sus este de a dezvolta un model (descriere) a viitorului sistem, de înțeles pentru codificator - persoana care scrie codul programului. Este de mare importanță aici care paradigmă de programare (paradigma de programare trebuie considerată și ca instrument de dezvoltare) ar trebui utilizată atunci când scrieți un program. Următoarele ar trebui citate ca exemple ale principalelor paradigme:

• Programare functionala;
• Programare structurata;
• programare imperativă;
• Programare logica;
• Programare orientată pe obiecte (prototipare; folosirea claselor; programare orientată subiectiv).

Alegerea ei depinde în mare măsură de obiceiurile, experiența, tradițiile, unelte disponibil echipei de dezvoltare. Uneori, produsul software dezvoltat este atât de complex încât pentru rezolvarea unui număr de sarcini în diferite componente sistemele folosesc paradigme diferite. De remarcat faptul că alegerea unei abordări sau alteia impune restricții asupra mijloacelor care vor fi utilizate în etapa de implementare a codului programului. Rezultatul rezolvării acestei probleme, în funcție de abordare, poate fi (în paranteze sunt instrumente software care pot fi folosite pentru a le obține):

• diagramă de clasă, etc (Ration Rose, Sybase PowerDisigner și multe altele).
• descrierea modulelor structurilor și a acestora interfata software(de exemplu, Sybase PowerDisigner și multe altele).

Dezvoltarea layout-urilor interfeței cu utilizatorul implică crearea unei reprezentări vizuale a modului în care vor arăta anumite forme video și ferestre în aplicația dezvoltată. Soluția la această problemă se bazează pe utilizarea instrumentelor de proiectare, care nu vor fi luate în considerare în acest articol.

2.2 Mijloace de implementare a codului programului

În etapa de implementare a codului programului, se realizează codarea componente individuale programe în conformitate cu proiectul tehnic elaborat. Mijloacele care pot fi aplicate depind în mare măsură de ce abordări au fost utilizate în timpul proiectării și, în plus, de gradul de elaborare. proiect tehnic... Cu toate acestea, dintre instrumentele de dezvoltare a codului programului, este necesar să se evidențieze următoarele tipuri principale de instrumente (exemple de instrumente sunt date între paranteze): metode și tehnici ale algoritmilor.

• limbaje de programare (C++, C, Java, C #, php și multe altele);
• mijloace de a crea interfața cu utilizatorul(MFC, WPF, QT, GTK + etc.)
• instrumente de control al versiunilor (cvs, svn, VSS).
• mijloace de obținere a codului executabil (MS Studio vizual, gcc și multe altele).
• instrumente de gestionare a bazelor de date (Oracle, MS SQL, FireBird, MySQL și multe altele).
• depanatoare (MS Visual Studio, gdb etc.).

2.3 Instrumente de testare a programelor

Sarcinile principale ale testării sunt de a verifica dacă funcționalitatea programului dezvoltat îndeplinește cerințele inițiale, precum și de a identifica erorile care se manifestă explicit sau implicit în timpul rulării programului. Printre principalele lucrări de testare se numără următoarele:

• Testarea eșecului și recuperarea.
• Testare funcțională.
• Testare de securitate.
• Testarea interacțiunii.
• Testarea procesului de instalare.
• Testare de utilizare.
• Testarea configurației.
• Testare stresanta.

Printre principalele tipuri de fonduri care pot fi utilizate pentru efectuarea lucrărilor furnizate se numără următoarele:

• instrumente pentru analiza codului, profilare (Code Wizard - ParaSoft, Purify - Rational Softawre. Test Coverage - Semantic etc.);
• instrumente de testare a funcționalității (TEST - Parasoft, QACenter - Compuware, Borland SilkTest etc.);
• instrumente pentru testarea performanței (QACenter Performance - Compuware etc.).

3. Concluzie

Procesul de dezvoltare software este un proces complex și ce instrumente trebuie utilizate depinde în mare măsură de sarcinile atribuite dezvoltatorilor. Indiferent de sarcinile de dezvoltare, instrumentele nu pot fi limitate doar la un set de unele instrumente; de ​​asemenea, este necesar să se includă metode, tehnici, abordări și tot ceea ce este folosit pentru a crea un program care îndeplinește cerințele specificate.

De asemenea uite :

Adnotare: Conceptul de proces de dezvoltare software. Proces universal... Procesul curent. Proces specific. Proces standard... Îmbunătățirea procesului. Strategii de tragere/împingere. Modele clasice proces: model cascadă, model spirală. Faze și activități.

Avantajul acestui model este limitarea posibilității de a da înapoi un pas arbitrar înapoi, de exemplu, de la testare la analiză, de la dezvoltare la lucru pe cerințe etc. Sa observat că astfel de rambursări ar putea crește catastrofal costul proiectului și momentul finalizării acestuia. De exemplu, dacă se găsesc erori de proiectare sau analiză în timpul testării, corectarea lor duce adesea la o reluare completă a sistemului. Acest model a permis revenirea doar la pasul anterior, de exemplu, de la testare la codare, din software acest model a fost criticat activ, practic, de către fiecare autor de articole și manuale relevante. A devenit general acceptat că nu reflectă specificul dezvoltării software. Dezavantajele modelului de cascadă sunt:

• identificarea fazelor și tipurilor de activități, ceea ce implică o pierdere a flexibilității dezvoltării, în special, dificultatea susținerii unui proces iterativ de dezvoltare;
• cerința de finalizare completă a fazei de activitate, consolidarea rezultatelor sub forma unui document inițial detaliat (sarcina tehnică, caietul de sarcini); cu toate acestea, experiența în dezvoltarea software-ului arată că este imposibil să finalizați pe deplin dezvoltarea cerințelor, proiectarea sistemului etc. - toate acestea pot fi modificate; iar motivele aici nu sunt doar faptul că mediul proiectului este mobil, ci și faptul că nu este posibilă definirea și formularea corectă a multor decizii în prealabil, acestea fiind clarificate și rafinate abia ulterior;
• integrarea tuturor rezultatelor dezvoltării are loc la final, drept urmare problemele de integrare se fac simțite prea târziu;
• utilizatorii și clientul nu se pot familiariza cu opțiunile sistemului în timpul dezvoltării și văd rezultatul doar la sfârșit; astfel, acestea nu pot influența procesul de creare a sistemului și, prin urmare, cresc riscurile de neînțelegere între dezvoltatori și utilizatori/client;
• modelul nu este rezistent la întreruperi în finanțarea proiectelor sau realocări Bani, dezvoltarea începută, de fapt, nu are alternative „pe parcurs”.

dar acest model continuă să fie utilizat în practică - pentru proiecte mici sau în dezvoltarea de sisteme tipice, unde iterația nu este atât de solicitată. Cu ajutorul acestuia, este convenabil să urmăriți dezvoltarea și să implementați controlul pas cu pas asupra proiectului. Acest model este adesea folosit și în proiecte offshore 1 Din engleza offshore - offshore, în interpretarea extinsă - în afara unei singure țări. cu salarii pe ora. Modelul cascadă a devenit parte integrantă a altor modele și metodologii, cum ar fi MSF.

Model în spirală a fost propus de Bary Boehm în 1988 pentru a depăși neajunsurile modelului cascadei, în primul rând pentru management mai bun riscuri. Conform acestui model, dezvoltarea produsului se desfășoară într-o spirală, fiecare rundă fiind o fază de dezvoltare specifică. Spre deosebire de modelul în cascadă, spirala nu are un set predeterminat și obligatoriu de bucle, fiecare buclă poate deveni ultima din dezvoltarea sistemului, iar la finalizarea acesteia se întocmesc planuri pentru bucla următoare. În cele din urmă, o buclă este tocmai o fază, și nu un tip de activitate, ca în modelul cascadă; în cadrul acesteia, multe tipuri diferite activitate, adică modelul este bidimensional.

Secvența buclelor poate fi următoarea: la prima buclă, se ia o decizie privind fezabilitatea creării de software, la următoarea buclă, Cerințe de sistem , apoi se realizează proiectarea sistemului etc. Bobinele pot avea alte semnificații.

Fiecare buclă are următoarea structură (sectoare):

• definirea obiectivelor, constrângerilor și alternativelor proiectului;
• evaluarea alternativelor, evaluarea și rezolvarea riscurilor; este posibilă utilizarea prototipurilor (inclusiv crearea unei serii de prototipuri), simularea sistemului, modelarea vizuală și analiza specificațiilor; concentrarea pe părțile cele mai riscante ale proiectului;
• dezvoltare și testare - aici este posibilă un model în cascadă sau utilizarea altor modele și metode de dezvoltare software;
• planificarea următoarelor iterații - sunt analizate rezultatele, planurile și resursele pentru dezvoltarea ulterioară, se ia (sau nu) o decizie cu privire la o nouă rundă; analizează dacă are sens să continui dezvoltarea sistemului sau nu; dezvoltarea poate fi suspendată, de exemplu, din cauza unor perturbări financiare; model în spirală vă permite să o faceți corect.

O spirală separată poate corespunde dezvoltării unei componente software sau introducerii de noi modificări în produs. Astfel, modelul poate avea o a treia dimensiune.

Modelul spirală este impractic de aplicat în proiecte cu un grad scăzut de risc, cu un buget limitat, pentru proiecte mici. Mai mult, absența mijloace bune prototiparea poate face, de asemenea, incomod utilizarea modelului în spirală.

Model în spirală nu a găsit o aplicație largă în industrie și este important, mai degrabă, din punct de vedere istoric și metodologic: este primul model iterativ, are o frumoasă metaforă - o spirală - și, ca și modelul cascadă, a fost folosit ulterior pentru a crea alt proces. modele și metodologii de dezvoltare software.

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

1. „Waterfall Model” (model de cascadă sau „waterfall”)

Una dintre cele mai vechi, implică o trecere secvențială de etape, fiecare dintre acestea trebuie finalizată complet înainte de începerea următoarei. Modelul Waterfall este ușor de gestionat proiectul. Datorita rigiditatii sale, dezvoltarea este rapida, costul si termenul sunt prestabilite. Dar aceasta este o sabie cu două tăișuri. Modelul cascadă va oferi doar rezultate excelente î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 abia după ce dezvoltarea este finalizată sau aproape finalizată. Produsele dezvoltate după acest model fără o alegere rezonabilă a acestuia pot avea defecte (lista de cerințe nu poate fi ajustată în niciun moment), care devine cunoscută abia la sfârșit datorită secvenței stricte a acțiunilor. Costul efectuării unei modificări este mare, deoarece trebuie să aștepte finalizarea întregului proiect pentru a-l inițializa. Cu toate acestea, costul fix depășește adesea dezavantajele abordării. Corectarea deficiențelor percepute în procesul de creație este posibilă și, din experiența noastră, necesită de la unu la trei acorduri suplimentare la un contract cu un mic TK.

Cu ajutorul modelului cascada am realizat multe proiecte de la zero, inclusiv elaborarea doar a specificațiilor tehnice. Proiecte despre care se scrie pe Habré: mediu -, mic -.

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

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

2. „V-Model”

A moștenit structura pas cu pas din modelul cascadei. 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 pacientului, software integrat pentru mecanismele de control airbag în vehicule etc. O caracteristică a modelului poate fi considerată că are ca scop verificarea și testarea amănunțită a unui produs care se află deja în fazele inițiale de proiectare. Faza de testare are loc concomitent cu faza de dezvoltare corespunzătoare, de exemplu, testele unitare sunt scrise în timpul codării.

Un exemplu al muncii noastre bazat pe metodologia V - aplicatie mobila pentru european operator celular ceea ce economisește taxele de roaming în timpul călătoriei. Proiectul este realizat conform unei specificații tehnice clare, dar include o etapă semnificativă de testare: confortul interfeței, funcțional, încărcare și inclusiv integrarea, care ar trebui să confirme că mai multe componente sunt din diferiți producători lucrează împreună stabil, furtul de bani și împrumuturi este imposibil.

Când să folosiți modelul V?

• Dacă este necesară testarea amănunțită a produsului, atunci modelul V va justifica ideea de bază: validare și verificare.
• Pentru proiecte mici și mijlocii în care cerințele sunt clar definite și fixate.
• In conditiile de disponibilitate a inginerilor cu calificarile necesare, in special a testatorilor.

3. „Model incremental”

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 un cititor DefView și apoi o rețea biblioteci electronice Vivaldi.

Să descriem esența unui increment ca exemplu. 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 dorit... A apărut elementul rădăcină al arhitecturii - serverul central Vivaldi, care acționează ca un singur motor de căutare pe toate serverele de stocare instalate în diferite instituții.

Când să folosiți un model incremental?

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

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

Model dezvoltare rapida aplicațiile includ următoarele faze:

• Modelarea afacerilor: definirea unei liste de fluxuri de informații între diferite departamente.
• Modelarea datelor: Informațiile adunate în pasul anterior sunt folosite pentru a defini obiectele și alte entități necesare pentru a circula informațiile.
• Modelarea proceselor: fluxurile de informații leagă obiectele pentru a atinge obiectivele de proiectare.
• Creați aplicația: utilizează instrumente de auto-build pentru a converti modelele CAD în cod.
• Testare: noi componente și interfețe sunt testate.

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 ales cu cunoștințe sigure afacerea tintași necesitatea producției urgente a sistemului în 2-3 luni.

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

Într-o metodologie de dezvoltare „agilă”, după fiecare iterație, clientul poate observa rezultatul și poate înțelege dacă este mulțumit de acesta sau nu. Acesta este unul dintre avantajele unui model flexibil. Dezavantajele sale includ faptul că, din cauza lipsei unor formulări specifice de rezultate, este dificil de estimat costurile cu forța de muncă și costurile necesare dezvoltării. Programare extremă(XP) este una dintre cele mai cunoscute utilizări practice ale modelului agil.

Acest tip se bazează pe întâlniri zilnice scurte numite „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ă:

• un raport despre 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 muncii.

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ă, într-un model flexibil, doar puțină planificare este suficientă pentru a începe un proiect.

6. „Model iterativ”

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 culori, 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ă este un element coerent.

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ă, la început - î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ă pe deplin.

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

• Cerințe pentru sistem final clar definite și de înțeles în prealabil.
• Proiectul este mare sau foarte mare.
• Principala provocare trebuie definită, dar detaliile de implementare pot evolua în timp.

7. „Model în spirală”

Modelul Spiral 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 fața noilor linii de produse, atunci când este necesar. cercetare științificăși teste practice.

Modelul spirală presupune 4 etape pentru fiecare buclă:

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

Să rezumam

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

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

Despre tehnologiile de dezvoltare:
.
.
.
.

Ce metodologii folosesti?

Astăzi, procesul de creare complex aplicații software este imposibil de imaginat fără împărțirea în etape ale ciclului de viață. Prin ciclul de viață al unui program înțelegem un set de etape:

• Analiza domeniului subiect și realizarea specificațiilor tehnice (interacțiunea cu clientul)
• Proiectarea structurii programului
• Codare (set de cod de program conform documentației proiectului)
• Testare și depanare
• Implementarea programului
• Suport program
• Eliminare

Luați în considerare tipurile de diagrame pentru vizualizarea modelului (acest lucru este obligatoriu, deși există mai multe tipuri):

Diagrama de caz de utilizare

Diagrama de clasă

Diagrama de stare (diagrama de stat)

Diagrama secvenței

Diagrama de colaborare

Diagrama componentelor

Diagrama de implementare

Aceasta încheie turul nostru de prezentare generală a diagramelor în special și a designului în general. Este demn de remarcat faptul că procesul de proiectare a devenit de mult standardul pentru dezvoltarea de software, dar de multe ori trebuie să se ocupe de un program superb scris, care, din cauza lipsei documentației normale, devine supraîncărcat cu funcționalități laterale inutile, cârje, devine greoaie. și își pierde calitatea anterioară. = (

Sunt convins că un programator este în primul rând un codificator - NU trebuie să comunice cu clientul, NU ar trebui să se gândească la arhitectura sistemului, nu ar trebui să inventeze o interfață cu programul, ar trebui doar să codeze - să implementeze algoritmi, funcționalități, aspect, utilizare, dar nu mai mult... Designerul, pe de altă parte, ar trebui să plece de la diagrame abstracte (descriind domeniul subiectului) la diagrame reprezentând structura datelor, claselor și procesele de interacțiune a acestora, pentru a picta totul pas cu pas în detaliu. Adică, complexitatea muncii și salariul designerului ar trebui să fie cu un ordin de mărime mai mare decât cel al programatorului == codificatorului. Scuze pentru răzvrătire...