1.

Uvod

Trenutno stanje (ZDA l. 2000):  Nekatere organizacije so do 10x boljše od drugih  Veliko programskih projektov propade  zaradi nepravilnega časovnega plana  zaradi nepravilnih funkcionalnost  zaradi napačnega proračun  preveč napak v fazi produkcije Leta 1995 se je le 16% programskih projektov končalo pravočasno in v časovnih okvirih. Projekti izvedeni

s strani največjih podpirajo le 42% prvotno načrtovanih funkcij. 53% projektov bo stalo približno 190% prvotno predvidenih stroškov. V večjih organizacijah bo samo 9% projektov končanih pravočasno in v okviru proračuna. Povprečen UIS zamuja 1 leto in je 100% dražji.

1

1.1 Razvojna okolja/znanstvena okolja
 Znanstveniki  Spoznavajo resnico  Preverjajo hipoteze  Širijo znanje  Inženirji  Spoznavajo resnico  Odkrivajo uporabnost  Preverjeno znanje uporabljajo za reševanje praktičnih problemov

1.2 Kaj gre ponavadi narobe?
      Napačno postavljene zahteve - 50% Napačno vodeno uvajanje sprememb zahtev - 30% Slaba metodologija razvoja - 25% Nerealni roki - 25% Slabo vodenje projekta - 20% Nezainteresirani uporabniki

1.3 Je to prava pot?
    V ostalih inženirskih disciplinah delajo drugače Zakaj se ravno programsko opremo prevečkrat izdeluje brez načrtovanja? Ali lahko storimo kaj na to temo? Ali obstajajo boljše rešitve?

1.4 Trikotnik uspeha
   Ljudje Procesi Tehnologija  Še vedno je treba misliti in uporabljati zdravo pamet  Vsega se ne moremo naučiti iz knjig. Potrebna je »kilometrina«.  Veliko vrednost lahko doda mentorstvo in svetovanje.

1.5 Evolucija inženirskih pristopov
Gradbeništvo naprimer obstaja že stoletja Naloga: Zgraditi most  Enostavno opisane lastnosti (dolžina, širina, obremenitev) in jasen zaključek (lahko se varno peljemo čez)  Arhitekti (načrtovalci) in gradbeniki se dobro razumejo med seboj  Vsi lahko berejo osnovne dokumente/načrte  Enostavno merjenje napredka; očitni mejniki  Projekt lahko izvajajo kvalificirani podizvajalci

2

Ljudje  certificirani in licencirani strokovnjaki za posamezna področja  Procesi  dodelani koraki za načrtovanje in izdelavo pozivov k ponudbi  preizkušene upravljalske metode  Tehnologija  izpopolnjena analitična in načrtovalska orodja  izpopolnjeni materiali  avtomatizacija upravljalskih mehanizmov  Nenehne izboljšave  učenje na preteklih napakah  zahtevane licence  procesi se izpopolnjujejo  prilagojena infrastruktura  izobraževanje  licenciranje  kodeks etike  zbornice

1.6 Evolucija razvoja programske opreme
 Procesi  Ad hoc  Beseda izvira iz latinščine (~=za ta namen). Označuje rešitev, ki je specifična za neko nalogo ali problem in se je ne da posplošiti oz. uporabiti za druge stvari.  An ad hoc process is one which is improvised or impromptu(made or done without previous preparation)  slapovni/zaporedni  Najstarejši razvojni model, kjer si faze sledijo zaporedno in vračanje nazaj ni mogoče

 

 

+: primeren za kompleksne projekte, če zahteve dobro razumemo in se med projektom ne bodo bistveno spreminjale -: ni fleksibilen; vsaka naknadna sprememba zahteva veliko dodatnega napora. Ni primeren za projekte, pri katerih pričakujemo pogosto spreminjanje in dodajanje zahtev. (ne odraža resničnega razvojnega procesa, ker namreč skoraj nikoli popolnoma ne končamo ene faze in gremo potem na drugo). Čeprav slapovni razvoj omogoča tudi vračanje, to vračanje ni namenjeno iterativnemu izvajanju postopkov, ampak odpravi morebitnih napak oziroma pomanjkljivosti. Druga pomanjkljivost, ki se večkrat (neupravičeno) očita zaporednemu modelu je, da vodi do velikih in kompleksnih monolitskih sistemov, ki jih težko vzdržujemo. Slapovni zato, saj razvoj poteka iz ene faze v drugo, podobno kot se voda pretaka iz višjega na nižji nivo (glej sliko).

3

spiralni / iterativni  Razvit kot odziv na pomanjkljivosti slapovnega pristopa  Pri iterativnem pristopu izvajamo korake slapovnega pristopa v več iteracijah.  V vsaki iteraciji razvijemo določen del funkcionalnosti celotnega sistema. (torej faze končamo le delno)  V začetnih iteracijah razvijemo najbolj tvegane dele sistema.  Sistem se razvija inkrementalno.  Najbolj tvegane so začetne iteracije – najprej razvijemo najbolj tvegan del sistema  Vsaka iteracija vključuje povezovanje v celoten sistem in preizkušanje

+: Najbolj tvegani deli so razrešeni še preden postane investicija velika, možna je predaja izvedenega dela projekta še preden je dokončan celoten projekt, začetne iteracije omogočijo zgodnje povratne informacije s strani uporabnikov...  -: Ne omogoča dobrega načrtovanja projekta – ne vemo koliko iteracij bo potrebnih za dokončanje celotnega projekta; vodenje projekta je zahtevno.  S pojavitvijo iterativnih modelov so se prvič pojavili prototipi, ki so iterativnim modelom prinesli dodatne prednosti. inkrementalni/postopni  Vsebuje prvine iterativnega modela  Sistem razbijemo na neodvisne dele (podprobleme)– razvoj posameznega dela pomeni poseben projekt  Aplikacijo tako razvijamo po delih, ki zajemajo le določen del funkcionalnosti želenega sistema, vendar so obenem dovolj samostojni, da jih lahko vključimo v produkcijo.  Iteracija iz iterativnega modela označuje sklop opravil znotraj projekta, inkrement iz inkrementalnega modela pa zaključuje sklop sistema  +: dele končnega produkta že relativno zgodaj predamo v uporabo, kar poveča možnost za odkrivanje in odpravljanje morebitnih napak in pomanjkljivosti; razvoj IS 
po inkrementalnem modelu v splošnem cenejši in manj tvegan, kot razvoj aplikacije v enem kosu -: Ni primeren v vseh primerih (npr.: ni za pričakovati, da bi sistem za kontrolo zračnega prometa lahko v praksi deloval, dokler ne bi bil v celoti dokončan)

4

prototipni model  Pojavi se z iterativnim modelom.  Temelji na izdelavi prototipov (predhodno izdelane in ponavadi nepopolne verzije sistema)  Prototipni modeli v veliki meri olajša komuniciranje z uporabnikom  Izdelava prototipov kot tehnika razvoja aplikacij temelji na tesnem sodelovanju med uporabnikom in analitikom.  Prototipi se navadno uporabljajo le kot del specifikacije sistema, za pridobitev jasnejše podobe bodočega sistema in se v nadaljevanju zavržejo.  Prototipni modeli so kot osnova za izdelavo produkcijskega sistema (RAD)  Uporablaja se kot del specifikacije sistema, za pridobitev jasnejše podobe bodočega sistema in se v nadaljevanju zavržejo.

5

RAD/JAD  Rapid Application Development (RAD) je inkrementalni razvoj programske opreme, ki daje poudarek na zelo kratkem razvojnem ciklu (tipično 60-90 dni)  Uporablja minimalno planiranja (s tem je omogočen tudi hiter razvoj) in je tako bolj enostaven za spreminjanje zahtev.  Sestavljen je iz štirih faz: 1. Requirements Planning  Uporabniki, managerji in IT-jevci diskutirajo glede na poslovne potrebe, omejitve, potrebe po sistemskih zmogljivostih,...Ko je vse to določeno se lahko nadaljuje 2. User Design  Uporabniki sodelujejo s sistemskimi analitiki in skupaj naredijo model, ki vsebuje vse procese, vhode ter izhode. RAD skupina ali podskupina ponavadi uporablja kombinacijo JAD tehnik (Joint Application Development) in CASE orodij (Computer Aided Software Engineering)  To je kontinuirana faza, v kateri se spreminja, razume in na koncu odobri sam model. 3. Construction  Faza v kateri se razvija program – v tej fazi še vedno sodelujejo uporabniki, ki priporočajo razne spremembe in izboljšave. Sem spada samo kodiranje, razvoj, integracija, testiranje. 4. Cutover  Kočnanje projekta, vključuje testiranje, učenje uporabnikov uporabe programa.

Lahko je sestavljen tudi na drugačen način in sicer iz faz Business Modeling, Data Modeling, Process Modeling, Application Generation, Testing and Turn over.

6

Extreme programming  Namenjena je izboljšanju kvalitete programske opreme. Vsebuje t.i. »izdaje« programov v kratkih ciklih, s katerimi se preverja ali je še kaj za spremeniti in preverja če je vse v redu.

Feature driven  Je iterativen in inkrementalen proces in je del Agilnih postopkov za razvoj programske opreme.  Sestavljen je iz petih osnovnih opravil in je tudi skupek najboljših praks (Best practices) izpeljanih iz programskega razvoja. Unified process  Je iterativen in inkrementalen proces.  Najbolj znan in najbolje dokumentiran izmed unified process je RUP (Rational Unified Process).  To ni samo proces ampak prej razširljiv framework, ki je posebej prilagojen za posamezne organizacije ali projekte.

Kombinirani model  Na osnovi zaporednega, vendar ta omogača vračanje v predhodnje faze ter vključuje rabo prototipov. Ta se zelo pogosto uporablja!

7

Ponovna uporaba  Je sposobnost razvoja aplikacij iz že obstoječih sistemov.  Prednosti so nižji stroški bodočega vzdrževanja, hitrejši razvoj, večja kakovost in produktivnost.  Komponente, ki jih pri razvoju lahko ponovno uporabimo, so vsi izdelki, ki nastanejo v katerikoli fazi razvojnega življenjskega cikla.  Tehnologija  jeziki  zbirni, procedualni, strukturirani, objektni  3GL (third generation programming language – Java, C, C++, Basic,...),  4GL (fourth generation programming language – Mathematica, SQL, ColdFusion,...),  CASE (Computer Aided Software Engineering - primer?)  Orodja podpore življenskemu ciklu  zajem zahtev, načrtovanje, izvedba, testiranje  nadzor nad konfiguracijami/verzijami  modeliranje  strukturirano, DFD (Data Flow Diagram)  Coad, OMT(Object Modeling Technique)  UML (Unified Modeling Language)  Še vedno se soočamo z istimi problemi kot pred 25 leti  slabo zastavljene zahteve  napeti roki  hitro se spreminjajoča tehnologija  hitro spreminjajoče potrebe  na veliko zastavljeni projekti  Izboljšave se počasi uveljavljajo

1.7 Razlike med izdelavo programske opreme in opredmetenih izdelkov
   programska oprema je resnično mehka/neopredmetena programsko opremo je navidezno lažje spreminjati uporabniki zahtevajo v programih večjo prilagodljivost  prilagajanje pa stane  niso še doseženi standardi industrijske proizvodnje  ni veliko “komponent”, ki bi omogočale izgradnjo kompleksnejših sistemov  komponenete niso razširjene (razen uporabniških vmesnikov)  modeli niso sprejeti kot načrti  ni še skladišč komponent

1.8 Osnovna dejstva
 Programska oprema je danes zelo kompleksna  posameznik jo težko obvladuje v celoti  težko jo je opisati v vsem razumljivi obliki  Komercialne zahteve povečujejo pritisk  krajšanje izdelavnih ciklov  povečana tekmovalnost  neskončna rast želja uporabnikov  Pomanjkanje ustreznih kadrov vodi k neuspehu  kljub najboljšim procesom in orodjem  vodenje ljudi je izredno zahtevno

8

  

velike spremembe so organizacijsko zahtevne ponovna uporaba starih izdelkov je redka Porazdelitev napak v ZDA v % Zahteve  Načrtovanje Kodiranje Dokumentacija Popravki 30 25 30 5 10

1.9 Odnosi
Večina napak se pojavi v fazi zajema zahtev in načrtovanja. Taka porazdelitev napak ni značilna ostala ameriška podjetja. Zato je potrebno izpolniti zajem zahtev z:  vključitvijo zahtev v načrte programov,  sprotnim testiranjem,  z objavljanjem sprotnih oprijemljivih delovnih rezultatov,  z obvladujem neizogibnih sprememb. Še vedno pa ostaja osredotočenost na stranke!

1.10 Inžinirski pristop pri razvoju programske opreme
Aplikacije morajo biti zasnovane in načrtovane, ne samo “izdelane”. Inženirji drugih panog uporabljajo:  procese, orodja, standarde,  visoko izobražene, izurjene, potrjene kadre ter  uporabljajo koncept sistemske integracije. Lastnosti uspešnih projektov:  iterativni proces,  spoštovanje zahtev,  nenehna integracija, uporaba metrik inzagotavljanja kakovosti,  delo s pogostimi, oprijemljivimi rezultati ter  skupinsko delo in podpora.

9

2. Strukturne tehnike
Če bi stavbe izdelovali kot programe pišejo programerji, bi prvi detel sesul civilizacijo. (G. Weinberg)

2.1 Ključni cilji strukturnih tehnik
Ključni cilji strukturnih tehnik so:  izdelava visoko kvalitetnih programov s predvidljivim delovanjem,  izdelava za vzdrževanje enostavnih programov,  poenostavitev programov in njihovega razvojnega procesa,  več predvidljivosti in sledljivosti v razvojnem procesu ter  pohitritev in pocenitev razvoja.

Strukturne tehnike nam omogočajo:  prijaznost do uporabnika,  neposredno uporabo z generatorji kode,  najvišjo možno stopnjo rigoroznosti ter  podatkovno usmerjenost. Nove metode večinoma zahtevajo računalniško podporo za učinkovito uporabo.

10

Tehnični cilji strukturnih tehnik so:  členitev kompleksnih problemov in gradnikov v obvladljive probleme,  enostavnost načrtovanja,  obvladovanje kompleksnosti,  uporaba razumljivih diagramskih tehnik,  izboljšati čitljivost diagramov in kode,  izboljšanje komunikacije s končnimi uporabniki,  enotnost arhitekture,  skladnost metod,  sestaviti standardno množico krmilnih struktur, ki jih je najenostavneje pretvoriti v kodo,  učinkovita komunikacija med člani razvojne skupine,  zmanjšanje števila načrtovalcev (najboljše podskupine imajo enega člana),  uporaba tehnik, ki delujejo tako nad majhnimi, kot nad velikimi programi,  zmanjšanje pomena storjenih napak,  prestrezanje napak v čim zgodnejši fazi,  rigorozni vmesniki med neodvisno razvitimi moduli,  močno skrbništvo nad podatki,  zagotoviti programerjem in analitikom učinkovita orodja za doseganje teh ciljev ter  maximalna avtomatizacije načrtovanja programske opreme s tehnikami, ki omogočajo samodejno generiranje kode. Pomembne lastnosti strukturnih tehnik so:  Tehnika je načrtovana kot uporabnikom prijazna (user-friendly),  Tehnike so načrtovane za takojšnjo uporabo 4G jezikov in kodnih generatorjev,  Tehnike morajo biti načrtovane čimbolj rigorozno,  Drugačne, precej zmogljivejše metode so uporabne šele z avtomatiziranimi orodji ter  Tehnike naj bodo načrtovane za uporabo z avtomatiziranimi načrtovalskimi orodji.

2.2 Strategije reševanja problemov
Osnovne strategije reševanja problemov so abstrakcija, formalizacija, deli in vladaj ter hierarhična ureditev.

2.2.1 Abstrakcija
Predstavlja posplošitev in poenostavitev. Abstrakcija je model realnosti. Je poenostavitev dejstev in nam omogoča predstavitev problema brez obremenjevanja z odvečnimi podrobnostmi – skladno z ravnjo in namenom obravnave. Z abstrakcijo lahko pogledamo na problem na različnih ravneh. Na nižjih so podrobnosti, medtem ko na najvišjem zajamemo celoto.

11

2.2.2 Formalizacija
Formalizacija zahteva rigorozen metodološki pristop. Formalizacija je premik od »umetniškega« programiranja k inženirskemu delu (pravila, sistematizacija, nadzor).

2.2.3 Deli in vladaj (Divide and Conquer)
Deli in vladaj je koncept reševanja težkih problemov z njihovim razbitjem na množico manjših neodvisnih problemov, ki so lažje obvladljivi. Je osnovno orodje za obvladovanje kompleksnosti. Osnovni programski konstrukt je modul, ki se lahko razvija in testira neodvisno od ostalih.

2.2.4 Hierarhična ureditev (Hierarchial Ordering)
V nasprotju z deli in vladaj, kjer je pomembna samo delitev, je za razumevanje pomembna še ureditev problema. Program lahko gradimo po nivojih, kjer v vsakem nivoju dodamo podrobnosti. Stukturirani programi so hierarhično urejeni, medtem ko so nestrukturirani urejeni samo sekvenčno. Strukturiranost precej olajša spreminjanje programov.

2.3 Temeljni principi razvoja programske opreme
Temeljni principi razvoja programske opreme (Software Engineering) so prikrivajne/ograjevanje, lokalizacija, skladnost zasnove ter celovitost.

2.3.1 Prikrivanje/ograjevanje
Ta princip je pomemben za izvedbo funkcionalne dekompozicije. Zaradi nadzora kompleksnosti mora biti sistem modulariziran. Vmesniki med moduli morajo biti čim enostavnejši. Izven modula so vidne samo informacije, ki so potrebne za interakcijo z ostalimi moduli, kar olajša razumevanje.

2.3.2 Lokalizacija
?

2.3.3 Skladnost zasnove
Z abstrakcijo in hierarhično ureditvijo skladnost zasnove olajša obvladovanje kompleksnosti. Je pomen enotnega razvojnega načrta, ki se ga držimo pri gradnji vseh komponent. Rezultat je enotna arhitektura, ki pa je najpomembnejša za razumevanje.

2.3.4 Celovitost
Pomeni, da je vse je vključeno in nič izpuščeno. Predstavlja pozornost, da kompleksen sistem ustreza vsem zahtevam. Daje pomen ne samo preverjanju podatkov in funkcij, ampak tudi pravilnosti in robustnosti.

2.4 Temeljni principi informacijskega inženiringa
Temeljni principi informacijskega inženiringa so:  podatkovna analiza (Data Analysis),  podatkovna neodvisnost (Data Independence),  strateško podatkovno planiranje (Strategic Data Planning) ter  prijazen dostop uporabnikov do podatkovne baze (End-User Access);.

12

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.