Projektiranje in organizacija informacijskih sistemov

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]