Specifikacija softverskih zahteva

Autor: Goran Radić, dipl.ing

Naziv jedinice: Softverski zahtevi (Software

Requirements)
U ovoj lekciji obradjivaćemo:

 Oblast Software Requirements

 Značaj ove oblasti za razvoj kompletnog softvera
 Podoblasti Software Requirements

Razvoj softverskog inženjerstva

Uprkos činjenici postojanja miliona softverskih profesionalaca širom sveta i širokoj

prisutnosti softvera u društvu, softversko inženjerstvo je tek nedevano steklo status
legitimne inženjerske discipline i priznate profesije. Nedavno su usvojeni standardi i
dokumentacija nekoliko tela i komiteta. IEEE Computer Society definiše softversko
inženjerstvo kao sistematičan i disciplinovan pristup razvoju, upravljanju i održavanju
softvera.

Na slici je prikazana šema softverskog inženjerstva prema SWEBOK-u:

Software Requirements

Oblast Software Requirements se bavi izvlačenjem, analizom, specifikacijom i

validacijom softverskih zahteva. Široko je prihvaćena i priznata oblast u sotverskoj
industriji. Softverski projekti su posebno ranjivi kada se ove aktivnosti realizuju na loš
način. Temelj je od koga polaze ostale oblasti i razvoj kompletnog softvera. Software
Requirements predstavlja sistematsko rukovanje zahtevima. Postoje razlike u pristupu i
modelovanju komponenti Software Requirements (npr. requirement engineer ili software
engineer ili requirement specialist i sl.). Da bi proces uzimanja zahteva bio uspešan mora
se posmatrati kao proces kompleksnih i isprepletanih aktivnosti (sekvencijalnih i
konkurentnih). Softverski zahtevi (Software Requirements) podrazumevaju osobine koje
moraju biti ispitane kako bi se rešio problem u realnom svetu.

Software Requirements obuhvata sledeće podoblasti:

1. Software Requirements Fundamentals

2. Requirements Process
3. Requirements Elicitation
4. Requirements Analysis
5. Requirements Specification
6. Requirements Validation
7. Practical Considerations
Detaljan prikaz podoblasti Software Requirements dat je na sledećoj slici:

Software Requirements Fundamenti

Software Requirements Fundamentals obuhvata:

1. Definition of a Software Requirement

2. Product and Process Requirements
3. Functional and Nonfunctional Requirements
4. Emergent Properties
5. Quantifiable Requirements
6. System Requirements and Software Requirements

Definicija Softverskih Zahteva

 
Software Requirement je osobina koja mora biti predstavljena (prikazana) u cilju
rešavanja nekog problema iz realnog sveta. Obrađuje probleme kojima će se upravljati
softverski u cilju njihovog rešavanja.

Primeri problema:

 automatizacija procesa pomoću softvera, osoba koje će ga koristiti

 podrška poslovnim procesima organizacije koja je naručila softver
 ispravljanje nedostataka postojećeg softvera
 upravljanje nekim uređajem i dr.

Sve navedeno može biti izuzetno kompleksno, pa su i zahtevi kompleksna kombinacija

od strane različitih ljudi, sa različitih nivoa u organizaciji i okruženja u kome će se
softver koristiti.

Osnovna karakterstika svih softverskih zahteva je da moraju biti verifabilni. Nekada je

jako skupo i teško verifikovati neki zahtev. Na primer, verifikacija zahteva propusnog
opsega call centra neizbežno iziskuje razvoj simulacionog softvera. Rangiranje prioriteta
softverskih zahteva - radi kasnije raspodele resursa i praćenja progresa. Softverski zahtevi
moraju biti jedinstveno identifikovani.

Proizvodni i procesni zahtevi

Postoji razlika između proizvodnih i procesnih parametara. Proizvodni parametri su

zahtevi softveru koji se razvija (npr. softver treba da verifikuje da je student ispunio sve
uslove da izađe na ispit). Procesni parametri (Process Requirements) se tiču samog
razvoja softvera (npr. softver treba da se piše u jeziku Ada). Neki softverski zahtevi
generišu implicitne procesne zahteve. Jedan od primera je izbor verifikacione tehnike.
Drugi je korišćenje tehnike analize za smanjenje grešaka koje mogu da dovedu do
neadekvatne pouzdanosti. Procesni zahtevi mogu biti uslovljeni od strane organizacije,
njenih kupaca ili treće strane (safety regulator).

Funkcionlani i nefunkcionlani zahtevi

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).

Primer nefunkcionalnih zahteva su i:

 dovoljan mrežni protok

 maintainability requirements,
 availability requirements i dr.
Emergent Properties

Emergance je centralni termin kompleksnih sistema. Emergent Properties javljaju se kada

više jednostavnih entiteta operiše u jednom okruženju i formiraju kompleksno ponašanje
kao kolektiv. Zahtevi koji predstavljaju izlazne karakteristike. To su zahtevi koji se ne
mogu obraditi jednom komponentom, ali će njihovo zadovoljenje zavisiti od sadejstva
više softverskih komponenti. Npr. zahtevi za propusnim opsegom call centra mogu da
zavise od toga kako telefonski sistem, informacioni sistem i operatori rade pod
određenim operacionim uslovima. Emergent properties utiču na arhitekturu sistema.

Kvantifabilni Zahtevi (Quantifiable Requirements)

Softverski zahtevi treba da se navedu jasno i kvantitativno. Važno je izbeći nejasne i

neverifabilne zahteve koji zavise od interpretacije subjektivnog rasuđivanja:

 npr. softver mora biti pouzdan

 npr. softver mora biti user-friendly

Ovo je posebno važno kod nefunkcionalnih zahteva.

Slede dva primera kvantifabilnih zahteva:

 Softver za call centar:

o softver mora povećati propusni opseg centra za 20% (propusni zahtev)
o sofver treba da ima verovatnoću generisanja fatalne greške tokom
   svakog sata rada sa manje od 10-8 (zahtev pouzdanosti)

System Requirements and Software Requirements

Prema definiciji International Council on Systems Engineering (INCOSE00) sistem

predstavlja interaktivnu kombinaciju elemenata (hardvera, softvera, ljudi, informacija,
servisa, tehnika, objekata i dr.) u cilju postizanja zacrtanog cilja. Sistemski zahtevi su
zahtevi za sistem kao celinu. Ako sistem sadrži softverske komponente, softverski
zahtevi su izvedeni iz sistemskih zahteva. U litetraturi se nekada umesto sistemskih
zahteva koristi termin korisnički zahtevi (što bi ipak bili zahtevi krajnjih korisnika (end-
user)). Sistemski zahtevi obuhvataju korisničke zahteve, zahteve regulatornih tela i dr.

Requirements Process

Requirements Process obuhvata:

2.1 Process Models

2.2 Process Actors
2.3 Process Support and Management
2.4 Process Quality and Improvement

Modeli Procesa (Process Models)

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.

Ova podoblast obuhvata kako se aktivnosti izvlačenja, analize, specifikacije i validacije

zahteva konfigurišu za različite tipove projekata. Uključene su i aktivnosti koje
obezbeđuju ulaze za requirements process, kao što su marketing i studija izvodljivosti
(feasibility studies).

Učesnici u procesu (Process Actors)

Podrazumeva opis uloge učesnika u requirements process-u. To je interdisciplinaran

proces. Requirements specialist ima ulogu medijatora između učesnika stakeholder-a (oni
koji imaju interes od rezultata projekta ili oni na koje utiče projekat) i software inženjera.
Obično je više učesnika uključeno pored requirements specialist-a. Stakeholderi variraju
od projekta do projekta, ali uvek uključuju korisnike i kupce.

Tipični primeri softver stakeholdera uključuju:

 korisnici - koji će koristiti softver, heterogene grupe

 kupci - obuhvata one koji naručuju softver ili one koji predstavljaju ciljnu
grupu softvera
 marketing saradnici - istraživači tržišta, utvrđivanje potreba tržišta
 regulatori - za aplikacije koje zahtevaju kontrolu (bankarstvo i sl.) i koji mora
zadovoljiti zahteve regulatornih tela
 software engineers - ove osobe imaju legitiman interes u razvoju softvera,
izvlačeći i
 korist iz već razvijenih kontrola (reuse u novim rešenjima), pažljiva analiza

Nije uvek moguće potpuno zadovoljenje zahteva svakog stakeholdera - preraspodela je

odgovornost softver inženjera.

Podrška i Upravljanje Procesom (Process Support and Management)

Ova podoblast bavi se potrebama za resursima. Obuhvata project management resources.

Koliko i kakvih resursa je potrebno i potrošeno u toku procesa uzimanja zahteva
(requirements process). Vezano je sa podoblasti Initiation and scope definition iz oblasti
znanja Software Engineering Management. Uspostavljanje veze između podoblasti
Process Models-a i pitanja troškova, ljudskih resursa, treninga i alata.

Poboljšanje i Kvalitet Procesa (Process Quality and Improvement)

Ova podoblast se bavi procenom kvaliteta (quality) i poboljšanja (improvement) procesa

uzimanja zahteva (requirements process). Ključna uloga u requirements procesu u
pogledu termina su troškovi i vremenski rokovi proizvodnje softvera i zadovoljavanje
potreba korisnika. Takođe ova podoblast pomaže u orijentaciji requirements process-a ka
standardima kvalitata.

Process quality and improvement je blisko vezan sa oblastima:

 Software Quality
 Software Engineering Process

Od posebnog značaja je tema atributa i merenja softverskog kvalitata i definicije

softverskog procesa.

Process Quality and Improvement podrazumeva:

 pokrivanje requirements procesa sa standardima unapređenja procesa i modela

 merenje i benchmarking requirements procesa
 planiranje poboljšanja i njihova implementacija

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.

Naziv jedinice: Softverski dizajn (Software Design)

Materijali vezani uz ovu lekciju:

- Test softverski dizajn (software design)

- Softverski dizajn (Software Design) (PDF dokument)

U ovoj lekciji obrađivaćemo:

•    oblast Software Design

•    podoblasti Software Design
•    Software Design Fundamentals
•    Key Issues in Software Design
•    Software Structure and Architecture

Na sledećoj slici je prikazana šema Softverskog dizajna:

Softverski dizajn (Software Design)

Dizajn je definisan kao proces definisanja arhitekture, komponenti, interface-a i ostalih

karakteristika sistema ili komponenti. Software design je aktivnost životnog ciklusa
software engineering-a u kome se softverski zahtevi analiziraju u cilju proizvodnje opisa
interne strukture softvera koja će služiti kao osnova za konstrukciju. Još preciznije,
software design mora opisati softversku arhitekturu, tj. kako je softver razložen i
organizovan u komponente i kakav je interface između ovih komponenti. Mora da opiše
komponente na nivou detalja koji omogućavaju njihovu konstrukciju.

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.

Rezultujući model možemo koristiti da isplaniramo naredne razvojne aktivnosti, da ih

koristimo kao ulaz i početnu tačku za konstrukciju i testiranje.

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.

Software Design obuhvata:

1. Software Design Fundamentals

2. Key Issues in Software Design
3. Software Structure and Architecture
4. Software Design Quality Analysis and Evaluation
5. Software Design Notations
6. Software Design Strategies and Methods

Osnove softverskog dizajna (Software Design Fundamentals)

Generalni koncepti dizajna (General Design Concepts)

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.

Kontekst softverskog dizajna (Context of Software Design)

Za razumevanje uloge software design-a važno je razumeti kontekst u kome se  

primenjuje životni ciklus software engineering-a. Važno je razumeti osnovne
karakteristike Software requirements analize vs. Software Design-a vs. Software
Construction vs. Software Testing.
Softver dizajn proces (Software Design Process)

Software design se generalno sastoji od dva procesa:

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

Enabling Techniques ili Software design principi odslikavaju fundamente različitih

pristupa i koncepata software design-a. Enabling Techniques su sledeće:

1. Apstrakcija (Abstraction)

Proces zanemarivanja informacija da bi se stvari koje su različite mogle tretirati kao da su

iste. U kontekstu software design-a, dva ključna apstraktna mehanizma su
parametarizacija i specifikacija. Apstrakcija po specifikaciji odrazumeva tri vrste
apstrakcije: procedural abstraction, data abstraction i control (iteration) abstraction.

2. Coupling and cohesion

Coupling (sprezanje) se definiše kao jačina relacija između modula. Cohesion (spajanje)
definiše kako su povezani elementi koji čine modul.

3. Decomposition and modularization

Dekompozicija i modularizacija velikog softvera u značajan broj    manjih nezavisnih

celina. Uobičajeno sa ciljem sa smeštanjem različitih funkcionalnosti ili  odgovornosti u
različite komponente.

4. Encapsulation/information hiding

Encapsulation/information hiding (skrivanje informacija) znači grupisanje i pakovanje

elemenata i internih detalja apstrakcije i pravljenjem ovih detalja nedostupnim
(inaccessible).

5. Separation of interface and implementation

Odvajanje interface-a i implementacije. Definisanje komponente preko public interface-a
(koji vide klijenti). Odvojeno od detalja realizacije komponente.

6. Sufficiency, completeness and primitiveness

Ostvarenjem sufficiency (dovoljnosti), completeness (savršenosti), i

primitiveness (jednostavnosti) znači osiguranje da softverska   komponenta obuhvata sve
značajne karaktersitike apstrakcije i ništa   više.

Ključna pitanja softverskog dizajna (Key Issues in Software Design)

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)

Konkurentnost, kako dekomponovati softver u procese, taskove i tredove i rešavati

pitanja efikasnosti, atomičnosti, sinhronizacije i rasporeda.

Kontrola i upravljanje događajima (Control and Handling of Events)

Kako organizovati podatke i kontrolu toka, kako obraditi reaktivne i privremene

događaje kroz različite mehanizme kao što su implicitan poziv i odziv.

Distribucija komponenti (Distribution of Components)

Bavi se pitanjima distribucije softvera preko hardvera, kako komponente

komuniciraju i dr.

Error and Exception Handling and Fault Tolerance

Kako uraditi prevenciju i toleranciju nedostataka i obradu izuzetaka.

Interaction and Presentation

Kako strukturirati i organizovati interakciju sa korisnikom i prezentaciju informacije.

Ova podoblast se ne bavi detaljima user interface-a, što je tema za user interface design
(deo Software Ergonomics)

Data Persistence

Perzistentnost (postojanost) podataka, bavi se pitanjima kako se obrađuju long-lived

podaci.

Softverska struktura i arhitektura (Software Structure and Architecture)

Software architecture je opis podsistema i komponenata softverskog sistema i relacija

između njih. Software architecture definiše internu strukturu rezultujućeg softvera, način
na koji je konstruisan i organizovan. U poslednjoj deceniji software architecture počinje
da se razvija kao šira disciplina, uključujući proučavanje softverske strukture i arhitekture
na više opšti način. Kao rezultat toga raste i broj ideja o softverskom dizajnu na različitim
nivoima apstrakcije. Neki od ovih koncepata mogu biti korisni tokom architectural design
(npr. architectural style) datog softvera, kao i tokom detaljnog dizajna (npr. lower-level
design patterns). Ovi koncepti mogu biti korisni i kod dizajna generičkih sistema, vodeći
do dizajna familija programa (product lines). Ovi koncepti mogu da se shvate i kao
pokušaji da se opišu i ponovo iskoriste znanja generičkog dizajna.

Architectural Structures and Viewpoints

Različiti high-level aspekti softverskog dizajna mogu se i moraju opisati i dokumentovati

(ovi aspekti se često nazivaju pogledi). Pogled predstavlja parcijalni aspekt softverske
arhitekture koji pokazuje specifičnu osobinu softverskog sistema.
Ovi odvojeni pogledi pripadaju odvojenim temama pridruženim softverskom dizajnu,
npr:

 logical view (zadovoljava funkcionalne zahteve)

 process view (pitanja konkurentnosti)
 physical view (pitanja distribucije)
 development view (kako je dizajn razbijen u implementacione jedinice)

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:

 General structure (npr. layers, pipes and filters, blackboard)

 Distributed systems (npr. client-server, threetiers, broker)
 Interactive systems (npr. Model-View-Controller, Presentation-Abstraction-
Control)
 Adaptable systems (npr., micro-kernel, reflection)
 Others (npr., batch, interpreters, process control, rule-based)

Design Patterns (microarchitectural patterns)

Sažeto opisano, patern je uobičajeno rešenje za uobičajen problem u datom kontekstu.

Dok architectural styles mogu biti posmatrani kao paternom opisana high-level
organizacija softvera (njihova makroarhitektura), ostali dizajn paterni mogu biti korišćeni
da opišu detalje na nižem, lokalnom nivou (njihova mikroarhitektura):
 

 Creational patterns (npr. builder, factory, prototype, singleton)

 Structural patterns (npr. adapter, bridge, composite, decorator, flyweight, proxy)
 Behavioral patterns (npr. command, interpreter, iterator, mediator,memento,
observer, state, strategy, template, visitor)

Families of Programs and Frameworks

Jedan od načina da se omogući ponovna upotreba softverskog dizajna i komponenata je

da se dizajnira familija softvera, koja se često naziva softver proizvodna linija. Ovo može
da se ostvari pomoću identifikovanja unificiranosti između članica takvih familija i
korišćenjem reusabilnih i custom-izovanih komponenata odgovornih za promenjivost
između članica familije. U objektno orijentisanom programiranju, framework - parcijalno
kompletiran softverski podsistem može biti proširen pomoću prikladno instanciranih
plug-in-ova.

REFERENCE:

 K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley,

1999,
 J. Bentley, Programming Pearls, second ed., Addison-Wesley, 2000,
 A. Hunt and D. Thomas, The Pragmatic Programmer, Addison-Wesley, 2000
  IEEE Std 1517-1999, IEEE Standard for Information Technology-Software Life
Cycle Processes- Reuse Processes, IEEE, 1999.
 IEEE/EIA 12207.0-1996//ISO/IEC12207:1995, Industry Implementation of Int.
Std. ISO/IEC 12207:95, Standard for Information Technology- Software Life
Cycle Processes, IEEE, 1996.
 B.W. Kernighan and R. Pike, The Practice of Programming, Addison-Wesley,
1999,
 S. Maguire, Writing Solid Code: Microsoft�s Techniques for Developing Bug-
Free C Software, Microsoft Press, 1993,
 S. McConnell, Code Complete: A Practical  Handbook of Software Construction,
Microsoft Press, second ed., 2004.
 I. Sommerville, Software Engineering, seventh ed., Addison-Wesley, 2005.

Naziv jedinice: Priroda i karakteristike dizajna

Materijali vezani uz ovu lekciju:

- Test priroda i karakteristike dizajna

- Priroda i karakteristike dizajna (PDF dokument)

U ovoj lekciji obrađivaćemo:

 konceptualni i tehnički dizajn

 dekompoziciju i modularnost
 nivoe dizajna
 iterativnost dizajna

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

Podrazumeva se različit ugao gledanja dizajnera i klijenata. Dizajneri moraju da

zadovolje i klijente i konstruktore sistema. Klijenti shvataju šta sistem treba da radi, dok
konstruktori sistema moraju da znaju kako taj sistem treba da radi. Dizajn je iterativni
proces iz dva dela:
  proizvodnja konceptualnog dizajna ili dizajn sistema koji opisuje klijentu šta
sistem radi
 pošto klijent odobri konceptualni dizajn, kreira se detaljniji dokument, tehnički
dizajn koji omogućava graditeljima sistema da utvrde koji će hardver i softver biti
potrebni za rešenje klijentovog problema

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.

Konceptualni i tehnički dizajn

Na slici je prikazan konceptualni i tehnički dizajn:

 
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 je skoncentrisan na funkcije sistema, dok tehnički dizajn opisuje

oblik sistema. U konceptualni dizajn spada šta sistem radi, a u tehnički dizajn spada opis
kako on to radi.

Razlika između dizajnerskih dokumenata

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

Projektovati sistem znači utvrditi skup komponenti i interfejsa među komponentama

kojima se zadovoljava konkretan skup zahteva. Kao što postoje mnogi načini da se
zahtevi iskažu i dokumentuju, postoje mnogi načini da se napravi dobar dizajn. U svakom
metodu postoji neka vrsta dekompozicije: počinje se od okvirnog opisa ključnih
elemenata sistema, a zatim se detaljno prikazuje kako će se elementi i funkcije sistema
međusobno uklapati.
 
Bez obzira na pristup dizajnu, svaka vrsta dekompozicije razdvaja dizajn na sastavne
delove koje nazivamo modulima ili komponentama. Za sistem kažemo da je modularan
kada svaku aktivnost sistema vrši samo jedna komponenta sa dobro definisanim ulazima i
izlazima. Komponenta dizajna je entitet sa dobro definisanim ulazom, izlazom ili
karakteristikama.

Dobro definisana komponenta

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.

Dekompozicija – prema Wasserman-u (1995)

1. Modularna dekompozicija

Ova konstrukcija se zasniva na tome da se komponentama dodele funkcije, dizajner

počinje sa opštim opisom funkcija koje treba implementirati i gradi detaljna objašnjenja o
organizaciji svake komponente i njenim relacijama sa ostalim komponentama.

2. Dekompozicija na osnovu podataka

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.

3. Dekompozicija na osnovu događaja

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.

4. Dizajn spolja ka unutra

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).

5. Objektno orijentisani dizajn

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

Na slici su prikazani nivoi dekompozicije:

Nivoi dizajna

Arhitekta softvera počinje proces projektovanja opštim pregledom izgleda i funkcija

budućeg softvera, obično radeći po top-down pristupu (odozgo nadole).

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.

Naziv jedinice: Konstrukcija softvera (Software

Construction)

Materijali vezani uz ovu lekciju:

- Test konstrukcija softvera (software construction)

- Konstrukcija softvera (Software Construction) (PDF dokument)

U ovoj lekciji obrađivaćemo:

 oblast Software Construction

 podoblasti Software Construction

Na slici je prikazan šematski prikaz softverske konstrukcije:

 
Termin software construction odnosi se na detaljno kreiranje softvera kroz kombinaciju
kodiranja, verifikacije, testiranje jedinice, integralnog testiranja i debugging-a. Oblast
Software Construction je povezana sa svim ostalim oblastima softverskog inženjerstva,
posebno sa Software Design-om i Software Testing-om. Sama oblast Software
Construction uključuje značajnu meru softverskog dizajna i aktivnosti testiranja.

Koristi izlaze iz dizajna i obezbeđuje jedan od ulaza za testiranje. Detaljnije granice

između dizajna, kreiranja i testiranja variraju u zavisnosti od procesa životnog ciklusa
softvera koji se koristi u projektu.

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.

Takođe je vezana sa upravljanjem projektima, u toj meri što upravljanje konstrukcijom

može da predstavlja veliki izazov.

Software Construction obuhvata:

1. Software Construction Fundamentals
2. Managing Construction
3. Practical considerations

1. Software Construction Fundamentals

Osnove konstrukcije softvera uključuju:

 Minimizing complexity
 Anticipating change
 Constructing for verification
 Standards in construction

Prva tri koncepta se primenjuju na dizajn isto kao i na konstrukciju. 

Minimiziranje Kompleksnosti (Minimizing Complexity)

Osnovni faktor kako ljudi izražavaju predanost računarima, je ograničena mogućnost

ljudi da pamte kompleksne strukture i informacije, posebno tokom dužeg vremenskog
perioda. Ovo vodi do najjačeg pokretača u softverskoj konstrukciji: minimiziranje
kompleksnosti. Potreba za smanjenjem kompleksnosti primenjuje se posebno na svaki
aspekat softverske konstrukcije i posebno je kritičan za proces verifikacije i testiranja
softverskih konstrukcija. Verifikacija i testiranje kompleksnih rešenja može da bude
teško izvodljivo.

U softverskoj konstrukciji smanjenje kompleksnosti je ostvareno kroz naglasak na

kreiranje koda koji je jednostavaniji i čitljiviji radije nego pametniji. Smanjenje
kompleksnosti je ostvareno kroz primenu standarda, koji se razmatraju u sekciji 4.
Standards in Construction, i kroz brojne specifične tehnike koje su sumirane u podsekciji
Coding. Podržane su i od konstrukcijski fokusiranih tehnika kvaliteta predstavljenih u
temi Construction Quality.

Predviđanje Promena (Anticipating Change)

Većina softvera se menja tokom vremena i predviđanje promena (anticipation of change)

proizvodi mnoge aspekte softverske konstrukcije. Softver je neizbežno deo promena u
spoljašnjim okruženjima i promene u ovim spoljašnjim okruženjima utiču na softver na
najrazličitije načine. Predviđanje promena je podržano od strane mnogih specifičnih
tehnika predstavljenih u temi Coding.
Konstrukcija za verifikaciju (Constructing for Verification)

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.

Standardi u Konstrukciji (Standards in Construction)

Standardi koji direktno utiču na temu konstrukcije uključuju korišćenje eksternih

standarda. Konstrukcija zavisi od korišćenja eksternih standarda za konstrukcione jezike,
konstrukcione alatke, tehničke interfejse i interakcije između oblasti Software
Construction i drugih oblasti. Standardi dolaze iz različitih oblasti, uključujući
specifikacije hardverskih i softverskih interfejsa, kao što su Object Management Group
(OMG – konzorcijum softverskih kompanija, postavljanje standarda za distribuirane
sisteme i modelovanje, http://www.omg.org) i internacionalne organizacije kao što su
IEEE ili ISO.

Postoje i drugi standardi:

 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))

Važno je i korišćenje internih standarda, standardi koji su kreirani na organizacionoj

osnovi na korporativnom nivou ili za korišćenje u specifičnim projektima. Interni
standardi podržavaju koordinaciju grupnih aktivnosti, minimiziranje kompleksnosti,
predviđanje promena i konstrukciju pogodnu za verifikaciju.

REFERENCE:

 K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley,

1999.
 J. Bentley, Programming Pearls, second ed., Addison-Wesley, 2000.
 A. Hunt and D. Thomas, The Pragmatic Programmer, Addison-Wesley, 2000.
 IEEE Std 1517-1999, IEEE Standard for Information Technology-Software Life
Cycle Processes- Reuse Processes, IEEE, 1999.
 IEEE/EIA 12207.0-1996//ISO/IEC12207:1995, Industry Implementation of Int.
Std. ISO/IEC 12207:95, Standard for Information Technology- Software Life
Cycle Processes, IEEE, 1996.
  B.W. Kernighan and R. Pike, The Practice of Programming, Addison-Wesley,
1999.
 S. Maguire, Writing Solid Code: Microsoft�s Techniques for Developing Bug-
Free C Software, Microsoft Press, 1993.
 S. McConnell, Code Complete: A Practical  Handbook of Software Construction,
Microsoft Press, second ed., 2004.
 I. Sommerville, Software Engineering, seventh ed., Addison-Wesley, 2005.

Naziv jedinice: Ostali modeli procesa izrade

softvera

Materijali vezani uz ovu lekciju:

- Test ostali modeli procesa izrade softvera

- Ostali modeli procesa izrade softvera (PDF dokument)

U ovoj lekciji obrađivaćemo:

 modele procesa izrade softvera

o transformacioni model
o fazni model
o interativni i inkrementalni razvoj
o spiralni model

Transformacioni model

Balzerov transformacioni model pokušava da redukuje mogućnost greške eliminacijom

nekoliko koraka razvoja. Pomoću automatske podrške, transformacioni proces primenjuje
niz transformacija radi pretvaranja specifikacije u sistem koji može da se isporuči (Balzer
1981). Tipične transformacije obuhvataju:

 izmenu predstavljanja podataka

 izbor algoritama
 optimizaciju

Iz razloga što od specifikacije do isporučenog sistema ima više puteva, sekvence

transformacija i odluka koje ga predstavljaju, čuvaju se kao formalni zapis u sklopu
dizajna. Glavna smetnja njegovoj upotrebi je potreba za preciznom formalnom
predstavom specifikacije, tako da transformacije mogu nad njom da se izvršavaju.
Smanjenje trajanja ciklusa

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

Npr. posmatramo programski paket za obradu teksta. Pretpostavimo da paket treba da

isporuči tri vrste funkcionalnosti:
 unošenje teksta
 organizovanje teksta
 formatiranje teksta

Za gradnju sistema pomoću inkrementalnog razvoja, može se u verziji 1 obezbediti samo

funkcije za unos teksta, zatim u verziji 2 i unos i organizaciju, a na kraju u verziji 3 unos
teksta, organizaciju i formatiranje. Koristeći iterativni razvoj, moguće je obezbediti
primitivne oblike sva tri tipa funkcionalnosti već u verziji 1. Npr. moguće je uneti tekst, a
zatim vršiti isecanje i umetanje, pri čemu je isecanje i umetanje sporo. U sledećoj
iteraciji, tj. verziji 2, postoji ista funkcionalnost, ali poboljšan kvalitet, tako da je isecanje
i umetanje lako i brzo. Svaka verzija poboljšava na neki način prethodnu.

Prednosti faznog razvoja

Ovakvi oblici faznog razvoja poželjni su iz više razloga:

 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

Boehm (1988) je posmatrao razvoj softvera u svetlu prisutnih rizika, sugerišući da

spiralni model može da kombinuje aktivnosti razvoja sa upravljanjem rizicima, radi
smanjenja i kontrole rizika. Spiralni model, na neki način je sličan modelu iterativnog
razvoja. Započinjući za zahtevima i početnim planom razvoja (uključujući budžet,
ograničenja i alternative), ovaj proces ubacuje korak koji vrši procenu rizika i prototipske
alternative, pre nego što se proizvede dokument „principi rada”, sa ciljem opisivanja
funkcionisanja sistema na visokom nivou apstrakcije. Iz tog dokumenta, definiše se i
nadgleda skup zahteva da bi se potvrdile kompletnost i doslednost zahteva. Stoga je
princip rada proizvod prve iteracije dok su zahtevi glavni proizvod druge iteracije po
redu. U trećoj iteraciji razvoj sistema produkuje dizajn, dok četvrta iteracija omogućava
testiranje.

U svakoj iteraciji, analiza rizika određuje različite varijante sa aspekta zahteva i

ograničenja dok se izradom prototipova verifikuje izvodljivost ili poželjnost, pre izbora
odgovarajuće varijante. Nakon identifikacije rizika, rukovodioci projekta moraju da
odluče kako da ih eliminišu ili minimiziraju.

Npr. projektanti možda nisu sigurni da li će korisnicima više da se dopada jedan

korisnički interfejs ili drugi. Da bi se izbegao rizik izbora interfejsa koji bi onemogućio
produktivnu upotrebu novog sistema, projektanti mogu da izrade prototip oba interfejsa i
izvrše testove da bi zaključili koji je poželjniji, ili čak da oba interfejsa uključe u projekat
kako bi korisnici mogli da, nakon prijavljivanja, odaberu interfejs. Ograničenja kao što su
budžet i vreme isporuke pomažu kod izbora strategije upravljanja rizicima.
Naziv jedinice: Savremena metodologija razvoja
softvera

Materijali vezani uz ovu lekciju:

- Test savremena metodologija razvoja softvera

- Savremena metodologija razvoja softvera (PDF dokument)

U ovoj lekciji obrađivaćemo:

 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).

Razvoj iteracija kroz životni ciklus softvera

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.

Principi agilnog načina

Vrednovanje pojedinaca i interakcije sa procesima i alatima, što podrazumeva da je

projektnom timu potrebno obezbediti neophodne resurse i imati poverenje u to da će oni
svoje poslove uraditi kvalitetno. Timovi se samoorganizuju i komuniciraju lično, umesto
posredstvom dokumentacije. Trosi se vise vremena u izradu softvera koji radi umesto u
izradu sveobuhvatne dokumentacije. Ovi metodi sadrze manje dokumentacije nego drugi
metodi, što je meta kritičara zbog nedostatka discipline.

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.

Cilj agilnog razvoja

Cilj agilnog razvoja je zadovoljavanje naručioca. Mnoge poslovne potrebe naručioca se

menjaju tokom vremena, što je ne samo posledica novih zahteva, već i potrebe da se
odgovori promenama na tržištu. Npr. nakon što se softver projektuje i izgradi,
konkurencija može da objavi novi proizvod koji zahteva izmene u planiranoj
funkcionalnosti softvera. Slično tome, vladina agencija ili telo za standardizaciju može da
nametne nove propise ili standarde koji utiču na projekat ili ograničenja vezana za
softver. Uvođenjem fleksibilnosti u proces razvoja agilne metode pružaju mogućnost da
naručioci dodaju ili menjaju zahteve u kasnim fazama ciklusa razvoja.

Principi Agile Manifesto (2001):

 zadovoljstvo kupca konstatnim isporukama upotrebljivog softvera 

  softver se isporučuje frekventno (pre sedmično, nego mesečno)
 softver koji radi je principijelna mera progresa
 zakašnjene promene u zahtevima su takođe dobodošle
 bliska kooperacija na dnevnom nivou između naručioca i developera
 lična konverzacija je najbolja forma komunikacije
 projekat grade motivisani ljudi, u koje treba verovati
 konstantna pažnja tehničkoj nadmoćnosti i dobrom dizajnu
 jednostavnost
 samo organizovan tim

Scrum

Scrum je iterativni inkrementalni proces softverskog razvoja. Model iterativnog razvoja,

gde se svaka 30-dnevna iteracija naziva „sprint” a služi za implementiranje zaostalih
zahteva najvišeg prioriteta. Prvi put predstavljen na OOPSLA (Object-Oriented
Programming, Systems, Languages & Applications) konferenciji u Austinu 1996, kasnije
dograđivan. Realizuje se preko predefinisanih zadataka.

Glavne uloge u Scrum-u imaju:

 ScrumMaster - koji vodi procese (slično project manager-u)

 Product Owner - koji predstavlja zainteresovane učesnike (stakeholders)
 Team - razvojni tim

Termin Sprint predstavlja period u trajanju od 15 do 30 dana (dužinu određuje Team), u

kome Team kreira softverski proizvod (inkrement). Skup karaktersitika koje ulaze u svaki
Sprint dolaze iz Product Backlog-a, koji predstavlja skup zahteva rangiranih po prioritetu.
Koji backlog item će ući u sprint se određuje tokom sprint planning meeting-a. Tokom
ovog sastanka Product Owner informiše tim o itemima u product backlog koje želi da
budu kompletirani. Tim određuje koliko ovoga se može uraditi tokom sledećeg sprinta.
Kada počne sprint niko ne može da promeni backlog, tj. zahtevi su zamrznuti za sprint.
Koordinacija se vrši na kratkim svakodnevnim sastancima tokom sprinta pod nazivom
scrum. Uloge u Scrumu su podeljene u dve grupe: pigs and chickens.

 
 

Ekstremno programiranje, XP

Extreme Programming je metodologija softverskog inženjerstva koja primenjuje skup 12

stakeholder veština koje podstiču posebne XP vrednosti. Extreme Programming je
disciplina softverskog razvoja zasnovana na vrednostima simplicity, communication,
feedback, courage i respect. Zasniva se na okupljanju celog tima zajedno na jednom
mestu, sa radom na praksi, sa dovoljno povratnih sprega radi obezbeđivanja timu da vidi
gde se nalazi i primeni prasku na datu situaciju. Extreme Programming tim koristi
jednostavnu formu planiranja i praćenja radi odlučivanja šta treba da se uradi sledeće i
radi predviđanja kada će se projekat završiti. Fokusiran na poslovnim vrednostima, tim
proizvodi softver u serijama malih potpuno integrisanih izdanja (releases) koji su prošli
sve testove koje je potrošač definisao.

XP je poseban oblik agilnog procesa, zasnovan na principima koji odražavaju opštija

načela agilnog manifesta XP-a naglašava vrednosti agilnosti:
 komunikaciju (communication)
 jednostavnost (simplicity)
 odvažnost (courage)
 povratnu spregu (feedback)
 poštovanje (respect)

Komunikacija obuhvata neprestanu razmenu informacije između naručioca i projektnog

tima.
Jednostavnost ohrabruje projektni tim da odabere najjednostavniji dizajn ili
implementaciju koji odgovara potrebama naručioca.
Odvažnost stvaraoci XP-a opisuju kao posvećenost ranim i čestim isporukama funkcija.
Povratne sprege se ugrađuju u različite aktivnosti tokom procesa razvoja. Npr.
programeri rade zajedno da bi jedni drugima dali povratne informacije o najboljem
načinu za implementaciju projektnih rešenja. U tom smislu postoji poštovanje između
članova programerskog tima.
12 veština XP-a

Extreme Programming ima 12 veština, grupisanih u 4 oblasti:

1. Fine scale feedback

o Pair programming
o Planning Game
o Test driven development
o Whole team
2. Continuous process
o Continuous Integration
o Refactoring or Design Improvement
o Small Releases
3. Shared understanding
o Coding Standards
o Collective Code Ownership
o Simple Design
o System Metaphor
4. Programmer welfare
o Sustainable pace

Programiranje u paru

Postoji razlika između stanovišta prema kojem je softversko inženjerstvo umetnost, i

onog prema kojem je ono nauka. Programiranje u paru se bavi umetničkom stranom
razvoja softvera, priznajući činjenicu da je metafora majstor-šegrt korisna u fazi u kojoj
novi programeri uče kako da razviju instinkt majstora. Koristeći jednu tastaturu, dva
programera koji rade u paru razvijaju sistem na osnovu specifikacija i dizajna. Jedna
osoba je odgovorna za kodiranje, ali rad u paru poseduje fleksibilnost, jer jedan
programer može da ima više partnera u istom danu. Slede konsultacije, razmena ideja,
itd.

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.

Pisanje testova pre kodiranja (Test driven development)

Da bi se osiguralo da potrebe naručioca budu glavni pokretač razvoja, prvo se pišu test
scenariji, zatim kod neophodan da se prođe taj test, kao način kojim se naručilac
primorava da specifikuje zahteve koji se, po izradi softvera, mogu testirati i verifikovati.
U XP-u se koriste dve vrste testova. Prva vrsta su funkcionalni testovi koje specifikuje
naručilac, a koje sprovode projektni tim i korisnici. Druga vrsta su testovi delova koje
piše i izvršava razvojni tim. U XP-u su funkcionalni testovi automatizovani, a u idealnom
slučaju oni se izvršavaju svakog dana. Funkcionalni testovi se smatraju delom
specifikacije sistema. Testovi delova se pišu i pre i posle kodiranja, radi verifikovanja da
svaki modul implementacije radi prema očekivanjima.

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

Brza isporuka funkcionalnosti znači da isporuka sistema koji funkcionišu može da se

izvrši u vrlo kratkom roku. Naglasak je na malim inkrementima ili poboljšanjima umesto
na velikim skokovima od jedne revizije do druge.

Prerađivanje koda (refaktorisanje)

Tokom izgradnje sistema, postoji verovatnoća da dođe do promene zahteva. Kako je

glavna karakteristika XP-filozofije dizajn jedino aktuelnih zahteva, često pojava novih
zahteva primorava projektni tim da ponovo razmotri postojeća projektna rešenja.
Prerađivanje koda (engl. refactoring) se odnosi na ponovno vraćanje na zahteve i dizajn, i
njihovo preformulisanje u skladu sa novim i postojećim potrebama. Nekada se
prerađivanje bavi načinima restrukturiranja dizajna koda bez izmena spoljašnjeg
ponašanja sistema. Prerađivanje se vrši u malim koracima, uz testiranje delova i
programiranje u paru, sa primenom jednostavnosti kao osnovnom idejom.

Male verzije

Sistem je projektovan tako da funkcionalnost može da se isporuči što je pre moguće.

Funkcije su dekomponovane na male delove, sa ciljem da se neka funkcionalnost isporuči
u ranoj fazi, a zatim poboljšava ili proširuje u kasnijim verzijama. Male verzije zahtevaju
fazni pristup razvoju, sa inkrementalnim ili iterativnim ciklusima.

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

Podrazumeva deljena razmišljanja o zajedničkom cilju i misiji. Projektni tim se

usaglašava oko zajedničke vizije načina rada sistema. Kao podršku zajedničkoj viziji tim
odabira zajedničku nomenklaturu i sporazumeva se oko zajedničkog načina tretiranja
ključnih pitanja.

Održivi korak (Sustainable pace)

Služi za dobrobit programera. Naglasak na ljudima u XP-u uzima u obzir i činjenicu da

umor može proizvesti greške. Tako pobornici XP-a sugerišu da je cilj 40 radnih časova
nedeljno. Forsiranje projektnog tima na postizanje rokova siguran je znak da su rokovi
nerealni ili da postoji nedostatak resursa.

Naziv jedinice: Planiranje i upravljanje SCM

procesom

Materijali vezani uz ovu lekciju:

- Test planiranje i upravljanje scm procesom

- Planiranje i upravljanje SCM procesom (PDF dokument)
U ovoj lekciji obrađivaćemo:

 oblast Software Configuration Management

 planiranje SCM procesa
 upravljanje procesom promena

Planiranje Software Configuration Management (SCM) procesom

Planiranje SCM procesa za dati projekat treba da se usaglasi sa organizacionim

kontekstom, primenjenim ograničenjima, najčešće prihvaćenim vođenjem i prirodom
projekta (npr. veličina). Osnovne aktivnosti obuhvaćene planiranjem su:

 Software Configuration Identification

 Software Configuration Control
 Software Configuration Status Accounting
 Software Configuration Auditing
 Software Release Management and Delivery

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.

Uobičajeno se definiše 6 kategorija SCM informacija koje se uključuju u SCMP:

 Uvod (namena, opseg, korišćeni termini)

 SCM Management (organizacija, odgovornosti, nadležnosti, primenjene polise,
direktive i procedure)
 SCM Activities (configuration identification, configuration control)
 SCM Schedules (koordinacija sa ostalim projektnim aktivnostima)
 SCM Resources (alati, fizički resursi, ljudski resursi)
 SCMP Maintenance

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 Configuration Identification

Identifikuje item-e koji će se kontrolisati, ustanovljava identifikacione šeme za item i

njegove verzije i uspostavlja alate i tehnike za upravljanje kontrolisanim item-ima. Ove
aktivnosti obezbeđuju osnovu za ostale SCM aktivnosti. Prvi korak u kontrolisanju
promena je identifikacija itema koji će se kontrolisati, što podrazumeva razumevanje
softverske konfiguracije unutar sistemske konfiguracije. Razvoj strategije za označavanje
softverskih item-a i opisivanje njihovih uzajamnih veza je od velike važnosti.

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 Configuration Control

Software configuration control se bavi upravljanjem promenama tokom životnog ciklusa

softvera. Pokriva procese za određivanje koje promene je potrebno napraviti,
odgovornost za odobrenje određenih promena, podrška implementaciji ovih promena i
odstupanja od softverskih zahteva. Informacija izvedena iz ovih aktivnosti je korisna u
merenju promena i aspekata ponovne izrade.

Tok upravljanja procesom promena

Prvi korak u upravljanju promenama je utrđivanje koje promene je potrebno napraviti.

Zahtev za promenama (software change request - SCR) obezbeđuje formalne procedure
za traženje i snimanje zahteva za promenama, evaluacije potencijalnih troškova i uticaj
predloženih promena, kao i prihvatanje, modifikovanje ili odbijanje predloženih
promena. Zahtev za promenama za software configuration može doći od strane bilo koga
u bilo kom trenutku u toku životnog ciklusa softvera i može da sadrži predloženo rešenje
i prioritet zahteva. Jedan od izvora zahteva za promenama je iniciranje akcija za
korekciju kao odgovor na izveštaj o postojanju problema. Bez obzira na izvor tip
promene (npr., kvar ili  unapređivanje) se uobičajeno prati.

Ovo obezbeđuje priliku za praćenje grešaka i prikupljanje merenje aktivnosti na

promenama po tipu promena. Jednom kada je SCR primljen, tehnička evaluacija
(nazivana i impact analiza) se izvodi u cilju određivanja opsega modifikacije koja bi bila
neophodna radi prihvatanja zahteva za promenom. Dobro razumevanje veza između
softverskih item-a je važan za ovaj zadatak. Odgovorno telo će evaluirati tehničke
aspekte predložene promena i odlučiti da li prihvata, modifikuje, odbija ili odlaže
predloženu promenu. Authority za prihvatanje ili odbijanje predloženih promena odvija
se sa entitetom tipično poznatim kao Configuration Control Board (CCB).

U manjim projektima, ovlašćenje (authority) se može postaviti na nivou pojedinca, radije

nego na višečlano telo. Može biti više nivoa ovlašćenja u zavisnosti od prirode promene
(npr. uticaja na budžet i rokove ili tekuće tačke u životnom ciklusu). Sastav CCB-a
korišćenog za dati sistem varira u zavisnosti od ovih kriterijuma (SCM predstavnik će
uvek biti prisutan). Sve zainteresovane strane (stakeholders) u zavisnosti od nivoa CCB-
a, imaju svoje predstavnike. Kada je nadležnost CCB-a striktno softver, govorimo o
Software Configuration Control Board (SCCB). Aktivnosti CCB-a su tipično tema i audit
i review oblasti softverskog kvaliteta.

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.

Snimanje i izveštavanje (Software Configuration Status Accounting)

Software Configuration Status Accounting (SCSA) je snimanje i izveštavanje o

informacijama potrebnim za efikasan menadžment softverske konfiguracije. Informacije
iz izveštaja mogu koristiti razni organizacioni i projektni elementi kao što su razvojni tim,
tim za održavanje, upravljanje projektom i aktivnosti softverskog kvaliteta. Izveštavanje
može imati formu pojedinačnih, ad-hoc upita ili periodičan sistem izveštavanja prema
unapred definisanim kriterijumima. Izveštaji mogu poslužiti i za različita merenja, kao
npr. broj zahteva za promenama ili prosečno vreme potrebno za implementaciju zahteva
za promenama.

Puštanje i distribucija (Software Release Management and Delivery)

Termin release se koristi u kontekstu distribucije item-a softverske konfiguracije izvan

aktivnosti razvoja. Ovo uključuje interno puštanje kao i distribuciju kupcima. Kada su
različite verzije softver item-a dostupne za isporuku, kao što su verzije za različite
platforme, najčešće je potrebno kreirati verziju i pakovati korektan materijal za isporuku
date verzije. Software building je aktivnost kombinovanja korektnih verzija software
configuration item-a, koristeći adekvatne konfiguracione podatke, a izvršivši program za
isporuku kupcu. Software release management obuhvata identifikaciju, pakovanje, i
isporuku elemenata proizvoda, kao npr. izvršni program, dokumentaciju, release notes i
konfiguracione podatke.

Naziv jedinice: Kvalitet Softvera (Software

Quality)
Materijali vezani uz ovu lekciju:

- Test kvalitet softvera (software quality)

- Kvalitet Softvera (Software Quality) (PDF dokument)

U ovoj lekciji obrađivaćemo:

 Oblast Software Quality

 Fundamente Softverskog kvaliteta
 Osiguranje kvaliteta softvera (Software Quality Assurance)

Kvalitet Softvera

Kvalitet softvera se posebno razmatra tokom kompletnog procesa softverskog

inženjerstva i vezan je sa svim oblastima razvoja softvera. Softverski kvalitet definiše
meru koliko je dobro softver dizajniran (quality of design) i koliko je dobro softver u
skladu sa tim dizajnom (quality of conformance).

Oblast Software Quality obuhvata:

 Fundamenti Softverskog kvaliteta

 Kultura i etika softverskog inženjerstva
 Vrednost i cena kvaliteta
 Kvalitet procesa softverskog inženjerstva
 Kvalitet softverskog proizvoda
 Poboljšanje kvaliteta
 Proces upravljanja kvalitetom softvera
 Verifikacija i validacija
 Pregled i revizija
 Merenja softverskog kvaliteta

Na slici je prikazana šematski podoblasti software quality:

 izvor: Guide to the SWEBOK

Fundamenti Softverskog Kvaliteta (Software Quality Fundamentals)

Softver inženjer treba da razume značenje koncepata i karakteristika kvaliteta i njihov

uticaj na razvoj softvera i održavanje. Važan koncept je da softverski zahtevi definišu
zahtevane karakteristike kvaliteta i uticaj na metode merenja i kriterijume prihvatanja
radi procene ovih karakteristika. Od softver inženjera se očekuje da dele predanost
kvalitetu softvera. Kultura i etika igraju značajnu ulogu u softverskom kvalitetu. IEEE
Computer Society i ACM (Association for Computing Machinery) su razvili etičke
kodove kao pomoć softverskim inženjerima i podršku razvoju stavova vezanih za
kvalitet.
 
Kupci imaju takođe određena očekivanja po pitanju kvaliteta softvera. Kupci ponekad
nemaju potpuno jasnu sliku o kvalitetu softvera, čija se percepcija razlikuje od gledišta
softver inženjera. Parametri kvaliteta softvera uspostavljaju se u ranim fazama razvoja
softvera. Kvalitet procesa i kvalitet proizvoda su različiti termini, ali između kojih postoji
jasna veza.

Da li se iz nekvalitetnog procesa razvoja može dobiti kvalitetan softver? Da li se iz

kvalitetnog procesa razvoja može dobiti nekvalitetan softver? Šta predstavlja kvalitetan
proces razvoja?

Software Quality Management Proces

Software Quality Management (SQM) primenjuje se na sve segmente softverskih

procesa, proizvode i resurse. Definiše procese, vlasnike procesa i zahteve za ove procese,
merenja procesa i njihovih izlaza i kanale feedback-a. Software Quality Management
proces se sastoji od više aktivnosti. Neke mogu direktno da otkriju defekte, dok druge
indiciraju gde je korisno raditi dalja ispitivanja. Neke od specifičnih SQM procesa su
(IEEE12207.0-96):

 Proces osiguranja kvaliteta (Quality Assurance process)

 Proces verifikacije (Verification process)
 Proces validacije (Validation process)
 Proces pregleda (Review process)
 Proces revizije (Audit process)

Osiguranje kvaliteta softvera (Software Quality Assurance)

SQA proces pruža obezbeđenje da su softverski proizvodi i procesi u životnom ciklusu

projekta u skladu sa njihovim datim zahtevima putem planiranja, propisivanja i izvođenja
skupa aktivnosti radi pružanja adekvatnog poverenja da je kvalitet ugrađen u softver. Ovo
znači osiguranje da je problem jasno i adekvatno naveden i da je rešenje zahteva ispravno
definisano i izraženo. SQA pokušava da održava kvalitet kroz razvoj i održavanje
proizvoda putem izvršavanja više različitih aktivnosti u svakoj fazi što može rezultirati u
ranoj identifikaciji problema, gotovo neizbežne pojave u svakoj kompleksnoj aktivnosti.
Uloga SQA je osiguranje da su planirani procesi prikladno izabrani i kasnije
implementirani prema planu, i da je pružen relevantan proces merenja.

Software Quality Assurance Plan

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).

Sadržaj Software Quality Assurance Plan-a

SQA plan identifikuje:

 dokumente
 standarde
 konvencije
 merenja
 statističke tehnike
 procedure za izveštavanje o problemu i korektivne akcije
 resurse
  metodologije
 trening
 izveštavanje i dokumentaciju

REFERENCE:

 F.A. Ackerman, Software Inspections and the Cost Effective Production of

Reliable Software, Software Engineering, Volume 2: The Supporting Processes,
Richard H. Thayer and Mark Christensen, eds., Wiley-IEEE Computer Society
Press, 2002.
 V.R. Basili and D.M. Weiss, A Methodology for Collecting Valid Software
Engineering Data, IEEE Transactions on Software Engineering, vol. SE-10, iss. 6
 B. Beizer, Software Testing Techniques, International Thomson Press, 1990.
 B.W. Boehm et al., Characteristics of Software Quality, TRW Series on Software
Technologies, vol. 1, 1978.
 R. Chillarege, Orthogonal Defect Classification, Handbook of Software
Reliability Engineering, M. Lyu, ed., IEEE Computer Society Press, 1996.
 S.D. Conte, H.E. Dunsmore, and V.Y. Shen, Software Engineering Metrics and
Models: The Benjamin Cummings Publishing Company, 1986.
 G. Dache, IT Companies will gain competitive advantage by integrating CMM
with ISO9001, Quality System Update, vol. 11, iss. 11, November 2001.
 R.G. Ebenau and S. Strauss, Software Inspection Process, McGraw-Hill, 1994.
 N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous & Practical
Approach, second ed., International Thomson Computer Press, 1998.
 D.P. Freedman and G.M. Weinberg, Handbook of  Walkthroughs, Inspections,
and Technical Reviews, Little, Brown and Company, 1998.
 M.A. Friedman and J.M. Voas, Software Assessment: Reliability, Safety
Testability, John Wiley & Sons, 1995.
 T. Gilb and D. Graham, Software Inspections, Addison-Wesley, 1993.
 R.B. Grady, Practical Software Metrics for Project Management and Process
Management, Prentice Hall, 1992.
 J. W. Horch, Practical Guide to Software Quality Management, Artech House
Publishers, 2003.
 IEEE-CS-1999, Software Engineering Code of Ethics and Professional Practice,
IEEE-CS/ACM, 1999,
 ISO 9001:2000, Quality Management Systems  Requirements, ISO, 2000.
 ISO/IEC 90003:2004, Software and Systems Engineering-Guidelines for the
Application of ISO9001:2000 to Computer Software, ISO and IEC, 2004.
 C. Jones and J. Capers, Applied Software Measurement: Assuring Productivity
and Quality, second ed., McGraw-Hill, 1996.
 S.H. Kan, Metrics and Models in Software Quality Engineering, second ed.,
Addison-Wesley, 2002.
 D. Kiang, Harmonization of International Software Standards on Integrity and
Dependability, Proc. IEEE International Software Engineering Standards
Symposium, IEEE Computer Society Press, 1995.
 J.C. Laprie, Dependability: Basic Concepts and Terminology in English, French,
German, Italian and Japanese, IFIP WG 10.4, Springer-Verlag, 1991.
 N.G. Leveson, Safeware: System Safety and Computers, Addison-Wesley, 1995.
 R.O. Lewis, Independent Verification and Validation: A Life Cycle Engineering
Process for Quality Software, John Wiley & Sons, 1992.
 J.A. McCall, �Factors in Software Quality � General Electric, n77C1502, June
1977.
 S. McConnell, Code Complete: A Practical Handbook of Software Construction,
Microsoft Press, second ed., 2004.
 J. Musa, Software Reliability Engineering: More Reliable Software, Faster
Development and Testing: McGraw Hill, 1999.
 National Institute of Standards and Technology, Baldrige National Quality
Program, available at http://www.quality.nist.gov.
 W.W. Peng and D.R. Wallace, Software Error Analysis, National Institute of
Standards and Technology, Gaithersburg, NIST SP 500-209, December 1993,
S.L. Pfleeger, Software Engineering: Theory and Practice, second ed., Prentice
Hall, 2001.
 R.S. Pressman, Software Engineering: A Practitioner�s Approach, sixth ed.,
McGraw-Hill, 2004.
 R. Radice, High Quality Low Cost Software Inspections, Paradoxicon, 2002, p.
479.
 S.R. Rakitin, Software Verification and Validation: A Practitioners Guide, Artech
House, 1997.
 J. Rubin, Handbook of Usability Testing: How to Plan, Design, and Conduct
Effective Tests, John Wiley & Sons, 1994.
 G.C. Schulmeyer and J.I. McManus, Handbook of Software Quality Assurance,
third ed., Prentice Hall, 1999.
 Capability Maturity Model Integration for Software Engineering (CMMI),�
CMU/SEI-2002-TR-028, ESC-TR-2002-028, Software Engineering Institute,
Carnegie Mellon University, 2002.
 I. Sommerville, Software Engineering, seventh ed., Addison-Wesley, 2005.
 J. Voas, Certifying Software For High Assurance Environments,IEEE Software,
 S. Wakid, D.R. Kuhn, and D.R. Wallace, Toward Credible IT Testing and
Certification,� IEEE Software, July/August 1999, pp. 39-47.
 D.R. Wallace and R.U. Fujii, �oftware Verification and Validation: An
Overview,� IEEE Software,
 D.R. Wallace, L. Ippolito, and B. Cuthill, Reference Information for the Software
Verification and Validation Process, NIST SP 500-234, NIST, April 1996,
 G.M. Weinberg, Measuring Cost and Value, Quality Software Management:
First-Order Measurement,
 K. Wiegers, Creating a Software Engineering Culture, Dorset House, 1996.
 M.V. Zelkowitz and D.R. Wallace, Experimental Models for Validating
Technology,Computer