1 / 44

Tarkvaratehnika

Tarkvaratehnika. Tere!. Tarkvaratehnika Kaspar Loog. Selles loengus…. Koskmudel – teooria ja praktika “Tavapärase” tarkvaraarenduse rusikareeglid Rational Unified Process - sissejuhatus. Miks me siin istume?. Miks me siin istume?. Chaos 1995

mihaly
Download Presentation

Tarkvaratehnika

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

  2. Tere! Tarkvaratehnika Kaspar Loog

  3. Selles loengus… • Koskmudel – teooria ja praktika • “Tavapärase” tarkvaraarenduse rusikareeglid • Rational Unified Process - sissejuhatus

  4. Miks me siin istume?

  5. Miks me siin istume? • Chaos 1995 • Aastal 1995 kulutasid USA firmad 81 miljardit dollarit tarkvaraprojektidele, mis katkestati • 31% projektidest katkestati enne lõpetamist • 53% projektidest läksid tähtajast üle rohkem kui poole võrra • Vaid 9% tarkvaraprojektidest, mis tehti suurfirmadele püsisid aja- ja rahaeelarve raames • Olukord ei ole 7 aastaga eriti muutunud

  6. Koskmudel – ajaloo prügikast?

  7. Koskmudeli teooria I Analüüs Kodeerimine

  8. Koskmudeli teooria suurte süsteemide korral

  9. Vajalikud täiendused koskmudeli teooriasse (Winston Royce) • Täielik programmi ülesehituse kirjeldus enne analüüsi ja kodeerimist • Ajakohase ja täieliku dokumentatsiooni haldamine • Kui võimalik, teha kõike 2x • Testimise planeerimine, kontrollimine ja jälgimine • Kliendi haaramine arendustegevusse

  10. Täielik programmi ülesehituse kirjeldus enne analüüsi ja kodeerimist

  11. Ajakohase ja täieliku dokumentatsiooni haldamine

  12. Kui võimalik, teha kõike 2x

  13. Testimise planeerimine, kontrollimine ja jälgimine

  14. Kliendi haaramine arendustegevusse

  15. Praktika koskmudeli rakendamisel

  16. Mis on koskmudeli rakendamisel viga? • Integratsiooni venimine ja hiline disaini ümbertegemine • Hiline riskide maandamine • Nõuetest lähtuv funktsionaalne tükeldamine • Vastuolulised suhted tellijate ja teostajate vahel • Liigne rõhk dokumentidel ja ülevaatuskoosolekutel

  17. Valmimisgraafik“tavapärasel” tarkvaraprojektil Integratsioonialgus 100% Disainimuutmine Arenduskäik (% kodeeritud) Tegelik tähtaeg Lõpptähtaeg

  18. Riskigraafik “tavapärasel” tarkvaraprojektil Nõuded Disain/kodeerimine Integratsioon Testimine Riskide vähendamine Riskide haldamine Riskide realiseerumise tõenäosus Riskide tükeldamine Riskide avastamine Projekti elutsükkel

  19. Barry Boehm Mõned rusikareeglid“tavapärasest” tarkvaraarendusest

  20. 1EEK vs 100EEK Tarkvaraprobleemi lahendamine varajastes disainietappides on on 100 korda odavam kui pärast tarkvara kliendini toimetamist

  21. 100% => 75% Tarkvaraprojekti ajagraafikut saab tihendada maksimaalselt 25% võrra (Kolm naist ei sünnita ühte last kolme kuuga)

  22. 1EEK => 2EEK extra Iga arendusele kuluv kroon tähendab, et hooldusele kulub 2 krooni

  23. Kulud = f(x) Tarkvara arendamise ja hoolduse kulud on funktsioon koodiridade arvust

  24. Inimesed on olulised Inimestevahelised erinevused on kõige suurem produktiivsuse mõjutaja

  25. Tarkvara maksab rohkem kui raudvara 1955 – 15:85 1985 – 85:15 2002 - ?

  26. 15% programmeerimist Ülejäänu on programmeerimist toetav ja abistav töö

  27. Mida rohkem seda rohkem Tarkvarasüsteemi koodirida maksab 3x rohkem kui üksiku programmi koodirida “Diseconomy of scale”

  28. 60% tarkvara vigadest on leitavad inimliku läbivaatuse korras

  29. 80% tootlikkusest tuleb 20% tegijatelt Pareto printsiip

  30. Mis edasi?

  31. Rational Unified Process

  32. RUP - tarkvaraarendusmetoodika • Protsess e. metoodika (process) Osaliselt järjestatud tegevused mingi eesmärgi saavutamiseks • Tarkvaraarendusprotsess(software development process) Tarkvaratoote valmistamiseks vajalikud tegevused

  33. RUP kui spiraalne metoodika

  34. RUP-i ‘parimad tavad’ • Arenda iteratiivselt • Halda nõudeid • Kasuta komponentarhitektuuri • Modelleeri visuaalselt • Kontrolli pidevalt kvaliteeti • Halda muudatusi

  35. Iteratiivsus a la Rational

  36. Iteratsioon ja koskmudel

  37. Halda nõudeid • Nõuete haldamine on süstemaatiline lähenemine pidevalt muutuvate nõuete leidmiseks, dokumenteerimiseks, organiseerimiseks ja jälgimiseks • Nõue on ‘oskus’ või ‘olukord’, millega tarkvara peab hakkama saama

  38. Komponentarhitektuuri kasutamine Rakendusspetsiifiline Valdkonnaspetsiifiline Middleware Süsteemitarkvara

  39. RUP ja UML • UML on skemaatiline keel, mida soovitatakse kasutada RUP-I rakendamisel

  40. UML aitab üldistada • UML aitab süsteemi üldisemalt vaadelda Alamsüsteemid Klassid Kood

  41. Pidev kvaliteedikontroll • Mis on kvaliteet? • "...the characteristic of having demonstrated the achievement of producing a product that meets or exceeds agreed-on requirements—as measured by agreed-on measures and criteria—and that is produced by an agreed-on process."

  42. Pidev kvaliteedikontroll • Kvaliteeti tuleb kontrollida pidevalt, mitte protsessi lõpus • Kui kvaliteeti kontrollida protsessi lõpus, on olemas oht, et toode tunnistatakse praagiks • Pidev kvaliteedikontroll annab ka kõigile osapooltele kindlustunnet hetkeseisu osas

  43. Muudatuste haldamine

  44. Järgmises loengus… • Mõisted • Töövood, faasid • Kuidas projekti tükeldada • Kuidas projekti tükke nimetada

More Related