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

Ciclul de viață al software-ului (software) este o perioadă de timp care începe din momentul în care se ia o decizie cu privire la necesitatea de a crea un produs software și se încheie în momentul retragerii sale complete din serviciu. Acest ciclu este procesul de construire și dezvoltare de software.

Etape ciclu de viață :

2. Proiectare

3. Implementare

4. Asamblare, testare, testare

5. Implementare (lansare)

6. Escorta

Există 2 cazuri de producție de software: 1) Software-ul este creat pentru un anumit client. În acest caz, aveți nevoie sarcină aplicată transformă-te într-un programator. Trebuie să înțelegeți cum funcționează mediul care trebuie automatizat (analiza proceselor de afaceri). Ca rezultat, apare o documentație-specificație a cerinței, unde exact ce sarcini ar trebui indicate. rezolvate și în ce condiții. Această lucrare este realizată de un analist de sistem (analist de proces 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 a cerințelor.

Proiecta

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

Implementare

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

Asamblare, testare, testare

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

Implementare (lansare)

Implementare - atunci când lucrează pentru un singur client. Acesta include configurarea programului la locul clientului, instruirea acestuia, consultanță, eliminarea erorilor și a deficiențelor evidente. Software-ul ar trebui înstrăinat - utilizatorul poate lucra cu software-ul fără participarea autorului.

Lansare - când software-ul este dezvoltat pe piață. Începe cu faza de testare beta. Corespunzător versiune - versiune beta. Testarea alfa este testarea de către oameni din aceeași organizație care nu au fost implicați în dezvoltarea de software. Testarea beta - realizarea mai multor copii ale software-ului și trimiterea acestuia către potențiali clienți. Scopul este de a verifica de două ori dezvoltarea de software.

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 în timpul funcționării. Efectuarea unor îmbunătățiri minore. Acumularea de propuneri pentru dezvoltarea următoarei versiuni.

Modele de ciclu de viață

1. Cascadă („cascadă”, model cascadă)

2. Prototipare

În primul rând, nu este dezvoltat produsul software în sine, 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, prezentul produs software este dezvoltat conform acelorași principii. Prototipul vă permite să înțelegeți mai bine cerințele pentru programul dezvoltat. Folosind prototipul, clientul își poate formula cerințele mai precis. Dezvoltatorul are ocazia să prezinte clientului rezultatele preliminare ale muncii sale folosind un prototip.

3. Model iterativ

Sarcina este împărțită în subtaskuri și se determină ordinea implementării acestora, astfel încât fiecare subtask ulterior extinde capacitățile software-ului. Succesul depinde în esență de cât de bine sunt împărțite sarcinile în subtaskuri și de modul în care este aleasă ordinea. Avantaje: 1) posibilitatea participării active a clientului la dezvoltare, acesta are posibilitatea de a-și clarifica cerințele în timpul 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 de a crea un produs software și se încheie în momentul retragerii sale complete din serviciu. (IEEE Std 610.12 standard)

Necesitatea de a determina etapele ciclului de viață al software-ului (LC) se datorează dorinței dezvoltatorilor de a îmbunătăți calitatea software-ului printr-un management optim al dezvoltării și utilizarea unei varietăți de mecanisme de control al calității în fiecare etapă, de la setarea problemă la sprijinul 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-ului în ansamblu;

Testare, operare de probă și replicare software;

Operarea regulată a software-ului, suport pentru întreținere și analiza rezultatelor;

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

Acest model este în general acceptat și respectă atât documentele de reglementare interne din domeniul dezvoltării de software, cât și cele din străinătate. Din punctul de vedere al asigurării siguranței 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 ale unui sabotaj tip.

Standarde privind ciclul de viață al software-ului

GOST 34.601-90

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

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

Inițial, a fost creat un model de ciclu de viață în cascadă, în care etapele majore au început una după alta folosind rezultatele muncii anterioare. Acesta prevede executarea 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 de formare a cerințelor sunt strict documentate sub formă de specificații tehnice și sunt fixate pe toată durata dezvoltării proiectului Fiecare etapă se încheie cu lansarea unui set complet de documentație suficient pentru ca dezvoltarea să fie continuată de către o altă echipă de dezvoltare. Inexactitatea oricărei cerințe sau interpretarea incorectă a acesteia, ca rezultat, duce la faptul că este necesar să „reveniți” la faza incipientă a proiectului și revizuirea necesară nu numai că elimină echipa proiectului din program, dar de multe ori 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ă proiectarea trece prin întregul proces o dată, arhitectura proiectată este bună și ușor de utilizat, proiectarea implementării este rezonabilă, iar erorile de implementare sunt ușor eliminate pe măsură ce testele progresează. Acest model presupune că toate erorile vor fi concentrate în implementare și, prin urmare, vor fi 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 utilizat în mod eficient numai pentru crearea de sisteme mici.

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

Riscul depășirii termenilor și costului proiectului;

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

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

Fezabilitatea încheierii proiectului.

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

Pentru proiectarea software a unui sistem complex, în special a unui sistem în timp real, se recomandă utilizarea unui model de ciclu de viață la nivelul întregului sistem, bazat pe combinația tuturor lucrărilor cunoscute în cadrul proceselor de bază considerate. Acest model este destinat utilizării în planificarea, programarea, gestionarea diferitelor proiecte software.

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

În prima parte a ciclului de viață, se efectuează analiza, proiectarea, dezvoltarea, testarea și testarea software-ului sistemului. Gama de lucrări, intensitatea muncii, durata și alte caracteristici ale acestora î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 caracteristicilor principale ale programelor de lucru pentru noile versiuni de software.

A doua parte a ciclului de viață, care reflectă suportul pentru funcționarea și întreținerea software-ului, este relativ slab legată de caracteristicile obiectului și de mediul de dezvoltare. Nomenclatura muncii în aceste etape este mai stabilă, iar intensitatea și durata muncii lor pot varia semnificativ și pot depinde 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 sistem reglementat proces tehnologic la fiecare dintre aceste etape. Un astfel de proces este susținut de instrumente de automatizare a dezvoltării, care sunt recomandabile pentru a alege dintre cele disponibile sau pentru a crea, luând în considerare obiectul de dezvoltare și o listă adecvată de lucrări.

Ar trebui să înceapă prin a definiCiclul de viață al software-ului (Modelul ciclului de viață al software-ului) este o perioadă de timp care începe din momentul în care se ia o decizie de a crea un produs software și se termină în momentul retragerii sale complete. Acest ciclu este procesul de construire și dezvoltare de software.

Modele de ciclu de viață software

Ciclul de viață poate fi gândit ca modele. În prezent, cele mai frecvente sunt:în cascadă, incremental (model în scenă cu control intermediar ) și spirală modele de ciclu de viață.

Model în cascadă

Model în cascadă (eng. 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 analizei și proiectării cerințelor. implementare, testare, integrare și asistență.

Procesul de dezvoltare este implementat folosind o secvență ordonată de pași independenți. Modelul presupune că fiecare pas ulterior începe după finalizarea completă a pasului anterior. La toate etapele modelului, se efectuează procese și lucrări auxiliare și organizaționale, inclusiv managementul proiectului, evaluarea și managementul calității, verificarea și validarea, managementul configurației și dezvoltarea documentației. Ca urmare a finalizării 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ătorul principaletape:

Analiza cerințelor,
Proiecta,
Codificare (programare),
Testare și depanare,
Funcționare și întreținere.

Avantajele modelului:

stabilitatea cerințelor pe parcursul întregului ciclu de viață al dezvoltării;
în fiecare etapă, se formează un set complet de documentație a proiectului care îndeplinește criteriile de completitudine și coerență;
certitudinea și claritatea etapelor modelului și ușurința aplicării acestuia;
etapele de lucru efectuate într-o succesiune logică permit planificarea datei de finalizare a tuturor lucrărilor și a resurselor corespunzătoare (monetare, materiale și umane).

Dezavantaje ale modelului:

complexitatea unei formulări clare a cerințelor și imposibilitatea schimbării lor dinamice pe parcursul întregului ciclu de viață;
flexibilitate redusă în managementul proiectelor;
secvenţă structură liniară procesul de dezvoltare, ca urmare, revenirea la pașii anteriori pentru rezolvarea problemelor emergente duce la creșterea costurilor și perturbarea programului de lucru;
inadecvarea utilizării produsului intermediar;
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 utilizatorului la crearea sistemului - chiar la început (când se dezvoltă cerințe) ș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. Nu au ocazia să evalueze calitatea, deoarece nu puteți vedea produsul finit al dezvoltării;
nu există nicio modalitate prin care 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 să implementați modelul ciclului de viață al cascadei datorită complexității dezvoltării software-ului fără a reveni la pașii anteriori și a modifica rezultatele acestora pentru a elimina problemele apărute.

Domeniul de aplicare al modelului de cascadă

Limitarea sferei de aplicare a modelului cascadei este determinată de dezavantajele sale. Utilizarea sa este cea mai eficientă în următoarele cazuri:

atunci când dezvoltă proiecte cu clar, neschimbatciclu de viață cerințe, implementare ușoară și metodologie tehnică;
atunci când dezvoltați un proiect axat pe construirea unui sistem sau produs de același tip ca cel dezvoltat anterior de dezvoltatori;
atunci când se dezvoltă un 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ă;
atunci când faci proiecte mari care implică mai multe echipe mari de dezvoltare.

Model incremental

(model în trepte cu control intermediar)

Model incremental (eng. creştere - creștere, creștere) implică dezvoltarea de software cu o succesiune liniară de etape, dar în mai multe trepte (versiuni), adică odată cu îmbunătățirea planificată a produsului pentru tot timpul până la sfârșitul ciclului de viață al dezvoltării software-ului.

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 existente a rezultatelor dezvoltării în diferite etape; durata de viață a fiecărei etape este prelungită pentru întreaga perioadă de dezvoltare.

La începutul lucrărilor la un proiect, sunt determinate toate cerințele de bază pentru sistem, împărțite în tot mai puțin importante. După aceea, sistemul este dezvoltat în conformitate cu principiul creșterilor, astfel încât dezvoltatorul să poată utiliza datele obținute în timpul dezvoltării software-ului. Fiecare increment ar trebui să adauge unele funcționalități sistemului. Versiunea începe cu componentele cu cea mai mare prioritate. Când părțile sistemului sunt definite, acestea iau prima parte și încep să o detalieze folosind cel mai adecvat proces. Î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. Dacă o piesă este gata, aceasta este livrată clientului care o poate folosi în muncă. 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 simpla implementare a unui subset de cerințe ale programului și rafinarea modelului într-o serie de versiuni succesive până când software-ul este complet implementat.

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 versiunilor se realizează din diverse motive:

clientul nu poate finanța imediat întregul proiect scump;
dezvoltatorul nu are resursele necesare pentru a implementa un proiect complex într-un timp scurt;
cerințele pentru implementarea pe etape și dezvoltarea produsului de către utilizatorii finali. Introducerea întregului sistem simultan poate provoca respingerea utilizatorilor săi și doar „încetini” procesul de tranziție la noile tehnologii. Figurativ vorbind, ei pot pur și simplu „să nu digere o bucată mare, deci trebuie să fie zdrobită și dată în părți”.

Avantaje și limitări acest model (strategie) este același cu cel al cascadei (model 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, o poate abandona sau poate oferi dezvoltarea unui produs mai perfect odată cu încheierea unui nou contract.

Avantaje:

costurile suportate din cauza schimbării cerințelor utilizatorilor sunt reduse, reanaliza și setul de documentație sunt reduse semnificativ în comparație cu modelul cascadei;
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 ce s-a făcut deja. 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 de 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 minimă a versiunii;
structura sistemului tinde să se deterioreze atunci când se adaugă noi componente - modificările constante perturbă structura sistemului. Pentru a evita acest lucru, este nevoie de timp și bani suplimentari pentru refactorizare. Structura slabă face ca software-ul să fie dificil și costisitor de schimbat. Un ciclu de viață software întrerupt duce la pierderi și mai mari.

Schema nu permite să ia în considerare cu promptitudine modificările 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 la software sunt fixate sub formă de specificații tehnice pentru tot timpul creării sale. Astfel, utilizatorii primesc adesea un PP care nu le satisface nevoile reale.

Model în spirală

Model în spirală: Ciclul de viață - la fiecare întoarcere a spiralei, se creează următoarea versiune a produsului, sunt specificate cerințele proiectului, se determină calitatea acestuia și se planifică munca următoarei întoarceri. Atentie speciala este dat etapelor inițiale de dezvoltare - analiză și proiectare, unde fezabilitatea anumitor soluții tehnice verificat și validat prin prototipare.

Acest model este un proces de dezvoltare software care combină atât proiectarea cât și prototiparea etapă cu etapă pentru a combina avantajele unui concept de jos în sus și de sus în jos, concentrându-se pe etapele inițiale ale ciclului de viață: analiză și proiectare.Trăsătură distinctivă acest model acordă o atenție specială riscurilor care afectează organizarea ciclului de viață.

În etapele de analiză și proiectare, fezabilitatea soluțiilor tehnice și gradul de satisfacție a clienților sunt verificate prin prototipare. Fiecare întoarcere a spiralei corespunde creării unui fragment sau a unei versiuni a sistemului. Acest lucru vă permite să clarificați cerințele, obiectivele și caracteristicile proiectului, să determinați calitatea dezvoltării și să planificați lucrările următoarei runde a spiralei. Astfel, detaliile proiectului sunt aprofundate și specificate în mod constant și, ca rezultat, este selectată o opțiune rezonabilă care îndeplinește cerințele reale ale clientului și este adusă la implementare.

Ciclul de viață la fiecare întoarcere 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 spiralat existent obiectiv al creării sistemului. Finalizarea incompletă a lucrărilor la fiecare etapă vă permite să treceți la etapa următoare fără a aștepta finalizarea completă a lucrărilor la cea curentă. Sarcina principală este de a arăta utilizatorilor de sistem un produs funcțional 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 specificare și completare a cerințelor;
permite schimbarea cerințelor pentru dezvoltarea de software, ceea ce este tipic pentru majoritatea dezvoltărilor, inclusiv pentru cele standard;
modelul oferă posibilitatea unui design flexibil, întrucât întruchipează avantajele modelului cascadă și, în același timp, iterațiile sunt permise în 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 fără promisiuni, cu pierderi financiare minime pentru el însuși;
feedback-ul utilizatorilor către dezvoltatori se face cu frecvență ridicată și la începutul modelului pentru a se asigura că produsul potrivit este creat cu o calitate înaltă.

Dezavantaje ale modelului:

dacă proiectul are un risc redus sau dimensiuni reduse, modelul poate fi scump. Evaluarea riscurilor după fiecare spirală este costisitoare;
Ciclul de viață al unui model are o structură complicată, deci poate fi dificil pentru dezvoltatori, manageri și clienți să-l folosească;
spirala poate continua la nesfârșit, 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 documentației suplimentare;
utilizarea modelului poate fi costisitoare și chiar prohibitivă deoarece timp. planificarea cheltuielilor, redefinirea obiectivelor, efectuarea analizei riscurilor și a prototipurilor pot fi excesive;
poate fi dificil să se definească obiective și repere care indică disponibilitatea de a continua procesul de dezvoltare în următorul și

Principala problemă a ciclului spiral este determinarea momentului în care să treceți la etapa următoare. Pentru a o rezolva, sunt introduse limite de timp pentru fiecare dintre etape.ciclu de viață iar tranziția se desfășoară conform planificării, chiar dacă nu toate lucrările planificate au fost finalizate.Planificare produse pe baza datelor statistice obținute în proiecte anterioare și a experienței personale a dezvoltatorilor.

Aplicații model spiralat

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

atunci când dezvoltă proiecte folosind noi tehnologii;
atunci când se dezvoltă serie nouă produse sau sisteme;
atunci când se dezvoltă proiecte cu modificări sau adăugiri semnificative preconizate;
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 evaluării și rezolvării riscurilor.

Adnotare.

Introducere.

1. Ciclul de viață al software-ului

Introducere.

Pașii procesului de programare Riley

Introducere.

1.1.1. Formularea problemei.

1.1.2. Proiectarea soluției.

1.1.3. Codarea algoritmului.

1.1.4. Întreținerea programului.

1.1.5. Documentație software.

Concluzie la punctul 1.1

1.2. Determinarea producției ciclului de viață în conformitate cu Lehman.

Introducere.

1.2.1 Definiția sistemului.

1.2.2. Implementare.

1.2.3. Serviciu.

Concluzie la clauza 1.2.

1.3. Fazele și activitatea ZhCPO conform lui Boehm

1.3.1. Model cascadă.

1.3.2. Raționamentul economic pentru modelul cascadei.

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

1.3.4. Determinarea fazelor ciclului de viață.

1.3.5. Lucrări de bază la proiect.

Literatură.

Introducere

Aplicatie industriala calculatoarele și cererea tot mai mare de programe au stabilit sarcini urgente să crească semnificativ productivitatea dezvoltării software-ului, dezvoltarea metodelor industriale pentru planificarea și proiectarea programelor, transferul tehnicilor, modelelor și metodelor organizatorice și tehnice, tehnice, economice și socio-psihologice din sfera producției materiale în sfera utilizării computerelor. O abordare complexă la procesele de dezvoltare, operare și întreținere a software-ului a prezentat o serie de probleme urgente, a căror soluție va elimina „blocajele” în proiectarea programelor, va reduce timpul de finalizare a lucrărilor, va îmbunătăți selecția și adaptarea celor existente programe și poate determina soarta sistemelor cu computere încorporate.

În practica dezvoltării de proiecte software mari, nu există adesea abordare uniformă la evaluarea costurilor forței de muncă, calendarul muncii ș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, probabil, 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 acest lucru termen de hârtie... În această carte, proiectarea software-ului se referă la procesul de creare a unui produs software.

1 Ciclul de viață al software-ului

INTRODUCERE

ZHCPO este proces continuu, care începe din momentul luării unei decizii cu privire la necesitatea de a crea 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), pașii procesului de programare, cascada și modelele în spirală. Dar toate conțin componente fundamentale comune: declarația problemei, proiectarea soluției, implementarea, întreținerea.

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

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

Și, pentru o schimbare, - vă prezentăm pașii procesului de programare prezentat de D. Riley în cartea „Folosirea limbajului Module-2”. Această idee, după părerea mea, este foarte simplă și familiară și vom începe cu ea.

1.1 Pași în procesul de programare Riley

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

declarație de problemă, 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ă;

întreținerea programului, adică un proces continuu de depanare a programului și adăugarea de noi funcții.

Figura: 1. Patru pași de programare.

Programarea începe din momentul când utilizator, adică cel care are nevoie de program pentru a rezolva problema prezintă problema analist de sistem. Utilizatorul și analistul de sisteme definesc împreună afirmația problemei. Acesta din urmă este apoi transmis algoritmistcine este responsabil pentru proiectarea soluției. O soluție (sau algoritm) reprezintă o succesiune de operații, a căror executare duce la o soluție la o problemă. Deoarece algoritmul nu este adesea adaptat pentru a rula pe o mașină, trebuie să fie tradus într-un program de mașină. Această operațiune este realizată de codificator. Întreț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 de mari dimensiuni, numărul de utilizatori, analiști de sistem și algoritmi poate fi semnificativ. În plus, poate fi necesar să reveniți la pașii anteriori din cauza unor circumstanțe neprevăzute. Toate acestea se adaugă argumentului pentru o proiectare atentă a software-ului: rezultatele fiecărui pas trebuie să fie complete, exacte și de înțeles.

1.1.1 Afirmația problemei

Unul dintre cei mai importanți pași în programare este definirea problemelor. Acesta servește ca un contract între utilizator și programator (i). La fel ca un contract legal scris greșit, declarația de problemă proastă este inutilă. Cu o formulare bună a sarcinii, atât utilizatorul, cât și programatorul reprezintă în mod clar și fără echivoc sarcina care trebuie efectuată, adică în acest caz, se iau î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 formulare bună a problemei servește ca bază pentru formarea soluției sale.

Formularea problemei (specificația programului); înseamnă, în esență, o descriere exactă, 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ă: nu contează pentru el cum funcționează computerul, dar ceea ce contează este ceea ce poate face computerul care îl interesează pe utilizator. Accentul este pus pe interacțiunea om-mașină.

Caracteristicile unei declarații de sarcini bune:

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

Completitudine, adică luând în considerare toate opțiunile pentru o intrare dată, inclusiv intrarea eronată sau neintenționată, și determinarea rezultatului corespunzător.

Claritate, adică ar trebui să fie de înțeles atât pentru utilizator, cât și pentru analistul de sisteme, deoarece declarația problemei este singurul contract dintre ei.

Adesea, cerința de precizie, completitudine și claritate este în conflict. Asa de mult documente juridice este greu de înțeles, deoarece acestea sunt scrise într-un limbaj formal care vă permite să formulați anumite dispoziții extrem de precis, excluzând orice discrepanțe minore. De exemplu, unele întrebări despre biletele de examen sunt uneori atât de precise, încât studentul 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 echilibrează toate cele trei cerințe.

Forma standard a enunțului de problemă.

Luați în considerare următoarea declarație de problemă: „Introduceți trei numere și scoateți numerele în ordine”

Această formulare nu îndeplinește cerințele de mai sus: nu este nici precisă, nici completă, nici înțeleasă. Într-adevăr, numerele ar trebui să fie introduse unul pe fiecare linie sau toate numerele pe o singură linie? Dacă 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 detaliat și greu de înțeles. Prin urmare, D. Riley propune să utilizeze un formular standard pentru stabilirea problemei, care oferă o acuratețe maximă, completitudine, claritate și include:

numele sarcinii (definiție schematică);

descriere generală (expunere succintă a problemei);

erori (opțiunile de intrare neobișnuite sunt listate î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, ilustrează diferite cazuri).

Exemplu. Declarație de problemă într-un formular standard.

NUME

Sortarea a trei numere întregi.

DESCRIERE

Intrare și ieșire trei numere întregi, sortate de la cel mai mic la cel mai mare.

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

Sunt afișate cele trei numere întregi introduse, toate fiind afișate pe o singură 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ă intrări suplimentare.

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

Ciclul de viață al unui IS este o serie de evenimente care apar odată cu sistemul în procesul de creare și utilizare a acestuia.

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 selectată ca un 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ă uniformitate în numele acestor etape.

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

Analiza cerințelor,

Proiecta,

Codificare (programare),

Testare și depanare,

Funcționare și întreținere.

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

modelul în cascadă (70-80 de ani) ≈ presupune trecerea la etapa următoare 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, se formează documentația proiectului, care este completă și consecventă.

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 software este în cascadă-returnare

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 dezvoltarea de software cu bucle de feedback între etape. Avantajul acestui model este că ajustările între etape sunt mai puțin consumatoare de forță de muncă decât modelul cascadei; cu toate acestea, durata de viață a fiecărei etape se extinde 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 simplu procese).

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 semnificația care este dată 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 suporturile de date.

Colectarea suporturilor de date utilizate în orice fel de prelucrare a datelor se numește mediu de date.

Setul de date conținute în orice moment în mediul informațional este starea mediului informațional.

Procesul poate fi definit ca o succesiune 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 necesar să fie generat automat pe un computer în conformitate cu o descriere dată, această descriere trebuie formalizată.

Criterii de calitate a software-ului

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 clienților

Caracteristici de calitate:

Operabilitate - sistemul funcționează și implementează funcțiile necesare.

Fiabilitate - sistemul funcționează fără eșecuri și eșecuri.

Recuperabilitate.

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

Eficiență economică - costul minim al produsului final cu profitul maxim.

Caracteristici de calitate:

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

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

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

Precizia calculului

Proprietățile algoritmului.

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

Certitudine constă în coincidența rezultatelor obținute indiferent de utilizator și de 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 valorile specifice ale datelor inițiale.

Discreție - posibilitatea de a împărți procesul de calcule prescris 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 modalități de a descrie (reprezenta) algoritmi:

1. descriere verbală;

2. descrierea algoritmului folosind formule matematice;

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

4. descrierea algoritmului folosind pseudocod;

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

6. folosind plase Petri.

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

Descriere grafică algoritm sub forma unei diagrameEste 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 problemelor care utilizează caractere speciale pentru a reprezenta operații.

Simbolurile care alcătuiesc diagrama bloc 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ă ambiguități.

Pseudo cod - descrierea structurii algoritmului într-un limbaj natural, dar parțial formalizat. Pseudocodul folosește câteva constructe formale și notație matematică comună. Nu există reguli stricte de sintaxă pentru scrierea pseudocodului.

Să ne uităm la cel mai simplu exemplu. Să fie necesar să descrieți 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\u003e X, atunci Concluzia Z

4. În caz contrar, ieșire X

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

Tipuri de algoritmi

liniar;

ramificare;

ciclic.

· Algoritm liniar - un set de comenzi (instrucțiuni) executate secvențial unul după altul.

· Algoritm de furcare - un algoritm care conține cel puțin o condiție, ca urmare a verificării computerului care 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) pe date inițiale noi. Majoritatea metodelor de calcul, enumerarea opțiunilor, sunt reduse la algoritmi ciclici. Ciclul programului - o secvență de comenzi (serie, corp buclă), care poate fi executată de mai multe ori (pentru date inițiale noi) până când se îndeplinește o anumită condiție.

C. Tipuri de date.

Un tip de date este o descriere a gamei de valori pe care o poate lua o variabilă de tipul specificat. Fiecare tip de date este caracterizat prin:
1. numărul de octeți ocupați (dimensiune)
2. gama de valori pe care o 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 (vectoriale);
2. bază (sistem) și definită de utilizator (definită de utilizator).
În limbajul C, sistemul de tip bază este format din patru tipuri de date:
1. caracter,
2. întreg
3. precizie unică reală,
4. dublă precizie reală.

Structura unui program C.

1. Operatori ai limbajului C ++

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

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

Operator condiționat

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

Comutator operator

intrerupator (<выражение>)
(caz<константное выражение 1>: <операторы 1>
caz<константное выражение 2>: <операторы 2>
...
caz<константное выражение N>: <операторы N>
}
Operatorul de comutare este conceput pentru a selecta una dintre mai multe modalități alternative de execuție a programului. Evaluarea operatorului de comutare î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 comutare este efectuată de operatorul de pauză. Dacă valoarea expresiei nu este egală cu orice expresie constantă, atunci controlul este transferat operatorului marcat cu cuvântul cheie implicit, dacă există.
Operator buclă cu condiție prealabilă

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

Operator 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 faptul că, dacă expresia este adevărată, bucla continuă și nu iese din buclă.
Operator ciclu pas

pentru ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Corpul instrucțiunii for este executat până când expresia condițională devine falsă (egală cu 0). O expresie inițială și o expresie de incrementare 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ționale, iar expresia incrementală este evaluată după fiecare execuție a instrucțiunii. Oricare dintre cele trei expresii de antet de buclă, sau chiar toate cele trei, pot fi omise (nu uitați să lăsați punct și virgula). Dacă expresia condițională este omisă, atunci este considerată adevărată și bucla devine infinită.
Operatorul de buclă în trepte î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 declarația for.
Operator de pauză

pauză;
Instrucțiunea break întrerupe executarea instrucțiunilor while, do, for și switch. Poate fi conținut doar în corpul acestor afirmații. Controlul este transferat operatorului de program după cel întrerupt. Dacă o instrucțiune break este scrisă în interiorul instrucțiunilor imbricate în timp ce, do, for, switch, acesta termină doar instrucțiunea care o cuprinde imediat.
Operator de continuare

continua;
Instrucțiunea de continuare transferă controlul la următoarea iterație în instrucțiunile while, do, pentru buclă. Poate fi conținut doar în corpul acestor afirmații. În declarațiile 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 incrementale și apoi evaluează expresia condițională.
Operator de retur

întoarcere [<выражение>];
Instrucțiunea return finalizează executarea funcției în care este conținută și returnează controlul funcției apelante. Controlul este trecut la punctul funcției de apelare

If (expresie booleană)

operator;

If (expresie booleană)

operator_1;

operator_2;

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

Dacă valoarea expresiei logice este adevărată, atunci se evaluează expresia_1, altfel se evaluează expresia_2.

switch (expresie întreagă)

valoarea cazului_1:

statement_sequence_1;

valoarea cazului_2:

statement_sequence_2;

valoare_n_caz:

statement_sequence_n;

mod implicit:

statement_sequence_n + 1;

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

Operator buclă.

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

Buclă 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 ++, numai variabilele numerice pot fi utilizate ca variabile în instrucțiunea select. În general, înregistrarea operatorului de selecție arată astfel:

comutator (variabil)
{
valoarea cazului 1:
acțiuni1
pauză;

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

mod implicit:
acțiuni implicite
}

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

comutator (variabil)
{
valoarea cazului 1:
valoarea cazului 2:
acțiuni1
pauză;

valoarea cazului 3:
acțiuni2
pauză;
...
}

Exemplu folosind selecția:

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

cazul 1:
cazul 2:
cazul 3:
x \u003d 3 * n; // dacă n este 1, 2 sau 3, atunci efectuăm câteva acțiuni
pauză;

cazul 4:
x \u003d n; // dacă n este 4, atunci faceți alte acțiuni
pauză;

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

C. Buclă: Buclă cu parametru

Forma generală de înscriere

pentru (inițializarea parametrilor; verificați starea de terminare; corectarea parametrilor) (

bloc de operațiuni;

for este o buclă parametrică (buclă 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 unei valori inițiale unui parametru de ciclu;

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

§ corectarea parametrilor - modificarea valorii parametrului cu fiecare pasaj al 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 bucla for începe să se execute. Condiția finală este verificată înainte de fiecare posibilă execuție a corpului buclei. Când expresia devine falsă (egală cu zero), bucla se termină. Parametrul este ajustat la sfârșitul fiecărei execuții a corpului buclei. Parametrul poate crește sau micșora.

Exemplu

#include
int main () (

pentru (num \u003d 1; num< 5; num++)

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

C. Buclă cu condiție prealabilă

Forma generală de înscriere

while (expresie) (

bloc de operațiuni;
}

Dacă expresia este adevărată (nu egală cu zero), atunci se execută blocul de operații închise între acolade, atunci expresia este verificată din nou. Succesiunea acțiunilor, 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 închisă, iar operația după executarea operatorului de buclă.

Exemplu

int k \u003d 5;
int i \u003d 1;
int sumă \u003d 0;
in timp ce eu<=k) {

Atunci când construiți o buclă while, este necesar să includeți în ea construcții care să schimbe 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 condiție prealabilă, deci este foarte posibil ca corpul buclei să nu fie executat nici măcar o dată dacă condiția verificată se dovedește a fi falsă în momentul primei verificări.

C. Buclă cu postcondiție

Bucla cu condiție post ... nu

Forma generală de înscriere

bloc de operațiuni;

) while (expresie);

Buclă cu postcondiție

Bucla do ... while este o buclă cu o postcondiție, unde adevărul expresiei este verificat după toate operațiile incluse în bloc, delimitat de acolade. Corpul buclei este executat până când expresia devine falsă, este, corpul buclei cu postcondiție este executat deși o 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 verificarea stării are loc în interiorul corpului 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 unei funcții 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 chiar și după toate acestea, în cele din 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, aceasta trebuie definită cu aceeași valoare de returnare și tipuri de date, altfel va fi creată o nouă funcție supraîncărcată. Rețineți că numele parametrilor funcției nu trebuie să fie aceleași.

Ar putea fi util să citiți: