T 2 zivotni ciklus i metodologije razvoja softvera

T-2: Životni ciklus i metodologije razvoja softvera

dr Zoran Jeremić[email protected]

Sadržaj

2

1. Uvod

2. Životni ciklus razvoja softvera


3. Metodologije razvoja softvera

Uvod

Softversko inženjerstvo možemo definisati kao sistemski pristup razvoju, korišćenju, održavanju i odumiranju softvera.

Pored isporuke softvera, visok kvalitet, mali troškovi i kratak vremenski rok su dodatni ciljevi koje softverski inženjer mora da dostigne.

Kvalitet i produktivnost konačnog proizvoda zavise od veštine ljudi uključenih u projekat, procesa koji koriste za različite zadatke u projektu i alata koje koriste.

U softverskom inženjerstvu glavni fokus je dat na procesima. Osnovni zadatak procesa je da pomogne ljudima da postignu

veći kvalitet i produktivnost kroz specifikaciju zadataka koje treba uraditi i definisanjem načina na koji ih treba uraditi.

3T-2: Životni ciklus i metodologije razvoja softvera

Životni ciklus razvoja softvera

Šta je informacioni sistem (IS)?

4

Hardver, softver, podaci, ljudi i procedure koji funkcionišu

zajedno da bi proizveli kvalitetne informacije.

Sistem—Skup komponenti koje međusobno sarađuju

kako bi postigli zajednički cilj.

U poslovanju se koriste različiti tipovi sistema


Šta je životni ciklus razvoja softvera?

(engl. System Development Life Cycle – SDLC)

Proces kroz koji stručnjaci različitih profila (analitičari, projektanti, inženjeri, programeri, ...) i korisnici informacionog sistema prave informacioni sistem.

5



Koje su preporuke za razvoj sistema?

T-2: Životni ciklus i metodologije razvoja softvera 6


Grupisanje zadataka po fazama (grupama aktivnosti)

Uključivanje korisnika (bilo koje lice za koje se sistem implementira)

Razvoj jasno definisanih standarda (procedure za koje kompanija očekuje da zaposleni treba da ih primenjuju)

Životni ciklus razvoja softveraKo su učesnici u životnom ciklusu razvoja softvera?


Životni ciklus razvoja softveraŠta je analitičar sistema?

8

Osoba odgovorna za dizajn i razvoj

informacionog sistema

Veza između korisnika i IT profesionalaca


Životni ciklus razvoja softveraŠta je projektni tim?

9

Sastoji se od korisnika, analitičara sistema i drugih IT profesionalaca

Grupa ljudi koji rade na projektu od početka do kraja

Vođa projekta—jedan od članova tima koji upravlja i kontroliše budžetom projekta i vremenskim planom


Životni ciklus razvoja softveraŠta je izvodljivost?

10

Procena koliko će koristi

kompanija imati od

razvoja sistema

Operaciona izvodljivost

Izvodljivost vremenskog

roka

Četiri testa izvodljivosti:

Tehnička izvodljivost

Ekonomska izvodljivost

(poznata i kao cost/benefit

analiza)

Zakonskaizvodljivost


Životni ciklus razvoja softveraŠta je dokumentacija?

11

Obuhvata izveštaje, dijagrame, programe i druge izveštaje

Kolekcija i rezime podataka i informacija


Šest tehnika za prikupljanje podataka i informacija?

12

Analiza dokumentacije Posmatranje Upitnici Intervjui Joint-application

design (JAD) sesija Istraživanje



Životni ciklus razvoja softveraKoje su faze životnog ciklusa razvoja softvera?

13

Faza 1. Planiranje

Faza 2. Analiza

Faza 3. Dizajn

Faza 4. ImplementacijaFaza 5. Podrška

Pregled projektnih zahteva

Analiza prioriteta projektnih zahteva

Dodeljivanje resursa Identifikovanje proj.

razvojnog tima

Izvođenje preliminarne analize Izvršenje detaljne analize:

Proučavanje trenutnog sistemaUtvrđivanje korisničkih zahtevaPredlog rešenja

Nabavka hardvera i softvera, ukoliko je potrebno

Razvoj detalja sistema

Razvoj programa, Instaliranje i testiranje novog

sistema Obuka korisnika Korišćenje novog sistema

Revizije sistema Identifikovanje grešaka i

unapređenja Praćenje performansi sistema


PlaniranjeKoji su razlozi za kreiranje ili modifikovanje informacionog sistema?

14

Rešavanje problema u postojećem

sistemu

Unapređenje postojećeg

sistem

Spoljašnji uslovi

zahtevaju promenu

Konkurentnost može voditi do

promene


PlaniranjeŠta je zahtev za održavanjem sistema?

15

Formalni zahtev za novim ili modifikovanim informacionim sistemom Takođe zvan

projektni zahtev


PlaniranjeŠta je faza planiranja?

16

Počinje kada upravni odbor primi projektni zahtev

Upravni odbor—

rukovodeće telo kompanije

Funkcije odbora:

Recenzija i odobravanja projektnih

zahteva

Dodeljivanje resursa

Formiranje razvojnog tima

projekta za svaki odobreni

projekat

Određivanje prioriteta

projektnim zahtevima


AnalizaŠta je faza analize?

17

Izvršenje preliminarnog istraživanja, poznato i kao

studija izvodljivosti

Izvršenje detaljne analize


AnalizaŠta je preliminarno istraživanje?

18

Utvrđivanje tačne prirode problema ili unapređenja i utvrđivanje da li je vredno truda Zaključci se prezentuju u izveštaju o izvodljivosti, poznatom kao studija

izvodljivosti


1. Proučavanje kako trenutni sistem funkcioniše

AnalizaŠta je detaljna analiza?

19

Ponekad se zove logički dizajn

2. Utvrđivanje šta korisnik želi, šta mu je potrebno i definisanje

zahteva

3. Predlaganje rešenja


Predstavlja se upravnom

odboru, koji donosi odluku o tome kako će se sistem razvijati

AnalizaŠta je predlog projekta?

20

Procenjuje izvodljivost

svakog alternativnog

rešenja

Predlaže najizvodljivije

rešenje za projekat


AnalizaŠta su moguća rešenja?

21

Kupovina paketskog softvera —softver dostupan na tržištu

Outsource—spolja razvijen softver

Izrada sopstvenog korisničkog softvera—softver razvijen prema

korisničkim zahtevima

Softver za vertikalno tržište—dizajniran za

određenu industriju

Softver za horizontalno

tržište—rađen za potrebe mnogih

kompanija


DizajnŠta je faza dizajna?

22

Izlaz:• dokument koji opisuje arhitekturu• plan implementacije• analiza osnovnih prioriteta• Plan testiranja

Razvoj svih detalja novog ili modifikovanog informacionog

sistema

Definiše se arhitektura sistema (komponente, njihov interfejs i ponašanje).


Razgovor sa kompanijama za izradu softvera

DizajnŠta je potrebno za nabavku novog softvera?

23

Identifikovanje svih hardverskih i softverskih zahteva novog ili modifikovanog sistema

Pretraživanje Weba

Čitanje štampanih i online trgovačkih časopisa, novina,

oglasa…

Razgovor sa drugim analitičarima sistema


DizajnKoja su tri osnovna dokumenta koja se koriste za pregled tehničkih specifikacija?

24

Manje formalni metod koji koristi standardnu formu

za dobijanje informacije o

proizvodu ili usluzi

Prodavac daje cene za

navedene proizvode

Prodavac bira proizvod(e) koji

ispunjavanju definisane zahteve i

predlaže cene

Kupac definiše

proizvode koje želi

Zahtev za informacijom

Zahtev za predlog

Zahtev za izjašnjavanjem


DizajnKako analitičari sistema testiraju softverski proizvod?

25

Proučavanje referenci prodavca Razgovor sa trenutnim korisnicima proizvoda Demonstracije proizvoda Korišćenje trial verzija softvera Merenje performansi korišćenjem benchmark testova


DizajnŠta je detaljni dizajn?

26

Obuhvata nekoliko aktivnosti

Dizajn baze podataka Dizajn ulaza i izlaza Dizajn programa

Detaljna specifikacija dizajna za komponente u predloženom rešenju


DizajnŠta je mockup?

27

Funkcionalnosti sistema se predstavljaju crtanjem elemenata korisničkog interfejsa.

http://www.balsamiq.com

Primer izgleda ekrana predstavljen korišćenjem alata za kreiranje mockup-a

T-2: Životni ciklus i metodologije razvojasoftvera

ImplementacijaŠta je prototip?

28

Radni model za predloženi sistem Izrada prototipa

previše rano može dovesti do problema

Nekompletna verzija softvera koji se razvija. Obično simulira samo nekoliko aspekata funkcionalnosti

eventualnog softvera i može biti potpuno drugačiji od kranjeg proizvoda.

Omogućava korisnicima softvera da evaluiraju ono što su developeri predložili kao rešenje.


ImplementacijaŠta je computer-aided software engineering (CASE)?

29

Softverski alati dizajnirani da podrže aktivnosti životnog ciklusa razvoja softvera


Prelazak na novi sistem

ImplementacijaŠta je faza implementacije?

30

Cilj je da se konstruiše ili izgradi novi ili modifikovani sistem a zatim isporuči korisnicima

Obuka korisnika

Instalacija i testiranje novog sistema

Razvoj programaT-2: Životni ciklus i metodologije razvoja softvera

ImplementacijaKoja su tri tipa testova koje izvršava projektni tim?

31

Provera da li aplikacija radi sa

drugim aplikacijama

Testiranje sistema

Testiranje integracije

Testiranje jedinice

Provera da li svaka pojedinačna komponenta funkcioniše

Provera da li svi programi u aplikaciji

rade zajedno


PodrškaŠta je obuka?

32

Pokazivanje korisnicima kako će koristiti hardver i softver u sistemu


PodrškaŠta je faza podrške?

33

Upravljanje analizom sistema nakon implementacije—vođenje sastanaka da bi se utvrdilo da li se informacioni sistem ponaša prema

očekivanjima

Identifikovanje grešaka

Identifikovanje potencijalnih unapređenja

Praćenje performansi sistema

Obezbeđuje tekuću pomoć nakon implementacije sistema


Modeli softverskih procesa

Šta je model procesa?

T-2: Životni ciklus i metodologije razvoja softvera 34

Uopšteno: razvojni plan koji definiše opšti proces razvoja softverskog proizvoda

Preciznije: Definicija koja odredjuje koje aktivnosti se izvršavaju, od strane kojih osoba u kojim ulogama; kojim redosledom će aktivnostibiti izvršavane, koji proizvodi će biti razvijani i kako će se procenjivati

njihov kvalitet.

Pregled postojećih modela softverskih procesa


Metodologije razvoja softvera

Metodologije razvoja softvera

Metodologija je formalizovani proces ili skup iskustava za kreiranje softvera

Skup pravila koje razvojni tim prati

Skup konvencija koje je organizacija odlučila da prati

Sistematičan, inženjerski pristup za organizovanje softverskih projekata


Među najpoznatije metodologije spadaju: Waterfall model Waterfall model sa prototipom Metodologija za paralelni razvoj V model Inkrementalni model Spiralni model Rapid Application Development (RAD) Rational Unified Process Extreme Programming (XP) Scrum metodologija

Metodologije razvoja razvoja


Build and Fix model

Većina softvera je razvijena korišćenjem ovog modela. U suštini ovde nema modela, specifikacije, ni dizajna.


Waterfall model


Jedan od najstarijih modelaDobar za rešavanje potpuno jasnih problema

bez izmena u zahtevimaJednostavan i razumljiv za korisnikaPredstavlja Vrlo apstraktan prikaz razvojnog procesa Niz aktivnosti

Jasne granice između faza sa izlaznim produktima

Waterfall model


Waterfall model

Naziva se još i linearno-sekvencijalni model.

Svaka faza mora biti u potpunosti završena pre nego što započne sledeća faza.

Na kraju svake faze, vrši se analiza da bi se utvrdilo da li je projekat na dobrom putu i da li se treba nastaviti ili obustaviti.

Ova analiza se naziva završna analiza faze.


Waterfall model

Tradicionalni pristup razvoju:

Definisanjezahteva

Dizajn softvera

Implementacija (kodiranje)

Verifikacija(testiranje)

Korišćenje(održavanje)


Waterfall model

Prednosti: Svaka faza ima specifične izlazne produkte i proces

analize. U jednom trenutku radi se samo na jednoj fazi. Dobar je za male projekte kod kojih su potpuno

definisani i jasni zahtevi. Potkrepljuje stav “definiši pre dizajna” i “dizajniraj pre

implementacije”.


Waterfall model

Nedostaci: Promena opsega u toku životnog ciklusa može ubiti

projekat. Ne postoji radna verzija softvera sve do kraja

životnog ciklusa. Velika je količina rizika i neizvesnosti. Nije pogodan za složene i objektno-orjentisane

projekte. Nije pogodan za dugotrajne i tekuće projekte. Nije dobar za projekte kod kojih postoji srednji ili veliki

rizik od promene zahteva. 44T-2: Životni ciklus i metodologije razvoja softvera

Waterfall model

Kada koristiti ovaj model? Ovakav model se koristi kod projekata koji su jasni i nisu

podložni promenama u toku razvoja (npr. projekti odbrane) Može se koristiti za projekte migracije, kod kojih će zahtevi ostati

isti ali se menja platforma ili jezik. Takođe se može koristiti za projekte gde sami sponzori vrše

testiranje, s obzirom da do završetka projekta nema isporuke.


Waterfall model sa prototipom

Prototip je delimično razvijen proizvod.

Prototip pomaže Dizajnerima da procene alternativne strategije dizajna (prototip

dizajna) Korisnicima da razumeju kako će izgledati sistem (prototip

korisničkog interfejsa)

Prototip je koristan za verifikaciju i validaciju



Može se koristiti kod scenarija gde ne postoje detaljne informacije u vezi ulaza u sistem, potreba za obradom i izlazom.

Omogućava klijentu da eksperimentiše sa radnom verzijom produkta.

Razvojni proces se nastavlja samo ako je klijent zadovoljan funkcionisanjem prototipa.

U toku određenih faza developer utvrđuje specifikaciju klijentovih stvarnih potreba.



Prednosti: Dizajner softvera i programer mogu dobiti povratne informacije

od korisnika u ranim fazama projekta. Klijent i izvođač radova mogu uporediti da li softver ispunjava

specifikacije, prema kojima je softver napravljen. Takođe omogućava softverskom inženjeru određeni uvid u

tačnost inicijalnih projektnih predračuna i da li se mogu ispuniti predloženi vremenski rokovi.



Nedostaci: Klijenti često očekuju da će nekoliko minimalnih izmena na

prototipu zadovoljiti njihove potrebe, ne shvatajući da se u žurbi izgradnje prototipa nije vodilo računa o celokupnom kvalitetu softvera .

Programeri mogu izgubiti fokus o stvarnoj nameni prototipa i kompromitovati kvalitet proizvoda, npr. mogu primeniti neke neefikasne algoritme ili neodgovarajuće programske jezike korišćene u razvoju prototipa (uglavnom posledica lenjosti ili bliskosti sa jednostavnijim metodama)

Prototip će teško biti prihvaćen na sudu u slučajevima kada se klijent ne slaže da je developer ispunio svoje obaveze. 50T-2: Životni ciklus i metodologije razvoja softvera


Kada koristiti ovaj model? Prototipovi su vrlo efikasni u analizi i dizajnu online sistema. Sistemi sa malo interakcije korisnika i sistema, npr sistemi koji

uglavnom vrše kalkulacije, imaju malo koristi od ovog modela Ponekada implementacija sistemskih funkcija može biti veoma

složena a potencijalne prednosti prototipova mogu biti veoma male.

Prototip je veoma dobar za dizajn dobrog human-computer interfejsa.

Jedna od najproduktivnijih upotreba prototipova do sada je bila kao alata za iterativno inženjerstvo korisničkih zahteva i dizajn korisničkog interfejsa.


Metodologija za paralelni razvoj

Metodologija je slična Waterfall modelu

Projekat je podeljen na manje projekte i svaka faza se izvršava posebno za svaki od njih.

Razvojni proces se izvršava konkurentno i odvojeno za svaki od potprojekata.



Prednosti: Smanjuje vreme razvoja Manje su šanse da su potrebne prepravke

Nedostaci: I dalje se koriste papirna dokumenta Podprojekte je ponekada teško integrisati


V model

Mnogo je veći značaj aktivnosti testiranja nego kod Waterfall modela. Procedure i uslovi testiranja se razvijaju u ranim fazama životnog ciklusa pre implementacije.

Životni ciklus počinje zahtevima kao i kod waterfall modela. Pre početka razvoja kreira se plan testiranja prihvatljivosti sistema

koji se fokusira na zadovoljenju funkcionalnosti definisanih zahtevima.

U ranim fazama dizajna definiše se arhitektura sistema i dizajn. Plan testiranja integracija se takode definiše u ovoj fazi kako bi se utvrdilo da svi delovi funkcionišu zajedno.

U kasnijim fazama dizajna se dizajniraju komponente softvera i testovi pojedinačnih jedinica.

U fazi implementacije se realizuje kodiranje. Po završetku kodiranja, ranije planirani testovi se izvršavaju.


V model


V model

Prednosti Svaka faza ima specifične produkte. Veće su šanse za uspeh od Waterfall modela zbog razvoja

planova testova u ranim fazama životnog ciklusa. U poređenju sa waterfall modelom vreme realizacije je kraće do

50%. Daje dobre rezultate kod malih projekata čije zahteve je lako

razumeti. Iskorišćenje resursa je veliko.


V model

Nedostaci Vrlo je rigidan, kao i waterfall model. Jako teško i skupo je postići malu fleksibilnost Softver se razvija tokom faze implementacije, pa nema ranih

prototipova. Model ne obezbeđuje rešenja problema nađenih u fazi testiranja.


V model

Kada koristiti ovaj model? Kada vreme i troškovi predstavljaju ograničenje projekta. Slično kao i kod Waterfall modela, ali aktivnosti testiranja koje

počinju veoma rano, doprinose smanjenju vremena razvoja i troškova projekta.


Inkrementalni model

Kombinuje elemente liearnog sekvencijalnog modela sa iterativnom filozofijom prototipova.

Svaka linearna sekvenca isporučuje uvećan softver.

Kod ovog modela, prvi inkrement je često osnovni proizvod, dok se u ostalim inkrementima dodaju dodatne funkcionalnosti.


Inkrementalni model


Inkrementalni model

Nedostaci Sistem mora imati “incremente”. Incrementi moraju biti od značaja za korisnika. Sveukupno, duže (značajno duže) vreme razvoja. Biznis procedura se menja sa svakim incrementom.


Spiralni model

Sličan je inkrementalnom modelu, sa većim naglaskom na analizi rizika.

Ima četiri faze: planiranje, analiza rizika, inženjerstvo i evaluacija. Projekat više puta prolazi ove faze u iteracijama.

Zahtevi se analiziraju u fazi planiranja. U fazi analize rizika identifikuju se rizici i alternativna rešenja. Prototip se kreira na kraju faze analize rizika.

Softver se razvija u inženjerskoj fazi a na kraju faze se realizuje testiranje. Faza evaluacije omogućava korisniku da evaluira projekat pre nego što se pređe na narednu spiralu.

U spiralnom modelu ugaona komponenta predstavlja progres, a radijus spirale predstavlja sveukupne troškove.


Spiralni model


Spiralni model

Prednosti: Visok je stepen analize rizika Dobar je za velike i kritične projekte. Softver se proizvodi u ranim fazama životnog ciklusa.


Spiralni model

Nedostaci: Može biti veoma skup model. Analiza rizika zahteva visok stepen ekspertize. Uspeh projekta je veoma zavistan od faze analize rizika. Nije dobar za male projekte.


Spiralni model

Kada se koristi? Za aplikacije koje imaju složeni grafički interfejs prema korisniku

i više-funkcionalni deo. Funkcionalnosi se mogu dodavati kroz faze, a grafički interfejs u nekoj od finalnih faza.

Često se koristi u velikim projektima. US vojska je usvojila ovaj model za svoj program budućih

borbenih sistema.


Rapid application development (RAD)

Inkrementalni proces razvoja softvera koji naglašava veoma kratak razvojni ciklus

Predstavlja “high-speed” adaptaciju linearnog sekvencijalnog modela u kome je brzi razvoj postignut korišćenjem konstrukcije zasnovane na komponentama.

Ukoliko su zahtevi jasni omogućava razvoj funkcionalnog sistema u kratkom periodu (npr. 60-90 dana)



Naglašava sledeće faze: Poslovno modelovanje – tokovi informacija između

poslovnih funkcija Modelovanje podataka – skupovi podataka potrebnih

za podršku poslovanju Modelovanje procesa – skupovi podataka se

transformišu da bi ostvarili tokove informacije neophodne za implementaciju poslovne funkcije.

Generisanje aplikacije – upotreba postojećih programskih komponenti (kada je moguće)

Testiranje – s obzirom da se naglašava upotreba postojećih komponenti, mnoge od njih su već testirane.



Nedostaci: Za velike ali skalabilne projekte, RAD zahteva

dovoljno ljudskih resursa koji bi kreirali odgovarajući broj RAD timova.

RAD zahteva da se developeri i korisnici pridržavaju RAD aktivnosti kako bi sistem završili na vreme u mnogo kraćem vremenskom roku.

Nisu sve aplikacije pogodne za RAD. Ako sistem ne može biti modularizovan na odgovarajući način, kreiranje komponenti potrebnih za RAD može biti problematično

RAD nije pogodan kada su tehnički rizici veliki.


AGILNE METODOLOGIJE


Agilne metodologije

Uključuju iteracije sa kratkim vremenskim intervalima.

Razdvajaju zadatke na male inkremente sa minimalnim planiranjem.

Mali timovi rade zajedno sa stakeholderima da definišu brze prototipove, dokaze koncepata i druga vizuelna sredstva za opisivanje problema koji se rešava.

Tim definiše zahteve za iteraciju, razvija kod, definiše i izvršava integrisane testove a korisnici verifikuju rezultate.

Verifikacija se izvršava mnogo ranije u razvojnom procesu nego kod Waterfall modela


Agilne metodologije

Neki od osnovnih principa agilnih metodologija su: Zadovoljstvo klijenta brzom, konstantnom isporukom korisnog

softvera. Radni softver se često isporučuje (u pitanju su nedelje a ne

meseci). Radni softver je principijelna jedinica napredka. Čak i kasne izmene zahteva su dobrodošle. Tesna, dnevna kooperacija između poslovnih ljudi i developera. Konverzacija licem u lice je najbolja forma komunikacije. Projekti se zasnivaju na angažovanju motivisanih individua, kojima

treba verovati. Jednostavnost . Samo-organizovani mali timovi (5-9 ljudi). Konstantno prilagođavanje promenljivim okolnostima.


Agilne metodologije

Neke od najpoznatijih metodologija agilnog razvoja softvera: Agile Modeling Agile Unified Process (AUP) Agile Data Method Dynamic System Development Method (DSDM) Essential Unified Process (EssUP) Extreme programming (XP) Feature Driven Development (FDD) Getting Real Open Unified Process (OpenUP) Scrum Lean software development


Extreme programming (XP)

Najčešće korišćena i najpoznatija agilna metodologija

Zasnovana je na jednostavnosti, komunikaciji, feedbacku i hrabrosti.

Timovi koriste jednostavnu formu planiranja i praćenja kako bi odlučili šta sledeće da rade.

Timovi kreiraju softver u seriji malih, potpuno integrisanih izdanja koja su prošla sve testove koje je korisnik definisao.

Predstavnik korisnika je deo tima.76T-2: Životni ciklus i metodologije razvoja softvera


Zasnovana je na 4 ključne aktivnosti: planiranje, upravljanje, dizajniranje i kodiranje

Planiranje Identifikuju se korisnički zahtevi. Planiranjem verzija kreira se raspored verzija. Često se prave mala izdanja. Projekt je podeljen u iteracije. Planiranje iteracije započinje svaku iteraciju.



Upravljanje Daje timu lokalni otvoreni radni prostor. Određuje održiv korak. Svaki dan započinje početnim sastankom. Prati se brzina projekta. Ljudi se razmeštaju. Popravlja se XP kada dođe do problema.



Dizajniranje Jednostavnost. Korišćenje CRC kartica za dizajn sesija. Kreiranje klinastih rešenja da bi se smanjio rizik. Funkcionalnosti se ne dodaju u ranim fazama. Ponovno planiranje kada god i gde god je potrebno.

Class –Responsibility -Collaboration



Kodiranje Korisnik je uvek dostupan. Kod se mora pisati tako da bude u skladu sa

standardima. Kodira se test jedinice prvo. Sav produkcioni kod je programiran u paru. Samo jedan par integriše kod u jednom trenutku. Česte integracije. Određen je računar za integraciju. Postoji kolektivno vlasništvo.



Testiranje Sav kod mora imati testove jedinica. Sav kod mora proći sve testove jedinica pre nego što se može

staviti u upotrebu. Kada se pronađe bag kreiraju se testovi. Testovi prihvatljivosti se često izvršavaju a rezultati se objavljuju.


T 2 zivotni ciklus i metodologije razvoja softvera

Education

Transcript of T 2 zivotni ciklus i metodologije razvoja softvera