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

• 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)

• 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)

• 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

• 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)

• 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

• 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

• 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

• Stran od poslovnih lokacij

• Več sob, posebej če je sestanek več kot dvodneven

10-15 m

zapisnikar

računalnik tiskalnik

tabla s papirjem

tabla

Hrana & Pijača

uporabnikiin

voditelji

projektor

vodjaJAD

računalniškiprojektor

razvijalci in opazovalci

10

-15

m

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

• 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)

• 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)

• 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

• 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)

• Č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 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

• 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

• Č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

• 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

• Č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

• 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]