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 Requirement2. Product and Process Requirements3. Functional and Nonfunctional Requirements4. Emergent Properties5. Quantifiable Requirements6. 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 designo opisuje kako je softver dekomponovan i organizovan u komponente 

(software architecture)2. Detailed design  

o opisuje specifično ponašanje ovih komponentio 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šavatipitanja 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 privremenedogađ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 komponentekomuniciraju 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 Fundamentals2. Managing Construction3. 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 softverao transformacioni modelo fazni modelo interativni i inkrementalni razvojo 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 feedbacko Pair programmingo Planning Gameo Test driven developmento Whole team

2. Continuous processo Continuous Integration o Refactoring or Design Improvement o Small Releases

3. Shared understandingo Coding Standards o Collective Code Ownershipo Simple Designo System Metaphor

4. Programmer welfareo 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