Projektiranje in organizacija informacijskih sistemov
This presentation is the property of its rightful owner.
Sponsored Links
1 / 22

Projektiranje in organizacija informacijskih sistemov PowerPoint PPT Presentation


  • 62 Views
  • Uploaded on
  • Presentation posted in: General

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

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


Projektiranje in organizacija informacijskih sistemov

Projektiranje in organizacija informacijskih sistemov

Dobra in slaba praksa


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


Projektiranje in organizacija informacijskih sistemov

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]


  • Login