Etape de dezvoltare software

Programarea profesională presupune că rezultatul muncii, un produs software, va fi folosit de un anumit cerc de oameni, utilizatori. În faza de dezvoltare a unui program la care poate participa un grup de persoane, utilizatorii sunt reprezentați de Client.

Pentru a finaliza sarcina de a crea și opera software, acesta este împărțit în anumite etape:

1. Enunțarea problemei.

2. Întocmirea unui algoritm.

3. Întocmirea și introducerea programului.

4. Depanarea și testarea programului.

5. Escortă produs software.

Crearea oricărui program începe cu enunțul problemei. Initial, problema se pune in termenii unora domeniul subiectului, și este necesar să o traducem în concepte și expresii care sunt mai apropiate de programare. Deoarece programatorul are inițial rareori o înțelegere aprofundată a domeniului subiectului, iar Clientul înțelege foarte rar programarea, stabilirea problemei poate deveni un proces iterativ foarte dificil.

Declarația problemei se termină cu crearea termeni de referință, și apoi specificarea programului extern, care include:

1. Descrierea datelor sursă și a rezultatelor (tipuri, prezentare, acuratețe, limitări etc.).

2. Descrierea sarcinii implementate de program.

3. Metoda de accesare a programului.

4. Descrierea posibilelor situații speciale și de urgență și erori ale utilizatorului.

În această etapă, programul este considerat o „cutie neagră”, pentru care se determină funcția pe care o îndeplinește, datele de intrare și de ieșire. Modul în care sunt realizate funcțiile nu este indicat aici.

La a doua etapă Se dezvoltă algoritmi definiți prin specificații și se formează (proiectează) structura generală a programelor. Tehnologia de design de sus în jos este de obicei folosită aici folosind metodă detalierea pas cu pas . Adică, mai întâi, un algoritm mărit este compilat în forma sa cea mai generală. Apoi pașii (blocurile) sunt specificați cu mai multe descriere detaliată. În această etapă, descrierile sunt produse într-un limbaj înțeles de oameni, folosind o formă specifică de notație algoritmică. În programare, o formă grafică de notație sub formă de diagrame de flux sau diagrame grafice este utilizată pe scară largă.

A treia etapă Aceasta este tocmai programarea într-un limbaj înțeles de computer. În esență, a treia etapă este o continuare a celei de-a doua, deoarece programul este și o formă de înregistrare a unui algoritm cu gradul maxim de detaliu - software.

Învățarea unuia dintre limbajele de programare nivel înalt iar acest curs este dedicat.

Etapa a patra presupune eliminarea tuturor erorilor și neînțelegerilor apărute în etapele anterioare. A greși este uman, așa că a patra etapă primește multă atenție.

Există o mare varietate de metode și recomandări pentru testare și depanare. Este necesar să se facă distincția între aceste două concepte. Testare este procesul prin care un program este verificat să funcționeze corect și să îndeplinească toate specificațiile de proiectare. În special, un set de teste este creat în aceste scopuri. Depanare– procesul de corectare a erorilor din program. Astfel, în timpul depanării, erorile de sintaxă, erorile algoritmice, erorile descoperite în timpul testării și altele sunt corectate.

Etapa a cincea apare atunci când produsul software este pus în funcțiune (sau încep vânzările sale). Aici este, de asemenea, posibilă detectarea erorilor care nu au fost găsite în etapa de testare - acestea trebuie să fie localizate și corectate. În plus, este posibilă modificarea proprietăților programului pentru ușurință în utilizare: elemente de interfață, unele funcții etc. S-ar părea că a cincea etapă este cea mai simplă. Dar i se alocă cea mai mare parte din timp și bani: până la jumătate sau mai mult.

Toate aceste etape de dezvoltare și întreținere a unui produs software, inclusiv finalizarea suportului operațional, constituie ciclul de viață al programului.

O altă împărțire în etape este posibilă cu o împărțire aproximativă în funcție de timpul de implementare, așa cum este indicat în Fig. 1.1:

1. Analiza cerințelor.

2. Determinarea caietului de sarcini.

3. Design.

4. Codificare.

5. Testare offline.

6. Testare cuprinzătoare.

Orez. 1.1. Costuri de timp pentru implementarea etapelor ciclului de dezvoltare software (cu excepția etapei de operare și întreținere)

Mai mult de jumătate din timp este alocat ultimei etape de operare și întreținere a produselor software mari: până la 67% din timpul total al ciclului de viață.

Numit clasic următorul set etape (procese) tehnologice:

1. Originea și cercetarea ideii

2. Management

3. Analiza cerințelor

4. Design

5. Programare

6. Testare și depanare

7. Punerea în funcţiune

8. Operare și întreținere

9. Încetarea funcționării

Procesele ciclului de viață software definite standard international ISO 12207 și sunt împărțite în trei grupuri (fără referire la timp):

· Procese principale: achizitie, furnizare, dezvoltare, operare, suport.

· Procese suport: documentare, managementul configurației, asigurarea calității, verificare, certificare, evaluare comună, audit, rezolvare a problemelor.

· Procese organizaționale: management, crearea infrastructurii, îmbunătățire, instruire.

Enunțarea problemei. Crearea oricărui program începe cu setarea unei probleme. Inițial, sarcina este formulată în funcție de aria subiectului și este necesară traducerea

Orez. 26.1.

în limbajul conceptelor mai apropiate de programare. Deoarece programatorul are rareori o înțelegere aprofundată a domeniului subiectului, iar clientul are o înțelegere aprofundată a programării (un exemplu simplu: trebuie să scrieți un program de contabilitate), stabilirea unei probleme poate deveni un proces iterativ foarte dificil. În plus, atunci când stabilește o sarcină, clientul de multe ori nu își poate formula clar și complet cerințele și criteriile.

În această etapă se determină și mediul în care va fi executat programul: cerințe hardware, OS și alte programe software utilizate.

Declarația problemei se termină cu crearea specificatii tehnice, si apoi specificația programului extern, inclusiv:

■ descrierea datelor sursă și a rezultatelor (tipuri, formate, acuratețe, metodă de transmitere, restricții);

■ descrierea sarcinii implementate de program;

■ metoda de accesare a programului;

■ descrierea posibilelor situații de urgență și erori ale utilizatorului.

Astfel, programul este considerat ca o „cutie neagră” pentru care sunt definite o funcție și date de intrare și de ieșire.

Selectarea unui model și a unei metode de rezolvare a problemei.În această etapă se analizează condițiile problemei, iar pe această bază se construiește și se determină un model al problemei. metoda generala deciziile ei. La construirea unui model sunt identificate caracteristicile problemei care sunt semnificative din punct de vedere al considerației, adică. este abstractizată. Aceste caracteristici trebuie să fie reprezentate în model cu completitatea și acuratețea necesare. Cu alte cuvinte, în această etapă se formalizează enunțul problemei și pe această bază se determină metoda generală de rezolvare a acesteia. Dacă există mai multe metode, cea mai bună este selectată pe baza criteriilor de complexitate, eficiență, acuratețe, în funcție de sarcinile specifice cu care se confruntă programatorul.

Dezvoltarea structurilor interne de date. Majoritatea algoritmilor depind de modul în care sunt organizate datele, așa că este intuitiv ca proiectarea unui program să înceapă nu cu algoritmi, ci cu dezvoltarea structurilor necesare pentru a reprezenta datele de intrare, ieșire și intermediare. În acest caz, sunt luați în considerare mulți factori, de exemplu, restricțiile privind dimensiunea datelor, precizia necesară și cerințele privind viteza programului. Structurile de date pot fi statice sau dinamice.

Când decideți cum vor fi organizate datele într-un program, este util să vă puneți următoarele întrebări.

■ Câtă acuratețe a datelor este necesară?

■ Care este intervalul valorilor datelor?

■ Este limitat? cantitate maxima date?

■ Este necesar să le stocați în program în același timp?

■ Ce acțiuni vor trebui efectuate asupra datelor?

De exemplu, dacă cantitatea maximă de date de același tip care trebuie procesată este cunoscută și mică, cel mai simplu mod este să creați o matrice statică pentru a o stoca. Dacă există multe astfel de matrice, segmentele de date și stiva ar putea să nu fie suficiente și va trebui să alocați spațiu în memoria dinamică pentru aceste matrice.

Dacă cantitatea maximă de date este necunoscută și se modifică constant în timp ce programul rulează, atunci structurile dinamice sunt folosite pentru a o stoca. Alegerea tipului de structură depinde de operațiunile necesare asupra datelor. De exemplu, pentru căutare rapidă elemente, un arbore binar este cel mai bun, iar dacă datele trebuie procesate în ordinea în care sosesc, se folosește o coadă.

Proiecta. Sub proiectarea programului definiția este înțeleasă structura generalași interacțiunea modulelor.

În această etapă se aplică tehnologie de design de sus în jos, a cărui idee principală este discutată mai sus. În acest caz, se folosește metoda de detaliere pas cu pas.

Vă puteți imagina acest proces în așa fel încât mai întâi programul să fie scris în limba unei mașini ipotetice care este capabilă să înțeleagă cele mai generale acțiuni, apoi fiecare dintre ele este descrisă la un nivel inferior de abstractizare etc. Este foarte important în această etapă specificația interfeței, aceste. determinarea modului în care subsarcinile interacționează.

Pentru fiecare subsarcină se întocmește o specificație externă similară cu cea dată mai devreme. În aceeași etapă sunt rezolvate problemele împărțirii programului în module, principalul criteriu fiind acela de a minimiza interacțiunea acestora. O sarcină poate fi implementată folosind mai multe module și invers, mai multe sarcini pot fi rezolvate într-un singur modul. Ei trec la un nivel inferior de proiectare numai după finalizarea proiectării nivelului superior. Algoritmii sunt scrisi într-o formă generalizată, cum ar fi cuvinte, diagrame generalizate sau alte metode.

ATENŢIE

În timpul fazei de proiectare, ar trebui să luați în considerare posibilitatea unor modificări viitoare ale programului și să vă străduiți să proiectați programul în așa fel încât modificările să fie cât mai simple posibil.

Deoarece nu se știe ce modificări vor trebui făcute, această dorință seamănă cu crearea " teorie generală totul"; în practică, trebuie să te limitezi la compromisuri rezonabile. Programatorul, pe baza experienței și a bunului său simț, decide ce caracteristici ale programului ar putea trebui schimbate sau îmbunătățite în viitor.

Procesul de proiectare este iterativ deoarece programele dimensiunea reală Este imposibil să te gândești la toate detaliile de prima dată.

Programare structurată. Programarea aici este considerată „în sens restrâns”, adică. este înțeles ca scrierea unui program într-un limbaj de programare folosind un algoritm gata făcut. Acest proces este adesea numit codificare pentru a o deosebi de ciclul complet de dezvoltare a programului.

Codarea este, de asemenea, organizată de sus în jos: mai întâi, modulele de nivel superior sunt codificate și cazurile de testare sunt compilate pentru a le depana. În același timp, în locul modulelor care nu au fost încă scrise nivelul următor Sunt instalate stub-uri, care în cel mai simplu caz emit pur și simplu un mesaj că le-a fost transferat controlul și apoi îl returnează la modulul de apelare. În alte cazuri, stub-ul poate produce valori care sunt predefinite sau calculate folosind un algoritm simplificat.

Astfel, este mai întâi creat scheletul logic al programului, care este apoi acoperit cu carnea codului. Ar părea mai logic să se aplice tehnologia de jos în sus procesului de programare: mai întâi scrieți și depanați modulele nivel inferior, și apoi combinați-le în fragmente mai mari, dar această abordare are câteva dezavantaje.

În primul rând, în procesul de codificare a nivelului superior, anumite dificultăți în proiectarea mai multor niveluri scăzute program (pur și simplu pentru că atunci când scrieți un program logica acestuia este gândită mai atent decât atunci când îl proiectați). Dacă eroare similară este descoperit ultimul, sunt necesare costuri suplimentare pentru reprelucrare deja module gata făcute nivel inferior.

În al doilea rând, pentru a depana fiecare modul, și apoi fragmente mai mari ale programului, este necesar să-și compună propriile cazuri de testare de fiecare dată, iar programatorul este adesea forțat să imite mediul în care trebuie să funcționeze modulul. Tehnologia de programare de sus în jos oferă o ordine naturală pentru crearea testelor - posibilitatea de depanare de sus în jos, care este discutată mai jos.

Etapele de proiectare și programare sunt combinate în timp: în mod ideal, designul și codul sunt pe primul loc nivel superior, apoi următorul etc. Această strategie este utilizată deoarece reduce costul erorii, deoarece poate fi necesar să se facă modificări în timpul procesului de codificare care afectează modulele de nivel inferior.

Testare de sus în jos. Această etapă este înregistrată ultima, dar aceasta nu înseamnă că testarea nu ar trebui efectuată în etapele anterioare. Atât proiectarea, cât și programarea trebuie să fie însoțite de scris suită de teste – datele inițiale de verificare și seturile corespunzătoare de reacții standard.

Este necesar să se facă distincția între procesele de testare și depanare a unui program. Testare este procesul prin care se verifică corectitudinea unui program. Testarea este pozitivă și scopul său este să arate că programul funcționează corect și îndeplinește toate specificațiile de proiectare. Depanare– procesul de corectare a erorilor dintr-un program, în care scopul nu este corectarea tuturor erorilor. Corectează erorile găsite în timpul testării. La planificare, trebuie luat în considerare faptul că procesul de detectare a erorilor respectă legea saturației, adică. Cele mai multe erori sunt descoperite în primele etape ale testării, iar cu cât rămân mai puține erori în program, cu atât va dura mai mult pentru a găsi fiecare dintre ele.

Există două strategii de testare: cutie neagră și cutie albă. La utilizarea primului, structura internă a programului nu este luată în considerare și testele sunt concepute astfel încât să verifice pe deplin funcționarea programului pe influențe de intrare corecte și incorecte.

Strategia cutiei albe presupune testarea tuturor ramurilor algoritmului. Numărul total de ramuri este determinat de combinarea tuturor alternativelor în fiecare etapă. Acesta este un număr finit, dar poate fi foarte mare, astfel încât programul este împărțit în fragmente, după care, după o testare exhaustivă, acestea sunt tratate ca noduri elementare de ramuri mai lungi. Pe lângă datele care asigură executarea instrucțiunilor în succesiunea cerută, testele trebuie să conțină verificarea conditiilor la limita(de exemplu, tranziție după condiție X> 10 trebuie verificat pentru valori mai mari, mai mici și egale cu 10). Răspunsul programului la date sursă eronate.

Dezavantaj Strategia „cutie albă” este că este imposibil să se detecteze o ramură lipsă utilizând-o, iar strategia „cutie neagră” necesită un număr mare de opțiuni de introducere, așa că în practică se folosește o combinație a ambelor strategii.

ATENŢIE

Ideea testării de sus în jos sugerează că testarea unui program începe înainte ca proiectarea acestuia să fie finalizată. Acest lucru vă permite să încercați mai devreme principalele interfețe intermodulare și, de asemenea, să vă asigurați că programul satisface practic cerințele utilizatorului. Abia după ce nucleul logic a fost testat într-o asemenea măsură încât să existe încredere în implementarea corectă a interfețelor principale, începem să codificăm și să testăm următorul nivel al programului.

Natural, testare completă un program în timp ce este prezentat sub forma unui schelet este imposibil, dar adăugarea fiecărui nivel următor vă permite să extindeți treptat zona de testare.

Faza de depanare end-to-end la nivel de sistem a designului de sus în jos durează mai puțin timp decât proiectarea de jos în sus și produce mai puține surprize, deoarece este mult mai puțin probabil să introducă erori majore care afectează o mare parte a sistemului. În plus, pentru fiecare modul conectat la sistem, mediul său a fost deja creat, iar datele de ieșire ale modulelor depanate pot fi folosite ca intrare pentru testarea altora, ceea ce facilitează procesul de testare. Acest lucru nu înseamnă că modulul trebuie conectat la sistem complet „brut”, poate fi convenabil să se efectueze o parte a testării în mod autonom, deoarece este dificil să se genereze la intrarea sistemului toate opțiunile necesare pentru testarea unui modul separat; .

Modelul în cascadă în forma sa pură este utilizat numai pentru programe simple, deoarece este dificil să se prevadă toate detaliile de implementare în avans. O schemă mai realistă este cu controlul intermediar (Fig. 26.2). Controlul efectuat după fiecare etapă permite, dacă este necesar, revenirea la orice nivel superior și efectuarea modificărilor necesare.

Principalul pericol al folosirii unei astfel de scheme este că dezvoltarea nu va fi niciodată finalizată, fiind în permanență într-o stare de rafinament și îmbunătățire.

Orez. 26.2.

• Tipurile și formatele nu se referă la tipurile de limbaje de programare.

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

Avantajul acestui model este că limitează posibilitatea de a reveni la un pas arbitrar înapoi, de exemplu, de la testare la analiză, de la dezvoltare la lucru pe cerințe etc. S-a remarcat că astfel de returnări ar putea crește catastrofal costul proiectului și timpul de finalizare a acestuia. De exemplu, dacă în timpul testării sunt descoperite erori de proiectare sau analiză, corectarea lor duce adesea la o reproiectare completă a sistemului. Acest model a permis întoarcerea doar la pasul anterior, de exemplu, de la testare la codificare din software, acest model a fost criticat activ de aproape fiecare autor de articole și manuale relevante; A devenit o opinie general acceptată că nu reflectă caracteristicile dezvoltării software. Dezavantajele modelului de cascadă sunt:

• identificarea fazelor și activităților, ceea ce implică o pierdere a flexibilității dezvoltării, în special dificultăți în susținerea unui proces iterativ de dezvoltare;
• cerința finalizării complete a fazei de activitate, consolidarea rezultatelor sub forma unui document sursă detaliat (sarcina tehnică, caietul de sarcini); cu toate acestea, experiența în dezvoltarea de software arată că este imposibil să finalizați complet dezvoltarea cerințelor, proiectarea sistemului etc. – toate acestea pot fi modificate; iar motivele pentru aceasta nu sunt doar faptul că mediul de proiect este fluid, ci și faptul că multe decizii nu pot fi determinate și formulate cu acuratețe în prealabil, acestea sunt clarificate și precizate abia ulterior;
• integrarea tuturor rezultatelor dezvoltării are loc la final, drept urmare problemele de integrare se simt prea târziu;
• utilizatorii și clientul nu se pot familiariza cu opțiunile sistemului în timpul dezvoltării și văd rezultatul doar la sfârșit; astfel, acestea nu pot influența procesul de creare a sistemului și, prin urmare, cresc riscurile de neînțelegere între dezvoltatori și utilizatori/client;
• modelul este instabil la eșecurile în finanțarea sau redistribuirea proiectelor numerar, dezvoltarea care a început, de fapt, nu are alternative „pe parcurs”.

Cu toate acestea acest model continuă să fie utilizat în practică - pentru proiecte mici sau în dezvoltarea de sisteme standard, unde iterativitatea nu este atât de solicitată. Cu ajutorul acestuia, este convenabil să urmăriți dezvoltarea și să efectuați controlul pas cu pas asupra proiectului. Acest model este adesea folosit și în proiecte offshore 1 Din engleza offshore - în afara țărmului, într-o interpretare extinsă - în afara unei țări. cu salarii pe ora. Modelul cascadă a fost încorporat ca componentă în alte modele și metodologii, cum ar fi MSF.

Model în spirală a fost propus de Barry Boehm în 1988 pentru a depăși neajunsurile modelului cascadei, în primul rând pentru management mai bun riscuri. Conform acestui model, dezvoltarea produsului se desfășoară într-o spirală, fiecare tură fiind o fază specifică de dezvoltare. Spre deosebire de modelul în cascadă, modelul în spirală nu are un set de ture predeterminat și obligatoriu, fiecare tură poate fi ultima în timpul dezvoltării sistemului, la finalizarea acestuia, se întocmesc planuri pentru tura următoare; În fine, o revoluție este tocmai o fază, și nu un tip de activitate, așa cum în modelul în cascadă se pot desfășura multe lucruri în cadrul acestuia; diverse tipuri activitate, adică modelul este bidimensional.

Succesiunea turelor poate fi următoarea: la prima tură se ia o decizie privind fezabilitatea creării software-ului, la următoarea se iau deciziile cerinţele de sistem , atunci sistemul este proiectat etc. Virajele pot avea alte semnificații.

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

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

O spirală separată poate corespunde dezvoltării unei componente software sau introducerii unor modificări regulate ale produsului. Astfel, modelul poate avea o a treia dimensiune.

Modelul în spirală nu este indicat de utilizat în proiecte cu un grad scăzut de risc, cu un buget limitat, pentru proiecte mici. În plus, lipsa fonduri bune prototiparea poate face, de asemenea, modelul în spirală incomod de utilizat.

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

Acest articol nu are link-uri către surse de informații. Informațiile trebuie să fie verificabile, altfel pot fi puse sub semnul întrebării și șterse. Poți... Wikipedia

Acest articol este propus spre ștergere. O explicație a motivelor și discuția corespunzătoare pot fi găsite pe pagina Wikipedia: A fi șters/30 iulie 2012. În timp ce discuția este în desfășurare... Wikipedia

- (Engleză: Software project management) un tip special de management de proiect, în cadrul căruia are loc planificarea, urmărirea și controlul proiectelor de dezvoltare software. Punctul cheieîn managementul proiectelor pentru... ... Wikipedia

- (software) o perioadă de timp care începe din momentul în care se ia o decizie privind necesitatea creării unui produs software și se termină în momentul în care acesta este complet retras din serviciu. Acest ciclu este procesul de construire și dezvoltare a software-ului. Cuprins 1 Standarde ... ... Wikipedia

Cea mai comună metodă de numerotare a versiunilor astăzi Ciclu de viață de succes program de calculator poate fi foarte lung; Modificările unui program variază de la remedieri de erori până la rescrieri complete. În durere... Wikipedia

Când Grace Hopper lucra la computerul Harvard Mark II de la Universitatea Harvard, colegii ei au descoperit această molie blocată într-un releu și interferând astfel cu funcționarea dispozitivului, după care a observat că „depanează” sistemul.... .. . Wikipedia

Dezvoltarea software (ing. inginerie software, dezvoltare software) este un tip de activitate (profesie) și un proces care vizează crearea și menținerea funcționalității, calității și fiabilității software-ului folosind ... Wikipedia

Noul Airbus A 380 folosește destul de mult software pentru a crea o cabină modernă în avion. Metoda de inginerie software a făcut posibilă crearea de software pentru aeronave descris în milioane de rânduri... Wikipedia

Dezvoltare software Proces de dezvoltare software Etape ale procesului Analiză Proiectare Programare Document ... Wikipedia

Cărți

• Poveștile utilizatorilor. Dezvoltare software agilă, Mike Con. În User Stories: Agile Software Development de Mike Cohn, care a fost așteptat cu nerăbdare de comunitatea agilă...
• Povești utilizator: Dezvoltare software agilă, Mike Con. Această carte, care a fost așteptată cu nerăbdare de comunitatea de dezvoltare software agilă, descrie procesul de pregătire a cerințelor pentru o dezvoltare software...

Expresia „scrie un program” reflectă doar una dintre etapele creării unui program de calculator, când dezvoltatorul de program (programatorul) scrie de fapt comenzi (instrucțiuni) pe hârtie sau folosind un editor de text. Programarea este procesul de creare (dezvoltare) a program, care poate fi reprezentat printr-o succesiune a următorilor pași:

1. Caietul de sarcini (definirea, formularea cerințelor pentru program).

2. Dezvoltarea algoritmului.

3. Codare (scrierea unui algoritm într-un limbaj de programare).

4. Depanare.

5. Testare.

6. Crearea unui sistem de ajutor.

7. Creați un disc de instalare (CD-ROM).

Specificație - Specificare, determinarea cerințelor pentru program - una dintre cele mai importante etape în care informațiile inițiale sunt descrise în detaliu, sunt formulate cerințele pentru rezultat, comanda programului în cazuri speciale (de exemplu, la introducerea date incorecte), sunt dezvoltate casete de dialog, oferind interacțiune între utilizator și program.

Dezvoltarea algoritmului - La etapa de dezvoltare a algoritmului este necesar să se determine succesiunea acțiunilor care trebuie efectuate pentru a obține rezultatul. Dacă o problemă poate fi rezolvată în mai multe moduri și, prin urmare, sunt posibile diferite variante ale algoritmului de rezolvare, atunci programatorul, folosind un anumit criteriu, de exemplu, viteza de rezolvare a algoritmului, selectează cel mai mult solutie potrivita. Rezultatul etapei de dezvoltare a algoritmului este o descriere verbală detaliată a algoritmului sau a diagramei bloc ale acestuia,

Codare - După ce cerințele pentru program sunt determinate și algoritmul soluției este compilat, algoritmul este scris în limbajul de programare selectat. Rezultatul este programul original.

Depanarea este procesul de găsire și eliminare a erorilor. Erorile din program sunt împărțite în două grupe: sintactice (erori în text) și algoritmice. Erori de sintaxă- cel mai usor de eliminat. Erorile algoritmice sunt mai greu de detectat. Etapa de depanare poate fi considerată completă dacă programul funcționează corect pe unul sau două seturi de date de intrare.

Testare - Faza de testare este deosebit de importantă dacă vă așteptați ca alții să vă folosească programul. În această etapă, ar trebui să verificați cum se comportă programul cât mai bine posibil. Mai mult seturi de date de intrare, inclusiv cele care sunt în mod evident incorecte.

Crearea unui sistem de ajutor - Dacă dezvoltatorul se așteaptă ca programul să fie utilizat de alții, atunci trebuie să creeze un sistem de ajutor și să ofere utilizatorului acces convenabil la informații de ajutor în timp ce lucrează cu programul. În programele moderne, informațiile de referință sunt prezentate sub formă de fișiere CHM sau HLP. Pe lângă informațiile de ajutor, care sunt accesate din program în timp ce acesta rulează, sistemul de ajutor include instrucțiuni pentru instalarea programului, care este pregătit sub forma unui fișier Readme într-unul dintre

formate: TXT, DOC sau NTM.

Crearea unui disc de instalare - Se creează un disc de instalare sau un CD-ROM, astfel încât utilizatorul să poată instala independent, fără ajutorul unui dezvoltator, programul pe computerul său. De obicei, pe lângă programul în sine, discul de instalare conține fișiere de ajutor și instrucțiuni pentru instalarea programului (fișierul Citiți-mă). Ar trebui să se înțeleagă că programe moderne, inclusiv cele dezvoltate în Delphi, în majoritatea cazurilor (cu excepția celor mai multe programe simple) nu poate fi instalat pe computerul utilizatorului de către copiere simplă, deoarece pentru munca lor au nevoie de biblioteci și componente speciale pe care un anumit utilizator poate să nu le aibă. Prin urmare, instalarea programului pe computerul utilizatorului trebuie să fie efectuată de un program special care este plasat disc de instalare. De regulă, program de instalare creează folder separat pentru programul instalat, îl copiază în el fisierele necesareși, dacă este necesar, efectuează configurarea sistem de operare prin completari si modificari la registru.