slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Projektovanje informacionih sistema Information Systems Design - Uvodna predavanja - PowerPoint Presentation
Download Presentation
Projektovanje informacionih sistema Information Systems Design - Uvodna predavanja -

Loading in 2 Seconds...

play fullscreen
1 / 50

Projektovanje informacionih sistema Information Systems Design - Uvodna predavanja - - PowerPoint PPT Presentation


  • 625 Views
  • Uploaded on

Prof. dr Angelina Njeguš Vanredni profesor Univerziteta Singidunum anjegus@singidunum.ac.rs Beograd, 2008/2009. Projektovanje informacionih sistema Information Systems Design - Uvodna predavanja - . Softverski inženjering. Formalne definicije softverskog inženjeringa:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Projektovanje informacionih sistema Information Systems Design - Uvodna predavanja -' - Patman


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1
Prof. dr Angelina Njeguš

Vanredni profesor Univerziteta Singidunum

anjegus@singidunum.ac.rs

Beograd, 2008/2009.

Projektovanje informacionih sistemaInformation Systems Design- Uvodna predavanja -

softverski in enjering
Softverski inženjering
  • Formalne definicije softverskog inženjeringa:
    • Inženjerska disciplina koja se bavi svim aspektima proizvodnje softvera
    • Disciplina koja obuhvata znanje, alate i metode za definisanje zahteva, razvoja softvera, rukovanje i održavanje softvera
  • Istorija razvoja softverskog inženjerstva :
    • 1940-te: ručno pisanje mašinskog koda
    • 1950-te: prvi alati, kao što su makro asembleri i interpreteri; prva generacija kompajlera
    • 1960-te: druga generacija alata kao što su optimizovani kompajleri; mainframe računari i softveri za velike korporacije
    • 1970-te: kolaborativni alati kao što su Unix; miniračunari i rast manjih poslovnih softvera
    • 1980-te: personalni računari (PC) i radne stanice; rast potrošačkih softvera
    • 1990-te: objektno-orjentisano programiranje i agilni procesi (npr., Extreme Programming); drastičan pad cena kapaciteta memorije računara i hardvera uopšte; WWW i PDA računari omogućavaju široku upotrebu softvera i rast sve kompleksnijih softvera
    • 2000-te: Upravljani kodovi i platforme kao što su Java, .NET, PHP i dr. čine pisanje softvera lakšim nego ikad. Web servisi, SOC (Service-oriented computing), SOA (servisno-orijentisana arhitektura) i sl.
softverski procesi
Softverski procesi
  • Svi softverski procesi koriste procedure u realizaciji procesa, s tim što su neki formalniji, tj. sadrže niz strogo definisanih procesnih koraka, striktne uloge, dokumentaciju i dr. (tzv. teški procesi), dok su drugi procesi adaptivniji, odnosno agilniji (okrenuti ljudskoj dimenziji, efikasnost kolaboracije ljudi koji prave i koriste softver u cilju dobijanja poslovne koristi).
  • Zajednički principi kod agilnih metoda u razvoju softvera:
    • Individue i interakcije između njih su važnije od procesa i alata
    • Softver koji radi je važniji od dokumentacije koja raste
    • Saradnja sa korisnicima je važnija od procesa ugovaranja
    • Odziv na promene je važniji od striktnog pridržavanja i praćenja plana
  • Striktna podela uloga, karakteristična za proceduralno orijentisane metode, se agilnim pristupom zamenjuju zajedničkom podelom znanja i odgovornosti za izvršavanje posla na nivou tima
  • Agilni – sazrevanje u vremenu; realizacija softvera koji se adaptira promenama okoline i promenama u zahtevima; oslanjanje na povratnu spregu radi analize rezultata svake iteracije od strane korisnika i usmeravanje toka sledeće iteracije
vodopad ivotni ciklus razvoja waterfall development lifecycle
Vodopad životni ciklus razvojaWaterfall Development Lifecycle
  • Vodopad pristup ne može adekvatno da se bori sa sve većom kompleksnošću koja nastaje:
    • Produženim trajanjem projekta
    • Sve većom veličinom aplikacije
    • Velikim ili distribuiranim timovima
    • Povećanom tehničkom kompleksnošću
    • Novinama u tehnologijama
  • Glavni problem ovog pristupa je što ne omogućava identifikovanje i umanjenje rizika u ranim fazama projekta
iterativni razvoj iterative development
Iterativni razvoj Iterative Development
  • Iterativni razvoj je pristup razvoju softvera u kome se životni ciklus softvera sastoji od nekoliko sekvencijalnih iteracija
    • Svaka iteracija je poseban mini-projekat koji se sastoji od aktivnosti kao što su analiza zahteva, dizajn, programiranje i testiranje
    • Iteracije u prvim fazama ukazuju na najveće rizike
    • Svaka iteracija proizvodi izvršne verzije
    • Svaka iteracija uključuje integraciju i testiranje
    • Cilj završetka iteracije je stabilan, integrisan, testiran deo celokupnog softverskog sistema koji se gradi
  • Razlika između dve sukcesivne iteracije je inkrement. Inkrement predstavlja razliku u ispunjenju funkcionalnih zahteva između posmatrane iteracije i iteracije koja joj neposredno prethodi implementirane u kodu
objedinjeni proces
Objedinjeni proces
  • Veliki broj proceduralnih procesa se primenjuje u razvoju OO softvera: OMT, Booch, MSF i dr.
  • Objedinjeni proces (Unified Process) nastaje ujedinjavanjem pristupa projektovanja softverskih sistema koji su formulisani od strane vodećih stručnjaka (Jacobson, Booch, Rumbaugh)
  • Glavni sponzor razvoja ove metodologije je bila firma Rational (vodeći prodavac CASE alata) otuda naziv Rational Unified Process ili kraće RUP
  • RUP se može svrstati i u kategoriju lakih procesa tzv. agilni UP, ako bi se iz UP-a izdvojio skup samo neophodnih artifakta za dati projekat.
  • RUP se oslanja na UML (Unified Modelling Language) koji služi za specifikaciju, vizuelizaciju, konstrukciju i dokumentaciju razvoja softvera
  • UML je brzo postao standardni jezik za modelovanje poslovnih potreba i softverskih aplikacija
  • UML je projektovan kao fleksibilni i prilagodljiv jezik i ne mora se samo koristiti za modelovanje objektno orijentisanih aplikacija.
rational unified process rup
RUP je pristup razvoja softvera koji je iterativan, centriran oko arhitekture i vođen slučajevima korišćenja

Osnovni koncepti u RUP:

Iterativno inkrementalni proces u razvoju softvera je proces koji obezbeđuje da sistem koji se razvija inkrementalno raste u vremenu iz iteracije u iteraciju

Milestone (kontrolna/ključna/kritična tačka)

Svaka faza u razvoju projekta se završava sa nekim milestone-om koji sumiraju rezultate svih prethodnih iteracija i u njoj se donose značajne odluke za ceo projekat u celini, u zavisnosti od toga da li su svi ciljevi i uslovi koji su bili definisani za tu tačku ispunjeni

Role definišu ponašanja i odgovornosti pojedinca ili tima

Artifakti:

Dokumenta: beleže zahteve sistema, kao i upotrebljivost, pouzdanost, performanse i podršku zahtevima

Model: pojednostavljeni pogled sistema koji prikazuje osnovni sistem bez nepotrebnih detalja

Elementi modela: pomaže timu da vizuelizuju, konstruišu i dokumentuju strukturu i ponašanja sistema

Rational Unified Process – RUP
faze iterativnog razvoja
Faze iterativnog razvoja
  • Životni ciklus softvera prema RUPu je dekomponovan tokom vremena u četiri sekvencijalne faze koje se završavaju glavnim kontrolnim tačkama
  • U početnoj fazi (inception): razumevanje šta treba graditi
    • Vizija, zahtevi visokog nivoa, poslovni slučajevi korišćenja
    • Identifikovanje rizika
    • Procena troškova, vremena, plana i kvaliteta proizvoda
    • Inicira se kreiranje poslovne studije opravdanosti ulaženja u projekat
  • Faza elaboracije (elaboration): razumevanje kako treba graditi
    • Osnovna arhitektura, većina zahteva je detaljna
    • Dizajn nije detaljan
    • Precizna procena resursa i vremena
  • Konstrukcija (construction): izgradnja proizvoda
    • Rad na proizvodu, završeno testiranje sistema
  • Tranzicija (transition): validacija rešenja
    • Prihvatljivost od strane stejkoldera
iteracije i faze
Iteracije i faze
  • U okviru svake faze razvija se proces kroz niz iteracija i inkrementa
  • Na kraju svake iteracije proverava se šta je urađeno i da li se u međuvremenu pojavio ili promenio neki zahtev čime se kontroliše nivo rizika za sledeću iteraciju
  • Strategija razvoja softvera korišćenjem ove metode je u malim koracima kojim se upravlja, a koji svaki za sebe može predstavljati mini projekat
  • Cilj je dobiti što kvalitetniji rezultat u posmatranom vremenu, a ne da se iza maske velikog projekta sakrije neefikasnost i loši rezultati
  • Svaka iteracija kao završetak ima implementiran kod
pregled rup koncepata
Pregled RUP koncepata
  • Discipline prikazuju sve aktivnosti kroz koje se mora proći kako bi se proizveo određeni skup artifakta. Ove discipline se opisuju kroz role, aktivnosti i uključene artifakte
  • Tokovi posla (workflow) grupiše aktivnosti koje se zajedno odvijaju
po etna faza inception ta razvijati
Početna faza (Inception) – Šta razvijati
  • Pripremiti dokument vizije i inicijalnih poslovnih slučajeva korišćenja
    • Uključiti ocenu rizika i procenu resursa
  • Razviti projektne zahteve visokog nivoa
    • Inicijalni slučajevi korišćenja i modeli domena (10-20% završeno)
  • Upravljati domenom projekta
    • Umanjiti rizike tako što će se identifikovati svi ključni zahtevi
    • Saznanje da će se zahtevi menjati
      • Upravljati promenama kroz iterativne procese
ciljevi po etne faze
Ciljevi početne faze
  • Cilj 1: Razumeti šta se razvija
    • Složiti se oko vizije
    • Navesti ključne aktere i slučajeve korišćenja (preliminarni model slučajeva korišćenja)
      • Identifikovati sve aktere
      • Pridružiti svakog aktera slučajevima korišćenja
      • Ukratko objasniti svakog aktera i slučajeve korišćenja sa 1 do 2 rečenice
      • Napraviti rečnik (definiše opštu terminologiju za sve modele i sadrži tekstualni opis zahtevanog sistema)
      • Identifikovati najosnovnije i kritične slučajeve korišćenja (<20% slučajeva korišćenja)
    • Odrediti domen sistema
    • Navesti detaljne ključne nefunkcionalne zahteve
osnovni koncepti u modelu slu ajeva kori enja

Slučaj

Korišćenja

Use Case

AkterActor

Osnovni koncepti u modelu slučajeva korišćenja

Akter (učesnik) predstavlja osobu ili drugi sistem koji je u interakciji sa sistemom

  • Akteri su obično ljudi, hardverski uređaji i dr. sistemi koji su u interakciji sa sistemom

Slučaj korišćenja (use case) definiše sekvencu akcija koje sistem izvršava, a predstavlja rezultat od određene vrednosti za aktera.

  • Use case predstavlja glavni deo neke komplentne funkcionalnosti od početka do kraja
    • Npr. student mora da izabere kurseve za semestar, da se upiše i uplati izabrane kurseve (use case: registrovanje na kurseve)
    • Npr. sekretar mora da dodaje, briše i modifikuje kurseve (use case: održavanje nastavnog plana, jer započinje isti akter i radi sa istim entitetima u sistemu)
ciljevi po etne faze nastavak
Ciljevi početne faze (nastavak)
  • Cilj 2: Identifikovati ključne zahteve
    • Funkcionalnost je jezgro aplikacije
      • Iscrtati ključne interfejse
      • Navesti rizike koji se odnose na performanse, redundnantnost, bezbednost podataka, ...
  • Cilj 3: Odrediti najmanje jedno potencijalno rešenje
    • Trebalo bi odgovoriti na pitanja od bitnog uticaja:
      • Da li možete razviti aplikaciju sa manjim brojem rizika, a pri prihvatljivim troškovima.
        • Da li ste razvijali slične sisteme? Sa kojom arhitekturom i sa kojim troškovima? Da li će trenutna arhitektura raditi ili će biti potrebno redizajnirati?
      • Profil osoblja – Da li ste u mogućnosti da angažujete osoblje sa pravim kompetencijama?
      • Da li se zahtevaju softverske komponente? Da li se mogu nabaviti? Pri prihvatljivim troškovima?
ciljevi po etne faze nastavak21
Ciljevi početne faze (nastavak)
  • Cilj 4: Razumevanje troškova, rasporeda i rizika
    • Poslovni slučajevi
      • Da li treba da finansiramo projekat
      • Troškovi
      • Povratak investicija (ROI)
    • Plan razvoja softvera
      • Plan projekta
      • Potreba za resursima
  • Cilj 5: Razumevanje koje procese pratiti i koje alate koristiti
faza elaboracije kako razvijati
Faza elaboracije – kako razvijati
  • Detaljni zahtevi (~80% završiti)
  • Postaviti izvršnu i stabilnu arhitekturu
    • Definisati, implementirati i testirati interfejse glavnih komponenti
    • Identifikovati zavisnost spoljnih komponenti i sistema
    • Neke ključne komponente će biti parcijalno implementirane
    • Grubo 10% koda će biti implementirano
  • Arhitektura sa ključnim slučajevima korišćenja
    • 20% slučajeva korišćenja nose 80% arhitekture
    • Projektovati, implementirati i testirati ključna scenarija za slučajeve korišćenja
  • Verifikovati arhitekturu
    • Pouzdanost: stres test (proverava ponašanje sistema kada je na izmaku resursa ili kada se za resurse treba boriti, npr. prevazilaženje deadlock stanja)
    • Skalabilnost i performanse: test punjenja
  • Kontinualna procena poslovnih slučajeva korišćenja, rizika i plana razvoja
ciljevi faze elaboracije
Ciljevi faze elaboracije
  • Cilj 1: Detaljnije razumevanje zahteva
    • Sa 20% slučajeva korišćenja obuhvatiti 80% zahteva
    • Izgraditi prototipe grafički orjentisanih slučajeva korišćenja
    • Proći kroz slučajeve korišćenja sa stejkholderima
  • Cilj 2: Projektovati, implementirati, vrednovati i postaviti arhitekturu
    • Doneti kritične odluke: kupiti ili razvijati, paterni, ...
    • Skicirati osnovnu strukturu vašeg sistema. Dokument arhitekture softvera predstavlja sveobuhvatan pregled arhitekture softverskog sistema. Uključuje: poglede, ciljeve i ograničenja, veličinu i performanse, kvalitet, proširljivost i portabilnost.
    • Izvršiti inicijalni test performansi
ciljevi faze elaboracije nastavak
Ciljevi faze elaboracije (nastavak)
  • Cilj 3: Umanjiti osnovne rizike i napraviti precizniji raspored i proceniti troškove
    • Ključni rizici:
      • Tehničke rizike - umanjiti implementiranjem i testiranjem arhitekture
      • Poslovne rizike - implementiranjem i testiranjem ključnih funkcionalnosti sistema
      • Timske rizike – tim treba da prođe kroz ceo životni ciklus softvera implementirajem realnog koda
  • Cilj 4: Uvođenje razvojnog okruženja
    • Zasniva se na prethodnom iskustvu tima
    • Kastimizacija i poboljšanje okruženja alata ukoliko je potrebno
    • Obučavati članove tima i uvoditi alate
vi estruke iteracije kod faze elaboracije
Iteracija 1

Projektovati, implementirati i testirati manji broj kritičnih scenarija

Identifikovati, implementirati i testirati manji skup paterna

Uraditi preliminarni logički dizajn baze podataka

Detaljan tok događaja počevši od najvažnijih slučajeva korišćenja

Testirati kako bi se umanjili rizici

Iteracija 2

Popraviti sve ono što nije radilo u prethodnoj iteraciji

Projektovati, implementirati i testirati ostatak scenarija

Uočiti ključne rizike implementiranjem konkurentnosti, procesa, niti i fizičke distribucije

Fokusirati se na testove performansi, punjenja i interfejsa

Identifikovati, implementirati i testirati paterne

Projektovati, implementirati i testirati preliminarnu verziju baze podataka

Detaljnije obraditi i ostalih 50% slučajeva korišćenja

Testirati arhitekturu u slučaju redizajna

Višestruke iteracije kod faze elaboracije
scenario
Scenario
  • Svaki use case ima tok događaja koji pokazuje šta sistem radi, ali ne i kako će sistem biti projektovan
  • Tok događaja use case-a ima jedan normalan, osnovni tok i nekoliko alternativnih tokova
    • Jedan tok događaja se naziva instanca use case-a ili scenario
    • Slučajevi korišćenja mogu imati mnogo instanci
    • Instanca slučaja korišćenja je jednostavan tok događaja u sistemu, obično iniciranih od strane aktera
  • Slučaj korišćenja opisuje skup povezanih scenarija
  • Scenario opisuje instancu slučaja korišćenja: određena sekvenca akcija koje opisuju ponašanje sistema
primer specifikacija use case a odabiranje kurseva koji e se predavati
Primer: Specifikacija use case-a“Odabiranje kurseva koji će se predavati”

1.0 Use case name

Odabiranje kurseva koji će se predavati

1.1 Brief Description

Ovaj use case pokreće Profesor. Omogućava da profesor izabere do četiri kursa koja će predavati tokom izabranog semestra

2.0 Flow of Events (tok događaja)

2.1 Osnovni tok (basic flow)

Ovaj use case počinje kada se profesor prijavi na sistem za registraciju i unese svoju lozinku. Sistem verifikuje da je lozinka valjana (ukoliko lozinka nije valjana izvršava se alternativni tok 2.2.1) i signalizira da profesor izabere tekući ili budući semestar (ukoliko se unese pogrešan semestar, izvršava se alternativni tok 2.2.2). Profesor unosi željeni semestar. Sistem signalizira da profesor izabere željenu aktivnost: add, delete, review, print ili quit.

Ukoliko je izabrana aktivnost Add, sistem prikazuje ekran sa poljem za unos naziva i broja kursa. Ukoliko profesor unese nevažeću kombinaciju ime/broj, izvršava se alternativni tok 2.2.3). Sistem prikazuje nuđene opcije za taj kurs (ako ime kursa ne može da se prikaže izvršava se alternativni tok 2.2.4). Profesor bira neku od ponuda. Sistem povezuje tog profesora sa izabranom ponudom (ukoliko veza ne može da se napravi, izvršava se alternativni tok 2.2.5). Zatim, use case ponovo počinje.

Ukoliko je izabrana opcija Delete, sistem prikazuje ekran sa nuđenim opcijama za taj kurs sa poljem za ime opcije i za broj. Profesor unosi ime i broj opcije (ako se unese nevažeća kombinacija ime/broj, izvršava se alternativni tok 2.2.3). Sistem uklanja vezu sa tim profesorom (ako veza ne može da se ukloni, izvršava se alternativni tok 2.2.6). Tada use case ponovo počinje.

Ukoliko je izabrana aktivnost Review, sistem poziva (ako informacija o kursu ne može biti pozvana, izvršava se alternativni tok 2.2.7) i prikazuje sledeće informacije o svim opcijama kurseva koje su njemu dodeljene: ime kursa, broj kursa, broj opcije kursa, dane u nedelji, vreme i lokaciju. Kada profesor ukaže da je on ili ona završio pregledanje, use case ponovo počinje.

Ukoliko je izabrana aktivnost Print, sitem štampa profesorov raspored (ukoliko raspored ne može da bude odštampan, izvršava se alternativni tok 2.2.8). Use case ponovo počinje.

Ukoliko je izabrana aktivnost Quit, use case se završava.

primer specifikacija use case a nastavak
Primer: specifikacija use case-a (nastavak)

2.2 Alternativni tokovi

2.2.1 Nevažeća lozinka

Unešena je nevažeća lozinka. Korisnik može ponovo da je unese ili da okonča use case.

2.2.2 Nevažeći semestar

Sistem obaveštava korisnika da je semestar nevažeći. Korisnik može ili ponovo da unese semestar ili da okonča use case

2.2.3 Nevažeće ime/broj kursa

Sistem obaveštava korisnika da je nevažeće ime/broj kursa. Korisnik može ponovo da unese valjanu kombinaviju ili da okonča use case

2.2.4 Opcija kursa ne može da se prikaže

Korisnik biva informisan da ta opcija nije trenutno dostupna. Use case ponovo počinje

2.2.5 Ne može da se uspostavi veza između profesora i opcije kursa

Ova informacija je zapamćena i sistem će kasnije uspostaviti tu vezu

2.2.6 Veza između profesora i opcije kursa ne može da se ukloni

Ova informacija ostaje zapamćena i sistem će kasnije ukloniti tu vezu

2.2.7 Ne može da se dobije informacija o rasporedu

Korisnik se obaveštava da ova opcija trenutno nije dostupna

2.2.8 Raspored ne može da se odštampa

Korisnik se obaveštava da ova opvija trenutno nije dostupna

3.0 Special Requirements

Za ovaj use case ne postoje posebni zahtevi

primer specifikacija use case a nastavak29
Primer: Specifikacija use case-a (nastavak)

4.0 Preconditions (preduslovi)

4.1 Pre nego što se pokrene ovaj use case mora biti završen podtok Create Course Offerings (Napravi opcije kursa) use case-a Maintain Course Information (Održavaj informacije o kursevima)

5.0 Post Conditions (post uslovi)

Ne postoje krajnji uslovi

6.0 Extension Points

Ne postoje tačke proširivanja

slojevit pristup layering approach
Slojevit pristup (layering approach)
  • Na slici je prikazan primer arhitekture sa četiri sloja:
    • Najviši sloj, sloj Aplikacije, sadrži servise koji su specifični za aplikaciju
    • Sledeći sloj, Biznis sloj (sloj poslovne logike), sadrži komponente specifične za poslovanje koje se koriste u nekoliko aplikacija
    • Srednji sloj, Middleware sloj, sadrži komponente kao što su GUI bilderi, interfejsi sistema za upravljanje bazama podataka, servisi operativnih sistema nezavisnih od platformi i OLE komponente kao što su spreadsheets i dijagram editori
    • Donji sloj, sloj sistemskog softvera, sadrži komponente kao što su operativni sistemi, baze podataka, interfejse ka određenim hardverima itd.
arhitektura zasnovana na komponentama component based architecture
Arhitektura zasnovana na komponentama (Component-based architecture)
  • Komponenta je nezavisan i zamenjivi softverski objekat koji enkapsulira implementaciju određene funkcionalnosti ili skupa funkcionalnosti iza jasno definisanog interfejsa i u interakciji je sa drugim komponentama sadržanih u jasno definisanoj arhitekturi
  • Većina komponenti je nezavisna od platforme
  • Tipovi komponenata:
    • Business component – softverska implementacija poslovnog koncepta ili procesa; sadrži određenu poslovnu funkcionalnost, npr. porudžbina, izračunavanje poreza, plaćanje itd.
    • Technical component – sadrži tehničku funkcionalnost koja se koristi za formiranje infrastrukture aplikacije; npr. komponente bezbednosti, sistemi menija, Java apleti, interakcija sa operativnim okruženjem itd.
    • Runtime software component – izvršna softverska komponenta koja se kreira tokom izvršavanja programa
primer komponentne arhitekture u e business aplikaciji
Primer komponentne arhitekture u e-business aplikaciji
  • Business components:
    • Customer relationship – servisi za skladištenje, održavanje i korišćenje korisničkih profila
    • Product catalogue – servisi koji omogućavaju konzistentan pristup informacijama kataloga proizvoda kao što su cene, specijalne ponude, nivo zaliha i dr.
    • Shopping cart – servisi koji omogućavaju klijentu prikupljanje i pregledanje skupa izabranih kupovina kao jednu transakciju
    • Payment – servisi koji omogućavaju proveru kredita i administriranje transakcija plaćanja
    • Order – servisi koji omogućavaju kreiranje porudžbenice,
    • Directory - servisi koji omogućavaju otvorenu i digitalnu verziju internog direktorijuma telefona
primer komponentne arhitekture u e business aplikaciji nastavak
Primer komponentne arhitekture u e-business aplikaciji (nastavak)
  • Komponentna arhitektura je troslojna gde je korisnički interfejs odvojen od poslovne logike i sloja podataka – omogućava se ponovna upotrebljivost određenih funkcionalnosti:
    • User interface layer – ovaj sloj podržava sve delove rešenja koji se odnose na korisničke interfejse
    • Business layer – uključuje:
      • Process components – obezbeđuje lokalnu poslovnu funkcionalnost
      • Business domain components – obezbeđuje funkcionalnost kroz različite poslovne procese
      • Business infrastructure components – kroz nekoliko poslovnih domena
    • Technical infrastructure layer – ove komponente obezbeđuju tehničke servise poslovnim komponentama
paterni patterns
Paterni (patterns)
  • Dizajn paterni i ponovno upotrebljive komponente pomažu u prevazilaženju složenosti koje postoje kod velikih aplikacija
  • Dizajn paterni (design patterns) - obezbeđuju pristup dokazanim metodologijama za rešavanje opštih problema i sposobnost korišćenja kolektivnog znanja i iskustva IT zajednice radi poboljšanja kvaliteta aplikacije
    • Paterni pomažu u organizovanju koda na dokazani način u rešavanju dobro definisanih problema
    • Omogućavaju bolju modularnost; visoko jedinstvo i slabu spregnutost
  • Ponovo upotrebljive komponente (reusable components) – enkapsuliraju funkcionalnost koja je zajednička kroz mnoge aplikacije i povećava produktivnost
faza konstrukcije razviti proizvod
Faza konstrukcije – razviti proizvod
  • Kompletan model zahteva i dizajna
  • Projektovanje, implementiranje i testiranje svake komponente
    • Prototipovanje sistema i uključivanje korisnika
    • Inkrementalno uključivanje izvršne arhitekture radi završavanja sistema
  • Razvijati dnevno ili nedeljno sa automatizovanim procesom razvoja
  • Testirati svaki build
    • Automatsko regresivno testiranje (potvrđuje se da li su ostali delovi sistema ostali stabilni posle završetka iteracije)
    • Test punjenja i stresa kako bi se osigurao integritet arhitekture
  • Isporučiti funkcionalni softver (beta verzija)
    • Uključiti materijale za obuku, korisničku dokumentaciju i dokumentaciju uvođenja rešenja u sistem
  • Napraviti opis verzije
ciljevi faze konstrukcije
Ciljevi faze konstrukcije
  • Cilj 1: Minimizirati troškove razvoja i dostići neki stepen paralelnog rada razvojnog tima
    • Organizovati tim oko arhitekture softvera
    • Optimizovati resurse i izbeći nepotrebne ostatke
    • Osigurati kontinuirani progres
      • Postaviti jasne ciljeve
      • Organizovati brze svakodnevne sastanke ...
  • Cilj 2: Iterativno razviti kompletan proizvod koji je spreman za tranziciju u korisničko okruženje
    • Opisati ostale slučajeve korišćenja i druge zahteve
    • Projektovati bazu podataka
    • Integraciono i sistemsko testiranje
    • Razviti prvu operativnu verziju sistema (beta verzija)
    • Odrediti da li su softver, sajtovi, korisnici spremni za uvođenje aplikacije
faza tranzicije uvo enje ka krajnjim korisnicima
Faza tranzicije – uvođenje ka krajnjim korisnicima
  • Potvrda da realizovani sistem zadovoljava tražene funkcionalnosti i performanse
  • Uvođenje inkrementalne “bug-fix” verzije
  • Ažuriranje korisničkih priručnika i dokumentacije uvođenja
  • Ažuriranje verzije
  • Vođenje analize projekta u toku perioda zatišja
ciljevi faze tranzicije
Ciljevi faze tranzicije
  • Cilj 1: Beta test za vrednovanje očekivanja korisnika
    • Ispravljanje bagova
  • Cilj 2: Obučavanje korisnika i održavanje pouzdanosti korisnika u sistem
  • Cilj 3: Pripremiti uvođenje sistema
    • Nabavka novog hardvera, migriranje podataka ...
  • Cilj 4: Pripremiti sistem za puštanje u rad, verziju za distribuciju, obučavati osoblje
  • Cilj 5: Poboljšati buduće performanse projekta kroz naučene lekcije
klju ni principi i najbolje prakse
Ključni principi i najbolje prakse
  • Razviti samo ono što je neophodno
    • Agilnost
    • Fokus na ključne zahteve (prikupiti, dokumentovati, organizovati, sortirati prema prioritetu)
  • Minimizirati papirne poslove
  • Biti fleksibilan
    • Zahtevi će se menjati – proceniti uticaj promena i odlučiti koje zahteve implementirati
    • Preneti promene svim članovima tima
    • Plan, ljudi itd.
  • Učiti iz prethodnih grešaka
    • Petlje povratne sprege
    • Poboljšanje procesa
  • Revizija redovnih rizika
  • Uspostaviti ciljeve, merljive kriterijume za napredovanje
  • Automatizovati
    • Podržati proces sa alatima za razvoj softvera
razvoj vo en slu ajevima kori enja
Razvoj vođen slučajevima korišćenja
  • Slučajevi korišćenja (use-case) opisuju servise koje sistem nudi korisnicima i drugim sistemima
  • Slučajevi korišćenja vode posao kroz svaku iteraciju:
    • Planiranje iteracija
    • Kreiranje i validacija arhitekture
    • Definisanje slučajeva i procedura testiranja
    • Dizajniranje korisničkih interfejsa i kreiranje korisničke dokumentacije
uspostaviti izvr nu arhitekturu u ranim fazama
Uspostaviti izvršnu arhitekturu u ranim fazama
  • Arhitektura obezbeđuje kostur strukture sistema
    • Podsistemi, ključne komponente, interfejsi, arhitekturalni mehanizmi (rešenja za opšte probleme, kao što su doslednost, interno-procesna komunikacija ...)
    • Implementiranje i testiranje arhitekture umanjuje veće tehničke rizike
tradicionalna funkcionalna dekompozicija
Tradicionalna funkcionalna dekompozicija
  • Vođena zahtevima
  • Mnoge zavisnosti kreiraju nefleksibilni sistem
izgraditi sistem sa komponentama
Izgraditi sistem sa komponentama
  • Komponentna arhitektura obezbeđuje fleksibilnost
  • Komponente omogućavaju:
    • Jasnu podelu posla između timova developera
    • Poboljšano održavanje i proširljivost
    • Ekonomička ponovna upotreba ili kastimizacija postojećih komponenti
    • Izbor između hiljada raspoloživih ActiveX i Java komponenata
    • Inkrementalnu evoluciju postojećeg softvera
testiranje svake iteracije
Testiranje svake iteracije
  • Veoma je važno započeti testiranje u ranim iteracijama
  • Kako se dodaju novi zahtevi u svakoj iteraciji, generišu se i novi testovi
slide50

RUP: integrisan sa alatima

  • Tool mentors: Web-based assistance for tool use
  • Extended Help: Process guidance from within any tool