Professional Documents
Culture Documents
Primeri problema:
Funkcionalni zahtevi (nekada se zovu sposobnosti) opisuju funkciju koji softver treba da
izvrši (npr. modulacija signala ili formatiranje teksta). Funkcionalni zahtevi preciziraju
ponašanja ili funkcije. Nefunkcionalni zahtevi preciziraju kriterijume koji se koriste za
procenu funkcionisanja sistema. Nefunkcionalni zahtevi nekada se nazivaju i atributi
kvaliteta, ciljevi kvaliteta, kvalitet servisnih zahteva i sl. Kao primer može se uzeti prikaz
broj zapisa u bazi (funkcionalni) i prikaz u realnom vremenu, ili do nekog perioda
(nefunkcionalni).
Requirements Process
Cilj ove podoblasti je razumevanje procesa uzimanja zahteva. Aktivnost koja nije u
prvom planu razvoja softvera, ali jeste proces koji se inicira na početku projekta i
usavršava tokom životnog ciklusa. Identifikacija softverskih zahteva kao konfiguracionih
stavki i njihovo upravljanje pomoću software configuration management veština, kao i
ostalih proizvoda procesa životnog ciklusa softvera. Treba da se prilagode organizaciji i
kontekstu projekta.
Software Quality
Software Engineering Process
REFERENCE:
A.M. Davis, Software Requirements: Objects, Functions and States, Prentice Hall,
1993.
J. Goguen and C. Linde, Techniques for Requirements Elicitation, presented at
International Symposium on Requirements Engineering, 1993.
IEEE Recommended Practice for Software Requirements Specifications, IEEE,
1998.
Information Technology, Software Measurement, Functional Size Measurement,
Part 1: Definitions of Concepts, IEEE, 2000.
G. Kotonya and I. Sommerville, Requirements Engineering: Processes and
Techniques, John Wiley & Sons, 2000.
P. Loucopulos and V. Karakostas, Systems Requirements Engineering, McGraw-
Hill, 1995.
S.L. Pfleeger, Software Engineering: Theory and Practice, second ed., Prentice
Hall, 2001,
S. Robertson and J. Robertson, Mastering the Requirements Process, Addison-
Wesley, 1999.
I. Sommerville and P. Sawyer, Requirements Engineering: A Good Practice
Guide, John Wiley & Sons, 1997, Chap. 1-2.
I. Sommerville, Software Engineering, seventh ed., Addison-Wesley, 2005.
R.H. Thayer and M. Dorfman, eds., Software Requirements Engineering, IEEE
Computer Society Press, 1997, pp. 176-205, 389-404.
R.R. You, Effective Requirements Practices, Addison-Wesley, 2001.
Software Design igra važnu ulogu u razvoju softvera, dozvoljavajući softver inženjerima
da proizvedu različite modele koji formiraju neku vrstu nacrta za rešenje koje se
implementira. Možemo analizirati i evaluirati ove modele da bismo utvrdili da li nam
mogu ili ne mogu pomoći da ispunimo različite zahteve. Možemo ispitati i evaluirati
različita alternativna rešenja i trade-offs.
Prema dokumentu IEEE/EIA 12207 Software Life Cycle Processes, software design se
sastoji iz dve aktivnosti koje spadaju između software requirements analysis i software
construction:
Software architectural design (nekada se naziva i top-level design), opisuje
softversku top level arhitekturu i organizaciju i identifikovanje različitih
komponenti
Software detailed design, opisuje svaku komponentu u dovoljnoj meri za početak
njenog konstruisanja
Posmatrajući opseg oblasti Software Design, postojeći opis oblasti ne obuhvata svaku
temu koja sadrži reč dizajn. Ova oblast bavi se prevashodno sa D-designom (dizajn
dekompozicije, preslikavanje softvera u komponent delove). S obzirom na konstantno
rastuće polje softverske arhitekture, postoji i FP-design (family pattern design) čiji je cilj
uspostavljanje iskoristive unificiranosti u porodici softvera.
Suprotno tome, oblast Software Design ne adresira I-design (invention design), koji se
obično sprovodi tokom software requirements procesa sa ciljem konceptualizacije i
specificiranja softvera koji treba da zadovolji uočene potrebe i zahteve. Oblast Software
Design se posebno oslanja na Software Requirements, Software Construction, Software
Engineering Management i Software Quality.
Softver nije jedino polje koje uključuje dizajn. Posmatramo dizajn kao formu za
rešavanje problema, gde postoje i limiti dizajna. U tom smislu govorimo i o generalnim
konceptima dizajna, ciljevima, ograničenjim, alternativama, i rešenjima.
1. Architectural design
o opisuje kako je softver dekomponovan i organizovan u komponente
(software architecture)
2. Detailed design
o opisuje specifično ponašanje ovih komponenti
o izlaz iz ovog procesa je skup modela i artifakata koji odslikavaju
o osnovne odluke koje su donete
Enabling Techniques
1. Apstrakcija (Abstraction)
Coupling (sprezanje) se definiše kao jačina relacija između modula. Cohesion (spajanje)
definiše kako su povezani elementi koji čine modul.
4. Encapsulation/information hiding
Postoji nekoliko ključnih tema koje treba uzeti u obzir prilikom dizajniranja softvera.
Jedna od njih je obezbeđivanje kvaliteta (performance). Druga važna stvar je kako
dekomponovati, organizovati i pakovati softverske komponenete. Svaki dizajnerski
pristup mora uzeti u obzir ove fundamente na jedan ili drugi način.
Nasuprot tome, druge teme se bave nekim aspektima ponašanja softvera koje nije u
domenu aplikacija. Takve teme koje obično daju poprečni presek funkcionalnosti
sistema, tretiraju se kao aspekti (teže da ne budu jedinica softverske funkcionalne
dekompozicije, već osobina koja utiče na performance ili semantiku komponenti na
sistematičan način). Neke od ovih ključnih tema su date u nastavku u abecednom redu.
Konkurentnost (Concurrency)
Data Persistence
Software design je multi-aspektni artifakt nastao kao rezultat dizajn procesa i generalno
sastavljen iz relativno nezavisnih i ortogonalnih pogleda.
Architectural Styles (macroarchitectural patterns)
Arhitektonski stil je skup ograničenja na arhitekturi koji definišu skup ili familiju
arhitektura koje ih zadovoljavaju. Arhitektonski stil se stoga može posmatrati kao meta
model koji može obezbediti high-level organizaciju softvera (makroarhitektura). Kao što
zgrade odražavaju određeni arhitektonski stil, tako postoje i stilovi arhitekture softvera.
Različiti autori su identifikovali više vrsta glavnih arhitektonskih stilova:
REFERENCE:
Priroda dizajna
Specifikacija zahteva definiše problem, rešenje problema dolazi kao zadovoljavanje svih
zahteva i specifikacija. U mnogim slučajevima je broj rešenja neograničen. Naručilac
može da bira među ponuđenim varijantama i odluči da primeni jedno od više mogućih
rešenja. Priroda rešenja može da se menja i u toku opisa ili implementacije. Npr. kada
arhitekta pokaže jedan skup nacrta naručiocu, oni mogu da dopune specifikacije.
Iterativnost dizajna
Proces je iterativan zato što dizajneri naizmenično rade na analizi zahteva, predlaganju
mogućih rešenja, testiranju izvodljivosti svih aspekata rešenja, prikazivanju mogućnosti
klijentima i dokumentovanju dizajna za razvojni tim.
Slika 1. Prikaz konceptulanog i tehničkog dizajna
Nekada se dizajn opisuje u jednom dokumentu, ali često postoje dva kao što je prikazano
na prethodnoj slici. Oba dizajnerska dokumenta opisuju isti sistem, ali na različite načine
zbog toga što su dokumenti namenjeni različitim korisnicima.
Konceptualni dizajn omogućava klijentu da shvati šta će sistem raditi tako što objašnjava
vidljive spoljašnje karakteristike sistema. Tehnički dizajn opisuje konfiguraciju hardvera,
softverske potrebe, komunikacione interfejse, ulaze u sistem i njegove izlaze, mrežnu
arhitekturu i sve ostalo čime se zahtevi prevode u rešenje klijentovog problema.
Ilustracija pomenutih razlika data je na sledećoj slici:
Dekompozicija i modularnost
Kažemo da je komponenta dobro definisana ako su svi njeni ulazi bitni za njenu funkciju,
a sve izlaze proizvodi neka od njenih akcija. To znači da ako nedostaje jedan ulaz,
komponenta nije u stanju da obavi svoju funkciju u celosti. Osim toga, izraz „dobro
definisana" znači da ne postoje nepotrebni ulazi, svi ulazi se koriste za generisanje izlaza.
Komponenta je dobro definisana samo kada je svaki izlaz rezultat rada komponente i
kada nijedan ulaz ne postaje izlaz, a da nije na neki način transformisan u komponenti.
1. Modularna dekompozicija
Ovaj dizajn se zasniva na spoljašnjim strukturama podataka, opšti opis prikazuje globalnu
strukturu podataka, a detaljni opisi navode koji će elementi podataka biti obuhvaćeni i
kakve su njihove međusobne veze.
Ovaj dizajn se zasniva na događajima koje sistem mora da obradi i koristi informacije o
tome kako događaji menjaju stanje sistema. Opšti opis sadrži spisak različitih stanja, a
detaljan opis navodi kako dolazi do transformacija stanja.
Ovaj pristup „crne kutije" zasniva se na onome što korisnik unosi u sistem. Opšti opis
navodi šta sve korisnik može da unese, a detaljni opisi opisuju šta će sistem uraditi sa
svakim od unetih elemenata (kao i dobijene rezultate).
Ovaj dizajn definiše klase objekata i njihove međusobne veze. Na najopštijem nivou
opisuju se tipovi objekata. Na detaljnijim nivoima se opisuju atributi objekata i akcije, a
dizajn objašnjava međusobne veze objekata
Shaw i Garlan (1996) predlažu da softverska arhitektura bude prvi korak u dizajnu
softvera. Oni razlikuju tri nivoa dizajna:
1. Arhitektura - povezuje sposobnosti sistema navedene u specifikaciji zahteva sa
sistemskim komponentama koje će ih implementirati. Komponente su obično
moduli, a arhitektura opisuje njihove međusobne veze
2. Dizajn koda - obuhvata algoritme i strukture podataka, a komponente su elementi
programskog jezika, kao što su pokazivači i dr. Tu su takođe elementarni
operatori uključujući osnovne jezičke primitive za aritmetiku i manipulaciju
podacima, kao i mehanizmi za kompoziciju kao što su matrice, datoteke i
procedure
3. Izvršni dizajn - još detaljnije izlaže dizajn koda. On opisuje dodelu memorije,
formate podataka, šablone bitova i dr.
Postepenost arhitekture
Nekada tek tokom razvoja sistema shvataju se sve nijanse problema. Npr. dizajneri
odluče da bi sistemom trebalo upravljati pomoću jednog tipa podataka, međutim, dok
prave prototip nekih funkcija, dolaze do zaključka da bi dizajn bio brži uz upotrebu
drugog tipa podataka i sl. Slično tome, dok dizajneri istražuju druge aspekte sistema,
mogu u komunikaciji sa programerima ili test inženjerima da promene dizajn kako bi
unapredili implementaciju, mogućnosti testiranja ili održavanje. Ove iteracije znače da
dizajneri moraju postepeno da rade na arhitekturi, na dizajnu koda i na izvršnom dizajnu
onoliko koliko im to dozvoljavaju njihovo razumevanje i kreativnost. Važno je da
arhitektura obezbedi kohezivnu opštu sliku za usmeravanje daljeg dizajna i razvoja, a
naizmeničan rad na komponentama dizajna ne sme tu kohezivnost da naruši.
Pored toga što se neki detalji dizajna izvršavaju pre konstrukcije, mnogo dizajnerskog
posla se izvršava unutar aktivnosti konstrukcije takođe. Zbog toga je oblast Software
Construction tesno vezana sa oblasti Software Design. Kroz konstrukciju, softver
inženjeri sprovode testiranje jedinice i integralni test, pa kažemo da je zbog toga oblast
Software Construction tesno vezana i sa oblašću Software Testing. Software Construction
tipično proizvodi veliki broj konfiguracionih stavki, kojima je potrebno upravljati u
softverskom projektu (source files, content, test cases, itd...), pa je oblast Software
Construction tesno povezana i sa oblašću Software Configuration Management.
Pošto se Software Construction jako oslanja na alate i metode i predstavlja verovatno
najveću tool-intensive oblast u SI, kažemo da je vezana i Software Engineering Tools and
Methods. Kvalitet softvera je važan u svim oblastima SI, ali zbog posebne važnosti
kvaliteta koda, Software Quality je takođe vezan sa Software Construction. Među svim
drugim disciplinama Software Engineering-a, Software Construction je naviše blizak
računarskim naukama, pošto se oslanja na platformu, algoritamsko znanje, detaljne kodne
prakse i dr.
Minimizing complexity
Anticipating change
Constructing for verification
Standards in construction
Constructing for verification znači izgradnju softvera na takav način da greške i nedostaci
mogu biti brzo otklonjeni, kao i tokom nezavisnih testiranja i operacionih aktivnosti.
Postojanje verifikacije funkcioniše kao i kod drugih oblasti. Specifične tehnike koje
podržavaju konstrukciju za verifikaciju uključuju standarde kodiranja.
Tehnike podrške za pripremu pregleda koda i testiranja jedinice. Kod treba organizavati u
cilju podrške automatizovanom testiranju. Restriktivna je upotreba kompleksnih i
jezičkih struktura teških za razumevanje.
Programski jezici (jezički standardi za jezike kao što su npr. Java ili C++)
Platforme (npr. programerski interfejs standardi za pozive operativnog sistema)
Alati (npr. standardi za notacije kao što je UML (Unified Modeling Language))
REFERENCE:
Transformacioni model
U ranim godinama razvoja softvera naručioci su bili spremni da duže čekaju na završetak
razvoja softverskih sistema. Vreme izbacivanja na tržište nije bilo toliko kratko kao
danas. Nekada su prolazile godine od trenutka kada su dokumenti sa zahtevima bili pisani
do trenutka kada je sistem isporučivan, što je nazivano trajanje ciklusa. Današnja
poslovna okruženja više ne tolerišu duga kašnjenja, a naručioci uvek traže nov kvalitet i
funkcionalnost. Npr. u 1996. godini, 80% prihoda Hewlett-Packarda dobijeno je od
proizvoda uvedenih u prethodne dve godine. Uvek se radi na razvijanju novih modela
procesa koji treba da pomognu da se smanji trajanje ciklusa.
Fazni razvoj
Jedan način za smanjenje vremena trajanja ciklusa je upotreba faznog razvoja. Sistem se
projektuje tako da može da se isporučuje u delovima, omogućavajući korisnicima da
imaju neku funkcionalnost dok je ostatak još u razvoju. Tako postoje dva sistema koja
uporedo funkcionišu: produkcioni sistem i razvojni sistem, kao što se vidi na slici.
Produkcioni sistem je onaj koji trenutno koriste naručilac i korisnik. Razvojni sistem
predstavlja sledeću verziju koja se priprema da zameni aktuelni produkcioni sistem.
Često se označavaju sistemi zavisno od rednog broja njihove verzije (izdanja): razvojni
tim gradi Verziju 1, testira je, a zatim predaje korisnicima kao prvu produkcionu verziju.
Zatim, dok korisnici koriste Verziju 1, projektni tim gradi Verziju 2. Projektni tim uvek
radi na Verziji n + 1, dok je Verzija n u fazi operativnog korišćenja.
Inkrementalni razvoj i iterativni razvoj
Postoje mnogi načini da projektni tim odluči kako da organizuje razvoj u okviru
pojedinih verzija. Dva najpopularnija pristupa su inkrementalni razvoj i iterativni razvoj,
što je prikazano na slici. Kod inkrementalnog razvoja sistem, kako je specifikovan u
specifikaciji zahteva, podeljen je na podsisteme prema funkcionalnosti. Verzije su
definisane na samom početku u vidu jednog malog, funkcionalnog podsistema, a zatim se
nove funkcionalnosti uključuju u svaku novu verziju. Inkrementalnim razvojem se sa
svakim novim izdanjem sistem dograđuje, sve do potpune funkcionalnosti. Iterativni
razvoj isporučuje potpun sistem na samom početku, a zatim vrši izmene funkcionalnosti
svakog podsistema, u svakoj novoj verziji.
Razlike između inkrementalnog i iterativnog razvoja
na tržište može da se izađe vrlo rano, ako se radi o funkcionalnostima koje nikada
ranije nisu bile nuđene
obuka može da započne sa ranom verzijom, čak i ako neke funkcije nedostaju
proces obuke omogućava projektnom timu da posmatra kako se izvršavaju neke
funkcije, i time sugeriše poboljšanja u kasnijim verzijama
projektni tim je otvoren za pitanja korisnika
česte verzije omogućavaju projektnom timu da brzo otkloni nepredviđene
probleme
projektni tim može da se fokusira na različite oblasti usavršavanja u različitim
verzijama
Spiralni model
Agilne metode
Scrum
Ekstremno programiranje (XP)
Agilne metode
Mnogi modeli procesa razvoja softvera koji su predloženi i korišćeni u periodu od 1970-
ih do 1990-ih pokušavali su da nametnu neki oblik discipline vezane za način na koji se
softver osmišljava, dokumentuje, razvija i testira. Kasnih 1990-ih, grupa projektanata koji
su se protivili toj disciplini, formulisala je sopstvene principe, pokušavajući da naglasi
uloge koje fleksibilnost može da igra u spretnom brzom razvoju softvera. Oni su sveli
svoja razmišljanja u „agilnom manifestu”, koji se fokusira na četiri principa alternativnog
načina razmišljanja o procesu razvoja softvera (Agile Alliance 2001).
Softver razvijen tokom jedne jedinice vremena predstavlja iteraciju, što je obično od 1 do
4 nedelje. Svaka iteracija je kompletan softverski projekat, uključujući zahteve, dizajn,
kodiranje, testiranje i dokumentaciju. Iteracija možda neće imati dovoljno
funkcionalnosti, ali je cilj imati raspoloživo izdanje, bez bugova, na kraju svake iteracije.
Nakon svake iteracije tim radi re-evaluaciju projekta.
Drugim rečima, primarno merilo uspeha i napredovanja je softver koji radi ispravno.
Usredsređivanje na zajednički rad sa naručiocem, umesto na proces ugovaranja, čime se
naručilac uključuje u ključne aspekte procesa razvoja. Fokusiranje na odgovore na
promene, umesto na planiranje i praćenje plana, jer veruju da je nemoguće da se svi
zahtevi predvide na početku procesa razvoja.
Scrum
Ekstremno programiranje, XP
Programiranje u paru
Igra planiranja
Naručilac definiše šta se podrazumeva pod pojmom „vrednost”, tako da se svaki zahtev
može oceniti prema količini vrednosti koju njegova implementacija unosi u sistem.
Korisnici pišu scenarije o tome kako bi sistem trebalo da radi, a projektni tim procenjuje
neophodne resurse za realizaciju tih scenarija. Svaki scenario odnosi se na jedan zahtev:
da se razvojnom timu dovoljno detaljno objasne vrednosti zahteva, radi procene resursa
potrebnih za implementiranje zahteva. Nakon pisanja scenarija, potencijalni korisnici
dodeljuju prioritete zahtevima, razdvajaju ih i spajaju, sve dok se ne postigne konsenzus
o tome šta je stvarno potrebno, kao i šta može da se uradi sa raspoloživim resursima.
Whole team
U idealnom slučaju, naručilac bi trebalo da bude uvek raspoloživ, tj. trebalo bi da radi sa
razvojnim timom na definisanju zahteva. Sa stanovišta XP-a kupac nije onaj koji plaća
račun, već onaj ko zaista koristi sistem. Prema XP-u kupac mora uvek biti pri ruci za sve
vreme i dostupan za pitanja. Npr. tim koji razvija sistem za finansijsku administraciju
treba da uključi finansijskog administratora.
Neprekidna integracija
Male verzije
Standardi kodiranja
Mnogi posmatrači posmatraju XP i druge agilne metode kao okruženje bez ikakvih
ograničenja gde je sve moguće. Međutim, XP u stvari zastupa jasnu definiciju standarda
kodiranja, sa ciljem da se članovi tima osposobe za razumevanje neophodne izmene u
produktima rada drugih članova tima. Ti standardi podržavaju i ostali praktičan rad, kao
što je testiranje i prerađivanje koda. Rezultat treba da bude kod koji izgleda kao da ga je
pisala jedna osoba, konzistentan sa aspekta pristupa i izražavanja.
Kolektivna svojina
U XP-u svaki učesnik u razvoju može da načini izmenu u bilo kom delu sistema dok je
on u fazi razvoja. Postoje teškoće upravljanja promenama, uključujući greške koje se
generišu kada dve osobe pokušavaju da istovremeno izmene isti modul.
Jednostavan dizajn
Dizajn se održava jednostavnim tako što se tretiraju jedino aktuelne potrebe. Ovaj pristup
se zasniva na stanovištu da predviđanje potencijalnih budućih potreba dovodi do
nepotrebnih funkcija.
Metafora
Kao dodatak, teme kao što su organizacija i odgovornost, resursi i rasporedi, izbor alatki i
implementacija i kontrola interface-a se tipično predmet razmatranja. Rezultati aktivnosti
planiranja su zapisani SCM planu (SCMP), koji je tipičan primer tema razmatranja i za
SQA.
Specifične odgovornosti za datu SCM aktivnost moraju se postaviti na nivou funkcije ili
organizacionog elementa. Mora se definisati sveobuhvatno nadgledanje i kanali
izveštavanja (što se takođe definiše i kod projektnog menadžmenta ili faze osiguranja
kvaliteta). Planiranje za SCM identifikuje osoblje i alate uključene u sprovođenju SCM
aktivnosti i zadataka. Razmatraju se pitanja rasporeda preko uspostavljanja neophodnih
sekvenci SCM aktivnosti i identifikovanja njihovih odnosa sa rasporedom kompletnog
projekta. Podrazumevaju se obuke za implementaciju planova i obuke za nove zaposlene.
Softverski projekat može koristiti naručene softverske proizvode (npr. kontrole). SCM
planiranje uključuje kako se ove komponente stavljaju pod konfiguracionu kontrolu i
kako promene ili nadogradnje mogu biti evaluirane i rukovane. Zahteva se uspostavljanje
praćenja prilagodljivosti (nove verzije). Kada se jedan softver item uklapa sa drugim,
promene na jednom utiču na drugi item. Planiranje SCM aktivnosti podrazumeva kako se
dva vezana item-a identifikuju i kako se promenama upravlja.
SCM plan
Rezultat SCM planiranja za dati projekat snimaju se u SCM plan (SCMP), aktivnom
dokumentu koji služi kao referenca u SCM procesu. Plan se održava, unapređuje i
odobrava po potrebi tokom životnog ciklusa softvera. U implementaciji SCMP-a
uobičajeno je neophodno razviti određen broj detaljnih procedura definišući tako kako će
specifični zahtevi biti izvedeni tokom višednevnih aktivnosti.
Nadgledanje SCM
Nakon što se SCM proces primeni, određen stepen nadgledanja mora da se obezbedi radi
sigurnosti da će odredbe SCMP-a da se pravilno izvedu. Najverovatnije postoje specifični
SQA zahtevi radi osiguranja poklapanja sa specifičnim SCM procesima i procedurama.
SCM merenja mogu biti dizajnirana radi obezbeđenja specifičnih informacija o proizvodu
ili pružanja pogleda na unutrašnjost funkcionisanja SCM procesa. Cilj monitoringa SCM
procesa je otkrivanje mogućnosti za unapređenja procesa. Npr. informacija o vremenu
potrebnom radi ostvarivanja različitih tipova promena mogu biti korisne u evaluaciji
kriterijuma za određivanje koji nivo autoriteta je optimalan radi autorizacije određenih
tipova promena.
Software items se razvijaju kako softverski projekat napreduje. Verzija softverskog item-
a je posebno identifikovan i specifikovan item. Revision je nova verzija item-a koja je
namenjena da zameni staru verziju item-a. Variant je nova verzija item-a koja će biti
dodata konfiguraciji bez zamene stare verzije.
Software change request (SCR) proces zahteva korišćenje alata i procedura za podršku,
počev od papirnih formi i dokumenata do elektronskih alata za otpočinjanje zahteva za
promenama, forsiranje toka procesa promena, beleženje CCB odluka i izveštavanje.
Odobrene SCR se implementiraju korišćenjem definisanih softverskih procedura u skladu
sa primenjenim rasporedom rešavanja zahteva. Pošto se više SCR može implementirati
istovremeno neophodno je obezbediti praćenje koji SCR je inkorporisan u datu
softversku verziju.
Kvalitet Softvera
SQA Plan definiše način koji će biti korišćen radi osiguranja da softver zadovoljava
korisnikove zahteve i da je najvećeg mogućeg kvaliteta unutar ograničenja projekta. Radi
zadovoljenja tog cilja, plan mora prvo obezbediti da je ciljani kvalitet jasno definisan i
shvaćen. SQAP mora razmatrati menadžment, razvojne planove i planove održavanja
softvera (IEEE730-98). SQA Plan mora biti konzistentan sa SQM planom (software
configuration management plan).
dokumente
standarde
konvencije
merenja
statističke tehnike
procedure za izveštavanje o problemu i korektivne akcije
resurse
metodologije
trening
izveštavanje i dokumentaciju
REFERENCE: