Prvi kolokvijum Flashcards
Navesti i kratko opisati atribute dobrog softvera.
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, bezbedan i siguran
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
Šta je softver i čime se bavi softversko inženjerstvo?
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
– sistemske dokumentacije
– korisničke dokumentacije
– 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 čemu se razlikuje softversko inženjerstvo od informatike (nauke o računarstvu)?
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, nove izmene softvera postaju sve složenije i skuplje.
Razvoj softvera po modelu vodopada (dijagram, prednosti i problemi).
Faze modela vodopada
* Analiza i definicija zahteva
* Projektovanje sistema i softvera:
* Implementacija i testiranje
* Integrisanje i testiranje sistema
* Eksploatacija i održavanje
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. Ovaj model je jedino pogodan kada su zahtevi dobro poznati.
Prednosti modela vodopada: Model vodopada se najčeće koristi kod velikih sistema gde je 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.
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
* Prikupljanje i analiza zahteva
* Specifikacija zahteva
* Validacija zahteva
Projektovanje i implementacija softvera - reč je o procesu prevođenja specifikacije sistema u realni upotrebljiv sistem.
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. Aktivnosti u projektovanju su :
* Arhitekturno projektovanje
* Projektovanje interfejsa
* Projektovanje komponenti.
* Projektovanje baze podatka.
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 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.
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.
Vizija sistema sadrži:
* Pozicioniranje proizvoda
* Opis korisnika
* Opis proizvoda
* Funkcionalni zahtevi
* Nefunkcionalni zahtevi
* Ograničenja
* Kvalitet
Faza 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, 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
– Test specifikacija
– Detaljni projekat 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
– 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?
Upravljanje zahtevima je jedan od osnovnih principa za uspešan razvoj softvera po RUP-u.
Ono znači prevođenje zahteva korisnika u skup njihovih potreba i funkcija sistema. Ovaj skup se kasnije pretvara u detaljnu specifikaciju funkcionalnih i nefunkcionalnih zahteva. Detaljna
specifikacija se prevodi u test procedure, projekat I korisničku dokumentaciju.
Potrebno je definisati proceduru u slučaju promene zahteva korisnika.
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). 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).
* 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.
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.
* Scenariji 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)
o Uz saradnju, ne samo Scrum master
* Uzima se u obzir high-level dizajn rešenja
Dnevni scrum sastanak
* Parametri
o Dnevno
o 15 minuta
o Stand-up
* Nije za rešavanje problema
o Svi su pozvani
o 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
o Pravilo 2-satne pripreme
o 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 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.
Navesti i kratko opisati kategorije strategija za upravljanje rizikom
Strategija izbegavanja
– Smanjiti verovatnoću pojave rizika
– Primenjeno kod defekta u komponentama
Strategije minimizacije
– Smanjiti uticaj rizika na projekat ili proizvod
– Primenjeno kod bolesti osoblja
Planovi za nepredviđene događaje
– Ako se rizik pojavi, ovi planovi definišu kako se radi
– sa rizikom
– Primenjeno kod finansijskih problema organizacije
