1 / 22

Projektiranje in organizacija informacijskih sistemov

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...

tacy
Download Presentation

Projektiranje in organizacija informacijskih sistemov

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Projektiranje in organizacija informacijskih sistemov Dobra in slaba praksa

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. Skupni razvoj aplikacij (JAD):Prostor • Stran od poslovnih lokacij • Več sob, posebej če je sestanek več kot dvodneven

  10. 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

  11. 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)

  12. 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.]

  13. 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

  14. 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!

  15. 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

  16. 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.]

  17. 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”

  18. 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]

  19. 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

  20. Herojstvo • Pretirana zagnanost dolgoročno le škodi • Pretirane prošnje za nadure imajo negativen učinek • Pretirane motivacijske kampanje takisto

  21. 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

  22. 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]

More Related