I.

PROGRAMSKO INENJERSTVO
- Inenjerska disciplina koja obuhvaa sve aspekte razvoja
-

programskog proizvoda
Podrazumijeva djelovanje teorija, metoda i alata za profesionalni
razvoj programskog rjeenja

CILJ PI:
-

Programsko inenjerstvo ima za cilj optimizirati trokove razvoja

programskog proizvoda

PROGRAMSKI PROIZVOD
-

Skup raunalnih programa i pripadne dokumentacije zahtjevi,

tehnika dokumentacija, korisnike upute
Programski proizvod se moe razviti za odreenog kupca ili
generalno za trite
Programski proizvod moe biti:
1. Generic razvijen da bi se prodao razliitim kupcima (npr.
Word, Excel)
2. Custom razvijen za jednog korisnika prema njegovim
zahtjevima

PROGRAMSKO INENJERSTVO <>INFORMACIJSKA ZNANOST

-

Informacijska znanost podrazumijeva teoriju i temeljne definicije i

postavke
Programsko inenjerstvo podrazumijeva praktian razvoj i isporuku
korisnog programskog proizvoda
Teorije informacijskih znanosti jo uvijek su nedostatne da se
ponaaju kao prava prethodnica programskom inenjerstvu

PROGRAMSKO INENJERSTVO <>SISTEMSKO INENJERSTVO

-

Sistemsko inenjerstvo podrazumijeva sve aspekte razvoja

raunalom podranih sustava ukljuuje -> hardver, softver,
upravljanje procesima
Programsko inenjerstvo podrazumijeva razvoj programske
infrastrukture, kontrola, aplikacija i baza podataka
Sistemsko inenjerstvo je via razina od programskog inenjerstva
Programsko inenjerstvo ukljueno je u sistemsko inenjerstvo

PROCESNI PRISTUP RAZVOJU PROGRAMSKOG PROIZVODA

(SOFTVER)
-

Skup aktivnosti kojima je cilj razvoj i evolucija

Osnovne aktivnosti procesnog pristupa:
o Specifikacija to sustav mora raditi i bitne znaajke razvoja
o Izgradnja proizvodnja programskog proizvoda
o Validacija provjera da li je funkcionalnost programskog
proizvoda u skladu sa zahtjevima korisnika

o Evolucija promjene u programskom proizvodu na izlazima,

mijenjanjem ulaznih parametara - odravanje

MODEL RAZVOJA ROGRAMSKOG PROIZVODA

-

Pojednostavljeni prikaz razvoja programskog proizvoda sa razliitih

gledita
Temeljni modeli razvoja:
o Waterfall
o Cirkularni razvoj
o Razvoj po komponentama

METODE RAZVOJA PROGRAMSKOG PROIZVODA

-

Strukturirani pristupI razvoju programskog proizvoda koji ukljuuje

modele sustava, notaciju, pravila, preporuke dizajna i upravljanje
razvojem
Npr.:
o Opis modela opisivanje grafikih modela koje treba izgraditi
o Pravila pravila koja su ugraena u modele sustava
o Preporuke savjeti koji su proizali iz prakse kao dobri
o Upravljanje koje aktivnosti treba izvoditi

DOBAR PROGRAMSKI PROIZVOD

-

Programski proizvod mora dati traenu funkcionalnost i mogunosti

krajnjem korisniku i mora imati svojstva:
o Odrivost treba se moi razvijati i obuhvatiti promjene
o Ovisnost treba biti pouzdan
o Djelotvornost ne smije beskorisno troiti sistemske resurse
o Prihvatljivost korisnik

KLJUNI IZAZOVI PROGRAMSKOG INENJERSTVA

-

Heterogenost tehnike razvoja koje mogu podrati razliite

platforme i razliite naine izvoenja
Isporuka tehnike razvoja koje omoguuju brzu isporuku
programskog proizvoda
Povjerenje tehnike razvoja koje pokazuju korisniku da moe
vjerovati programskom proizvodu

PROFESIONALNA I ETINA ODGOVORNOST

-

Programsko inenjerstvo zahtjeva odgovornost, a ne samo koritenja

tehnikih vjetina
Programsko inenjerstvo zahtjeva poteno i etino ponaanje kako bi
se respektiralo kao profesionalan rad
Etino ponaanje je vie od obinog pridravanja zakonskih
regulativa

PROBLEMI U PROFESIONALNOJ ODGOVORNOSTI

-

Pouzdanost treba potovati pouzdanost i poslovne tajne poslodavca ili

klijenta, bez obzira da li je ili nije takav ugovor potpisan
Kompetencija nije dozvoljeno pogreno prikazivanje vlastitih
sposobnosti (preuveliavanje sebe), nije dobro prihvatiti posao koji
nadmauje vlastite kompetencije
Intelektualno vlasnitvo treba potovati zakone o intelektualnom
vlasnitvu, zabrani multipliciranja i sl.
Zlouporaba raunala nije dozvoljeno koritenje vlastitih tehnikih
znanja kako bi se zlouporabilo tue raunalo. Zlouporaba se smatra od
obinog koritenja igrica pa do ekstremnih namjernih ubacivanja virusa.

II. VRSTE PROGRAMSKIH PROIZVODA:

- Tehniki raunalom podran sustav
o Sustav koji se sastoji od hardvera i softvera, u kojem se
normalno ne podrazumijevaju operatori kao korisnici i runo
obavljanje posla. Sustav nije samosvjestan.

- Socio tehniki sustav*

o Ukljuuje tehniki sustav, ali i postupke koje korisnik moe i

treba koristiti time se postie interakcija ovjeka i
raunala. Odreen je politikom u poduzeu i internim
organizacijskim pravilima.

*Karakteristike socio-tehnikih sustava:

o NUNA SVOJSTVA*
Svojstva sustava koje u cijelosti ovise o elementima
sustava
i njegovim odnosima (vezama).
o NE PREDODREENOST
Ne deavaju se uvijek jednaki izlazi na temelju jednakih
ulaza, jer je prisutna djelomina ovisnost o ovjekovoj
aktivnosti
o POVEZANOST S ORGANIZACIJOM
Onaj dio sustava koji je poveznica sa organizacijskim
postavkama ne ovisi samo o sustavu

*Nuna svojstva dijelimo na:

-

Veliina
o

Pouzdanost*
o

Veliina sustava (ukupan iskoriteni prostor) varira i ovisi o tome

kako su
komponente grupirane i spojene
Pouzdanost sustava ovisi o pouzdanosti njegovih komponenata.
Neoekivane aktivnosti mogu uzrokovati nove vrste pogreaka i time
naruiti pouzdanost sustava

Sigurnost
o

Sposobnost sustava da se obrani od napada. Teko je mjerljiva.

Napadi

mogu biti tako smiljeni da ih niti dizajneri nisu predvidjeli i tako

mogu
pobijediti ugraene obrambene mehanizme

Popravljivost
o

Pokazuje koliko je lako rijeiti otkriveni problem. Ovisi o mogunosti

dijagnosticiranja problema, pristupu pokvarenoj komponenti i
modificiranju
ili zamjeni

Korisnost
o

Pokazuje koliko je lako koristiti sustav. Ovisi o tehnikim

komponentama
sustava, korisnicima i okruenju.

*Pouzdanost
-

Meuzavisnost komponenti uzrokuje prenaanje pogreaka po

sustavu
Pogreke u sustavu obino nastaju zbog nepredvidivih veza izmeu
komponenti
Vjerojatno je nemogue predvidjeti sve mogue veze izmeu
komponenti
Mjere pouzdanosti mogu dati pogrenu sliku sustavne pouzdanosti
Klasifikacija pouzdanosti
o Pouzdanost hardvera

Kolika je mogunost hardverske pogreke i koliko je

potrebno za popravak komponente

o Pouzdanost softvera

Kolika je mogunost da e softverska komponenta

proizvesti pogrean izlaz. Razlika izmeu softverske i
hardverske pogreke je u tome to se softver ne haba, ne
troi

o Pouzdanost korisnika

Kolika je mogunost da e korisnik uiniti pogreku

III.
-

SISTEMSKO INENJERSTVO:

Specificiranje, dizajniranje, implementiranje, vrednovanje,

distribucija i odravanje socio - tehnikih sustava, ukljuujui:
o
o
o

sustavno podrane poslove (funkcionalnost)

ogranienja i zahtjevi prilikom stvaranja sustava (zahtjevi korisnika)
operacije i naini koritenja (manual)

obino koristi waterfall model

potreba za istovremenim razvojem razliitih dijelova sustava
neizbjeno ukljuivanje strunjaka iz razliitih podruja i disciplina:
o
o
o

velika mogunost meusobnog nerazumijevanja

razliite discipline imaju razliit rjenik potrebno vie vremena u
pregovorima
sudionici mogu imati vlastiti reim rada koji se razlikuje od drugih

SISTEMSKO INENJERSTVO PROCES

1.
2.
3.
4.
5.
6.
7.

Definiranje potreba
Dizajn sustava
Razvoj pod sustava
Integracija
Instalacija
Evolucija
Gaenje sustava

1. Definiranje potreba
-

Funkcionalnost
o

Svojstva sustava
o

Funkcionalnost je definirana na apstraktan nain

Definicija ne funkcionalnih potreba za sustav openito

Nepoeljne karakteristike
o

Neprihvatljivo i nepoeljno ponaanje sustava

CILJEVI SUSTAVA
Definirati zato se sustav osigurava za odreenu sredinu:
-

Funkcionalnost
o

Zbog definiranja protupoarnog i protuprovalnog sustava u

zgradi, kako bi se oglasio unutranji ili vanjski alarm zbog vatre

ili neautoriziranog upada

Organizacija
o

Kako bi se pokazalo da posao normalno funkcionira u zgradi

bez obzira na dogaaje poara ili neautoriziranog upada

2. Dizajn sustava

1. Dijeljenje potreba

Razmjetaj (organiziranje) potreba u povezane skupine

2. Definiranje pod sustava

Definiranje pod-sustava koji zajedno osiguravaju sustavne

potrebe

3. Dodjela potreba definiranim pod sustavima

4. Specificiranje funkcionalnosti pod sustava
5. Definiranje poveznica izmeu pod sustava

Vrlo kritina aktivnost u paralelnom razvoju pod-sustava

Problemi u dizajnu:
-

Dijeljenje potreba na hardverske, softverske i korisnike moe biti

neodluno (nije crno-bijelo)
Potekoe u dizajnu mogu se lako rijeiti koritenjem adekvatnog
softvera
Hardverske platforme mogu biti neodgovarajue za zahtjeve
softvera. Softver treba rijeiti takve probleme

3. Razvoj pod sustava

-

Obino paralelan razvoj hardverskih, softverskih i komunikacijskih

elemenata
Ponekad ukljuuje nabavku gotovih elemenata
Manjak komunikacije prema implementacijskom timu
Spor mehanizam za zahtijevanje promjena obino ima za posljedicu
poveanje vremena za razvoj, a zbog potreba za prepravcima

4. Integracija
-

Proces koji postavlja hardver, softver i korisnika na jedno mjesto i od

toga stvara sustav
Pod-sustavi se spajaju jedan po jedan
Mogu nastati problemi u povezivanju pod-sustava (interface
problems)
Mogui su i problemi u nekoordiniranim isporukama komponenata

5. Instalacija
-

Nakon zavretka integracije sustav se uvodi kod korisnika:

o
o
o

Mogui problemi u okruenju prilikom instalacije

Mogua je ljudska odbojnost prema novom sustavu
Sustav bi trebao moi funkcionirati zajedno sa starim sustavom neko
vrijeme

o
o

Mogui su fiziki problemi (mrea, kabliranje)

Potrebno je dogovoriti obuku korisnika

6. Evolucija koritenje i odravanje

-

Veliki sustavi imaju dug ivotni vijek. Treba neto mijenjati nove potrebe,
zahtjevi
Evolucija ima svoju novanu vrijednost
o Promjene je potrebno analizirati sa tehnike i poslovne perspektive
o Podsustavi komuniciraju mogui su nepredvidivi problemi
o Struktura sustava je naruena kroz promjene koje su stvorene

7. Gaenje sustava
-

Nakon korisnog vremena izbaaj sustava iz funkcije

Moe ukljuivati i odstranjivanje materijala (tetnih koje treba zbrinuti) koji
oneiuju okolinu
Moe zahtijevati rekonstrukciju podataka i konverziju kako bi ih neki drugi
sustav mogao koristiti

IV.
-

SUSTAV, LJUDI, ORGANIZACIJA

Socio-tehniki sustav je slika organizacijskog sustava sa svrhom

postizanja poslovnih ciljeva
Software inenjer treba poznavati organizacijsko okruenje
Ne poznavanje okruenja moe dovesti do nesuglasja izmeu
softvera, i zahtjeva i potreba korisnika i organizacije

UTJECAJI:
-

Promjene u procesu

Promjene u poslu

o
o

Da li sustav zahtjeva promjene u procesu rada u okruenju

Da li koritenjem sustava ljudi trebaju mijenjati svoje dosadanje
naine rada

Organizacijske promjene
o

Da li sustav mijenja vrsto postavljenu organizacijsku strukturu u

poduzeu

Nabavka sustava
-

Kupovina odreenog sustava za organizaciju sa ciljem rjeavanja

odreenih problema (potreba)
Prije nabavke obavezna je specifikacija sustava i zahtjevi za
dizajnom, arhitekturom, i sl.
o
o

Za stvaranje ugovora za razvoj sustava

Za kupovinu ve gotovog sustava (preteno jeftinije nego razvoj
novog iz temelja)

Veliki kompleksni sustavi obino su mjeavina gotovih kupljenih

sustava i novo-razvijenih (normalno proces nabave se razlikuje)

Proces nabavke sustava

1. GOTOV KONFEKCIJSKI SUSTAV
1.
2.
3.
4.

ISTRAIVANJE TRITA
PRILAGOAVNJE ZAHTJEVIMA
ODABIR SUSTAVA
ZAHTJEV ZA PONUDU
5. ODABIR DOBAVLJAA

2. PRILAGOENI SUSTAV

1. ISTRAIVANJE TRITA
2. SLANJE UPITA ZA PONUDU

3. ODABIR PONUDE
4. ZAKLJUIVANJE UGOVORA
5. RAZVOJ

Legacy sustav
-

Socio-tehniki sustav koji je razvijen starim ili zastarjelim

tehnologijama
Bitan u poslovnoj sredini (krucijalan) i obino je vrlo riskantno ugasiti
takav sustav
o
o

Bankarski sustav za upravljanje raunima

Sustav upravljanja zrakoplovima

Takvi sustavi ograniavaju nove procese u poslovanju i troe znatne

iznose budeta

KARAKTERISTIKE LEGACY SUSTAVA:

-

Hardware
o

moe biti zastarjela (mainframe) arhitektura posluitelj i terminali

moe se temeljiti na podrci dobavljaa koji vie ne postoje

mogu biti napisane u zastarjelim programskim jezicima

mogu biti ogranieni strukturom i funkcionalnou software-a

Software
Aplikacije
Poslovni procesi
Poslovna pravila
o mogu biti ukljuena u aplikativni softver (predefinirani algoritmi)

V.
RAZVOJ PROGRAMSKOG SUSTAVA (SOFTVER)
- Proces koji se sastoji od aktivnosti:

1.
2.
3.
4.

Specifikacija
Dizajn
Validacija
Evolucija

Model razvoja sustava je apstraktni prikaz razvoja sustava. Prikazuje

razvoj iz specifinih pogleda.

OSNOVNI MODELI RAZVOJA PROGRAMSKOG SUSTAVA:

-

Waterfall model
o Odvojene i razliite faze specifikacije i izgradnje
Evolutionary development
o Specifikacija, izgradnja i validacija se isprepliu
Component based
o Sustav se sastavlja na temelju izgraenih komponenti

1. Waterfall model:
1. Definiranje potreba
2. Dizajniranje sustava
3. Implementacija i testiranje elemenata
4. Integracija i testiranje sustava
5. Koritenje i odravanje
Problemi:
-

Teko je implementirati promjene kada se sustav ve koristi. Faza se

treba zavriti prije odlaska na drugu fazu
Nefleksibilna podjela projekta na faze oteava brzinu odgovora na
zahtjeve za promjene od strane korisnika
Model je prikladan samo onda kada su zahtjevi (potrebe) dobro
shvaeni
Malo poslovnih sustava ima stabilne (nepromjenjive) zahtjeve
Pogodan za razvoj velikih sustava kada se sustav razvija sa vie
strana

2. Evolutionary development
-

Istraivaki razvoj
o
o

Izgrauje se u suradnji sa korisnikom ime nastaje gotov proizvod, a

na temelju dobro definirane specifikacije
Mogue je jednostavno dodavati nove mogunosti koje je korisnik
traio

Izbacivanje prototipa
o
o

Treba razumijevati zahtjeve sustava

Mogue je zapoeti sa slabo razumljivim zahtjevima, naknadno se
iskristaliziraju stvarne potrebe

Problemi:
-

Nedostatak transparentnosti u razvoju

Sustav je obino loe strukturiran
Zahtijevane bolje vjetine brzo prototipiranje

Koristivost:
-

Za malene i srednje sustave

Za razvoj dijelova velikih sustava (npr. user interface)
Za sustave s kratkim ivotnim vijekom

3. Component Based Development (CBD)

-

Komponentalni razvoj

Faze:
1. Analiza komponenata
2. Modifikacija potreba
3. Dizajn viestruko koritenje komponenata (reuse)
4. Razvoj i integracija
Dva temeljna pristupa:
o INCREMENTAL DELIVERY viestruka ponavljajua isporuka
o SPIRAL DEVELOPMENT spiralni razvoj

Incremental delivery:
-

Razvoj je razbijen (podijeljen) u korake pri emu svaki korak

isporuuje odreenu zahtijevanu funkcionalnost
Izgrauje se lista prioriteta zahtijevane korisnike funkcionalnosti, i
funkcionalnosti sa najviim prioritetima isporuuju se u prvim
koracima

Kad se zapone razvoj novog koraka, korisniki zahtjevi se ne mijenjaju,

ali se obogauju zahtjevom budueg koraka

PREDNOSTI:
-

Korisnik moe dobiti novu funkcionalnost u svakom koraku pa je time

i cjelokupna sustavna funkcionalnost prije dostupna
Raniji koraci ponaaju se kao prototipi, pa mogu sluiti i kao podloga
za korisnike zahtjeve u buduim koracima
Uspjenost cijelog sustava je manje rizina
Programski elementi najveih prioriteta (poetni koraci) testirat e se
najvie.

Spiral development spiralni razvoj:

-

Proces razvoja softvera prikazan je u obliku spirale, za razliku od

slijednog nizanja aktivnosti sa povratnim vezama
Svaki krug u spirali prikazuje fazu u razvoju softvera
Ne postoje fiksne faze kao specifikacija ili dizajn krugovi u spirali
definiraju se po potrebi
Rizici se procjenjuju i rjeavaju kroz proces razvoja

VI. AKTIVNOSTI U RAZVOJU SOFTVERA

1. Specifikacija zahtjeva na softver
2. Dizajn i implementacija softvera
3. Validacija (testiranje i potvrda korektnosti) softvera
4. Evolucija softvera
1. Specifikacija zahtjeva na softver
-

Proces kojim se:

o definiraju potrebiti servisi zahtijevani od korisnika,
o postavljaju ogranienja na operacije u sustavu,
o postavljaju ogranienja na razvoj sustava
Definiranje zahtjeva
o Studija izvodljivosti
o Upoznavanje i analiza zahtjeva
o Specifikacija zahtjeva
o Provjera valjanosti zahtjeva

2. Dizajn i implementacija
-

Proces konverzije specifikacije zahtjeva u izvrno programsko

rjeenje
1. Dizajn dizajniranje strukture kojom je podrana specifikacija
2. Implementacija prevoenje dizajniranje strukture u izvrni
programski oblik softver

Dizajn i implementacija usko su povezani i obavezni (nije mogue

postojanje jednog bez drugog)

AKTIVNOSTI DIZAJNA:
-

Dizajniranje arhitekture programskog proizvoda

Saeta specifikacija
Dizajn suelja
Dizajn komponenata
Dizajn podataka
Dizajn algoritama

STRUKTURIRANE METODE:
-

Metodoloki potkrijepljen dizajn sustava

Dizajn se obino dokumentira skupom grafikih modela
Mogui modeli:

Object Model
Sequence Model
State Model
Structural Model
Data flow Model

PROGRAMIRANJE I ISPRAVLJANJE GREAKA:

Programer provodi odreena programska testiranja, a time i

rjeava pronaene programske pogreke

Proces ispravljanja pogreke:

1. Lociranje greke
2. Izrada popravka
3. Popravak greke
4. Ponovni test programa

3. Validacija
-

Provodi se kako bi se ustanovilo da li izgraeni programski

proizvod odgovara prethodnoj projektnoj dokumentaciji i
zahtjevima korisnika
Provode se procesi:
o
o

Verifikacije provjera korektnosti postupaka

Validacija provjera korektnosti podataka

Provodi se provjera i pregled procesa i testiranje funkcionalnosti

programa
Testiranje funkcionalnosti provodi se provoenjem funkcionalnosti
programa i koritenjem korektnih stvarnih podataka

FAZE TESTIRANJA:
- Testiranje komponenti
o
o

Testiranje svake komponente pojedinano

Komponente mogu biti funkcije i/ili objekti koji su pojedinani ili
meusobno povezani

Testiranje sustava
o
o

Testiranje kompletnog programskog sustava

Testiranje na izvanredne okolnosti

Testiranje programskog sustava sa stvarnim podacima od

korisnika
Provjera da li sustav odgovara zahtjevima korisnika

Testiranje u stvarnosti
o

4. Evolucija
-

Softver je fleksibilan i moe se mijenjati ovisno o zahtjevima korisnika

Svaka promjena u poslovnim pravilima i odnosima mora rezultirati
promjenama u programskom sustavu
esto se smatra da je faza odravanja manje bitna Pogreno
Postoji granica izmeu razvoja i evolucije (odravanja) programskog
sustava. Granica postaje sve manja jer je sve manje sustava potpuno
novo.