PERMASALAHAN
Para pakar software engineering (rekayasa perangkat lunak) sepakat bahwa requirements engineering adalah suatu pekerjaan yang sangat penting, terutama berdasarkan fakta bahwa kebanyakan kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan). The Standish Group mencatat bahwa prosentase akumulatif kegagalan sebuah project pengembangan software sebagian besar disebabkan oleh masalah requirements dan spesifikasinya [Standish-94].
KASUS I
Didalam Pengembangan software SIM PNF nasional dan media belajar Pendidikan Non Formal yang dikembangkan BPPLSP Regional IV Surabaya, dari perkembangan yang ada menunjukkan bahwa tim pengembang mengalami kesulitan dalam hal:
1.Mendefinisikan kebutuhan (penterjemahan konten)
2.Penyelesaian software selalu melebihi / tidak sesuai jadwal dikarenakan keinginan Pj program lembaga berubah (faktor kebijakan, input dari konsultan lembaga)
3.Pada kesempatan review bersama antara tim pengembang dan Pj program lembaga, seringkali review dari pj program menjadikan masukan/editing yang diminta ternyata mengharuskan pengembang membongkar total.
HASIL EKSPLORASI KASUS I
Menurut IEEE Standard Glossary of Software Engineering Technology (IEEE Std 610.12-1990) [IEEE-610.12], requirement dapat diartikan :
1. Suatu kondisi atau kemampuan yang diperlukan oleh user untuk memecahkan masalah atau mencapai tujuan
2. Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standard, spesifikasi atau dokumen formal lain
3. Gambaran yang terdokumentasi dari kondisi atau kemampuan yang disebut pada 1 dan 2
Secara umum jika kita pelajari ada perbedaan mendasar definisi formal dari terminologi yang berhubungan dengan orang-orang dalam requirements engineering [IEEE-610.12]:
• Customer: Orang atau orang-orang yang membayar produk dan biasanya (tidak selalu yang memutuskan requirements. Dalam konteks ini direkomendasikan bahwa customer dan supplier adalah anggota dari organisasi yang sama.
• Supplier: Orang atau orang-orang yang memproduksi produk untuk customer. Dalam konteks ini direkomendasikan bahwa customer dan supplier adalah anggota dari organisasi yang sama.
• User: Orang atau orang-orang yang mengoperasikan atau berinteraksi secara langsung dengan produk. User dan customer kadang bukanlah orang yang sama.
Menurut Pamela Zave [Zave-97], Requirements engineering adalah cabang dari software engineering yang mengurusi masalah yang berhubungan dengan tujuan (dunia nyata), fungsi, dan batasan-batasan pada sistem software. Termasuk hubungan faktor-faktor tersebut dalam menetapkan spesifikasi yang tepat dari suatu software, proses evolusinya baik berhubungan dengan masalah waktu maupun dengan software lain (dalam satu famili).
Dan pada Proses Requirements Engineering, hasil dari fase requirements engineering terdokumentasi dalam requirements specification. Requirements specification berisi kesepakatan bersama tentang permasalahan yang ingin dipecahkan antara pengembang dan customer (dalam hal ini Pj Program), dan merupakan titik start menuju proses berikutnya yaitu software design. Sistemisasi proses negosiasi pengembang dan customer dalam requirements engineering dibagi dalam 3 proses besar yaitu: elicitation, specification, validation and verification. Formula ini kemudian juga dikenal dengan nama The Three Dimensions of Requirements Engineering. Proses requirements engineering ini dilakukan secara iterasi dengan mengakomodasi adanya feedback dari customer (user).
Adapun Requirements Elicitation, merupakan proses mengumpulkan dan memahami requirements dari user. Kadang masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan disiplin ilmu yang dimiliki). Pj Program lembaga (sebagai customer) adalah expert pada domain yang softwarenya ingin dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun tentu memahami dengan benar bagaimana sebuah software harus dikembangkan. Gap knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi) antara pengembang dan customer. Proses interaksi tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming, prototyping, use case, dsb.
Setelah masalah berhasil dipahami, dilakukan Requirements Specificatio. Dimana pengembang mendeskripsikannya dalam bentuk spesifikasi dokumen. Spesifikasi ini berisi tentang fitur dan fungsi yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode pengembangannya. IEEE mengeluarkan standard untuk dokumen spesifikasi requirements yang terkenal dengan nama IEEE Recommended Practice for Software Requirements Specifications [IEEE-830]. Dokumen spesifikasi requirements bisa berisi functional requirements, performance requirements, external interface requirements, design constraints, maupun quality requirements.
Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha:
· Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar sudah ditulis
· Verification (verifikasi), yaitu proses untuk memastikan bahwa requirements sudah ditulis dengan benar
Proses validasi dan verifikasi ini melibatkan customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan requirements.
Para pakar software engineering (rekayasa perangkat lunak) sepakat bahwa requirements engineering adalah suatu pekerjaan yang sangat penting, terutama berdasarkan fakta bahwa kebanyakan kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan). The Standish Group mencatat bahwa prosentase akumulatif kegagalan sebuah project pengembangan software sebagian besar disebabkan oleh masalah requirements dan spesifikasinya [Standish-94].
KASUS I
Didalam Pengembangan software SIM PNF nasional dan media belajar Pendidikan Non Formal yang dikembangkan BPPLSP Regional IV Surabaya, dari perkembangan yang ada menunjukkan bahwa tim pengembang mengalami kesulitan dalam hal:
1.Mendefinisikan kebutuhan (penterjemahan konten)
2.Penyelesaian software selalu melebihi / tidak sesuai jadwal dikarenakan keinginan Pj program lembaga berubah (faktor kebijakan, input dari konsultan lembaga)
3.Pada kesempatan review bersama antara tim pengembang dan Pj program lembaga, seringkali review dari pj program menjadikan masukan/editing yang diminta ternyata mengharuskan pengembang membongkar total.
HASIL EKSPLORASI KASUS I
Menurut IEEE Standard Glossary of Software Engineering Technology (IEEE Std 610.12-1990) [IEEE-610.12], requirement dapat diartikan :
1. Suatu kondisi atau kemampuan yang diperlukan oleh user untuk memecahkan masalah atau mencapai tujuan
2. Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standard, spesifikasi atau dokumen formal lain
3. Gambaran yang terdokumentasi dari kondisi atau kemampuan yang disebut pada 1 dan 2
Secara umum jika kita pelajari ada perbedaan mendasar definisi formal dari terminologi yang berhubungan dengan orang-orang dalam requirements engineering [IEEE-610.12]:
• Customer: Orang atau orang-orang yang membayar produk dan biasanya (tidak selalu yang memutuskan requirements. Dalam konteks ini direkomendasikan bahwa customer dan supplier adalah anggota dari organisasi yang sama.
• Supplier: Orang atau orang-orang yang memproduksi produk untuk customer. Dalam konteks ini direkomendasikan bahwa customer dan supplier adalah anggota dari organisasi yang sama.
• User: Orang atau orang-orang yang mengoperasikan atau berinteraksi secara langsung dengan produk. User dan customer kadang bukanlah orang yang sama.
Menurut Pamela Zave [Zave-97], Requirements engineering adalah cabang dari software engineering yang mengurusi masalah yang berhubungan dengan tujuan (dunia nyata), fungsi, dan batasan-batasan pada sistem software. Termasuk hubungan faktor-faktor tersebut dalam menetapkan spesifikasi yang tepat dari suatu software, proses evolusinya baik berhubungan dengan masalah waktu maupun dengan software lain (dalam satu famili).
Dan pada Proses Requirements Engineering, hasil dari fase requirements engineering terdokumentasi dalam requirements specification. Requirements specification berisi kesepakatan bersama tentang permasalahan yang ingin dipecahkan antara pengembang dan customer (dalam hal ini Pj Program), dan merupakan titik start menuju proses berikutnya yaitu software design. Sistemisasi proses negosiasi pengembang dan customer dalam requirements engineering dibagi dalam 3 proses besar yaitu: elicitation, specification, validation and verification. Formula ini kemudian juga dikenal dengan nama The Three Dimensions of Requirements Engineering. Proses requirements engineering ini dilakukan secara iterasi dengan mengakomodasi adanya feedback dari customer (user).
Adapun Requirements Elicitation, merupakan proses mengumpulkan dan memahami requirements dari user. Kadang masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan disiplin ilmu yang dimiliki). Pj Program lembaga (sebagai customer) adalah expert pada domain yang softwarenya ingin dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun tentu memahami dengan benar bagaimana sebuah software harus dikembangkan. Gap knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi) antara pengembang dan customer. Proses interaksi tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming, prototyping, use case, dsb.
Setelah masalah berhasil dipahami, dilakukan Requirements Specificatio. Dimana pengembang mendeskripsikannya dalam bentuk spesifikasi dokumen. Spesifikasi ini berisi tentang fitur dan fungsi yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode pengembangannya. IEEE mengeluarkan standard untuk dokumen spesifikasi requirements yang terkenal dengan nama IEEE Recommended Practice for Software Requirements Specifications [IEEE-830]. Dokumen spesifikasi requirements bisa berisi functional requirements, performance requirements, external interface requirements, design constraints, maupun quality requirements.
Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha:
· Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar sudah ditulis
· Verification (verifikasi), yaitu proses untuk memastikan bahwa requirements sudah ditulis dengan benar
Proses validasi dan verifikasi ini melibatkan customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan requirements.
No comments:
Post a Comment