Skoči na: navigacija, iskanje

Vsebina 1 Osnove 2 Poslovne aplikacije 2.1 E-poslovanje 2.2 Več-funkcijski poslovni sistem 2.3 Poslovno informacijska arhitektura 2.4 Funkcionalni informacijski podsistmi 2.4.1 Prodajni podistem 2.4.2 Proizvodni podsistem 2.4.3 Kadrovski podsistem 2.4.4 Računovodski podsistem 2.4.5 Finančni podsistem 2.5 CRM - upravljanje odnosov s strankami 2.6 ERP - integriran IS 3 Osnove razvoja informacijskih sistemov 3.1 Osnovni pojmi 3.2 Življenski modeli razvoja IS 3.2.1 Zaporedni oz. slapovni model 3.2.2 Iterativni model 3.2.3 Prototipni model 3.2.4 Inkrementalni model 3.3 Metodologije razvoja IS 3.3.1 Metodologija kot sociološka komponenta 3.3.2 Formalizacija metodologij 3.3.3 Vrste metodologij 3.3.4 Pojem agilnosti 3.3.5 Izbira metodologije 4 Strukturni razvoj 4.1 Osnovne značilnosti strukturnega razvoja 4.2 Primer strukturne metodologije: Informacijski inžiniring 4.3 Strateško načrtovanje 4.3.1 Strateški plan razvoja informatike 4.3.2 Razvoj po strukturnem pristopu 4.3.2.1 Zajem in specifikacija zahtev 4.3.2.1.1 Zajem zahtev 4.3.2.1.2 Ureditev zahtev 4.3.2.1.3 Potrditev zahtev 4.4 Analiza 4.4.1 Izdelava modela sistema 4.4.1.1 Podatkovni model 4.4.1.1.1 Identifikacija odvečnih povezav 4.4.1.1.2 Preverjanje transakcij 4.4.1.2 Procesni model 4.4.1.2.1 Diagram funkcionalne ragradnje 4.4.1.2.2 Diagram podatkovnih tokov (DFD) 4.4.1.2.3 Procesni diagram 4.4.1.2.4 Model procesne logike 4.4.2 Izdelava prototipov 4.4.3 Izdelava predloga arhitekture sistema 4.4.4 Opredelitev strategije testiranja 4.4.5 Predstavitev rezultatov analize naročniku 4.5 Načrtovanje 4.5.1 Izdelava načrta PB 4.5.1.1 Relacijski model 4.5.2 Izdelava načrta programskih modulov 4.5.3 Izdelava načrta dokumentacije 4.5.4 Izdelava načrta testiranja 4.5.5 Izdelava načrta namestitve in uvedbe 4.5.6 Predstavitev načrta naročniku 4.6 Izvedba 4.7 Testiranje 4.7.1 Test programskih enot 4.7.2 Test integracije 4.7.3 Test sistema 4.7.4 Test sprejemljivosti 4.8 Uvajanje 4.8.1 Namestitev IR 4.8.2 Dodelitev pravic za delo z IR 4.8.3 Prevedba podatkov 4.8.4 Izvedba potrditvenega testa IR 4.8.5 Izvedba končnega testa IR 4.8.6 Uvajanje uporabnikov in skrbnikov za delo z IR 4.8.7 Prehod na novi sistem 4.8.7.1 Fazni pristop 4.8.7.2 Zamenjva ali vse naenkrat 4.8.7.3 Vzporedno delovanje 5 Objektni razvoj 5.1 Osnovni principi objektne usmerjenosti 5.2 Osnove modelirnega jezika UML in procesa RUP 5.3 Objektna analiza in načrtovanje 6 Načrtovanje podatkovnih baz 6.1 Tri-nivojsko načrtovanje 6.2 Konceptualno načrtovanje 6.3 Osnove relacijskega modela in logično načrtovanje 6.4 Normalizacija 7 Izpiti

Osnove

• Informacijski sistem
• Podatek in informacija

Poslovne aplikacije

E-poslovanje

• E-poslovanje: S terminom označujemo uporabo informacijskih tehnlogoj in omrežij (internet, intranet, ekstranet, ...) za podporo elektronskemu trgovanju, podjetniškemu komuniciranju in sodelovanju ter spletnim poslovnim procesom.

• E-poslovanje se lahko izvaja:
  • med podjetji (B2B)
  • med podjetjem in partnerji
  • med podjetjem in strankami (B2C)

Več-funkcijski poslovni sistem

• Presegajo meje tradicionalnih poslovnih funkcij in se odpirajo navzven
• Stranke, dobavitelji, partnerji in zaposleni postajajo pomemben člen poslovnih procesov
• Prenova in izboljšanje ključnih poslovnih procesov

Poslovno informacijska arhitektura

• ERP - integriran poslovni informacijski sistem
  • zagotoviti učinkovite interne poslovne procese na področju proizvodnje, distribucije in financ
• CRM - Upravljanje odnosov s strankami
  • Pridobiti in zadržati dobičkonosne stranke
  • trženje, prodaja, podpora
• PRM - upravljanje odnosov s partnerji
  • pridobiti in zadržati partnerje, ki lahko povečajo prodajo in distribucijo izdelkov ali storitev podjetja
• SCM - upravljanje oskrbovalne verige
  • razviti učinkovite procese iskanja virov in nabave izdelkov ter storitev potrebnih za poslovanje
• KM - upravljanje z znanjem
  • zaposlenim zagotoviti ustrezna odločitvena orodja in orodja, ki podpirajo skupinsko delo

• povezava med njimi

              Dobavitelji
                  |
                 SCN
                  |
Zaposleni - KM - ERP - PRM - Partnerji
                  |
                 CRM
                  |
               Stranke

Funkcionalni informacijski podsistmi

• S pojmom sistem za upravljanje s poslovnimi funkcijami označujemo nabor aplikativnih sistemov, ki v podjetju podpirajo:
  • finančno
  • računovodsko
  • prodajno
  • proizvodno in
  • kadrovsko PF

Prodajni podistem

• Prodajni podsistem je odgovoren za načrtovanje, nadzor in obdelavo transakcij povezanih s prodajno funkcijo (upravljanje, prodaje, oglaševanja, promocije, ...)
• Prodajni podsistem:
  • Interaktivna prodaja
  • Avtomatizacija procesa prodaje
  • Tržne raziskave in napovedi
  • Oglaševanje in propaganda
  • Vodenje izdelkov
  • Obvladovanje odnosov s strankami
  • Vodenje prodaje

Proizvodni podsistem

• Proizvodni podsistem skrbi za načrtovanje, nadzor in izvajanje proizvodnega procesa.
• Osnovni koncepti:
  • CIM - računalniško podprta proizvodnja
  • CAM - računalniško podprto krmiljenje strojev in naprav
  • CAPP - računalniško podprta izdelava tehnoloških postopkov
  • CAD - računalniško podprto konstruiranje

Kadrovski podsistem

• Kadrovski podsistem podpira procese namenjene upravljanju s kadri oziroma zaposlenimi.
• Kadrovski podsistem:
  • Pridobivanje kadrov
  • Izbiranje in zaposlovanje novih kadrov
  • razporeditev na delovna mesta in ocena uspešnosti
  • usposabljanje
  • načrtovanje kariere

Računovodski podsistem

• Računovodski sistem podpira:
  • evidentiranje in izdelavo poročil o poslovnih transakcijah
  • sledenje toku sredstev skozi podjetje
  • izdelavo finančnih poročil

• Računovodski podsistem zagotavlja informacije potrebne za načrtovanje in vodenje poslovnih dejavnosti
• Temeljni računovodski aplikativni sistemi:
  • Obdelava naročil: zajem in obdelava naročil strank, priprava podatkov za AS za obvladovanje zalog in za terjatve
  • Plače: evidenca dela zaposlenih in podatkov o nadomestilih, priprava izplačil plač ter dokumentov in poročil plačilne liste
  • Glavna knjiga: združevaje podatkov iz drugih računovodskih sistemov, priprava periodičnih izkazov stanja in poslovnih poročil
  • Terjatve: evidenca zneskov dolga strank, priprava faktur, mesečnih izkazov in poročil o vodenju kreditov
  • Obveznosti iz poslovanja: evidenca nakupov, dolgov in izvedenih plačil dobaviteljem, priprava poročil o upravljanju z denarnimi sredstvi
  • Obvladovanje zalog: obdelava podatkov o stanju zalog: priprava podatkov za za dostavo in ponovna naročila

Finančni podsistem

• Finančni sistem podpira:
  • upravljanje s financami poslovnega sistema
  • razporejanje in nadzor finančnih virov

• Upravljanje s finančnimi viri obsega:
  • upravljanje z denarnimi sredstvi in vrednostnimi papirji
  • Načrtovanje proračunskih sredstev
  • finančno napovedovanje
  • finančno planiranje

• Finančni podsistem:
  • Upravljanje z denarnimi sredstvi
  • Upravljanje z investicijami
  • Načrtovanje naložb
  • Finančno planiranje

CRM - upravljanje odnosov s strankami

• CRM je poslovni aplikativni sistem, ki je v celoti osredotočen na stranko
• CRM združuje avtomatizacijo procesov prodaje, neposredno trženje, upravljanje z računi, upravaljanje z naročili in podporo stankam
• Primarna cilja CRM:
  • podjetju oz. zaposlenim zgotoviti enoten in celovit pogled nad vsemi podatki o strankah
  • strankam omogočiti enoten in celovit pogled na podjetje

• Temeljni sklopi CRM:
  • Upravljanje s stiki in računi: zajem in sledenje vseh stikov stranke s podjetjem
  • Prodaja: prodajnemu osebju zagotavlja potrebna programska orodja za učinkovito prodajo izdelkov, zagotavlja hiter dostop do podatkov o strankah
  • Trženje in izpolnitev: omogoča pripravo in izvedbo oglaševalskih akcij, analizo odzivov vanje, zagotavlja hiter odziv na zahteve strank
• Podpora
  • podpornemu osebju zagotavlja programska orodja in podatke za učinkovito izvajanje podpornih aktivnosti
• Zadržanje in zvestoba
  • Omogoča identifikacijo in nagrajevanje najzvestejših in najdobičkonosnejših strank

• Prednosti CRM:
  • Omogoča identifikaicijo naboljših strank
  • Omogoča prilagajanje in personifikacijo produktov in storitev skladno z zahtevami, željami in navadami strank
  • Stranki omogoča enako izkušnjo neodvisno od mesta oz. načina dostopa (neposredno v prodajalni, prek spleta, telefona, ...)

• Pasti CRM:
  • Ne zagotavlja uspeha: 50% CRM projektov ne izpolni začetnih pričakovanj, 20% implementacij je škodovalo odnosu z obstoječimi dolgoletnimi strankami
  • glavna razloga za neuspeh: pomanjkanje razumevanja, nezadostna priprava

• Trendi CRM:
  • sodelovalni CRM: poenostavlja načine interakcije in sodelovanja s strankami, dobavitelji in partnerji
  • CRM portal: vsem uporabnikom omogoča dostop do potrebnih orodij in informacij, glede na njihove vloge in zahteve

ERP - integriran IS

• Integrirana več funkcijska programska oprema, ki s prenovo proizvodnih, distribucijskih, finančnih, kadrovskih in drugih poslovnih procesov omogoča večjo učinkovitost, prilagodljivost in donosnost podjetja.

• ERP je tehnološka hrbtenica e-poslovanja.

• Temeljni sklopi ERP:
  • Načrtovanje proizvodnje
  • Integrirana logistika
  • Računovodstvo in finance
  • Kadri
  • Prodaja, distribucija in upravljanje z naročili

• Temeljni sklopi ERP so v interakciji z zaposlenimi in strankami

• Prednosti ERP:
  • Kakovost in učinkovitost: služi za izboljšanje internih procesov, izboljšanje kvalitete in učinkovitosti proizvodnje, distribucije in strežbe strank
  • Zmanjšanje stroškov: opazno zmanjšanje na področju obdelave transakcij in IT podpore
  • Podpora pri odločanju: zagotavlja hiter in agregiran dostop do ključnih informacij o stanju in uspehu podjetja - vodstvu omogoči sprejemanje pravih in pravočasnih odločitev
  • Poslovna agilnost: podre ločnice med poslovnimi procesi, informacijskimi sistemi in viri informacij; z ERP se vzpostavi učinkovita in prilagodljiva organizacijska struktura

• Trendi ERP
  • podcenjevanje kompleksnosti razvoja in načrtovanja ERP sistema s strani vodstva in IT strokovnjakov
  • zapostavljanje ključnih uporabnikov v procesu načrtovanja in razvoja
  • neustrezen obseg usposabljanja

• Prilagodljiv ERP -> Spletni ERP -> Medorganizacijski ERP -> Celovito elektronsko poslovanje

Osnove razvoja informacijskih sistemov

Osnovni pojmi

• v okviru razvoja IS nas zanima, kako razviti računalniške rešitve, ki bodo čim bolje podprle delovanje IS
• V okviru razvoja IS se ukvarjamo z:
  • Razvojem računalniške rešitve
  • Nabavo ustrezne strojne opreme
  • Namestitvijo sistemske programske opreme
  • Uvedbo rešitve
  • Vzdrževanjem rešitve

• Pri razvoju IS imajo velik pomen sociološki dejavniki
  • Kako dojemamo problematiko?
  • Kako razumemo potrebe uporabnikov?
  • Kako uvedemo rešitve v prakso?

• Nekatere vrste IS zahtevajo specifične pristope
  • ekspertni sistemi
  • odločitveni sistemi
  • sistemi za podporo delovnim procesom

• V okviru razvoja IS nastanejo tudi računalniški programi

Življenski modeli razvoja IS

• Faze razvoja IS:
  • Analiza
  • Načrtovanje
  • Implementacija
  • Testiranje
  • Uvedba
  • Vzdrževanje

• Življenski model razvoja IS (SDLC) pove, v kakšnem soseledju in na kakšen način si v okviru razvoja IS sledijo posamezne faze.

• Poznamo različne življenske modele
  • Zaporedni ali slapovni model
  • Iterativni model
  • Prototipni model
  • Inkrementalni model

• V praksi se večinoma uporablja kombinacija različnih modelov

Zaporedni oz. slapovni model

• Zaporedno izvajanje faz
• Ko se ena faza zaključi, se lahko začne druga

• Značilnoisti:
  • Najstarejši razvojni model, značilen za prve oblike strukturnega pristopa
  • Faze si sledijo zaporedno
  • Vračanje nazaj ni mogoče
  • Primeren za relativno kompleksne projekte, če zahteve dobro razumemo in če se med projektom ne bodo bistveno spreminjale
  • Omogoča dobro in natančno projektno vodenje

• Prednosti:
  • Pomaga zmanjševati količino režijskega dela, ki ni v neposredni povezavi z izdelavo programske opreme, saj je mogoče načrtovanje v celoti izvesti vnaprej.
• Slabosti:
  • Ni fleksibilen
  • Nenaraven - težko pričakujemo da se nek postopek v celoti zaključi, ko se začne drugi
  • Ne omogoča paralelnega izvajanja delov postopkov

• Zaradi kritik se pojavijo modificirane različice
• Odprava nekaterih pomanjkljivosti:
  • bolj enostavno prehajanje med postopki
  • paralelno izvajanje

• Nudi zelo dobro oporo sistematičnemu razvoju
• Možno ga je uporabiti v kombinaciji z drugimi modeli.

Iterativni model

• Razvit kot odziv na pomanjkljivosti slapovnega pristopa.
• Faze razvoja izvajamo v več iteracijah
• V vsaki iteraciji razvijemo določen del funkcionalnosti celotnega sistema
• Iteracija gre navadno čez vse faze razvoja
• V začetnih iteracijah razvijemo najbolj tvegane dele sistema
• Gre za evolucijski razvoj

• Lastnosti:
  • Tipično trajanje iteracije je 7-14 dni
  • Vsaka iteracija gre čez vse faze
  • Naslednja iteracija se lahko začne šele ko je prejšnja končana
  • Vsebina naslednje je določena na podlagi rezultatov prejšnje
  • Med izvajanjem iteracije ne sprejemamo sprememb

• Prednosti:
  • Najbolj tvegani deli so razrešeni še preden postane investicija velika
  • Začetne iteracije omogočajo zgodnje povratne informacije s strani uporabnikov
  • Preizkušanje in povezovanje v sistem sta nepretrgana
  • Ciljni mejniki omogočajo kratkoročno osredotočenje
  • Napredek merimo z ocenjevanjem izvedenega dela
  • Možna je predaja izvedenega dela projekta še preden je dokončan celoten projekt

• Slabosti:
  • Ne omogoča dobrega načrtovanja poteka projekta
  • ni mogoče predvideti koliko iteracij bo potrebnih za razvoj dokončnega izdelka
  • vodenje projekta je zahtevno

Prototipni model

• Gre za različico iterativnega modela
• Temelji na izdelavi prototipov in njihovi postopni izboljšavi, dokler ne dosežemo zadovoljive kakovosti.

Inkrementalni model

• Temelji na postopni izdelavi rešitve in sprotni predaji posameznih inkrementov naročniku
• Ne izdelujemo celotne rešitve hkrati. Omejimo se na posamezen sklop, ki ga razvijemo v celoti in predmo uporabniku.
• Ob predaji nov sklop povežemo z ostalimi
• Inkremente je moč razvijati vzporedno
• Rezultat je rešitev, sestavljena iz integriranih sklopov
• Potrebno je določiti ustrezen razpored razvoja sklopov
• Zaporedje lahko doličimo glede na več kriterijev (pomembnost, tveganje, ...)

• Razporejanje glede na pomembnost
  • najprej razvijemo sklope z najpomembnejšo funkcionalnostjo. Na tak način funkcionalnost postopno nadgrajujemo
  • Lahko uporabimo MOSCOW analizo, kjer funkcionalnosti rešitve razdelimo na:
    • funkcije, ki jih je nujno implementirati
    • funkcije, ki bi jih bilo dobro implementirati
    • funkcije, ki bi jih lahko implementirali
    • funkcije, ki jih ne bomo implementirali

• Razporejanje glede na tveganost
  • Najprej razvijemo najbolj tvegane dele, da tveganost celotnega projekta čim prej zmanjšamo

• Prednosti:
  • Uporabnik prej dobi del zahtevane rešitve, saj se rešitev razvija po delih
  • Rešitev, ki se uporablja, se postopoma nadgrajuje, uporabnik pa lahko sodeluje pri testiranju razvitih sklopov
  • Naročnik lažje sledi napredovanju projekta

• Slabosti:
  • ni mogoče uporabiti pri vseh projektih, saj nekaterih rešitev ni možno predajati po delih
  • Rešitev moramo razdeliti na sklope in predviditi odvisnosti med njimi. Pri neustreznem načrtovanju se lahko zgodi, da sklope neustrezno razporedimo.

• Poseben primer je, ko inkrementi predstavljajo samostojne projekte
• Inkrementalni model je možno učinkovito uporabiti v kombinaciji z iterativnim modelom (vsak inkrement se izvaja iterativno)

Metodologije razvoja IS

• Nekaj definicij
  • Metodologija je priporočena zbirka filozofij, faz, postopkov, pravil, tehnik, orodij, dokumentacije, upravljanja in izobraževanja za razvijalce IS.
  • Metodologija razvoja IS je priporočen način razvoja IS, ki temelji na filozofiji in množici principov.
  • Metodologija je množica dogovorov, s katerimi se projektna skupina/organizacija strinja.
  • Metodologija je vse kar redno delamo, da bi dosegli končni rezultat - delujoča PO pri končnem uporabniku.

• Zgodovina metodologij
  • Obdobje pred pojavom metodologij - pred 1970: ni formalnih metodologij, ključna vloga je programer
  • Zgodnje obdobje metodologij - do 1980: SDLC, največ poudarka je na zajemu zahtev, analizi in načrtovanju
  • Obdobje metodologij - do konca 1990: iterativni in inkrementalni razvoj, RAD, objektna usmerjenost, strateško načrtovanje, večanje teže metodologij
  • Obdobje ponovne ocenitve metodologij - danes: kritika težkih metodologij, lahme metodologije, spletne aplikacije, nove tehnologije, hitro spreminjanje zahtev, trend agilnosti

Metodologija kot sociološka komponenta

• Poleg tehnik in orodij zajema skupek dogovorov, ki v organizaciji oziroma skupini veljajo pri razvoju informacijskih rešitev.
• Je prežeta s filozofijo in miselnostjo organizacije in njenih zaposlenih.
• Je dinamična in odvisna od posameznikov, ki sestavljajo organizacijo.
• Zajema vse kar počnemo, da izdelamo izdelek oziroma opravimo storitev, ki je cilj našega dela.

Formalizacija metodologij

• Metodologije razvoja IS v mnogih podjetjih niso formalizirane
  • Postopki, tehnike, orodja niso dokumentirani
  • razvoj poteka stihijsko

• Posledice:
  • Slabša kakovost izdelka
  • Razvoj je nesledljiv in netransparenten
  • tveganje, da izdelek ne bo pravi
  • težje vzdrževanje, ...

• Komercialne metodologije
  • IE - Oracle CDM
  • SSADM
  • Rational Unified Process
  • STRADIS
  • Agilne metodologije (XP, SCRUM, FDD, ...)

Vrste metodologij

• Več načinov delitve:
  • glede na tip metodologije: Metodologije za hiter razvoj, Objektno usmerjene metodologije, Podatkovno-procesne metodologije, Procesno usmerjene metodologije, Organizacijsko usmerjene metodologije, Metodologije usmerjene v človeka
  • glede na težo metodologije: določena na podlagi obsega in gostote, obseg je določen glede na število različnih elementov, gostoto lahko definiramo kot nivo podrobnosti
  • glede na utežitev metodologije: spredaj utežene (poudarek na analizi in načrtovanju), zadaj utežene (dajejo poudarek kodiranju in testiranju), uravnotežene (kombinacija obeh)
• Delitev nam pomaga pri izbiri ustrezne delitve

Pojem agilnosti

• Začetki leta 2001, ko se srečajo strokovnjaki iz področja lahkih metodologij, formirajo skupno izjavo
• Na osnovi izjave se izpelje več konkretnih priporočil za razvoj PO:
  • Principi agilnih metodologij
  • Načela in priporočila za agilno modeliranje

• Osnovna načela agilnosti
  • Posamezniki in njihova komunikacija so pomembnejši kot sam proces in orodja
  • Delujoča programska oprema je pomembnejša kot popolna dokumentacija
  • Vključevanje uporabnika je pomembnejše kot pogajanje na osnovi pogodb
  • Upoštevanje sprememb je pomembnejše od sledenja planu.

• Najboljši način komuniciranja je neposredna komunikacija
• Nepotrebna teža metodologije je draga
• Večje razvojne skupine potrebujejo težje metodologije
• Višja stopnja formalnosti metodologije je primerna za projekte z višjo stopnjo kritičnosti
• Boljša komunikacija in več povratnih informacij zmanjšuje potrebo po vmesnih izdelkih
• Čim večji so discipliniranost, izkušnje in znanje razvojne skupine, tem manjša je potreba po podrobno definiranem procesu, formalnosti in dokumentaciji.
• Odkloni od načrtovane rešitve nas vodijo k pravi rešitvi.

Izbira metodologije

• Pri izbiri si pomagamo z:
  • Modeli za klasifikacijo metodologij
  • Modeli za klasifikacijo projektov
  • Izbira metodologije glede na podprte postopke in življenski cikel
  • Izbira metodologije na podlagi agilnih principov

• Lahke metodologije uporabimo ko:
  • je glavni cilj razvoj programske rešitve
  • imamo odgovorne, disciplinirane, izkušene in motivirane razvijalce, ki so seznanjeni s posebnimi tehnikami dela
  • stranko, ki razume bistvo lahkih metodologij in je pripravljena sodelovati
  • imamo nepredvidljive in spreminjajoče se zahteve
  • je cilj razvoja relativno majhen sistem z nižjo stopnjo kritičnosti, ki ga je mogoče razviti z majhno razvojno ekipo

• Težke metodologije uporabimo ko:
  • cilj ni le razvoj programskega sistema ampak tudi prenova organizacijskega sistema
  • imamo manj izkušene razvijalce, pri katerih točno določena formalna pravila nadomestijo znanje in izkušnje
  • naročnik zahteva visoko stopnjo formalizma
  • imamo relativno dobro definirane in stabilizirane zahteve
  • je cilj razvoja obsežnejši sistem, z višjo stopnjo kritičnosti, ki zahteva izdelavo ustreznih načrtov in dokumentacije

• Praksa?
  • Empirične raziskave kažejo na nizko uporabo metodologij
  • Razlogi?
    • nizka strukturiranost procesa razvoja
    • neprilagodljivost metodologij
    • zastarelost metodologij
    • sociološka neprimernost
    • neosveščenost uporabnikov

Strukturni razvoj

Osnovne značilnosti strukturnega razvoja

• Eden prvih sistematičnih pristopov k razvoju IS
• Zaporedno izvajanje aktivnosti
• Zgleduje se po standardnih postopkih razvoja tehničnih izdelkov
• Izoblikoval se je konec 60 in v začetku 70 let
  • Razlog: uvedba discipliniranega izvajanja analize in načertovanja
  • Cilj: zmanjšanje stroškov izgradnje in uvajanja IS
• Pristop iz "vrha navzdol"

Primer strukturne metodologije: Informacijski inžiniring

• nastane 1981, avtor James Martin
• uveljavitev v sredini 80. let, uporablja se še danes
• zasnovan na teoretičnih in praktičnih dosežkih iz 80. let
• Značilnosti
  • sloni na povezani množici tehnik za planiranje, analizo, načrtovanje, razvoj in vzdrževanje IS celotne združbe ali vsaj njenih delov
  • Uporablja pristop od vrha navzdol
  • je podatkovno usmerjen
  • podpira avtomatizacijo razvoja
  • uveljavlja strateško planiranje
  • povečuje produktivnost

• predpostavlja da so PS podatkovno usmerjeni, tehnični sistemi pa procesno ali dogodkovno
• 4 faze
  • strateško planiranje
  • analiza
  • načrtovanje
  • izvedba

• posebej obravnava podatke, posebej aktivnosti

Strateško načrtovanje

• po IE je to prva faza razvoja IS
• Strateško planiranje informatike je proces izoblikovanja informacijskega sistema, ki organizaciji omogoča uresničitev njenih ciljev in ji s tem posredno zagotavlja konkurenčno prednost

• Cilji strateškega planiranja so:
  • povezati razvoj IS s poslovno strategijo organizacije
  • izboljšati komunikacijo med vodstvom in informatiki
  • načrtovati pretok informacij in procesov
  • zmanjšati stroške in čas, potreben za razvoj aplikacij
  • predlagati optimalno zaporedje nadaljnih korakov pri planiranju in razvoju IS
  • Pripraviti izhodišča za nadaljne korake informatizacije
  • zagotoviti uporabo standardov za enotne tehnološke rešitve
  • pokazati na organizacijske probleme pri uvajanju informacijske podpore in predlagati optimizacijske rešitve za dosego racionalnejše uporabe informacijske podpore

• Problemi, če gre za investiranje v informatiko na osnovi sprotnih potreb
  • investiranje v sisteme, ki ne podpirajo poslovnih usmeritev
  • sistemi niso integrirani (podvojitev naporov in podatkov)
  • ni sredstva za določanje prioritet projektom, plani se pogosto spreminjajo
  • problemi obvladovanja podatkov: niso dostopni, se neskladni, netočni ali nepravočasni
  • nezadostne infrastrukturne investicije
  • vsi projekti so ovrednosteni le na finančni bazi
  • problemi glede IT investicij povzročajo konflikte med različnimi oddelki znotraj organizacije
  • nerazumevanje med informatiki in uporabniki vodi v konflikte in nezadovoljstvo
  • sistemi imajo večinoma krajšo življensko dobo, pogosteje je potreben ponoven razvoj, kar povzroča večje stroške

• Metodologija - 6 postopkov
  • pregled in analiza obstoječega stanja
  • opredelitev poslovno informacijske arhitekture
  • opredelitev informacijske vizije
  • opredelitev projektov
  • izdelava letnega načrta
  • spremljanje izvajanja in vzdrževanje strateškega plana

Strateški plan razvoja informatike

• izdelava traja od 3 do 6 mesecev
• pri izdelavi sodelujejo
  • zunanji sodelavci
  • metodologi
  • ključni uporabniki
  • člani vodstvene skupine organizacije
• strateški plan je potrebno osveževati

Razvoj po strukturnem pristopu

• temelji na strukturni izvedbi analize in načrtovanja
• podatki se obravnavajo ločeno od aktivnosti in postopkov
• ključen element je podatkovna baza, okoli katere se razvijejo programski moduli
• z uveljavitvijo objektnih programskih jezikov se ukinja
• Danes se uporablja hibridni pristop: temelji na objektni filozofiji, vendar potakovna baza še vedno ohranja ključen pomen

• strukturni pristop zajema več postopkov:
  • zajem in specifikacija zahtev
  • analiza
  • načrtovanje
  • izvedba
  • testiranje
  • uvajanje
  • vzdrževanje

Zajem in specifikacija zahtev

• je ena pomembnejših aktivnosti razvoja oziroma nakupa IR
• osnovni namen je opredeliti želeno IR na način, ki bo omogočal
  • pri nakupu IR izbrati med obstoječimi rešitvami
  • pri razvoju IR opredeliti osnovno funkcionalnost ter tehnološke in druge nefunkcionalne zahteve in omejitve za izgradnjo želene IR
• rezultat je dokument, kjer so zabeležene vse funkcionalne in nefunkcionalne zahteve v zvezi z želeno IR
• v nadaljnih korakih se dokument lahko uporablja:
  • kod vhod v postopek analize
  • pri pripravi razpisne dokumentacije za nakup IR oziroma izbiro zunanjega izvajalca
  • kot priloga k pogodbi med naročnikom in izvajalcem sistema

• Zajem zahtev izvede sistemski analitik ob tesnem sodelovanju s poznavalci problemske domene oziroma ključnimi uporabniki
• Osnovni koraki:

Zajem zahtev

• različne tehnike
  • razgovori
  • vprašalniki
  • opazovanje pri delu
  • analiza obstoječega sistema
  • skupinsko načrtovanje aplikacij

• splošni napotki za uspešno izvedbo zajema zahtev
  • analitik mora biti objektiven
  • analitik mora upoštevati vse možnosti v okviru nekega problema
  • analitik posveča pozornost podrobnostim
  • analitik mora stremeti k novim in boljšim rešitvam
  • analitik ne daje obljub uporabnikom
  • analitik nima zadržkov pri zajemanju zahtev

Ureditev zahtev

• razumevanje želene IR poizkušamo opredeliti še v okviru dokumenta, s katerim bodo zahteve IR podane bolj formalno in jedrnato
• izdelek, ki nastane imenujemo specifikacija zahtev
• specifikacija zahtev lahko služi kot temeljna podlaga pri dogovarjanju med naročnikom in izvajalcem
• Specifikacija zahtev ima navadno naslednjo strukturo:
  1. kratek opis namena IR ali njenega podsistema
  2. opis funkcionalnih zahtev
  3. opis nefunkcionalnih zahetv
  4. opis vmesnikov
  5. slovar izrazov

• Funkcionalne zahteve so zahteve, ki se nanašajo na funkcionalnost sistema.
• Nefunkcionalne zahteve so zahteve, ki se nanašajo na tehnične in druge nevsebinske zahteve sistema

Potrditev zahtev

• Namen je predstavitev specifikacije zahtev naročniku in pridobitev soglasja o tem, da so zajete zahteve res to, kar si naročnik želi.

Analiza

• Namen je je izdelati razumljiv opis realnega sveta oziroma poslovnega okolja na katerega se nanaša razvoj IS
• Izdelamo model sistema, ki na formalen način opredeli potrebne podatkovne strukture in funkcije, ki te strukture uporabljajo.
• Analiza daje odgovor na vprašanje kaj naj IS podpira. Kaj se izvaja v poslovnih funkcijah in kakšne podatke te rabijo?
• Analiza služi kot:
  • sredstvo za definicijo zahtev
  • osnova za dogovor med naročnikom in izvajalcem
  • osnova za kasnejše faze razvoja

• Rezultat analize je model sistema
• Na osnovi modelov se v nadaljnih korakih izdela podatkovna baza ter potrebni programski moduli.
• Poleg modela sistema v fazi analize izdelamo tudi predlog tehnične arhitekture sistema ter opcijsko prototipe komponent uporabniškega vmesnika
• Med izdelke analize sodi tudi strategija testiranja.

• Postopek analize izvajajo sistemski analitik, sistemski arhitekt in ključni uporabniki.
• Postopek analize tipično zajema naslednje aktivnosti:
  • Izdelava modela sistema
  • Izdelava prototipov
  • Izdelava predloga tehnične arhitektutre sistema
  • Opredelitev strategije testiranja
  • Predstavitev rezultatov analize naročniku

Izdelava modela sistema

• Modeliranje je uveljavljena inžinirska tehnika. Modele razvijamo zato, da bi sistem bolje razumeli.
• Model je poenostavitev realnosti, pri čemer je abstrakcija realnosti poljubno natančna.
• Pomembno je, da model prikazuje pomembne elemente in izpušča tiste, ki nas ne zanimajo.
• Prednosti modeliranja:
  • Omogoča vizualizacijo sistema
  • Prikazuje tako statične kot dinamične lastnosti sistema
  • Predstavlja šablono za nadaljno gradnjo sistema
  • Dokumentira sprejete odločitve

• Izbira modelov:
  • Za modeliranje sistema lahko izberemo različne sisteme
  • Izbira modelov določa, kako bomo pristopili k reševanju problema, ter kako oblikovali rešitev.
  • Modeli morajo podpirati izražanje na različnih ravneh natančnosti.
  • Najboljši modeli so tesno povezani z realnostjo
  • En sam model nikoli ni dovolj. Sistem je potrebno modelirati iz različnih vidikov. Najboljši pristop je izbira nekaj modelov, ki kar najbolje prekrijejo najpomembnejše vidike sistema.
  • Metodologije razvoja IS predlagajo različne modele.

• Model, ki ga izdelamo v fazi analize po strukturnem pristopu, se v grobem deli na:
  • Podatkovni model: prikazuje model s podatkovnega vidika tako, da opisuje podatkovne strukture, ki so potrebne za delovanje sistema. Poleg podatkovnih struktur zajema tudi vse povezave med njimi.
  • Procesni model: prikazuje sistem z vidika aktivnosti ali procesov, ki se v sistemu izvajajo. Definirani so tokovi podatkov med procesi.
  • Model procesne logike: natančneje definira procese, definirane v procesnem modelu

• Za predstavitev posameznih modelov sistema uporabljamo formalne, semi-formalne in tudi neformalne tehnike:
  • Podatkovni model: diagram entiteta-razmerje
  • Procesni model: procesni diagram, diagram podatkovnih tokov, funkcionalna razgradnja
  • Model procesne logike: naravni jezik, strukturiran jezik, odločitvene tabele, odločitveni grafi, diagrami prehajanja stanj

Podatkovni model

• je eden izmed najpomembnejših izdelkov faze analizein predstavlja vse podatkovne kategorije, za katere na nekem delovnem področju obstaja potreba, da se o njih podatki spremljajo, obdelujejo in hranijo
• v analizi izdelamo konceptualni podatkovni model
• Za idelavo uporabljamo diagramsko tehniko entiteta-razmerje
• Entitetne tipe je potrebno dokumentirati (v obliki tabele ali česa podobnega)
• Možni koraki konceptualnega načrtovanja
  1. Identificiraj entitetne tipe
  2. Identificiraj povezave
  3. Identificiraj in z entitetnimi tipi poveži atribute
  4. Atributom določi domene
  5. Določi kandidate za ključe; izmed kandidatov izberi primarni ključ
  6. Po potrebi uporabi elemente razširjenega diagrama entiteta-razmerje
  7. Preveri, če v modelu obstajajo odvečni elementi
  8. Preveri, če model "zdrži" transakcije
  9. Preveri model z uporabnikom
• V postopku identifikacije povezav smo pozorni na dvoumne in nepopolne povezave: dvoumne odpravimo z restrukturiranjem sistema, nepopolne pa z prestrukturiranjem

Identifikacija odvečnih povezav

• Povezava je odvečna, če je možno priti do iste informaicje preko drugih povezav
  • izdelati želimo minimalen podatkovni model
  • Zgolj pregledovanje med entitetnimi tipi ne zadošča

Preverjanje transakcij

• Pregledati moramo, če model podpira zahtevane transakcije
• transakcije izvajamo ročno
• Če neke transakcije ne uspemo izvesti, je model pomankljiv (manjkajo bodisi entitetni tip, povezava ali atribut)
• Možna dva pristopa:
  1. preverjanje preko opisa transakcij
     • Vsako transakcijo opišemo
     • Preverimo če model zajema vse entitetne tipe, povezave in atribute, ki jih transakcija potrebuje
  2. preverjanje preko transakcijskih poti
     • Preverimo na modelu - pot transakcije narišemo
     • Pristop načrtovalcu omogoča da:
       • da identificira pomanjkljivost modela
       • da identificira dele modela, ki so za transakcijo kritični
       • da odkrije odvečne dele modela

Procesni model

• Prikazuje sistem iz vidika aktivnosti ali procesov, ki se v sistemu izvajajo. V procesnem modelu lahko nastopajo tudi podatkovne strukture, ki jih procesi potrebujejo pri svojem delovanju.
• Za izdelavo procesnega modela uporabljamo dve diagramski tehniki: diagram razgradnje in diagram podatkovnih tokov. Uporabimo lahko tudi procesni diagram.

Diagram funkcionalne ragradnje

• Z njim prikažemo hierarhijo funkcij, ki jih želimo s sistemom podpreti.
• Hierarhijo funkcij lahko prikažemo na različne načine, najbolj običajno kot navpično hierarhijo.
• Smernice za izdelavo:
  • Število nivojev in število enot na enem nivoju običajno ni omejeno, čeprav velja priporočilo, da naj ima vsak element največ devet podrejenih elementov
  • Za vsako enoto velja, da ima nič, eno ali več podrejenih enot (vej) in da vedno pripada natanko eni nadrejeni enoti na prvem višjem nivoju
  • Enote na istem nivoju razporedimo od leve proti desni po neki sekvenčni karakteristiki, ki jo natančno opišemo in k diagramu dokumentiramo

Diagram podatkovnih tokov (DFD)

• Uporabimo jih za prikaz okolja, v katerem bo sistem deloval, ter za prikaz odvisnosti med procesi, ki jih bo sistem podprl.
• DFD združuje podatkovni in procesni pogled na obravnavano področje
• DFD je uvedel Tom DeMarco leta 1978. Od takrat je nastalo več različic DFD tehnike, ki se razlikujejo predvsem v notaciji.
• Sodi med enostavnejše diagramske tehnike
• Osnovni gradniki so:
  • Proces
  • Tok podatkov
  • Podatkovni skladišče
  • Zunanja entiteta
• Proces predstavlja množico aktivnosti, ki vhodne podatke pretvorijo v izhodne. Je generičen pojem in lahko predstavlja dogajanje na različnih ravneh.
  • Vsakemu procesu je dodeljen naziv in številčna oznaka, ki se v diagramu vpišeta v grafični simbol procesa.
  • Za naziv procesa običajno uporabimo glagol, glagolski samostalnik ali zaporedje besed, ki opisujejo vrsto dejavnosti.
  • Številčna oznaka enolično določa proces
• Tok podatkov predstavlja množico vhodnih ali izhodnih podatkov, ki imajo enolično definirano vsebino in strukturo.
  • Vsakemu toku podatkov določimo naziv, ki pove kaj tok prenaša.
  • Nazivi so samostalniki, običajno v ednini, ali pa kombinacija samostalnika in pridevnika
  • Podatkovni tok se lahko giblje med zunanjimi entitetami in procesi, med dvema procesoma ali med podatkovim skladiščem in procesom.
• Podatkovna shramba predstavlja prostor, kamor procesi shranjujejo podatke za druge procese ali kasnejšo uporabo.
  • Lahko je enostavna ali kompleksna
  • V vsako shrambo mora pisati vsaj en proces
  • Iz shrambe ni možno brati podatkov, ki vanjo niso bili zapisani.
  • Je interna struktura, zato dostop do nje ni dovoljen zunanjim entitetam
  • Ustreza enemu ali več entitetnim tipom iz podatkovnega modela.
• Zunanje entitete predstavljajo zunanje procese ali sisteme
  • Nahajajo se izven interesnega področja analize
  • Ne zanima nas njihova struktura ali obnašanje, temveč le podatkovni tokovi, ki se pretakajo med obravnavanim območjem in nijm
• Pogosto identificiramo večje število procesov
  • predstavitev v enem diagramu je nepregledna
  • Uporabljamo razčlenjevanje. Diagrame rišemo od vrha navzdol: začnemo na vrhnji ravni, kjer nastopajo obsežnejši procesi, nadaljujemo do najnižje ravni, kjer nastopajo zelo podrobni procesi
  • za vsak proces, ki je predstavljen na višji ravni, izdelamo poseben DFD, kjer proces razbijemo na podprocese
• Kontekstni diagram: razčlenjevanje DFD začnemo na najvišji ravni, kjer nastopa en sam proces - korenski proces
  • prikazuje kontekst sistema - sistem v sodelovanju z okoljem
  • ima en sam proces
  • nima podatkovnih shramb
  • podatkovni tokovi med korenskim procesom in zunanjimi entitetami opredeljujejo vmesnike med sistemom in okoljem
• Prvi nivo diagrama podatkovih tokov
  • Prvi nivo razčlenitve kontekstnega diagrama predstavlja DFD na hierarhičnem nivoju 1.
  • prikažemo ga z eno sliko, kjer korenski proces razčlenimo na potrebno število pod-procesov
  • pri razčlenjevanju je potrebno ohraniti vso funkcionalnost - seštevek funkcionalnosti podprocesov je enak funkc. nadrejenega procesa
  • evidentirani procesi morajo biti približno enakovredni oz. uravnoteženi
• Kako podrobno razčlenjujemo DFD?
  • Razčlenjevanje je smiselno do nivoja procesov, pri katerih ugotovimo, da je težko definirati shrambe podatkov, ki povezujejo njihove pod-procese. Na tem nivoju se procesi povezujejo neposredno s podatkovnimi tokovi.
  • Ta pogoj je vedno izpolnjen na nivoju elementarnih procesov, ki jih lahko opišemo z zaporedjem korakov.
  • Za opis procesov na najnižji ravni DFD tehnika ni primerna, ker ne prikazuje zaporedja. Uporablja se druge tehnike, ki so del modeliranja procesne logike.

Procesni diagram

• Uporabimo ga, ko želimo prikazati tok dogodkov ali potek določenega procesa.
• Obstajajo številne tehnike, ki se razlikujejo predvsem po številu gradnikov in notaciji
• ena najpopularnejših tehnik so eEPC diagrami
• Tipični gradniki
  1. dogodek
     • vsaka aktivnost procesa ima praviloma vhodni in izhodni dogodek
     • vhodni dogodek se zgodi ob določenem trenutku, ko je izpolnjen nek pogoj in ima za posledico začetek izvajanja neke aktivnosti
     • ko se aktivnost izvede, lahko rezultat vpliva na izhodni dogodek
     • primeri dogodkov so: prijava zaključena, izpitni rok vnesen, ocena vpisana, prijava zavrnjena
  • aktivnost
  1. • je najmanjša enota poslovnega procesa
     • pomeni zaokroženo celoto procesiranja
     • primeri: razpis ustnega izpita, prijava na izpit, vpis končne ocene, odjava iz izpita
     • lahko poteka v sodelovanju z uporabnikom ali popolnoma avtomatsko
  • krmilni tok
  1. • oz. kontrolni tok v obliki puščice nakazuje zaporedje dogodkov in aktivnosti v modeliranem procesu
     • lahko ga razumemo kot nosilec kontrolnih podatkov in drugih pomembnih podatkov za izvajanje procesa
  • operator
  1. • predstavlja mesto združevanja kontrolnega toka ali združitve iz več kontrolnih tokov v enega
     • lahko razdruži tok v več tokov
     • več tokov se lahko združi v enega (AND, OR, XOR)
  • vloga
  1. • predstavlja subjekt ki aktivnost izvaja oz. je zanjo odgovoren
  • aplikacija
  1. • predstavlja informacijsko rešitev, ki podpira izvajanje neke aktivnosti
  • informacijski objekt
  1. • predstavlja nosilec podatkov, ki bodisi vstopa ali izstopa iz aktivnosti (vhod/izhod)

Model procesne logike

• dopolnjuje procesni model
• osredotoči se na tiste procese, ki v procesnem modelu niso dovolj jasno opisani: zaporednje korakov, kompleksne odločitvene situacije
• model procesne logike izdelamo s pomočjo diagramskih tehnik, kot so: strukturiran jezik, odločitvene tabele, odločitvena drevesa, diagrami prehajanja stanj, ...
• Najpreprostejši način opisa procesne logike je naravni jezik.
• Strukturiran jezik je oblika naravnega jezika:
  • opisi kratki in jedrnati, uporabljamo glagole in samostalnike
  • drugih besednih oblik ne uporabljamo
  • pišemo z zamiki, da poudarimo strukturo posameznih delov jezika

• Odločitvene tabele' in odločitvena drevesa uporabimo pri modeliranju zapletenejše procesne logike
  • primerni, ki nastopa veliko pogojev
  • odločitvena tabela: v zgornjih vrsticah prikazujemo pogoje, ki morajo biti izpolnjeni, v spodnjih pa aktivnosti, ki sledijo (kombinaciji teh dveh pravimo pravilo - en stolpec va tabeli)
  • odločitveno drevo: vozlišča so pogoji, povezave pa vrednosti posameznih pogojev, pot do predzadnjega nivoja predstavlja pravilo, v listih je predstavljen seznam aktivnosti

• z diagramom prehajanja stanj prikažemo stanja, v katerih se lahko nahaja opazovan proces ter odzive oziroma prehajanja med stanji kot odziv na različne dogodke
  • glavni gradniki:
    • stanje: sistem se lahko nahaja v različčnih stanjih, določena so z vrednostmi lastnosti, ki nas v tem okviru zanimajo;
    • dogodek: povzročajo prehajanja med stanji; vpliva na spremembo ene ali več opazovanih lastnosti; pripeti se v določenem trenutku in nima časovne razsežnosti
    • akcija: se lahko zgodijo ob dogodkih; zgodijo se v trenutku

Izdelava prototipov

• je neobvezna, a je učinkovito sredstvo za prikaz izgleda ter osnovne funkcionalnosti uporabniškega vmesnika
• navadno se uporabljajo le kot del specifikacije sistema in se v nadaljevanju razvoja zavržejo
• obstajajo metode, ki tako izdelane prototipe izkoristijo kot osnovo za izdelavo produkcijskega sistema

Izdelava predloga arhitekture sistema

• v okviru analize analiziramo tudi tehnične in druge nefunkcionalne zahteve
• na podlagi tega podamo predlog tehnične arhitekture sistema
• upoštevamo tudi strategijo podjetja in standarde, ki se v podjetju uporabljajo
• opredelimo: strojno, komunikacijsko in programsko opremo, ki je potrebna za vzpostavitev ustreznega razvojenga in produkcijskega okolja
• izdelamo le predlog, ki služi kot eden pomembnih virov za oceno stroškov razvoja oz. nakupa IR

Opredelitev strategije testiranja

• način testiranja je določen s standardi, njegova izvedba je vseeno odvisna od izvedbe projekta
• v okviru strategije testiranja določimo:
  • kaj je predmet testiranja
  • kdo, kje in kako bo izvajal testiranje
  • kje bo nameščeno testno okolje
  • na kakšni strojni opremi bo nameščeno testno okolje
  • v kateri točki projekta se bo namestilo testno okolje
  • bo testiranje potekalo v več iteracijah ali v celoti
  • kakšna orodja se bo uporabljalo za pripravo in izvajanje testov

Predstavitev rezultatov analize naročniku

• ko izdelamo vse izdelke, pripravimo predstavitev naročniku
• osnovni namen: pridobitev potrdila s strani naročnika
• naročnik morda nima znanj za razumevanje elementov, predstavitev mora biti temu primerna
• potrditev se izvede v obliki dokumenta, ki je pogosto ena izmed kontrolnih projektnega vodenja

Načrtovanje

• Glavni namen načrtovanja je izdelati načrt zgradbe sistema glede na specifikacije, ki so bile zbrane v fazi analize.
• Načrt daje odgovor kako izdelati sistem, da bo ustrezal zahtevam, ki smo jih evidentirali v fazi analize.
• Cilji načrtovanja so:
  • Izdelati načrt IR, ki ustreza ugotovitvam iz analize in upošteva tehnološke omejitve sistema.
  • Dokumentirati specifikacije načrta na način, ki bo omogočal vzdrževanje sistema.
  • Zasnovati strategijo prehoda iz obstoječe na novo aplikacijo.
• Osnovna rezultata načrtovanja sta načrt podatkovne baze in načrt programskih modulov, s katerima pripravi vse potrebno za izdelavo podatkovnih in programskih komponent IR.
• V fazi načrtovanja izdelamo tudi
  • načrt dokumentacije
  • načrt testiranja
  • načrt namestitve in uvedbe

• Pri načrtovanju sodelujejo načrtovalec podatkovne baze, načrtovalec aplikacije, skrbnik podatkovne baze, izdelovalec dokumentacije, uvajalec, poslovni lastnik in končni uporabnik.
• Tipične aktivnosti načrtovanja so:
  • izdelava načrta podatkovne baze
  • izdelava načrta programskih modulov
  • izdelava načrta dokumentacije
  • izdelava načrta testiranja
  • izdelava načrta namestitve in uvedbe
  • predstavitev načrta naročniku

Izdelava načrta PB

• Namen aktivnosti je na podlagi konceptualnega modela iz analize izdelati logični podatkovni model in izvesti ostale korake, potrebne za vzpostavitev učinkovite fizične podatkovne baze.
• V sklopu načrtovanja izdelamo logični sistem in določimo sistem pravic za uporabo podatkov in programskih modulov.
• Logično modeliranje podatkovne baze nastopi za konceptualnim modeliranjem.
• Osnova logičnega modeliranja je jezik, ki je razumljiv ciljnemu SUPB.
• Če izberemo relacijski SUPB, potem govorimo o relacijskem modelu.
• Prehod iz konceptualnega v logični model je navadno avtomatiziran s strani CASE orodij
• Tipični koraki pri izdelavi relacijskega modela:
  • za entitetne tipe kreiraj relacije
  • preveri relacije z normalizacijo
  • preveri relacije s pregledom uporabniških transakcij
  • preveri omejitve integritete
  • preveri model z uporabnikom
  • združi lokalne modele v globalni model
  • preveri zmožnosti modela za razširitve

Relacijski model

• Koncepti:
  • relacija
  • atribut
  • domena
  • n-terica
  • funkcionalna odvisnost
  • ključ
  • pogled
  • normalizacija

• Relacijo si lahko predstavljamo kot dvodimenzionalno tabelo.
• Atribut je poimenovani stolpec relacije.
• Domena je množica dovoljenih vrednosti enega ali več atributov, ki so vključeni v to domeno.
• N-terica je ena vrstica v relaciji
• Števnost relacije je število N-teric v relaciji.
• Stopnja relacije je število atributov v relaciji.
• Relacijska podatkovna baza je množica normaliziranih relacij z enoličnimi imeni.
• Normalizirane relacije so relacije, ki ustrezajo normalnim oblikam. Te določajo pravila, ki jih morajo relacije zadoščati, da pri vnašanju, spreminjanju in brisanju podatkov ne prihaja do anomalij.
• Lastnosti relacij:
  • enoličnost: ime relacije, ime atributa v relaciji, n-terica v relaciji
  • atomarnost: vsaka celica vsebuje natanko eno atomarno vrednost
  • zaloga vrednosti
  • nepomembnost vrstnega reda
• Funkcionalna odvisnost Y od X (X->Y - X funkc. določa Y): če v nobeni relaciji, ki pripada Rne obstajata dve n-terici, ki bi bili enaki v vrednostih X in nebi bili enaki v vrednostih Y
• množici atributov, ki določajo vsako n-terico pravimo ključ relacije
• Vrste ključev
  • Kandidat za ključ
  • Primarni ključ
  • Superključ
  • Tuji ključ
• Za celovitost in skladnost podatkov skrbimo z omejitvami
• Pogledi
• Normalizacija je postopek, s katerem pridemo do množice primernih relacij, ki ustrezajo potrebam poslovne domene.
• 4 normalne oblike

Izdelava načrta programskih modulov

• Namen aktivnosti je prikazati, kako bodo posamezne funkcije in procesi, identificirani v sklopu analize, realizirani v okviru rešitve.
• Normalizacija je postopek, s katerem pridemo do množice primernih relacij, ki ustrezajo potrebam poslovne domene.
• Pretvorba ni nujno 1:1.
• Strukturo programskega modula prikažemo s pomočjo strukturnega diagrama.
  • prikazuje prog. module, iz katerih bo sestavljena prog. rešitev
  • prikazuje odvisnost med njimi in podatke, ki se med njimi prenašajo
  • omogoča prikaz zaporedja, izbire in ponavljanja
• Lastnosti strukturnih diagramov
  • moduli so organizirani v hierarhijo
  • vseobsegajoč modul ali koren
  • na 2. nivoju so moduli, ki jih koren lahko kliče
  • moduli komunicirajo s pomočjo parametrov

Izdelava načrta dokumentacije

• Namen aktivnosti je določiti obseg in strukturo dokumentacije ter izbrati ustrezne standarde in vzorce za dokumentacijo.
• Upoštevamo zahteve naročnika iz zajema zahtev.
• Določimo vire za dokumentacijo.
• Nekatere dele dokumentacije lahko izdelamo šele, ko je sistem izdelan.
• Dokumentacijo lahko razdelimo na:
  • uporabniško
  • sistemsko-tehnično
  • navodila za oprativno skrbništvo

• Uporabniška dokumentacija je osnovna pomoč za uporabnike oziroma uporabo rešitve.
• Sistemsko-tehnična dokumentacija dokumentira informacijsko rešitev s sistemsko-tehničnega vidika.
• Navodila za operativno skrbništvo zajemajo opis ključnih postopkov, ki so potrebni za operativno delovanje sistema.
• V okviru načrta izdelamo vzorce dokumentacije, ki jih predstavimo naročniku.
• Cilj je uskladitev o obliki dokumentacije.
• Nivo podrobnosti in obseg dokumentacije je odvisen od dogovora med izvajalcem in naročnikom. Praviloma se podrobneje dokumentirajo samo pomembnejši podsistemi in kritični postopki.

Izdelava načrta testiranja

• Testiranje, ki intenzivno poteka v fazi izvedbe ter v okviru namestitve in uvedbe sistema, je nujno predhodno načrtovati.
• Načrt testiranja zajema:
  • načrt poteka testiranja: določimo zaporedje izvajanja posameznih testov
  • načrt za izvedbo posameznih testov: določimo kaj bomo v okviru posameznega testa testirali
• Načrt za izvedbo testa mora opredeliti:
  • Namen
  • faza
  • okolje
  • področje
  • način izvedbe testiranja: podroben opis
• Testni scenariji opisujejo postopke uporabe sistema in so zato dobro vodilo za testiranje funkcionalnosti IR.
• Za izvedbo testa po nekem scenariju je potrebno določiti vhodne podatke in pričakovane rezultate.
• Načrt testiranja je sestavljen iz več dokumentov:
  • potek testiranja
  • scenariji testiranja funkcioanlnih in nefunkcionalnih zahtev
  • podroben opis izvedbe posameznih testov

Izdelava načrta namestitve in uvedbe

• Naloga aktivnosti je izdelati načrt namestitve in uvedbe IR v razvojno, testno in produkcijsko okolje ter uvedbo uporabnikov in skrbnikov za delo z IR.
• Pri načrtovanju namestitve razvojnega okoja sodelujejo samo člani projekte skupine, pri načrtovanju namestite testnega in produkcijskega okolja pa sodelujejo tudi predstavniki končnih uporabnikov.
• v načrtu je potrebno opredeliti
  • namen in cilj namestitve in uvedbe
  • zahteve okolja
  • naloge namestitve in uvedbe
  • udeležence namestitve in njihove odgovornosti
  • opis sestave paketa za namestitev IR
  • opis procesa namestitve in uvedbe
  • merila za uspešno namestitev in uvedbo
  • vrednotenje ugotovljenih napak ali pomanjkljivosti pri postopku namestitve in uvedbe
  • potrditev oz. odobritev rezultatov namestitve in uvedbe
• Načrt namestitve in uvedbe sestoji iz:
  • načrta namestitve IR
  • načrta dodelitve pravic
  • načrta prevedbe podatkov
  • načrta uvajanja
  • načrta za izvedbo potrditvenega ter dokončnega testa IR
  • načrt prehoda na nov sistem

Predstavitev načrta naročniku

• Osnovni namen predstavitve je pridobitev potrditve s strani naročnika o ustreznosti načrta.
• Naročniku predstavimo le osnovne elemente načrta.
• Za predstavitev je primeren načrt uporabniškega vmesnika.
• Na osnovi predstavitve lahko naročnik opozori na pomanjkljivosti oz. izrazi dodatne želje.
• Aktivnost ze zaključi s potrditvijo (navadno podpis dokumenta).

Izvedba

Testiranje

• Glavni namen testiranja je zagotoviti, da IR deluje tako, kot smo načrtovali.
• Postopek testiranja se prepleta skozi ves življenski cikel razvoja.
• Končni izdelek je preverjena in delujoča IR.
• Testiranje se izvaja na več ravneh: razvijalec, preizkuševalec, končni uporabnik.
• Zaradi varnosti moramo za testiranje in produkcijo zagotoviti ločena okolja.
• Najboljši pristop je ločitev strojne opreme. Prosukcijsko okolje vedno namestimo na ločeno strojno opremo.
• Vrste testov:
  • Test programskih enot
  • Test integracije
  • Sistemski test
  • Test sprejemljivosti: potrditveni test
  • Test sprejemljivosti: končni test

Test programskih enot

• je osnovno testiranje, osredotočeno na ustreznost uporabniškega vmesnika in funkcionalnosti programske enote
• izvaja se v razvojnem okolju, z njim se ukvarjajo razvijalci, ki so razvili module
• navadno je nesistematično in se ne izvaja po načrtu
• Ko je razvitih več enot, testiranje prevzame preizkuševalec. Skladno z načrtom preveri funkcionalnost sklopa, preden se namesti v testno okolje.
• Testiranje programskih enot se izvaja tudi v testnem okolju, kjer ustreznost sklopa potrdi končni uporabnik.
• Če je mogoče, testiranje v testnem in razvojnem okolju izvajamo vzporedno.

Test integracije

• namenjeno testiranju povezav med prog. moduli in testiranju vmesnikov
• poteka v več korakih, vzporedno z razvojem
• poteka v testnem okolju. Pri njem sodelujejo integrator, preizkuševalec in ključni uporabniki.
• Izvaja se po pripravljenem načrtu in se zaključi s potrditvijo.

Test sistema

• Testiranje sistema namenjeno testiranju obnašanja sistema kot celote ter njegovega delovanja v okolju. Poudarek na testiranju nefunkcionalnih zahtev kot na primer: zmogljivost, dostopnost, test pod obremenitvijo ipd.
• Test se izvaja v testnem okolju. Izvede se enkrat, in sicer takrat, ko je v testnem okolju nameščen celoten sistem in povezan z okoljem. Pri izvedbi testa sodelujejo: skrbnik podatkovne baze, sistemski administrator, skrbnik aplikacije, preizkuševalec in ključni uporabniki.

Test sprejemljivosti

• potrditveni in končni test
• Potrditveni test namenjen testiranju celotne IR, tako z vidika funkcionalnih kot nefunkcionalnih zahtev, z namenom pridobitve potrdila o njegovi ustreznosti. Test se izvaja v testnem okolju v sklopu postopka namestitve in uvedbe IR. Test izvaja ključni uporabnik po pripravljenem načrtu.
• Končni test je zadnji test IR. Izvedemo ga v produkcijskem okolju z namenom, da se prepričamo, da pri postopku namestitve ni prišlo do kakršnihkoli napak. Končni test izvedemo s pomočjo produkcijskih oziroma pravih primerov. Izvaja ga ključni uporabnik.

Uvajanje

• Glavni namen namestitve in uvedbe je:
  • namestitev izbrane IR ali njenih delov v testno ali produkcijsko okolje
  • izvedba potrditvenega in končnega testa
  • uvedba uporabnikov, skrbnikov in drugih, ki bodo z IR delali, za delo z novo IR
• Z izvedbo postopka zagotovimo, da lahko uporabniki nemoteno uporabljajo novo IR.
• Končen izdelek sta IR nameščena v produkcijsko okolje in uvedeni uporabniki.
• Ko je ta faza končana, se uporaba nove IR lahko prične.
• Aktivnosti v okviru postopka namestitve in uvedbe IR izvajajo načrtovalec podatkovne baze, uvajalec, skrbnik podatkovne baze, končni uporabnik, sistemski administrator, skrbnik aplikacije, postavitveni inženir, informacijski varnostni inženir in poslovni lastnik.
• Lahko razdelimo na sedem aktivnosti:
  • Namestitev IR
  • Dodelitev pravic za delo z IR
  • Prevedba podatkov
  • Izvedba potrditvenega testa IR
  • Izvedba končnega testa IR
  • Uvajanje uporabnikov in skrbnikov za delo z IR
  • Prehod na novi sistem

Namestitev IR

• vključitev nove IR v testno ali produkcijsko okolje. Potrebno je namestiti:
  • strojno opremo
  • sistemsko programsko opremo
  • aplikativno programsko opremo
• poteka na podlagi načrta, postopki morajo biti čim bolj avtomatizirani
• Namestitev IR v testno okolje poteka v več fazah (med razvojem) ali v celoti (ob zaključku).
• Namestitev IR v produkcijsko okolje se izvede, ko je aplikacija razvita in potrjena s potrditvenim testom v testnem okolju.

Dodelitev pravic za delo z IR

• V skladu z načrtom namestitve in uvedbe – načrt dodelitve pravic definiramo vloge, izvedemo vključitev oseb – uporabnikov v ustrezne vloge in jim dodelimo gesla.
• Upoštevamo tudi varnostno politiko. Pravice za dostop do podatkov in uporabo programskih modulov dodelimo naenkrat celotni posamezni skupini uporabnikov, ki izvajajo določeno vlogo.

Prevedba podatkov

• vzpostavitev začetnega stanja podatkov.
• Prevedba podatkov je lahko zelo kompleksen proces, saj se poleg prenosa podatkov pogosto izvaja tudi čiščenje, agregacija, reorganizacija podatkovnih struktur itd.
• Podatki v obstoječih sistemih so pogosto pomanjkljivi ali nepopolni, zapisani v obliki, ki je razumljiva zgolj programerjem itd.
• Načrt za prevedbo podatkov je narejen v sklopu načrta namestitve in uvedbe. Programski moduli, ki so potrebni za prevedbo podatkov, so narejeni v sklopu izvedbe.
• Prevedba podatkov v sklopu namestitve in uvedbe poteka v testno in produkcijsko okolje.
• Prevedba podatkov v testno okolje se izvede v sklopu namestitve testnega okolja. Po potrebi se lahko izvede večkrat.
• Prevedba podatkov v produkcijsko okolje se izvede v sklopu namestitve IR v produkcijsko okolje.

Izvedba potrditvenega testa IR

• Izvedem ga v testnem okolju.
• Predstavlja zaključni test pravilnega delovanja celotne IR v testnem okolju in zajema vse funkcionalnosti sistema, potrebne za delovanje v testnem okolju.
• Poteka na osnovi načrta testiranja in se zaključi s potrdilom o ustreznosti IR za namestitev v produkcijsko okolje

Izvedba končnega testa IR

• Končni test izvedemo v produkcijskem okolju.
• Predstavlja končni test pravilnega delovanja IR v produkcijskem okolju in poteka na produkcijskih primerih - na "živih" oz. produkcijskih podatkih v produkcijskem okolju.
• V končni test običajno ne moremo zajeti vse funkcionalnosti sistema. Poteka na osnovi načrta testiranja in se zaključi s potrdilom o ustreznosti IR za uporabo v produkcijskem okolju.

Uvajanje uporabnikov in skrbnikov za delo z IR

• Naloga uvajanja je naučiti uporabnike uporabljati in skrbeti za IR.
• Uvajanje izvaja uvajalec, ki je v primeru razvoja IR običajno član razvojne ekipe, v primeru nakupa IR pa predstavnik proizvajalca.
• Osnovni cilj uvajanja je vsako skupino uporabnikov naučiti uporabljati tiste sklope IR, ki jih uporabniki pri svojem delu potrebujejo.
• V okviru obravnavane aktivnosti je potrebno poleg običajnih uporabnikov uvesti tudi skrbnike IR.
• Poleg uvajanja samega je potrebno poskrbeti tudi za pripravo uvajalnih gradiv in testnih podatkov v podatkovni bazi, ki bodo služili za potrebe uvajanja.
• Smernice in priporočila za uvajanje:
  • uvajanje uporabnikov za uporabo novega sistema naj poteka ločeno za običajne uporabnike in za skrbnike novega sistema
  • najprej naj predstavniki izvajalca ali prodajalca IR izvedejo uvajanje skrbnikov, nato pa naj se izvede uvajanje uporabnikov – možen pristop: train the trainer
  • pri uvajanju je potrebno upoštevati velikost organizacije in uporabnike razdeliti v skupine glede na njihovo področje dela in podobnost načina uporabe novega sistema
  • uvajanje naj poteka v testnem okolju; če se uvajanje izvaja na produkcijski podatkovni bazi, je potrebno paziti, da ne izvajamo aktivnosti, kjer bi nastali podatki, ki jih ne bi mogli povrniti v prejšnje stanje oz. v stanje, ki odraža dejansko stanje v organizaciji
  • uporabniki morajo imeti dostop do sistema pomoči uporabnikom (raznovrstnih navodil), hkrati pa tudi vedeti, na koga se lahko obrnejo, če naletijo na težave, ki jih kljub navodilom ne znajo sami rešiti.

Prehod na novi sistem

• Prehod na nov sistem predstavlja trenutek, ko je IR primerna za uporabo v produkcijskem okolju.
• O trenutku začetka uporabe nove IR mora biti vnaprej obveščena vsa organizacija.
• Najprimernejši termini za začetek uporabe nove IR so delovno neintenzivna obdobja. Pogoj, ki mora biti izpolnjen za možnost začetka uporabe, so uspešno opravljene aktivnosti namestitve, testiranja, prevedbe podatkov in uvajanja.
• Različne strategije:

Fazni pristop

• Star/obstoječ sistem nadomestimo z novim v več korakih oziroma postopoma.
• Vsebina posameznega koraka ali faze je lahko različna; npr. najprej eno poslovno področje, potem drugo itd., ali najprej en funkcionalni sklop, zatem drugi itd.
• Prednosti postopne uvedbe oziroma postopne zamenjave starega z novim sistemom so številne, vendar takšen pristop ni vedno izvedljiv, saj pogosto zahteva začasne vmesnike za komunikacijo med deli novega in starega sistema.

Zamenjva ali vse naenkrat

• pri tej strategiji gre za enkratno zamenjavo obstoječega sistema z novim. Na izbran (in ustrezno načrtovan) trenutek se stare aplikacije ugasne in nadomesti z novimi.
• Takšen pristop zmanjša potrebo po virih, vendar je bolj tvegan, saj pomeni, da nimamo več dostopa do starega sistema v primeru, da gre kaj narobe.

Vzporedno delovanje

• strategija vzporednega delovanja temelji na vzporedni uporabi starega in novega sistema
• Med uvajanjem novega sistema v produkcijo starega ne ugašamo, temveč uporabljamo oba vzporedno.
• Prednost takšne strategije je v zmanjšanju tveganja (če gre kaj narobe, imamo še vedno na voljo star sistem), ključna slabost pa v zahtevnosti po virih ter potencialni neskladnosti podatkov zaradi dvojnega zajema.
• V praksi se strategija vzporednega delovanja pogosto uporablja v okrnjeni obliki, kjer star sistem ohranimo za vpoglede, medtem ko so vi vnosi izvedeni v novem sistemu.

Objektni razvoj

Osnovni principi objektne usmerjenosti

Osnove modelirnega jezika UML in procesa RUP

Objektna analiza in načrtovanje

Načrtovanje podatkovnih baz

Tri-nivojsko načrtovanje

Konceptualno načrtovanje

Osnove relacijskega modela in logično načrtovanje

Normalizacija

Izpiti

Izpiti