Procese și etape ale ciclului de viață al software-ului. Ciclul de viață al software-ului. Etape și etape. Domeniul de aplicare al modelului cascadă

Ciclu de viață software(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 retragerii complete din serviciu. Acest ciclu este procesul de construire și dezvoltare a software-ului.

Etape ciclu de viață :

2. Design

3. Implementare

4. Asamblare, testare, testare

5. Implementare (lansare)

6. Escortă

Există 2 cazuri de producție de software: 1) Software-ul este realizat pentru un anumit client. În acest caz, aveți nevoie sarcina aplicata se transformă într-un programator. Este necesar să înțelegem cum funcționează mediul care trebuie automatizat (analiza procesului de afaceri). Ca urmare, apare o documentație-specificație a cerinței, unde exact ce sarcini trebuie indicate. rezolvate si in ce conditii. Această activitate este efectuată de un analist de sisteme (analist de procese de afaceri).

2) Software-ul este dezvoltat pentru piață. Este necesar să se efectueze cercetare de piatași găsiți ce produs nu este pe piață. Acest lucru este asociat cu un risc mare. Scopul este de a dezvolta o specificație de cerințe.

Proiecta

Scopul este de a determina structura generală (arhitectura) a software-ului. Rezultatul este o specificație software. Programatorul de sistem face această treabă.

Implementarea

Scrierea codului programului. Implementarea include dezvoltarea, testarea și documentarea.

Asamblare, testare, testare

Asamblarea a tot ceea ce a fost făcut de diferiți programatori. Testarea întregului pachet software. Depanare - găsirea și eliminarea cauzelor erorilor. Test - rafinament caracteristici tehnice... Drept urmare, programul este garantat să funcționeze.

Implementare (lansare)

Implementare - atunci când lucrează pentru un singur client. Include configurarea programului la locul clientului, instruirea clientului, consultanta, eliminarea erorilor si a neajunsurilor evidente. Software-ul ar trebui să fie înstrăinat - utilizatorul poate lucra cu software-ul fără participarea autorului.

Lansare - când software-ul este dezvoltat pentru piață. Începe cu faza de testare beta. Corespunzător versiune - versiune beta. Alpha testing este testarea de către persoane din aceeași organizație care nu au fost implicate în dezvoltarea programelor. Testare beta - realizarea mai multor copii ale software-ului și trimiterea acestuia către potențiali clienți. Scopul este de a verifica din nou dezvoltarea software-ului.

Dacă un software fundamental nou este lansat pe piață, atunci sunt posibile mai multe teste beta. După testarea beta - lansarea versiunii comerciale.

Escorta

Eliminarea erorilor observate in timpul functionarii. Făcând îmbunătățiri minore. Acumularea de propuneri pentru dezvoltarea versiunii următoare.

Modele de ciclu de viață

1. Cascada („cascada”, model în cascadă)

2. Prototiparea

În primul rând, nu produsul software în sine este dezvoltat, ci prototipul său, care conține soluția la principalele probleme cu care se confruntă dezvoltatorii. După finalizarea cu succes a dezvoltării prototipului, produsul software real este dezvoltat după aceleași principii. Prototipul vă permite să înțelegeți mai bine cerințele pentru programul dezvoltat. Prin utilizarea prototipului, clientul își poate formula cerințele mai precis. Dezvoltatorul are posibilitatea de a prezenta clientului rezultatele preliminare ale muncii sale folosind un prototip.

3. Model iterativ

Sarcina este împărțită în subsarcini și se determină ordinea implementării acestora, astfel încât fiecare subsarcină ulterioară extinde capacitățile software-ului. Succesul depinde în esență de cât de bine sunt împărțite sarcinile în subsarcini și de modul în care este aleasă ordinea. Avantaje: 1) posibilitatea de participare activă a clientului la dezvoltare, acesta având posibilitatea de a-și clarifica cerințele pe parcursul dezvoltării; 2) capacitatea de a testa piese nou dezvoltate împreună cu cele dezvoltate anterior, aceasta va reduce costul depanării complexe; 3) în timpul dezvoltării, puteți începe implementarea în părți.

Ciclul de viață al software-ului

Ciclul de viață al software-ului este o perioadă de timp care începe din momentul în care se ia o decizie cu privire la necesitatea creării unui produs software și se termină în momentul retragerii complete din serviciu. (standard IEEE Std 610.12)

Necesitatea de a determina etapele ciclului de viață software (LC) se datorează dorinței dezvoltatorilor de a îmbunătăți calitatea software-ului prin managementul optim al dezvoltării și utilizarea diferitelor mecanisme de control al calității în fiecare etapă, de la formularea problemei până la suportul autorului pentru software. Cea mai generală reprezentare a ciclului de viață al software-ului este un model sub formă de etape de bază - procese, care includ:

Analiza sistemului și justificarea cerințelor software;

Proiectare software preliminară (schiță) și detaliată (tehnică);

Dezvoltarea componentelor software, integrarea acestora și depanarea software în ansamblu;

Testare, operare de probă și replicare software;

Întreținere regulată a software-ului, asistență la întreținere și analiza rezultatelor;

Întreținerea software-ului, modificarea și îmbunătățirea acestuia, crearea de noi versiuni.

Acest model este general acceptată și corespunde atât domestice documente de reglementareîn domeniul dezvoltării software, și străine. Din punctul de vedere al asigurării securității tehnologice, este recomandabil să se ia în considerare mai detaliat caracteristicile prezentării etapelor ciclului de viață în modele străine, deoarece software-ul străin este cel mai probabil purtător de defecte software de tip sabotaj.

Standardele ciclului de viață al software-ului

GOST 34.601-90

ISO / IEC 12207: 1995 (analog rusesc - GOST R ISO / IEC 12207-99)

Prezentarea grafică a modelelor de ciclu de viață vă permite să evidențiați vizual caracteristicile acestora și unele proprietăți ale proceselor.

Inițial, a fost creat un model de cascadă al ciclului de viață, în care etapele majore au început una după alta folosind rezultatele lucrări anterioare... Acesta prevede execuția secvențială a tuturor etapelor proiectului într-o ordine strict fixă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrării în etapa anterioară. Cerințele identificate în etapa formării cerințelor sunt strict documentate în formular termeni de referintași sunt înregistrate pe toată durata derulării proiectului. Fiecare etapă se încheie cu lansarea unui set complet de documentație, suficientă pentru ca dezvoltarea să fie continuată de o altă echipă de dezvoltare. Inexactitatea oricărei cerințe sau interpretarea ei incorectă, ca urmare, duce la faptul că este necesar să „revenire” la faza incipientă a proiectului, iar reelaborarea necesară nu numai că scoate echipa de proiect din program, dar adesea duce la o creștere calitativă a costurilor și, eventual, la încetarea proiectului în forma în care a fost conceput inițial. Principala concepție greșită a autorilor modelului cascadă este presupunerea că proiectul trece prin întregul proces o dată, arhitectura proiectată este bună și ușor de utilizat, designul de implementare este rezonabil și erorile de implementare sunt ușor eliminate pe măsură ce testarea progresează. Acest model presupune că toate erorile vor fi concentrate în implementare și, prin urmare, sunt eliminate uniform în timpul testării componentelor și a sistemului. Prin urmare, model de cascadă pentru proiecte mari nu este foarte realist și poate fi folosit eficient doar pentru crearea de sisteme mici.

Cel mai specific este modelul ciclului de viață în spirală. În acest model, atenția este concentrată asupra procesului iterativ al etapelor inițiale de proiectare. În aceste etape, conceptele, specificațiile cerințelor, proiectarea preliminară și detaliată sunt create succesiv. La fiecare etapă se precizează conținutul lucrării și se concentrează aspectul software-ului creat, se evaluează calitatea rezultatelor obținute și se planifică munca următoarei iterații. La fiecare iterație se evaluează următoarele:

Riscul depășirii termenilor și costului proiectului;

Necesitatea de a efectua încă o iterație;

Gradul de completitudine și acuratețe al înțelegerii cerințelor pentru sistem;

Fezabilitatea rezilierii proiectului.

Standardizarea ciclului de viață al software-ului se realizează în trei direcții. Prima direcție este organizată și promovată de către Organizația Internațională de Standardizare (ISO – International Standard Organization) și Comisia Electrotehnică Internațională (IEC – Comisia Electrotehnică Internațională). La acest nivel se realizează standardizarea celor mai generale procese tehnologice care sunt importante pentru cooperarea internațională. A doua direcție este dezvoltată în mod activ în SUA de către Institutul de Ingineri Electrotehnici și Electronici (IEEE) împreună cu Institutul Național American de Standarde (ANSI). Standardele ISO / IEC și ANSI / IEEE sunt în mare parte de natură consultativă. A treia zonă este stimulată de Departamentul de Apărare al SUA (Departamentul de Apărare-DOD). Standardele DOD sunt obligatorii pentru firmele comandate de Departamentul Apărării al SUA.

Pentru proiectare software sistem complex, în special sistemele în timp real, este recomandabil să se utilizeze un model de ciclu de viață la nivel de sistem, bazat pe combinarea tuturor lucrărilor cunoscute în cadrul proceselor de bază considerate. Acest model este destinat utilizării în planificarea, programarea, gestionarea diverselor proiecte software.

Este recomandabil să împărțiți setul de etape ale acestui model de ciclu de viață în două părți, care diferă semnificativ în caracteristicile proceselor, caracteristicile tehnice și economice și factorii care le influențează.

În prima parte a ciclului de viață, se efectuează analiza sistemului, proiectarea, dezvoltarea, testarea și testarea software-ului. Gama lucrărilor, intensitatea muncii lor, durata și alte caracteristici în aceste etape depind în mod semnificativ de obiect și de mediul de dezvoltare. Studiul unor astfel de dependențe pentru diferite clase de software face posibilă prezicerea compoziției și principalelor caracteristici ale programelor de lucru pentru noile versiuni de software.

A doua parte a ciclului de viață, care reflectă suportul pentru operarea și întreținerea software-ului, este relativ slab legată de caracteristicile obiectului și ale mediului de dezvoltare. Gama de lucru în aceste etape este mai stabilă, iar intensitatea și durata muncii lor pot varia semnificativ și depind de utilizarea în masă a software-ului. Asigurare de înaltă calitate pentru orice model de ciclu de viață sisteme software posibil numai atunci când se utilizează un reglementat proces tehnologic la fiecare dintre aceste etape. Un astfel de proces este susținut de instrumente de automatizare a dezvoltării, care este indicat să alegeți dintre cele disponibile sau să le creați ținând cont de obiectul de dezvoltare și de lista de lucrări adecvate acestuia.

Începe prin a definiCiclul de viață al software-ului(Software Life Cycle Model) este o perioadă de timp care începe din momentul luării deciziei de a crea un produs software și se termină în momentul retragerii complete a acestuia. Acest ciclu este procesul de construire și dezvoltare a software-ului.

Modele de ciclu de viață software

Ciclul de viață poate fi reprezentat sub formă de modele. În prezent, cele mai frecvente sunt:în cascadă, incrementale (model pas cu pas cu control intermediar ) și spiralămodele de ciclu de viață.

Model în cascadă

Model în cascadă(ing. model de cascadă) Este un model al procesului de dezvoltare software, al cărui ciclu de viață arată ca un flux care trece secvenţial prin fazele de analiză şi proiectare a cerinţelor. implementare, testare, integrare și suport.

Procesul de dezvoltare este realizat folosind o succesiune ordonată de pași independenți. Modelul presupune că fiecare pas ulterior începe după finalizarea completă a pasului anterior. La toate etapele modelului, sunt efectuate procese și lucrări auxiliare și organizaționale, inclusiv managementul proiectelor, evaluarea și managementul calității, verificarea și validarea, managementul configurației și dezvoltarea documentației. Ca urmare a parcurgerii etapelor, se formează produse intermediare care nu pot fi modificate în etapele ulterioare.

Ciclul de viață este împărțit în mod tradițional în următoarele principaleetape:

Analiza cerințelor,
Proiecta,
Codare (programare),
Testare și depanare,
Operare și întreținere.

Avantajele modelului:

stabilitatea cerințelor pe parcursul întregului ciclu de viață al dezvoltării;
la fiecare etapă, se formează un set complet de documentație de proiect care îndeplinește criteriile de completitudine și coerență;
certitudinea și inteligibilitatea etapelor modelului și ușurința aplicării acestuia;
etapele de lucru desfășurate într-o succesiune logică vă permit să planificați timpul de finalizare a tuturor lucrărilor și resursele corespunzătoare (monetare, materiale și umane).

Dezavantaje ale modelului:

complexitatea formulării clare a cerințelor și imposibilitatea schimbării dinamice a acestora pe parcursul întregului ciclu de viață;
flexibilitate scăzută în managementul proiectelor;
ulterior structura liniara procesul de dezvoltare, ca urmare, revenirea la pașii anteriori pentru a rezolva problemele emergente duce la creșterea costurilor și la perturbarea programului de lucru;
neadecvarea produsului intermediar pentru utilizare;
imposibilitatea modelării flexibile a sistemelor unice;
detectarea tardivă a problemelor de asamblare datorită integrării simultane a tuturor rezultatelor la sfârșitul dezvoltării;
participarea insuficientă a utilizatorilor la crearea sistemului - la început (la dezvoltarea cerințelor) și la sfârșit (în timpul testelor de acceptare);
utilizatorii nu pot fi siguri de calitatea produsului dezvoltat până la sfârșitul întregului proces de dezvoltare. Ei nu au posibilitatea de a evalua calitatea, deoarece nu puteți vedea produsul finit al dezvoltării;
nu există nicio modalitate ca utilizatorul să se obișnuiască treptat cu sistemul. Procesul de învățare are loc la sfârșitul ciclului de viață, când software-ul a fost deja pus în funcțiune;
fiecare fază este o condiție prealabilă pentru implementarea acțiunilor ulterioare, ceea ce face din această metodă o alegere riscantă pentru sistemele care nu au analogi, deoarece sfidează modelarea flexibilă.

Este dificil de implementat modelul ciclului de viață Waterfall din cauza complexității dezvoltării software fără a reveni la pașii anteriori și a le modifica rezultatele pentru a elimina problemele emergente.

Domeniul de aplicare al modelului cascadă

Limitarea domeniului de aplicare al modelului de cascadă este determinată de dezavantajele acestuia. Utilizarea sa este cea mai eficientă în următoarele cazuri:

la dezvoltarea proiectelor cu clare, neschimbateciclu de viață cerințe, implementare și metodologie tehnică ușor de înțeles;
la dezvoltarea unui proiect axat pe construirea unui sistem sau a unui produs de același tip cu cel dezvoltat anterior de dezvoltatori;
la dezvoltarea unui proiect legat de crearea și lansarea unei noi versiuni a unui produs sau sistem existent;
la dezvoltarea unui proiect legat de transferul unui produs sau sistem existent pe o nouă platformă;
la realizarea unor proiecte mari care implică mai multe echipe mari de dezvoltare.

Model incremental

(model în trepte cu control intermediar)

Model incremental(ing. creştere- crestere, crestere) presupune dezvoltarea de software cu o succesiune liniara de etape, dar in mai multe trepte (versiuni), i.e. cu îmbunătățirea planificată a produsului pentru tot timpul până când ciclul de viață al dezvoltării software se încheie.

Dezvoltarea software-ului se realizează în iterații cu bucle de feedback între etape. Ajustările între etape fac posibilă luarea în considerare a influenței reciproce cu adevărat existente a rezultatelor dezvoltării în diferite etape, durata de viață a fiecărei etape fiind întinsă pe întreaga perioadă de dezvoltare.

La începutul lucrului la un proiect, sunt determinate toate cerințele de bază pentru sistem, subdivizate în mai mult și mai puțin importante. După aceea, sistemul este dezvoltat conform principiului incrementelor, astfel încât dezvoltatorul să poată utiliza datele obținute în cursul dezvoltării software. Fiecare increment ar trebui să adauge anumite funcționalități sistemului. Lansarea începe cu componentele cu cea mai mare prioritate. Odată ce părțile sistemului sunt definite, acestea iau prima parte și încep să o detalieze folosind procesul cel mai potrivit. În același timp, este posibil să se clarifice cerințele pentru alte părți care au fost înghețate în setul actual de cerințe ale acestei lucrări. Dacă este necesar, puteți reveni mai târziu la această parte. Daca piesa este gata, aceasta este livrata clientului, care o poate folosi la lucru. Acest lucru va permite clientului să clarifice cerințele pentru următoarele componente. Apoi dezvoltă următoarea parte a sistemului. Pașii cheie în acest proces sunt pur și simplu implementarea unui subset al cerințelor programului și rafinarea modelului într-o serie de lansări succesive până când software-ul este implementat complet.

Ciclul de viață al acestui model este tipic pentru dezvoltarea sistemelor complexe și complexe, pentru care există o viziune clară (atât din partea clientului, cât și din partea dezvoltatorului) a ceea ce ar trebui să reprezinte rezultatul final. Dezvoltarea versiunii se realizează din mai multe motive:

lipsa capacității clientului de a finanța imediat întregul proiect costisitor;
dezvoltatorul nu dispune de resursele necesare pentru a implementa un proiect complex într-un timp scurt;
cerințe pentru implementarea în etape și dezvoltarea produsului de către utilizatorii finali. Introducerea întregului sistem deodată poate provoca respingere în rândul utilizatorilor săi și nu face decât să „încetinească” procesul de tranziție la noile tehnologii. Figurat vorbind, ei pur și simplu pot „nu digera o bucată mare, așa că trebuie zdrobită și dată în părți”.

Avantajeși limităriacest model (strategie) este același cu cel al cascadei (modelul clasic al ciclului de viață). Dar spre deosebire de strategia clasică, clientul poate vedea rezultatele mai devreme. Deja pe baza rezultatelor dezvoltării și implementării primei versiuni, el poate modifica ușor cerințele pentru dezvoltare, poate să o abandoneze sau să ofere dezvoltarea unui produs mai perfect odată cu încheierea unui nou contract.

Avantaje:

costurile care sunt suportate din cauza schimbării cerințelor utilizatorilor sunt reduse, reanalizarea și colectarea documentației sunt reduse semnificativ în comparație cu modelul în cascadă;
este mai ușor să obțineți feedback de la client cu privire la munca depusă - clienții își pot exprima comentariile cu privire la piesele finite și pot vedea ceea ce a fost deja făcut. pentru că primele părți ale sistemului sunt prototipul sistemului ca întreg.
clientul are capacitatea de a achiziționa și stăpâni rapid software-ul - clienții pot obține beneficii reale din sistem mai devreme decât ar fi posibil cu un model în cascadă.

Dezavantaje ale modelului:

managerii trebuie să măsoare continuu progresul procesului. în cazul dezvoltării rapide, nu merită să creați documente pentru fiecare modificare minoră a versiunii;
structura sistemului tinde să se deterioreze atunci când sunt adăugate noi componente - schimbările constante perturbă structura sistemului. Este nevoie de timp și bani suplimentari pentru a refactoriza pentru a evita acest lucru. Structura slabă face ca software-ul să fie dificil și costisitor de schimbat. Un ciclu de viață întrerupt al software-ului duce la pierderi și mai mari.

Schema nu permite luarea în considerare promptă a schimbărilor emergente și clarificarea cerințelor software. Coordonarea rezultatelor dezvoltării cu utilizatorii se realizează numai în punctele planificate după finalizarea fiecărei etape de lucru și Cerințe generale software-ului sunt fixate sub formă de specificații tehnice pentru întreaga perioadă de creare a acestuia. Astfel, utilizatorii primesc adesea un PP care nu le satisface nevoile reale.

Model în spirală

Model spiralat:Ciclul de viață - la fiecare tură a spiralei, se creează următoarea versiune a produsului, se clarifică cerințele proiectului, se determină calitatea acestuia și se planifică activitatea următoarei ture. Atentie speciala se acordă etapelor inițiale de dezvoltare - analiză și proiectare, unde fezabilitatea anumitor solutii tehnice verificat și validat prin prototipare.

Acest model este un proces de dezvoltare software care combină atât proiectarea, cât și prototiparea pas cu pas pentru a combina avantajele unui concept de jos în sus și de sus în jos, subliniind etapele inițiale ciclu de viață: analiză și proiectare.Trăsătură distinctivă acest model pune un accent special pe riscurile care afectează organizarea ciclului de viață.

La etapele de analiză și proiectare se verifică prin prototipare fezabilitatea soluțiilor tehnice și gradul de satisfacție a clienților. Fiecare rotație a spiralei corespunde creării unui fragment sau a unei versiuni funcționale a sistemului. Acest lucru vă permite să clarificați cerințele, obiectivele și caracteristicile proiectului, să determinați calitatea dezvoltării, să planificați activitatea următoarei runde a spiralei. Astfel, detaliile proiectului sunt aprofundate și specificate în mod consecvent și, ca urmare, este selectată o opțiune rezonabilă care să îndeplinească cerințele reale ale clientului și care este adusă la implementare.

Ciclul de viață la fiecare cotitură a spiralei - pot fi aplicate diferite modele ale procesului de dezvoltare software. În cele din urmă, produsul final este un produs finit. Modelul combină capacitățile modelului de prototipare șimodel de cascadă... Dezvoltarea prin iterații reflectă ciclul spiral existent în mod obiectiv al creării sistemului. Finalizarea incompletă a lucrărilor la fiecare etapă vă permite să treceți la următoarea etapă fără a aștepta finalizarea completă a lucrărilor la cea curentă. Sarcina principală este de a arăta utilizatorilor sistemului un produs care funcționează cât mai curând posibil, activând astfel procesul de specificare și completare a cerințelor.

Avantajele modelului:

vă permite să arătați rapid utilizatorilor sistemului un produs funcțional, activând astfel procesul de clarificare și completare a cerințelor;
permite schimbarea cerințelor pentru dezvoltarea software, ceea ce este tipic pentru majoritatea dezvoltărilor, inclusiv cele standard;
modelul oferă posibilitatea de proiectare flexibilă, deoarece întruchipează avantajele modelului cascadă și, în același timp, iterațiile sunt permise prin toate fazele aceluiași model;
vă permite să obțineți un sistem mai fiabil și mai stabil. Pe măsură ce software-ul evoluează, erorile și punctele slabe sunt descoperite și remediate la fiecare iterație;
acest model permite utilizatorilor să participe activ la activități de planificare, analiză de risc, dezvoltare și evaluare;
riscurile clientului sunt reduse. Clientul poate finaliza dezvoltarea unui proiect nepromițător cu pierderi financiare minime pentru el însuși;
Feedback-ul de la utilizatori către dezvoltatori se face cu frecvență ridicată și la începutul modelului pentru a se asigura că este creat produsul de înaltă calitate dorit.

Dezavantaje ale modelului:

dacă proiectul are un risc scăzut sau mic, modelul poate fi costisitor. Evaluarea riscului după fiecare spirală este costisitoare;
Ciclul de viață al unui model are o structură complicată, așa că poate fi dificil pentru dezvoltatori, manageri și clienți să-l folosească;
spirala poate continua pe termen nelimitat, deoarece fiecare răspuns al clientului la versiunea creată poate genera un nou ciclu, care întârzie finalizarea proiectului;
un număr mare de cicluri intermediare poate duce la necesitatea procesării suplimentare a documentației;
utilizarea modelului poate fi costisitoare și chiar prohibitiv de accesibilă. timp. planificarea cheltuită, redefinirea obiectivelor, efectuarea analizei de risc și crearea de prototipuri pot fi excesive;
poate fi dificil să se definească obiective şi repere care indică dorinţa de a continua procesul de dezvoltare în următorul şi

Principala problemă a ciclului spirală este determinarea când să trecem la următoarea etapă. Pentru a o rezolva, se introduc limite de timp pentru fiecare dintre etape.ciclu de viață iar tranziția se desfășoară conform planului, chiar dacă nu toate lucrările planificate au fost finalizate.Planificareproduse pe baza datelor statistice obţinute în proiectele anterioare şi experienta personala dezvoltatori.

Aplicații pentru modelul spiralat

Utilizarea modelului în spirală este recomandată în următoarele cazuri:

la dezvoltarea proiectelor folosind noile tehnologii;
la dezvoltare noua serie produse sau sisteme;
atunci când se dezvoltă proiecte cu modificări semnificative așteptate sau completări la cerințe;
să realizeze proiecte pe termen lung;
atunci când se dezvoltă proiecte care necesită demonstrarea calității și a versiunilor unui sistem sau produs pe o perioadă scurtă de timp;
la dezvoltarea proiectelor. pentru care este necesar să se calculeze costurile asociate cu evaluarea și rezolvarea riscurilor.

Adnotare.

Introducere.

1. Ciclul de viață al software-ului

Introducere.

Etapele procesului de programare Riley

Introducere.

1.1.1. Formularea problemei.

1.1.2. Proiectarea soluției.

1.1.3. Codarea algoritmului.

1.1.4. Mentinerea programului.

1.1.5. Documentația software.

Concluzie la clauza 1.1

1.2. Definiția ZHCPO conform Lehman.

Introducere.

1.2.1 Definirea sistemului.

1.2.2. Implementarea.

1.2.3. Serviciu.

Concluzie la clauza 1.2.

1.3. Fazele și lucrul ZHCPO conform lui Boehm

1.3.1. Model cascadă.

1.3.2. Justificare economică model în cascadă.

1.3.3. Îmbunătățirea modelului cascadei.

1.3.4. Determinarea fazelor ciclului de viață.

1.3.5. Lucrări de bază pe proiect.

Literatură.

Introducere

Aplicație industrială calculatoarele și cererea în creștere de software au stabilit sarcini urgente să crească semnificativ productivitatea dezvoltării software, dezvoltarea metodelor industriale de planificare și proiectare a programelor, transferul de tehnici, modele și metode organizatorice și tehnice, tehnice, economice și socio-psihologice din sferă producerea materialuluiîn domeniul computerelor. O abordare complexă proceselor de dezvoltare, operare și întreținere a software-ului a înaintat o serie de probleme presante, a căror soluție va elimina „gâturile de sticlă” în proiectarea programelor, va reduce timpul de finalizare a lucrărilor, va îmbunătăți selecția și adaptarea existente. programe și poate determina soarta sistemelor cu computere încorporate.

În practica dezvoltării de proiecte software mari, adesea nu există abordare uniformă la evaluarea costurilor cu forța de muncă, a calendarului de lucru și costuri materiale, care împiedică creșterea productivității dezvoltării de software și, în cele din urmă - management eficient ciclul de viață al software-ului. Deoarece un program de orice tip devine un produs (cu excepția, poate, a programelor educaționale, model), abordarea producției sale ar trebui să fie în multe privințe similară cu abordarea producției de produse industriale, iar problemele de proiectare a programelor devin extrem de importante. . Această idee se află în centrul B.W. „Ingineria software” a lui Boehm, pe care am folosit-o pentru a scrie asta termen de hârtie... În această carte, proiectarea software se referă la procesul de creare a unui proiect de produs software.

1 Ciclul de viață al software-ului

INTRODUCERE

ZHCPO este proces continuu, care începe din momentul luării unei decizii privind necesitatea creării de software și se termină în momentul retragerii sale complete din serviciu.

Există mai multe abordări pentru definirea fazelor și activităților ciclului de viață al software-ului (LCPO), etapelor procesului de programare, modelelor în cascadă și spirală. Dar toate conțin componente fundamentale comune: enunțarea problemei, proiectarea soluției, implementarea, întreținerea.

Cel mai cunoscut și complet, poate, este structura centrului ciclului de viață conform lui Boehm, care include opt faze. Ea va fi prezentată în viitor mai detaliat.

Una dintre opțiunile posibile este descrierea nivelului superior conform lui Lehman, care include trei faze principale și prezintă o descriere a programului ciclului de viață în chiar caz general.

Și, spre schimbare, - vă prezentăm etapele procesului de programare prezentate de D. Riley în cartea „Using the Module-2 language”. Această idee, după părerea mea, este foarte simplă și familiară și vom începe cu ea.

1.1 Etapele procesului de programare Riley

Procesul de programare include patru pași (Fig. 1):

declarația problemei, adică obținerea unei idei adecvate despre ce sarcină ar trebui să îndeplinească programul;

proiectarea unei soluții la o problemă deja pusă (în general, o astfel de soluție este mai puțin formală decât programul final);

codificarea programului, adică traducerea soluției proiectate într-un program care poate fi executat pe mașină;

menținerea programului, adică un proces continuu de depanare a problemelor din program și de adăugare de noi caracteristici.

Orez. 1.Patru pași de programare.

Programarea începe din momentul în care utilizator, adică cineva care are nevoie de un program pentru a rezolva o problemă prezintă problema analist de sistem. Utilizatorul și analistul de sisteme definesc împreună declarația problemei. Acesta din urmă este apoi transmis algoritmist care este responsabil pentru proiectarea soluției. O soluție (sau algoritm) reprezintă o secvență de operații, a căror execuție duce la rezolvarea unei probleme. Deoarece algoritmul nu este adesea citit de mașină, ar trebui tradus într-un program de mașină. Această operație este efectuată de codificator. Menținătorul este responsabil pentru modificările ulterioare ale programului. Un analist de sisteme, un algoritmist, un codificator și un programator însoțitor sunt toți programatori.

În cazul unui proiect software mare, numărul de utilizatori, analiști de sistem și algoritmi poate fi semnificativ. În plus, poate fi necesară revenirea la pașii anteriori din cauza unor circumstanțe neprevăzute. Toate acestea se adaugă la argumentul pentru proiectarea atentă a software-ului: rezultatele fiecărui pas trebuie să fie complete, precise și ușor de înțeles.

1.1.1 Declarația problemei

Unul dintre cei mai importanți pași în programare este definirea problemei. Acesta servește ca un contract între utilizator și programator(i). La fel ca un contract scris prost din punct de vedere legal, declarația proastă a problemei este inutilă. Cu o bună formulare a problemei, atât utilizatorul, cât și programatorul reprezintă clar și fără ambiguitate sarcina care trebuie îndeplinită, adică. în acest caz, sunt luate în considerare atât interesele utilizatorului, cât și ale programatorului. Utilizatorul poate planifica să utilizeze software care nu a fost încă creat, pe baza cunoștințelor pe care le poate. O bună formulare a problemei servește ca bază pentru formarea soluției acesteia.

Formularea problemei (specificarea programului); în esență înseamnă o descriere precisă, completă și de înțeles a ceea ce se întâmplă atunci când un anumit program este executat. Utilizatorul se uită de obicei la computer ca și cum ar fi o cutie neagră: pentru el nu contează cum funcționează computerul, dar ceea ce contează este ce poate face computerul care îl interesează pe utilizator. În acest caz, accentul principal este pe interacțiunea unei persoane cu o mașină.

Caracteristicile unei declarații bune de sarcină:

Precizie, adică eliminarea oricărei ambiguități. Nu ar trebui să existe nicio întrebare cu privire la ceea ce va fi rezultatul programului pentru orice intrare dată.

Completitudine, adică luarea în considerare a tuturor opțiunilor pentru o intrare dată, inclusiv intrarea eronată sau neintenționată și determinarea ieșirii corespunzătoare.

Claritate, adică ar trebui să fie clar atât pentru utilizator, cât și pentru analistul de sisteme, deoarece enunțul problemei este singurul contract între ei.

Adesea, cerințele de acuratețe, completitudine și claritate sunt în conflict. Asa de mult acte juridice greu de înțeles pentru că sunt scrise în limbaj formal, care vă permite să formulați foarte precis anumite prevederi, excluzând orice discrepanțe cele mai nesemnificative. De exemplu, câteva întrebări în bilete de examen sunt uneori formulate atât de precis, încât elevul petrece mai mult timp înțelegând întrebarea decât răspunzând la ea. Mai mult, studentul poate să nu înțeleagă deloc sensul principal al întrebării din cauza numărului mare de detalii. Cea mai bună formulare a problemei este cea care realizează un echilibru între toate cele trei cerințe.

Forma standard a enunțului problemei.

Luați în considerare următoarea afirmație a problemei: „Introduceți trei numere și scoateți numerele în ordine”.

Această formulare nu satisface cerințele de mai sus: nu este nici exactă, nici completă, nici de înțeles. Într-adevăr, numerele trebuie introduse câte unul pe linie sau toate numerele pe o singură linie? Expresia „în ordine” înseamnă ordonarea de la cel mai mare la cel mai mic, de la cel mai mic la cel mai mare sau aceeași ordine în care au fost introduse.

Evident, o astfel de formulare nu răspunde la multe întrebări. Dacă luăm în considerare răspunsurile la toate întrebările, atunci enunțul problemei va deveni pronunțat și greu de înțeles. Prin urmare, D. Riley sugerează utilizarea unui formular standard pentru stabilirea problemei, care oferă maximă acuratețe, completitudine, claritate și include:

numele sarcinii (definiție schematică);

descrierea generala (scurta prezentare a problemei);

erori (opțiunile de intrare neobișnuite sunt enumerate în mod explicit pentru a arăta utilizatorilor și programatorilor ce va lua mașina în astfel de situații);

exemplu ( bun exemplu poate transmite esența problemei și, de asemenea, ilustra diverse cazuri).

Exemplu. Enunțarea problemei în forma standard.

TITLU

Sortarea a trei numere întregi.

DESCRIERE

Introduceți și scoateți trei numere întregi, sortate de la cel mai mic la cel mai mare.

Se introduc trei numere întregi, câte un număr pe linie. În acest caz, un întreg este una sau mai multe cifre zecimale consecutive, care pot fi precedate de un semn plus „+” sau de un semn minus „-”.

Sunt afișate cele trei numere întregi introduse, toate trei fiind afișate pe aceeași linie. Separați numerele adiacente cu un spațiu. Numerele sunt afișate de la cel mai mic la cel mai mare, de la stânga la dreapta.

1) Dacă sunt introduse mai puțin de trei numere, programul așteaptă introducerea suplimentară.

Ciclul de viață al software-ului. Etape și etape

Ciclul de viață al unui IS este o serie de evenimente care au loc cu sistemul în procesul de creare și utilizare.

Etapă- o parte a procesului de dezvoltare software, limitată de un anumit interval de timp și care se încheie cu lansarea unui anumit produs (modele, componente software, documentație), determinată de cerințele stabilite pentru această etapă.

Ciclul de viață este modelat în mod tradițional ca un număr de etape succesive (sau etape, faze). În prezent, nu există o defalcare general acceptată a ciclului de viață sistem softwareîn etape. Uneori, o etapă este evidențiată ca element separat, uneori este inclusă ca parte integrantă a unei etape mai mari. Acțiunile întreprinse într-o etapă sau alta pot varia. Nu există o uniformitate în denumirile acestor etape.

În mod tradițional, se disting următoarele etape principale ale ciclului de viață al software-ului:

Analiza cerințelor,

Proiecta,

Codare (programare),

Testare și depanare,

Operare și întreținere.

Ciclul de viață al software-ului. Model în cascadă

modelul în cascadă (70-80 ani) ≈ presupune trecerea la următoarea etapă după finalizarea completă a lucrării la etapa anterioară,

Principala realizare a modelului cascadei este finalizarea etapelor. Acest lucru face posibilă planificarea costurilor și a termenelor. În plus, a documentatia proiectului cu completitudine și consecvență.

Modelul cascadă este aplicabil proiectelor software mici cu cerințe clar definite și neschimbabile. Procesul real poate dezvălui eșecuri în orice etapă, ceea ce duce la o revenire la una dintre etapele anterioare. Modelul unei astfel de producții de software este cascadă-retur

Ciclul de viață al software-ului. Model pas cu pas cu control intermediar

model pas cu pas cu control intermediar (80-85 ani) ≈ model iterativ dezvoltare software cu bucle de feedback între etape. Avantajul acestui model este că ajustările între etape necesită mai puțină muncă decât modelul în cascadă; cu toate acestea, durata de viață a fiecărei etape este prelungită pe întreaga perioadă de dezvoltare,

Principalele etape ale rezolvării problemelor

Scopul programării este de a descrie procesele de prelucrare a datelor (denumite în continuare procese simple).

Datele (date) reprezintă o reprezentare a faptelor și ideilor într-o formă formalizată, potrivită pentru transfer și prelucrare într-un anumit proces, iar informația (informația) este sensul care se acordă datelor atunci când sunt prezentate.

Prelucrarea datelor este executarea unei secvențe sistematice de acțiuni asupra datelor. Datele sunt prezentate și stocate pe suporturi de date.

Colecția de purtători de date utilizate în orice fel de prelucrare a datelor se numește suport de date.

Un set de date conținute în orice moment în mediul informațional - starea mediului informațional.

Un proces poate fi definit ca o secvență de stări succesive ale unui anumit mediu informațional.

A descrie un proces înseamnă a determina succesiunea stărilor mediului informațional. Pentru ca procesul solicitat să fie generat automat pe orice computer conform unei descrieri date, această descriere trebuie formalizată.

Criterii de calitate software

Un produs comercial (produs, serviciu) trebuie să îndeplinească cerințele clienților.

Calitatea este o caracteristică obiectivă a unui produs (produs, serviciu), care arată gradul de satisfacție a clientului

Caracteristici de calitate:

Operabilitate- sistemul functioneaza si implementeaza functiile cerute.

Fiabilitate- sistemul funcționează fără defecțiuni și defecțiuni.

Recuperare.

Eficienţă- sistemul își implementează funcțiile în cel mai bun mod posibil.

Eficiență economică – cost minim produs final cu profit maxim.

Caracteristici de calitate:

Ținând cont de factorul uman- ușurință în utilizare, viteza de învățare a lucrului cu PP, ușurință în întreținere, efectuarea modificărilor.

Portabilitate(portabilitate) - portabilitatea codului către o altă platformă sau sistem.

Completitudine funcțională- Posibil cea mai completă implementare a funcțiilor externe.

Precizia calculelor

Proprietățile algoritmului.

Eficacitatea înseamnă posibilitatea de a obţine un rezultat după efectuarea unui număr finit de operaţii.

Certitudine consta in coincidenta rezultatelor obtinute indiferent de utilizator si mijloacele tehnice aplicate.

Caracter de masă constă în posibilitatea aplicării algoritmului la o întreagă clasă de probleme de același tip, care diferă în anumite valori ale datelor inițiale.

Discretenie - posibilitatea de a împărți procesul de calcule prescrise de algoritm în etape separate, capacitatea de a selecta secțiuni ale programului cu o anumită structură.

Metode de descriere a algoritmilor

Există următoarele moduri de a descrie (reprezenta) algoritmii:

1. descriere verbală;

2. descrierea algoritmului folosind formule matematice;

3. o descriere grafică a algoritmului sub forma unei diagrame bloc;

4. descrierea algoritmului folosind pseudocod;

5.Metoda combinată de afișare a algoritmului folosind metode verbale, grafice și alte metode .

6. folosind reţele Petri.

Descriere verbală algoritmul este o descriere a structurii algoritmului în limbaj natural. De exemplu, la dispozitive aparate electrocasnice de regulă, este atașat un manual de instrucțiuni, adică. o descriere verbală a algoritmului conform căruia acest dispozitiv urmează să fie utilizat.

Descriere grafică algoritm sub forma unei organigrame Este o descriere a structurii algoritmului folosind forme geometrice cu linii de comunicare.

O diagramă de flux este o reprezentare grafică a unei metode de rezolvare a unei probleme care utilizează caractere speciale pentru a reprezenta operații.

Simbolurile care alcătuiesc diagrama de flux a algoritmului sunt determinate de GOST 19.701-90. Acest GOST corespunde standardului internațional pentru proiectarea algoritmilor, prin urmare, diagramele bloc ale algoritmilor, întocmite în conformitate cu GOST 19.701-90, în tari diferite sunt înțelese fără ambiguitate.

Pseudo cod- descrierea structurii algoritmului într-un limbaj natural, dar parțial formalizat. Pseudocodul folosește niște constructe formale și notații matematice comune. Nu există reguli de sintaxă stricte pentru scrierea pseudocodului.

Să aruncăm o privire la cel mai simplu exemplu. Să fie necesar să descriem algoritmul pentru afișarea celei mai mari valori a două numere pe ecranul monitorului.

Figura 1 - Un exemplu de descriere a algoritmului sub forma unei diagrame bloc

Descrierea aceluiași algoritm în pseudocod:

2. Introducerea numerelor: Z, X

3. Dacă Z> X atunci Concluzia Z

4. În caz contrar, ieșirea X

Fiecare dintre metodele enumerate de afișare a algoritmilor are atât avantaje, cât și dezavantaje. De exemplu, metoda verbală se remarcă prin verbozitatea și lipsa de claritate, dar face posibilă o mai bună descriere a operațiilor individuale. Metoda grafică este mai descriptivă, dar de multe ori este necesară descrierea unor operații în formă verbală. Prin urmare, atunci când dezvoltați algoritmi complecși, este mai bine să utilizați o metodă combinată.

Tipuri de algoritmi

liniar;

ramificare;

ciclic.

· Algoritm liniar- un set de comenzi (instructiuni) executate secvential una dupa alta.

· Algoritm de bifurcare- un algoritm care conține cel puțin o condiție, ca urmare a verificării căreia computerul asigură o tranziție la unul dintre cei doi pași posibili.

· Algoritm ciclic- un algoritm care prevede repetarea multiplă a aceleiași acțiuni (aceleași operații) peste date inițiale noi. Majoritatea metodelor de calcul, enumerarea opțiunilor sunt reduse la algoritmi ciclici. Bucla de program - o secvență de comenzi (serie, corp buclă), care poate fi executată de mai multe ori (pentru date inițiale noi) până când este îndeplinită o anumită condiție.

C. Tipuri de date.

Un tip de date este o descriere a intervalului de valori pe care le poate lua o variabilă de tipul specificat. Fiecare tip de date este caracterizat prin:
1.numărul de octeți ocupați (dimensiune)
2. intervalul de valori pe care le poate lua o variabilă de acest tip.

Toate tipurile de date pot fi împărțite în următoarele tipuri:
1.tipuri simple (scalare) și complexe (vectorale);
2. bază (sistem) și utilizator (definit de utilizator).
În limbajul C, sistemul de tip de bază este format din patru tipuri de date:
1.personaj,
2.întreg,
3. precizie unică reală,
4. dublă precizie reală.

Structura unui program C.

1. Operatorii limbajului C++

Operatorii controlează procesul de execuție a programului. Setul de operatori C++ conține toate constructele de control ale programării structurate.
Declarația compusă este delimitată de acolade. Toți ceilalți operatori se termină cu punct și virgulă.
Operator gol -;
Un operator gol este un operator numai punct și virgulă. Poate apărea oriunde într-un program unde sintaxa necesită o instrucțiune. Executarea unei instrucțiuni goale nu schimbă starea programului.
Operator compus - (...)
Acțiunea unei instrucțiuni compuse constă în execuția secvențială a instrucțiunilor conținute în ea, cu excepția cazurilor în care orice instrucțiune transferă în mod explicit controlul în alt loc din program.
Operator de manipulare a excepțiilor

încerca (<операторы> }
captură (<объявление исключения>) { <операторы> }
captură (<объявление исключения>) { <операторы> }
...
captură (<объявление исключения>) { <операторы> }

Operator condiționat

dacă (<выражение>) <оператор 1>

Comutator de operator

intrerupator (<выражение>)
(caz<константное выражение 1>: <операторы 1>
caz<константное выражение 2>: <операторы 2>
...
caz<константное выражение N>: <операторы N>
}
Operatorul de comutare este destinat să selecteze una dintre mai multe căi alternative de execuție a programului. Evaluarea operatorului comutator începe cu evaluarea expresiei, după care controlul este transferat operatorului marcat cu o expresie constantă egală cu valoarea evaluată a expresiei. Ieșirea din operatorul de comutator este efectuată de operatorul de întrerupere. Dacă valoarea expresiei nu este egală cu nicio expresie constantă, atunci controlul este transferat operatorului marcat cu cuvântul cheie implicit, dacă există.
Operator de buclă cu precondiție

in timp ce (<выражение>) <оператор>

Operator de buclă cu postcondiție

do<оператор>in timp ce<выражение>;
În limbajul C++, acest operator diferă de implementarea clasică a unei bucle cu o postcondiție prin aceea că, dacă expresia este adevărată, bucla continuă, iar bucla nu iese.
Operator de ciclu pas

pentru ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Corpul instrucțiunii for este executat până când expresia condiționată devine falsă (egal cu 0). O expresie inițială și o expresie incrementală sunt utilizate în mod obișnuit pentru a inițializa și modifica parametrii buclei și alte valori. Expresia inițială este evaluată o dată înainte de primul test al expresiei condiționate, iar expresia incrementală este evaluată după fiecare execuție a instrucțiunii. Oricare dintre cele trei expresii de antet de buclă, și chiar toate trei, pot fi omise (nu uitați să lăsați punct și virgulă). Dacă expresia condiționată este omisă, atunci este considerată adevărată, iar bucla devine infinită.
Operatorul de buclă în pas în limbajul C++ este o construcție flexibilă și convenabilă, prin urmare operatorul de buclă cu precondiția while este folosit extrem de rar în limbajul C++, deoarece în cele mai multe cazuri este mai convenabil să folosiți instrucțiunea for.
Operator de pauză

pauză;
Instrucțiunea break întrerupe execuția instrucțiunilor while, do, for și switch. Acesta poate fi inclus doar în corpul acestor declarații. Controlul este transferat operatorului de program în urma celui întrerupt. Dacă o instrucțiune break este scrisă în instrucțiuni imbricate while, do, for, switch, atunci se încheie numai instrucțiunea care o include imediat.
Operator de continuare

continua;
Instrucțiunea de continuare transferă controlul către următoarea iterație în instrucțiunile while, do, for loop. Acesta poate fi inclus doar în corpul acestor declarații. În instrucțiunile do și while, următoarea iterație începe prin evaluarea unei expresii condiționate. În instrucțiunea for, următoarea iterație începe prin evaluarea expresiei de increment și apoi evaluarea expresiei condiționate.
Operator de retur

întoarcere [<выражение>];
Declarația return încheie execuția funcției în care este conținută și returnează controlul funcției apelante. Controlul este transmis la punctul funcției de apelare

Dacă (expresie booleană)

operator;

Dacă (expresie booleană)

operator_1;

operator_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

Dacă valoarea expresiei logice este adevărată, atunci expresia_1 este evaluată, în caz contrar expresia_2 este evaluată.

comutare (expresie întreagă)

valoarea cazului_1:

secvență_de_instrucțiuni_1;

valoarea cazului_2:

secvență_de_instrucțiuni_2;

case value_n:

statement_sequence_n;

Mod implicit:

instrucțiuni_secvență_n + 1;

Ramura Mod implicit nu poate fi descris. Se execută dacă niciuna dintre expresiile de nivel superior nu este satisfăcută.

Operator de buclă.

Turbo C are următoarele constructe care vă permit să programați bucle: în timp ce, fă în timp ce și pentru ... Structura lor poate fi descrisă după cum urmează:

Bucla cu verificarea stării în partea de sus:

Operator de selecție

Dacă acțiunile care trebuie efectuate în program depind de valoarea unei variabile, puteți utiliza instrucțiunea select. În același timp, în C++, doar variabilele numerice pot fi folosite ca variabile în instrucțiunea select. V vedere generala declarația de selecție arată astfel:

comutator (variabil)
{
valoare caz 1:
acțiuni 1
pauză;

valoarea cazului 2:
acțiunea 2
pauză;
...

Mod implicit:
acțiuni implicite
}

Cuvântul cheie break trebuie adăugat la sfârșitul fiecărei ramuri. Opreste executarea operatiei de selectie. Dacă nu îl scrieți, după efectuarea acțiunilor dintr-o ramură a selecției, execuția acțiunilor din următoarele ramuri va continua. Cu toate acestea, uneori această proprietate de alegere este utilă, de exemplu, dacă trebuie să efectuați aceleași acțiuni pentru valori diferite ale unei variabile.

comutator (variabil)
{
valoare caz 1:
valoarea cazului 2:
acțiuni 1
pauză;

valoarea cazului 3:
acțiunea 2
pauză;
...
}

Exemplu de utilizare a selecției:

int n, x;
...
comutator (n)
{
cazul 0:
pauză; // dacă n este 0, atunci nu efectuăm nicio acțiune

cazul 1:
cazul 2:
cazul 3:
x = 3 * n; // dacă n este 1, 2 sau 3, atunci efectuăm unele acțiuni
pauză;

cazul 4:
x = n; // dacă n este 4, atunci efectuăm alte acțiuni
pauză;

Mod implicit:
x = 0; // pentru toate celelalte valori ale lui n, efectuați acțiunile implicite
}

C. Loop: o buclă cu un parametru

Forma generală de intrare

pentru (inițializarea parametrilor; verificarea stării de terminare; corectarea parametrilor) (

bloc de operațiuni;

for este o buclă parametrică (bucla cu un număr fix de repetări). Pentru a organiza un astfel de ciclu, este necesar să se efectueze trei operațiuni:

§ inițializarea parametrilor- atribuirea valorii inițiale parametrului de ciclu;

§ verificarea stării finale- compararea valorii parametrului cu o anumită valoare limită;

§ corectarea parametrilor- modificarea valorii parametrului cu fiecare trecere a corpului buclei.

Aceste trei operații sunt scrise între paranteze și separate prin punct și virgulă (;). De obicei, parametrul buclei este o variabilă întreagă.
Parametrul este inițializat o singură dată — când începe să se execute bucla for. Condiția de terminare este verificată înainte de fiecare execuție posibilă a corpului buclei. Când expresia devine falsă (egale cu zero), bucla se termină. Corectarea parametrilor se efectuează la sfârșitul fiecărei execuții a corpului buclei. Parametrul poate crește sau descrește.

Exemplu

#include
int main () (

pentru (num = 1; nr< 5; num++)

printf ("num =% d \ n", num);

Si. Buclă cu precondiție

Forma generală de intrare

în timp ce (expresie) (

bloc de operațiuni;
}

Dacă expresia este adevărată (diferită de zero), atunci blocul de operații cuprins între acolade este executat, atunci expresia este verificată din nou. Secvența de acțiuni, constând în verificarea și executarea unui bloc de operații, se repetă până când expresia devine falsă (egal cu zero). În acest caz, bucla este ieșită și operația după operatorul buclă este executată.

Exemplu

int k = 5;
int i = 1;
int suma = 0;
in timp ce eu<=k) {

Când se construiește o buclă while, este necesar să se includă constructe care modifică valoarea expresiei testate, astfel încât în final să devină falsă (egal cu zero). În caz contrar, bucla va fi executată la nesfârșit (buclă infinită), de exemplu

bloc de operațiuni;
}

while este o buclă cu o precondiție, deci este foarte posibil ca corpul buclei să nu fie executat nici măcar o dată dacă condiția care este verificată se dovedește a fi falsă la momentul primei verificări.

Si. Bucla cu postcondiție

Bucla cu postcondiție do ... while

Forma generală de intrare

bloc de operațiuni;

) în timp ce (expresie);

Bucla cu postcondiție

Bucla do ... while este o buclă cu o postcondiție, în care adevărul expresiei este verificat după ce au fost executate toate operațiunile incluse în blocul cuprins între acolade.Corpul buclei este executat până când expresia devine falsă , adică corpul buclei cu postcondiția este executat deși o singură dată.

Este mai bine să utilizați o buclă do ... while în cazurile în care trebuie efectuată cel puțin o iterație sau când inițializarea obiectelor care participă la testarea unei condiții are loc în corpul buclei.

Exemplu... Introduceți un număr de la 0 la 10

#include
#include
int main () (

sistem ("chcp 1251");

printf ("Introduceți un număr între 0 și 10:");

scanf ("% d", & num);

) în timp ce ((num< 0) || (num > 10));

printf ("Ați introdus numărul% d", num);

getchar (); getchar ();

Definirea funcțiilor

Să luăm în considerare definiția funcției folosind exemplul funcției sum.

În C și C++, funcțiile nu trebuie definite până când nu sunt utilizate, dar trebuie declarate anterior. Dar și după toate acestea, până la urmă, această funcție trebuie definită. După aceea, prototipul funcției și definiția sa sunt legate și funcția poate fi utilizată.

Dacă funcția a fost declarată anterior, trebuie definită cu aceeași valoare de returnare și tipuri de date, altfel va fi creată o funcție nouă, supraîncărcată. Rețineți că numele parametrilor funcției nu trebuie să fie identice.

Ar putea fi util să citiți: