Anda di halaman 1dari 7

RANGKUMAN MAKALAH Elicitation of Use Cases for Product Lines

Alessandro Fantechi1, Stefania Gnesi2, Isabel John3, Giuseppe Lami2, and Jrg Drr3
Dip. Di Sistemi e Informatica, Universita di Firenze, Italy CNR Istituto di Scienza e Tecnologie dellInformazione A. Faedo, Pisa, Italy 3 Fraunhofer Institute for Experimental Software Engineering (IESE) Kaiserslutern, Germany
2 1

F.van der Linden (Ed.): PFE 2003, LNCS 3014, pp. 152 167, 2004. Springer Verlag Berlin Heidelberg 2004

Oleh : Alif Finandhita 23511034 Program Studi Magister Informatika Sekolah Teknik Elektro dan Informatika, Institut Teknologi Bandung I. Latar Belakang
Software Product Lines (SPL) merupakan sebuah proses manufakturisasi dari perangkat lunak, dimana konsep reuse digunakan. SPL akan baik digunakan jika perangkat lunak yang akan dibangun memiliki kesamaan requirement dengan beberapa perangkat lunak lainnya yang sudah ada. Clements dan Northrop menyatakan bahwa SPL merupakan sekumpulan softwareintensive systems yang saling berbagi dan mengeloa fitur umum satu sama lainnya, untuk memenuhi kebutuhan spesifik dari suatu pasar atau misi tertentu, yang dikembangkan dari seperangkat aset inti dengan cara yang sudah ditentukan [1]. Di dalam ilmu rekayasa perangkat lunak, ada bidang ilmu yang terkait dengan bagaimana proses rekayasa dilakukan terhadap software product lines, yaitu Software Product Lines Engineering (SPLE). SPLE adalah salah satu paradigma di dalam rekayasa perangkat lunak yang akan memandu suatu organisasi menuju proses pengembangan produk perangkat lunak dari satu aset inti daripada mengembangkan satu per satu dari awal [2]. Sama halnya dengan proses rekayasa perangkat lunak pada produk tunggal, di dalam SPLE pun analisis kebutuhan memegang peranan penting, agar product lines yang dibangun dapat memenuhi kebutuhan pengguna serta memenuhi unsur kesamaan dan keragamannya. Requirement adalah spesifikasi dari apa yang harus diimplementasikan, deskripsi bagaimana sistem harusnya bekerja atau bagian-bagian yang ada didalam sistem, bisa juga dijadikan batasan dalam proses pengembangan sistem [3]. Langkah yang paling penting dalam proses requirement adalah komunikasi yang akurat antara pengguna yang memerlukan sistem dengan pembuat sistem. Ketika komunikasi tersebut terjadi maka proses yang disebut dengan elicitation untuk menggali informasi mengenai kebutuhan kebutuhan yang diinginkan dan diperlukan oleh user di dalam sistem yang akan dikembangkan. Proses Elicitation merupakan bagian dari pekerjaan yang terdapat di dalam requirement engineering yang tidak dapat dipisahkan dari bagian lainnya di dalam tahapan analisis kebutuhan. Requirement yang baik menyatakan sesuatu yang dibutuhkan, dapat diverifikasi, memungkinkan, dan Jelas. Requirement elicitation merupakan proses yang sangat penting di

dalam mengumpulkan kebutuhan, terdapat kolaborasi antara stakeholder dengan requirements analyst untuk memperoleh solusi dari permasalahan yang dimiliki oleh stakeholder[4]. Dalam proses software product line engineering pun tidak terlepas dari masalah yang terkait dengan requirements. Ketika hal masalah tersebut terjadi, maka product line yang dibangun dan dikembangkan tidak akan dapat memenuhi kebutuhan penggunanya dengan baik, karena bisa diakibatkan oleh tidak baiknya proses elicitation yang dilakukan, termasuk juga penggunaan model yang mungkin tidak sesuai dengan domain permasalahannya. Ada dua masalah yang akan dihadapi oleh software product line ketika melakukan proses elicitation dan kemudian memodelkan kebutuhannya. Masalah pertama yaitu yang terkait dengan proses untuk memberoleh kebutuhan umum untuk semua anggota dari product line dan requirements hanya valid untuk bagian dari anggota product line. Di sisi lain juga terdapat masalah yang terkait dengan pengkhususan dan menginstansiasikan generic product line requirements ke dalam bentuk application requirements untuk produk tunggal. Use Cases merupakan salah satu tool yang dapat digunakan di dalam requirements engineering untuk menangkap kebutuhan dari sudut pandang eksternal, yang memungkinkan strukturisasi dokumen requirements dengan menyatakan tujuan yang akan dicapai dan menyediakan satu pernyataan untuk menspesifikasikan interaksi antara software system yang dimaksud dengan lingkungannya [5]. Dalam pemodelan product line, commonalities dan variabilities dari suatu sistem harus dapat dideskripsikan dengan baik. Agar mendukung berbagai macam pemodelan untuk product lines dengan menggunakan use cases, perubahan dan modifikasi harus dapat dilakukan. Menangkap berbagai macam jenis karakteristik dari jenis produk yang berbeda merupakan isu utama untuk proses product line requirements engineering. Bagaimana cara untuk mendeskripsikan product line requirements dengan menggunakan model Use Cases? Bagaimana proses analisis kebutuhan terhadap dokumentasi sistem yang sudah ada dilakukan? Bagaimana pendekatan ilmiah untuk mengintegrasikan legacy information yang ditemukan di dalam dokumentasi yang sudah ada ke dalam product line dengan menggunakan Use Cases? Bagaiamana proses elicitation dilakukan? Makalah yang dirangkum ini menyediakan jawaban atas pertanyaan pertanyaan tersebut.

II. Isi Makalah


Elicitation of Use Cases for Product Lines , merupakan makalah ilmiah yang menjelaskan bagaimana pendekatan dilakukan untuk memperoleh product line requirements melalui proses elicitation terhadap informasi yang ada di dalam Use Cases. Pendekatan mulai dilakukan dari analisis terhadap dokumentasi pengguna yang berasal dari sistem yang sudah ada sebelumnya. Di dalam proses pembangunan software product line, pendekatan seperti itu dapat dilakukan untuk software product line engineering yang sifatnya independent (perusahaan membangun product line tanpa ada produk pendahulunya), project-integrating (existing systems yang sedang dikembangkan akan diintegrasikan ke dalam product line), reengineering-driven (legacy systems harus di-reengineer ke dalam product line) atau leveraged (perusahaan membangun product line berdasarkan product line yang sudah ada). Dokumentasi pengguna yang berguna sebagai masukan untuk proses pemodelan kebutuhan product line dapat ditemukan dalam kasus project-integrating, reengineering-driven dan leveraged di product line engineering. Oleh karena itu, penulis pada makalah ini menjadikan dokumentasi pengguna sebagai pilihan utama untuk memulai proses elicitation dalam menggali informasi yang dibutuhkan di dalam pemodelan product line.

Proses pengembangan software product line merupakan pekerjaan yang cukup kompleks. Pemahaman mendalam terkait domain utama permasalahan menjadi prasyarat utama untuk mencapai kesuksesan di dalam membangun dan mengembangkan product line. Oleh karenanya, untuk menunjang tercapainya kesuksesan tersebut, dasar pengetahuan utama dari sistem yang sudah ada dapat digunakan oleh perusahaan dalam melakukan product line engineering untuk membangun product line baru. Untuk memperoleh kebutuhan dari sistem yang sudah ada, melalui dokumentasi pengguna yang memang sudah dibuat sebelumnya, maka proses requirements engineering terhadap product line harus dapat dilakukan dengan baik. Langkah langkah yang dilakukan didalam proses requirements engineering tersebut adalah dengan melakukan elicitation terhadap dokumen dokumen tersebut untuk mengetahui kesamaan (commonalities) atau keragaman (variabilities) dari setiap kebutuhan yang akan digunakan sebagai dasar pengembangan, kemudian setelah itu dilakukan pemodelan terhadap kebutuhan yang diperoleh. Proses ini seringkali dilakukan secara berulang antara product line engineers dengan domain experts untuk memperoleh problem domain knowledge yang memang benar benar dibutuhkan oleh product line. Setelah itu dilakukan maka langkah yang terakhir adalah membuat Product Line Use Cases. Berikut adalah gambaran proses yang dimaksud :

Gambar 1. Proses Menggali Informasi untuk Product Line Use Cases Dengan pendekatan yang ditawarkan seperti yang tergambar pada gambar 1, kesamaan dan keragaman di dalam product line dapat dinyatakan dan dikelola dalam bentuk Use Cases. Use Cases dapat digunakan untuk menjelaskan karakteristik umum yang dimiliki oleh semua produk yang terkait dengan product line maupun keragaman yang membedakan antara satu produk dengan produk lainnya. Hanya satu line member yang dideskripsikan oleh Use Cases yang kemudian diperoleh melalui proses instansiasi. Bagaimana Use Cases dapat digunakan dan dikembangkan untuk merepresentasikan semua tipe dari keragaman yang dibutuhkan untuk memodelkan suatu product line? Maka diajukanlah pendekatan Product Line Use Cases (PLUC) oleh penulis makalah tersebut. Referensi terkait dengan Product Line Engineering Process mengikuti model yang didefinisikan di dalam CAFE project dimana pengembangan product line diidentifikasikan oleh dua proses, yaitu domain engineering dan application engineering [6]. Berbeda dengan proses requirement engineering pada perangkat lunak biasa (untuk single product), proses pendefinisian kebutuhan pada product line tidak hanya dipengaruhi oleh kebutuhan pengguna, tapi juga dipengaruhi oleh

kemampuan dari product line-nya. Hal tersebut dilakukan karena perangkat lunak yang dikembangkan selain harus dapat memenuhi kebutuhan pengguna juga harus mempertimbangkan kemampuan dari product line specializing, dan dapat mengakomodasi kebutuhan untuk menambah dan memperluas product line. Oleh karena itu, software product lines membutuhkan proses requirements engineering yang lebih rumit dan requirements tersebut harus dapat beradaptasi dengan keragaman yang terdapat di dalamnya. Secara umum product line requirements dapat dikomposisikan menjadi dua bagian, constant part yang meliputi requirements terkait fitur atau fungsionalitas umum untuk semua produk yang dimiliki oleh product line (karena sudah umum maka tidak perlu dimodifikasi lagi) dan variable part yang merepresentasikan fungsionalitas yang dapat diubah untuk membedakan antara satu produk dengan produk lainnya. Peralihan dari level product line ke level product mungkin dilakukan dengan melakukan proses instansiasi, begitu juga sebaliknya dengan melakukan proses abstraksi. Dari kedua proses ini yang menjadi perhatian utama adalah keragaman. Ekstensi Use Cases yang dapat digunakan untuk menyatakan keragaman pada saat proses product line requirements engineering merupakan ekstensi berbasis struktur Use Cases yang memiliki dua level yaitu level product line dan level produk [7]. Dalam kasus ini, menurut penulis, Use Cases yang terkait dengan produk harus diturunkan dari Use Cases yang terkait dengan product line melalui sebuah proses instansiasi. Pendekatan ini mempertimbangkan keragaman yang secara implisit akan disertakan ke dalam komponen komponen yang terdapat di dalam Use Cases. Untuk melakukan pendekatan ini, beberapa tags disertakan ke dalam skenario Use Case (baik skenario utama maupun ekstensinya) untuk dapat mengidentifikasi dan menspesifikasi berbagai keragaman yang terdapt di dalam product line. Ada tiga tags yang merepresentasikan keragaman tersebut, yaitu Alternative (menyatakan komponen alternatif), Parametric(menyatakan komponen yang wajib digunakan), dan Optional (menyatakan komponen pilihan).

Gambar 2. Contoh Use Cases dalam Notasi PLUC Gambar di atas menunjukan contoh penggunaan Use Cases dalam notasi PLUC. Notasi tersebut menjelaskan aktivitas yang terkait dengan pengiriman dokumen proyek, diasumsikan dalam proses tersebut dapat dikirim dua jenis dokumen yang berbeda, slides atau papers.

Setelah PLUC dibuat, maka yang dilakukan selanjutnya adalah melakukan proses elicitation terhadap PLUC untuk menggali requirements yang dibutuhkan. Sumber utama di dalam proses elicitation ini adalah legacy information yang terdapat di dalam sistem yang sudah ada. Sampai saat ini, informasi yang dibutuhkan untuk membangun model product line dielisitasi secara interaktif melalui keterlibatan para ahli. Namun demikian, seiring seringnya para domain experts ini unavailable karena beban kerja yang tinggi, maka proses keterlibatannya menjadi resiko tersendiri untuk kesuksesan pengenalan pendekatan product line engineering di dalam organisasi. Ada semacam kurangnya panduan untuk mengintegrasikan informasi tekstual yang terdapat di dalam legacy documents kedalam model product line. Metode elicitation pada single system tidak dapat begitu saja diimplementasikan pada product line, karena terdapat banyak dokumen yang harus dibandingkan, kesamaan serta keragamannya juga harus dapat dielisitasi serta dibutuhkannya konsep tambahan seperti konsep abstraksi dan pengambilan keputusan. Secara sistematis, proses integrasi legacy documentation kedalam model product lines mendukung hal hal berikut : Integrasi dan reuse informasi tekstual. Pemodelan product line yang layak agar tidak terlalu bergantung kepada keberadaan domain experts. Peningkatan kepercayaan terhadap penggunaan product line di dalam proses pengembangan organisasi karena ada keyakinan dengan menggunakan legacy information (bukannya mengembangkan produk dari awal) maka akan mengurangi beban di dalam membangun product line. Ada tiga tahapan di dalam pendekatan elicitation informasi untuk PLUC ini, yaitu : Tahap Persiapan (preparation) Tahap Pencarian (search) Tahap Seleksi, perubahan, dan modifikasi (selection, change and modification) Dua tahapan pendekatan yang pertama dapat dilakukan oleh seseorang yang cukup memiliki pemahaman terhadap domain permasalahan, tapi tidak perlu mereka ini sebagai seorang domain experts. Tahapan yang ketiga membutuhkan keterlibatan domain experts agar entitas dokumen yang valid dapat dipilih. Berikut adalah gambaran proses elicitation yang dimaksud :

Gambar 3. Gambaran Pendekatan Elicitation dalam Menggali Informasi untuk PLUC Berikut adalah gambaran hasil akhir implementasi pendekatan elicitation terhadap suatu kasus yang terkait dengan product line, pengembangan product line untuk aplikasi games pada dua perangkat mobile phones yang berbeda (sebut saja P1 dan P2) :

Gambar 4. Notasi PLUC untuk Contoh Kasus Product Line Aplikasi Games

III. Kesimpulan
Kesimpulan yang didapat setelah merangkum makalah dengan judul Elicitation of Use Cases for Product Lines adalah sebagai berikut : 1. Requirements Engineering merupakan bagian penting yang tidak dapat dipisahkan di dalam software engineering, baik itu untuk pengembangan single software systems maupun untuk pengembangan software product lines melalui proses software product lines engineering. 2. Terdapat perbedaan karakteristik yang mendasar antara menggali informasi untuk kebutuhan di dalam pengembangan perangkat lunak tunggal (single product) dengan pengembangan software product lines. Proses pendefinisian kebutuhan pada product line tidak hanya dipengaruhi oleh kebutuhan pengguna, tapi juga dipengaruhi oleh kemampuan dari product line-nya. 3. Product line requirements engineering yang dikembangkan selain harus dapat memenuhi kebutuhan pengguna juga harus dapat mempertimbangkan kemampuan dari product line specializing, dan dapat mengakomodasi kebutuhan untuk menambah serta memperluas product line. 4. Use Cases merupakan salah satu tool yang dapat digunakan di dalam requirements engineering untuk menangkap kebutuhan dari sudut pandang eksternal, yang memungkinkan strukturisasi dokumen requirements dengan menyatakan tujuan yang akan dicapai dan menyediakan satu pernyataan untuk menspesifikasikan interaksi antara software system yang dimaksud dengan lingkungannya. 5. Model Use Cases dapat dikembangkan untuk kebutuhan software product lines engineering dimana ekstensi Use Cases berbasis strukturnya yang memiliki dua level, level product line dan level produk, dapat digunakan untuk menyatakan keragaman pada saat proses product line requirements engineering, hingga akhirnya ada model turunan Use Cases dengan Product Lines Use Cases (PLUC).

6.

7. 8.

9.

Product line requirements dapat dikomposisikan menjadi dua bagian, constant part yang meliputi requirements terkait fitur atau fungsionalitas umum untuk semua produk yang dimiliki oleh product line (tidak perlu diubah) dan variable part yang merepresentasikan fungsionalitas yang dapat diubah untuk membedakan antara satu produk dengan produk lainnya. Proses elicitation pada PLUC dilakukan dengan menjadikan legacy information pada sistem yang sudah ada sebagai sumber utama. Metode elicitation pada single system tidak dapat begitu saja diimplementasikan pada product line, karena terdapat banyak dokumen yang harus dibandingkan dan diverifikasi, kesamaan serta keragaman pada product line juga harus dapat dielisitasi. Selain dari itu, dibutuhkan konsep tambahan seperti konsep abstraksi dan pengambilan keputusan ketika melakukan elicitation dalam proses product line requirements engineering. Pendekatan yang ditulis di makalah tersebut memberikan model spesifik yang dapat digunakan oleh perusahaan atau organisasi dalam menggali informasi yang dibutuhkan melalui proses elicitation untuk mengembangkan software product lines dengan menggunakan legacy information yang sudah ada di sistem sebelumnya sebagai dasar utama. Dengan demikian hal tersebut akan mengurangi beban ketika membangun product line karena perusahaan tidak harus membangun produk dari awal.

IV. Referensi
[1] Clements,P.,Northrop,L.,2002., Software Product Lines: Practices and Patterns, Boston:AddisonWesley., 2002. [2] Kwanwoo Lee.,Kyo C.Kang.,and Jaejoon Lee., Concepts and Guidelines of Feature Modelling for Product Line Software Engineering, Springer-Verlag Berlin Heidelberg, 2002. [3] Sommerville, Ian., Software Engineering 6th. Addison Wesley., 2001. [4] Goguen,J.A., Charlotte Linde, Techniques for Requirements Elicitation , Proceedings of the 1st International Symposium on Requirements Engineering, p.152-163,1993. [5] Cockburn, A., Writing Effective Use Cases., Addison Wesley, 2001. [6] Van der Linden, F. , Software Product Families in Europe: The Esaps and Cafe Projects, IEEE Software, 19(4):41-49, July-August 2002. [7] Bertolino, A.,Fantechi, A.,Gnesi, S.,Lami, G.,Maccari, A.,"Use Case Description of Requirements for Product Lines", REPL02, Essen, Germany, September 2002.