1 / 38

Development and Quality Plans

Development and Quality Plans. Manajemen Kualitas Perangkat Lunak. POLITEKNIK ELEKTRONIKA NEGERI SURABAYA - 2013. Development and Quality Plans. Development Plan and Quality Plan Objectives The Elements of The Development Plan Elements of The Quality Plan

topper
Télécharger la présentation

Development and Quality Plans

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. DevelopmentandQuality Plans ManajemenKualitasPerangkatLunak POLITEKNIK ELEKTRONIKA NEGERI SURABAYA - 2013

  2. Development and Quality Plans • DevelopmentPlanand Quality PlanObjectives • The Elements of The Development Plan • Elements of The Quality Plan • Developmentand Quality Plans for Smalland for Internal Projects • Software Development Risks and Software Risk Management

  3. DevelopmentPlan and Quality Plan Objectives

  4. TujuanRencanaPengembangandanJaminanKualitas Software Perancanaansebagaisebuahproses, memilikibeberapatujuan yang masingdiantaranyaberartimempersiapkanpondasi yang kokohuntukbeberapahalberikut: • Jadwalkegiatan development yang memimpinkesuksesandanpenyelesaiantepatwaktuterhadapsebuahproyekdanperkiraanterhadapjumlahsumberdayamanusiadanbiayanya. • Perekruktananggotatimdanalokasisumberdayauntuk development termasukkegiatanpenjadwalan, penggunaansdmmembutuhkanperkiraan

  5. TujuanRencanaPengembangandanJaminanKualitas Software (cont’d) • Memecahkanpermasalahan development • Menerapkankegiatan yang dibutuhkan SQA • Menyediakanmanajemendengan data yang diperlukanuntukpengawasanproyek

  6. ElementsofDevelopmentPlan

  7. Unsur-unsurRencanaPengembangan • Produkproyek • Interface proyek • Metodologiproyekdan tool pengembangan • Standardanpengembangan software • Pemetaanterhadapprosespengembangan • Milestone (kejadianpenting) proyek • Organisasistafproyek • Fasilitaspengembangan • Resikopengembangan • Metodepengawasan • Perkiraanbiayaproyek

  8. Unsur-unsurRencanaPengembangan(cont’d) 1. Produkproyek • Dokumenrencana yang menetapkantanggalpenyelesaian, menunjukkan item yang akandiserahkankepelanggan (deliverable). • Produksoftware (menetapkantanggalpenyelesaiandantempatinstallasi) • Pelatihan(menetapkantanggal, peserta dan tempat) 2. Interface proyek • Interface denganpaket software yang ada • Interface dengansoftware/hardware yang sedangdikerjakantim lain dalam system/project yang sama • Interface dengan hardware yang ada

  9. Unsur-unsurRencanaPengembangan(cont’d) 3. Metodologiproyekdan development tool untukditerapkanpadatiaptahapproyek 4. Standardanprosedurdari software development Sebuahdaftar (software development standartdanprosedur) yang seharusnyadisiapkanuntukditerapkandalamsebuahproyek.

  10. Unsur-unsurRencanaPengembangan(cont’d) 5. Pemetaanterhadapprosespengembangan Pemetaanprosespengembanganmelibatkanpenyediaandefinisi yang lengkapdarimasing-masingtahapanproyek. Definisiinitermasuk input dan output danrencanakegiatan yang khusus. Definisikegiatanmeliputi : • Perkiraan lama kegiatan, perkiraaninitergantungpadaproyeksebelumnya. • Rangkaianlogikapadamasing-masingkegiatan yang diperlihatkan, termasukdeskripsidariketergantungankegiatansebelumnya yang harusdilengkapi. • Tipedarisumberdayaprofesional yang diperlukandanperkiraanbagaimanasumberdayainidiperlukanuntukmasing-masingkegiatan.

  11. Unsur-unsurRencanaPengembangan(cont’d) 6. Milestone (kejadianpenting) proyek Untukmasing-masingkegiatanpenting, termasukwaktudanprodukproyek (kodedandokumentasi) yang didefinisikan. 7. Organisasistafproyek • Strukturorganisasi • Kebutuhanprofesional • Jumlahanggotatim yang diperlukan • Namadariketuatimdananggota

  12. Unsur-unsurRencanaPengembangan(cont’d) 8. Fasilitaspengembangan Fasilitaspengembangandiperlukanmeliputi : hardware, software dan tool pengembangan hardware, ruangkantordan item yang lain. Untukmasing-masingfasilitas, periodewaktu yang diperlukanharusditunjukkandalamtabelwaktu. • 9. Resikopengembangan • Celahteknologi • Kekuranganstaf • Ketergantunganantarelemenorganisasi.

  13. Unsur-unsurRencanaPengembangan(cont’d) 10. Metodepengawasan Untukmengawasipenerapanproyek, manajerproyekdanmanajemenmenerapkanrangkaiankegiatanpengawasansaatmenyiapkanlaporan progress danrapatkoordinasi. 11. Perkiraanbiayaproyek Perkiraanbiayaproyekdidasarkanpadaperkiraanbiaya proposal, diikutioleh review menyeluruhdarirelevansiberdasarkanperkiraansumberdayamanusia, negosiasikontrakdengansubkontraktor danpemasok

  14. ElementsofQualityPlan

  15. Unsur-UnsurPerencanaanKualitas Semuaataubeberapa item berikuttergantungpadaproyek, elemendarirencanakualitasproyektersebutantara lain : Daftartujuankualitas (Quality goals) Perencanaanpemeriksaankegiatan (Planned review Activities) Perencanaanujicoba software (Planned software tests) Perencanaanujicobauntukpengembang software eksternal (Planned acceptance tests for externally developed software) Pengelolaanprosedurdanpengelolaan tool (Configuration management)

  16. Unsur-UnsurPerencanaanKualitas (cont’d) 1. Daftartujuankualitas (Quality goals) Istilah quality goals mengacupadapersyaratankualitaspadasistemperangkatlunak yang dikembangkansecarasubstantif. Ukurankuantitatifbiasanyalebihdipelihdaripadaukurankualitatifketikamemilihtujuandarikualitas, karenaukurankuantitaifmemberikanpengembang/development untukmenilaisecaraobyektifpeforma software selama proses pengembangandanpengujiansistem.

  17. Unsur-UnsurPerencanaanKualitas (cont’d) 2. Perencanaanpemeriksaankegiatan (Planned review Activities) Perencanaankualitasharusmenyediakandaftarlengkapdarisemuarencana review kegiatan : TinjauanDesain (Design Review), InspeksiDesain (Design Inspections), Inspeksipada Program/coding (Code Inspections) dsb. Sebelummelakukanperencanaanpemeriksaankegiatanadabeberapalangkah yang harusdilakukan : Ruanglingkupkegiatanpemeriksaan Jeniskegiatanpemeriksaan Jadwalkegiatanpemeriksaan Prosedurspesifikygakanditerapkan Siapa yang bertanggungjawabuntukkegiatanpemeriksaan

  18. Unsur-UnsurPerencanaanKualitas (cont’d) 2. Perencanaanpemeriksaankegiatan (Planned review Activities) Perencanaankualitasharusmenyediakandaftarlengkapdarisemuarencana review kegiatan : TinjauanDesain (Design Review), InspeksiDesain (Design Inspections), Inspeksipada Program/coding (Code Inspections) dsb. Sebelummelakukanperencanaanpemeriksaankegiatanadabeberapalangkah yang harusdilakukan : Ruanglingkupkegiatanpemeriksaan Jeniskegiatanpemeriksaan Jadwalkegiatanpemeriksaan Prosedurspesifikygakanditerapkan Siapa yang bertanggungjawabuntukkegiatanpemeriksaan

  19. Unsur-UnsurPerencanaanKualitas (cont’d) 3. Perencanaanujicoba software (Planned software tests) Perencanaankualitasharusmenyediakandaftarlengkapdarisemuaperencanaanpadaujicoba software. Parameter yang harusadapadasetiaptesadalah : Pengujian unit, integrasi atau keseluruhansistem yang akan diuji Jenis kegiatan pengujian yang akan dilakukan, termasuk spesifikasipengetesanterkomputerisasipadaperangkatlunak. Jadwal test yang direncanakan Prosedur spesifik yang akan diterapkan Siapa yang bertanggung jawab untuk melaksanakan tes.

  20. Unsur-UnsurPerencanaanKualitas (cont’d) 4. Perencanaanujicobauntukpengembang software eksternal (Planned acceptance tests for externally developed software) Daftarlengkapdariperencanaanujicobauntukpengembangsotwareeksternalharusdisediakan di dalamperencanaankualitas. Item yang harusadaadalah : Perangkat lunak yang dibeli Software yang dikembangkan oleh subkontraktor Software yang didapatkandaripelanggan

  21. Unsur-UnsurPerencanaanKualitas (cont’d) 5. Pengelolaanprosedurdanpengelolaan tool (Configuration management) Rencana kualitas harus menentukanpengelolaan tool danprosedur, termasuk prosedur perubahan kontrol dimaksudkan untukditerapkan di seluruh proyek.

  22. Development and Quality Plansfor Small and for Internal Projects

  23. RencanaPengembangandanRencanaKualitasuntukProyek Kecil danProyek Internal Proyek Kecil Prosedurperencanaanpengembangandanmutu yang berlakuuntukproyek-proyekbesartidakdapatsecaraotomatisditerapkanuntukproyek-proyekkecil. Makadariituprosedurkhususdiperlukan. Prosedurinimenentukanbagaimanamemperlakukanproyektersebutdihubungkandenganrencana: Kasus / situasidimanatidakdiperlukannyarencanapembangunanmaupunrencanakualitas Kasus / situasidimanakeputusanuntukmenyiapkanrencanadiserahkankepadakebijaksanaanpemimpinproyek. Kasus / situasidimanarencanapembangunandankualitasadalahwajib.

  24. RencanaPengembangandanRencanaKualitasuntukProyek Kecil danProyek Internal (cont’d) • Unsurdaripengembangandanperencaanaankualitasuntukproyekkecil : • Perencanaanpengembangan : • Produkproyek, mengindikasikanhasil yang diserahkan “deliverables” • Proyek benchmarks • Resikopengembangan • Perkiraanbiayaproyek • PerencanaanKualitas : • Tujuandarikualitas

  25. RencanaPengembangandanRencanaKualitasuntukProyek Kecil danProyek Internal (cont’d) Beberapakeuntunganuntukproyek-proyekkecil yang direncanakandibandingkandenganproyek-proyek yang tidakterencanadapatdiidentifikasisebagaiberikut: Sebuahpemahaman yang lebihkomprehensifdanmenyeluruhterhadaptugasdapatdicapai. Tanggungjawab yang lebihbesaruntukmemenuhikewajiban yang ditugaskan. Hal inimenjadilebihmudahbagimanajemendanpelangganuntukberbagipengawasanproyekdanuntukmengidentifikasipenundaantakterdugasejakdini. Pemahamanlebihbaik yang berkaitandenganpersyaratandanjadwaldapatdicapaiantara developer dengan customer.

  26. RencanaPengembangandanRencanaKualitasuntukProyek Kecil danProyek Internal (cont’d) Proyek Internal Proyek internal merupakanproyek yang digunakanuntuksebuahdepartemendalamorganisasiitusendiri. Dan nantinyaakandigunakankeseluruhperusahaan. KeuntunganBagi Tim Developer : Mencegahanggaran yang berlebihan. Mencegahkegagalanproyekakibatpenundaan. Mencegahkehilanganpasarsepertijatuhnyareputasi KeuntunganBagi Customer : Deviasilebihkecil Pengawasanlebihbaikterhadapprosespengembangan. Resikolebihkecilakibatketerlambatan internal.

  27. RencanaPengembangandanRencanaKualitasuntukProyek Kecil danProyek Internal (cont’d) KeuntunganBagiOrganisasi : Mengurangiresikokehilanganpasar. Mengurangiresikoatasketerlambatan supply, mengurangipenaltiterhadapkontrak. Mengurangiresikodarikegagalanreputasi. Mengurangiresikopermintaananggarandanauntukpemasukan(supply tambahan).

  28. Software Development Risk and Software Risk Management

  29. In modern Software Project, security and risk management are not just something one might do if there are time and resources. Security has become an important part of the end product. So, risk management must be introduced at the beginning of the project, and must be evaluated and assessed during the whole development cycle

  30. Software Development Risk Methodologies for identification of software risk items have been offered by Boehm (1991), Keilet al., (1998), Ropponen and Lyytinen (2000), Barki et al., (1993) and IEEE (2001). Karolak (1996) and Jones (1994) have broadened the scope of software risk items to include strategic risk, such as marketing risks and financial risks.

  31. Software Development Risk (cont’d) Ropponen and Lyytinen (2000) have classified software risk items into; Scheduling and timing risks System functionality risks Subcontracting risks Requirement management risks Resource usage and performance risks Personnel management risks.

  32. Software Development Risk (cont’d) Meanwhile, Boehm and Ross (1989) suggest a list of the 10 major software risk items; Personnel shortfalls Unrealistic schedules and budgets Developing wrong software functions Developing wrong user interface Gold plating Continuing stream of requirement changes Shortfalls in externally furnished components Shortfalls in externally performed tasks Real-time performance shortfalls Straining computer science capabilities

  33. Risk Management Activities and Measures RMAs are to prevent software risks, to achieve early identification of software risk items, and to resolve them. Boehm and Ross (1989), Boehm (1991), Ropponen and Lyytinen (2000), and Karolak (1996), among others, have suggested a wide variety of risk management actions

  34. Risk Management Activities and Measures (cont’d) risk management actions can be grouped into the following classes: Internal risk management actions, applied within the software developing organization. Subcontracting risk management actions, dealing with the relationship between the software developer and his subcontractors and suppliers. Customer risk management actions, dealing with the relationship between the software developer and the customer.

  35. Risk Management Activities and Measures (cont’d) When planning RMA, one should note that; Some RMAs can prevent, identify or resolve SRIs of various types. Some SRIs can be treated by several RMAs. The efficiency of an RMA varies significantly with different projects and in different environments.

  36. The Risk Management Process It combines planning activities, implementation activities and monitoring activities. The aim; to initiate those risk management actions that can respond to the software risks identified and evaluated earlier.

  37. The Risk Management Process (cont’d) The RMA workflow,

More Related