Software

Procesoarele de text precum LibreOffice Writer sunt incluse în categoria de aplicații software .

Este cunoscut sub numele de software ( pronunție engleză:  /ˈsɔftˌwɛr/ ), ​suport logic sau logic pentru sistemul formal al unui sistem informatic , care include setul de componente logice necesare care face posibilă îndeplinirea unor sarcini specifice, ca spre deosebire de componentele fizice care se numesc hardware . Interacțiunea dintre software și hardware face ca un computer (sau alt dispozitiv) să fie funcțional, adică software -ul trimite instrucțiuni pe care hardware -ul le execută, făcând posibilă funcționarea.

Componentele logice includ, printre multe altele, aplicații de calculator , cum ar fi procesorul de text , care permite utilizatorului să efectueze toate sarcinile referitoare la editarea textului; așa-numitul software de sistem , cum ar fi sistemul de operare , care practic permite ca restul programelor să funcționeze corect, facilitând și interacțiunea dintre componentele fizice și restul aplicațiilor și oferind o interfață cu utilizatorul. ]

Marea majoritate a software -ului este scris în limbaje de programare de nivel înalt , deoarece sunt mai ușor și mai eficiente de utilizat pentru programatori , deoarece sunt mai aproape de limbajul natural decât limbajul mașină . Limbile de nivel înalt sunt traduse în limbajul mașină folosind fie un compilator , fie un interpret , sau o combinație a ambelor. Software-ul poate fi scris și în limbaj de asamblare , care este de nivel scăzut și are o corespondență ridicată cu instrucțiunile limbajului mașinii; este tradus în limbajul mașinii folosind un asamblator .

Software - ul de anglicism este cel mai răspândit atunci când se face referire la acest concept, în special în jargonul tehnic , în timp ce termenul sinonim „logicial”, derivat din termenul francez logiciel , este folosit mai ales în țările și zonele de influență franceză.

Etimologie

Software ( AFI:  [ˈsoft.wer] ) este un cuvânt din engleză , care în spaniolă nu are o traducere adecvată contextului, pentru care este folosit în mod regulat fără traducere și a fost astfel admis de Academia Regală Spaniolă (RAE). Deși poate să nu fie strict același, este adesea înlocuit cu expresii precum programe (de calculator) , aplicații (de calculator) sau software . ]

Software-ul este ceea ce se numește un produs în inginerie software . ]

Termenul „logicial” este o copie lexicală a termenului francez logiciel , un neologism care a fost format în 1969 din cuvintele logique („logic”) și matériel („material”) ca traducere a Delegației IT responsabilă de Planul de calcul . . ]

Definiție software

Există mai multe definiții similare acceptate pentru software , dar probabil cea mai formală este următoarea:

Este ansamblul de programe de calculator, proceduri, reguli, documentație și date asociate, care fac parte din operațiunile unui sistem informatic.

Extras din standardul IEEE 729 ]

Având în vedere această definiție, conceptul de software depășește programele de calculator în diferitele lor stări: cod sursă , binar sau executabil ; documentația sa, datele care trebuie prelucrate și chiar informațiile utilizatorului fac, de asemenea, parte din software : adică cuprinde tot ceea ce este intangibil , tot ceea ce este legat de „non-fizic”.

Termenul de software a fost folosit pentru prima dată în acest sens de John W. Tukey în 1957 . În ingineria software-ului și în știința calculatoarelor , software -ul este întreaga informație procesată de sisteme informatice : programe și date .

Conceptul de citire a diferitelor secvențe de instrucțiuni ( program ) din memoria unui dispozitiv pentru a controla calculele a fost introdus de Charles Babbage ca parte a motorului său de diferențe . Teoria care stă la baza majorității software-ului modern a fost propusă de Alan Turing în eseul său din 1936, „Numere calculabile”, cu o aplicație la problema deciziei. ]

Clasificare software

Program Finder în Ubuntu 13.10

Deși această distincție este oarecum arbitrară și uneori confuză, în scopuri practice, software-ul poate fi clasificat în trei tipuri: ]

• Software de sistem :Obiectivul său este separarea adecvată a utilizatorului și a programatorului de detaliile sistemului informatic utilizat, izolându-l în special de procesările legate de caracteristicile interne ale: memorie, discuri, porturi și dispozitive de comunicație, imprimante, ecrane, tastaturi etc Software- ulde sistemoferă utilizatorului și programatoruluiinterfețe adecvate de nivel înalt,drivere, instrumente și utilitare de asistență care permitîntreținereagenerală a sistemuluiAcesta include printre altele:
  • Sisteme de operare
  • drivere de dispozitiv
  • unelte de diagnostic
  • Instrumente de corecție și optimizare
  • servere
  • Utilități
• Software de programare :Este ansamblul de instrumente care permitprogramatoruluidezvolte programe de calculator, folosind diferite alternative șilimbaje, într-un mod practic. Acestea includ în formă de bază:
  • editori de text
  • compilatoare
  • interpreți
  • linkerii
  • epuratoare
  • Medii de dezvoltare integrate ( IDE ): Acestea grupează instrumentele anterioare, de obicei într-un mediu vizual, astfel încât programatorul să nu fie nevoie să introducă mai multe comenzi pentru a compila, interpreta, depana etc. De obicei, au o interfață grafică avansată ( GUI ).
• Software de aplicație : Este un software care permite utilizatorilor să realizeze una sau mai multe sarcini specifice, în orice domeniu de activitate care poate fi automatizat sau asistat, cu accent deosebit pe afaceri. Include printre multe altele:
  • Aplicații pentru sisteme de control și automatizări industriale
  • Aplicații de automatizare de birou
  • software educațional
  • Software de afaceri ]
  • Baze de date
  • Telecomunicații (de exemplu, Internetul și toată structura sa logică)
  • Joc video
  • software medical
  • Software de calcul numeric si simbolic .
  • Software de proiectare asistată ( CAD )
  • Software de control numeric ( CAM )

Procesul de creare a software-ului

Un „proces” este definit ca setul ordonat de pași de urmat pentru a ajunge la o soluție la o problemă sau pentru a obține un produs, în acest caz particular, pentru a realiza un produs software care rezolvă o anumită problemă.

Procesul de creare a software -ului poate deveni foarte complex, în funcție de dimensiunea, caracteristicile și criticitatea acestuia. De exemplu, crearea unui sistem de operare este o sarcină care necesită un proiect, management, numeroase resurse și o întreagă echipă disciplinată de muncă. La cealaltă extremă, dacă este un program simplu (de exemplu, rezoluția unei ecuații de ordinul doi), acesta poate fi realizat de un singur programator (chiar și un amator) cu ușurință. Astfel, acestea sunt în mod normal împărțite în trei categorii în funcție de dimensiunea lor ( linii de cod ) sau de cost: „mic”, „mediu” și „mari”. Există mai multe metodologii de estimare, una dintre cele mai populare este sistemul COCOMO care oferă metode și un software (program) care calculează și oferă o aproximare a tuturor costurilor de producție într-un „ proiect software ” (raportul om/ore, costul monetar, numărul de linii sursă în funcție de limba utilizată etc.).

Avand in vedere cele mari, este necesara indeplinirea unor sarcini complexe, atat tehnice cat si manageriale, management puternic si analize diversificate (printre altele), complexitatea acesteia a dus la dezvoltarea unei inginerie specifice care sa se ocupe de studiul si realizarea acesteia. : este cunoscut sub numele de inginerie software .

În timp ce în cele de dimensiuni medii, echipele mici de lucru (chiar și un analist-programator experimentat ) pot îndeplini sarcina. Deși, întotdeauna în cazuri medii și mari (și uneori și în unele mici, în funcție de complexitatea lor), trebuie urmate anumite etape care sunt necesare pentru construcția software -ului . Asemenea etape, deși trebuie să existe, sunt flexibile în forma lor de aplicare, în funcție de metodologia sau procesul de dezvoltare aleasă și utilizată de echipa de dezvoltare sau de programatorul-analist solo (dacă ar fi cazul).

„ Procesele de dezvoltare software ” au reguli prestabilite, și trebuie aplicate în crearea de software de dimensiuni medii și mari , deoarece în caz contrar cel mai sigur este că proiectul nu se va putea încheia sau se va încheia fără îndeplinirea obiectivelor planificate. , și cu o varietate de eșecuri inacceptabile (ele eșuează, pe scurt). Printre astfel de „procese” se numără agile sau ușoare (exemplu XP ), grele și lente (exemplu RUP ), și variante între ele. Ele sunt aplicate în mod normal în funcție de tipul și dimensiunea software -ului care urmează să fie dezvoltat, la discreția liderului (dacă există) al echipei de dezvoltare. Unele dintre aceste procese sunt Extreme Programming (în engleză eXtreme Programming sau XP), Rational Unified Process (în engleză Rational Unified Process sau RUP), Feature Driven Development ( FDD ) etc. ]

Oricare ar fi „procesul” folosit și aplicat dezvoltării software (RUP, FDD, XP, etc), și aproape independent de acesta, trebuie aplicat întotdeauna un „model de ciclu de viață”. ]

Se estimează că, din toate proiectele software mari întreprinse, 28% eșuează, 46% cad în modificări severe care le întârzie și 26% au succes total. ]

Atunci când un proiect eșuează, rareori se datorează defecțiunilor tehnice, principala cauză a eșecurilor și eșecurilor este lipsa aplicării unei metodologii sau procese de dezvoltare bune. Printre altele, o tendință puternică, de câteva decenii, este de a îmbunătăți metodologiile sau procesele de dezvoltare, sau de a crea altele noi și de a conștientiza profesioniștii IT cu privire la utilizarea corectă a acestora. În mod normal, specialiștii în studiul și dezvoltarea acestor domenii (metodologii) și domenii conexe (cum ar fi modele și chiar management de proiect) sunt ingineri software , este orientarea lor. Specialiștii din orice altă zonă a dezvoltării computerelor (analist, programator, absolvent de informatică, inginer informatic, inginer de sisteme etc.) își aplică în mod normal cunoștințele de specialitate, dar folosind modele, paradigme și procese care au fost deja dezvoltate.

Este obișnuit pentru dezvoltarea de software de dimensiuni medii ca echipele umane implicate să aplice „metodologii proprii”, de obicei un hibrid al proceselor anterioare și uneori cu propriile criterii. ]

Procesul de dezvoltare poate implica sarcini numeroase și variate, ​ de la administrativ, prin tehnic și chiar management și administrare. Dar, aproape riguros, anumite etape minime sunt întotdeauna îndeplinite ; care poate fi rezumat astfel:

• Captură, elicitare, ​ specificarea și analiza cerințelor (ERS)
• Proiecta
• Codificarea
• Teste (unitate și integrare)
• Instalare și trecere la producție
• întreținere

În etapele anterioare denumirile lor pot varia ușor, sau pot fi mai globale, sau dimpotrivă, mai rafinate; de exemplu indicați ca o singură fază (în scopuri documentare și interpretative) de „analiza și proiectare”; sau indicați ca „implementare” ceea ce se spune ca „codare”; dar strict vorbind, toate există și includ practic aceleași sarcini specifice.

Secțiunea 4 a acestui articol oferă detalii suplimentare despre fiecare dintre etapele indicate.

Modele de proces sau de ciclu de viață

Pentru fiecare dintre fazele sau etapele enumerate în articolul precedent, există sub-etape (sau sarcini). Modelul de proces sau modelul ciclului de viață utilizat pentru dezvoltare definește ordinea sarcinilor sau activităților implicate, definește, de asemenea, coordonarea dintre acestea, precum și legătura și feedback-ul lor. Dintre cele mai cunoscute putem aminti: modelul în cascadă sau secvenţial , modelul spiralat , modelul iterativ incremental . Dintre cele menționate mai sus există la rândul lor câteva variante sau alternative, mai mult sau mai puțin atractive în funcție de aplicația cerută și de cerințele acesteia. ]

Model în cascadă

Acesta, deși este mai frecvent cunoscut sub numele de modelul cascadei , este numit și „model clasic”, „model tradițional” sau „model secvenţial liniar”.

Modelul de cascadă pură „este folosit cu greu așa cum este”, deoarece aceasta ar presupune cunoașterea prealabilă și absolută a cerințelor, a nevolatilității (sau rigidității) acestora și a etapelor ulterioare fără erori; acest lucru ar putea fi aplicabil numai sistemelor rare și mici care urmează să fie dezvoltate. În aceste împrejurări, trecerea de la o etapă la alta a celor menționate ar fi fără întoarcere, de exemplu, trecerea de la proiectare la codificare ar presupune o proiectare exactă fără erori sau modificare sau evoluție probabilă: «codează ceea ce este proiectat fără erori, va exista să nu fie absolut variante viitoare. Acest lucru este utopic; întrucât în ​​mod intrinsec „ software-ul este de natură evolutivă”, schimbător și aproape lipsit de erori, atât în ​​timpul dezvoltării sale, cât și în timpul vieții sale operaționale. ]

Figura 2: Model de cascadă pur sau secvenţial pentru ciclul de viaţă al software-ului.

Orice modificare în timpul executării oricăreia dintre etapele acestui model secvenţial ar putea implica repornirea întregului ciclu de la început, ceea ce ar avea ca rezultat costuri mari de timp şi dezvoltare. Figura 2 prezintă o posibilă schemă a modelului în cauză. ]

Cu toate acestea, modelul cascadă în unele dintre variantele sale este unul dintre cele mai utilizate astăzi , datorită eficienței și simplității sale, mai mult decât orice în software -ul mic și în unele de dimensiuni medii ; dar nu este niciodată (sau foarte rar) folosit în „forma sa pură”, așa cum am menționat mai sus. În schimb, există întotdeauna un feedback între etape, care nu este nici complet previzibil, nici rigid; aceasta oferă oportunitatea dezvoltării de produse software în care există anumite incertitudini, schimbări sau evoluții pe parcursul ciclului de viață. Astfel, de exemplu, odată ce cerințele au fost surprinse și specificate (prima etapă), se poate trece la proiectarea sistemului, dar în această ultimă fază este cel mai probabil ca ajustări ale cerințelor (chiar dacă sunt minime) vor trebui realizate, fie din cauza defecțiunilor detectate, a neclarităților, fie pentru că cerințele în sine s-au schimbat sau au evoluat; cu care este necesar să revenim la prima etapă sau anterioară, să faceți reajustările pertinente și apoi să continuați din nou cu proiectarea; acesta din urmă este cunoscut sub numele de feedback. Lucrul normal în modelul cascadă este apoi aplicarea aceluiași cu etapele sale retroalimentate într-un fel, permițând întoarcerea de la una la cea anterioară (și chiar posibilitatea de a sări la mai multe anterioare) dacă este necesar.

În acest fel, se obține „modelul în cascadă de feedback”, care poate fi schematizat așa cum este ilustrat în Figura 3.

Figura 3: Modelul cascadă de feedback pentru ciclul de viață.

Ceea ce s-a spus este, în linii mari, forma și utilizarea acestui model, unul dintre cele mai utilizate și populare. ​ Modelul cascadă de feedback este foarte atractiv, chiar ideal, dacă proiectul prezintă o rigiditate mare (puține modificări, prognoză neevolutivă), cerințele sunt foarte clare și corect specificate. ]

Există mai multe variante asemănătoare modelului: rafinarea etapelor (mai multe etape, mai mici și mai specifice) sau chiar să prezinte mai puține etape decât cele indicate, deși în acest caz cea care lipsește va fi în cadrul altora. Ordinea acestor faze indicată în articolul anterior este logică și adecvată, dar rețineți, așa cum sa spus, că în mod normal va exista feedback invers.

Modelul liniar sau în cascadă este cea mai veche și mai utilizată paradigmă, totuși critica la adresa acestuia (vezi dezavantaje) a pus sub semnul întrebării eficacitatea acestuia. Cu toate acestea, are un loc foarte important în ingineria software și continuă să fie cel mai utilizat; și este întotdeauna mai bine decât o abordare aleatorie. ]

Dezavantaje ale modelului cascadă: ]

• Modificările introduse în timpul dezvoltării pot deruta echipa de profesioniști în fazele incipiente ale proiectului. Dacă schimbările apar într-un stadiu matur (codificare sau testare), acestea pot fi catastrofale pentru un proiect mare.
• Nu se întâmplă adesea ca clientul sau utilizatorul final să explice clar și complet cerințele (etapa inițială); iar modelul liniar o cere. Incertitudinea naturală de la început este apoi greu de adaptat. ]
• Clientul trebuie să aibă răbdare, deoarece software -ul nu va fi disponibil până la începutul proiectului. O eroare importanta detectata de client (in faza de exploatare) poate fi dezastruoasa, implicand o repornire a proiectului, cu costuri mari.

Modele evolutive

Software -ul evoluează în timp. ​ Cerințele utilizatorilor și ale produsului se schimbă adesea pe măsură ce produsul este dezvoltat. Din cauza datelor de pe piață și a concurenței, nu este posibil să așteptați pentru a aduce pe piață un produs complet complet, așa că este recomandabil să introduceți o versiune funcțională limitată într-un fel pentru a atenua presiunile concurentei.

În aceste situații sau în situații similare, dezvoltatorii au nevoie de modele de progres care sunt concepute pentru a găzdui un timp sau o evoluție progresivă, în care cerințele de bază sunt cunoscute dinainte, chiar dacă nu sunt bine definite în detaliu.

În modelul cascadă și feedback, natura evolutivă a software -ului nu este luată în considerare , este considerat ca fiind static, cu cerințe bine cunoscute și definite de la început. ]

Cele evolutive sunt modele iterative, permit dezvoltarea unor versiuni din ce în ce mai complete și mai complexe, până la atingerea obiectivului final dorit; chiar să evolueze mai departe, în timpul fazei de operare.

Modelele „iterative incrementale” și „spirale” (printre altele) sunt două dintre cele mai cunoscute și mai utilizate de tipul evolutiv. ]

Model iterativ incremental

În termeni generali, se pot distinge, în Figura 4, pașii generali urmați de procesul de dezvoltare a unui produs software . În modelul ciclului de viață selectat, acești pași sunt identificați în mod clar. Descrierea sistemului este esențială pentru a specifica și pregăti diferitele incremente până la atingerea produsului global și final. Activitățile concurente (specificare, dezvoltare și validare) sintetizează desfășurarea detaliată a creșterilor, care se va face ulterior.

Figura 4: Diagrama generică a dezvoltării evolutive incrementale.

Diagrama din figura 4 prezintă într-un mod foarte schematic, funcționarea unui ciclu iterativ incremental, care permite livrarea de versiuni parțiale pe măsură ce se construiește produsul final. ​ Adică, pe măsură ce fiecare increment definit ajunge la stadiul de funcționare și întreținere. Fiecare versiune emisă încorporează funcționalitățile și cerințele care au fost analizate după cum este necesar la incrementele anterioare.

Modelul incremental este un model de tip evolutiv care se bazează pe mai multe cicluri în cascadă de feedback aplicate în mod repetat, cu o filozofie iterativă. ​ Figura 5 prezintă o perfecționare a diagramei anterioare, sub o schemă temporară, pentru a obține în final schema modelului de ciclu de viață iterativ incremental, cu activitățile sale generice asociate. Aici fiecare ciclu în cascadă care se aplică pentru a obține o creștere este observat în mod clar; acestea din urmă sunt integrate pentru a obţine produsul final complet. Fiecare increment este un ciclu în cascadă de feedback, deși, pentru simplitate, în Figura 5 este prezentat ca secvențial pur.

Figura 5: Model iterativ incremental pentru ciclul de viață al software -ului .

Se observă că există activități de dezvoltare (pentru fiecare increment) care se desfășoară în paralel sau concomitent, astfel, de exemplu, în figură, în timp ce se realizează proiectarea detaliată a primului increment, analiza celui de-al doilea este în curs de realizare deja. Figura 5 este doar schematică, o creștere nu va începe neapărat în faza de proiectare a celei precedente, poate fi mai târziu (chiar înainte), în orice moment al etapei precedente. Fiecare increment se încheie cu activitatea de „exploatare și întreținere” (indicată ca „Operare” în figură), care este locul în care are loc livrarea produsului parțial către client. Ora de pornire a fiecărei creșteri depinde de mai mulți factori: tipul de sistem; independență sau dependență între creșteri (două creșteri total independente pot fi începute cu ușurință în același timp dacă este disponibil suficient personal); capacitatea și numărul de profesioniști implicați în dezvoltare; etc. ]

Sub acest model, software -ul este livrat „prin părți funcționale mai mici”, dar reutilizabile, numite incremente. În general, fiecare increment se bazează pe cel care a fost deja livrat. ]

După cum se arată în Figura 5, secvențele în cascadă sunt aplicate într-un mod eșalonat, pe măsură ce timpul calendaristic progresează. Fiecare secvență liniară sau cascadă produce un increment și, adesea, primul increment este un sistem de bază, cu multe funcții suplimentare (cunoscute sau nu) rămase nefurnizate.

Clientul utilizează inițial acest sistem de bază, între timp, rezultatul utilizării și evaluării acestuia poate contribui la planul de dezvoltare a următoarelor incremente (sau versiuni). În plus, la acest plan contribuie și alți factori, cum ar fi prioritizarea (urgența mai mare sau mai mică în necesitatea fiecărei creșteri) și dependența dintre creșteri (sau independența).

După fiecare integrare, se livrează un produs cu o funcționalitate mai mare decât precedentul. Procesul se repetă până când se ajunge la software-ul final complet .

Fiind iterativ, cu modelul incremental este livrat un produs parțial, dar complet operațional, în fiecare pas , și nu o parte care este utilizată pentru a reajusta cerințele (ca în modelul de prototipare ). ]

Abordarea incrementală este foarte utilă atunci când personalul de dezvoltare este scăzut; de asemenea, dacă nu există un termen limită disponibil pentru proiect, astfel încât sunt livrate versiuni incomplete, dar oferă utilizatorului funcționalități de bază (și în creștere). Este, de asemenea, un șablon util în scopuri de evaluare.

Notă: Poate fi considerată și utilă, în orice moment sau increment, să se încorporeze temporar paradigma MCP ca complement, având astfel un amestec de modele care îmbunătățesc schema și dezvoltarea generală.

Exemplu:

Un procesor de text care este dezvoltat sub paradigma incrementală ar putea, în principiu, să ofere funcții de bază de editare a fișierelor și producție de documente (ceva ca un simplu editor ). Într-un al doilea pas, s-ar putea adăuga editare și generare și amestecare mai sofisticate de documente . Într-o a treia creștere, ar putea fi luată în considerare adăugarea de funcții de verificare ortografică , scheme de paginare și șabloane ; într-o a patra abilități proprii de desen și ecuații matematice. Așa mai departe până când ajungeți la procesorul final necesar. Astfel, produsul crește, apropiindu-se de scopul final, dar încă de la livrarea primului increment este deja util și funcțional pentru client, care observă un răspuns rapid în ceea ce privește livrarea timpurie; fără a observa că termenul limită al proiectului poate să nu fie limitat sau definit, ceea ce oferă o marjă operațională și reduce presiunea asupra echipei de dezvoltare. ]

După cum sa spus, iterativul incremental este un model de tip evolutiv, adică în cazul în care schimbările probabile ale cerințelor sunt permise și așteptate în momentul dezvoltării; este permisă o anumită marjă pentru ca software -ul să poată evolua. ​ Aplicabil atunci când cerințele sunt destul de bine cunoscute, dar nu sunt complet statice și definite, o problemă care este esențială pentru a putea utiliza un model în cascadă.

Modelul este indicat pentru dezvoltarea de software în care se observă, în etapa sa inițială de analiză, că are de acoperit zone destul de bine definite, cu suficientă independență pentru a fi dezvoltat în etape succesive. Astfel de domenii care urmează să fie acoperite au, de obicei, diferite grade de urgență pentru care trebuie prioritizate într-o analiză anterioară, adică să definească care va fi primul, al doilea și așa mai departe; acest lucru este cunoscut sub numele de „definirea incrementelor” pe baza prioritizării. Este posibil să nu existe priorități funcționale din partea clientului, dar dezvoltatorul trebuie să le stabilească oricum și cu anumite criterii, deoarece pe baza acestora vor fi dezvoltate și livrate diferitele incremente.

Faptul că există incremente funcționale ale software -ului ne duce imediat să ne gândim la o schemă de dezvoltare modulară , prin urmare acest model facilitează o astfel de paradigmă de proiectare.

În rezumat, un model incremental ne face să ne gândim la o dezvoltare modulară, cu livrări parțiale ale produsului software numite „incremente” ale sistemului, care sunt alese în funcție de priorități predefinite într-un fel. Modelul permite o implementare cu perfecționări succesive (extindere sau îmbunătățire). Cu fiecare creștere, sunt adăugate noi funcționalități sau sunt îndeplinite noi cerințe sau versiunea implementată anterior a produsului software este îmbunătățită .

Acest model oferă o oarecare flexibilitate, astfel încât în ​​timpul dezvoltării modificările sunt incluse în cerințe de către utilizator, o modificare propusă și aprobată a cerințelor poate fi analizată și implementată ca o nouă creștere sau, eventual, poate constitui o îmbunătățire/adaptare a uneia deja planificate. . . Deși în cazul în care există o modificare a cerințelor de către client care afectează creșterile finalizate anterior (detecție/încorporare tardivă) , trebuie evaluată fezabilitatea și trebuie încheiat un acord cu clientul, deoarece poate avea un impact puternic asupra costurilor. ]

Selectarea acestui model permite livrări funcționale timpurii către client (ceea ce este benefic atât pentru client, cât și pentru grupul de dezvoltare). Livrările acelor module sau incremente în care apare necesitatea operațională de a face acest lucru sunt prioritizate, de exemplu pentru încărcăturile anterioare de informații, esențiale pentru următoarele incremente. ]

Modelul iterativ incremental nu obligă să precizeze cu precizie și detaliu absolut tot ceea ce trebuie să facă sistemul, (și cum), înainte de a fi construit (ca în cazul cascadei, cu cerințe înghețate). Se face doar în incrementul de dezvoltare. Acest lucru face procesul mai ușor de gestionat și reduce impactul costurilor. Așa este, deoarece în cazul modificării sau refacerii cerințelor, aceasta afectează doar o parte a sistemului. Deși, logic, această situație se agravează dacă apare într-un stadiu avansat, adică în ultimele trepte. În cele din urmă, modelul facilitează încorporarea noilor cerințe în timpul dezvoltării.

Cu o paradigmă incrementală, timpul de dezvoltare inițial este redus, deoarece funcționalitatea parțială este implementată. De asemenea, oferă un impact avantajos asupra clientului, care este livrarea timpurie a părților de lucru ale software -ului .

Modelul oferă toate avantajele modelului în cascadă de feedback, reducându-și dezavantajele doar la sfera fiecărui increment.

Modelul incremental nu este recomandat pentru sisteme în timp real , de înaltă securitate, procesare distribuită sau sisteme cu risc ridicat.

Model în spirală

Modelul în spirală a fost propus inițial de Barry Boehm . Este un model evolutiv care combină natura iterativă a modelului MCP cu aspectele controlate și sistematice ale modelului în cascadă. Oferă potențial pentru dezvoltarea rapidă a versiunilor incrementale. În modelul în spirală, software -ul este construit într-o serie de versiuni incrementale. În primele iterații, versiunea incrementală ar putea fi un model de hârtie sau un prototip. În ultimele iterații, sunt produse versiuni din ce în ce mai complete ale sistemului proiectat. ]

Modelul este împărțit într-un număr de Activități-cadru, numite „regiuni de sarcini”. În general, există între trei și șase regiuni de activitate (există variante ale modelului). Figura 6 prezintă schema unui model în spirală cu șase regiuni. În acest caz, este explicată o variantă a modelului original al lui Boehm, expusă în tratatul său din 1988; în 1998 a expus un tratat mai recent.

Figura 6: Model în spirală pentru ciclul de viață al software -ului .

Regiunile definite în modelul figurii sunt:

• Regiunea 1 — Sarcini necesare pentru a stabili comunicarea între client și dezvoltator.
• Regiunea 2 — Sarcini inerente definirii resurselor, timpului și alte informații legate de proiect.
• Regiunea 3 — Sarcini necesare pentru evaluarea riscurilor tehnice și de management ale proiectului.
• Regiunea 4 — Sarcini pentru a construi una sau mai multe reprezentări ale aplicației software .
• Regiunea 5 — Sarcini pentru a construi aplicația, a o instala, a o testa și a oferi asistență utilizatorilor sau clienților (de exemplu, documentație și practică).
• Regiunea 6 — Sarcini pentru a obține feedback-ul clienților, pe baza evaluării a ceea ce a fost construit și instalat în ciclurile anterioare.

Activitățile enumerate pentru cadru sunt generale și se aplică oricărui proiect, mare, mediu sau mic, complex sau nu. Regiunile care definesc aceste activități cuprind un „set de sarcini” ale lucrării: acest set trebuie adaptat la caracteristicile proiectului particular care urmează să fie întreprins. Rețineți că ceea ce este enumerat la articolele de la 1 la 6 sunt seturi de sarcini, dintre care unele depind în mod normal de proiectul sau dezvoltarea în sine.

Proiectele mici necesită un număr redus de sarcini și, de asemenea, formalități. În proiectele mai mari sau critice, fiecare regiune de sarcini conține sarcini cu un nivel mai ridicat de formalitate. În orice caz, se aplică activități de protecție (de exemplu, managementul configurației software , asigurarea calității etc.).

La începutul ciclului sau al procesului evolutiv, echipa de ingineri se întoarce în jurul spiralei (metaforic vorbind) începând din centru (marcat cu ๑ în figura 6) și în direcția indicată; primul circuit al spiralei poate duce la elaborarea unui caiet de sarcini de produs ; următorii pași ar putea genera un prototip și versiuni progresiv mai sofisticate ale software -ului .

Fiecare trecere prin regiunea de planificare determină ajustări ale planului proiectului; costul și planificarea sunt reluate pe baza evaluării clientului. Managerul de proiect trebuie să ajusteze numărul de iterații necesare pentru a finaliza dezvoltarea.

Modelul în spirală poate fi adaptat și aplicat pe parcursul întregului ciclu de viață al software -ului (în modelul clasic, sau în cascadă, procesul se termină cu livrarea software -ului ).

O vedere alternativă a modelului poate fi văzută examinând „axa punctului de intrare în proiect”. Fiecare dintre cercurile mici (๏) fixate de-a lungul axei reprezintă puncte de plecare ale diferitelor proiecte (conexe); și anume:

• Un proiect de „dezvoltare a conceptului” începe la începutul spiralei, trece prin mai multe iterații până când este complet, este zona marcată cu verde.
• Dacă cele de mai sus urmează să fie dezvoltate ca produs real, se demarează un alt proiect: „Dezvoltarea unui produs nou”. Care va evolua cu iterații până la culminare; este zona marcată cu albastru.
• Eventual și similar, vor fi generate proiecte de „îmbunătățire a produsului” și „întreținere a produsului”, cu iterațiile necesare în fiecare zonă (zone roșii, respectiv gri).

Când spirala este caracterizată în acest fel, este operațională până când software -ul este îndepărtat, eventual poate fi inactiv (procesul), dar atunci când are loc o schimbare, procesul începe din nou la punctul de intrare corespunzător (de exemplu, în „îmbunătățire” ). al produsului").

Modelul în spirală oferă o abordare realistă, care evoluează ca software-ul ; este foarte potrivit pentru dezvoltări la scară largă.

Spiralul folosește MCP pentru a reduce riscurile și îi permite să fie aplicat în orice stadiu de evoluție. Menține abordarea clasică (cascada), dar încorporează un cadru iterativ care reflectă mai bine realitatea.

Acest model necesită luarea în considerare a riscurilor tehnice în toate etapele proiectului; Aplicat corect, ar trebui să le reducă înainte ca acestea să devină o problemă reală.

Modelul evolutiv ca Spiral este deosebit de potrivit pentru dezvoltarea de sisteme de operare (complexe); de asemenea, în sistemele cu risc ridicat sau critice (ex. browsere și controlere aeronautice) și în toate cele în care este necesară o gestionare puternică a proiectului și a riscurilor sale, tehnice sau manageriale.

Dezavantaje importante :

• Este nevoie de multă experiență și abilități în evaluarea riscurilor, ceea ce este necesar pentru succesul proiectului.
• Este dificil să convingi clienții mari că această abordare evolutivă poate fi controlată.

Acest model nu a fost folosit la fel de mult, precum Cascade (Incremental) sau MCP , deci eficacitatea lui nu este bine măsurată, este o paradigmă relativ nouă și greu de implementat și controlat.

Model spirală Win & Win

O variantă interesantă a modelului Spiral văzută anterior (Figura 6) este „Modelul Spiral Win-Win” ( Barry Boehm ). Modelul Spiral anterior (clasic) sugerează comunicarea cu clientul pentru stabilirea cerințelor, în care clientul este întrebat pur și simplu de ce are nevoie și acesta oferă informațiile pentru a continua; dar acest lucru este într-un context ideal care se întâmplă rar. În mod normal, clientul și dezvoltatorul intră într-o negociere, costul este negociat în funcție de funcționalitate, performanță, calitate etc.

„Astfel, obținerea cerințelor necesită o negociere, care are succes atunci când ambele părți câștigă”.

Cele mai bune negocieri sunt forțate pentru a obține „Victoria & Victoria” (Win & Win), adică clientul câștigă obținând produsul care îl satisface, iar dezvoltatorul câștigă și obținând un buget realist și o dată de livrare. Evident, acest model necesită abilități puternice de negociere.

Modelul Win-Win definește un set de activități de tranzacționare la începutul fiecărui pas în jurul spiralei; se definesc urmatoarele activitati:

1. Identificarea sistemului cheie sau a subsistemelor managerilor * (știi ce vor).
2. Determinarea „condițiilor de victorie” pentru manageri (știind de ce au nevoie și îi satisface)
3. Negocierea condițiilor de «victorie» ale managerilor pentru a obține condiții «Victory & Victory» (negociați astfel încât ambii să câștige).

* Manager: Client ales cu un interes direct în produs, care poate fi recompensat de organizație dacă are succes sau criticat dacă nu.

Modelul Win & Win pune accentul pe negocierea inițială, introduce și 3 repere în procesul numite „puncte de fixare”, care ajută la stabilirea finalizării unui ciclu al spiralei și oferă repere de decizie înainte de a continua proiectul de negociere.dezvoltare software .

Etape în dezvoltarea software -ului

Captarea, analiza și specificarea cerințelor

La începutul unei dezvoltări (nu al unui proiect), aceasta este prima fază care se desfășoară și, în funcție de modelul de proces adoptat, aproape că se poate termina pentru a trece la etapa următoare (cazul modelului Feedback Waterfall) sau se poate face parţial.pentru a reveni apoi la el (cazul Model Iterativ Incremental sau altele de natură evolutivă).

În cuvinte simple și practic, în această fază se dobândesc, se adună și se precizează caracteristicile funcționale și nefuncționale pe care trebuie să le îndeplinească viitorul program sau sistem de dezvoltat.

Beneficiile caracteristicilor, atât ale sistemului sau programului de dezvoltat, cât și ale mediului acestuia, parametrii nefuncționali și arhitectura, depind enorm de cât de bine este realizată această etapă. Aceasta este probabil cea mai importantă și una dintre cele mai dificile faze de realizat cu acuratețe, deoarece nu poate fi automatizată, nu este foarte tehnică și depinde în mare măsură de priceperea și experiența analistului care o realizează.

Implică puternic utilizatorul sau clientul sistemului, prin urmare are nuanțe foarte subiective și este dificil să modelezi cu certitudine sau să aplici o tehnică care este „cea mai apropiată de cea potrivită” (de fapt, nu există așa ceva ca „ cel potrivit"). Deși au fost concepute mai multe metodologii, inclusiv software de suport , pentru captarea, evocarea și înregistrarea cerințelor, nu există o modalitate infailibilă sau absolut sigură, iar criteriile bune și mult bun simț trebuie aplicate împreună de către analistul sau analiștii responsabili cu cerinte.sarcina; De asemenea, este esențial să se realizeze o comunicare și înțelegere fluidă și adecvată cu utilizatorul final sau clientul sistemului.

Cel mai important artefact rezultat în urma finalizării acestei etape este ceea ce este cunoscut sub numele de specificația cerințelor software sau pur și simplu un document ERS.

După cum sa spus, capacitatea analistului de a interacționa cu clientul este esențială; Lucrul comun este că clientul are un obiectiv general sau o problemă de rezolvat, nu cunoaște deloc zona (informatica) și nici jargonul acesteia, nici măcar nu știe exact ce trebuie să facă produsul software (ce și câte funcții) cu atât mai puțin cum ar trebui să funcționeze. În alte cazuri mai puțin frecvente, clientul „crede” că știe exact ce are de făcut software -ul și, în general, are dreptate foarte parțial, dar încăpățânarea lui împiedică sarcina de elicitare. Analistul trebuie să aibă capacitatea de a face față acestor tipuri de probleme, care includ relațiile umane; Trebuie să știi să te pui la nivelul utilizatorului pentru a permite o comunicare și înțelegere adecvată. ]

Sunt putine situatiile in care clientul stie cu certitudine si chiar complet ce cere de la viitorul sau sistem, acesta este cel mai simplu caz pentru analist.

Sarcinile legate de captarea, elicitarea, modelarea și înregistrarea cerințelor, pe lângă faptul că sunt extrem de importante, pot deveni dificil de realizat corect și pot dura mult timp în raport cu procesul total de dezvoltare; Procesul și metodologiile de desfășurare a acestui set de activități sunt în mod normal presupuse a fi parte a ingineriei software , dar având în vedere complexitatea menționată mai sus, se face referire în prezent ca inginerie a cerințelor [ deși nu există încă formal.

În întreaga lume există grupuri de studiu și cercetare care sunt dedicate exclusiv elaborării de modele, tehnici și procese pentru a încerca să obțină capturarea, analizarea și înregistrarea corectă a cerințelor. Aceste grupuri sunt cele care vorbesc în mod normal despre ingineria cerințelor; adică aceasta este considerată ca o zonă sau disciplină, dar nu ca o carieră universitară în sine.

Unele cerințe nu necesită prezența clientului, pentru a fi captate sau analizate; În anumite cazuri, acestea pot fi propuse chiar de analist sau chiar să adopte unilateral decizii pe care le consideră adecvate (atât în ​​cerinţe funcţionale, cât şi nefuncţionale). Pentru a cita exemple probabile: Unele cerințe de arhitectură de sistem, cerințe nefuncționale precum cele legate de performanță, nivelul de suport pentru erori operaționale, platforme de dezvoltare, relații interne sau legături între informații (între înregistrări sau tabele de date) pentru stocarea în baze de date sau baze de date, etc. Unele funcționale precum opțiuni secundare sau suport necesare pentru o funcționare mai bună sau mai simplă; etc.

Obținerea specificațiilor de la client (sau alți actori care intervin) este un proces uman extrem de interactiv și iterativ; în mod normal, pe măsură ce informația este captată, aceasta este analizată și retroalimentată cu clientul, rafinându-le, șlefuind-o și corectând-o dacă este necesar; indiferent de metoda ERS utilizată. Analistul trebuie să cunoască întotdeauna subiectul și problema de rezolvat, să-l domine, într-o anumită măsură, în măsura în care viitorul sistem de dezvoltat îl cuprinde. Prin urmare, analistul trebuie să aibă o capacitate ridicată de a înțelege probleme din domenii sau discipline de lucru foarte diverse (care nu sunt în mod specific ale lor); Astfel, de exemplu, dacă sistemul de dezvoltat va fi de gestionare a informațiilor unei companii de asigurări și a sucursalelor sale la distanță, analistul trebuie să înțeleagă cum funcționează și își gestionează informațiile, de la niveluri foarte scăzute și chiar ajungând la niveluri de management. Având în vedere marea diversitate a domeniilor de acoperit, analiștii sunt, de regulă, asistați de specialiști, adică oameni care au cunoștințe profunde ale domeniului pentru care va fi dezvoltat software -ul ; Evident, o singură persoană (analistul) nu poate acoperi un număr atât de mare de domenii de cunoaștere. În marile companii de dezvoltare de produse software , este obișnuit să existe analiști specializați în anumite domenii de activitate.

Dimpotrivă, nu este problema clientului, adică nu trebuie să știe nimic despre software , sau design, sau alte lucruri conexe; ar trebui să se limiteze doar la furnizarea de obiective, date și informații (prin propriile sale sau din înregistrările sale, echipamentele, angajații etc.) analistului și ghidat de acesta, astfel încât, în primă instanță, să definească „ Universul ”. of Discourse », și Cu lucrările ulterioare, am putut pregăti documentul ERS corespunzător .

Este bine cunoscută presiunea asupra dezvoltatorilor de sisteme informatice pentru a înțelege și a răspunde nevoilor clienților/utilizatorilor. Cu cât contextul problemei este mai complex, cu atât este mai dificil de realizat, forțând uneori dezvoltatorii să devină aproape experți în domeniile pe care le analizează.

Atunci când acest lucru nu se întâmplă, este foarte probabil să se genereze un set de cerințe eronate sau incomplete și, prin urmare, un produs software cu un grad ridicat de dezaprobare din partea clienților/utilizatori și un cost de reinginiere și întreținere foarte mare. Tot ceea ce nu este detectat, sau este înțeles greșit în stadiul inițial, va provoca un puternic impact negativ asupra cerințelor, propagă acest curent degradant pe tot parcursul procesului de dezvoltare și crescând deteriorarea acestuia cu cât este detectat mai târziu (Bell și Thayer 1976) (Davis). 1993).

Procese de elicitare a cerințelor, modelare și formulare

Întrucât captarea, elicitarea și specificarea cerințelor reprezintă o parte crucială a procesului de dezvoltare a software -ului , deoarece atingerea obiectivelor finale așteptate depinde de această etapă, au fost concepute modele și diverse metodologii de lucru în aceste scopuri. Există, de asemenea, instrumente software care sprijină sarcinile aferente efectuate de inginerul de cerințe.

Standardul IEEE 830-1998 oferă o standardizare a „Recommended Practices for Software Requirements Specification ”. ]

Pe măsură ce cerințele sunt obținute, acestea sunt în mod normal analizate, rezultatul acestei analize, cu sau fără client, este reflectat într-un document, cunoscut sub numele de ERS sau Software Requirements Specification , a cărui structură poate fi definită de diverse standarde, precum CMMI .

Un prim pas pentru realizarea sondajului de informații este cunoașterea și definirea corectă a ceea ce este cunoscut sub numele de „Universul Discursului” al problemei, care este definit și înțeles prin:

Universul discursului (UdeD) : este contextul general în care software -ul trebuie dezvoltat și trebuie să funcționeze. UofD include toate sursele de informații și toate persoanele legate de software . Acești oameni sunt cunoscuți și ca actori ai acelui univers. UdeD este realitatea circumstanțială de setul de obiective definite de cei care au cerut software -ul .

Din extragerea și analiza informațiilor din domeniul său se obțin toate specificațiile și tipurile de cerințe necesare pentru viitorul produs software .

Obiectivul inginerii cerințelor (RI) este de a sistematiza procesul de definire a cerințelor, permițând elicitarea, modelarea și analiza problemei, generând un angajament între inginerii de cerințe și clienți/utilizatori, deoarece ambii participă la generarea și definirea cerințelor. cerinte.a cerintelor de sistem. IR oferă un set de metode, tehnici și instrumente care ajută inginerii de cerințe (analiști) să obțină cerințe cât mai sigure, veridice, complete și oportune, permițând practic:

• intelege problema
• Facilitează obținerea nevoilor clientului/utilizatorului
• Validați cu clientul/utilizatorul
• Asigurarea specificațiilor cerințelor

Deși există diverse modalități, modele și metodologii de a evoca, defini și documenta cerințele, nu se poate spune că una dintre ele este mai bună sau mai proastă decât cealaltă, de obicei au multe în comun și toate îndeplinesc același obiectiv. Cu toate acestea, ceea ce se poate spune fără îndoială este că este esențial să folosiți unul dintre ele pentru a documenta specificațiile viitorului produs software . Astfel, de exemplu, există un grup de cercetare argentinian care de câțiva ani propune și studiază utilizarea ca metodologie a LEL (Extended Lexicon of Language) și a Scenariilor, aici una dintre numeroasele referințe și bibliografie despre acesta este prezentat.. Un alt mod, mai ortodox, de captare și documentare a cerințelor poate fi obținut în detaliu, de exemplu, în lucrarea Universității din Sevilla privind „Metodologia pentru analiza cerințelor sistemelor software”. ]

Figura 7 prezintă o schemă, mai mult sau mai puțin riguroasă, deși nedetaliată, a pașilor și sarcinilor de urmat pentru a capta, analiza și specifica cerințele software . Tot acolo puteți vedea ce artefact sau document este obținut la fiecare etapă a procesului. Diagrama nu explică metodologia sau modelul de utilizat, ea pur și simplu conturează sarcinile care trebuie îndeplinite, într-un fel.

Figura 7: Diagrama sarcinilor pentru captarea și analiza cerințelor.

O posibilă listă, generală și ordonată, de sarcini recomandate pentru a obține definiția a ceea ce trebuie făcut, a produselor de obținut și a tehnicilor de utilizat în timpul activității de elicitare a cerințelor, în faza de Specificare a cerințelor software este:

1. Obține informații despre domeniul problemei și sistemul actual (UdeD).
2. Pregătiți și organizați întâlniri pentru elicitare/negociere.
3. Identificați/examinați obiectivele utilizatorilor.
4. Identificați/examinați obiectivele sistemului.
5. Identificați/examinați cerințele de informații .
6. Identificați/examinați cerințele funcționale .
7. Identificați/examinați cerințele nefuncționale .
8. Prioritizează obiectivele și cerințele.

Câteva principii de bază de reținut:

• Prezentați și înțelegeți pe deplin domeniul informațional al problemei.
• Definiți corect funcțiile care trebuie îndeplinite de software .
• Reprezentați comportamentul software -ului ca urmare a unor evenimente externe, particulare, chiar neașteptate.
• Recunoașteți cerințele incomplete, ambigue sau contradictorii.
• Împărțiți clar modelele care reprezintă informații, funcții și comportament și caracteristicile nefuncționale.

Clasificarea și identificarea cerințelor

Pot fi identificate două forme de cerințe:

• Cerințe utilizator: Cerințele utilizatorului sunt propoziții în limbaj natural împreună cu diagrame cu serviciile pe care sistemul trebuie să le ofere, precum și restricțiile sub care trebuie să funcționeze.
• Cerințe de sistem: cerințele de sistem determină serviciile de sistem și, dar cu restricțiile în detaliu. Ele servesc ca un contract.

Adică ambele sunt la fel, dar cu un nivel diferit de detaliu.

Exemplu de cerință de utilizator: sistemul trebuie să acorde împrumuturi. Exemplu de cerințe de sistem: Funcția de împrumut: introduceți codul partenerului, codul exemplu; plecare: data întoarcerii; etc.

Există trei tipuri de cerințe de sistem:

• cerințe funcționale

Cerințele funcționale descriu:

• Serviciile furnizate de sistem (funcții).
• Răspunsul sistemului la anumite intrări.
• Comportamentul sistemului în anumite situații.

• cerințe nefuncționale

Cerințele nefuncționale sunt restricții privind serviciile sau funcțiile oferite de sistem (de exemplu, limite de timp, proces de dezvoltare, performanță etc.)

Exemplul 1. Biblioteca Centrală trebuie să poată frecventa simultan toate bibliotecile Universității

Exemplul 2. Timpul de răspuns la o interogare de la distanță nu trebuie să depășească 1/2 s

La rândul lor, există trei tipuri de cerințe nefuncționale:

• Cerințe de produs. Acestea specifică comportamentul produsului (de exemplu, performanță, memorie, rata de eșec etc.)
• Cerințe organizaționale. Acestea sunt derivate din politicile și procedurile organizațiilor client și dezvoltatori (de exemplu, standarde de proces, limbaje de programare etc.)
• Cerințe externe. Ele derivă din factori externi sistemului și procesului de dezvoltare (ex. cerințe legislative, etică etc.)

• Cerințe de domeniu.

Cerințele de domeniu sunt derivate din domeniul aplicației și reflectă caracteristicile domeniului respectiv.

Ele pot fi funcționale sau nefuncționale.

De exemplu, sistemul bibliotecii universitare trebuie să poată exporta date prin limba spaniolă de intercomunicare a bibliotecii (LIBE). De exemplu, sistemul de biblioteci nu va putea accesa bibliotecile cu material cenzurat.

Proiectare sistem

În ingineria software , proiectarea este o fază a ciclului de viață al software -ului . Se bazează pe specificația cerințelor produsă de analiza cerințelor (faza de analiză), proiectarea definește modul în care vor fi îndeplinite aceste cerințe, structura care trebuie dată sistemului software pentru a deveni realitate.

Proiectarea rămâne o fază separată de programare sau codare, aceasta din urmă corespunzând traducerii într-un limbaj de programare dat a premiselor adoptate în proiectare.

Distincțiile dintre activitățile menționate până acum nu sunt întotdeauna atât de clare pe cât s-ar dori în teoriile clasice ale ingineriei software . Designul, în special, poate descrie funcționarea interioară a unui sistem la diferite niveluri de detaliu, fiecare dintre acestea fiind undeva între analiză și codificare.

„Design arhitectural” este în mod normal înțeles ca proiectare „la nivel foarte înalt”, care definește structura sistemului doar în ceea ce privește modulele software din care este compus și relațiile macroscopice dintre acestea. Acestui nivel de proiectare îi aparțin formule precum client-server sau „trei niveluri”, sau, mai general, decizii privind utilizarea arhitecturii hardware speciale ce urmează a fi utilizată, sistemul de operare, DBMS , protocoalele de rețea etc.

Un nivel intermediar de detaliu poate defini descompunerea sistemului în module, dar de data aceasta cu o referire mai mult sau mai puțin explicită la modul de descompunere oferit de limbajul de programare particular cu care urmează să fie implementată dezvoltarea, de exemplu, într-un proiectat cu tehnologie obiect , proiectul ar putea descrie sistemul în termeni de clase și interrelațiile lor.

Designul detaliat, în sfârșit, este o descriere a sistemului care este foarte aproape de codificare (de exemplu, descriind nu numai clasele în abstract, ci și atributele și metodele lor cu tipurile lor).

Datorită naturii „intangibile” a software -ului și în funcție de instrumentele utilizate în proces, granița dintre proiectare și codare poate fi, de asemenea, practic imposibil de identificat. De exemplu, unele instrumente CASE sunt capabile să genereze cod din diagrame UML, care descriu grafic structura unui sistem software .

Codare software

În această etapă sunt efectuate sarcinile cunoscute în mod obișnuit ca programare ; care constă în esență în convertirea a tot ceea ce este proiectat în faza anterioară în cod sursă, în limbajul de programare ales. Această sarcină este realizată de programator , urmând în totalitate liniile directoare impuse în proiectare și ținând întotdeauna cont de cerințele funcționale și nefuncționale (ERS) specificate în prima etapă.

Este obișnuit să credem că etapa de programare sau codare (unii o numesc implementare) este cea care consumă cea mai mare parte din munca de dezvoltare a software -ului ; cu toate acestea, acest lucru poate fi relativ (și aplicabil în general sistemelor mici), deoarece etapele anterioare sunt cruciale, critice și pot dura mult mai mult. Estimările sunt de obicei făcute pentru 30% din timpul total al programării, dar această cifră nu este consecventă, deoarece depinde în mare măsură de caracteristicile sistemului, de criticitatea acestuia și de limbajul de programare ales. Cu cât nivelul limbajului este mai scăzut, cu atât timpul de programare este mai mare, deci, de exemplu, ar dura mai mult timp pentru a codifica un algoritm în limbaj de asamblare decât același programat în limbaj C.

În timp ce aplicația, sistemul sau software -ul în general este programat, se efectuează și sarcini de depanare, aceasta fiind sarcina de a elibera codul de erorile care pot fi găsite în această fază (de semantică, sintaxă și logică). Există un fel de suprapunere cu următoarea fază, deoarece depanarea logicii necesită testare unitară, de obicei cu date de testare; Este clar că nu toate erorile vor fi găsite doar în etapa de programare, vor mai fi și altele care vor fi găsite în etapele ulterioare. Apariția unei erori funcționale (răspuns prost la cerințe) poate duce în cele din urmă la revenirea la faza de proiectare înainte de a continua codarea.

În faza de programare, codul poate adopta diverse stări, în funcție de modul de lucru și limbajul ales și anume:

• Cod sursă : este codul scris direct de programatori în editorii de text, care generează programul . Conține setul de instrucțiuni codificate într-un limbaj de nivel înalt. Poate fi distribuit în pachete, proceduri, biblioteci sursă etc.

• Cod obiect : este codul binar sau intermediar rezultat din procesarea codului sursă cu un compilator . Constă într-o traducere completă și unică a acestuia din urmă. Codul obiect nu poate fi citit de om (de obicei este în format binar), dar nici nu este executabil direct de computer. Este o reprezentare intermediară între codul sursă și codul executabil, în scopul unei legături finale cu rutinele bibliotecii și între proceduri sau pentru utilizare cu un mic interpret intermediar [pentru diferite exemple vezi EUPHORIA , (interpret intermediar), FORTRAN (pur compilator) MSIL (Microsoft Intermediate Language) (interpret) și BASIC (interpret pur, interpret intermediar, compilator intermediar sau compilator pur, în funcție de versiunea utilizată)].
  • Codul obiect nu există dacă programatorul lucrează cu un limbaj ca pur interpret , în acest caz același interpret este însărcinat cu traducerea și executarea codului sursă linie cu linie (în funcție de fluxul programului), la momentul execuției. . În acest caz , nici fișierele de cod executabil nu există . Un dezavantaj al acestui mod este că execuția programului sau a sistemului este puțin mai lentă decât dacă s-ar face cu un interpret intermediar și considerabil mai lentă decât în ​​cazul în care fișierele de cod executabil există. Adică nu favorizează performanța în viteza de execuție. Dar un mare avantaj al modului pur interpret este că acest mod de lucru facilitează foarte mult sarcina de depanare a codului sursă (comparativ cu alternativa de a o face cu un compilator pur). Frecvent, se folosește un mod mixt de lucru (dacă limbajul de programare ales permite acest lucru), adică inițial lucrând ca pur interpret, iar odată ce codul sursă a fost depanat (fără erori), un compilator din același limbaj este utilizat. folosit pentru a obține codul executabil complet, care accelerează depanarea și optimizează viteza de execuție.

• Cod executabil : Este codul binar care rezultă din legarea unuia sau mai multor fragmente de cod obiect cu rutinele și bibliotecile necesare . Constituie unul sau mai multe fișiere binare cu un format astfel încât sistemul de operare să fie capabil să le încarce în memoria RAM (eventual o parte a memoriei virtuale ) și să treacă la execuția directă a acestuia. Prin urmare, se spune că codul executabil este direct „inteligibil de computer”. Codul executabil, cunoscut și sub numele de cod de mașină , nu există dacă este programat în modul „interpret pur”.

Teste (unitate și integrare)

Dintre diferitele teste care sunt efectuate pe software , se pot distinge următoarele:

• Teste unitare : constau în testarea sau testarea unor bucăți mici de software ; la nivel de secții, proceduri, funcții și module; cele cu funcționalități specifice. Aceste teste sunt folosite pentru a asigura funcționarea corectă a secțiunilor de cod, mult mai mici decât întregul, și care au funcții specifice cu un anumit grad de independență.
• Teste de integrare : Sunt efectuate odată ce testele unitare au fost finalizate cu succes ; acestea sunt menite să asigure că întregul sistem, inclusiv subsistemele care alcătuiesc bucățile individuale mari de software , funcționează corect atunci când funcționează și interoperează împreună.

Testarea se face de obicei cu așa-numitele date de testare , care este un set selectat de date tipice la care poate fi supus sistemul, modulele sau blocurile de cod. De asemenea, alese: Date care conduc la condiții de limită software pentru a testa toleranța și robustețea acestuia; date de utilitate pentru măsurarea performanței; date care cauzează condiții eventuale sau particulare neobișnuite și cărora software -ul nu va fi supus în mod normal, dar poate apărea; etc. „Datele de testare” nu sunt neapărat fictive sau „create”, dar, de obicei, datele cu o probabilitate scăzută de apariție sunt.

În general, există o fază finală și completă de testare a software -ului , numită Beta Test , în timpul căreia sistemul instalat în condiții normale de funcționare și de lucru este testat exhaustiv pentru a găsi erori, instabilități, răspunsuri eronate etc. că controalele anterioare au trecut. Acestea sunt în mod normal efectuate de personal adecvat angajat sau afectat în mod specific de acesta. Posibilele erori găsite sunt transmise dezvoltatorilor pentru depanare. În cazul software -ului de dezvoltare „la cerere” , utilizatorul final (clientul) este cel care realizează Beta Test, având o perioadă de probă convenită cu dezvoltatorul.

Instalare și trecere la producție

Instalarea software -ului este procesul prin care programele dezvoltate sunt transferate în mod corespunzător pe computerul de destinație, inițializate și, eventual, configurate ; toate cu scopul de a fi utilizate de către utilizatorul final. Constituie etapa finală în dezvoltarea propriu-zisă a software -ului . După aceasta, produsul va intra în faza de operare și producție, pentru care a fost conceput.

Instalarea, în funcție de sistemul dezvoltat, poate consta într-o simplă copie pe hard disk-ul de destinație (cazuri rare în prezent); sau, mai frecvent, cu unul de complexitate intermediară în care diferitele fișiere componente ale software -ului (executabile, biblioteci , date proprii etc.) sunt decomprimate și copiate în locuri specifice prestabilite de pe disc; legăturile sunt chiar create cu alte produse, pe lângă sistemul de operare în sine . Acest ultim caz este de obicei un proces destul de automat care este creat și ghidat cu instrumente software specifice ( ambalare și distribuție, instalatori ).

La produsele mai complexe, a doua alternativă este cea folosită, dar este realizată sau ghidată de specialiști; poate necesita chiar instalarea pe mai multe computere diferite (instalare distribuită).

De asemenea, în software -ul de complexitate medie și mare, este necesar în mod normal un proces de configurare și verificare , prin care sunt atribuiți parametrii de funcționare adecvați și este testată operabilitatea funcțională a produsului.

În produsele vândute în masă, instalările complete, dacă sunt relativ simple, sunt de obicei realizate de utilizatorii finali înșiși (cum ar fi sisteme de operare, pachete de birou, utilități etc.) cu propriile instrumente de instalare ghidată; chiar și configurația este de obicei automată. În produsele cu design specific sau „personalizate”, instalarea este în mod normal limitată la specialiști implicați în dezvoltarea software -ului în cauză.

Odată ce software -ul a fost instalat cu succes , acesta trece în faza de producție (operare), în timpul căreia îndeplinește funcțiile pentru care a fost dezvoltat, adică este utilizat în final de către utilizatorul(i) final, producând rezultatele așteptate.

Întreținere

Întreținerea software este procesul de control, îmbunătățire și optimizare a software -ului deja dezvoltat și instalat, care include și depanarea erorilor și a defectelor care s-ar fi putut scurge din faza de control și beta test. Această fază este ultima (înainte de iterare, în funcție de modelul utilizat) care se aplică ciclului de viață al dezvoltării software . Faza de întreținere este cea care vine după ce software -ul este operațional și în producție.

Faza de întreținere va depinde de o bună documentație de proiectare și dezvoltare, atât din punct de vedere al timpului, cât și al banilor. Modificările aduse software -ului care a fost dezvoltat cu documentație necorespunzătoare sau slabă și design slab pot fi la fel de scumpe sau mai scumpe decât dezvoltarea software -ului de la zero. Din acest motiv, este de o importanță fundamentală să se respecte în mod corespunzător toate sarcinile fazelor de dezvoltare și să se mențină o documentație adecvată și completă.

Perioada fazei de întreținere este în mod normal cea mai lungă din întregul ciclu de viață. Această fază implică , de asemenea , upgrade şi evoluţii software ; nu implică neapărat că sistemul a avut erori. Una sau mai multe modificări ale software -ului , de exemplu adaptative sau evolutive, pot duce chiar la revizuirea și adaptarea unei părți din primele faze ale dezvoltării inițiale, modificându-le pe toate celelalte; în funcţie de cât de profunde sunt schimbările. Modelul obișnuit al cascadei este deosebit de costisitor de întreținut, deoarece rigiditatea acestuia implică faptul că orice modificare provoacă o revenire la faza inițială și modificări puternice în celelalte faze ale ciclului de viață.

În timpul ferestrei de întreținere, este obișnuit să apară noi revizuiri și versiuni ale produsului; care îl lansează mai rafinat, cu o funcționalitate mai mare și mai bună, performanțe mai bune etc. Există mai multe fațete care pot fi modificate pentru a provoca schimbări, adaptări sau extinderi și îmbunătățiri dezirabile, evolutive.

Practic, există următoarele tipuri de modificări:

• Perfective: Cele care conduc la o îmbunătățire a calității interne a software -ului sub orice aspect: Restructurarea codului, definirea mai clară a sistemului și a documentației acestuia; optimizarea performanței și eficienței.
• Evolutiv: Adăugiri, modificări, chiar eliminări, necesare în software pentru a acoperi extinderea sau modificarea acestuia, în funcție de nevoile utilizatorului.
• Adaptive: Modificări care afectează mediile în care funcționează sistemul, cum ar fi: modificări ale configurației hardware (pentru actualizarea sau îmbunătățirea componentelor electronice), modificări ale software -ului de bază , ale managerilor de baze de date, ale comunicațiilor etc.
• Corectiv: Modificări necesare pentru corectarea erorilor de orice fel în produsul software dezvoltat .

Natura evolutivă a software -ului

Software -ul este produsul secundar al procesului de dezvoltare, conform ingineriei software . Acest produs este intrinsec evolutiv pe parcursul ciclului său de viață: în general, evoluează generând versiuni din ce în ce mai complete, complexe, îmbunătățite, optimizate într-un anumit aspect, potrivite pentru noi platforme (fie hardware sau sisteme de operare), etc. ]

Când un sistem încetează să evolueze, în cele din urmă își va finaliza ciclul de viață, va deveni învechit și, inevitabil, mai devreme sau mai târziu, va fi înlocuit cu un produs nou.

Software -ul evoluează pur și simplu pentru că trebuie să se adapteze la schimbările din mediu, fie ele funcționale (cerințele utilizatorilor), operaționale, platforme sau arhitectură hardware .

Dinamica evoluției software este studiul modificărilor sistemului. Contribuția majoră în acest domeniu a fost adusă de Meir M. Lehman și Belady , începând cu anii 1970 și 1980. Munca lor a continuat în anii 1990, cu Lehman și alți cercetători de relevanță pentru feedback-ul în procesele de evoluție (Lehman, 1996; Lehman şi colab., 1998; Lehman şi colab., 2001). Din aceste studii au propus un set de legi (cunoscute sub numele de legile lui Lehman ) privind schimbările produse în sisteme. Aceste legi (de fapt ipoteze) sunt invariante și aplicabile pe scară largă.

Lehman și Belady au analizat creșterea și evoluția mai multor sisteme software mari ; derivând în final, după măsurătorile lor, următoarele opt legi:

1. Schimbare continuă: Un program care este utilizat într-un mediu real trebuie să se schimbe în mod necesar sau va deveni progresiv mai puțin util în acel mediu.
2. Creșterea complexității: Pe măsură ce un program în evoluție se schimbă, structura lui tinde să devină din ce în ce mai complexă. Resursele suplimentare trebuie alocate pentru conservarea și simplificarea structurii.
3. Evoluție prelungită a programului: Evoluția programului este un proces de autoreglare. Atributele sistemului, cum ar fi dimensiunea, timpul dintre lansări și numărul de erori documentate, sunt aproximativ invariante pentru fiecare versiune de sistem.
4. Stabilitate organizațională: Pe durata de viață a unui program, viteza de dezvoltare a acestuia este aproximativ constantă și independentă de resursele dedicate dezvoltării sistemului.
5. Conservarea familiarității: Pe durata de viață a unui sistem, modificarea incrementală în fiecare lansare este aproximativ constantă.
6. Creștere continuă: funcționalitatea oferită de sisteme trebuie să crească continuu pentru a menține satisfacția utilizatorilor.
7. Scăderea calității: calitatea sistemelor software va începe să scadă dacă aceste sisteme nu se adaptează la schimbările din mediul lor de operare.
8. Feedback de sistem: procesele Evolution încorporează sisteme de feedback multi-agent și multi-buclă și acestea trebuie tratate ca sisteme de feedback pentru a obține o îmbunătățire semnificativă a produsului.

Bibliografie

Cărți

• JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James (2000). Procesul de dezvoltare software unificat . Pearson Addison-Wesley. 

• Pressman, Roger S. (2003). Software Engineering, A Practical Approach (ediția a cincea ediție). McGraw Hill. ISBN  84-481-3214-9 . 

• IACOBSON; BOOCH; RUMBAUGH (1999). UML - Limbajul unificat de modelare . Pearson Addison-Wesley. Rational Software Corporation, Addison Wesley Iberoamericana. ISBN  84-7829-028-1 . 

• Haeberer, AM; PAS Veloso, G. Baum (1988). Formalizarea procesului de dezvoltare software (Ediția preliminară). Buenos Aires: Kapelusz. ISBN  950-13-9880-3 . 

• Fowler, Martin; Kendall Scott (1999). UML picătură cu picătură . Addison Wesley. ISBN  9789684443648 . 

• Loucopoulos, Pericles; Karakostas, V. (1995). Ingineria cerințelor de sistem . Londra: Companiile McGraw-Hill. pp. 160p ISBN  978-0077078430 . 

• Sommerville, Ian; P. Sawyer (1997). Ingineria cerințelor: un ghid de bune practici ( ediția prima ediție). Wiley & Sons. pp. 404 pagini ISBN  978-0471974444 . Recuperat în 2008 . 

• Gottesdiener, Ellen; P. Sawyer (2002). Cerințe prin colaborare : Ateliere pentru definirea nevoilor . Addison-Wesley Professional. pp. 368 pagini ISBN  978-0201786064 . Recuperat în 2008 . 

• Sommerville, Ian (2005). Inginerie software (ediția a 7-a). Madrid: Pearson Education S.A. ISBN  84-7829-074-5 . 

Articole și reviste

• Weitzenfeld - „Procesul de dezvoltare software” - 2002
• Carlos Reynoso - „Metode heterodoxe în dezvoltarea software-ului” - 2004
• Grupul ISSI - Universitatea Politehnică din Valencia - «Metodologii Agile în Dezvoltarea Software-ului» - 2003
• Martin Fowler - „Noua metodologie” - 2003
• Cutter IT Journal – „Ingineria și managementul cerințelor”. 25 august 2000. Cutter Consortium.
• „Software Requirements Engineering”, ediția a doua, IEEE Computer Society. Los Alamitos, CA, 1997 (Compendiu de lucrări și articole despre ingineria cerințelor).
• Lehman, MM - «Legile evoluției software revizuite», poz. pap., EWSPT96, octombrie 1996, LNCS 1149, Springer Verlag, 1997, p. 108-124

Vezi și

• inginerie software
• Program de calculator
• program calculator
• Programare
• Faze de dezvoltare software
• software de colaborare
• software gratuit _
• liber versus gratuit
• Inginerie informatică
• cod puturos

Modele de ciclu de viață

• Model în cascadă sau secvenţial
• Model iterativ incremental
• model evolutiv în spirală
• model prototip
• model de dezvoltare rapidă

Link- uri externe

• Portal:Software . Conținut legat de software .
• Wikimedia Commons găzduiește o galerie media despre software .
• Wikționarul are definiții și alte informații despre software .