Transcript Prenos - Vegova

Programski inženiring
(Software Engeneering)
Programsko inženirstvo
Kaj je SWE? (a spet teorija)
Zakaj SWE? (kako bi bilo, če bi se temu izognili)
SWE da ali ne?
Izhodišče: ali ti je všeč, da je SW tako buggy in hkrati tako drag?
Stopnja
napak
Dejansko stanje –
posledica programskega
NEINŽENIRINGA!!!
sprememba
Idealna krivulja
Čas
Programsko inženirstvo
(software engineering – SWE)
D E F I N I C I J E (opredelitev)

Boehm: SWE je praktična uporaba računalništva, informatike,

Dennis: SWE je uporaba principov, veščin in umetnosti pri

Parnas: SWE je programiranje, če je izpolnjen vsaj en od naslednjih
managementa in drugih znanosti za analizo, načrtovanje, konstrukcijo
in vzdrževanje programske opreme in pridružene dokumentacije
načrtovanju in konstruiranju programov in programskih sistemov.
dveh pogojev:
– V razvoj programa je vključena več kot ena oseba
– Proizvedena bo več kot ena verzija programa

Fairley:
SWE je tehnološka in managerska disciplina, ki se ukvarja s
sistematično proizvodnjo in vzdrževanjem programskih izdelkov, ki so
razviti in prilagojeni pravočasno in sicer v okviru načrtovanega
proračuna (stroškov).
3
Programsko inženirstvo
(nad.)
D E F I N I C I J E (opredelitev)

Pomberger & Blaschek: SWE se praktična uporaba znanosti

‘Po domače’: SWE uporaba tehničnih in ne-tehničnih znanj pri

Okolje programskega inženirstva
za ekonomično produkcijo in uporabo visoko kakovostne
programske opreme.
razvoju, obratovanju in vzdrževanju programske opreme, s katero
so zadovoljni uporabniki in razvijalci.
– sistem računalnikov, podporne programske opreme, pripomočkov, procedur
in podpornega osebje, ki razvijalcem programske opreme zagotavlja
potrebne pogoje, avtomatizacijo procesov, metodologije in orodja.
4
Problemi razvoja velikih
programskih sistemov











Pravilnost oz. nepredvidljiva kakovost končnega produkta
Učinkovitost oz nizka produktivnost osebja in skupin
Obvladovanje kompleksnosti sistema
Zanesljivost sistema
Fleksibilnost sistema
Slaba / pomanjkljiva dokumentacija
Slabo vodenje / organizacija projektov
Predolgi razvojni cikli
Pomanjkanje kadra za razvoj programske opreme
Visoki stroški razvoja
Visoki stroški vzdrževanja
POSLEDICE
 Astronomska cena programskih rešitev
 Nezadovoljni uporabniki
 Nezadovoljni razvijalci
5
Vzroki za probleme pri razvoju
SW

Proces razvoja je v teoriji in praksi še vedno relativno slabo opredeljen
(?ali pa enostavno ne poznamo teorije?)

Uporaba zastarelih/ lastnih improviziranih metod razvijanja IS

Nezadostna uporaba računalniške podpore pri razvijanju IS

Pomanjkljivo metodološko znanje razvijalcev IS

Nezadostno upoštevanje dejstva, da informacijski procesi in sistemi za
različne ravni in načine upravljanja zahtevajo različne metode
njihovega razvijanja
6
Atributi kakovosti SW
Atributi
kakovosti SW
Pravilnost
Prijaznost
Primernost
Učinkovitost
Učljivost
Robustnost
Možnost
Portabilnost
vzdrževanja
Berljivost
Razširljivost
Možnost
testiranja
7
Glavni vzroki za (ne)uspeh SW







Zahteve uporabnikov so napačno ali le delno
zbrane;
Zahteve uporabnikov se prepogosto spreminjajo;
Uporabniki niso pripravljeni dajati zadostne
resurse projektom IT;
Uporabniki ne želijo sodelovati z razvijalci
Uporabniki imajo nerealna pričakovanja
Sistem ni več pomoč / benefikacija za
uporabnike;
Razvijalci ‘niso kos’ svoji nalogi.
8
Dobri načrti so delo dobrih
načrtovalcev







Najeti najboljše načrtovalce
Načrtovalcem zagotoviti permanentno
izobraževanje in ispopolnjevanje;
Podpirati izmenjavo informacij in znanj ter
interakcijo med načrtovalci;
Motivirati načrtovalce (odstraniti ovire) in
usmeriti njihove napore v produktivno delo;
Ponuditi dobro delovno okolje
Uskladiti cilje posameznikov z strategijo in cilji
organizacije
Dati poudarek na timskem delu
9
Mere za zagotavljanje kakovosti SW

Konstruktivne
–
–
–
–

Analitične
–
–
–
–

Dosledna uporaba metod v vseh fazah razvojnega procesa
Uporaba ustreznega razvojnega orodja
Razvoj SW na osnovi visoko kakovostnih pol-produktov
Dosledno pisanje/vzdrževanje razvojne dokumentacije
Statična analiza programa
Dinamična analiza programa
Sistematično izbiranje testnih primerov
Konsistentno beleženje rezultatov analiz
Organizacijske
– Nenehno (permanentno) izobraževanje razvijalcev
– Institucionalizacija zagotavljanja kakovosti (uvedba
standardov ISO, ANSI, IEEE…)
10
Večplastnost programskega
inženirstva
Orodja
Metode
Usmerjenost na procese
Usmerjenost na kakovost
11
Življenjski cikel programske opreme
(SDLC - System Development Life Cycle)
12
Življenjski cikel

prične se z zasnovo in konča z vzdrževanjem pri
uporabniku
razvojni proces razčlenimo na zaporedje medsebojno
odvisnih aktivnosti, ki temeljijo na začetnih potrebah po
izdelavi uporabnega produkta
zakaj “cikel" - vsak razviti produkt generira nove potrebe

Definicija (standard ANSI/IEEE Std 792-1983):


– življenjski cikel programske opreme = nabor diskretnih
aktivnosti v času razvoja programske opreme in programskih
sistemov
– faza življenjskega cikla = čas izvajanja posameznih aktivnosti
(tudi sama aktivnost)
13
Faze življenjskega cikla programske opreme
Problem
Delovanje in
vzdrževanje
Testiranje sistema
Implementacija in
testiranje komponent
Analiza zahtev
Specifikacija (opredelitev)
sistema
Načrtovanje sistema
in komponent
14
Faze življenjskega cikla
1. analiza zahtev
vključuje:
analiziranje programskega problema (funkcionalen opis) in specifikacije
želenega obnašanja grajenega sistema (funkcionalne zahteve in specifikacije)
rezultat:
Software Requirements Specifications oz. Specifikacije Zahtev Programske
Opreme
SZPO opisuje: funkcionalne zahteve, značilnosti strojnega okolja, obliko
uporabniških vmesnikov in performančne cilje oz. zahtevane zmogljivosti
15
Faze življenjskega cikla
1. analiza zahtev (nad.)
aktivnosti faze analize ločimo v 2 skupini:
analiza problema
–
rezultat = popolno razumevanje problemskega področja
opis produkta
–
rezultat = skladen in kompleten dokument programskih specifikacij
aktivnosti obeh skupin ne izvajamo zaporedno, temveč sočasno

v tej fazi odgovorimo na vprašanje: KAJ POTREBUJEMO
oz. kaj naj bi grajeni programski sistem zagotavljal
16
Faze življenjskega cikla
2. načrtovanje
vključuje:
preliminarno načrtovanje – dekompozicija (razčenitev) programskega
sistema v njegove dejanske konsistentne komponente in interaktivna
razgradnja teh komponent v vedno manjše podkomponente, dokler niso dovolj
majhne, da jih lahko ljudje brez težav razumejo
vsak modul je dokumentiran - opisani so vhodi, izhodi in funkcije.
podrobno načrtovanje – za vsak modul definiramo in dokumentiramo
algoritme
podrobno načrtovanje – za vsak modul definiramo in dokumentiramo
algoritme
 rezultati:
–
–
–
–

modularna razgradnja
definicija strukture podatkov
definicija formata datotek
opis pomembnejših algoritmov
v tej fazi odgovorimo na vprašanje: KAKO
oz. kako bomo zadovoljili identificirane zahteve oz. obnašanje sistema
17
Faze življenjskega cikla
2. načrtovanje (nad.)
rezultat:
–
–
–
–
modularna razgradnja
definicija strukture podatkov
definicija formata datotek
opis pomembnejših algoritmov
v tej fazi odgovorimo na vprašanje:
KAKO
oz. kako bomo zadovoljili identificirane zahteve oz.
obnašanje sistema
18
Faze življenjskega cikla
3. implementacija
izvedemo kodiranje
transformacija algoritmov v računalniku razumljiv jezik
testiramo in čistimo napake vsakega modula, specificiranega pri
načrtovanju
19
Faze življenjskega cikla
4. testiranje in integracija
testiranje posameznih modulov
osredotočimo na del programa, da lažje ugotovimo in odstranimo napake
kontroliramo tudi obnašanje modula glede na podane specifikacije
(funkcionalno testiranje)
integracijsko testiranje
že stestirane module integriramo oz. povežemo (združimo) v enotno
programsko strukturo ter jih testiramo (testiranje programskih komponent)
sistemsko testiranje
preverimo, ali se celoten programski sistem, postavljen v določeno strojno
okolje, obnaša ustrezno podanim specifikacijam zahtev programske opreme
20
Faze življenjskega cikla
5. prenos v ciljno okolje / uporaba
izročimo programsko in pripadajočo strojno opremo
 začne se uporaba sistema

6. vzdrževanje
neprestano iskanje napak in njihovo odstranjevanje
 razširitev sistema

7. umik iz uporabe
21
Modeli življenjskega cikla
Klasični pristopi:





SLAM-DUNK model
BAROČNI model
KASKADNI model
KASKADNI model, razširjen s prototipno komponento
SPIRALNI model
Objektni pristopi:

Unified Process
22
Slam- dunk model






najbanalnejši in najpogosteje uporabljen model
izrazito negativen primer
na začetku se začne tudi kodiranje
filozofija uporabnika metode: preprosteje je kodirati, odkrivati in popravljati
napake kot pa izgubljati čas z "znanostjo" - psihološko ozadje
občutek, da lahko brez natančne razgradnje pristopimo k realizaciji, saj
imamo "vse v glavi"
takšne projekte imenujemo tudi "kmalu bo gotovo", zanje pa je značilno, da
vedno zamujajo ali pa nikoli niso gotovi
23
Baročni model







vnaša disciplino v prej opisan "slam-dunk" model
bistvo modela: predhodna faza se konča pred naslednjo fazo - ta model
lahko imenujemo tudi "etapni model"
baročni model uzakonjuje pretirano disciplino
zahteve so vedno spreminjajoče =>paradoks, faza analize se nikoli ne
konča
v realni okvir lahko ta proces spravimo le tako, da se fazi analize in snovanja
delno prekrivata
baročni model enostavno ne deluje, ker razvoj programske opreme ni
determinističen proces
ta model je prispeval k razvoju realnejšega "kaskadnega" modela
24
Kaskadni model
Analiza (KAJ?)
Načrtovanje (KAKO?)
Implementacija (NAREDI)
Testiranje (PREIZKUSI)
Pomanjkljivost: predolg
čas porabljen od začetka
do implementacije.
Rešitev – uporaba
prototipov
Prenos v ciljno okolje
Uporaba in vzdrževanje
25
Prototipiranje
Cilji prototipiranja:
–
–
–
–
–
oddaljiti se od stroge zaporednosti
pospešiti odzivni čas
zmanjšati tveganje za stranko in razvijalca
cenenost in hitrost
nepopolno, vendar da nazorne rezultate
Prototip - delna implementacija sistema, narejena s
primarnim namenom, da omogoči uporabniku, stranki ali
razvijalcu čim lažjo seznanitev s problemom ali njegovo
rešitvijo. (A. Davis)
26
Metodi prototipiranja
metoda
zavračanja (throw-away)
–ustrezna za raziskovalne in eksperimentalne prototipe
–zgradimo hiter in robusten (quick-and-dirty) prototip, ki ga predstavimo
uporabnikom z namenom, da skupaj z njimi:
 ugotovimo izvedljivost želja (zahtev)
 potrdimo potrebnost oz. nujnost posameznih funkcij
 odkrijemo manjkajoče (nepodane) zahteve
 raziščemo možnosti razvoja ustreznega uporabniškega vmesnika.
–po pridobitvi vsega potrebnega znanja o problemu in o rešitvah prototip
zavržemo in začnemo razvijati sistem
razvojna
metoda (evolutionary)
–ustrezna za razvojne prototipe
–sistematičen pristop pri izgradnji, prototip preraste v sam sistem
27
Spiralni model
določi cilje,
alternative,
omejitve
ovrednoti alternative,
identificiraj in zmanjšaj tveganja
prototipi
načrt zahtev principi
zahteve
sistemsko
podrobno
načrtovanje
načrtovanje
načrt razvoja
načrt izvedbe
načrtovanje
naslednje faze
test &
instalacija
implement
razvoj&
verifikacija izdelka
28
Analiza spiralnega modela
– omogoča boljšo oceno tveganja
– mešanica čistega strukturiranega in fleksibilnega
prototipnega modela
– podpira hitre odzive in zagotavlja kakovost
29
Preverjanje rezultatov
VALIDACIJA
 preverjanje ustreznosti programskega izdelka
 Ali gradim pravi produkt?
VERIFIKACIJA
 preverjanje pravilnosti programskega izdelka
 Ali gradim produkt pravilno?
Dokaz pomena sprotnega preverjanja
Razmerje stroškov za odpravljanje napake, ki je odkrita
v fazi analize zahtev : v fazi vzdrževanja =
1 : 200
Značilno za XP (eXtreme programming)
30
Dva inženirska pristopa
RAZVOJNO INŽENIRSTVO
•proizvede nov sistem in izhaja iz začetnih postavk ter danosti
OBRNJENO INŽENIRSTVO
•izhaja iz sistema, ki obstaja in deluje
•proces razstavitve in analize obstoječega fizičnega podatkovnega
in procesnega modela IS in njegova vnovična obnovljena ali
spremenjena izgradnja
•vzroki: uvedba sodobnejše tehnologije ali spremenjene zahteve
uporabnikov
•uporaba: za vzdrževanje, izboljševanje, spreminjanje ali
ažuriranje informacijskega sistema ali za celotno zamenjavo z
novim sistemom
31
Vidiki razvoja programskih rešitev
Procesni vidik => Diagram toka podatkov (DFD)
opisuje transformacije nad podatki
poenostavljena notacija: Vhod --> Proces --> Izhod
obravnava procesno obnašanje sistema - kako sistem pretvori vhode v izhode
Podatkovni (informacijski) vidik => Entitetno relacijski diagrami (ERD) in
podatkovni slovarji
opisuje obliko informacij, ki jih mora sistem procesirati
nakazuje medsebojne relacije med informacijskimi enotami
nanaša se na strukturo in uporabo podatkov v sistemu
Dogodkovni vidik
opisuje obnašanje sistema v realnem času
nanaša se na dinamično obnašanje sistema => kako si dogodki sledijo v
časovnem zaporedju
kontrolni diagrami in diagrami prehajanja stanj
32
Orodja CASE
Computer Aided Software Engineering
 CASE - tehnologija avtomatizacije razvoja in vdrževanja
programske opreme oz. sistemov

Osnovna ideja: s povezovanjem in avtomatizacijo vseh faz
življenjskega cikla programskih sistemov zagotoviti popolnoma
integrirana orodja, ki bodo zmanjšala trud, potreben za
razvoj in vzdrževanje programske opreme
33
Pridobitve CASE








praktičnost strukturnih in objektnih tehnik
vsiljuje programsko/informacijsko inženirstvo
izboljšana kvaliteta programske opreme (avtomatske
kontrole, preverjanja)
praktičnost prototipiranja
lažje, enostavnejše vzdrževanje
skrajšan čas razvoja
razvijalci se lahko osredotočijo na kreativni del razvoja
ponovna uporaba programskih komponent
34
Funkcije CASE

Diagramska orodja
// risanje diagramov, kreiranje grafičnih
specifikacij

Oblikovalniki // za kreiranje obrazcev, poročil, specifikacij, preprostih
prototipov

Podatkovni slovarji

Preverjanje specifikacij // avtomatsko odkrivanje nepopolnih,

Generatorji kode // generiranje izvedljive kode avtomatično (direktno)

Generatorji dokumentacije //
sintaktično nepravilnih in nekonsistentnih specifikacij
iz grafičnih specifikacij sistema
za pridobivanje tehnične in
uporabniške dokumentacije, ki jo zahtevajo razvojne tehnike
35
CASE repozitorij
mehanizem za hranjenje in organizacijo vseh
informacij o programskem sistemu:








informacije o problemu, ki ga rešujemo
inf. o problemskem področju oz. domeni
inf. o procesu, ki ga uporabljamo
podatkovne in procesni modeli
prototipi
resursi projekta in zgodovina,
organizacijski kontekst ...
omogoča praktično uporabo koncepta ponovne uporabnosti (reusability) =>
dvig produktivnosti // ne gre le za ponovno uporabo izvorne kode modulov, temveč
tudi projektnih planov, prototipnih modelov, specifikacij, ..
36
Cilji CASE
Spremeniti način gradnje programskih sistemov
Zagotoviti:
1. Interaktivno razvojno okolje //hitri odzivni časi, namenskimi
resursi in zgodnje preverjanje/iskanje/ izločanje napak
2. Avtomatizacijo mnogih opravil razvoja in vzdrževanja
3. Vizualno programiranje // zmogljiv uporabniški vmesnika
Končni cilj CASE tehnologije:
s pomočjo integriranih programskih orodij avtomatizirati
celoten življenjski cikel programske opreme
37
Kategorije CASE

Upper CASE (front-end CASE)
– zgodnje faze življenjskega cikla (analiza in
načrtovanje)

Lower CASE (back-end CASE)
– kasnejše faze življenjskega cikla (implementacija in
vzdrževanje)

Integrirana (integrated) CASE
38
Nekatera orodja CASE








POSE (Picture Oriented Software Engineering)
PowerDesigner
Oracle Designer
Rational ROSE
Popkin System Architect
CA Cool
Case Studio
DBDesigner
Integracija CASE in RAD



Rapid Application Development
Microsoft Visual Studio (Enterprise)
IBM VisualAge
Borland Enterprise Studio
39
Mal’ za šalo, mal’ za res
alias ‘Življenje nekega programa’
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Programer je napisal in oddal program, za katerega verjame, da je brez napak.
Program je testiran, najdenih 20 napak.
Programer popravi 10 napak in pojasni ekipi za testiranje, da preostalih 10 napak niso pravi
‘hrošči’.
Ekipa za testiranje ugotovi, da 5 popravkov ne deluje in odkrije 15 novih hroščev.
Dokler ne ponorijo v prodaji in marketingu, se ponavlja naslednja zgodba:
1.
2.
Preberi točko 3.
Preberi točko 4.
Zaradi pritiska s strani komercialistov in marketinga (najava novega produkta se je zanašala
na veliko preoptimističen terminski načrt projekta), program dajo v uporabo.
Uporabniki najdejo 137 novih hroščev.
Originalnega programerja (po tem ko je dobil plačilo za svojo ‘umetnijo’) ni nikjer.
Na novo zbrana programerska ekipa odpravi skoraj vseh 137 hroščev, vendar najde 468
novih.
Originalni programer pošlje (slabo plačani) ekipi za testiranje kartici iz Dominikanske
Republike in Jamajke. Celotna ekipa za testiranje da odpoved.
S strani konkurenčen firme pride do sovražnega prevzema podjetja. Novi lastniki poberejo
ves profit od zadnje verzije programa, ki je imela 783 hroščev.
Novi CIO pride v nadzorni odbor. Najame programerja, ki naj ponovno naredi (zlepi) program
iz ostankov starega.
Programer napiše in odda program, za katerega verjame, da je brez napak.
Vrni se na točko 2.
40