SWE pitanja Flashcards
Navesti i kratko opisati atribute dobrog softvera
Softver treba da ima funkcionalnost i performanse saglasno zahtevu korisnika. Takodje, mora biti pogodan za održavanje, da je upotrebljiv i da uliva poverenje.
Pogodnost za održavanje – Treba da je u stanju da se lako menja i nadogradjuje
Stabilnost – Softver mora ulivati poverenje, što podrazumeva da je softver pouzdan (reliability), bezbedan (security) i siguran (safety)
Efikasnost – Softver mora ekonomično koristiti resurse sistema (procesorsko vreme, memoriju)
Upotrebljivost – Softver mora biti ugodan za korišćenje, da ima odgovarajući korisnički interfejs i adekvatnu dokumentaciju
Sta je softver i cime se bavi softversko inzenjerstvo?
Softver je računarski program, pridružena dokumentacija i konfiguracioni podaci neophodni da bi softver radio korektno.
Softverski sistem se obično sastoji od :
– određenog broja programa
– konfiguracionih fajlova, koji se koriste da postave ove programe
– sistemske dokumentacije, koja opisuje strukturu sistema
– korisničke dokumentacije, koja objašnjava kako se koristi sistem
– Web sajtova za korisnike
Softversko inženjerstvo je inženjerska disciplina koja se bavi teorijom, metodama i alatima za profesionalni razvoj softvera.
Postoje 2 osnovna tipa SW proizvoda:
Generički – za slobodno tržište
Ugovorni – za određenog nalogodavca
Po cemu se razlikuje softversko inzenjersvto od informatike?
Nauka o računarstvu ili Informatika se bavi teorijom i osnovama računarstva.
Softversko inženjerstvo se bavi praktičnom stranom razvoja i isporuke korisnog softvera.
Teorija nauke o računarstvu je trenutno dovoljno razvijena i obezbeđuje solidnu osnovu za softversko inženjerstvo.
Grafički ilustrovati i opisati inkrementalni razvoj softvera. Navesti osnovne prednosti i nedostatke.
Umesto da se sistem isporuči odjedanput, razvoj i isporuka se mogu razdeliti u inkremente pri čemu svaki inkrement obezbeđuje deo tražene funkcionalnosti.
Prednosti inkrementalnog razvoja:
* Smanjena cena izmene korisničkih zahteva u toku razvoja - količina analiza i dokumentacije koju treba ponovno uraditi je mnogo manja u odnosu na model vodopada.
* Olakšano dobijanje povratne informacije od korisnika u toku razvoja - korisnici imaju uvid i mogućnost komentarisanja trenutno implementiranih funkcionalnosti, a samim tim i u progres realizacije projekta.
* Moguća brža isporuka korisnog softvera naručiocu - korisnici mogu da koriste softver pre nego u slučaju modela vodopada.
Problemi inkrementalnog razvoja:
* Proces nije vidljiv - menadžerima su potrebne redovne isporuke kako bi merili napredovanje. Ako se sistem brzo razvija nije efikasno praviti dokumentaciju za svaku verziju sistema.
* Struktura sistema ima tendenciju degradacije sa dodavanjem novih inkremenata - ukoliko se ne ulaže novac u refaktorisanje i unapređenje softvera, periodične izmene imaju za posledicu degradaciju strukure. Nove i nove izmene softvera postaju sve složenije i skuplje. FALI SLIKA
Razvoj softvera po modelu vodopada (dijagram, prednosti i problemi).
Faze modela vodopada
* Analiza i definicija zahteva: Servisi, ograničenja i ciljevi sistema se postavljaju u saradnji sa korisnikom. Zatim se to definiše detaljni i to služi kao specifikacija sistema
* Projektovanje sistema i softvera: Zahtevi se dele na SW i HW. Postavlja se arhitektura celog sistema. Projektovanje SW obuhvata identifikovanje komponenti i njihovih veza
* Implementacija i testiranje: Pišu se i programske komponente. Testiraju se programi i komponente radi provere da li su saglasni sa specifikacijom
Nenad Đorđević 16080
Page 3 of 15
* Integrisanje i testiranje sistema: Programi i programske komponente se integrišu i testira se sistem kao celina radi provere da li je usklađen sa SW zahtevima. Nakon toga se sistem isporučuje
* Eksploatacija i održavanje: Nakon puštanja sistema u eksploataciju nastaje njegova evolucija
Nedostaci modela vodopada: Osnovni nedostatak ovog modela je nemogućnost efikasnog prihvatanja izmena u zahtevima korisnika kada je proces u toku. U principu, jedna faza mora biti završena da bi se otpočela naredna, pa izmene zahteva resetuju čitav proces. Takođe, nefliksibilna deoba projekta na disjunktne faze otežava odgovor na promenu korisničkih zahteva. Ovaj model je jedino pogodan kada su zahtevi dobro poznati.
Prednosti modela vodopada: Model vodopada se najčeće koristi kod velikih sistema gde se razvoj razdeljen na nekoliko lokacija. U ovim situacijama planom vođena priroda modela vodopada pomaže u koordinisanju posla.
Navesti i kratko opisati zajedničke aktivnosti za različite softverske procese.
Aktivnosti u okviru procesa Realni softverski procesi predstavljaju isprepletenu mešavinu aktivnosti čiji je krajnji cilj specifikacija, projektovanje, implementacija i testiranje softverskog sistema. Četiri osnovne aktivnosti softverskog procesa specifikacija, razvoj, validacija i evolucija su različito organizovane u različitim procesima.
Specifikacija softvera je proces određivanja servisa zahtevanih od strane korisnika, kao i ograničenja u pogledu funkcionisanja i razvoja sistema. Proces inženjeringa zahteva:
* Studija izvodljivosti - Provera da li je tehnički i finasijski izvodljiv razvoj sistema
* Prikupljanje i analiza zahteva - Određivanje šta zainteresovane strane žele ili očekuju od sistema
* Specifikacija zahteva - Detaljno definisanje zahteva
* Validacija zahteva - Provera validnosti specificiranih zahteva
Projektovanje i implementacija softvera - reč je o procesu prevođenja specifikacije sistema u realni upotrebljiv sistema.
Projektovanje softvera - projektovanje strukture softvera tako da realizuje zadatu specifikaciju;
Implementacija - prevodjenje definisane strukture u izvšni program;
Aktivnosti projektovanja i implementacije su blisko povezane i često se preklapaju.
* Arhitekturno projektovanje u okviru kog se identifikuje osnovna strukutra sistema, osnovne komponente (često se nazivaju podsistemi ili moduli), njihova međusobna veza i način distribucije.
* Projektovanje interfejsa u okviru kog se definišu interfejsi između komponenti sistema.
* Projektovanje komponenti u okviru kog se za svaku identifikovanu komponentu projektuje željeno funkcionisanje.
* Projektovanje baze podatka u okviru kog se projektuju strukture podataka sistema i način njihove reprezentacije u bazi podataka.
Nenad Đorđević 16080
Page 4 of 15
Validacija softvera
Verifikacija i validacija (V & V) ima za cilj da pokaže da sistem odgovara sopstvenoj specifikaciji i zahtevima naručioca. Uključuje proveru i pregled procesa, kao i testiranje sistema. Testiranje sistema uključuje izvršenje test slučajeva koji se izvode iz specifikacije realnih podataka koje sistem obrađuje.
Evolucija softvera
Softver je podrazumevano fleksibilan i podložan izmenama. Kako se zahtevi menjaju kroz promenu poslovnih okolnosti, softver koji podržava odgovarajući posao mora da evoluira i da se menja. Iako često dolazi do mešanja između novog razvoja I evolucije (održavanja) postojećeg sistema, sama razlika postaje sve manje relevantna pošto imamo sve manje potpuno novih sistema.
Grafički ilustrovati i kratko opisati „4+1“ model sistema.
Logička arhitektura - opisuje najvažnije klase u sistemu, njihovu organizaciju u pakete i podsisteme kao i organizaciju paketa i podsistema u nivoe (layers).
Za predstavljanje logičke arhitekture se koriste dijagrami klasa. Mogućnost automatskog generisanja koda na osnovu dijagrama klasa
Procesna arhitektura - opisuje najvažnije procese i niti (threads) u sistemu i njihovu organizaciju. Procesi se izvršavaju u nezavisnim adresnim prostorima računara, dok su niti procesi koji se izvršavaju paralelno sa procesima ili drugim nitima ali u adresnom prostoru nekog od procesa. Za procesne arhitekture se koriste dijagrami klasa.
Implementacioni model - Za prikaz implementacionog modela se koriste dijagrami komponenti.
Fizički model - opisuje fizičke čvorove u sistemu i njihov razmeštaj u prostoru. Za prikaz fizičkog modela se koriste dijagrami razmeštaja.
Navesti i kratko opisati faze u RUP-u. Objasniti odnos faza i iteracija u RUP-u.
Isto kao za ono drugo pitanje za rup
Navesti faze RUP metodologije i objasniti šta se dobija kao rezultat svake od faza.
Faze su:
1. Početna faza (Inception)
2. Faza razrade (Elaboration)
3. Faza izrade (Construction)
4. Faza isporuke (Transition)
Svaka faza može imati proizvoljan broj iteracija i svaka iteracija (osim, naravno, početne) treba da rezultira izvršnom verzijom koja se može testirati.
Početna faza:
* Analiza problema
* Razumevanje potreba (potencijanih) korisnika
* Generalno definisanje sistema
* Upravljanje kod promena korisničkih zahteva
Rezultat ove faze je dokument: Vizija sistema - Piše se bez mnogo tehničkih detalja tako da bude razumljiva i korisnicima i razvojnom timu. Koriste se samo blok dijagrami za šematski prikaz sistema.
Vizija sistema sadrži:
* Pozicioniranje proizvoda
* Opis korisnika
* Opis proizvoda
* Funkcionalni zahtevi
* Nefunkcionalni zahtevi
* Ograničenja
* Kvalitet
Faza elaboracije/razrade:
* Izrada plana projekta
* Organizacija i ekipni rad
* Detaljna definicija zahteva
* Definisanje arhitekture sistema
Rezultati ove faze su:
– Plan projekta (Plan faza, Plan izrade, Rezultati projekta, Kontrolne tačke (milestones), Resursi)
– Use-case specifikacija (Opis slučajeva korišćenja, Definisanje aktera u sistemu, Određivanje arhitekturno najznačajnijih slučajeva korišćenja)
– Arhitekturni projekat sistema (Definisanje arhitekture sistema, Definisanje najbitnijih klasa, Realizacija arhitekturno najznačajnijih slučajeva korišćenja (preko sequence diagram), UML dijagrami klasa)
Faza izrade:
* Realizacija sistema
* Testiranje
Rezultati ove faze su:
– Plan testiranja (Zahtevi testiranja, Strategija testiranja, Tehnike testiranja, Alati za testiranje, Resursi, Proizvodi, Kontrolne tačke)
– Test specifikacija (Test-case-ovi sadrže: Opis, Radnje-ulazi, Očekivani odzivi-izlazi, Završne radnje)
– Detaljni projekat sistema (Arhitekturni projekat razvijen u detalje, Dijagrami klasa, “4+1” model sistema)
– Softverski proizvod
Faza isporuke:
* Finalizacija softverskog sistema
* Alfa (beta) testiranje
* Izrada korisničke dokumentacije (uputstva)
* Obuka korisnika
* Uvođenje sistema kod korisnika
Rezultati ove faze su:
– Test izveštaji - Pregled rezultata testiranja (Generalna procena testiranog SW-a, Uticaj test okruženja, Predložena poboljšanja), Rezultati izvršenja test-case-ova
– Korisničko uputstvo
– Instalacija sistema
Navesti osnovne principe agilnog razvoja softvera izražene kroz „Agile Manifesto“.
Principi:
– Zadovoljstvo korisnika brzom isporukom korisnog softvera
– Mogućnost promene zahteva, čak i u poodmakloj fazi razvoja
– Česta isporuka softvera, u razmaku od par nedelja
– Ispravan softver je osnovna mera napretka
– Razvoj koji je u stanju da održi konstantan tempo
– Bliska saradnja između projektanata i poslovnih saradnika
– Najbolji tip komunikacije je komunikacija “licem-u-lice”
– Projekti se izvode u okruženju u kojem su motivisani pojedinci, u koje se može imati poverenja
– Kontinualno usmeravanje pažnje ka tehničkoj veštini i dobrom dizajnu
– Jednostavnost
– Samoorganizovani timovi
– Prilagođavanje promenljivim okolnostima
Šta predstavlja upravljanje zahtevima?
SLIKA FALI
Svaki od funkcionalnih i nefunkcionalnih zahteva evoluira kroz različite fokuse i perspektive, definišući različite nivoe detalja u zahtevima. Svaka nenamerna praznina u zahtevima povećava rizik propadanja projekta ili dodavanja druge mane.
Upravljanje zahtevima je više od dokumentovanja istih. Šest preporuka “dobre prakse” za upravljanje zahtevima:
1. Odvojite dovoljno vremena za proces definisanja zahteva.
2. Izaberite pravi pristup za iznošenje zahteva.
3. Prenesite – saopštite zahteve svim interesnim stranama.
4. Razvrstajte zahteve po prioritetu.
5. Zahtevi za ponovno korišćenje – reuse.
6. Pratite zahteve kroz životne cikluse softvera.
Proces upravljanja zahtevima sastoji se od međusobno nerazdvojivih podprocesa, koji se ne mogu zasebno i sekvencijalno odvijati:
* Prikupljanje zahteva
* Analiza zahteva
* Specifikacija zahteva
* Validacija zahteva
SLIKA FALI
Objasniti osnovne tipove veza kod Use-case dijagrama i ilustrovati jednim dijagramom.
Osnovni tipovi veza su Relacije – predstavljaju povezanost aktera i slučajeva korišćenja.
* Asocijacije – relacija komunikacije; puna linija od aktera do slučaja korišćenja; komunikaciju iniciraju i jedna i druga strana.
* Zavisnosti – konkretno se koriste dva stereotipa ove relacije: uključivanje («include») i proširivanje («extend»). Predstavlja se isprekidanom linijom sa strelicom. Uključivanje od jednog ka drugom slučaju korišćenja (od A ka B) govori o tome da će ponašanje A da uključi i ponašanje B (ne važi obrnuto). Uključivanjem se opisuje zajedničko ponašanje između dva ili više slučaja korišćenja. Proširivanje od A ka B znači da B može da obuhvati i ponašanje iz A (može da se proširi). Proširivanje se događa u tačno određenim tačkama koje se nazivaju tačke ekstenzije.
* Generalizacije – nasleđivanje; puna linija sa trougaonom strelicom. Generalizacija od A ka B kaže da je A specifičan slučaj korišćenja u odnosu na B.
Use-case metoda i scenariji događaja. Ilustrovati na primeru.
Slučajevi korišćenja predstavljaju tehniku baziranu na scenarijima i zapisanu pomoću UML dijagrama koja identifikuje aktere u sistemu i slučajeve korišćenja sistema.
Use-case metoda
* Sistem se posmatra sa stanovišta korisnika sistema.
* Opisuju se slučajevi korišćenja sistema i scenarija ponašanja.
* Koristi se UML notacija.
* Koristi se kod RUP modela razvoja SW-a.
* Servisi objekata mogu biti otkriveni i modeliranjem scenarija događaja za različite funkcije sistema.
* Događaji se prate do objekata koji reaguju na njih.
* Tipičan model scenarija događaja je interakcija između korisnika i sistema.
* Scenarija događaja su primeri kako će sistem biti korišćen u realnom životu. Oni bi trebalo da uključe:
– Opis početne situacije;
– Opis normalnog toka događaja;
– Opis izuzetaka (ako se izađe iz normalnog toka);
– Informacije o konkurentnim aktivnostima;
– Opis stanja gde se scenario završava.
Navesti koji sve sastanci po Scrum-u postoje i kratko ih opisati.
Postoje 4 vrste sastanaka:
Planiranje sprinta
* Tim bira stavke iz product backlog-a za koje može da se obaveže da ih može završiti
* Kreira se Sprint backlog (Identifikuju se zadaci)
* Uz saradnju, ne samo Scrum master
* Uzima se u obzir high-level dizajn rešenja
Dnevni scrum sastanak
* Parametri
* Dnevno
15 minuta
* Stand-up
* Nije za rešavanje problema
* Svi su pozvani
* Samo članovi tima, scrum master i vlasnik proizvoda smeju da pričaju
* Pomaže da se izbegnu ostali nepotrebni sastanci
Pregled sprinta
* Tim prezentuje ono što je urađeno za vreme sprinta
* Tipično u formi demonstracije novih funkcionalnosti ili upotrebljene arhitekture
* Neformalno
* Pravilo 2-satne pripreme
* Bez slajdova
* Učestvuje ceo tim
* Svi su pozvani
Retrospektiva sprinta
* Periodično razmatranje šta je dobro, a šta ne
* Tipično 15–30 minuta
* Radi se posle svakog sprinta
* Ceo tim učestvuje
Navesti i kratko opisati kategorije zahteva.
Kategorije zahteva
* Funkcije: “šta” sistem mora da bude sposoban da uradi.
* Osobine: “koliko dobro” će funkcije biti izvršavane.
* Cena: koliko će koštati (bilo koji ulazni resurs: novac, ljudi, ili vreme) kreiranje i održavanje funkcija i njihovih osobina.
* Ograničenja: bilo koja restrikcija u slobodi definisanja zahteva ili dizajnu.
Tipovi zahteva
* Nije kvantifikovan, ali je testiranjem moguće utvrditi da je realizovan
* Kvantifikovan (na mernoj skali)
* Funkcije se ne mogu kvantifikovati, one ili su ili nisu prisutne.
* Sve osobine i cena se mogu i moraju kvantifikovati.
* Ograničenja mogu biti bilo kog tipa.
Nefunkcionalni zahtevi: Ograničenja u projektu se moraju takođe definisati. Kategorije ograničenja: Nivo kvaliteta, Nivo cene, Funkcionalnost, Dizajn, Politička, Kulturološka, Pravna
Lažni zahtevi.
1. Zahtevi nisu iskazani na kvantifikovan i merljiv način:
“smanjena cena”,
* “poboljšana kontrola upravljanja”,
* “visoka upotrebljivost”,
* “povećano zadovoljstvo kupca”,
2. Ideje o projektovanju umesto stvarnih zahteva.
* “zahteva se objektno orjentisana baza podataka”,
* “potrebno je poboljšano uputstvo za rukovanje”,
* “obezbediti Windows XP interfejs”.
