projektiranje in organizacija informacijskih sistemov
Download
Skip this Video
Download Presentation
Projektiranje in organizacija informacijskih sistemov

Loading in 2 Seconds...

play fullscreen
1 / 22

Projektiranje in organizacija informacijskih sistemov - PowerPoint PPT Presentation


  • 105 Views
  • Uploaded on

Projektiranje in organizacija informacijskih sistemov. Dobra in slaba praksa. Odbor za spremembe (Change Board). Sestavljajo ga vsi (oz. predstavniki vseh), ki sodelujejo pri projektu – razvijalci,pisci dokumentacije, služba za podporo uporabnikom, prodaja, uprava...

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 'Projektiranje in organizacija informacijskih sistemov' - tacy


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
odbor za spremembe change board
Odbor za spremembe(Change Board)
  • Sestavljajo ga vsi (oz. predstavniki vseh), ki sodelujejo pri projektu – razvijalci,pisci dokumentacije, služba za podporo uporabnikom, prodaja, uprava...
  • Odbor mora potrditi vsako spremembo
  • Koristi:
    • manjša možnost, da bodo spremembe kaj pokvarile
    • o vseh spremembah bodo obveščeni vsi
    • razvijalcem so lahko spremembe všeč tudi, če niso potrebne; prodaji so všeč, tudi če niso (preprosto) izvedljive:odbor take spremembe ustavi
  • Slabosti:
    • birokracijo imajo radi le birokrati
    • odbor lahko sprejme preveč ali premalo sprememb
  • Podoben odbor je mogoče zasnovati tudi na nižjem nivoju
dnevna gradnja in testiranje daily build and smoke test
Dnevna gradnja in testiranje(Daily Build and Smoke Test)
  • Aplikacijo vsak dan prevedemo, sestavimo in testiramo
  • “Vsak dan” lahko pomeni tudi samo “pogosto”: sinhronizacija projekta (sync pulse)
  • Razvijalcu ni potrebno dodajati vse kode sproti; ne sme pa čakati predolgo
  • Te prakse ni modro opuščati, ko se mudi: nasprotno!
  • Koristi:
    • zmanjšanje možnosti težav pri integraciji
    • sprotno testiranje bistveno olajša odpravljanje napak
    • večja vidljivost projekta
    • izboljšanje morale: programerji radi vidijo, da program dela
    • boljši odnosi z naročnikom
  • Slabosti:
    • odvisnost od resnosti razvijalcev in kvalitete testov
    • pritisk k izdaji pogostih vmesnih različic
  • Kazni (praviloma zabavne) za te, ki pokvarijo aplikacijo
  • NT 4.0 ima 5.6M vrstic in se je prevajal po 19 ur, a so ga vseeno prevedli in testirali dnevno
pripravljenost na spremembe designing for change
Pripravljenost na spremembe(Designing for Change)
  • Vedi, kaj se utegne spremeniti
  • Skrivanje informacij
    • getID (sprememba IDjev iz pozitivnih v negativne...)
      • skriti način dodeljevanja IDjev ali pa celo njihov tip
  • Če veš, da se bo nekaj spreminjalo, poskrbi, da te to ne bo prizadelo
    • abstraktne podatkovne strukture uporabljaj kot abstraktne
    • uporabljaj simbolične konstante namesto konstant
    • ponavljajoča se koda sodi v funkcijo – čeprav enovrstično
  • Uporabljaj predmetno usmerjeno programiranje
  • Tveganja:
    • uporaba predmetov še ne pomeni predmetne usmerjenosti
    • in obratno, npr. Python (izvorna koda) je v osnovi predmetno usmerjen, čeprav v Cju
postavljanje ciljev
Postavljanje ciljev
  • Možni cilji so, denimo:
    • minimalna raba pomnilnika
    • hitrost kode
    • preglednost izpisa
    • preglednost kode
    • dolžina kode
    • hitrost programiranja
  • Študije kažejo, da razvijalci sledijo cilju, ki jim ga zadajo
  • Prednosti:
    • Motivacija ob izpolnjevanju cilja
  • Slabosti:
    • Pomanjkanje motivacije, če cilji niso izpolnjeni
skupni razvoj aplikacij joint application development jad
Skupni razvoj aplikacij(Joint Application Development, JAD)
  • Intenzivni sestanki uporabnikov, vodstva in razvijalcev: 3–5 dni, 4–8 ur dnevno
  • Sodelujoči:
    • “sponzor”
    • voditelj
    • uporabniki
    • dokumentalist (zapisnikar)
    • razvijalci, tehnično osebje
  • Prednosti
    • pritegne vodstvo k projektu
    • olajša analizo zahtev
    • odstranjuje nepotrebne funkcije
    • lahko se konča z razvitim prototipom
skupni razvoj aplikacij jad voditelj
Skupni razvoj aplikacij (JAD):Voditelj
  • Za uspeh je ključen dober voditelj
    • odlične komunikacijske sposobnosti
    • dober pogajalec, zna dobro usklajevati različne interese
    • dobro pozna poslovno plat projekta
    • odlične organizacijske sposobnosti
    • nepristranskost (zaključki sestanka ga ne zadevajo direktno)
    • nihče od ostalih udeležencev JAD mu ni nadrejen
  • JAD vodja
    • pripravi sestanek
    • ga vodi
    • spremlja njegove zaključke
  • Postavi osnovna pravila, na podlagi katerih se izvaja sestanek
  • Skrbi za dinamiko sestanka
    • vodi diskusije
    • v diskusije vključuje posamezne sodelujoče
    • razrešuje nastale konflikte
    • skrbi za to, da so doseženi cilji sestanka
skupni razvoj aplikacij jad druge vloge
Skupni razvoj aplikacij (JAD):Druge vloge
  • Uporabniki
    • določijo zahteve (povabiti je treba tiste, ki bodo to znali!)
    • revidirajo nastale načrte, modele in prototipe
    • odločajo o sprejetju zaključkov
  • Vodstvo
    • potrdi cilje projekta
    • postavi prioritete
    • potrdi urnike, stroške in ostale plane
  • Dokumentalist
    • vodi zapisnik
    • pogosto to vlogo opravlja eden od razvijalcev
  • Razvijalci
    • So prisotni, a se navadno ne vključujejo, če niso pozvani
    • Njihova naloga je skrbeti, da načrtovani sistem ne bo neizvedljiv
    • Lahko pomagajo dokumentalistu pri tehničnih detajlih
skupni razvoj aplikacij jad prostor
Skupni razvoj aplikacij (JAD):Prostor
  • Stran od poslovnih lokacij
  • Več sob, posebej če je sestanek več kot dvodneven
slide10
Hrana & Pijača

tabla s papirjem

tabla

projektor

uporabnikiinvoditelji

razvijalci in opazovalci

računalniški

projektor

vodja

JAD

zapisnikar

računalnik

tiskalnik

10-15 m

10-15 m

skupni razvoj aplikacij jad klju ni dejavniki za uspeh
Skupni razvoj aplikacij (JAD):Ključni dejavniki za uspeh
  • izkušen vodja
  • predanost sponzorja metodologiji
  • ključni udeleženci popolnoma prisotni
  • na sestanek morajo priti “zvezde”, ne “nakladači” in birokrati; udeležene strani na JAD ne smejo poslati tistih, ki jih “lahko pogrešijo”
  • dislociranost sestanka (ni telefonov, e-mailov, ...)
  • dobra pripravljenost sodelujočih
  • realnost ciljev: če je navdušenje preveliko, si lahko zastavimo neuresničljive cilje
  • izogniti se je potrebno lažnemu vtisu, da smo večino dela opravili
  • nadaljevanje z inkrementalnimi pristopi (npr. z evolucijsko izdelavo prototipa)
izbor primernega razvojnega modela
Izbor primernega razvojnega modela
  • Pri razvoju vedno implicitno ali eksplicitno uporabljamo nek model
  • Včasih se pravi model pojavi implicitno in intuitivno, modreje pa ga je izbrati zavestno

[O tem ste sicer izvedeli vse pri Orodjih in razvoju aplikacij in drugih predmetih.]

kratkoro ni mejniki miniature milestones
Kratkoročni mejniki(Miniature milestones)
  • Uvedemo takoj v začetku ali v krizni situaciji, ne pa kar iznenada
  • Postavijo si jih lahko tudi razvijalci sami (micro-management)
  • “Razdalja” med njimi naj bo dan ali dva.
    • za tako majhna opravila lažje določimo čas dela
    • zamujeno je lažje ujeti
  • Mejnik naj bo binaren: naloga je lahko opravljena ali ne, nič vmes.
  • Mejnikov ne smemo pozabljati, sicer bodo pozabljena opravila rušila načrt
  • Stalno preverjaj, kje si: brez tega kratkoročni mejniki nimajo smisla
  • Prednosti:
    • povečajo vidljivost
    • posebej primerni v krizni situaciji
    • učinkoviti v kombinaciji z dnevnim prevajanjem in testiranjem
    • primerni za razvojne cikle, ki jih je težko nadzorovati
    • dobri za motivacijo
  • Slabosti:
    • kratkoročni mejniki so neprimerni za dolgoročno načrtovanje
oddaja del outsourcing
Oddaja del(Outsourcing)
  • Delo oddajamo z enakim razlogom, kot kruha ne pečemo sami doma (ali pač?)
  • Prednosti:
    • ponovna uporaba kupljenih komponent
    • večje število razvijalcev
    • večje izkušnje razvijalcev
  • Tveganje:
    • izguba vidljivosti
    • če nekdo drug razvija zate, te to ne reši skrbi za ta del aplikacije, temveč se tvoje skrbi le povečajo

Vedno obdrži dovolj kontrole, da po potrebi potegneš razvoj nazaj k sebi!

produktivno okolje
Produktivno okolje
  • Poprečen programer potrebuje 15 minut, da “odplava” v delo in lahko dela ure in ure, dokler ne postane lačen
  • Programer potrebuje:
    • deset kvadratnih metrov prostora
    • dva kvadratna metra mize
    • nastavljiva višina stola, monitorja...
    • možnost izklopa telefona
    • možnost izklopa sodelavcev ter drugega hrupa in motenj
    • pet metrov polic
  • Programerju pride prav tudi:
    • okno
    • tabla
    • možnost stika s sodelavci, konferenčne sobe
    • tiskalnik in kopirni stroj, pisarniški material
jeziki za hiter razvoj rapid development languages
Jeziki za hiter razvoj(Rapid Development Languages)
  • Čim višji je jezik, tem
    • hitrejši bo razvoj
    • manj bo napak
    • lažje bo spreminjati že narejeno

Slabosti:

    • (potencialno) počasnejša koda
    • neprimernost za nekatere tipe projektov
  • Dinamični jeziki so odličen pripomoček, če so uporabljani razumno in v kombinaciji s hitrejšimi jeziki.

[O tem ste že poslušali pri ORA – dinamični jeziki.]

skupina za orodja
Skupina za orodja
  • Skupina zadolžena za iskanje, testiranje, ocenjevanje in razpečevanje novih orodij
    • primerno za večje organizacije
    • lahko tudi en sam človek, ki tega niti ne počne ves čas
    • tudi če tega ni, se v skupini najde nekdo, ki to počne sam od sebe
  • Tveganja:
    • skupina mora biti na uslugo, ne pa določati standardov: razvijalec najbolj ve, kaj potrebuje, zato mu skupina lahko le svetuje
    • te skupine ne smejo sestavljati tisti, ki niso sposobni za “pravo delo”
pomanjkanje motivacije
Pomanjkanje motivacije
  • Delovni prostor
    • premalo svetlobe, mize, polic
    • hrup, stalne prekinitve
    • neprimerna strojna oprema in razvojna orodja
    • ilegalne kopije programske opreme (?!)
  • Nezaupanje vodstvu:
    • zavajanje in manipulacija
    • tehnična nevednost
    • pomanjkanje stika s podrejenimi
  • Neupoštevanje programerjev pri odločitvah, ki jih zadevajo
  • Prehudi roki
  • Pomanjkanje priznanja
  • Slabo razpoloženje v skupini[več o tem na enem prihodnjih predavanj]
slaba ekipa
Slaba ekipa
  • Četudi se s projektom mudi, je smiselno z začetkom počakati, da imajo čas pravi ljudje, ne pa postrgati vse do zadnjega
  • Neobvladljivi uslužbenci
herojstvo
Herojstvo
  • Pretirana zagnanost dolgoročno le škodi
  • Pretirane prošnje za nadure imajo negativen učinek
  • Pretirane motivacijske kampanje takisto
dodajanje ljudi v projekte ki zamujajo
Dodajanje ljudi v projekte, ki zamujajo
  • Če v projekte, ki zamujajo, dodajamo nove ljudi
    • bodo stari izgubljali čas z uvajanjem, namesto da bi delali,
    • novi sodelavci bodo delali počasi in s tem podirali načrte
    • v njihovi kodi bo veliko napak, s popravljanjem katerih bomo izgubili še več časa
ostalo
Ostalo
  • Nerealna pričakovanja in pobožne želje
  • Pomanjkanje stika z naročniki
  • Prepogoste zamenjave tehnologij
  • Zamenjava orodij sredi projekta
  • Neuporaba orodij za
    • nadzor verzij
    • oddajanje in hranjenje poročil o hroščih

[tudi o teh temah boste več izvedeli na prihodnjih predavanjih]

ad