1. PROCESI PROGRAMSKOG INŽENJERSTVA
U ovoj prezentaciji razmatraju se strukturirane aktivnosti kojima je cilj razviti funkcionalni programski produkt.

2. Satish Mishra (1997). “Visual Modeling & Unified Modeling Language (UML) : Introduction to UML”. Rational Software Corporation

3. PROCESI PROGRAMSKOG INŽENJERSTVA
Sadržaj ove prezentacije:
Procesi i modeli procesa programskog inženjerstva.
Iteracije u modelima procesa programskog inženjerstva.
Generičke aktivnosti u procesima programskog inženjerstva.
CASE tehnologije za potporu aktivnostima u procesima programskog inženjerstva.
Zaključci

4. PROCESI PROGRAMSKOG INŽENJERSTVA
Procesi i modeli procesa programskog inženjerstva.
Iteracije u modelima procesa programskog inženjerstva.
Generičke aktivnosti u procesima programskog inženjerstva.
CASE tehnologije za potporu aktivnostima u procesima programskog inženjerstva.
Zaključci

5. Procesi i modeli procesa programskog inženjerstva
Uvodne definicije:
Proces programskog inženjerstva je strukturirani skup aktivnosti potreban da se oblikuje i razvija programski produkt.
Generičke aktivnosti u procesima programskog inženjerstva pojavljuju se u svakom procesu u malo promijenjenom slijedu.
Model procesa programskog inženjerstva je apstraktna (pojednostavljena) reprezentacija procesa. Predstavlja opis procesa iz određene perspektive.

6. NAJZNAČAJNIJI MODELI Vodopadni (engl. waterfall)
Odvojene i specifične faze specifikacije i razvoja
2. Evolucijski (engl. evolutionary development)
Specifikacija, razvoj i validacija su isprepleteni
3. Komponentno usmjeren (engl. component-based)
Sustav se gradi od postojećih komponenata
4. RUP (engl. Rational Unified Process)
Temelji se na oblikovanju preko modela
(engl. Model Based Design, MBD)
5. Agilni pristup (engl. Agile software development)
Postoje mnoge varijacije ovih modela (npr. model u kojem se vodopadni slijed aktivnosti preslikava u formalnu specifikaciju).

7. 1. Vodopadni model programskog inženjerstva
Zahtjevi
1. Vodopadni model programskog inženjerstva
Implementacija i ispitivanje dijelova
Oblikovanje
Integracija i ispitivanje sustava
Održavanje sustava u radu

8. PROCESNE FAZE U VODOPADNOM MODELU
Analiza zahtjeva i definicije
Razvoj i oblikovanje sustava i programske potpore
Implementacija i ispitivanje (testiranje) modula
Integracija i testiranje sustava
Uporaba sustava i održavanje
Temeljna značajka vodopadnog modela:
Pojedina faza se mora dovršiti prije pokretanja nove faze (nema povratne veze između susjednih faza).

9. PROBLEMI VODOPADNOG MODELA
Nefleksibilna particija projekta u odvojene dijelove čini implementaciju promjena koje zahtijeva kupac vrlo teškom (temeljni nedostatak vodopadnog modela).
Model je prikladan samo ako su zahtjevi dobro razumljivi i eventualne promjene svedene na minimum.
Vrlo malo poslovnih sustava ima stabilne zahtjeve.
Vodopadni model se uglavnom koristi za velike inženjerske projekte gdje se sustav razvija na nekoliko odvojenih mjesta.

10. 2. EVOLUCIJSKI MODEL RAZVOJA I OBLIKOVANJA
Dva uobičajena postupka:
Istraživački razvoj i oblikovanje (engl. exploratory development)
Cilj ovakvog pristupa je kontinuiran rad s kupcem na temelju inicijalne specifikacije. Započinje se s dobro definiranim početnim zahtjevima i razumijevanjem kako dijelovi sustava funkcioniraju, a nove funkcionalnosti se dodaju temeljem prijedloga kupca.
Metoda odbacivanja prototipa (engl. throwaway prototyping)
Cilj je bolje razumijevanje zahtjeva sustava. Započinje se sa slabo definiranim zahtjevima koji se tijekom postupka razjašnjavaju u smislu što je doista potrebno. Za to se koriste prototipovi.

11. EVOLUCIJSKI MODEL RAZVOJA I OBLIKOVANJA
Ponavljanje aktivnosti: specifikacija, razvoj, validacija
Početna inačica, među-inačice, završna inačica
Temeljem zahtjeva

12. EVOLUCIJSKI MODEL RAZVOJA I OBLIKOVANJA
Problemi:
Proces razvoja i oblikovanja nije jasno vidljiv (otežava posao voditeljima projekta).
Sustavi su često vrlo loše strukturirani zbog stalnih izmjena.
Često su potrebne posebne vještine (npr. brzi razvoj prototipa – engl. Rapid System Prototyping).
Primijenjivost:
Za male i srednje interaktivne sustave.
Za dijelove velikih sustava (npr. korisničko sučelje).
Za sustave s kratkim vijekom trajanja.

13. 3. MODEL PROGRAMSKOG INŽENJERSTVA ZASNOVAN NA KOMPONENTAMA
(engl. Component Based Software Engineering - CBSE)
Sustav se integrira višestrukom uporabom postojećih komponenata ili uporabom komercijalnih, gotovih komponenata (COTS: engl. commercial-of-the-shelf).
Stupnjevi procesa:
Specifikacija i analiza zahtjeva
Analiza komponenata
Modifikacija zahtjeva (jer su komponente fiksirane)
Oblikovanje sustava s višestrukom uporabom komponenata (engl. reuse)
Razvoj i integracija
S povećanom standardizacijom komponenata CBSE se sve više prihvaća u razvoju sustava.

14. MODEL PROGRAMSKOG INŽENJERSTVA TEMELJEN NA VIŠESTRUKOJ UPORABI KOMPONENATA
Oblikovanje sustava temeljeno na ponovnoj uporabi komponenata
Analiza knjižnice komponenata
Promjena zahtjeva jer su komp. fiksirane
Specifikacija temeljena na zahtjevima
Razvoj i integracija
Validacija sustava

15. 4. RATIONAL UNIFIED PROCESS (RUP)
Moderan model procesa programskog inženjerstva izveden na temelju jezika za modeliranje UML (engl. Unified Modeling Language) i pridruženih aktivnosti.
Najčešće opisan kroz tri perspektive:
Dinamička perspektiva koja pokazuje slijed faza procesa kroz vrijeme.
Statička perspektiva koja pokazuje aktivnosti u pojedinim fazama procesa.
Praktična perspektiva koja sugerira aktivnosti kroz iskustvo i dobru praksu.

16. Preuzeto iz:
UML i RUP Ivar Jacobson Rational Software
Prilagodio: N.Bogunović

17. Prije UML-a 1960-te – 1970-te 1980-te – rane 1990-te
programiranje
1960-te – 1970-te
COBOL, FORTRAN, C
Tehnike strukturne analize i oblikovanja
1980-te – rane 1990-te
Smalltalk, Ada, C++, Visual Basic
Rane generacije OO metoda
Sredina i kasne 1990-te
Java
UML
Unified Process (RUP)
modeliranje

18. Temelji UML-a UML je jezik za: vizualizaciju specifikaciju
oblikovanje (i konstruiranje)
dokumentiranje
artefakata programske potpore.
UML je posebice prikladan za specificiranje objektno usmjerene arhitekture programske potpore.
Dijelovi UML-a pogodni su u specificiranju i drugih arhitektura.
Uvođenje arhitekture programske potpore: to je struktura ili strukture sustava koji sadrži elemente, njihova izvana vidljiva obilježja i odnose između njih.

19. Prednosti UML-a Otvoren standard.
Podupire cijeli životni ciklus oblikovanja programske potpore.
Podupire različite domene primjene.
Temeljen je na iskustvu i potrebama zajednice oblikovatelja i korisnika programske potpore.
Podržavaju ga mnogi alati.

20. Mnogo dionika, mnogo pogleda
Arhitekturu programske potpore različito vidi:
Korisnik-kupac
Projekt manager
Inženjer sustava
Osoba koje razvija sustav
Arhitekt
Osoba koja održava sustav (engl. maintainer)
Drugi dionici
Višedimenzionalna realnost
Mnogo dionika rezultira u
višestrukim pogledima, višestrukim nacrtima

21. Koliko pogleda ? Pogledi odgovaraju nekom kontekstu.
Svi sustavi ne trebaju sve poglede:
Jedan procesor, nije potreban nacrt razmještaja procesora.
Jedan proces, nije potreba nacrt razmještaja procesa.
Vrlo mali programi, nije potreban nacrt implementacije.
Neki dodatni pogledi:
Pogled podataka, pogled sigurnosti u sustavu
Svaki pogled dokumentira se nacrtom – DIJAGRAMOM.
Više pogleda (dijagrama) u okviru nekog konteksta = MODEL
Model je apstraktan (reduciran, pojednostavljen, smanjen, ograničen) opis sustava iz određene perspektive.

22. UML (v1.3) Modeli i Dijagrami
State
Diagrams
State
Diagrams
Class
Diagrams
Use Case
Diagrams
Use Case
Diagrams
State
Diagrams
Use Case
Diagrams
Use Case
Diagrams
State
Diagrams
Use Case
Diagrams
Object
Diagrams
Sequence
Diagrams
Scenario
Diagrams
State
Diagrams
Scenario
Diagrams
State
Diagrams
Collaboration
Diagrams
Component
Diagrams
Models
Scenario
Diagrams
Component
Diagrams
Scenario
Diagrams
Component
Diagrams
Statechart
Diagrams
Deployment
Diagrams
Activity
Diagrams

23. Dijagrami Pojedini dijagram je pogled u model
Prikazan s aspekta određenog dionika
Daje određeno predstavljanje sustava
Semantički je konzistentan s ostalim pogledima
U okviru UML v1.3 postoji devet standardnih dijagrama:
Statički pogledi: use case, class, object, component, deployment
Dinamički pogledi: sequence, collaboration, statechart, activity
U RUP procesu svakoj aktivnosti pridružen je jedan ili više modela za opis, koji su dokumentirani s jednim ili više dijagrama (pogleda, engl. views).

24. Tim + UML + RUP = dobitna kombinacija
Team-Based
Development
Projektni tim !
Modeling
Language
Unified Process

25. Kako je nastao RUP ? !!! rane 80' Rational Unified Process 5.0
Uključuje inženjerstvo poslovnog procesa, rukovanje zahtjevima, rukovanje oblikovanjem i promjenama, funkcijsko ispitivanje, evaluaciju performansi, inženjerstvo podataka, oblikovanje sučelja
Rational Unified Process 5.0
1998
Rational
Objectory Process 4.1
The Rational Approach
UML
Objectory Process
!!! rane 80'
The
Ericsson Approach

26. Prikaz RUP-a RUP će se prikazati kroz tri temeljna obilježja:
Promiče iteracije na pojedinim fazama oblikovanja programske potpore
Temelji se na obrascima uporabe (tj. predlošku scenarija)
U fokusu je arhitektura sustava

27. Prikaz RUP-a
RUP
Promiče iteracije na pojedinim fazama oblikovanja programske potpore
Temelji se na obrascima uporabe (tj. predlošku scenarija)
U fokusu je arhitektura sustava

28. Faze u životnom ciklusu RUP procesa
Inception
Elaboration
Construction
Transition
vrijeme
Inception (početak) Definira doseg projekta, razvoj modela poslovnog procesa, specifikacija početnih zahtjeva
Elaboration (elaboracija) Plan projekta, specifikacija značajki i temelji arhitekture sustava
Construction Izgradnja produkta (oblikovanje, programiranje, ispitivanje)
Transition Prijenos produkta korisnicima (postavljanje u radnu okolinu)

29. Glavni “Milestones” (ključne točke i pridruženi dokumenti)
Inception
Elaboration
Construction
Transition
vrijeme
Vizija
Temeljna arhitektura
Početna sposobnost
Izdanje produkta
(engl. release)

30. Faze i pridružene iteracije
Inception
Elaboration
Construction
Transition
Prelim
Iteracija
...
Arh
Iteracija
...
Razvojna
Iteracija
Razvojna
Iteracija
...
Prijenos
Iteracija
...
Release
Release
Release
Release
Release
Release
Release
Release
Iteracija je sekvenca aktivnosti u okviru prihvaćenog plana i kriterija evaluacije. Rezultira u dokumentu, a kasnije i jednoj izvršnoj inačici programa (izdanju, engl. release).

31. Iteracije i aktivnosti (tijek rada, engl. workflow)
Faze životnog ciklusa
Aktivnosti I n c e p t i o E l a b o r t i n C o n s t r u c i T r a n s i t o
Zahtjevi
Iteracija u fazi elaboracije
Analiza
Intenzitet aktivnosti
Oblikovanje
Implementacija
Test P r e l i m n a ne I t o ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1
vrijeme
iteracije

32. Detaljizirana struktura RUP-a
Inicijalna aktivnost
Faze životnog ciklusa
Aktivnosti u RUP-u
Inception
Elaboration
Construction
Transition
Mod. poslovnog proc.
Jezgrene
(temeljne)
aktivnosti
(engl. core workflows)
Zahtjevi
Analiza i oblikovanje
Implementacija
Test
Razmještaj
Potporne aktivnosti
Mgmt. konfiguracije i promjena
Management razvoja projekta
Briga o okolišu
Preliminary Iteration(s)
Iter. #1
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m
Iter. #m+1
Iteracije

33. Aktivnosti (tijek rada) i pridruženi modeli
Modeli su dokumentirani dijagramima (pogledima)
Aktivnosti:
Use Case
Model
Zahtjevi
Analysis
Model
Analiza
Design
Model
Razmještaj
Model
Oblikovanje
Implementacija
Model
Implementacija
Test
Model
Test
Svakoj aktivnosti pridružen je jedan ili više modela.

34. Primjer: Use Case Model (nije potrebno pamtiti pridruživanje)
Diagrams
Use Case
Model
(Obrazac uporabe)
Class
Diagrams
Object
Diagrams
Analysis
Model
Component
Diagrams
Design
Model
Deployment
Diagrams
Depl.
Model
Sequence
Diagrams
Pridruživanje dijagrama modelu
Impl.
Model
Collaboration
Diagrams
Statechart
Diagrams
Test
Model
Activity
Diagrams

35. Primjer: Test Model Use Case Diagrams Class Diagrams Object Diagrams
Analysis
Model
Component
Diagrams
Design
Model
Deployment
Diagrams
Test model odnosi se na sve druge modele i koristi njihove odgovarajuće dijagrame
Depl.
Model
Sequence
Diagrams
Impl.
Model
Collaboration
Diagrams
Statechart
Diagrams
Test
Model
Activity
Diagrams

36. Prikaz RUP-a
RUP
Promiče iteracije na pojedinim fazama oblikovanja programske potpore
Temelji se na obrascima uporabe (tj. predlošku scenarija)
U fokusu je arhitektura sustava

37. Što znači: Temelji se na obrascima uporabe (Use Case)?
Aktivnosti:
Zahtjevi
Analiza
Oblikovanje
Impl.
Test
Obrasci uporabe (use cases) povezuju sve ove aktivnosti zajedno

38. Obrasci uporabe kao pokretači iteracija
Obrasci uporabe pokreću brojne aktivnosti u životnom ciklusu oblikovanja programske potpore, kao npr.:
Kreiranje i validacija arhitekture sustava
Definicija ispitnih slučajeva, scenarija i procedura
Planiranje pojedinih iteracija
Kreiranje korisničke dokumentacije
Razmještaj (engl. deployment) sustava
Sinkroniziraju sadržaj različitih modela

39. Prikaz RUP-a
RUP
Promiče iteracije na pojedinim fazama oblikovanja programske potpore
Temelji se na obrascima uporabe (tj. predlošku scenarija)
U fokusu je arhitektura sustava
Arhitektura programske potpore je struktura ili strukture sustava koje sadrži elemente, njihova izvana vidljiva obilježja i odnose između njih.

40. RUP: u fokusu je arhitektura sustava
Modeli su prijenosnici za vizualizaciju, specifikaciju, konstruiranje (oblikovanje, implementacija) i dokumentiranje arhitekture
RUP propisuje sukcesivno rafiniranje od grubog modela do konačne izvršne arhitekture
RUP promiče oblikovanje programske potpore zasnovano na modelima (engl. Model Based Design, MBD)
Aktivnosti:
Inception
Elaboration
Construction
Transition
vrijeme
Arhitektura

41. RUP predstavlja inženjerski pristup
Aktivnost
Jedinica posla
Radnik
Uloga tima ili individue
ŠTO
TKO
Opiši
Use Case
Analitičar
Odgovoran za
Artefakt
Dio informacije koji se proizvede, modificira ili koristi u procesu
Use case
Use case paket

42. RUP je samo okvir (engl. framework)
NE POSTOJI UNIVERZALNI PROCES OBLIKOVANJA PROGRAMSKE POTPORE
RUP je predložen imajući u vidu fleksibilnost i proširenje
omogućuje razne strategije životnog ciklusa projekta
odabire koje artefakte treba proizvesti
definira aktivnosti i radnike
modelira koncepte

43. RUP ZAKLJUČCI
U središtu RUP procesa su obrasci uporabe sustava koji semantički povezuju sve aktivnosti.
RUP definira i međusobno povezuje dinamičke faze i statičke aktivnosti procesa (vidi prikaze iteracija i aktivnosti).
Za opis pojedinih aktivnosti koriste se odgovarajući modeli.
Modeli su dokumentirani s jednim ili više dijagrama (pogleda).
Dijagrami su definirani UML standardom.
Oblikovana arhitektura sustava sadrži skup pogleda u modele (tj. skup dijagrama).

44. 5. AGILNI PRISTUP RAZVOJU PROGRAMSKE POTPORE
Grupa metoda za razvoj programske potpore kojima je zajednički iterativni razvoj uz male inkremente te koje podržavaju brzi odziv na korisničke zahtjeve.
Ovaj model razvoja programske potpore koristi se za brzi razvoj manjih i srednjih projekata u stalnoj interakciji s klijentima putem stalnog predočavanja novih poboljšanja, uz relativno slabo dokumentiranje.
Najpoznatije metode uključuju:
Čisti razvoj programske potpore (engl. Lean software development)
Ekstremno programiranje (engl. Extreme programming)
Razvoj zasnovan na ispitivanju (engl. Test-driven development)

45. ČISTI (LEAN) RAZVOJ PROGRAMSKE POTPORE
Izvorno korištena metoda u industrijskom produkcijskom sustavu Toyote
Cilj je razviti u što kraćem vremenu sustav koji će zadovoljiti korisnike
Koristi se 7 principa oblikovanja:
Eliminacija svega suvišnoga (koda, nejasnih zahtjeva, birokracije, spore interne komunikacije)
Naglašeno učenje (stalna komunikacija s klijentom, stalna testiranja i brze nadogradnje)
Odlaganje odluke (predlaganjem opcija klijentu, skupljanjem činjenica)
Dostava proizvoda što je brže moguće (niz metoda, uglavnom mali inkrementi, više timova radi isto)
Motivacija i suradnja unutar tima
Ugradnja cjelovitosti u sustav (kupac mora biti zadovoljan sa sustavom u cjelini: funkcionalnošću, intuitivnošću korištenja, cijenom)
Razumjevanje modela (svaki član tima mora znati kako i zašto čisti razvoj programske potpore treba funkcionirati)

46. EKSTREMNO PROGRAMIRANJE (XP)
Javlja se (sredinom 1990-tih) kao otpor strukturiranom (ponajviše vodopadnom) procesu programskog inženjerstva.
Smatra se da vodopadni model unosi previše birokracije u proces oblikovanja.
Jedina mjera napretka je funkcionalni programski produkt.
Pristup se bazira na razvoju, oblikovanju i isporuci funkcionalnih dijelova.
Postupak uključuje kontinuirano poboljšavanje koda.
Sudjelovanje korisnika u razvojnom timu.
U razvoju sustava najčešće se programira u paru (jedno radno mjesto, međusobno provjeravanje (engl. pairwise programming).
Nedostatak: nerazumljivost, ne podupire ponovnu uporabu (engl. reuse) rješenja.

47. PROCESI PROGRAMSKOG INŽENJERSTVA
Procesi i modeli procesa programskog inženjerstva.
Iteracije u modelima procesa programskog inženjerstva.
Generičke aktivnosti u procesima programskog inženjerstva.
CASE tehnologije za potporu aktivnostima u procesima programskog inženjerstva.
Zaključci

48. ITERACIJE U MODELIMA PROCESA PROGRAMSKOG INŽENJERSTVA
Iteracije u procesu programskog inženjerstva sastavni su dio velikih projekata jer se pojedini dijelovi moraju ponovno oblikovati.
Iteracije se mogu primijeniti na bilo koji generički model procesa programskog inženjerstva.
Iteracije se javljaju u svakoj fazi procesa programskog inženjerstva (vidi npr. RUP).
Postoje dva međuovisna pristupa iteracijama:
Inkrementalni
Spiralni

49. INKREMENTALNI PRISTUP
(kao oblik iteracija)
Sustav se ne isporučuje korisniku u cjelini. Razvoj, oblikovanje i isporuka razbiju se u inkrementalne dijelove koji predstavljaju djelomične funkcionalnosti.
Zahtjevi korisnika se svrstaju u prioritetne cjeline. Dijelovi višega prioriteta isporučuju se u ranim dijelovima sustava (inkrementima).
S početkom razvoja pojedinog inkrementa njegovi zahtjevi se fiksiraju (zamrzavaju). Zahtjevi na ostale kasnije inkremente nastavljaju evoluirati.

50. INKREMENTALNI ITERACIJSKI PRISTUP
Pridruži zahtjeve inkrementima
Oblikuj arhitekturu sustava
Definiranje zahtjeva
Validiraj sustav
Validiraj inkrement
Integriraj inkrement
Razvij inkrement sustava
Konačan sustav
Sustav nekompletan

51. INKREMENTALNI PRISTUP ITERACIJAMA
PREDNOSTI
Kupac dobiva svoju vrijednost sa svakim inkrementom. Temeljna funkcionalnost sustava se ostvaruje u ranim fazama projekta.
Rani inkrementi služe kao prototipovi na temelju kojih se izlučuju zahtjevi za kasnije inkremente.
Smanjen je rizik za neuspjeh projekta.
Prioritetne funkcionalne usluge sustava imaju mogućnost detaljnijeg ispitivanja (testiranja) jer su implementirane u ranim fazama projekta.
NEDOSTATCI
Teško je preslikati korisničke zahtjeve u inkremente odgovarajuće veličine
Teško je odrediti koje će zajedničke značajke sustava biti potrebne za razvoj svih daljnjih inkremenata

52. SPIRALNI PRISTUP (kao oblik iteracija)
Proces oblikovanja se predstavlja spiralom umjesto sekvencom aktivnosti.
Svaka petlja u spirali predstavlja jednu fazu procesa.
Nema ranih završenih faza (kao npr. specifikacija, razvoj, …).
Eksplicitno se određuju i razrješavaju rizici razvoja programskog produkta.

53. Procjena i smanjivanje rizika
Postavljanje ciljeva
Planiranje
Razvoj i validacija

54. SEKTORI U SPIRALNOM MODELU ITERACIJA
Postavljanje ciljeva
Temeljem zahtjeva identifikacija specifičnih ciljeva (opcija/alternativa i ograničenja).
Procjena i smanjivanje rizika
Analiziraju se rizici u opcijama te preslikavaju u aktivnosti koje ih reduciraju (poput SWOT analize – snage, slabosti, prilike, prijetnje). Analiza rizika rezultira u evoluciji prototipova.
Razvoj i validacija
Analizom prototipa slijedi razvoj produkta. U ranim spiralama koncept, kasnije spirale nose sve detaljnije aktivnosti (specifikacija, oblikovanje, razvoj, testiranje, uporaba).
Planiranje
Planiraju se faze (ciklusi spirale) od izlučivanja zahtjeva do oblikovanja, razvoja i integracije (od koncepta do produkta).

55. PROCESI PROGRAMSKOG INŽENJERSTVA
Procesi i modeli procesa programskog inženjerstva.
Iteracije u modelima procesa programskog inženjerstva.
Generičke aktivnosti u procesima programskog inženjerstva.
CASE tehnologije za potporu aktivnostima u procesima programskog inženjerstva.
Zaključci

56. GENERIČKE AKTIVNOSTI U PROCESU PROGRAMSKOG INŽENJERSTVA
Pojavljuju se u svakom modelu procesa programskog inženjerstva:
Specifikacija programskog produkta temeljem analize i izlučivanja zahtjeva.
Oblikovanje i implementacija programskog produkta
Validacija i verifikacija programskog produkta
Evolucija programskog produkta

57. Generička aktivnost: SPECIFIKACIJA PROGRAMSKOG PRODUKTA
Specifikacija programskog produkta određuje se procesom inženjerstva zahtjeva (engl. Requirements engineering).
Proces rezultira dokumentom u kojem se navode potrebne usluge i ograničenja u radu i razvoju sustava.
Temeljni dio ove aktivnosti čine:
Studija izvedivosti
Izlučivanje (otkrivanje) zahtjeva
Validacija zahtjeva
Upravljanje promjenama u zahtjevima
Ova aktivnost detaljno je analizirana ranije u sklopu prikaza inženjerstva zahtjeva !

58. GENERIČKE AKTIVNOSTI U PROCESU PROGRAMSKOG INŽENJERSTVA
Pojavljuju se u svakom modelu procesa programskog inženjerstva:
Specifikacija programskog produkta temeljem analize i izlučivanje zahtjeva.
Oblikovanje i implementacija programskog produkta
Validacija i verifikacija programskog produkta
Evolucija programskog produkta

59. Generička aktivnost: OBLIKOVANJE I IMPLEMENTACIJA PROGRAMSKOG PRODUKTA
To je proces preslikavanja specifikacije u stvarni sustav.
Uključuje:
Oblikovanje programskog produkta
Oblikovanje strukture sustava koja realizira specifikaciju (izbor i modeliranje arhitekture).
Implementaciju (programiranje)
Preslikavanje strukture u izvršni program.
Aktivnosti oblikovanja i implementacije su povezane i mogu biti isprepletene.

60. PODAKTIVNOSTI UNUTAR OBLIKOVANJA PROGRAMSKOG PRODUKTA
Izbor i oblikovanje arhitekture (kriteriji za odabir stila?).
Apstraktna specifikacija (koncepcijska, ne tehnička).
Konkretna specifikacija (tehnička).
Oblikovanje sučelja
Oblikovanje komponenata
Oblikovanje struktura podataka
Oblikovanje algoritama

61. Podaktivnosti u oblikovanju
OBLIKOVANJE PROGRAMSKOG PRODUKTA (podaktivnosti i rezultati – dokumenti)
Podaktivnosti u oblikovanju
Specifikacija zahtjeva
Oblikovanje sučelja
Oblikovanje komponenata
Oblikovanje struktura podataka
Oblikovanje algoritama
Izbor i oblikovanje arhitekture
Apstraktna specifikacija
Specifikacija sučelja
Arhitektura sustava
Specifikacija programa
Specifikacija algoritama
Specifikacija struktura podataka
Specifikacija komponenata
Produkti oblikovanja

62. OBLIKOVANJE PROGRAMSKOG PRODUKTA -izbor arhitekture
Prva aktivnost unutar oblikovanja (vidi prethodnu sliku).
Izbor arhitekture nažalost nije poduprt formalnim postupcima, već se najčešće temelji na neformalnoj analizi i dobroj inženjerskoj praksi.
Na temelju odabrane arhitekture slijedi sistematski pristup oblikovanja programskog produkta.
Arhitektura bi trebala biti dokumentirana skupom modela (najčešće grafičkih dijagrama).
Neke moguće arhitekture programske potpore:
Protok podataka (engl. data-flow)
Objektno usmjerena arhitektura
Repozitorij podataka
Arhitektura temeljena na događajima …

63. OBLIKOVANJE PROGRAMSKOG PRODUKTA – Implementacija
(programiranje i otklanjanje pogrešaka)
Implementacija je preslikavanje dokumentiranog oblikovanja (odabrane arhitekture) u program i otklanjanje pogrešaka u dijelu programa za koji su zaduženi.
Programiranje je osobna aktivnost – ne postoji generički proces programiranja.
Programeri tijekom implementacije izvode i neke dodatne aktivnosti: ispitivanje (testiranje) programskog produkta s ciljem otkrivanja i otklanjanja pogrešaka (engl. debugging), oblikovanje i programiranje ispitnih programa.

64. GENERIČKE AKTIVNOSTI U PROCESU PROGRAMSKOG INŽENJERSTVA
Pojavljuju se u svakom modelu procesa programskog inženjerstva:
Specifikacija programskog produkta temeljem analize i izlučivanje zahtjeva.
Oblikovanje i implementacija programskog produkta
Validacija i verifikacija programskog produkta
Evolucija programskog produkta

65. Generička aktivnost: VALIDACIJA I VERIFIKACIJA PROGRAMSKOG PRODUKTA
Validacija i verifikacija treba pokazati da sustav odgovara specifikaciji i zadovoljava zahtjevima kupca i korisnika.
Validation – “Are we building the right system ?”
Verification – “Are we building the system right ?”
Validacija se provodi ispitivanjem sustava (testiranjem).
Ispitivanje se temelji na radu sustava s ispitnim ulaznim parametrima (podacima) koji se izvode iz specifikacije stvarnih podataka koje sustav treba prihvatiti. Ispitivanje je složena i vrlo skupa aktivnost.
Ispitivanje (testiranje sustava) bit će detaljno obrađeno u posebnim predavanjima.
Verifikacija uključuje provjeru odsustva pogrešaka, poželjno zasnovanu na formalnim (matematičkim i logičkim) metodama.

66. Udio troška ispitivanja u nekim modelima procesa programskog inženjerstva
VODOPADNI
ITERATIVNI
KOMPONENTNI
DUGOVJEČNI

67. ISPITIVANJE (TESTIRANJE) PROGRAMSKE POTPORE Što je ispitivanje ?
Pretpostavka za ispitivanje:
Bez specifikacije nema testiranja !
Testiranje znači usporedbu stvarnih rezultata s postavljenim i očekivanim zahtjevima.
The Institute of Electrical and Electronics Engineers (IEEE) definira:
test - kao jedan ili više testnih slučajeva (engl. test case)
testiranje - kao proces analize programskog koda sa svrhom pronalaska razlike između postojećeg i zahtijevanog stanja te vrednovanja svojstava programa.

68. ISPITIVANJE PROGRAMSKE POTPORE
Terminologija:
Testni podaci (I)
Ulazi odabrani za provođenje određenog testa.
Očekivani izlaz (O)
Zabilježen prije provođenje testa.
Testni slučaj (engl. test case)
Uređeni par (I, O).
Kriterij prolaza testa
Kriterij usporedbe očekivanog i stvarnog izlaza određen prije provođenja testa.
Stvarni izlaz
Rezultat dobiven provođenjem testa.

69. ISPITIVANJE PROGRAMSKE POTPORE
Proces ispitivanja po integracijskim dijelovima sustava:
(oblikovanje odozgo prema dolje, ispitivanje odozdo prema gore)
Ispitivanje komponenti, engl. Unit (Component) testing.
Integracijsko ispitivanje
Ispitivanje sustava, engl. System/Release testing.
Test prihvatljivosti, engl. Acceptance Testing.
Test instalacije, engl. Installation testing.
Alpha test (interni).
Beta test (vanjski).

70. AKTIVNOSTI I PRODUKTI TIJEKOM PROCESA ISPITIVANJA
oblikovanje
Tijek aktivnosti
Spec. zahtjeva Spec. sustava Oblikovanje sustava
Produkti aktivnosti
Plan testa prihvatljivosti Plan testa integracije Plan testiranja podsustava
Testiranje tijekom oblikovanja modula
Puštanje u rad Test prihvatljivosti Test integracije Test podsustava
ispitivanje

71. ISPITIVANJE PROGRMASKE POTPORE
Ispitivanje je nezaobilazna aktivnost u svakom procesu programskog inženjerstva.
Međutim:
1972. Dijkstra: “Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.”
(Ispitivanje programa može biti vrlo učinkovit način za pokazati prisutnost pogrešaka, ali je beznatno neadekvatno za pokazati njihovu odsutnost)
Ispitivanje se dopunjuje formalnom verifikacijom.

72. Formalna verifikacija
To je postupak provjere da formalni model dijela izvedenog sustava (/), odgovara formalnoj specifikaciji (S) sa matematičkom izvjesnošću ("odgovara" = logički zadovoljava).
Nije tradicijska aktivnost u programskom inženjerstvu, ali sve se više uvodi.
Detaljniji prikaz ove aktivnosti u kasnijim predavanjima.
I - formalni model
Da / Ne
Sustav za verifikaciju
S - formalna specifikacija

73. GENERIČKE AKTIVNOSTI U PROCESU PROGRAMSKOG INŽENJERSTVA
Pojavljuju se u svakom modelu procesa programskog inženjerstva:
Specifikacija programskog produkta temeljem analize i izlučivanje zahtjeva.
Oblikovanje i implementacija programskog produkta
Validacija i verifikacija programskog produkta
Evolucija programskog produkta

74. Generička aktivnost: EVOLUCIJA PROGRAMSKOG PRODUKTA
Programski produkt je inherentno fleksibilan i može se mijenjati.
Kako se mijenjaju zahtjevi na sustav (zbog promjene poslovnog procesa), programski produkt koji podupire poslovni proces također se mora mijenjati.
Iako postoji granica između razvoja i oblikovanja s jedne strane i evolucije i održavanja s druge strane, to ona postaje sve više irelevantna, jer je sve manje programskih sustava potpuno novo (oblikovano bez uporabe dijelova ranijih produkata).

75. Analiza postojećeg sustava
EVOLUCIJA SUSTAVA
Analiza postojećeg sustava
Definiraj (nove) zahtjeve
Predloži izmjene
Modificiraj sustav
Postojeći sustav
Novi sustav

76. PROCESI PROGRAMSKOG INŽENJERSTVA
Procesi i modeli procesa programskog inženjerstva.
Iteracije u modelima procesa programskog inženjerstva.
Generičke aktivnosti u procesima programskog inženjerstva.
CASE tehnologije za potporu aktivnostima u procesima programskog inženjerstva.
Zaključci

77. CASE - Computer-aided software engineering
To su programski produkti koji podupiru proces programskog inženjerstva, a posebice aktivnosti specifikacije, oblikovanja, implementacije i evolucije.
Iako je CASE tehnologija dovela do značajnog unapređenja procesa oblikovanja programske potpore, ipak poboljšanja nisu sukladna očekivanjima (tj. poboljšanje efikasnosti za red veličine !?).
Zašto?
Programsko inženjerstvo zahtijeva kreativnost, koju nije lako, a često ni moguće automatizirati.
Programsko inženjerstvo je timska aktivnost. U većim projektima mnogo vremena se utroši na interakcije unutar tima. CASE tehnologija slabo podupire timski rad.

78. CASE TEHNOLOGIJA Kako izabrati pogodan alat ?
CASE podupire automatizaciju oblikovanja raznim alatima kao npr.:
Grafički editori za razvoj modela sustava.
Rječnici i zbirke za upravljanje entitetima u oblikovanju.
Grafička okruženja za oblikovanje i konstrukciju korisničkih sučelja.
Alati za pronalaženje pogrešaka u programu.
Automatizirani prevoditelji koji generiraju nove inačice programa.
… .
Kako izabrati pogodan alat ?
Potrebno poznavanje klasifikacije CASE tehnologije.

79. Klasifikacija CASE alata
Klasifikacija omogućuje razumijevanje različitih tipova CASE alata i njihovu potporu aktivnostima u procesu programskog inženjerstva.
Funkcionalna perspektiva
Alati se klasificiraju prema specifičnoj funkciji.
Procesna perspektiva
Alati se klasificiraju prema aktivnostima koje podupiru u procesu.
Integracijska perspektiva
Alati se klasificiraju prema njihovoj organizaciji u integrirane cjeline.

80. Funkcionalna perspektiva CASE alata

81. Procesna perspektiva CASE alata
Alati
Generičke aktivnosti

82. Integracijska klasifikacija CASE alata
Sveobuhvatnost u procesu
Alati (u užem smislu)
Podupiru individualne zadatke u procesu (npr. oblikovanje, provjera konzistencija, editiranje teksta, …)
Radne klupe (engl. workbenches)
Podupiru pojedine aktivnosti (faze) procesa (npr. specifikaciju)
Razvojne okoline (engl. environments)
Podupiru cijeli ili značajan dio procesa programskog inženjerstva. Uključuju nekoliko integriranih radnih klupa.

83. Integracijska klasifikacija: alati, radne klupe, razvojne okoline
Uređivači Prevoditelji Usporedba datoteka Integrirane Procesno usmjerene
(Npr. Rational Rose)
Analiza i oblikovanje Programiranje Ispitivanje
Više metoda Jedna metoda Opće namjene Za jedan prog. jezik

84. CASE alati i radne klupe u okviru predmeta:
“Oblikovanje programske potpore”
Subversion – upravljanje konfiguracijama programske potpore.
ArgoUML – oblikovanje zahtjeva, oblikovanje modela objektno usmjerene arhitekture i generiranje koda.
Neobvezne radne klupe i razvojne okoline (temeljno usmjerene na dio procesa programskog inženjerstva tj. implementaciju i ispitivanje):
Visual Studio – implementacija programske potpore vezana uz Microsoftove tehnologije
Eclipse – implementacija programske potpore vezana uz Java tehnologije (i druge).

85. PROCESI PROGRAMSKOG INŽENJERSTVA
Procesi i modeli procesa programskog inženjerstva.
Iteracije u modelima procesa programskog inženjerstva.
Generičke aktivnosti u procesima programskog inženjerstva.
CASE tehnologije za potporu aktivnostima u procesima programskog inženjerstva.
Zaključci

86. ZAKLJUČCI (1 od 2)
Procesi u programskom inženjerstvu su strukturirane aktivnosti usmjerene na produkciju i evoluciju programskih proizvoda.
Modeli procesa programskog inženjerstva su njihova apstraktna reprezentacija (npr. vodopadni, evolucijski, komponentni, RUP).
Nema univerzalnog i standardnog modela procesa programskog inženjerstva.
Generičke aktivnosti u procesu su specifikacija, oblikovanje i implementacija, validacija i verifikacija te evolucija.
Iteracije opisuju ponavljajuće podaktivnosti unutar faza ili aktivnosti modela procesa.

87. ZAKLJUČCI (2 od 2)
Generička aktivnost specifikacije generira dokument o zahtjevima na sustav.
Generička aktivnost oblikovanja i implementacije preslikava specifikaciju u arhitekturu i radni (izvršni) program.
Generička aktivnost validacije i verifikacije provjerava da li sustav zadovoljava specifikaciju i potrebe korisnika.
Evolucija se bavi izmjenama sustava tijekom njegove uporabe.
CASE tehnologije podupiru automatizaciju aktivnosti tijekom procesa programskog inženjerstva do neke granice.