aplikativni softver

Aplikativni softver

Violeta Tomašević[email protected]

2008/2009.

Fakultet za informatiku i menadžmentUniverzitet Singidunumwww.fim.singidunum.ac.yu

2Aplikativni softver

Formiranje ocene

Obaveza Način polaganja, prag prolaznosti (%)

Termin (nedelja)

Udeo u oceni (%)

Prisutnost - - 10

Kolokvijum 1 računar, 50 IX 40

Završni ispit usmeni XII 50

Literatura

www.crnarupa.singidunum.ac.yu• Shari L. Pfleeger, Joanne M. Atlee, Softversko inženjerstvo:teorija i praksa, prevod

Računarski fakultet, Beograd, 2006.• Martin Flowler, UML ukratko, prevod Mikro knjiga, 2004.


1) Da studenti:

sagledaju kompleksnost procesa razvoja softvera

nauče kako da priđu problemu koga rešavaju sa inženjerskog aspekta

nauče kako se ocenjuje kvalitet softverskog proizvoda

detaljnije upoznaju načine modelovanja procesa razvoja softvera

Ciljevi kursaSW

SW

SW

SW

2) Da studenti:

ovladaju osnovama raznih tehnika koje se koriste za razvoj web aplikacija


Sadržaj kursaNedelja Tema

I Uvod u razvoj softvera. Kvalitet softvera. Modelovanje.

II UML jezik za modelovanje.

III Internet programiranje: HTML, CSS.

IV Internet programiranje: JavaScript, cookies.

V Internet programiranje: XML.

VI Internet programiranje: DTD.

VII Internet programiranje:XML Schema.

VIII Rad sa bazama podataka na Internet-u.

IX Rad sa bazama podataka: PHP.

X Rad sa bazama podataka: PHP.

XI Web servisi.

XII Web servisi.


REŠENJE

UvodAnaliza sistema je razlaganje problema na delove, tj. potprobleme (PP) koje možemo da razumemo i koje možemo da rešimo. Veze između potproblema su izuzetno važne, jer mogu biti ključni faktor u nalaženju rešenja složenog problema.

PROBLEM

PP1 PP2 PP3

R1 R2 R3Sinteza rešenja je sklapanje parcijalnih rešenja (R) u cilju nalaženja kompletnog rešenja problema.

APLIKATIVNI SOFTVER

APLIKATIVNI SOFTVER

Ako postoji potre

ba

REŠENJE


Pojam aplikativnog softvera

Sistemski softver

Računarski hardver

Aplikativni softver

Assembler

Word proc. Graphics Spreadsh.

Web app. Databases Games

Debugger Compilers

File Mng. OS Utilities

Aplikativni softver čine programi napravljeni za specifičnu svrhu i nisu u direktnoj vezi sa hardverom. Pri svom izvršavanju oslanjaju se na sistemski softver, posebno na operativni sistem. Obično se kupuju odvojeno od računarskog hardvera.

Sistemski softver obuhvata programe na niskom nivou (low-level) koji služe za kontrolu operacija nad računarskom opremom.

U nekim slučajevima nema jasne granice između sistemskog i aplikativnog softvera. Na primer, nema saglasnosti oko toga da li je Internet Explorer web browser deo Windows OS ili nije.


Izazovi pri izradi softvera (1)Svaki problem se može rešiti na više načina. Oni se razlikuju po efikasnosti, preciznosti, mogućnosti modifikovanja, korisnosti, razumljivosti i drugim osobinama. Stoga pisanje softvera zahteva znanje, ali i domišljatost i veštinu.

Haker

Softverskiinženjer

Ume da napiše kod koji nešto radi.

Ume da proizvede sveobuhvatan stabilan i razumljiv kod koji se lako održava i koji efikasno radi ono zbog čega je napravljen. Taj kod predstavlja visoko kvalitetan softver.


Izazovi pri izradi softvera (2)I pored toga što proizvođači teže softveru bez mana, u stvarnosti mnogi softverski proizvodi sadrže nedostatke.

Neočekivana upotreba sistema usled zloupotrebe usled nestručnog rukovanja

Tržište diktira brz razvoj softvera brza isporuka ostavlja malo vremena za testiranje, pa su greške češće ponekad je teže ispraviti uočene nedostatke, nego napisati kompletan novi softver

Kvalitet je neophodan što je nedostatak duže neotkriven, njegovo otklanjanje više košta (troškovi ispravljanja greške u fazi analize su 10 puta manji od troškova nakon isporuke).

O čemu treba voditi

računa?


Šta je dobar softver?Kvalitet softvera zavisi od konteksta posmatranja. Na primer, nedostaci koji se tolerišu u softveru za obradu teskta, ne mogu se prihvatiti u sistemima gde je faktor bezbednosti izuzetno bitan.

Kvalitet softvera mora se posmatrati na više načina:

Kvalitet proizvoda

Kvalitet postupka izrade proizvoda

Kvalitet proizvoda u kontekstu poslovnog okruženja u kome će se koristiti


Kvalitet proizvodaKarakteristike proizvoda koje određuju kvalitet zavise od toga

ko analizira softver

Korisnik

smatra da je softver kvalitetan ako radi na odgovarajući način, lako se uči i koristi.

Korisnik meri: tip i broj otkaza.

Projektant

razmatra interne karakteristike proizvoda i procenjuje nedostatke.

Projektant meri: broj nedostataka u zahtevima, projektu i kodu.

Modeli kvalitetadovode u vezu spoljni pogled korisnika i unutrašnji pogled programera na softver.


Boehm-ov model kvaliteta (1)

Po ovom modelu, kvalitetan softver je onaj koji:

radi ono što korisnik od njega traži,

ispravno i efikasno koristi računarske resurse,

jednostavan je za učenje i korišćenje,

dobro je projektovan, dobro kodiran i lako se testira i održava.

Boehm-ov model kvaliteta (Boehm i dr., 1978.) je jedan od najpoznatijih modela. On predstavlja hijerarhiju karakteristika od kojih svaka doprinosi ukupnom kvalitetu. U model su uključena očekivanja kako korisnika, tako i programera.


Opšta korisnost

Mogućnost održavanja

Osnovni naručilac

Prenosivost

Pouzdanost

Efikasnost

Ljudsko inženjerstvo

Mogućnost testiranja

Razumljivost

Mogućnost izmene

Nezavisnost od uređaja

Samosadrživost

Tačnost

Potpunost

Robustnost/integritet

Doslednost

Odgovornost

Efikasnost uređaja

Pristupačnost

Komunikativnost

Samoopisivost

Strukturisanost

Sažetost

Čitljivost

Proširivost

Boehm-ov model kvaliteta (2)


Kvalitet procesaKvalitet procesa razvoja softvera je jednako važan kao i kvalitet proizvoda. Ako neka od aktivnosti krene u pogrešnom smeru, to može da pogorša kvalitet proizvoda. Zbog toga se radi modelovanje postupka koje omogućava lakšu analizu postupka i nalaženje načina za njegovo poboljšanje.

Pitanja koja treba postaviti u procesu razvoja:

Gde i kada ćemo verovatno naći neku vrstu nedostatka?

Kako možemo što ranije da pronađemo nedostatke u procesu razvoja?

Kako možemo da ugradimo toleranciju na greške, da bi smanjili verovatnoću da nedostatak pređe u otkaz?

Da li postoje alternativne aktivnosti koje mogu da načine proces efikasnijim, uz osiguranje kvaliteta?


Kvalitet u kontekstu poslovanjaKvalitet sa aspekta poslovanja se posmatra u zavisnosti od proizvoda i usluga koje pruža poslovni sistem čiji je softver sastavni deo. Pri tome se analizira poslovna vrednost proizvoda.

Tehnička vrednost proizvoda

Poslovna vrednost proizvoda

Povratak investicije

Kraći put do kupca

Kvalitetproizvoda

Kvalitet procesa

Produktivnost

........


Učesnici u razvoju softvera

Kupac

KupacProjektant

Softverski sistem

Ima potrebu

Ima potre

buUgovorna obaveza

Kupac je kompanija, organizacija ili pojedinac koji finansira razvoj softverskog sistema.

Korisnik je jedan ili više pojedinaca koji će stvarno koristiti sistem.

Projektant je kompanija, organizacija ili pojedinac koji pravi softverski sistem za kupca.

Učesnici u projektu mogu istovremeno da imaju više uloga. Na primer, ako neki sektor u kompaniji razvija sam softver za svoje potrebe, on je istovremeno i kupac i korisnik i projektant.


Faze u razvoju softvera (1) Analiza i definisanje zahteva. U ovoj fazi se u saradnji sa kupcem utvrđuju zahtevi koji opisuju sistem. Pri njihovom definisanju uzimaju se u obzir entiteti, aktivnosti i ograničenja koja postoje u sistemu, kao i interakcija sistema sa okruženjem.

Projektovanje (dizajn) sistema.U cilju zadovoljenja definisanih zahteva, generiše se projekat sistema koji opisuje finkcionalnost sistema i njegov izgled sa stanovišta kupca. Projekat obično sadrži snimke ekrana, izveštaje koji će se generisati, interakciju sistema sa korisnikom, itd.

Projektovanje programa. Kada kupac odobri projekat sistema, generišu se pojedinačni podprojekti pogodni za programsku realizaciju.

Implementacija (pisanje) programa.


Faze u razvoju softvera (2) Testiranje modula. Nakon pisanja programa, najpre se testiraju individualni delovi koda, tj. pojedinačni moduli.

Testiranje integrisanog sistema. Moduli se povezuju u celinu i testira se da li moduli dobro rade u spezi sa drugim modulima.

Završno testiranje sistema. Proverava se da sistem služi svojoj nameni, tj. da li zadovoljava postavljene zahteve.

Isporuka sistema.

Održavanje. Tokom upotrebe sistema mogu se uočiti razni problemi koje treba rešavati.

Proces razvoja softvera je svaki opis razvoja softvera koji sadrži neke od nabrojanih faza, organizovanih tako da proizvode proveren kod.


Modeli procesa razvoja softvera (1)MODEL

PROCESA RAZVOJA

MODEL PROCESA RAZVOJA

ISPORUČENI PROIZVOD

ISPORUČENI PROIZVOD

SPECIFIKACIJA ZAHTEVA

SPECIFIKACIJA ZAHTEVA

Razlozi za modelovanje procesa

Kada grupa opiše primenjivani proces projektovanja, opis postaje zajedničko shvatanje aktivnosti, resursa i ograničenja uključenih u razvoj softvera.

Modelovanje pomaže u nalaženju nedoslednosti, viškova i izostavljenih elemenata u samom procesu, što poboljšava efikasnost procesa.

Model treba da odražava ciljeve razvoja. Nakon izrade modela projektni tim ocenjuje aktivnosti sa aspekta njihove usklađenosti sa postavljenim ciljevima.

Svaki proces mora biti napravljen prema situaciji u kojoj će se primenjivati. Modelovanje procesa pomaže da projektni tim utvrdi mesta na kojima su potreba prilagođavanja.


Modeli procesa razvoja softvera (2)

Kaskadni model (model vodopada)

V model

Fazni razvoj (inkrementalni i iterativni)

Prototipski model

Model specifikacije rada

Transformacioni model

Spiralni model

Agilne metode (ekstremno programiranje)


Kaskadni model (1)Kaskadni model ili model vodopada (Royce, 1970.) predstavlja veoma visok nivo apstrakcije razvojnog procesa čije su faze kaskadno prikazane.

PROJEKTOVANJEPROJEKTOVANJE

OPERATIVNI RAD

I ODRŽAVANJE

OPERATIVNI RAD

I ODRŽAVANJE

TESTIRANJETESTIRANJE

KODIRANJEKODIRANJE

ANALIZA ZAHTEVAANALIZA ZAHTEVA Osobine modela

Jedna faza razvoja treba da se u potpunosti okonča pre početka sledeće faze.

Za svaku aktivnost procesa definišu se kritične tačke i međuproizvodi, što olakšava praćenje stepena gotovosti projekta.


Kaskadni model (2)Prednosti modela

Jednostavnost koja olakšava pružanje objašnjenja kupcima.

Dobijanje pune funkcionalnosti sistema.

Eksplicitno ukazivanje na međuproizvode koji su neophodni za započinjanje sledeće faze.

Pogodan za slučaj kada je neophodno odjednom zameniti stari sistem.

Nedostaci modela

Ne odražava povratne sprege koje zbog grešaka i nepreciznosti zahteva postoje u stvarnosti.

Sistem je obično preveliki da se uradi u jednoj iteraciji.

Nije pogodan kod znatnih izmena zahteva.


V model (1)

PROJEKTOVANJE SISTEMA

PROJEKTOVANJE SISTEMA

KODIRANJEKODIRANJE

PROJEKTOVANJE PROGRAMA

PROJEKTOVANJE PROGRAMA

ANALIZA ZAHTEVAANALIZA ZAHTEVA

ZAVRŠNO TESTIRANJE

ZAVRŠNO TESTIRANJE

TESTIRANJE SISTEMA

TESTIRANJE SISTEMA

TESTIRANJE DELOVA I INTEGRACIJE

TESTIRANJE DELOVA I INTEGRACIJE

OPERATIVNI RAD I ODRŽAVANJE

OPERATIVNI RAD I ODRŽAVANJEValidacija zahteva

Verifikacija projekta

V model (nemačko Ministarstvo odbrane, 1992.) je modifikovani kaskadni model koji pokazuje odnos testiranja i faza analize i projektovanja, čineći eksplicitnim neke povratne sprege koje su skrivene u kaskadnom modelu.


V model (2)V model se prvenstveno bavi aktivnostima i ispravnim radom sistema, za razliku od kaskadnog modela koji je usredsređen na dokumente i međuproizvode.

Testiranje delova, testiranje sistema pri integraciji i testiranje sistema bave se ispravnošću programa i mogu se koristiti za verifikovanje dizajna programa.

Završni test služi za validaciju zahteva, tj. proveru da li su svi zahtevi potpuno implementirani.

Ako se pronađu problemi tokom verifikacije ili validacije, aktivnosti sa leve strane V modela mogu se ponoviti radi popravke i poboljšanja zahteva, dizajna ili koda, pre nego što se ponove testiranja na desnoj strani modela.

Kako se koristi V model?


Fazni razvoj (1)

Izrada verzije 1 Izrada verzije 2 Izrada verzije 3

Upotreba verzije 1 Upotreba verzije 2 Upotreba verzije 3

Razvojni sistemi

Produkcioni sistemi

PR

OJE

KT

NI

TIM

KO

RIS

NIC

I

Vreme

Fazni razvoj je način projektovanja softvera koji omogućava isporučivanje sistema u delovima, tako da je korisnicima na raspolaganju jedan deo funkcija, dok je ostatak funkcija još u razvoju. Zato obično postoje dva sistema koji uporedo funkcionišu: produkcioni i razvojni sistem.

Produkcioni sistem je onaj koji trenutno koriste naručilac i korisnik. Razvojni sistem predstavlja sledeću verziju koja se priprema da zameni postojeći produkcioni sistem. Sistemi se obično nazivaju prema rednom broju njihove verzije. Tako, projektni tim uvek radi na verziji n+1, dok je verzija n u fazi operativnog korišćenja.


Fazni razvoj (2)Inkrementalni razvoj podrazumeva da se sistem u skladu sa specifikacijom zahteva deli na podsisteme prema funkcijama. Verzije se definišu kao funkcionalni podsistemi, tako da se svakoj novoj verziji priključuju nove funkcije. Sistem se nadograđuje do potpune funkcionalnosti.

Iterativni razvoj takođe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se potpun sistem isporučuje u svim verzijama, s tim što se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledeća verzija unapređuje prethodnu.


Fazni razvoj (3)Pogodnosti iterativnog razvoja

Obuka može da počne sa prvom verzijom, što je dobro, jer praćenje izvršavanja nekih funkcija može da sugeriše poboljšanja u kasnijim verzijama.

Na tržište može da se izađe vrlo rano, ako se radi o funkcionalnostima koje nikada ranije nisu bile nuđene.

Česte verzije omogućavaju brzo otkanjanje nepredviđenih problema.

Projektni tim može da se usredsredi na različite oblasti usavršavanja u različitim verzijama (na pr. korisnički interfejs, performanse sistema itd.).

Pogodnosti inkrementalnog razvoja

Operativni podskup funkcija po zahtevima korisnika može biti vrlo brzo isporučen.

Projektni tim može da ima relativno mali broj ljudi.

Progres na projektu je vidljiv (nije samo u okviru dokumenata).

Mogućnost odziva od strane korisnika kroz ceo ciklus razvoja vodi ka stabilnijim međurezultatima i sistemu uopšte.


Prototipski model (1)

PROTOTIPSKI ZAHTEVI

PROTOTIPSKI ZAHTEVI

PROTOTIPSKI PROJEKAT

PROTOTIPSKI PROJEKAT

PROTOTIPSKI SISTEM

PROTOTIPSKI SISTEM TESTTEST

LISTA REVIZIJA

LISTA REVIZIJA

LISTA REVIZIJA

ZAHTEVI SISTEMA(nekada neformalni ili nekompletni)

ISPORUČENI SISTEM

revizija prototipa

pogled korisnika ili naručioca

Prototipski model se zasniva na izradi prototipova. Ovaj model omogućava da se kompletan sistem ili delovi sistema brzo konstruišu radi razjašnjenja ili boljeg razumevanja otvorenih pitanja, sve sa ciljem smanjenja rizika i neodređenosti prilikom projektovanja sistema.

Prototip je delimično razvijen proizvod koji omogućava naručiocima i projektantima da ispitaju neke aspekte predloženog sistema i odluče da li je on pogodan i potreban u sklopu gotovog proizvoda.


Prototipski model (2)

Definisanje skupa zahteva od strane naručioca i korisnika.

Ispitivanje alternativa (analize mogućih ekrana, tabela i dr. izlaza iz sistema).

Revizija zahteva prema željama naručioca i korisnika.

Prelazak na fazu projektovanja.

Istraživanje varijanti u projektovanju.

Revidiranje inicialnog dizajna dok svi učesnici ne budu zadovoljni.

Ako se pri razmatranju varijanti dizajna naiđe na probleme koji potiču od zahteva, vraća se na ponovnu specifikaciju zahteva.

Kodiranje sistema uz razmatranje varijanti sa mogućim iteracijama kroz zahteve i dizajn.

SISTEMSISTEM

REVIZIJA REVIZIJAREVIZIJA

TESTTESTPROJEKATPROJEKATZAHTEVIZAHTEVIZAHTEVISISTEMA

ISPORUČENISISTEM

PR

IME

R R

AZ

VO

JA S

IST

EM

A


Model specifikacije rada (Zave, 1984.) omogućava projektnom timu i naručiocu da u ranim fazama projektovanja ispitaju zahteve sistema i njihove implikacije, i po potrebi ih koriguju. Zahtevi se pre početka projektovanja ocenjuju ili izvršavaju na način koji pokazuje prirodu sistema, koristeći programske pakete. Tako se izbegavaju problemi u kasnijim fazama koji mogu da nastanu usled neodređenosti vezane za zahteve sistema. Ovaj model, za razliku od tradicionalnih modela, objedinjuje funkcionalnost i dizajn i time spaja potrebe naručioca sa implementacijom.

Model specifikacije rada

SPECIFIKACIJA RADA

(orijentisana ka problemu)

SPECIFIKACIJA RADA

(orijentisana ka problemu)

Izvršiti i revidirati

ZAHTEVI SISTEMA ISPORUČENI SISTEM

TESTTESTTRANSFORMISANA

SPECIFIKACIJA (orijentisana ka implementaciji)

TRANSFORMISANA SPECIFIKACIJA

(orijentisana ka implementaciji)


Transformacioni model

FORMALNA SPECIFIKACIJA

FORMALNA SPECIFIKACIJA

Poređenje sa zahtevima;

ažurirati ako je potrebno

ZAHTEVI SISTEMA ISPORUČENI SISTEM

TESTTEST

TRANSFORMACIJA NTRANSFORMACIJA N

TRANSFORMACIJA 2TRANSFORMACIJA 2

TRANSFORMACIJA 1TRANSFORMACIJA 1

.........

FORMALNI ZAPIS O RAZVOJU

Niz transformacija sa obrazloženjima

Transformacioni model (Balzer, 1981.) pokušava da redukuje mogućnost greške primenom niza transformacija kojima se specifikacija zahteva pretvara u sistem koji može da se isporuči. Sekvence transformacija i odluka se čuvaju kao formalni zapis u okviru dizajna.

Transformacioni model veoma mnogo obećava. Glavna smetnja da bude šire prihvaćen je neophodnost formalne specifikacije da bi transformacije mogle nad njom da se izvršavaju.


Spiralni model (1)Spiralni model (Boehm, 1988.) posmatra razvoj softvera u svetlu prisutnih rizika tako što kombinuje aktivnosti razvoja sa upravljanjem rizicima. Na taj način se postižu manji rizici, a i njihova kontrola je olakšana.

Po spiralnom modelu, proces razvoja softvera se odvija u 4 iteracije:

1. Opis funkcionisanja sistema na visokom nivou apstrakcije

2. Definisanje skupa zahteva

3. Generisanje dizajna sistema

4. Testiranje

Zahtevi i plan razvoja

Validacija i verifikacija dizajna

Validacija zahteva

Dokument “Principi rada”

Testiranje

U svakoj iteraciji, radi se analiza rizika koja identifikuje rizike i određuje različite varijante sa aspekta zahteva i ograničenja za njihovo minimiziranje. Zatim se izradom prototipova verifikuju izvodljivost i pogodnost varijanti pre nego što se odabere odgovarajuća.


Spiralni model (2)

start

Određivanje ciljeva, varijanti i ograničenja

Ocenjivanje varijanti i rizika

Plan Razvoj i testiranje

Varija

nte

2

Varijante 1

Varija

nte

3

Varija

nte

4

Organičenja 4

Organičenja 3

Organičenja 2

Organičenja 1

Analiza rizika 4

Analiza rizika 3

Analiza rizika 2

Analiza riz

ika 1

Prototip 3

Prototip 4Prototip 2Prototip 1

Plan integracije i testiranje

Plan implementacije

Plan razvoja

Pricipi rada

Zahtevi, plan razvoja

Zahtevi pre

ma

softv

eru

Validacija

zahtevaDiza

jn softv

era

Validacija i

verifikacija dizajna

Det

aljn

i diz

ajn

Kodiranje

Testiranje


Agilne metode (1)Agilne metode (Agile Alliance, 2001.) su nastale kao otpor mnogim ranijim modelima razvojnog procesa koji su pokušavali da nametnu neki oblik discipline vezane za osmišljavanje softvera, dokumentovanje, razvoj i testiranje. Ideja je da se naglasi uloga fleksibilnosti u spretnom brzom razvoju softvera.

4 principa agilnog razvoja

Za uspešnost projekta najvažniji su kvalitet ljudi koji na njemu rade i kvalitet njihove saradnje. Postupci i alati imaju sporedni značaj.

Bolje je uložiti vreme u izradu softvera koji radi, nego u izradu sveobuhvatne dokumentacije.

Zajednički rad sa naručiocem je vrlo važan, jer se tako naručilac uključuje u ključne aspekte razvoja.

Umesto planiranja i praćenja plana, važnije je odgovarati na promene, jer se ne mogu svi zahtevi predvideti na početku razvoja.


Agilne metode (2)Primeri agilnih procesa

Ekstremno programiranje, XP (eXtreme Programming), (Beck, 1999.) predstavlja skup tehnika za omogućavanje kreativnosti projektnog tima uz minimizovanje prekomernog administriranja. Crystal (Cockburn, 2002.) predstavlja skup pristupa zasnovanih na činjenici da svaki projekat zahteva različit skup dogovora i metodologija. Stoga je najvažnije naći način za jednostavnu i kompaktnu organizaciju projektnog tima kako bi razvojni proces bio brži i efikasniji. Scrum (Object Technology, Schwaber & Bedle, 2002.) je model koji se zasniva na iterativnom razvoju, gde se svaka 30-dnevna iteracija naziva “sprint”, a služi za implementiranje zaostalih zahteva najvišeg prioriteta. Više samoorganizovanih i autonomnih timova paralelno implementira delove proizvoda. Koordinacija se vrši na kratkim dnevnim sastancima (scrum). Adaptivni razvoj softvera, ASD (Adaptive Software Development) (Highsmith & Bayer, 2000.) se zasniva na šest osnovnih principa: fokusiranju tj. postavljanju ciljeva, opisu na bazi svojstava, iterativnosti, poštovanju utvrđenog vremena isporuke, prihvatanju rizika i tretiranju izmena kao prilagođavanje sistema, a ne kao grešaka.


Ekstremno programiranje (1)

Karakteristike agilnosti

Jednostavnost

Komunikacija podrazumeva neprestanu razmenu informacija između naručioca i projektnog tima.

Odvažnost

Povratnasprega

Komunikacija

Povratne sprege se ugrađuju u različite aktivnosti tokom procesa razvoja.

Jednostavnost ohrabruje projektni tim da odabere najjednostavniji dizajn ili implementaciju koji odgovaraju potrebama naručioca.

Odvažnost je posvećenost blagovremenim i čestim isporukama funkcija.


Ekstremno programiranje (2)F

akto

ri X

P-a

Igra planiranja. Generišu se mape svih budućih verzija (šta sadrže i rokovi isporuke).

Male verzije. Funkcije su dekomponovane na male delove koji se isporučuju, a zatim proširuju. Koriste se inkrementalni i iterativni ciklusi.

Metafora. Pojektni tim se usaglašava oko zajedničke vizije rada sistema.

Jednostavan dizajn.Tretiraju se samo aktuelne potrebe.

Testovi pre kodiranja. Funkcionalne testove definiše naručilac, a izvršava tim. Testove delova realizuje tim radi verifikacije.

Prerađivanje koda. Promena zahteva primorava tim da preispita postojeća rešenja. Ovo je najveći problem.

Kolektivna svojina. Svaki učesnik može da izmeni bilo koji deo sistema, dok je on u fazi razvoja.

Neprekidna integracija. Rade se dnevne ili satne isporuke. Naglasak na malim inkrementima poboljšanja.

Održiv korak. Umorni ljudi više greše. Sugeriše se 40 sati nedeljno rada. Ako to nije dovoljno, nešto nije u redu (rokovi ili resursi).

Naručilac raspoloživ na terenu.

Standardi kodiranja. Insistira se na njima zbog boljeg razumevanja u timu.

Programiranje u paru.


Alati i tehnike za modelovanjeIzbor alata i tehnika za modelovanje zavisi od sadržaja modela. Postoje različite vrste notacija koje se mogu koristiti:

tekstualne, u kojima se procesi iskazuju kao funkcije, grafičke, u kojima se procesi prikazuju u formi hijerarhije pravougaonika i strelica, kombinovane, koje kombinuju slike, tekst i grafički prikaz sa tabelama.

Poželjne osobine alata i tehnika za modelovanje (Curtis, Kellner & Over, 1992.):

1. Da ljudima olakšaju razumevanje i međusobnu komunikaciju.2. Da pruže podršku poboljšanju procesa. Tehnika treba da identifikuje komponente razvoja i

održavanja, omogući višekratnu upotrebljivost procesa i podprocesa, kao i poređenje alternativa.

3. Da pruže podršku upravljanju procesom. Tehnika treba da omogući planiranje i prognoziranje, nadgledanje i upravljanje procesom, kao i merenje ključnih karakteristika procesa.

4. Da obezbede automatsko vođenje tokom izvršavanja procesa. Tehnika treba da definiše okruženje za razvoj softvera, obezbedi smernice i sugestije i sačuva višekratno upotrebljive reprezentacije procesa za kasniju upotrebu.

5. Da pruže podršku automatskom izvršavanju procesa. Tehnika treba da automatizuje proces u celosti ili delimično.

aplikativni softver

Documents