Vajad kellegagi rääkida?
Küsi julgelt abi LasteAbi
Logi sisse

Projektiplaani seisundiaruanne (1)

1 Hindamata
Punktid
Tallinna Tehnikaülikool
Informaatikainstituut
Projektiplaani seisundiaruanne
2. iseseisev töö õppeaines ”Infosüsteemi projekti juhtimine”
Autor: Eero Ringmäe
010636IAPM
Juhendaja : Karin Rava
Tallinn 2006
Sisukord
1. Projektist 3
1.1.1 Projekti üldine taust 3
1.1.2 Projekti olukord seisundiaruande esitamise tähtajaks 3
2. Projekti korrigeeritud rollid 3
3. Valminud tulemused ja tööde seis 5
1.1.3 Alustatud tegevused 5
1.1.4 Plaanitud ja tegelikult saadud tulemused 5
4. Tekkinud probleemide kirjeldused, lahendused, mõjud 6
1.1.5 Ülekoormatud analüütikud 6
1.1.6 Alliksüsteemi analüüsi venimine 6
1.1.7 Lõppkasutaja aruandluskeskkondade valik 6
5. Eeldused projekti lõpetamiseks 6
1.1.8 Analüüsifaas 6
1.1.9 Realiseerimisfaas 7
1.1.10 Juurutusfaas 7




  • Projektist


  • Projekti üldine taust


    Käesolev projekt hõlmab kolmes balti riigis tegutseva finantsettevõtte müügiaruandluse keskkonna uuendamist tarkvaraarendusteenust pakkuva ettevõtte poolt. Tegemist on suuremahulise projekti esimene iteratsiooniga. Projekti eesmärgiks on organisatsiooni keskse andmelao pealt müügiaruandluseks vajaliku andmemudeli loomine ning lõppkasutaja tööriista juurutamine .
    Aruandluse uuendamise projekti põhjuseks oli finantsettevõtte liikumine tsentraalse juhtimise poole ning vajadus seni võrdlemisi omapäi tegutsenud allüksuste aruandlussüsteemid ühendada. Seni on erinevates üksustes kasutusel olnud kuni seitse erinevat lõppkasutaja aruandlustööriista korraga ning üksuste lõikes ei ole ühtset arusaamist ka kõige põhilisematest ärimõistetest nagu 'toode', 'intress' või ' klient '. Sellest tulenevalt on kesksete juhtimisotsuste tegemiseks vajaliku informatsiooni kvaliteet sageli ebarahuldav.
    Müügiaruandluse süsteemi juurutamine on sillapeaks, mille käigus peab loodama sobiv arhitektuurne lahendus ka mitmete teiste aruandlusvaldkondade tsentraliseerimiseks ( finantsaruandlus , kasumlikkuse aruandlus ). Kogu projekti ajakavaks on pea kaks aastat 2006 a. augustist – 2008 a. kolmanda kvartalini. Müügiaruandluse süsteemi loomise esialgseks ajakavaks on august 2006 – veebruar 2007.
  • Projekti olukord seisundiaruande esitamise tähtajaks


    Projekt algas reaalselt 2006. aasta oktoobri teisel nädalal. Praeguseks on tööd kestnud neli nädalat. Analüütikud on jõudnud läbi viia intervjuud kõigi ettevõtte osakondade ärikasutate esindajatega. Kuna osutus, et kaks analüütikut olid intervjuude tiheda ajagraafiku tõttu ülekoormatud, otsustas täitja projekti kaasata veel ühe analüütiku.
    Alliksüsteemide analüüsi lõpetamine venis 3 päeva (lisandus 25% tööde mahust). Tööd lõpetati 25.10.2006.
    Kõige probleemsemaks osutus lõppkasutaja tarkvaratoodete valik. Nimelt ei olnud mitmetel lõppkasutajatel aega kõigi tarkvaratoodete demonstratsioone vaatama tulla ja seetõttu seati ettevõttesse üles kahe eelistatuma toote testkeskkonnad, milles kasutajad said endale sobival ajal ise eksperimenteerida. Seetõttu lükkub esialgselt 10. novembriks 2006 plaanitud lõppkasutaja tarkvara valik kuni nädala võrra edasi.
  • Projekti korrigeeritud rollid


    Projektis osalevad kolm ettevõtet – klient, arendusteenuse pakkuja ja aruandlustarkvara müüja. Allpool on toodud planeeritud rollid ettevõtete kaupa. Toodud rollide esindajad ei pruugi olla projektiga algusest lõpuni seotud, üks inimene võib teatud juhtudel täita mitut rolli (analüütik ja arhitekt , arhitekt ja arendaja ) Võib juhtuda, et rolli täitmiseks pole vaja inimest täiskoormusega.
    Punasega on märgitud rollid, mille reaalne ressursivajadus erines plaanitust.
    Intervjueerimist planeerides ja läbi viies selgus, et vajalikku informatsiooni kättesaamiseks piisab kolmest kasutajast valdkonna kohta – valdkonnajuhist ja kahest kogenuimast analüütikust. Ka juhtkonnast intervjueeriti väiksemat hulka inimesi, kuna plaanimisel selgus, et mitmete inimeste infovajadused kattuvad.
    Rollid klientorganisatsioonis:
    • projektijuht , kes vastutab projekti tähtaegade, eelarvestamise jms eest– 1in
    • arhitekt, kes konsulteerib süsteemi väljatöötamisel – 1in
    • lõppkasutajad, kes defineerivad nõuded ning võtavad süsteemi vastu või lükkavad tagasi – 12in (prognoos 20-30in)
    • juhtkond , kes osalevad ärinõuete kirjeldamisel – 3in (prognoos 5in)

    Rollid tarkvaarendusteenust pakkuvas ettevõttes:
    • projektijuht, kes vastutab tähtaegade, ajahinnangute, projektisiseste rollide jaotamise jms eest – 1in
    • arhitekt, kes töötab välja süsteemi tehnilise lahenduse põhiprintsiibid – 1in
    • analüütik-intervjueerija, kes kireldab ärinõuded ja teostab andmeallikate analüüsi – 3in (prognoos 2in)
    • arendaja, kes realiseerivad süsteemi füüsiliselt – 3in

    Välised rollid
    • Aruandluskeskkonda tarniv ettevõte – müügimees, kes tutvustab võimalikke tooteid (1in)
    • Aruandluskeskkonda tarniv ettevõte – juurutaja, kes installeerib süsteemi kliendi ettevõttes ning pakub edasist tuge (1-2in)
    • Aruandluskeskkonda tarniv ettevõte – koolitaja , kes viib kasutajad kurssi süsteemi omadustega (1-2in)

  • Valminud tulemused ja tööde seis


  • Alustatud tegevused


    Kõik tegevused kuuluvad analüüsietappi. Analüüsietapi lõpukuupäevaks on planeeritud 16.11.2006. Mahud on antud tööpäevades. Üheks tööpäevaks loetakse 8h ühe inimese tööd.
    Punasega on märgitud planeeritud lõpukuupäevad.
    Tegevus
    Maht tööpäevades
    Algus
    Lõpp
    Liisinguvaldkonna intervjuud
    3
    16.10.2006
    18.10.2006
    Väärtpaberivaldkonna intervjuud
    3
    18.10.2006
    20.10.2006
    Kaarditehingute intevjuud
    3
    23.10.2006
    25.10.2006
    Juhtkonna intervjuud
    2.5
    09.10.2006
    11.10.2006
    Laenuvaldkonna intervjuud
    3
    25.10.2006
    27.10.2006
    Alliksüsteemi analüüs
    13
    09.10.2006
    25.10.2006
    Ärinõuete kinnitamise seminarid
    9
    03.11.2006
    15.11.2006
    Ärinõuete konsolideerimine
    17
    11.10.2006
    03.11.2006
    Aruandlustarkvara kriteeriumite väljatöötamine
    6
    24.10.2006
    31.10.2006
    Business Objects demo
    1
    01.11.2006
    01.11.2006
    ProClarity demo
    1
    02.11.2006
    02.11.2006
    WebFocus demo
    1
    03.11.2006
    03.11.2006
    Demokeskkonnad kasutajatele
    5
    06.11.2006
    10.11.2006
  • Plaanitud ja tegelikult saadud tulemused


    Plaanitud tulemus
    Seisund
    Intervjueerimisdokumentatsioon
    OK (27.10.2006)
    Alliksüsteemide analüüsidokumentatsioon
    OK (25.10.2006, kulu 25% planeeritust enam)
    Konsolideeritud ärinõuete dokumentatsioon
    OK (03.11.2006)
    Lõppkasutaja tarkvara nõuete spetsifikatsioon
    OK (31.10.2006)
    Lõppkasutaja tarkvara valik
    NOK, lisandus 5 päeva iseseisva demokeskkonna ülesseadmiseks.
  • Tekkinud probleemide kirjeldused, lahendused, mõjud


  • Ülekoormatud analüütikud


    Probleemi kirjeldus: esialgse projektiplaani järgi pidi teenusepakkuja tooma projekti kaks analüütikut. Kuna aga analüüsietapis oli intervjueerimine ja lõppkasutaja tarkvara valimine planeeritud samale perioodile, olid mõlemad analüütikud tugevalt ülekoormatud.
    Lahendus: teenusepakkuja tõi lõppkasutaja tarkvara valikule abistama kolmanda analüütiku.
  • Alliksüsteemi analüüsi venimine


    Probleemi kirjeldus: olemasolevate süsteemide viletsa dokumenteerituse tõttu ei jõutud alliksüsteemi analüüsiga tähtajaks valmis.
    Lahendus: töid pikendati 3 päeva võrra, ehk selle taski jaoks 25% võrra. Kliendiga jõuti eelarve suurendamise osas kokkuleppele.
    Mõju: kuna arhitektil oli selles projektis osakoormus ning analüüsietapil selle rolli esindajal rohkem ülesandeid polnud, siis projekti lõpptähtajale tööde pikenemine mõju ei avalda.
  • Lõppkasutaja aruandluskeskkondade valik


    Probleemi kirjeldus: kuna mitmetel ärikasutajatel polnud võimalik mõnda aruandlustarkvara paketti tutvustaval seminaril kohal olla ning paljud kasutajad arvasid, et demonstratsioonidelt ei saadud piisavalt infot, ei olnud kasutajad nõus olemasoleva info alusel toodete vahel valikut tegema.
    Lahendus: kuna kliendi näol on tegemist suure ettevõttega, olid kaks aruandlustoodete müüjat kolmest valmis omal kulul nädalaks üles seadma demonstratsioonkeskkonnad, mida kasutajad oma PC-de tagant endale sobival hetkel katsetada said.
    Mõju: aruandluskeskkonna valik lükkus nädala võrra edasi. Kuna ärinõuete kinnitamine lõpeb plaani järgi 2 nädalat kauem kui aruandluskeskkonna valik pidi kinnitatud olema, siis analüüsietapi lõpptähtaega venimine ei pikenda .
  • Eeldused projekti lõpetamiseks


  • Analüüsifaas


    Tööülesanne
    Oodatav tulem
    Tähtaeg
    Ärinõuete konsolideerimine
    Ärinõuete dokumentatsioon
    21.11.2006
    Ärinõuete kinnitamise seminarid
    Dokumentatsioon vastu võetud
    08.11.2006
    Aruandluskeskkonna valimine
    Tellija poolt kinnitatud valik
    13.11.2006
  • Realiseerimisfaas


    Tööülesanne
    Oodatav tulem
    Tähtaeg
    Füüsilise andmemudeli väljatöötamine (aluseks alliksüsteemide analüüs)
    Realiseeritud füüsiline andmemudel
    27.11.2006
    Andmelaadimiste (Extract Transform Load ) realisatsioon (eraldi jagatav nelja valdkonna lõikes)
    Toimivad andmelaadimisprotsessid
    27.12.2006
    Andmekvaliteedi valideerimine
    Andmekvaliteet vastab intervjueerimisel paika pandud kriteeriumitele
    19.01.2007
    Aruandluskeskkonna sidumine andmemudeliga
    Andmebaas aruandluskeskkonna kaudu kasutatav
    21.12.2006
  • Juurutusfaas


    Tööülesanne
    Oodatav tulem
    Tähtaeg
    Andmebaasikihi toodangukeskkonna ülesseadmine
    Andmebaas ning andmelaadimisprotsessid installeeritud.
    26.01.2007
    Aruandluskeskonna ülesseadmine
    Aruandluskeskkonna server ja klientrakendused installeeritud
    06.02.2007
    Aruandluskeskkonna koolitus
    Kõigil ärikasutajatel läbitud vähemalt neli akadeemilist tundi koolitust.
    27.02.2007
    7
  • Vasakule Paremale
    Projektiplaani seisundiaruanne #1 Projektiplaani seisundiaruanne #2 Projektiplaani seisundiaruanne #3 Projektiplaani seisundiaruanne #4 Projektiplaani seisundiaruanne #5 Projektiplaani seisundiaruanne #6 Projektiplaani seisundiaruanne #7
    Punktid 50 punkti Autor soovib selle materjali allalaadimise eest saada 50 punkti.
    Leheküljed ~ 7 lehte Lehekülgede arv dokumendis
    Aeg2008-01-12 Kuupäev, millal dokument üles laeti
    Allalaadimisi 68 laadimist Kokku alla laetud
    Kommentaarid 1 arvamus Teiste kasutajate poolt lisatud kommentaarid
    Autor Rain Ungert Õppematerjali autor
    Teine iseseisev töö. Infosüsteemi projekti juhtimine

    Sarnased õppematerjalid

    Projektiplaani lõpuaruanne
    8
    doc

    Projektiplaani lõpuaruanne

    Tallinna Tehnikaülikool Informaatikainstituut Projektiplaani lõpuaruanne 3. iseseisev töö õppeaines "Infosüsteemi projekti juhtimine" Autor: Eero Ringmäe 010636IAPM Juhendaja: Karin Rava Tallinn 2006 Sisukord 1. Projektist.......................................................................................................................... 3 1.1

    Infosüsteemi projekti juhtimine
    Projektiplaani spetsifikatsioon
    6
    doc

    Projektiplaani spetsifikatsioon

    Tallinna Tehnikaülikool Informaatikainstituut Projektiplaani spetsifikatsioon 1. iseseisev töö õppeaines "Infosüsteemi projekti juhtimine" Autor: Eero Ringmäe 010636IAPM Juhendaja: Karin Rava Tallinn 2006 Sisukord 1. Taust.................................................................................................................................3 2

    Infosüsteemi projekti juhtimine
    Projekti kui infosüsteemi spetsifikatsioon
    9
    doc

    Projekti kui infosüsteemi spetsifikatsioon

    ......................................................................................................8 4. Andmevaade.................................................................................................................... 8 5. Ajaline vaade................................................................................................................... 9 2 1. Projektist 1.1.1 Projekti üldine taust Käesolev projekt hõlmas kolmes balti riigis tegutseva finantsettevõtte müügiaruandluse keskkonna uuendamist. Projekti eesmärgiks oli organisatsiooni keskse andmelao pealt müügiaruandluseks vajaliku andmemudeli loomine ning lõppkasutaja tööriista juurutamine. Projekti käigus loodi ettevõttele müügiaruandluse infotehnoloogiline arhitektuur ning realiseeriti nelja olulise ärivaldkonna aruandlus. Tegemist oli suuremahulise ärianalüüsi tarkvara ehitamise projekti esimene iteratsiooniga

    Infosüsteemi projekti juhtimine
    Tarkvaratehnika 2016 2017 eksami materjal
    138
    docx

    Tarkvaratehnika 2016/2017 eksami materjal

    läbirääkimised. o Süsteemi nõuded  Millised on süsteemi täpsed/detailsed nõuded, millised on konkreetsed funktsionaalsused, ning samuti ka piirangud, mis lepitakse kokku vastavalt lepingule. Mida peab funktsionaalselt süsteem tegema, et kasutaja saaks seda kasutada. See toimub siis kui antud projekt vms on võidetud.  Mis on nõuete analüüs? o Protsess, mis on mõeldud saavutamaks teenuseid, mida klient soovib süsteemist saada. Süsteemi poolt kirjeldame, mida süsteem peab tegema, et kasutaja mingeid vajadusi rahuldada, sinna alla kuuluvad ka piirangud. See on see protsess, kuidas see toimib ja kuidas me neid kirjeldame.  Miks on nõuete analüüs oluline?

    Tarkvaratehnika
    Projektijuhtimine konspekt
    32
    doc

    Projektijuhtimine konspekt

    PROJEKTITÖÖ Loengukonspekt SISUKORD SISSEJUHATUS................................................................................................................. 3 1. PROJEKTITÖÖ PÕHIALUSED.....................................................................................4 1.1 Projekt ja projekti etapid............................................................................................4 1.2 Projektiorganisatsioon ja projektid põhiorganisatsioonis.......................................... 7 1.3 Projektide liigid..........................................................................................................8 2. PROJEKTI MÄÄRATLEMINE......................................................................................9 3

    Raamatupidamise alused
    Projektipersonali juhtimine konspekt
    101
    pdf

    Projektipersonali juhtimine konspekt

    kriteeriume (aeg, kulud ja tulemuslikkus) erinevalt. Projektid, mis puudutavad organisatsiooni tervikuna, inimlike või poliitilisi aspekte toovad tavaliselt esile väga tundlike teemasid. Kuidas projektimeeskond saab hakkama nende valdkondadega määrab projekti tulemuse. Kolmas oluline sarnasus on, et projektid toimuvad mingis taustsüsteemis. Inimesed algatavad projekti kuna soovitakse midagi muuta ­ tavaliselt mingit osa keskkonnast, kus töötatakse. Projekt leiab aset keskkonnas, mida selle propageerijad soovivad muuta. Projektijuht püüdes mõjutada inimesi tegutseb ka keskkonnas ja mõjutab nii omakorda projekti kulgu. Kokkuvõttes, keskkonna elemendid mõjutavad üksteist, mis omakorda tekitavad muutusi keskkonnas. Mille poolest erineb tavajuhtimine projekti juhtimisest? Kuigi muutused ettevõtluskeskkonnas näitavad trendi, et juhtimine peab kogu aeg muutuma ja olema oma

    Organisatsioon ja juhtimine
    Tarkvaratehnika kordamisküsimused
    210
    pdf

    Tarkvaratehnika kordamisküsimused

    TARKVARATEHNIKA KORDAMISKÜSIMUSED     1. Mis on tarkvaratehnika?  Software engineering    ! ​“Engineers Australia” definitsioon: ​ Tarkvaratehnika ​on tiimide poolt rakendatav distsipliin  tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara mis rahuldab  kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel.    IEEE definitsioon: Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava  lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see  tähendab, inseneriteaduste rakendamine tarkvarale.     Tarkvaraarendus ​ on nõrgem termin, kus tingimata ei kasutata protsesse, tööriistu,  standardeid, jne. Tarkvaraarendus on progemine + konfigursatsiooni haldus.    Tarkvaratehnika ei ole ainult programmi kirjutamine, vaid teemad hõlmavad ka kvaliteeti,  ajakavasid,

    Tarkvaratehnika
    Lõpueksam-2008 õppekava alusel Majanduse alused
    105
    doc

    Lõpueksam: 2008 õppekava alusel Majanduse alused

    Majanduse alused 1. Võimaliku tootmise piir VTP on kahe kauba tootmiskombinatsioonide jada, mis saadakse ühiskonna tootlikke ressursse omavahel kombineerides. Pareto-efektiivsuse kriteerium väidab, et kõik punktid võimaliku tootmise piiril on efektiivsed ning asudes ühes neist punktidest saab ühe hüvise tootmise suurendamiseks ressursse ümber jaotada vaid teise hüvise tootmise vähendamise arvel. Kui ressursse tuleb juurde või nende kvaliteet paraneb, nihkub VTP pikaajaliselt majanduskasvu tõttu koordinaattelgede nullpunktist kaugemale. 2. Alternatiivkulu printsiip See tähendab, et mida enam soovitakse tarbida teist hüvist, seda enam tuleb esimese hüvise tarbimist piirata. Saamatajäänud tulu parimast alternatiivsest kasutamata jäänud võimalusest. 3. Nõudmise üldine seadus- nõudlusfunktsioon ja selle nihked Nõudlusseaduse kohaselt: Muude tingimuste samaks jäädes, mida kõrgem on hind, seda väiksem on nõutav kogus. 4. Turutasakaal- tasakaaluh

    Majanduse alused




    Kommentaarid (1)

    kucomon profiilipilt
    16:56 15-10-2017



    Sellel veebilehel kasutatakse küpsiseid. Kasutamist jätkates nõustute küpsiste ja veebilehe üldtingimustega Nõustun