Abordare sistematică a dezvoltării software. Aspecte temporale și „spațiale” ale abordării sistemelor. Modelul ciclului de viață al software-ului în cascadă. Principii generale și abordări ale dezvoltării software. Modele de dezvoltare software Waterfall Model Cascade Software Spiral Extreme

Modele de dezvoltare software Waterfall Waterfall Model Spiral Extreme Programming UI Prototyping Incremental W-Model Testing Unified Software Development Process (USDP) Metodologie MSF

Model cascadă Analiza cerințelor Dezvoltarea unei specificații de produs Proiectarea Dezvoltarea unei arhitecturi de produs Implementarea Dezvoltarea codului sursă Integrarea părților individuale ale codului sursă Testarea și eliminarea defectelor

Programare extremă Analiza cerințelor inițiale Proiectare Integrare Implementare Testare Noi cerințe Analiză/Aprobare/Modificare plan de dezvoltare Lansarea produsului

UI Prototyping Lansarea produsului Dezvoltare software ținând cont de modificări Clarificarea cerințelor și specificațiilor Modificarea prototipului și finalizarea unor funcționalități Funcționalitate de bază Prototip de interfață Specificație preliminară

Dezvoltare incrementală Iterația 1 Iterația 2…. Analiza cerințelor Proiectare Implementare Testarea componentelor Integrare Testarea întregii Iterații N

Procesul de dezvoltare software unificat (USDP) Ø Model de caz de utilizare, descrie cazurile în care va fi utilizată aplicația. Ø Modelul analitic descrie clasele de baza pentru aplicatie. Ø Modelul de proiectare descrie conexiunile și relațiile dintre clase și obiectele alocate Ø Modelul de implementare descrie distribuția software-ului între computere. Ø Modelul de implementare descrie organizarea internă a codului programului. Ø Un model de testare constă din componente de testare, proceduri de testare și diferite opțiuni de testare.

Procesul unificat de dezvoltare a software-ului (USDP) Adunarea cerințelor Iter 1…. Iter N Design Iter 1…. Iter N Implementare Iter 1…. Iter N Construction Iter 1…. Iter N Testare Iter 1…. Iter N

Componente tipice ale arhitecturii unui produs software și cerințe tipice pentru software Ø Ø Ø Ø Organizarea programelor Clase de bază ale sistemului Organizarea datelor Reguli de afaceri Interfață cu utilizatorul Gestionarea resurselor Securitate Performanță Scalabilitate Interacțiune cu alte sisteme (integrare) Internaționalizare, localizare Intrare-ieșire a datelor Gestionarea erorilor

Componentele tipice ale arhitecturii unui produs software și cerințele software tipice Toleranța la erori este un set de proprietăți ale sistemului care mărește fiabilitatea acestuia prin detectarea erorilor, recuperarea și localizarea consecințelor negative pentru sistem. La proiectarea oricărui sistem real pentru a asigura toleranța la defecțiuni, este necesar să se prevadă toate situațiile posibile care pot duce la defecțiuni ale sistemului și să se dezvolte mecanisme pentru gestionarea defecțiunilor. Fiabilitatea este capacitatea unui sistem de a rezista la diverse defecțiuni și defecțiuni. Eșecul este trecerea unui sistem la o stare complet inoperabilă ca urmare a unei erori. Eșecul este o eroare în funcționarea sistemului care nu duce la defecțiunea sistemului. Cu cât sunt mai puține defecțiuni și defecțiuni într-o anumită perioadă de timp, cu atât sistemul este considerat mai fiabil.

Componente tipice ale arhitecturii unui produs software și cerințe tipice pentru software Curba de fiabilitate N t 1 t Cu cât mergeți mai departe, cu atât va fi mai greu să găsiți o eroare. Cu cât sistemul este mai complex, cu atât este mai mare probabilitatea defecțiunilor și defecțiunilor.

Componente tipice ale arhitecturii unui produs software și cerințe tipice software Ø Posibilitatea implementării arhitecturii dezvoltate. Ø Functionalitate redundanta. Ø Luarea deciziei de a cumpăra componente software gata făcute. Ø Schimbarea strategiei.

O listă de întrebări care vă permite să trageți o concluzie despre calitatea arhitecturii: Ø Este clar descrisă organizarea generală a programului; Ø Ø Ø Specificația include o privire de ansamblu asupra arhitecturii și a rațiunii sale. Componentele majore ale programului, responsabilitățile și interacțiunile lor cu alte componente sunt definite în mod adecvat? Dacă toate funcțiile specificate în specificația cerințelor sunt implementate de un număr rezonabil de componente ale sistemului. Există o descriere a celor mai importante clase și a rațiunii lor? Este oferită o descriere a organizării bazei de date? Sunt definite toate regulile de afaceri? Este descris impactul lor asupra sistemului?

O listă de întrebări care vă permite să trageți o concluzie despre calitatea arhitecturii: Ø Este descrisă strategia de proiectare a interfeței cu utilizatorul? ØEste interfața cu utilizatorul făcută modulară, astfel încât modificările aduse acesteia să nu afecteze restul sistemului. Ø Există o descriere a strategiei de intrare/ieșire a datelor? ØA fost efectuată o analiză de performanță a sistemului care va fi implementat folosind această arhitectură? ØA fost efectuată o analiză de fiabilitate a sistemului proiectat? ØA fost efectuată o analiză a problemelor de scalabilitate și extensibilitate a sistemului?

Refactorizarea software Refactorizarea implică adaptarea software-ului la noul hardware și la noile sisteme de operare, noi instrumente de dezvoltare, noi cerințe, precum și arhitectura și funcționalitatea software. Aceasta este o modificare a structurii interne a software-ului fără modificarea comportamentului său extern, menită să asigure modificarea software-ului. Motive rezonabile pentru refactorizare: Codul se repetă; implementarea metodei este prea mare; există prea multă imbricare de bucle sau bucla în sine este foarte mare; clasa are conectivitate slabă (proprietățile și metodele clasei ar trebui să descrie doar 1 obiect); o interfață de clasă nu formează o abstractizare consistentă; Metoda ia prea mulți parametri. Este necesar să se încerce să se păstreze numărul de parametri rezonabil de minim; părțile individuale ale clasei se schimbă independent de celelalte părți ale clasei;

Refactorizarea software: Când schimbați un program, mai multe clase trebuie schimbate în paralel. Dacă apare o astfel de situație, este necesară reorganizarea cursurilor pentru a minimiza locurile de posibile schimbări în viitor; trebuie să modificați mai multe ierarhii de moștenire în paralel; trebuie să schimbați mai multe blocuri de caz. Este necesar să modificați programul în așa fel încât să implementați blocul de caz și să îl numiți de numărul necesar de ori în program; elementele de date asociate utilizate împreună nu sunt organizate în clase. Dacă utilizați în mod repetat același set de elemente de date, atunci este util să luați în considerare combinarea acestor date și plasarea operațiunilor efectuate asupra lor într-o clasă separată;

Metoda de refactorizare software folosește mai multe elemente ale unei alte clase decât ale sale. Aceasta înseamnă că metoda trebuie mutată într-o altă clasă și apelată din cea veche; tipul de date primitiv este supraîncărcat. Pentru a descrie o entitate din lumea reală, este mai bine să folosiți o clasă decât să supraîncărcați un tip de date existent; Clasa are o funcționalitate prea limitată. Este mai bine să scăpați de această clasă mutându-și funcționalitatea într-o altă clasă; Datele „rătăcite” sunt transmise de-a lungul unui lanț de metode. Datele care sunt transmise unei metode doar pentru ca aceasta să le transmită unei alte metode se numesc „rătăcite”. Dacă apar astfel de situații, încercați să schimbați arhitectura claselor și metodelor pentru a scăpa de ele.

Refactorizarea obiectului proxy software nu face nimic. Dacă rolul unei clase este de a redirecționa apelurile de metodă către alte clase, atunci cel mai bine este să eliminați un astfel de obiect intermediar și să faceți apeluri către alte clase direct; o clasă știe prea multe despre o altă clasă. În această situație, este necesar să se facă încapsularea mai strictă pentru a se asigura că moștenitorul are cunoștințe minime despre părintele său; metoda are un nume nefericit; membrii datelor sunt publici. Acest lucru estompează linia dintre interfață și implementare, întrerupe inevitabil încapsularea și limitează flexibilitatea programului; plasați comentarii în codul sursă;

Subclasa de refactorizare software folosește doar o mică parte din metodele strămoșilor săi. Această situație apare atunci când o nouă clasă este creată doar pentru a moșteni mai multe metode din clasa de bază și nu pentru a descrie vreo entitate nouă. Pentru a evita acest lucru, este necesar să se transforme clasa de bază astfel încât să ofere noii clase acces numai la metodele de care are nevoie; codul conține variabile globale. Numai acele variabile care sunt utilizate efectiv de întregul program ar trebui să fie globale. Toate celelalte variabile trebuie să fie fie locale, fie trebuie să devină proprietăți ale unor obiecte; programul conține cod care poate fi necesar într-o zi. Când se dezvoltă un sistem, este recomandabil să se asigure locuri unde codul sursă poate fi adăugat în viitor.

Model cascadă Analiza cerințelor Proiectare Implementare Integrare Testare Crearea unei specificații de produs Crearea unei arhitecturi de produs Dezvoltarea codului sursă Integrarea părților individuale ale codului sursă Testarea și eliminarea defectelor

Modelul de caz de utilizare Unified Software Development Process (USDP) descrie cazurile în care va fi utilizată aplicația. Modelul analitic descrie clasele de bază pentru aplicație. Modelul de proiectare descrie conexiunile și relațiile dintre clase și obiectele alocate. Modelul de implementare descrie distribuția software-ului între computere. Modelul de implementare descrie organizarea internă a codului programului. Un model de testare constă din componente de testare, proceduri de testare și diferite cazuri de testare.

Componente tipice ale arhitecturii unui produs software și cerințe tipice de software Organizarea programelor Clasele de sistem de bază Organizarea datelor Reguli de afaceri Interfață cu utilizatorul Gestionarea resurselor Securitate Performanță Scalabilitate Interacțiune cu alte sisteme (integrare) Internaționalizare, localizare Intrare/ieșire date Gestionarea erorilor

Componente tipice ale arhitecturii unui produs software și cerințe tipice de software Posibilități de implementare a arhitecturii dezvoltate. Posibilitatea implementării arhitecturii dezvoltate. Funcționalitate redundantă. Funcționalitate redundantă. Luarea deciziei de a cumpăra componente software gata făcute. Luarea deciziei de a cumpăra componente software gata făcute. Schimbați strategia. Schimbați strategia.

Organizarea generală a programului este descrisă în mod clar; dacă specificația include o privire de ansamblu asupra arhitecturii și a rațiunii sale. Organizarea generală a programului este descrisă în mod clar; dacă specificația include o privire de ansamblu asupra arhitecturii și a rațiunii sale. Componentele majore ale programului, responsabilitățile și interacțiunile lor cu alte componente sunt definite în mod adecvat? Componentele majore ale programului, responsabilitățile și interacțiunile lor cu alte componente sunt definite în mod adecvat? Dacă toate funcțiile specificate în specificația cerințelor sunt implementate de un număr rezonabil de componente ale sistemului. Dacă toate funcțiile specificate în specificația cerințelor sunt implementate de un număr rezonabil de componente ale sistemului. Există o descriere a celor mai importante clase și a rațiunii lor? Există o descriere a celor mai importante clase și a rațiunii lor? Este oferită o descriere a organizării bazei de date? Este oferită o descriere a organizării bazei de date? Sunt definite toate regulile de afaceri? Sunt definite toate regulile de afaceri? Este descris impactul lor asupra sistemului? Este descris impactul lor asupra sistemului? O listă de întrebări care vă permite să trageți o concluzie despre calitatea arhitecturii:

Lista de verificare a întrebărilor care vă permite să judecați calitatea arhitecturii: Este descrisă strategia de proiectare a interfeței cu utilizatorul? Este descrisă strategia de proiectare a interfeței cu utilizatorul? Interfața utilizatorului este modulară, astfel încât modificările aduse acesteia să nu afecteze restul sistemului. Interfața utilizatorului este modulară, astfel încât modificările aduse acesteia să nu afecteze restul sistemului. Există o descriere a strategiei de intrare/ieșire a datelor? Există o descriere a strategiei de intrare/ieșire a datelor? A fost analizată performanța sistemului care va fi implementat folosind această arhitectură? A fost analizată performanța sistemului care va fi implementat folosind această arhitectură? A fost efectuată analiza de fiabilitate a sistemului proiectat? A fost efectuată analiza de fiabilitate a sistemului proiectat? A fost analizată scalabilitatea și extensibilitatea sistemului? A fost analizată scalabilitatea și extensibilitatea sistemului?

Codul de refactorizare software este repetat; implementarea metodei este prea mare; există prea multă imbricare de bucle sau bucla în sine este foarte mare; clasa are conectivitate slabă (proprietățile și metodele clasei ar trebui să descrie doar 1 obiect); o interfață de clasă nu formează o abstractizare consistentă; Metoda ia prea mulți parametri. Este necesar să se încerce să se păstreze numărul de parametri rezonabil de minim; părțile individuale ale clasei se schimbă independent de celelalte părți ale clasei; Refactorizarea presupune adaptarea software-ului la noul hardware și noile sisteme de operare, noi instrumente de dezvoltare, noi cerințe, precum și arhitectura și funcționalitatea software. Aceasta este o modificare a structurii interne a software-ului fără modificarea comportamentului său extern, menită să asigure modificarea software-ului. Motive rezonabile pentru refactorizare:

Refactorizarea software: Când schimbați un program, mai multe clase trebuie schimbate în paralel. Dacă apare o astfel de situație, este necesară reorganizarea cursurilor pentru a minimiza locurile de posibile schimbări în viitor; trebuie să modificați mai multe ierarhii de moștenire în paralel; trebuie să schimbați mai multe blocuri de caz. Este necesar să modificați programul în așa fel încât să implementați blocul de caz și să îl numiți de numărul necesar de ori în program; elementele de date asociate utilizate împreună nu sunt organizate în clase. Dacă utilizați în mod repetat același set de elemente de date, atunci ar putea merita să luați în considerare combinarea acestor date și plasarea operațiunilor efectuate asupra lor într-o clasă separată;

Metoda de refactorizare software folosește mai multe elemente ale unei alte clase decât ale sale. Aceasta înseamnă că metoda trebuie mutată într-o altă clasă și apelată din cea veche; tipul de date primitiv este supraîncărcat. Pentru a descrie o entitate din lumea reală, este mai bine să folosiți o clasă decât să supraîncărcați un tip de date existent; Clasa are o funcționalitate prea limitată. Este mai bine să scăpați de această clasă mutându-i funcționalitatea într-o altă clasă; Datele „rătăcite” sunt transmise de-a lungul unui lanț de metode. Datele care sunt transmise unei metode doar pentru a fi transmise către o altă metodă se numesc „rătăcite”. Dacă apar astfel de situații, încercați să schimbați arhitectura claselor și a metodelor pentru a scăpa de ele.

Subclasa de refactorizare software folosește doar o mică parte din metodele strămoșilor săi. Această situație apare atunci când o nouă clasă este creată doar pentru a moșteni mai multe metode din clasa de bază și nu pentru a descrie vreo entitate nouă. Pentru a evita acest lucru, este necesar să se transforme clasa de bază astfel încât să ofere noii clase acces doar la metodele de care are nevoie; codul conține variabile globale. Numai acele variabile care sunt utilizate efectiv de întregul program ar trebui să fie globale. Toate celelalte variabile trebuie să fie fie locale, fie trebuie să devină proprietăți ale unor obiecte; programul conține cod care poate fi necesar într-o zi. Când dezvoltați un sistem, este recomandabil să furnizați locuri unde codul sursă poate fi adăugat în viitor.

Când luăm în considerare tehnologia de dezvoltare software, este necesar să folosim o abordare sistematică, care implică luarea în considerare nu a unor aspecte individuale ale problemei dezvoltării software, ci a problemei în ansamblu. Abordarea sistemelor este implementată în spațiu și timp.

O abordare sistematică în timp ia în considerare succesiunea etapelor de creare a software-ului din momentul formării unei nevoi nesatisfăcute de software pana se rezolvași suport în operarea produsului software rezultat.

Abordare sistematică în „spațiu” implică luarea în considerare a software-ului dezvoltat ca parte a sistemului. Totodată, pe baza studierii nevoilor de informații ale sistemului, care va include software-ul dezvoltat, se formulează obiectivele și setul de funcții software și se analizează prototipurile software. Cerințele software sunt generate și documentate.

Tehnologia modernă de dezvoltare software consideră programarea ca una dintre etapele de dezvoltare dintr-un lanț de etape succesive ale ciclului de dezvoltare. Toate aceste etape sunt unite de conceptul de ciclu de viață al software-ului și trebuie susținute de instrumente software și hardware adecvate.

În conformitate cu standardul internațional ISO/IEC 12207 „Tehnologia informației - Procese ciclului de viață software”, procesul de dezvoltare a software-ului conține următoarele etape ale ciclului de viață al software-ului:

1) analiza cerințelor sistemului și domeniului de aplicare;

2) proiectarea arhitecturii sistemului;

3) analiza cerințelor software (specificații, interfețe externe);

4) proiectarea arhitecturii software;

5) proiectarea detaliată a fiecărei unități software;

6) codare software (programare)

7) testarea unităților software;

8) integrarea (combinația de software) și testarea unui set de unități software;

9) teste de calificare software (testare cuprinzătoare);

10) unitățile de structură software de integrare a sistemului trebuie să fie integrate cu unitățile hardware;

11) teste de calificare a sistemului;

12) instalarea software-ului.

Astfel, procesul de dezvoltare software începe de la sistemul în care software-ul va fi utilizat și se termină din nou în sistem.

După etapele de dezvoltare din ciclul de viață al software-ului, urmează etapa de operare și întreținere a software-ului în timpul funcționării. Uneori se oferă o listă de etape ale ciclului de viață al software-ului cu unele generalizări (măriri) ale celor 12 etape date. De exemplu, etapele de proiectare a sistemului și determinarea cerințelor software, proiectarea pachetului software, proiectarea algoritmului software, programarea (codarea), depanarea software autonomă, depanarea software integrată, operarea software-ului.

Neglijând etapele proiectării software-ului, dorința de a începe imediat programarea fără a elabora suficient algoritmi și problemele de interacțiune a unităților structurale software duce adesea la un proces haotic de dezvoltare a software-ului cu șanse reduse de succes.

Model spiralat al ciclului de viață al software-ului. Tehnologii de dezvoltare software „grele și ușoare” (rapide).

Modelul ciclului de viață (LC) considerat este un model de tip cascadă. Acest tip de model de ciclu de viață este bun pentru software pentru care este posibil să se formuleze complet și precis toate cerințele software chiar la începutul dezvoltării.

Schema unui software de ciclu de viață în spirală. Cu toate acestea, procesul real de creare a software-ului nu se încadrează întotdeauna într-o schemă atât de rigidă și de multe ori este nevoie de a reveni la etapele anterioare cu clarificare sau revizuire a deciziilor luate.

Software-ul, ca și alte sisteme complexe pentru care cerințele inițiale nu sunt suficient de complete, se caracterizează printr-un proces iterativ de dezvoltare. Mai mult, pentru unele tipuri de software este chiar de dorit să treceți la etapa următoare cât mai repede posibil. În același timp, deficiențele care sunt inevitabile cu o astfel de muncă grăbită sunt eliminate la următoarea iterație sau rămân pentru totdeauna.

Sarcina principală este de a realiza un software de lucru cât mai repede posibil, activând astfel procesul de clarificare și completare a cerințelor. Acesta este așa-numitul model spiral al ciclului de viață al software-ului.

La fiecare tură a spiralei, este creată o versiune a produsului, sunt specificate cerințele software și este planificată activitatea următoarei ture. Modelul spiralat al ciclului de viață al software-ului reflectă procesul existent în mod obiectiv de dezvoltare iterativă a software-ului (Fig. 8.2).

Se crede că schema spirală a ciclului de viață a software-ului este destinată nu atât dezvoltatorilor grăbiți, cât și software-ului ale căror prime versiuni de calitate scăzută sunt acceptabile pentru scopul funcțional al software-ului.

Există o direcție de „Tehnologii rapide” de dezvoltare software (Agile Software Development), care oferă o justificare ideologică pentru opiniile asociate cu modelul spiral al ciclului de viață. Aceste tehnologii se bazează pe patru idei:

Interacțiunea interactivă a indivizilor este mai importantă decât procedurile și instrumentele formale,

Software-ul care funcționează este mai important decât a avea documentație pentru el,

Cooperarea cu clientul este mai importantă decât contractele formale,

Răspunsul rapid la schimbările externe este mai important decât respectarea strictă a planurilor.

Orez. 8.2 - Schema software-ului ciclului de viață în spirală

Cu alte cuvinte, tehnologiile rapide vizează înlocuirea procedurilor de interacțiune documentate formale și intensive în muncă în timpul dezvoltării cu unele interactive, ceea ce este posibil cu o dimensiune redusă a proiectului, calități ale angajaților selectate, plasarea dezvoltatorilor și clienții „în aceeași cameră” și pentru dezvoltarea software pentru sisteme necritice.

Corectitudinea acestor principii într-o anumită măsură, atunci când dezvoltarea de software este realizată de un număr mic de „fani”) calificați și dedicați pentru dezvoltarea anumitor tipuri de software, este greu de contestat. Cu toate acestea, tehnologiile Agile și ideologii lor recunosc acest lucru, sunt aplicabile în proiectele software de o anumită clasă și scară, la fel ca modelul ciclului de viață în spirală în general, și anume acolo unde erorile software duc la unele inconveniente sau pierderi de fonduri recuperabile.

În cazul în care software-ul defectuos duce la o amenințare la adresa vieții umane sau la pierderi materiale mari, ar trebui utilizate tehnologii cuprinzătoare și bine gândite pentru a asigura fiabilitatea produsului software.

Odată cu creșterea dimensiunii unui proiect software și creșterea numărului de persoane care participă la acesta, crește nevoia de tehnologie de dezvoltare rigidă care alcătuiește un ciclu de viață software în cascadă. Aici este nevoie de documentare, deoarece pierderea oricăruia dintre dezvoltatori este posibilă în orice moment, este necesară oficializarea conexiunilor între programe, gestionarea modificărilor software etc. Nu degeaba modelul ciclului de viață în cascadă este inclus în software. standarde de dezvoltare. În același timp, vă permite, de asemenea, să implementați un proces de dezvoltare iterativ datorită etapelor stipulate în proiectarea STS și software pentru acestea.

Pentru proiectele software foarte mari (o echipă de dezvoltatori de peste 100), tehnologia de dezvoltare este un factor cheie care influențează nu numai calitatea software-ului, ci și însăși posibilitatea creării acestuia.

Tehnologii de dezvoltare software „grele și ușoare”. . Dezvoltatorii multor tipuri de software consideră că modelul ciclului de viață al cascadei este prea înregimentat, prea documentat și greu și, prin urmare, irațional. Există o direcție de „Tehnologii rapide” (tehnologii ușoare) de dezvoltare software (Agile Software Development), care oferă o justificare ideologică pentru aceste opinii. Aceste tehnologii se bazează pe patru idei:

1. interacțiunea interactivă a indivizilor este mai importantă decât procedurile și instrumentele formale,

2. software-ul care funcționează este mai important decât a avea documentație pentru el,

3. cooperarea cu clientul este mai importantă decât contractele formale cu acesta,

4. răspunsul rapid la schimbările externe este mai important decât respectarea strictă la planurile planificate.

Corectitudinea acestor principii, cu excepția celui de-al treilea într-o anumită măsură (dezvoltarea software-ului este realizată de un număr mic de programatori calificați - „fani” care nu au nevoie de control și motivație suplimentară) pentru dezvoltarea de software este dificil de contestat. Cu toate acestea, tehnologiile Agile, și acest lucru este recunoscut de ideologii lor, sunt aplicabile în proiectele software de o anumită clasă și scară, precum și modelul ciclului de viață în spirală în general, și anume acolo unde erorile software duc la unele inconveniente sau pierderi de fonduri recuperabile și unde cerințele software sunt în continuă schimbare, deoarece au fost prost definite în prealabil și este necesară o adaptare rapidă la aceste schimbări.

tehnologii rapide -încearcă să ajungă la un compromis între disciplina strictă a dezvoltării și absența sa completă în numele reducerii fluxului de lucrări care însoțesc dezvoltarea Tehnologiile rapide nu pot asigura o fiabilitate ridicată a unui produs software tocmai din cauza minimizării lucrărilor care confirmă legal responsabilitatea dezvoltatorului. .

Un exemplu de tehnologii Agile este Extreme Programming (XP). Iterațiile în XP sunt foarte scurte și constau în patru operațiuni: codificare, testare, ascultare a clientului, proiectare. Principiile XP - minimalism, simplitate, participarea clientului, ciclu scurt, interacțiune strânsă între dezvoltatori - ar trebui să stea în aceeași cameră, întâlnirile operaționale zilnice cu clientul par rezonabile și au fost folosite de mult timp nu numai în tehnologiile rapide, ci și în XP. sunt duse la valori extreme.

O analiză a multor proiecte software a arătat că tehnologiile ușoare care propovăduiesc principiile auto-organizării, punând accent pe utilizarea abilităților individuale ale dezvoltatorilor, iterații scurte de dezvoltare într-un model în spirală, XP, SCRUM sunt comune și adesea conduc la succes, făcând cele mai multe caracteristici ale lucrului în echipe mici.

În cazul în care software-ul care funcționează incorect duce la o amenințare la adresa vieții umane sau la pierderi materiale mari, ar trebui utilizate tehnologii „grele” oficializate ordonate, pe deplin gândite și previzibile, asigurând fiabilitatea produsului software chiar și în cazul dezvoltatorilor cu calificare medie. Odată cu creșterea dimensiunii proiectului software, creșterea numărului de participanți În acest domeniu, este în creștere nevoia unei tehnologii de dezvoltare rigide și formale care să stabilească responsabilitatea fiecărui participant la dezvoltare care alcătuiește ciclul de viață al software-ului în cascadă. . Nu degeaba modelul ciclului de viață în cascadă este inclus în standardele de dezvoltare software.

În echipele mari de dezvoltare, problema managementului iese în prim-plan.

Pentru proiectele software foarte mari, problemele de dezvoltare ordonată, coordonată: structurarea, integrarea, asigurarea interacțiunii corecte a programelor, organizarea implementării corecte și coordonate a schimbărilor inevitabile sunt cheie. și influențează însăși posibilitatea creării lor.

În proiectele software mici, perfecționările algoritmice și influența indivizilor talentați individuali joacă un rol decisiv, în timp ce în proiectele mari acești factori sunt nivelați și nu au o influență decisivă asupra progresului dezvoltării.

Dezvoltatorii de software cu capacități medii, care este majoritatea și care mențin disciplina tehnologică în cadrul tehnologiei potrivite, trebuie să dezvolte software de calitatea cerută. „Păstrează ordinea și el te va sprijini.”

Deci, esența abordării structurale a dezvoltării software EIS constă în descompunerea (defalcarea) acestuia în funcții automate: sistemul este împărțit în subsisteme funcționale, care, la rândul lor, sunt împărțite în subfuncții, cele în sarcini și așa mai departe până la proceduri specifice. În același timp, sistemul menține o viziune holistică în care toate componentele sunt interconectate. Când se dezvoltă un sistem „de jos în sus”, de la sarcini individuale la întregul sistem, integritatea se pierde și apar probleme la descrierea interacțiunii informaționale a componentelor individuale.

Toate cele mai comune metode ale abordării structurale se bazează pe o serie de principii generale:

1. Principiul „împărți și cuceri”;

2. Principiul ordonării ierarhice este principiul organizării componentelor unui sistem în structuri arborescente ierarhice cu adăugarea de noi detalii la fiecare nivel.

Izolarea a două principii de bază nu înseamnă că principiile rămase sunt secundare, deoarece ignorarea oricăreia dintre ele poate duce la consecințe imprevizibile (inclusiv eșecul întregului proiect”). Principalele principii ale acestor principii sunt:

1. Principiul abstracției - evidențierea aspectelor esențiale ale sistemului și abstracția de la cele neimportante.

2. Principiul consistenței, validității și consistenței elementelor sistemului.

3. Principiul structurării datelor – datele trebuie să fie structurate și organizate ierarhic.

În abordarea structurală, există în principal două grupuri de instrumente care descriu structura funcțională a sistemului și relațiile dintre date. Fiecare grup de instrumente corespunde anumitor tipuri de modele (diagrame), cele mai comune dintre ele sunt:

· DFD (Data Flow Diagrams) - diagrame de flux de date;

· SADT (Structured Analysis and Design Technique - metodologie de analiză structurală și proiectare) - modele și diagrame funcționale corespunzătoare: notații IDEF0 (modelarea funcțională a sistemelor), IDEF1х (modelarea conceptuală a bazelor de date), IDEF3х (construcția sistemelor de evaluare a calității munca unui obiect; descrierea grafică a proceselor de flux, interacțiunea proceselor și a obiectelor care sunt modificate de aceste procese);

· ERD (Entity - Relationship Diagrams) - diagrame entitate-relație.

Aproape toate metodele abordării structurale (analiza structurală) în etapa formării cerințelor software utilizează două grupuri de instrumente de modelare:

1. Diagrame care ilustrează funcțiile pe care trebuie să le îndeplinească sistemul și relațiile dintre aceste funcții - DFD sau SADT (IDEF0).

2. Diagrame care modelează datele și relațiile lor (ERD).

Forma specifică a diagramelor enumerate și interpretarea proiectelor acestora depind de stadiul ciclului de viață al software-ului.

În etapa de formare a cerințelor software, modelele SADT și DFD sunt folosite pentru a construi modelul „AS-IS” și modelul „TO-BE”, reflectând astfel structura existentă și propusă a proceselor de afaceri ale organizației și interacțiunea dintre acestea ( utilizarea modelelor SADT, deoarece sunt de obicei limitate doar la această etapă, deoarece nu au fost inițial destinate proiectării software). Cu ajutorul ERD se realizează o descriere a datelor utilizate în organizație la nivel conceptual, indiferent de instrumentele de implementare a bazei de date (DBMS).

Adnotare: Sunt luate în considerare abordarea flexibilă a creării de software și principiile de bază ale dezvoltării flexibile. Este furnizată o listă de tehnici care, într-o anumită măsură, corespund principiilor dezvoltării software flexibile. Sunt analizate valorile și principiile cheie ale dezvoltării agile.

Puteți descărca prezentarea pentru această prelegere.

Scopul prelegerii:

Obțineți o înțelegere a scopului și a principiilor de bază ale dezvoltării software agile.

Introducere

Metodologie de dezvoltare software agilă se concentrează pe utilizarea unei abordări iterative, în care software este creat treptat, în pași mici, inclusiv implementarea unui set specific de cerințe. Se presupune că cerințele se pot schimba. Echipele Agile sunt formate din dezvoltatori versatili care îndeplinesc diverse sarcini în procesul de creare a unui produs software.

Atunci când se utilizează metodologii agile, riscurile sunt minimizate prin reducerea dezvoltării la o serie de cicluri scurte numite iterații, cu durata de 2-3 saptamani. O iterație este un set de sarcini programate pentru a fi finalizate într-o anumită perioadă de timp. În fiecare iterație, este creată o versiune funcțională a sistemului software, care implementează cea mai mare prioritate (pentru această iterație) cerintele clientului. Fiecare iterație îndeplinește toate sarcinile necesare pentru a crea software de lucru: planificare, analiza cerințelor, proiectare, codificare, testare și documentație. Deși o singură iterație nu este, în general, suficientă pentru a lansa o nouă versiune a unui produs, aceasta implică că actuala software gata de lansare la sfârșitul fiecărei iterații. La sfârșitul fiecărei iterații, echipa reevaluează prioritățile cerințelor pentru produsul software, eventual făcând ajustări la dezvoltarea sistemului.

Principiile și semnificația dezvoltării agile

Metodologia de dezvoltare agilă a declarat postulate cheie care permit echipelor să atingă o productivitate ridicată:

oamenii și interacțiunile lor;
livrare de software de lucru;
cooperarea cu clientul;
reacție la schimbare.

Oameni și interacțiune. Oamenii sunt cea mai importantă componentă a succesului. Membrii individuali ai echipei și o bună comunicare sunt importante pentru echipele performante. Pentru a facilita comunicarea, metodele agile implică discuții frecvente despre rezultatele muncii și schimbări în decizii. Discuțiile pot avea loc zilnic timp de câteva minute și la sfârșitul fiecărei iterații cu o analiză a rezultatelor lucrării și o retrospectivă. Pentru o comunicare eficientă în timpul întâlnirilor, membrii echipei trebuie să respecte următoarele reguli cheie de conduită:

respect pentru opiniile fiecărui membru al echipei;
fii sincer în toate comunicările;
transparența tuturor datelor, acțiunilor și deciziilor;
încredere că fiecare participant va sprijini echipa;
angajamentul față de echipă și obiectivele acesteia.

Pentru a crea echipe de înaltă performanță în metodologii flexibile, pe lângă o echipă eficientă și o bună comunicare, sunt necesare instrumente software perfecte.

Software-ul de lucru este mai important decât documentația cuprinzătoare. Toate metodologiile agile subliniază necesitatea de a livra clienților mici bucăți de software de lucru la intervale specificate. Software, de regulă, trebuie să treacă nivelul de testare unitară, testare la nivel de sistem. În acest caz, cantitatea de documente ar trebui să fie minimă. În timpul procesului de proiectare, echipa ar trebui să mențină un scurt document actualizat care să conțină justificarea deciziei și o descriere a structurii.

Cooperarea cu clientul este mai importantă decât acordurile contractuale formale. Pentru ca proiectul să fie finalizat cu succes, este necesară o comunicare regulată și frecventă cu clientul. Clientul trebuie să participe în mod regulat la discuția cu privire la deciziile luate cu privire la software, să-și exprime dorințele și comentariile. Implicarea clientului în procesul de dezvoltare software este necesară pentru a crea un produs de calitate.

Răspunsul rapid la schimbare este mai important decât respectarea unui plan. Capacitatea de a răspunde la schimbare determină în mare măsură succesul unui proiect software. În timpul procesului de creare a unui produs software, cerintele clientului. Clienții de multe ori nu știu exact ce vor până când nu văd ceva care funcționează. software. Metodologiile agile caută feedback de la clienți în timpul procesului de creare a unui produs software. Capacitatea de reacție la schimbare este esențială pentru a crea un produs care să satisfacă clientul și să ofere valoare afacerii.

Principiile dezvoltării agile sunt susținute de 12 principii. Metodologiile specifice de dezvoltare agilă definesc procese și reguli care aderă mai mult sau mai puțin la aceste principii. Metodologiile flexibile pentru crearea produselor software se bazează pe următoarele principii:

Prioritatea cea mai mare este satisfacerea dorințelor clientului prin livrarea de software util într-un timp scurt, urmată de actualizări continue. Metodologiile agile implică livrarea rapidă a versiunii inițiale și actualizări frecvente. Scopul echipei este să livreze o versiune funcțională în câteva săptămâni de la începerea proiectului. În viitor, sistemele software cu funcționalități din ce în ce mai mari ar trebui să fie livrate la fiecare câteva săptămâni. Clientul poate începe operarea comercială a sistemului dacă îl consideră suficient de funcțional. De asemenea, clientul poate pur și simplu să se familiarizeze cu versiunea actuală a software-ului și să-și ofere feedback cu comentarii.
Nu ignorați cerințele în schimbare, chiar și în stadiile târzii de dezvoltare. Procesele agile permit adaptarea schimbărilor pentru a oferi clientului un avantaj competitiv. Echipele care folosesc metode agile se străduiesc să asigure o structură de program de înaltă calitate, cu impact minim al schimbărilor asupra sistemului în ansamblu.
Furnizați frecvent versiuni noi de software, la intervale de o săptămână până la două luni, cu preferință pentru termene limită mai scurte. Scopul este de a furniza un program care să răspundă nevoilor utilizatorului cu un minim de documentație însoțitoare.
Clienții și dezvoltatorii trebuie să lucreze împreună pe parcursul întregului proiect. Se crede că pentru un proiect de succes, clienții, dezvoltatorii și toate părțile interesate trebuie să comunice frecvent și pe larg pentru a îmbunătăți în mod intenționat produsul software.
Proiectele trebuie implementate de oameni motivați. Creați condiții normale de lucru pentru echipa de proiect, oferiți sprijinul necesar și încredere că membrii echipei vor duce treaba până la finalizare.
Cea mai eficientă și eficientă metodă de a transmite informații echipei de dezvoltare și de a face schimb de opinii în cadrul acesteia este conversația față în față. În proiectele agile, principalul mod de comunicare este interacțiunea umană simplă. Documentele scrise sunt create și actualizate treptat pe măsură ce software-ul este dezvoltat și numai atunci când este necesar.
Un program de lucru este principalul indicator al progresului într-un proiect. Abordarea finalizării unui proiect agil este judecată de cât de bine software-ul disponibil în prezent îndeplinește cerințele clientului.
Procesele agile promovează dezvoltarea pe termen lung. Clienții, dezvoltatorii și utilizatorii trebuie să poată menține un ritm constant la nesfârșit.
O concentrare neobosită pe excelența tehnică și designul de calitate crește impactul tehnologiilor agile. Membrii echipei Agile se străduiesc să producă cod de calitate prin refactorizare regulată.
Simplitatea este arta de a obține mai mult făcând mai puțin. Membrii echipei rezolvă problemele curente cât mai simplu și eficient posibil. Dacă apare vreo problemă în viitor, este posibil să faceți modificări la codul de înaltă calitate fără cheltuieli mari.
Cele mai bune arhitecturi, cerințe și design-uri provin de la echipe auto-organizate. În echipele agile, sarcinile sunt atribuite nu membrilor individuali, ci echipei în ansamblu. Echipa decide cum să implementeze cel mai bine cerințele clientului. Membrii echipei lucrează împreună la toate aspectele proiectului. Fiecare participant are voie să contribuie la cauza comună. Nu există niciun membru al echipei care să fie singurul responsabil pentru arhitectură, cerințe sau teste.
Echipa trebuie să se gândească în mod regulat la cum să devină și mai eficientă și apoi să își ajusteze și să își ajusteze comportamentul în consecință. O echipă agilă își ajustează continuu organizarea, regulile, acordurile și relațiile.

Principiile de mai sus, într-o anumită măsură, corespund unui număr de metodologii de dezvoltare software:

AgileModeling	un set de concepte, principii și tehnici (practici) care vă permit să efectuați rapid și ușor modelarea și documentarea în proiecte de dezvoltare software;
AgileUnifiedProcess (AUP)	o versiune simplificată a IBM RationalUnifiedProcess(RUP), care descrie o aproximare simplă și ușor de înțeles (model) pentru crearea de software pentru aplicații de afaceri;
Deschide	Este o metodă iterativă-incrementală de dezvoltare software. Poziționat ca o versiune ușoară și flexibilă a RUP;
AgileDataMethod	un grup de metode iterative de dezvoltare software în care cerințele și soluțiile sunt realizate prin colaborarea diferitelor echipe interfuncționale;
DSDM	o metodologie de dezvoltare a sistemelor dinamice bazată pe conceptul de dezvoltare rapidă a aplicațiilor (RapidApplicationDevelopment, RAD). Este o abordare iterativă și incrementală care pune accent pe implicarea continuă a utilizatorului/consumatorului în proces;
Programare extremă (XP)	programare extremă;
Dezvoltare de software adaptiv (ADD)	dezvoltare de software adaptiv;
Dezvoltare bazată pe caracteristici (FDD)	dezvoltare concentrată pe adăugarea treptată a funcționalității;
GettingReal	o abordare iterativă fără specificații funcționale utilizate pentru aplicațiile web;
MSFfogAgileSoftwareDevelopment	Metodologia flexibilă de dezvoltare a software-ului Microsoft;
Scrum	stabilește reguli pentru gestionarea procesului de dezvoltare și vă permite să utilizați practicile de codificare existente, ajustarea cerințelor sau efectuarea de modificări tactice [