Please enable JavaScript.

Coggle requires JavaScript to display documents.

SOFTVERSKO INŽENJERSTVO - kolokvijum - Coggle Diagram

- - - - specifična svrha
      - nije u direktnoj vezi sa hardverom
      - oslanja se na sistemski softver (OS)
      - kupuje se odvojeno od hardvera
    - - programi na niskom nivou(low-level)
      - kontrola operacija nad računarskom opremom
  - - - veze između potproblema su izuzetno važne, jer mogu biti ključni faktor u nalaženju rešenja
      - razlaganje problema na delove, tj. potprobleme (PP) koje možemo da razumemo i rešimo
    - - sklapanje parcijalnih rešenja (R) u cilju nalaženja kompletnog rešenja problema
  - - - usled zloupotrebe
      - usled nestručnog rukovanja
    - - brza isporuka ostavlja malo vremena za testiranje, pa su greške češće
      - ponekad je teže ispraviti uočene nedostatke, nego napisati kompletan novi softver
    - - što je nedostatak duže neotkriven, njegovo otklanjanje više košta
  - - - Namenjen konkretnom naručiocu
      - Namenjen otvorenom tržištu
  - - - obavlja prve korake u razvoju, definiše zahteve sa korsinikom, sa projektantima generiše opis funkcija sistema
    - - projektuje sistema prema zahtevima
    - - prema projektu, piše programski kod na nekom programskom jeziku koristeći odgovarajuće razvojno okruženje
    - - detaljno testira napisani programski kod u cilju verifikacije i validacije sistema
    - - isporučuje i instalira softver u radnom okruženju, obučava korisnike i održava sistem
- - - - .. je uređeni skup zadataka koje treba uraditi da bi se napravio proizvod ili pružila usluga
        
        definisanje aktivnosti i resursa
        
        definisanje ograničenja (budžet, vremenski rokovi, prostor, redosled aktivnosti, raspoloživost alata,...)
    - - od početka izrade softvera do isporuke i održavanja
    - - .. je disciplina u razvoju u cilju veće efikasnosti
  - - - saradnja sa kupcem i korisnikom
      - analiza zahteva (entiteti, aktivnosti i ograničenja)
      - interakcija sistema sa okruženjem
      - rezultat faze - lista korisničkih zahteva
    - - prema zahtevima, pravi se projekat sistema koji daje plan rešenja
      - plan - arhitektura sistema, komponente i algoritmi
    - - generisanje potprojekata (modula) pogodnih za programsku realizaciju
      - veze između modula i načini razmene podataka
    - - izrada programskog koda prema projektu
    - - nalaženje i ispravljanje grešaka
      - jedinično testiranje
      - integraciono testiranje
      - sistemsko testiranje
    - - instaliranje softvera u radnom okruženju
      - obuka korisnika
    - - ispravljanje grešaka nakon isporuke
      - unapređivanje sistema (novi zahtevi ili promene u okruženju)
  - - - opis sistema postaje zajedničko shvatanje svih učesnika; lakša komunikacija, retka su pogrešna tumačenja
      - modelovanje odražava ciljeve razvoja ; pre implementacije se procenjuje usklađenost predviđenih aktivnosti sa postavljenim zahtevima
      - modelovanje pomaže u nalaženju nedoslednosti, suvišnih ili izostavljenih elemenata; bolje efikasnost
      - model odgovara konkretnoj, ali se može primeniti i u drugim situacijama; dobro je da ostane trag o projektu
  - - - Royce 1970. g., najstariji model
      - Osobine
        
        veoma visok nivo apstrakcije
        
        kaskadna veza faza
        
        kritične tačke i međuproizvodi
      - Prednosti
        
        jednostavnost - olakšava
        komunikaciju sa kupcima
        
        lako praćenje projekta
        
        laka primena modela - jedna iteracije, pogodan kada u krtkom roku treba zameniti stari sistem novim
      - Mane
        
        ne podržava povratne sprege koje postoje u stvarnosti (više iteracija, dopuna zahteva, greške u završnim fazama,..)
        
        ne ukazuje na način povezivanja faza (kako izlaz jedne faze transformisati u rezultat sledeće faze)
        
        razvoj softvera se ne posmatra kao rešavanje problema - model koristi industrijski pristup, a razvoj softvera je stvaralački a ne proizvođački proces
        
        ograničena interakcija sa korisnikom (samo u prvoj i poslednjoj fazi, što je malo)
      - slika slajd 7
    - - Nemačko ministarstvo odbrane, 1992. g.
      - Osobine
        
        modifikovan kaskadni model
        
        jedan od najčešće korišćenih
        
        eksplicitne povratne sprege
      - Kako se koristi V model?
        
        analiza zahteva, projektovanje sistema i programa, kodiranje
        
        testiranje
        
        ako se pojavi problem u nekoj fazi testiranja, ponavljaju se prethodne faze prema zadatim povratnim spregama
        
        nakon unosa potrebnih izmena, koriguje se programski kôd,
        a onda se ponovo sprovodi testiranje
        
        razvoj obično ima više ovakvih iteracija do konačne verzije sistema
      - Prednosti
        
        podržava povratne sprege - pogodan za razvoj složenih, realnih sistema
        
        omogućava verifikaciju i validaciju sistema
        
        daje kvalitetan proizvod - zbog strogo kontrolisanog procesa razvoja
        
        vodi računa o testiranju u ranim fazama projekta
      - Mane
        
        nedovoljna fleksibilnost - pri povratku na ranije faze nije dovoljno samo uneti izmene, već treba ažurirati sve naredne faze zajedno sa dokumentacijom
        
        zahteva obimne resirse i veća novčana sredstva jer je razvojni tim brojan
      - slika slajd 9
    - - velika konkurencija na tržištu diktira kraći razvoj; najveći prihod od novijih softvera
      - ubrzanje se postiže isporukom u fazama
      - svakoj fazi odgovara poseban skup funkcija; neke funkcije su u upotrebi, a neke u razvoju.
      - Inkrementalni razvoj (slajd 13)
        
        podela sistema na podsisteme (faze, verzije) prema funkcijama
        
        svaka nova verzija nadograđuje sistem do pune funkcionalnosti
        
        Prednosti:
        
        brza iporuka operativnog skupa funkcija - već nakon prve faze, korisnik ima skup funkcija
        
        vidljiv napredak na projektu - progres na projektu vidljiv ne samo preko dokumenata, već i u praktičnom radu
        
        permanentni odziv korisnika - stalna interakcija sa korisnikom vodi stabilnijim međurezultatima i sistemu uopšte
        
        mali projektni tim - manji troškovi, ali to može da utiče na kvalitet (prelazak sa jednog na drugi posao)
        
        primer slajd 13
      - Iterativni razvoj (slajd 15)
        
        podela sistema na podsisteme (faze, verzije) prema funkcijama
        
        u svim verzijama se isporučuje ceo sistem, uz menjanje funkcija svakog podsistema
        
        Prednosti:
        
        mogućnost rane obuke - već nakon prve faze delimična obuka može da počne (organizacija interfejsa, načini izvršavanja funkcija,...), korisnici sugerišu moguća poboljšanja
        
        česte isporuke - korisnici brže uočavaju probleme koji se onda lakše otklanjaju, velika odgovornost razvojnog tima po pitanju kvaliteta verzije
        
        mogućnost specijalizovanih verzija - u različitim verzijama, razvojni tim se može posvetiti usavršavanju tazličitih aspekata sistema
        
        primer slajd 15
      - slika slajd 12
    - - zasniva se na izradi prototipova (nekompletna verzija programa koji se razvija)
      - pomoću prototipova, za kratko vreme može se generisati ceo sistem ili njegovi delovi radi razjašnjenja otvorenih pitanja
      - svrha prototipova je da smanje rizik prilikom razvoja
      - prototipovi mogu da budu uključeni u finalni proizvod, ali i ne moraju
      - Prednosti
        
        redukovanje vremena i troškova - detaljna analiza pri izradi prototipa zahteva u ranoj fazi utvrđuje šta korisnik zaista želi, a time se ubrzava razvoj i smanjuju troškovi
        
        intenzivna interakcija sa korisnicima
      - Mane
        
        nedovoljna analiza - fokusiranje na prototipove odvraća od analize na nivou celog sistema, posledice mogu biti: predviđanje boljih rešenja, nekompletna specifikacija, konačna rešenja teška za održavanje
        
        konfuzija između prototipova i finalnih sistema - prototipovi nisu finalni proizvodi koje treba "samo malo doraditi", potreban je veliki napor za uvođenje provere grešaka ili mehanizama zaštite, korisnici prihvataju svojstva prototipa kao finalna iako će biti izbačena, pa nastaje konflikt sa razvojnim timom
      - slika slajd 17
    - - Boehm 1986. g.
      - vodi računa o postojećim rizicima
      - uobičajene aktivnosti u razvoju softvera se kombinuju
        sa analizom rizika
      - kombinuje kaskadni i prototipski model
      - namenjen razvoju velikih, složenih i skupih sistema
      - Model predstavlja iterativni razvoj u četiri iteracije:
        
        zahtevi i planiranje životnog ciklusa
        
        planiranje razvoja
        
        planiranje integracije i testiranja
        
        implementacija
      - Svaka iteracija obuhvata pun
        krug i prolazi kroz četiri kvadranta (slajd 22):
        
        kvadrant 1:
        
        odeređivanje ciljeva, alternativa i ograničenja
        
        kvadrant 2:
        
        evaluacija alternativa, identifikacija i procena rizika
        
        kvadrant 3:
        
        razvoj i verifikacija putemtestiranja
        
        kvadrant 4:
        
        planiranje sledće iteracije
      - Spiralni model slika slajd 23
      - Prednosti:
        
        redukovanje rizika - sistem se razvija izradom prototipa za najvažnije karakteristike, a onda se po testiranju prototipa unose izmene u sistem; tako su rizici najmanji
        
        dobra kontrola troškova - pošto su prototipovi mali, troškovi se lako procenjuju
        
        aktivno učešće korisnika
      - Mane:
        
        ograničena primena - model nije pogodan za manje projekte, već najbolje radi u slučaju velikih i složenih projekata
        
        neophodno znanje o rizicima - potreba velika veština u radu sa rizicima, uvošenje rizika uvećava troškove i to uvećanje može da bude veće od troškova izrade sistema
        
        složenost modela - striktno definisan protokol razvoja je nekada teško ispoštovati
    - - Balzer 1985. g.
      - pokušaj automatskog modelovanja procesa razvoja softvera
      - smanjuje se mogućnost greške uvođenjem niza unapred definisanih transformacija kojima se formalna specifikacija prevodi u proizvod koji se isporučuje
      - modelovanje se svodi na izbor sekvence transformacija (sekvenca se čuva u formalnom zapisu u okviru projekta) radi postizanja cilja projekta
      - tipične transofrmacije:
        
        prelazak sa jednog na drugi način predstavljanja
        podataka
        
        različiti algoritmi
        
        metode optimizacije
        
        prevođenje
      - model je mnogo obećavao
      - problem: formalnu specifikaciju nije lako napraviti
      - slika slajd 19
    - - Rational Software (IBM),1996.g.
      - Rational Unified Process je adaptivni proces razvoja opšte namene
      - razvojna organizacija selektuje elemente RUP a i formira proces razvoja koji joj najviše odgovara
      - iterativni postupak orijentisan ka arhitekturi i vođen slučajevima korišćenja
      - dobro strukturiran proces u kome je jasno ko , šta i kako treba da radi na projektu
      - lako se prilagođava i malim i velikim projektima i razvojnim timovima
      - rado korišćena metodologija od strane iskusnih razvojnih timova
      - Gradivni elementi RUP-a
        
        uloge (KO) - definišu skup povezanih veština, sposobnosti i
        odgovornosti
        
        prizvodi rada (ŠTA) - predstavljaju rezultat nekog zadatka, uključujući proizvode, modele, dokumentaciju,..
        
        zadaci (KAKO) - opisuju posao dodeljen koji proizvodi neki koristan rezultat
      - U svakoj iteraciji zadaci su organizovani u 9 disciplina
        
        Inženjerske discipline:
        
        poslovno modelovanje
        
        zahtevi
        
        analiza i projektovanje
        
        implementacija
        
        testiranje
        
        isporuka
        
        discipline za podršku
        
        konfiguracija i upravljanje izmenama
        
        upravljanje projektom
        
        okruženje
      - RUP posmatra životni proces kroz 4 faze:
        
        faza započinjanja –razumevanje ciljeva i obima projekta,definisanje funkcionalnosti i slučajeva korišćenja, predlog bar jednog rešenja, razmatranje troškova i rizika; rezulat faze: kritična tačka u kojoj se odlučuje da li je projekat izvodljiv i finansijski prihvatljiv (dalje |odustajanje)
        
        faza razrade –definisanje arhitekture sistema, cilj je smanjenje rizika u vezi sa zahtevima, arhitekturom i izborom alata; rezulat faze: kritična tačka u kojoj se gleda da li postoji detaljan plan o vođenju projekta i minimizaciji rizika (dalje | odustajanje ili suštinskeizmene)
        
        faza konstrukcije –razvoj komponenata, testiranje, izrada dokumentacije; rezulat faze: kritična tačka u kojoj se odlučuje da li je finalna verzija spremna zaisporuku(dalje | odustajanje ili povratak na neku prethodnufazu)
        
        faza tranzicije –isporučivanje gotovog proizvoda; rezulat faze: kritična tačka u kojoj se odlučuje da li je sistem stabilan, kompletan i potpuno spreman za isporuku(novi razvoj | povratak na neku prethodnufazu)
        
        slika slajd 29
      - Prednosti:
        
        visok nivo prilagodljivosti - RUP samo preporučuje, ništa ne zahteva
        
        iterativnost procesa - postepen razvoj vodi smanjenju troškova i vremenskimuštedama
        
        upravljanje rizicima - usmerava razvoj ka nižimtroškovima
      - Mane:
        
        neprilagođenost malim projektima - kod kojih faze započinjanja i razrade gube na značaju
        
        iterativnost procesa - može da bude i mana ukoliko su rukovodioci i razvojni timovi neiskusni, pa može da dođe do velikih propusta, čak i odustajanja od projekta
  - - - XP (Extreme Programming) - skup tehnika kojima se naglašava kreativnost timskog rada uz minimalno administriranje
      - Scrum - propisuje načine upravljanja zahtevima,
        iteracijama razvoja, implementacijom i isporukom
      - Crystal - familija metodologija fokusirana na razvojni tim, a
        ne na procese i proizvode; dobar razvojni tim najviše utiče na kvalitet proizvoda, a česte isporuke smanjuju potrebu
        za međuproizvodima
    - - slika slajd 31
  - - - osnovne vrednosti - osnovni kriterijumi za sagledavanje uspešnosti posla; međusobno povezane, poštuju agilne vrednosti i dalje ih nadograđuju; suviše opšte da bi se na osnovu njih definisali praktični mehanizmi; zato se uvode principi
        
        slika slajd 35
      - principi - otkrivaju različite alternative za odlučivanje koje uključuju osnovne vrednosti; konkretniji su; lakše se prevode u skup mehanizama koji se koristi u praksi
        
        slika slajd 36
      - prakse - skup praktičnih mehanizama pomoću kojih se izvode aktivnosti; razvojni tim mora vrlo disciplinovano da primenjuje obavezne prakse
        
        slika slajd 37
      - aktivnosti - iz principa proističu odluke koje se obaveznim praksama prevode u aktivnosti razvojnog tima; usmerene ka dobijanju kvalitetnog proizvoda u što kraćem vremenu i uz što manje troškove
        
        slika slajd 38
    - - fokusiranje tima na razvoj softvera - nema mnogo dokumentacije i sastanaka
      - prijatna radna atmosfera - mogućnosti za učenje i napredovanje, 8 časovno radno vreme, nema nezamenljivih
      - dobar softver po prihvatljivoj ceni - smanjen rizik jer se sve izmene prihvataju
    - - metod se teško sprovodi
      - nije lako naći dovoljno programera za rigorozno sprovođenje praksi
      - klijenti možda ne žele da se uključe u projekat zbog drugih obaveza
      - teško uklopiti karaktere u savršenu celinu
- - - - slika slajd 2
    - - slika slajd 3
    - - automatizacija poslova koji su se ranije obavljali ručno (elektronsko plaćanje, elektronsko naručivanje,...)
      - proširivanje ili poboljšanje postojećeg sistema (nove telefonske usluge, novi načini kreditiranja,...)
      - izrada novog sistema koji obavlja posao koji do tada nije bio rađen (doziranje leka, elektronsko izdavanje…)
  - - - precizno utvrđivanje ponašanja koje naručilac očekuje od softvera (ne vodeći računa o realizaciji)
    - - Zahtevi:
        
        svakog meseca se štampaju liste sa obračunom zarade za svakog radnika
        
        radnici koji se posebno ističu mogu dobiti stimulacije
        
        svakom radniku ostaviti mogućnost korišćenja godišnjeg odmora
        
        sistemu se može pristupati sa više lokacija u kompaniji
  - - - upoznati se sa procesom obavljanja posla
      - postavljati prava pitanja (čiji se odgovori mogu pretočiti u zahteve)
    - - intenzivnija saradnja, jer ni kupac nema praktičnih iskustava
      - ne ulagati previše napora i ne insistirati na potpunom definisanju skupa zahteva, jer će vremenom svi bolje razumeti problem, pa će zahtevi biti bolje definisani
  - - - suštinski - moraju da budu ispunjeni u konačnoj verziji softvera
      - poželjni - nije neophodno da budu ispunjeni, ali bi bilo dobro
      - opcioni - mogu se ispuniti, ali se mogu i izostaviti iz konačne verzije
      - Primer slajd 13
  - - - korisnik uočava koja funkcionalnost nedostaje, koje osobine nisu dovoljno korisne, koja su poboljšanja neophodna
      - projektant ispituje izvodljivost rešenja i mogućnosti optimizacije
    - - Ilustrativni prototip
        
        softver koji se razvija radi boljeg upoznavanja sa problemom
        
        ne ulazi u konačni proizvod
        
        ne mora se voditi računa o kvalitetu, efikasnosti, proveri grešaka
        
        brzo dovodi do suštine problema ili rešenja
        
        kad se dobiju odgovori, odbacuje se i prelazi na razvoj softvera
      - Evolutivni prototip
        
        razvija se sa ciljem da bude deo gotovog proizvoda
        
        pažljivo se razvija, vodeći računa o kvalitetu, odzivu, modularnosti,...
  - - - boljem razumevanju zahteva
      - lakšem uočavanju pitanja koja treba postaviti naručiocu/korisniku
      - lakšem nalaženju nedostataka (nepoznato ponašanje u pojedinim situacijama)
      - lakšem otkrivanju nedoslednosti u zahtevima (na pr. isti ulaz daje različite izlaze)
  - - - Chen, 1976. g.
      - grafička notacija za predstavljanje konceptualnih modela koja daje strukturiran pogled na problem
      - identifikuje objekte i entitete u sistemu, njihove osobine i međusobne odnose
      - osim za modelovanje zahteva, koristi se i za modelovanje dizajna sistema, strukture softvera, baze podataka,...
      - stabilan model (promene zahteva se uglavnom odnose na izmene u ponašanju entiteta, dok se skup entiteta ne menja)
      - nivo detalja modelovanja nije lako odrediti (šta su entiteti, a šta atributi)
      - koriste se u složenijim slučajevima
      - Primer Jackson i Zave, 1995. g., slajd 21
    - - grafički opis niza događaja koji se razmenjuju između entiteta (ponašanje)
      - opis se sastoji od vertikalnih i horizontalnih linija
        
        Vertikalne linije
        
        vremenske ose, vreme teče na dole
        
        na vrhu ose je naziv entiteta na koji se linija odnosi
        
        Horizontalne linije
        
        predstavljaju same događaje, tj. interakciju između entiteta
        
        mogu se shvatiti kao poruke koje entiteti razmenjuju
      - zahtev se dekomponuje na scenarije, a onda se za svaki scenario napravi trag
      - svaki dijagram predstavlja jedan trag od više mogućih
      - precizna i razumljiva semantika, pa se tragovi događaja često primenjuju
      - ne koriste se za kompletno modelovanje, jer bi broj tragova bio preveliki, već samo u početnoj fazi za ključne zahteve
      - Primer slajd 23
    - - grafički opis komunikacije između sistema i okruženja
      - definišu dinamičko ponašanje, tj. promene u ponašanju sistema usled nekih događaja
      - posebno pogodni za modelovanje različitog ponašanja izlaza sistema kada se na njegov ulaz dovede fiksna vrednost (sistemi kod kojih izlaz ne zavisi samo od ulaza, već i od trenutnog stanja sistema)
      - mogu se naći u određenom broju stanja
      - stanju odgovara stabilan skup uslova koji važe u intervalu između dva događaja
      - do promene stanja dolazi usled pojave događaja koji menja uslove u sistemu (pobudni događaj)
      - prelazi bez efekta se ne modeluju, da ne bi opterećivali model
      - Priemer slajd 25
  - - - dobru organizaciju zahteva
      - jasne tekstualne opise zahteva
      - preciznu prateću dokumentaciju u vidu raznih dijagrama i ilustracija
    - - Definicija zahteva
        
        dokument namenjen poslovnom auditorijumu (kupcima, naručiocima, korisnicima)
        
        kompletan spisak zahteva naručioca
        
        interakcija sa okruženjem
        
        entiteti iz okruženja i ograničenja vezana za entitete
      - Specifikacija zahteva
        
        dokument namenjen tehničkom auditorijumu (projektantima, rukovodiocima projekta, timovima za testiranje, održavanje)
        
        zahtevi o ponašanju softvera
        
        samo entiteti iz okruženja kojima se pristupa putem nekog interfejsa
  - - - skicirati opštu namenu sistema, uključujući ciljeve, veze sa drugim sistemima, uz uvođenje terminologije, oznaka, skraćenica i sl.
      - navesti razloge za razvoj sistema (zašto je postojeći sistem nezadovoljavajući, pa treba razvijati novi, koje delove postojećeg sistema treba zameniti, a koje ne i dr.)
      - opisati rešenje koje se predlaže kroz prikaz osnovnih funkcionalnosti na nivou slučajeva korišćenja
      - opisati okruženje u kome će sistem da radi (navođenje svih hardverskih i softverskih komponenata sa kojima će sistem biti u interakciji)
      - navesti pretpostavke vezane za ponašanje okruženja (uslovi koji mogu dovesti do otkaza sistema, kao i eventualne promene u okruženju koje mogu dovesti do promena zahteva)
  - - - detaljno opisati sve ulaze i izlaze (interfejs sistema), uključujući izvore ulaza, odredišta izlaza, dozvoljene opsege i formate ulaznih i izlaznih veličina, protokole razmene podataka, vremenska ograničenja, i sl.
      - prikazati zahtevanu funkcionalnost pomoću ulaza i izlaza korisničkog interfejsa, uključujući provere ispravnosti ulaznih i izlaznih veličina; za sve moguće vrednosti na ulazu, mora biti poznata vrednost na izlazu; ovde se mogu koristiti različite tehnike modelovanja (konačni automati, tragovi događaja i dr.)
      - utvrditi usklađenost svakog zahteva sa kriterijumom koji naručilac postavlja u pogledu kvaliteta
  - - - Da li su zahtevi ispravni? (odgovaraju shvatanjima naručioca)
      - Da li su zahtevi dosledni? (zahtevi mogu biti istovremeno ispunjeni)
      - Da li su zahtevi nedvosmisleni? (više osoba isto interpretira zahteve) Primer : “...odstupanje položaja osovine je malo"
      - Da li su zahtevi kompletni? (uzete u obzir sve moguće kombinacije ulaza) Primer: neplaćeno odsustvo, odmor, povišica, akontacija,...
      - Da li su zahtevi izvodljivi? Primer: oprečni zahtevi kao jeftin sistem, brz, sa obradom velike količine podataka
      - Da li je svaki zahtev relevantan? Primer: simulator tenka posada šalje e mail poruke (teška realizacija)
      - Da li je zahteve moguće testirati? (testiranje pre realizacije softvera) Primer: test za proveru mogućeg broja korisnika
      - Da li zahtevi mogu da se prate? (označavanje u dokumentima)
  - - - ispravnost zahteva (subjektivna procena)
      - doslednost zahteva (automatska procena)
      - nedvosmislenost zahteva (subjektivna procena)
      - potpunost zahteva (subjektivna procena)
      - relevantnost zahteva (subjektivna procena)
      - mogućnost praćenja zahteva (automatska procena)
  - - - formiranje izveštaja o uočenim greškama
    - - jedan od autora izlaže zahteve zainteresovanim subjektima
      - zainteresovani subjekti daju mišljenja i komentare
      - tehnika je pogodna kad ima mnogo zainteresovanih subjekata (da ne bi svi čitali pojedinačno)
    - - revizori se stavljaju u konkretne uloge (računovođa,...) i prate propisana pravila
    - - po raznim aspektima
      - ocenjuju svi učesnici na projektu (projektanti, naručioci,...) razne aspekte: ciljeve, namenu, funkcije, rizike,...
  - - - daje sigurnost da će sistem realizovan po datoj specifikaciji zadovoljiti zahteve korisnika
      - složen proces u kome treba dokazati da specifikacija obuhvata sve funkcije, događaje, aktivnosti i ograničenja iznete u zahtevima
      - često se, osim specifikacije, uključuju i pretpostavke o ponašanju okruženja
      - koriste se specijalizovani programi koji pretražuju prostor izvršavanja specifikacije; ovi programi su složeni i troše značajne resurse
- - - - osnova za projektovanje: specifikacija zahteva
      - cilj projektovanja : generisanje rešenja koje zadovoljava potrebe naručioca
      - broj mogućih rešenja je obično veliki (može i beskonačno)
        
        sva rešenja ispunjavaju isti cilj
        
        rešenja se razlikuju po aspektima kojima posvećuju veću pažnju
      - projektovanjem se utvrđuje skup komponenata od kojih će biti sastavljen sistem i njihovih međusobnih vezaurse
  - - - rezultat bilo koje metode je hijerarhija komponenata ili modula na više nivoa
      - slika slajd 5
  - - - projektovanje arhitekture sistema . Povezuju se mogućnosti sistema iz specifikacije zahteva sa komponentama (modulima) koje će biti implementirane. Arhitektura opisuje modularnu strukturu i načine povezivanja podsistema u sistem.
      - projektovanje programskog kôda . Obuhvata izbor programskog jezika , struktura podataka i algoritama za obradu. Utvrđuje se skup programskih modula , procedure i funkcije u njima.
      - završno projektovanje . Detaljnije opisuje implementaciju kroz formate podataka, protokole, upravljanje memorijom,...
  - - - cevi i filtri (slajd 8)
        
        koriste se u sistemima baziranim na tokovima podataka
        
        svaki korak u postupku procesiranja podataka izdvojen je u jednu filtarsku komponentu (krug na dijagramu)
        
        filtri rade nezavisno i nisu svesni postojanja drugih filtara u sistemu
        
        podaci prolaze kroz cevi koje povezuju filtre (linije sa strelicama)
        
        cevi se mogu koristiti za memorisanje ili za sinhronizaciju
        
        Primer slajd 8
        
        Prednosti:
        
        sistem se lako modifikuje dodavanjem novih filtara, ili uklanjanjem postojećih
        
        filtri predstavljaju nezavisne komponente koje se lako samostalno razvijaju
        
        filtri se mogu koristiti više puta , tj. moguće je generisati različite tokove kombinovanjem datog skupa filtara
        
        stil omogućava konkurentno procesiranje zato što filtri rade nezavisno i obavljaju svoju funkciju kada prime potrebne podatke, ne čekajući da se svi podaci učitaju ili obrade drugim filtrima
        
        jednostavna analiza ponašanja sistema
        
        Mane:
        
        podstiče se paketna obrada, pa stil nije dobar za interaktivne aplikacije
        
        nepotrebni gubitak vremena u transformacijama podataka (na pr. ulaz tekstualni, a filtar procesira realne brojeve)
        
        može se desiti da filtri ponavljaju pripremne funkcije drugih filtara, što utiče na pad performansi i povećanje stepena složenosti sistema (na pr. provera ispravnosti datuma)
      - slojevita arhitektura (slajd 11)
        
        dekomponuje aplikaciju u više apstraktnih nivoa
        
        svaki nivo predstavlja jedan sloj koji sadrži grupu zadataka
        
        slojevi su hijerarhijski raspoređeni tako da svaki sloj pruža usluge sledećem višem sloju u hijerarhiji
        
        usluge u jednom sloju implementiraju se korišćenjem usluga koje pruža prvi niži sloj u odnosu na posmatrani
        
        Primer slika slajd 11
        
        Prednosti:
        
        niži slojevi mogu biti više puta korišćeni od strane različitih viših slojeva
        
        postojanje slojeva čini lakšom standardizaciju zadataka
        
        razvoj i testiranje jednog sloja se obavljaju nezavisno od drugih slojeva, pošto se veze (interfejsi) između slojeva ne menjaju, već se sve promene obavljaju unutar sloja
      - klijent-server arhitektura (slajd 13)
        
        klijentske komponente zahtevaju usluge od servera
        
        serverska komponenta pruža usluge većem broju
        klijentskih komponenata
        
        serveri su stalno aktivni i osluškuju da li ima
        zahteva od klijenata
        
        zahtevi se šalju komunikacionim kanalima koji zavise od mašina na kojima se server i klijent nalaze
        
        Primeri slajd 13
        
        prispeli zahtevi se obično opslužuju u odvojenim nitima na serveru
        
        u komunikaciji često ima „ praznog hoda"
        
        zbog saobraćaja na mreži
        
        zbog neophodnog transformisanja zahteva i rezultata u formate koji su često različiti na serverskoj i klijentskog strani
        
        u distribuiranim sistemima sa više servera koji obavljaju istu funkciju, mora se obezbediti transparentnost (primer Google pretraživač)
      - ravnopravan pristup (slajd 15)
        
        može se shvatiti kao simetrična klijent server arhitektura
        
        ista komponenta može da radi i kao klijent (zahteva usluge od drugih komponenata) i kao server (pruža usluge drugim komponentama)
        
        komponenta može i da zadrži samo jednu funkcionalnost, bilo klijentsku ili serversku
        
        komponenta može dinamički da menja svoju ulogu između navedene tri
        
        Prednosti:
        
        komponente mogu da koriste ne samo svoje, već i kapacitete kompletne mreže
        
        administriranje je jednostavnije, zato što su ovakve mreže samoorganizujuće
        
        skalabilan i otporan sistem na otkaze pojedinih komponenata
        
        konfiguracija sistema se može menjati dinamički u toku rada (uključivanje i isključivanje komponenata)
        
        Mane:
        
        nema garancije u pogledu kvaliteta pruženih usluga, pošto komponente sarađuju na dobrovoljnoj osnovi
        
        teško je obezbediti sigurnost mreže
        
        performanse ovakvih sistema rastu sa povećanjem broja komponenata, ali i opadaju sa njegovim smanjenjem
      - arhitektura zasnovana na događajima (slajd 17)
        
        radi na principu difuzionog emitovanja poruka
        
        komponente (izvori događaja) šalju poruke o tome da je nastupio neki događaj na magistralu događaja
        
        ostale komponente na magistrali mogu događajima da pridružuju procedure (registrovanje procedura)
        
        zatim sistem poziva sve registrovane procedure
        
        Primer slajd 17
      - objektno orijentisani pristup (slajd 18)
        
        veliki broj savremenih sistema koristi delimično ili u celosti ovaj pristup
        
        problem i njegovo rešenje se organizuju kao skup objekata kojima se opisuju ne samo podaci, već i ponašanja
        
        pristup koristi enkapsuliranje informacija, pa mnogi projektanti posmatraju klase i objekte sa stanovišta mogućnosti njihovog ponovnog korišćenja u drugim projektima
        
        pristup se koristi u celom procesu razvoja (definisanje zahteva, projektovanje, programiranje, testiranje)
        
        Karakteristike:
        
        identitet. Podaci su organizovani u diskretne celine koje se nazivaju objektima. Objekat ima ime, svoja stanja i ponašanja (na primer, objekat brana , stanja potpuno_otvorena i potpuno_zatvorena , ponašanje zvučno_upozorenje kada branu treba otvoriti).
        
        apstrakcija. Predstavlja različite aspekte sistema . Skup apstrakcija formira hijerarhiju koja prikazuje međusobne odnose različitih pogleda na sistem.
        
        klasifikacija. Grupisanje objekata sa zajedničkim svojstvima i ponašanjem. Jedna grupa odgovara klasi koja može da ima svojstva (atributi) i ponašanja (operacije). Načini grupisanja mogu biti različiti (na primer, avioni i bicikli zasebne grupe, ili grupa prevozna sredstva). Objekat je instanca neke klase . Svaka instanca ima svoje vrednosti atributa , a sa ostalim instancama iz klase ima samo zajednička imena atributa.
        
        enkapsulacija. Pakovanje informacija tako da se spolja vidi ono što treba da bude vidljivo, a ostalo je sakriveno. Klasa enkapsulira atribute i ponašanja objekta skriva implementacione detalje.
        
        nasleđivanje. Organizovanje klasa u hijerarhiju na osnovu njihovih sličnosti i razlika. Na vrhu je klasa sa opštim osobinama , koja se rafinira u specijalizovane potklase. Potklasa nasleđuje strukturu, atribute i ponašanje nadređene klase.
        
        polimorfizam. Osobina da se isto ponašanje različito manifestuje kod različitih klasa i potklasa. Metod klase predstavlja implementaciju operacije klase. U sistemu sa polimorfizmom, više različitih metoda implementira istu operaciju.
        
        perzistencija . Sposobnost da ime, stanje i ponašanje objekta opstanu u vremenu, tj. da se očuvaju i nakon promene objekta. Takav objekat je trajan. Ovo se koristi ukoliko se vrednost nekog atributa često menja, a potrebno je sačuvati sve njegove vrednosti.