poglavlje 1: uvod u softverskoweb.studenti.math.pmf.unizg.hr/~manger/si/si-1.pdf · 2020. 9. 9. ·...

Poglavlje 1:

Uvod u softversko

inženjerstvo

Sastavio: Robert Manger

01.10.2020

Sveučilište u Zagrebu

PMF – Matematički odsjek

SOFTVERSKO INŽENJERSTVO

Predavanja 2020/2021

O čemu je riječ u Poglavlju 1

• Navodimo osnovne pojmove koji se susreću u softverskom inženjerstvu.

• Opisujemo modele koji ugrubo opisuju proces razvoja softvera.

• Spominjemo metode razvoja softvera: one profinjavaju i konkretiziraju pojedine modele.

• Naglašavamo da postoji menadžerski aspekt softverskog inženjerstva: problematika upravljanja složenim projektima.

SI-1 SOFTVERSKO INŽNJERSTVO 2

Sadržaj Poglavlja 1

1.1. Osnovni pojmovi vezani uz softversko inž

1.2. Modeli za softverski proces

1.3. Klasične i agilne metode razvoja softvera

1.4. Upravljanje softverskim projektom


Osnovni pojmovi vezani uz softv inž


• Odnose se na razvoj softvera.

• Već smo ih susretali u prethodnim kolegijima:

− programski jezici

− računarski praktikumi

− strukture podataka i algoritmi

− baze podataka

− mreže računala i slično.

• Sad tim istim pojmovima dajemo preciznije značenje.

Softverski produkt i softversko inž (1)

• Softverski produkt: skup računalnih programa i pripadne dokumentacije, stvoren zato da bi se isporučio nekom korisniku.

• Softverski produkt može biti razvijen za:– sasvim određenog korisnika

(bespoke product, customized product)

– općenito za tržište

(generic product).

• Softverski produkt često ćemo nazivati softverili (softverski) sustav.



• Atributi kvalitete softverskog produkta:

– Mogućnost održavanja. Softver se mora moći mijenjati

u skladu s promijenjenim potrebama korisnika.

– Pouzdanost i sigurnost. Softver se mora ponašati na

predvidiv način, te ne smije izazivati fizičke ili

ekonomske štete.

– Efikasnost. Softver mora imati zadovoljavajuće

performanse te on treba upravljati strojnim resursima

na štedljiv način.

– Upotrebljivost. Softver treba raditi ono što korisnici od

njega očekuju, sučelje mu treba biti zadovoljavajuće te

za njega mora postojati dokumentacija.



• Softversko inženjerstvo: disciplina koja se bavi svim aspektima proizvodnje softvera:– Dakle, bavi se modelima, metodama i alatima koji su

nam potrebni da bi na što jeftiniji način mogli proizvoditi što kvalitetnije softverske produkte.

• Softversko inženjerstvo je u isto vrijeme:– znanstvena disciplina

– tehnička struka

– profesija

• U bliskoj je vezi s još dva područja znanja:– računarstvo (computer science)

– sistemsko inženjerstvo (system engineering)


Softverski proces, metode i alati (1)

• Softverski proces: skup aktivnosti i pripadnih

rezultata čiji cilj je razvoj ili evolucija softvera.

• Osnovne aktivnosti unutar softverskog

procesa su:

– utvrđivanje zahtjeva

– oblikovanje

– implementacija

– verifikacija i validacija

– održavanje odnosno evolucija.



• Model za softverski proces: idealizirani prikaz

softverskog procesa, kojim se određuje poželjni

način odvijanja i međusobnog povezivanja

osnovnih aktivnosti.

• Metoda razvoja softvera: profinjenje i konkretizacija odabranog modela:

– Uvodi specifičnu terminologiju.

– Dijeli osnovne aktivnosti u pod-aktivnosti.

– Propisuje što se sve mora raditi unutar pod-aktivnosti.

– Propisuje način dokumentiranja rezultata pod-aktivnosti.

– Daje naputke vezane uz organizaciju rada, stil oblikovanja, stil programiranja, itd.



• CASE alati (Computer Aided Software Engineering):

softverski paketi koji daju automatiziranu podršku za

pojedine aktivnosti unutar softverskog procesa:– Slijede određenu metodu razvoja softvera.

– Implementiraju pravila iz te metode.

– Sadrže editore za odgovarajuće dijagrame.

– Služe za izradu odgovarajuće dokumentacije.

• CASE alati se dijele na dvije vrste:– Upper-CASE alati - podrška za početne aktivnosti unutar

softverskog procesa, kao što su specifikacija i oblikovanje.

– Lower-CASE alati - podržavaju samu realizaciju softvera,

dakle programiranje, verifikaciju i validaciju, te eventualno

održavanje.SI-1 SOFTVERSKO INŽNJERSTVO 10

Dokumentacija softvera (1)

• Razvoj softvera ne sastoji se samo od razvoja

programa nego također i od sastavljanja

dokumenata koji prate te programe.

• Dokumentacija je sastavni i nezaobilazni dio

onoga što softverski inženjeri proizvode.

• Dokumentacija softvera dijeli se u dvije kategorije:

– Sistemska dokumentacija namijenjena je softverskim

inženjerima, omogućuje sam razvoj softvera i njegovo

kasnije održavanje.

– Korisnička dokumentacija namijenjena je korisnicima,

omogućuje im da koriste sustav.



• Primjeri dokumenata iz sistemske dokumentacije:

– dokument o zahtjevima

– dizajn sustava

– plan testiranja

– izvorni tekst programa.

• Primjeri dokumenata iz korisničke dokumentacije:

– funkcionalni opis

– vodič za instalaciju

– uvodni priručnik

– referentni priručnik

– priručnik za administriranje.SI-1 SOFTVERSKO INŽNJERSTVO 12


• Izrada dokumentacije:

– Jednim dijelom može se automatizirati ili barem

olakšati korištenjem CASE-alata.

– Za konačno oblikovanje dokumenata potrebni su

standardni uredski alati poput tekst procesora ili alata

za crtanje dijagrama.

• Oblici postojanja dokumentacije:

– u obliku zasebnih dokumenata (papirnatih ili

elektroničkih)

– u on-line obliku, izravno dostupna iz samog softvera

koji opisuje.


Modeli za softverski proces

• Svi modeli se u većoj ili manjoj mjeri zasnivaju

na istim osnovnim aktivnostima:

– utvrđivanje zahtjeva (specifikacija)

– oblikovanje (design)

– implementacija (programiranje)

– verifikacija i validacija

– održavanje odnosno evolucija.

• Modeli se razlikuju po načinu odvijanja i

međusobnog povezivanja osnovnih aktivnosti.


Model vodopada (1)

• Model vodopada (waterfall model) nastao je u

ranim 70-tim godinama 20. stoljeća, kao

neposredna analogija s procesima iz drugih

inženjerskih struka (npr. gradnja mostova).

• Softverski proces je građen kao niz vremenski

odvojenih aktivnosti.

• Aktivnosti se odvijaju kao faze sekvencijalno

jedna iza druge.

• Svaka faza daje neki rezultat koji predstavlja

polazište za iduću fazu.

• Povratak u prethodnu fazu je nepoželjan.SI-1 SOFTVERSKO INŽNJERSTVO 16

Model vodopada (2)


Utvrđivanje zahtjeva (specifikacija)

Oblikovanje (design)

Integracija modula i testiranje sustava

Programiranje i testiranje modula

Puštanje u rad i održavanje

Dokument o zahtjevima

Dizajn sustava

Moduli

Sustav

Model vodopada (3)

• Prednosti:– Omogućeno je detaljno planiranje cijelog softverskog

procesa i podjela poslova na velik broj suradnika.

– Lagano se može utvrditi trenutno stanje.

– Dobro je prihvaćen od menadžera.

• Mane:– Faze je u praksi teško razdvojiti, dolazi do naknadnog

otkrivanja grešaka i nepoželjnog vraćanja.

– Zbog tendencije da se zbog poštovanja rokova u

određenom trenutku „zamrzne“ pojedina faza, sustav se

često nastavlja razvijati u nezadovoljavajućem obliku.

– Proces je spor, pa se može dogoditi da u trenutku

puštanja u rad sustav već bude neažuran i zastario.


Model evolucijskog razvoja (1)

• Model evolucijskog razvoja (evolutionary

development) nastao je kao protuteža modelu

vodopada.

• Na osnovi približnog opisa problema razvija se

polazna verzija sustava i pokazuje se korisniku.

• Temeljem korisnikovih primjedbi, ta polazna

verzija se poboljšava, opet pokazuje, itd.

• Nakon dovoljnog broja iteracija dobiva se

konačna verzija sustava.

• Unutar svake iteracije, osnovne aktivnosti se

obavljaju simultano i ne daju se razdvojiti.




Utvrđivanje zahtjeva (specifikacija)

Oblikovanje (design)

Verifikacija, validacijaImplementacija

simultane aktivnosti

Približni

opis

Polazna

verzija

Privremene

verzije

Konačna

verzija


• Prednosti:

– Model je u stanju proizvesti brzi odgovor na zahtjeve

korisnika.

– Razvoj je moguć i onda kad su zahtjevi ispočetka

nejasni.

– Specifikacija se može postepeno razvijati u skladu sa

sve boljim korisnikovim razumijevanjem problema.

• Mane:

– Proces nije transparentan za menadžere.

– Konačni sustav obično je loše strukturiran zbog stalnih

promjena, te je nepogodan za kasnije održavanje.

– Zahtijevaju se posebni alati i natprosječni softverski

inženjeri.SI-1 SOFTVERSKO INŽNJERSTVO 21

Model inkrementalnog razvoja (1)

• Model inkrementalnog razvoja (incremental

development) može se shvatiti kao hibrid modela

vodopada i modela evolucijskog razvoja.

• Sustav se opet razvija u nizu iteracija. No za

razliku od evolucijskog modela, pojedina iteracija

ne dotjeruje već realizirani dio sustava, nego mu

dodaje sasvim novi dio - inkrement.

• Razvoj jednog inkrementa unutar jedne iteracije

odvija se po bilo kojem modelu - na primjer kao

vodopad.



• Prednosti:

– Proces je još uvijek transparentan za menadžere, jer je

vidljivo do kojeg smo inkrementa došli.

– Korisnici ne moraju dugo čekati da bi dobili prvi

inkrement koji zadovoljava njihove najpreče potrebe.

– Razvoj slijedi prioritete.

• Mane:

– Koji put je teško podijeliti korisničke zahtjeve u smislene

inkremente.

– Budući da cjelokupni zahtjevi nisu dovoljno razrađeni na

početku, teško je odrediti zajedničke module koji bi

morali biti implementirani u prvom inkrementu.SI-1 SOFTVERSKO INŽNJERSTVO 24

Model formalnog razvoja (1)

• Model formalnog razvoja (formal systems

development) zasniva se na korištenju

takozvanih formalnih metoda za razvoj softvera.

• Zahtjevi se precizno definiraju na formalni

način, korištenjem nedvosmislene matematičke

notacije.

• Zatim se ta formalna specifikacija transformira

do programa, nizom koraka koji čuvaju

korektnost.



• Prednosti:– Nakon izrade formalne specifikacije, sve daljnje faze

razvoja softvera mogle bi se automatizirati.

– Postoji „matematički“ dokaz da je program točna

implementacija polazne specifikacije; nema velike

potrebe za testiranjem.

– Rješenje je neovisno o platformi, dakle portabilno.

• Mane:– Izrada formalne specifikacije zahtijeva velik trud i znanje.

– Dokazi korektnosti transformacija postaju preglomazni za

iole veće sustave.

– Korisnici ne mogu pratiti razvoj.

– Specifikacijski jezici nisu pogodni za interaktivne sustave.


Model grafičkog razvoja (1)

• Model grafičkog razvoja (Model Driven

Engineering – MDE) sličan je modelu formalnog

razvoja.

• Umjesto formalne specifikacije razvija se grafički

model (skup dijagrama) koji prikazuje građu i

ponašanje sustava.

• Koristi se grafički jezik za modeliranje poput UML.

• Primijetimo da se ovdje riječ „model“ pojavljuje u

dva značenja.

• Pretpostavlja se da postoji alat koji dijagrame

automatski pretvara u program. SI-1 SOFTVERSKO INŽNJERSTVO 28


• Model grafičkog razvoja ima svoje pobornike i

trenutno je predmet intenzivnog istraživanja.

• Prednosti su mu slične kao kod formalnog razvoja,

s time da bi trebao biti jednostavniji za upotrebu.

• Glavna mana mu je da za sada nije upotrebljiv

osim u vrlo jednostavnim primjerima. SI-1 SOFTVERSKO INŽNJERSTVO 29

Utvrđivanje

zahtjeva

(specifikacija)

Grafičko

modeliranje

(analiza,

oblikovanje)

Automatsko

generiranje

programa iz

grafičkog

modela


• Današnji CASE alati u stanju su generirati dio

programskog koda iz UML dijagrama, no daleko su

od toga da bi mogli generirati cijeli program.

• Kod složenijih sustava UML dijagrami zapravo i ne

mogu jednoznačno opisati sve detalje.

• To se u UML verziji 2.0 nastoji nadoknaditi

uvođenjem posebnog jezika zvanog Object

Constraint Language – OCL.

• OCL služi za specificiranje ograničenja koja nisu

vidljiva iz dijagrama.

• Očekuje se da će OCL pomoći da se ostvari

automatsko generiranje programa iz modela.SI-1 SOFTVERSKO INŽNJERSTVO 30

Model usmjeren na ponovnu upotrebu

(1)• Model usmjeren na ponovnu upotrebu (reuse-

oriented development) polazi od pretpostavke

da već postoje gotove i upotrebljive softverske

cjeline, na primjer:

– COTS sustavi (Commercial Off-The-Shelf Systems),

– ili dijelovi prije razvijenih sustava.

• Novi sustav nastoji se u što većoj mjeri

realizirati spajanjem postojećih sustava ili

dijelova.

• Ista ideja prisutna je i u drugim tehničkim

disciplinama.SI-1 SOFTVERSKO INŽNJERSTVO 31


(2)


Utvrđivanje zahtjeva

Analiza raspoloživih

dijelova

Oblikovanje sustava uz

ponovnu upotrebu dijelova

Modifikacija zahtjeva

Implementacija i integracija

Verifikacija i validacija sustava


(3)• Prednosti:

– Smanjuje se količina softvera koju stvarno treba

razviti, te se tako smanjuje vrijeme, trošak i rizik.

– Stavlja se oslonac na provjerene i dobro testirane

dijelove softvera.

• Mane:

– Zbog kompromisa u specifikaciji sustav možda neće

u potpunosti odgovoriti stvarnim potrebama korisnika.

– Djelomično je izgubljena kontrola nad evolucijom

sustava, budući da ne upravljamo razvojem novih

verzija korištenih dijelova.


Klasične i agilne metode razvoja


• Rad softverskog tima obično se organizira u skladu s nekom metodom razvoja softvera. − Svaka od metoda slijedi jedan od modela za

softverski proces ili kombinira više modela.

− Osnovne aktivnosti iz modela podijeljene su u manje aktivnosti.

− Propisuje se način odvijanja svake aktivnosti te način njenog dokumentiranja.

• U sljedećim odjeljcima− navodimo osnovna svojstva pojedinih vrsta metoda

− Detaljnije opisujemo dvije danas aktualne metode: UP odnosno XP.

Vrste metoda i njihova svojstva (1)

• Danas korištene metode za razvoj softvera

ugrubo se dijele na klasične i agilne.

• Svojstva klasičnih metoda.– Razvoj softvera promatra se kao pažljivo planirani

proces koji ima svoj početak i kraj. U tom procesu u

potpunosti se utvrđuju zahtjevi te se softver realizira u

skladu s njima.

– Provodi se upravljanje projektom. Određuje se precizni

plan aktivnosti, po potrebi i za dulji vremenski period

unaprijed, te raspored ljudi i resursa po aktivnostima.

– Inzistira se na urednom dokumentiranju svih aktivnosti

i svih proizvedenih dijelova softvera.



• Daljnja podjela klasičnih metoda:

– Starije funkcionalno-orijentirane metode poput

Yourdonove ili Jacksonove JSD slijede logiku

funkcionalno-orijentiranih programskih jezika

(Cobol, C, Fortran).

– Novije objektno-orijentirane metode predstavljaju

nadgradnju objektno-orijentiranih programskih

jezika (Java, C++, C#) i danas su se integrirale u

zajednički standard UP (Unified Process - Booch,

Rumbaugh, Jacobson - 90-te godine) koji se oslanja

na grafički jezik UML (Unified Modeling Language).



• Svojstva agilnih metoda.

– Razvoj softvera promatra se kao niz iteracija čiji broj nije

moguće predvidjeti. Svaka iteracija usklađuje sustav s

trenutnim zahtjevima. Zahtjevi se stalno mijenjaju, ne

postoji cjelovita ili konačna specifikacija.

– Ne postoji upravljanje projektom u pravom smislu riječi.

Aktivnosti se dogovaraju s korisnicima te se odvijaju uz

njihovo aktivno sudjelovanje. Planiranje je kratkoročno –

jedan ili dva tjedna unaprijed.

– Izbjegavaju se svi oblici dokumentacije osim onih koji se

mogu automatski generirati iz programa. Sam program

u izvornom obliku predstavlja svoju najpouzdaniju

dokumentaciju.SI-1 SOFTVERSKO INŽNJERSTVO 38


• Najpopularnija agilna metoda je Extreme

Programming – XP. Također je poznata metoda

Scrum koja se uglavnom bavi agilnim vođenjem

projekta i može se kombinirati s XP.

• U literaturi su zabilježena istraživanja koja mjere i

uspoređuju učinkovitost pojedinih metoda za

razvoj softvera. Prema tim istraživanjima:– Agilne metode imaju prednosti kad je riječ o malim i

kratkoročnim projektima u brzo promjenjivom

poslovnom okruženju.

– No nije se još dokazalo da se agilne metode mogu

uspješno skalirati na velike projekte.


Primjer klasične metode (1)

• Metoda Unified Process – UP služi za razvoj

objektno-orijentiranih sustava.

• UP je nastala na kraju 20. stoljeća u tvrtci

Rational Corporation (danas dio IBM-a). Stvorio

ju je Ivar Jacobson u suradnji s Grady Boochom

i Jamesom Rumbaughom.

• Ime je odabrano zato što je UP objedinio

nekoliko prijašnjih metoda istih autora.

• UP je u bliskoj vezi s grafičkim jezikom UML –

obje tvorevine razvijene su u okviru istog

projekta s namjerom da budu komplementi

jedna drugoj. SI-1 SOFTVERSKO INŽNJERSTVO 40


• Proces razvoja softvera u skladu s UP sastoji

se od 4 faze (phases) koje se realiziraju u

vremenskom slijedu jedna iza druge.

• Pojedina faza završava onda kad se

dosegne njezin međaš (milestone), dakle kad

se postignu njezini ciljevi.

• Svaka faza realizira se kroz simultano i

iterativno odvijanje 5 temeljnih aktivnosti

(core workflows).



• Zbog postojanja vremenski odvojenih faza UP

podsjeća na model vodopada.

• No iteracija temeljnih aktivnosti liči na model

evolucijskog razvoja.

• Dakle UP ustvari kombinira dva modela

nastojeći iskoristiti prednosti jednog i drugog.

• U svakoj fazi postoji jedna ili dvije osnovne

aktivnosti na koje je stavljen posebni naglasak.

• Kod manjih projekata faze možemo poistovjetiti

s odgovarajućim dominantnim aktivnostima.



• Faze UP, ciljevi, naglasci, međaši:

– Inception. Ciljevi: dokazati izvedivost i isplativost

projekta, utvrditi ključne zahtjeve da bi se vidio

kontekst (doseg) sustava, prepoznati rizike.

Naglasak: zahtjevi i analiza. Naziv međaša: Life

Cycle Objectives.

– Elaboration. Ciljevi: stvoriti izvršivu jezgru arhitekture

sustava. Profiniti procjenu rizika, definirati atribute

kvalitete, evidentirati primjere korištenja (use-case)

koji pokrivaju 80% funkcionalnih zahtjeva, stvoriti

detaljni plan za fazu konstrukcije. Naglasak: zahtjevi,

analiza, te pogotovo oblikovanje. Naziv međaša: Life

Cycle Architecture.



• Faze UP, ciljevi, naglasci, međaši (nastavak):

– Construction. Ciljevi: dovršiti zahtjeve, analizu i

oblikovanje, te dograditi jezgru arhitekture do konačnog

sustava. Pritom treba očuvati integritet arhitekture i

oduprijeti se pritiscima da se sustav dovrši na brzinu.

Obaviti beta test i pokrenuti sustav. Naglasak:

oblikovanje, te pogotovo implementacija. Naziv međaša:

Initial Operational Capability.

– Transition. Ciljevi su: popraviti uočene greške, prirediti

sustav za rad u korisničkoj okolini, distribuirati ga na

korisnička radna mjesta, stvoriti korisničku

dokumentaciju, organizirati podršku korisnicima, napraviti

“post-project review”. Naglasak: implementacija, te

pogotovo test. Naziv međaša: Product Release. SI-1 SOFTVERSKO INŽNJERSTVO 45


• Temeljne aktivnosti u UP:

– Zahtjevi (requirements). Utvrđuje se što sustav treba

raditi.

– Analiza (analysis). Zahtjevi se analiziraju, profinjuju i

strukturiraju.

– Oblikovanje (design). Predlaže se građa sustava koja

će omogućiti da se zahtjevi realiziraju.

– Implementacija (implementation). Stvara se softver koji

realizira predloženu građu.

– Testiranje (test). Provjerava se da li stvoreni softver

zaista radi onako kako bi trebao.


Primjer agilne metode (1)

• Metoda Extreme Programming – XP nastala je

oko 2000-te godine, autor je Kent Beck.

• Naziv je odabran zato što XP ideju iterativnog

razvoja softvera s naglaskom na programiranje

tjera do ekstremnih razmjera.

• Razvojni proces u skladu s XP sastoji se od

kontinuiranog niza vrlo brzih iteracija.

– Svaka iteracija stvara novo izdanje sustava koje se

isporučuje korisniku.

– Vremenski razmak između dvije isporuke nije veći od

dva tjedna.SI-1 SOFTVERSKO INŽNJERSTVO 47



Izaberi

korisničke priče

za novo izdanje

Razbij

korisničke priče

u zadatke

Planiraj novo

izdanje

Evaluiraj sustavIsporuči novo

izdanje

Razvij,

integriraj i

testiraj softver

Jedna iteracija metode XP:


• Novo izdanje sustava može sadržavati novu

funkcionalnost – tada XP podsjeća na model

inkrementalnog razvoja.

• No moguće je da novo izdanje samo popravlja ili

mijenja već postojeću funkcionalnost – tada XP

liči na model evolucijskog razvoja.

• Dakle, XP kombinira inkrementalni i evolucijski

model. No naglasak je na izuzetno kratkim i

brzim iteracijama.



• Zahtjevi u XP prikazuju se kao skup kratkih kartica

teksta, takozvanih korisničkih priča (user stories).

– Na početku iteracije biraju se one priče koje će se

implementirati u dotičnom izdanju – uzima se onoliko

priča koliko se može implementirati u dva tjedna i to one

s najvišim prioritetom.

– Ostale priče se ostavljaju za buduća izdanja.

– Odabrane priče razgrađuju se u manje zadatke koji se

raspoređuju programerima u skladu s procijenjenom

složenošću.

– Opisani neformalni postupak planiranja novog izdanja

naziva se planning game.SI-1 SOFTVERSKO INŽNJERSTVO 50


• U XP-u ne može doći do kašnjenja isporuke.– Ono što se do predviđenog roka isporuke uspjelo

implementirati to se isporučuje, ostalo se ostavlja za

buduća izdanja.

– Naručitelj programerima plaća utrošeno radno vrijeme.

Nema ugovora koji bi vezao plaćanje uz traženu

funkcionalnost.

• U metodi XP iznimno važnu ulogu igraju korisnici.– Postoji predstavnik korisnika koji je član razvojnog tima i

stalno je dostupan ostalim članovima.

– Predstavnik korisnika donosi korisničke priče, određuje

prioritete, dogovara se o sadržaju idućeg izdanja,

sudjeluje u testiranju sustava.SI-1 SOFTVERSKO INŽNJERSTVO 51


• Važna inovacija koju je XP donio u programersku

praksu naziva se razvoj gdje test ide prvi (test-first

development):

– Najprije se sastavljaju testovi za novi komad

funkcionalnosti, zatim se ta funkcionalnost implementira.

– Čim je novi programski kod napisan, on se odmah

testira.

– Nužan je odgovarajući CASE-alat.

– Testovi se trajno pohranjuju.

– Nad novom verzijom softvera, osim najnovijih testova,

također se moraju izvršiti i svi prijašnji testovi.



• Druga inovacija koju je XP donio je programiranje

u paru (pair programming).

– Jedan zadatak ne obavlja jedan programer nego

dvojica. Oni sjede za istom radnom stanicom i zajedno

pišu isti programski kod.

– Dvojica suradnika u zajedničkoj diskusiji lakše dolaze

do dobrog rješenja te jedan drugom ispravljaju greške.

– Parovi nisu fiksirani već se mijenjaju od zadatka do

zadatka.

– Time se postiže kolektivno vlasništvo nad programskim

kodom, gdje su svi upućeni u sve dijelove programa.



• U XP-u se softver oblikuje tako da podrži trenutne

zahtjeve i ništa više od toga. – To je u suprotnosti s principima tradicionalnog soft inž.

– Pobornici XP smatraju da se promjene ionako ne mogu

predvidjeti, pa se ne isplati o njima brinuti unaprijed.

• Opasnost kod iterativnog razvoja softvera je da se

struktura softvera postepeno degradira. XP

otklanja tu opasnost povremenim reorganiziranjem

koda, tzv. refaktorizacijom (refactoring). – Kad programer primijeti da se struktura programa

narušila, on je popravlja tako da pojednostavi ili

premjesti neke dijelove koda, eliminira ponavljanja, itd.



• Metoda XP ne propisuje nikakve oblike

dokumentacije. – Prema pobornicima XP, jednostavan i pregledno

napisani programski kod sam sebe najbolje

dokumentira.

– Štoviše, iz tog koda moguće je automatski generirati

razne izvještaje i dijagrame kakvi se inače koriste u

dokumentima.

– Ovakav pristup je realističan u situaciji kad se nove

verzije softvera proizvode gotovo svakodnevno –

ažuriranje zasebne dokumentacije predstavljalo bi

preveliki teret i bilo bi podložno greškama.


Upravljanje softverskim projektom

• Klasične metode razvoja softvera predviđaju da

će se softverski proces odvijati kao projekt.– Softversko inženjerstvo ima i svoj menadžerski

aspekt.

– Upravljanje softverskim projektom povjerava se

softverskom menadžeru.

• Upravljanje softverskim projektom bit će tema

posebnog kolegija. Ovo potpoglavlje daje samo

uvodni prikaz. – Nabrajaju se razni poslovi softverskog menadžera.

– Podrobnije se opisuju dva takva posla: planiranje i

praćenje projekta te upravljanje rizicima.


Poslovi softverskog menadžera (1)

• Softverski menadžer nastoji postići sljedeće ciljeve:

– isporučiti softver naručitelju do ugovorenog roka

– držati ukupne troškove unutar planiranih granica

– stvoriti softver koji zadovoljava naručiteljeva očekivanja

– postići da razvojni tim dobro funkcionira i da njegovi

članovi budu zadovoljni poslom koji obavljaju.

• Slični ciljevi žele se postići u bilo kojem projektu.

– Ipak, softversko inženjerstvo razlikuje se od drugih

inženjerskih struka.

– Te razlike čine upravljanje softverskim projektom i

postizavanje ovakvih ciljeva relativno teškim zadatkom. SI-1 SOFTVERSKO INŽNJERSTVO 58


• Osobine po kojima se razvoj softvera razlikuje od

na primjer gradnje mosta ili broda.

– Produkt je „neopipljiv“. Teško je vidjeti rezultat. Teško

je procijeniti koliki dio posla je obavljen i da li je

kvalitetno obavljen.

– Nema standardnog razvojnog procesa. Postoje razne

metode i alati. Ne zna se koji je najbolji način razvoja

zadane vrste softvera u zadanim okolnostima.

– Projekt je obično „neponovljiv“. Novi softver donosi

nešto novo i još neviđeno. Iskustva na starim

projektima nisu sasvim primjenjiva. Tehnologija se

brzo mijenja pa je način rada svaki put drukčiji.



• Većina menadžera u većoj ili manjoj mjeri obavlja

sljedeće poslove:

– pisanje prijedloga projekta, traženje podrške za

njegovu realizaciju

– procjenjivanje troškova projekta

– planiranje i praćenje projekta

– upravljanje rizicima

– podnošenje izvještaja nadređenom menadžmentu ili

naručiteljima

– izbor suradnika, poticanje njihovog individualnog i

timskog rada.


Planiranje i praćenje projekta (1)

• To je redoviti, svakodnevni i najegzaktniji posao

softverskog menadžera. Uključuje:– definiranje projektnih aktivnosti, njihovog trajanja i

međuzavisnosti

– određivanje kalendara početka i završetka svake

aktivnosti

– raspoređivanje ljudi i drugih resursa na aktivnosti

– praćenje izvršenja aktivnosti

– povremena revizija svih parametara.

• Za ovaj posao menadžer koristi egzaktne

upravljačke modele i metode koje su

implementirane u alatima poput MS Project.SI-1 SOFTVERSKO INŽNJERSTVO 61


• Primjer:

projekt s

12

aktivnosti.

Zadana su

trajanja

aktivnosti i

njihove

među-

ovisnosti.



SI-1 63

• Prikaz pomoću mreže, kalendar aktivnosti.

Start

T1

T2

T4

T3

T6

T7

T5

T8

T9

T10

T11

T12

Kraj

7

0

0

0

8

8

8

15

15

10

10

15

15

15

5

20

10

10

25

dan 55

dan 0

dan 0

dan 0

dan 0

dan 8

dan 8

dan 15

dan 15

dan 10

dan 23

dan 28

dan 38

dan 45



• Mreža omogućuje da se provede analiza kritičnih

putova.

– Kritični put je najdulji put od polaznog do završnog

čvora.

– Aktivnosti na kritičnom putu zovu se kritične aktivnosti.

– Menadžer mora posvetiti posebnu pažnju kritičnim

aktivnostima jer kašnjenje bilo koje od njih izazvat će

kašnjenje cijelog projekta.

– Za aktivnosti koje nisu na kritičnom putu izračunavaju

se maksimalna kašnjenja koja se mogu tolerirati.



• Rezultati

analize

kritičnih

putova

prikazani

pomoću

Ganttovog

dijagrama.

Start

T1

T2

T3

T4

T5

T6

Kraj

T7

T8

T9

T10

T11

T12

Dan

0

Dan

10

Dan

20

Dan

30

Dan

40

Dan

50

Dan

60


SI-1 66

• Raspoređivanje ljudi na aktivnosti.

T1

T2

T3

T4

T5

T6

T7

T8

T9

T10

T11T12

Dan

0

Dan

10

Dan

20

Dan

30

Dan

40

Dan

50

Dan

60

Janica

Ana

Franjo

Stjepan

Marija


• Nakon što se projekt počne izvršavati,

menadžer treba pratiti da li sve teče po planu.

• Kod većine projekata prije ili kasnije dolazi do

odstupanja od plana.

– Tada je potrebno uvažiti nove podatke i ponovo

generirati sve dijagrame.

– Dobit ćemo revidirani plan s odgođenim datumima

završetka nekih aktivnosti.

– Revizija plana obavlja se lako i brzo ako se služimo

alatom za upravljanje projektom poput MS Project.


Upravljanje rizicima (1)

• Rizici su nešto što bi voljeli da se ne desi, a dijele

se u tri kategorije.

– Rizici vezani uz projekt. Utječu na odvijanje projekta ili

na njegove resurse.

– Rizici vezani uz produkt. Utječu na kvalitetu softvera

koji razvijamo u sklopu projekta.

– Poslovni rizici. Utječu na organizaciju koja izvršava ili

financira projekt.

• Upravljanje rizicima sastoji se od predviđanja

rizika koji bi mogli utjecati na projekt te od

poduzimanja akcija da se oni izbjegnu ili umanje.



• Primjeri rizika iz raznih kategorija.


Primjer 1 Primjer 2 Primjer 3

Opis rizika

Ključni članovi

razvojnog tima možda

će se razboljeti u

najnezgodnije vrijeme.

Baza podataka koju

ugrađujemo u naš produkt

možda neće moći obraditi

dovoljan broj transakcija u

sekundi.

Financijer projekta

možda će imati

financijskih problema pa

će htjeti smanjiti sredstva

za projekt.

Kategorija

rizikavezan uz projekt vezan uz produkt poslovni

Vjerojatnost

pojavljivanjavelika umjerena mala

Učinak rizika ozbiljan podnošljiv katastrofalan

Plan za

upravljanje

Reorganiziraj tim tako

da ima više preklapanja

poslova pa će ljudi

lakše moći zamijeniti

jedan drugog.

Nabavi odmah bolju bazu

podataka za koju je manje

vjerojatno da će stvarati

probleme.

Napiši unaprijed

dokument koji dokazuje

da projekt daje važan

doprinos poslovnim

ciljevima financijera, te

da bi smanjivanje

sredstava donijelo više

štete nego koristi.

Strategija plana minimizacija izbjegavanje priprema


• Postupak upravljanja rizicima:

– četiri faze, svaka daje rezultate

– zadnje tri faze se iteriraju.


Identifikacija

rizika

Analiza

rizika

Planiranje

rizika

Nadziranje

rizika

Lista

potencijalnih

rizika

Rang lista

najznačajnijih

rizika

Planovi za

upravljanje

rizicima

Nove

procjene

rizika


• Faza identifikacije: identificiraju se rizici koji bi

mogli predstavljati prijetnju procesu razvoja

softvera, softveru koji se razvija ili organizaciji

koja je uključena u razvoj.

– Identifikacija se najčešće svodi na brainstorming u

kojem sudjeluju svi članovi tima.

– Softverski menadžer može upotrijebiti svoja iskustva

iz prošlih projekata te se sjetiti teškoća s kojima se

ranije susretao.

– Postoje i kontrolne liste uobičajenih rizika.



• Faza analize: za svaki od identificiranih rizika

potrebno je procijeniti njegovu vjerojatnost

pojavljivanja te ozbiljnost njegovog učinka.

– Vjerojatnost pojavljivanja rizika može biti: vrlo mala

(<10%) mala (10-25%), umjerena (25-50%), velika

(50-75%) ili jako velika (>75%).

– Učinak rizika može biti: katastrofalan (ugrožava

opstanak projekta), ozbiljan (uzrokuje veliko

kašnjenje projekta), podnošljiv (kašnjenje je unutar

dozvoljenog) ili neznatan.



• Nakon što su napravljene sve procjene,

oblikuje se rang lista rizika po kriteriju njihove

značajnosti.

– Gleda se kombinacija vjerojatnosti pojavljivanja i

učinka.

– Dakle najznačajniji su rizici s velikom vjerojatnošću

koji imaju katastrofalan ili ozbiljan učinak.

• Daljnje faze postupka provode se samo za

10-ak rizika s vrha rang liste.



• Faza planiranja: razmatra se svaki od

značajnih rizika i razvijaju se planovi za

upravljanje tim rizicima. Planovi najčešće

slijede jednu od tri strategije.

– Izbjegavanje. Nastojimo smanjiti vjerojatnost

pojavljivanja rizika.

– Minimizacija. Nastojimo smanjiti učinak rizika.

– Priprema. Nastojimo pripremiti sve što je potrebno

za djelovanje u trenutku pojave rizika.



• Faza nadziranja: sastoji se od provjere jesu

li sve pretpostavke o projektu, produktu i

poslovnom okruženju i dalje iste ili su se

promijenile.

– Povremeno treba ispitati za svaki od rizika da li

je on postao više ili manje vjerojatan, te da li se

promijenila ozbiljnost njegovog učinka.

– Ako je došlo do promjena, pokreće se nova

iteracija.


poglavlje 1: uvod u softverskoweb.studenti.math.pmf.unizg.hr/~manger/si/si-1.pdf · 2020. 9. 9. ·...

Documents