LABELLED TRANSITION SYSTEM FOR REQUIREMENT CHANGE (LTS-RC): PEMODELAN PERUBAHAN KEBUTUHAN PERANGKAT LUNAK BERDASARKAN LABELLED TRANSITION SYSTEM

Prosiding Seminar Nasional Manajemen Teknologi VII Program Studi MMT-ITS, Surabaya 2 Pebruari 2008

LABELLED TRANSITION SYSTEM FOR REQUIREMENT CHANGE (LTS-RC): PEMODELAN PERUBAHAN KEBUTUHAN PERANGKAT LUNAK BERDASARKAN LABELLED TRANSITION SYSTEM Martasari Widiastuti dan Daniel Siahaan Jurusan Teknik Informatika Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember Surabaya Email: [email protected]; [email protected] ABSTRAK Perubahan kebutuhan memberikan dampak yang signifikan terhadap peningkatan biaya pengembangan perangkat lunak. Keterbatasan resource yang tersedia untuk merealisasikan perubahan kebutuhan menyebabkan perubahan kebutuhan perlu dikelola. Diantara cara yang digunakan untuk mengelolanya adalah dengan mengklasifikasikan serta memberikan prioritas terhadap perubahan kebutuhan yang akan direalisasikan agar optimal sesuai dengan resource yang tersedia. Untuk memetakan prioritas perubahan kebutuhan serta menelusuri dampaknya maka dilakukan pemodelan perubahan kebutuhan. Penelitian ini mengajukan Labelled Trasition System for Requirement Change (LTS-RC), suatu metode baru untuk memodelkan perubahan kebutuhan berdasarkan Labelled Transition System (LTS). LTS-RC menurunkan prinsip dari Labelled Transition System (LTS). LTS merupakan model yang efektif untuk menggambarkan perubahan perilaku sistem. Sedangkan LTS-RC adalah LTS yang dikembangkan untuk memodelkan perubahan kebutuhan perangkat lunak, sehingga mempermudah stakeholder untuk mengamati alur perubahan kebutuhan beserta dampaknya. Dengan model LTS-RC tersebut diharapkan dapat memberikan solusi dalam menyusun strategi optimalisasi perubahan kebutuhan. Kata kunci: perubahan kebutuhan, perangkat lunak, resource, Labelled Transition System, Labelled Transition System for Requirement Change, stakeholder

PENDAHULUAN Perkembangan teknologi yang pesat serta adanya persaingan pasar yang sangat ketat menjadikan beberapa spesifikasi kebutuhan perangkat lunak menjadi tidak relevan. Hal ini mendorong untuk perlu dilakukannya perubahan kebutuhan. Berdasarkan survey yang dilakukan oleh Standish Group tentang rata-rata keberhasilan proyek perangkat lunak, ditemukan bahwa sekitar 33 % hingga 51% proyek perangkat lunak berada pada posisi yang masih mengambang (challenged) [2]. Proyek tersebut belum bisa dikatakan berhasil maupun gagal, dan salah satu kondisi yang dialaminya adalah over budget. Diantara penyebab hal ini adalah karena permasalahan perubahan kebutuhan perangkat lunak. Oleh karena itu, diperlukan cara untuk mengelolanya, yaitu dengan mengklasifikasikan serta memberikan prioritas. Penelitian sebelumnya telah mencoba menganalisa, mengklasifikasi serta menvalidasi perubahan kebutuhan sebagai salah satu upaya pengelolaannya. Klasifikasi yang dihasilkan merupakan sumber informasi berharga dalam memberikan prioritas perubahan kebutuhan serta menelusuri


dampaknya [6]. Prioritas tersebut dapat dijadikan sebagai bahan pertimbangan bagi stakeholder yang berwenang untuk menentukan perubahan kebutuhan yang paling optimal dan representatif untuk direalisasikan sesuai dengan resource yang tersedia. Untuk memetakan prioritas perubahan kebutuhan perangkat lunak serta menelusuri dampaknya dapat dilakukan dengan memodelkan perubahan kebutuhan tersebut. Penelitian ini mengajukan suatu ide untuk mengadaptasi Labelled Transition System (LTS) untuk memodelkan perubahan kebutuhan perangkat lunak, yang diberi nama Labelled Transition System for Requirement Change (LTS-RC). Tulisan ini disusun dalam beberapa bagian. Bagian pertama adalah pendahuluan yang berisi tentang latarbelakang penelitian. Bagian kedua membahas mengenai perubahan kebutuhan perangkat lunak beserta deskripsi dampak yang diakibatkannya. Bagian ketiga membahas mengenai Labelled Transition System (LTS). Bagian keempat adalah pembahasan metode baru untuk memodelkan perubahan kebutuhan perangkat lunak menggunakan Labelled Transition System for Requirement Change (LTS-RC). Bagian terakhir ditutup dengan kesimpulan. PERUBAHAN KEBUTUHAN PERANGKAT LUNAK Definisi kebutuhan perangkat lunak berdasarkan standart IEEE 1220-1998: standart aplikasi dan manajemen dari proses engineering sistem adalah: Statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, teastable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines) [4]. Requirement engineering merupakan dasar untuk pengembangan perangkat lunak. Hal ini menjadi alasan mendasar timbulnya peningkatan budget, perubahan jadwal, tes, dan desain. Idealnya, developer membuat spesifikasi kebutuhan perangkat lunak yang stabil; namun, hal ini jarang terjadi. Perangkat lunak akan berubah dikarenakan adanya proses perkembangan atau kebijakan developer sendiri. Perubahan kebutuhan dapat berpengaruh pada siklus pengembangan perangkat lunak, mulai dari fase penggalian kebutuhan hingga fase perawatan perangkat lunak. Dalam faktanya, kurang lebih setengah dari kebutuhan sistem perangkat lunak mengalami perubahan sebelum proses instalasi [7]. Manny Lehman, dalam studi ekstensifnya pada sistem perangkat lunak, menyusun hukum evolusi perangkat lunak untuk mendeskripsikan permasalahan yang umum tentang sistem perangkat lunak yang berubah. Dia menyatakan bahwa perangkat lunak tidak pernah berhenti untuk selalu mengalami perbaikan dan perkembangan yang dipicu oleh perbedaan antara kapabilitas yang ada dengan apa yang dibutuhkan oleh lingkungan yang selalu berubah [7]. Ada banyak alasan mengapa kebutuhan perangkat lunak harus berubah. Perubahan lingkungan mendorong perubahan dalam protokol dan standart yang penting untuk komunikasi dengan sistem yang lain. Manajemen perubahan adalah salah satu aspek paling penting untuk proyek pengembangan perangkat lunak yang sukses. Oleh karena itu, developer harus memiliki mekanisme yang efektif untuk mengelola proses perubahan [7]. Perkiraan Resiko Organisasi pengembang perangkat lunak banyak yang mengalami permasalahan yang kronis, mulai dari proyek yang tertunda hingga over budget. Permasalahan tersebut tidak hanya ditemui selama pengembangan baru saja, namun juga selama perubahan dan perbaikan kebutuhan dari proyek yang ada [7]. Kesulitan yang dialami

ISBN : 978-979-99735-4-2 C-11-2


praktisioner perangkat lunak adalah menghindari adanya perubahan kebutuhan perangkat lunak serta meminimumkan resiko yang diakibatkannya. Resiko Implementasi Perubahan Ada beberapa resiko yang harus disadari oleh praktisioner ketika mengelola perubahan kebutuhan. Resiko tersebut meliputi penurunan kualitas, perubahan kebutuhan yang berkelajutan (snowball), dan fisibilitas perubahan kebutuhan [7]. Adapun deskripsi mengenai resiko perubahan kebutuhan tersebut adalah sebagai berikut: Penurunan Kualitas Salah satu resiko mayoritas terkait dengan implementasi perubahan untuk sistem perangkat lunak dalam siklus produksi adalah resiko penurunan kualitas. Pengukuran kualitas menjadi sebuah keharusan untuk diambil dalam rangka untuk menangani dan mengurangi kompleksitas. Perubahan Kebutuhan Snowball Ketika menjumpai permintaan perubahan tunggal, yang mengharuskan developer menambahkan fungsionalitas baru untuk sistem atau perubahan fungsi yang ada, menyebabkan adanya resiko dari kejadian perubahan kebutuhan yang kecil ”snowball” meluas ke dalam proyek yang besar. Efek snowball ini disebabkan oleh beberapa faktor. Ketika merubah suatu kebutuhan sistem, perubahan tersebut memiliki ketergantungan pada kebutuhan yang lain, dan kebutuhan yang lain juga bergantung pada kebutuhan tersebut. Ketika kasusnya seperti ini, perubahan kebutuhan tidak terisolasi hanya pada kebutuhan tunggal. Hal ini akan berpengaruh pada proyek yang besar selagi terkait dengan perubahan yang perlu dilakukan untuk memenuhi ketergantungan kebutuhan. Ada juga kasus bahwa perubahan kebutuhan tunggal dapat menimbulkan konflik dengan kebutuhan yang sudah ada. Dalam kasus ini, kedua kebutuhan harus dimodifikasi sehingga fungsionalitas baru dapat coexist dengan kebutuhan yang lain. Permasalahan yang lain adalah performance. Ketika perubahan tunggal menurunkan faktor kualitas seperti performance CPU, maka perubahan tersebut membutuhkan komponen hardware atau alokasi sistem yang perlu ditambahkan. Fisibilitas Perubahan Kebutuhan Manajer proyek harus mampu untuk menentukan fisibilitas dari perubahan kebutuhan berdasarkan pada keterbatasan biaya serta budget dari proyek. Banyak proyek pengembang perangkat lunak yang memiliki beberapa board pengontrol perubahan untuk menentukan keputusan final pada status dan prioritas permintaan perubahan. Board ini menentukan apakah perubahan harus diimplementasikan ke dalam sistem dan memprioritaskan perubahan tersebut. Oleh karena itu, manajer proyek harus mengontrol faktor-faktor yang akan menyebabkan implementasi perubahan menyebabkan over budget atau keluar dari jadwal. Cara untuk mengontrol faktor yang merupakan dampak perubahan kebutuhan dapat dilakukan dengan memodelkan alur prioritas perubahan kebutuhan. Alur tersebut menunjukkan peta perubahan kebutuhan yang akan dilakukan terkait dengan kebutuhan ininsial yang akan dirubah. Labelled Transition Systems Labelled Transition System (LTS) digunakan untuk memodelkan perilaku sistem yang dibuat serta menggambarkan komunikasi antar komponen dalam sistem tersebut. LTS adalah tahapan transisi sistem dimana setiap transisi tersebut diberi label untuk

ISBN : 978-979-99735-4-2 C-11-3


mempermudah pengamatan alur perubahan sistem. Label dari transisi memodelkan komponen perubahan kebutuhan yang terjadi. Lintasan yang terjadi merupakan urutan kejadian yang dapat diamati dan dimulai dari jadwal perubahan kebutuhan sesuai dengan prioritas yang paling urgent. Sebagai tambahannya, digunakan komposisi pararel untuk memodelkan sistem yang dihasilkan oleh komposisi komponen perubahan kebutuhan yang berjalan pada jadwal yang hampir bersamaan. Dengan kata lain, label yang ada menginterpretasikan komunikasi yang bersinggungan antar komponen [5]. Labelled Transition System (LTS) adalah salah satu model yang menyediakan animasi grafis yang efektif berdasarkan aturan yang diberikan untuk model perilaku sistem. Model perilaku sistem adalah diskripsi tahapan kejadian selama sistem dijalankan. Model tersebut juga dapat mendeskripsikan bagaimana komponen sistem, lingkungan, dan juga user berinteraksi dalam rangka menjalankan fungsional sistem [1]. Contoh untuk Labelled Transition System dapat dilihat pada Gambar 1.

Gambar. Contoh LTS [5]

Tool untuk visualisasi diimplementasikan sebagai plugin pada tool Labelled Transition System Analyser (LTSA). LTSA telah diadaptasikan untuk membuat penggunaan arsitektur plugin MagicBeans sehingga perluasan modul dapat lebih mudah ditulis dan ditambahkan pada sistem. Plugin animator (visualiser) dari web menyediakan editor pane XML untuk LTSA dimana rule diberikan, definisi visualisasi dapat lebih spesifik dan mudah diedit, serta disediakan pula implementasi web server sederhana yang memungkinkan stakeholder menampilkan visualisasi dalam standart web browser. Komponen animator menggunakan model perilaku sistem dalam bentuk Labelled Transition System (LTS) untuk memodelkan perubahan kebutuhan yang dikontrol oleh partisipan animasi. Animator juga mendefinisikan aturan yang dibuat sesuai dengan prioritas model yang diinginkan. Aturan tersebut yang mengikat serta memberikan hasil balikan untuk animasi dalam membangun halaman web yang merepresentasikan tahapan sistem. Spesifikasi dari visualisasi dipetakan dari aturan yang dibuat untuk memvisualisasikan elemen. Ketika animator menghasilkan visualisasi dari tahapan sistem, aturan tersebut yang menggabungkan semua visual elemen yang bersesuaian dengan tahapan sistem. Visual elemen disini termasuk botton, hyperlink, yang terkait dengan kejadian yang dikontrol oleh partisipan. Elemen aktif ini memungkinkan partisipan mentriger kejadian yang mereka kontrol [1]. Contoh untuk visualisasi web sederahana dapat dilihat pada Gambar 2.

ISBN : 978-979-99735-4-2 C-11-4


Gambar. 2 Contoh Visualisasi Web [5]

Sebagai tambahannya, validasi juga bisa menggunakan animator ekstensi dengan tool LTSA, seperti pada contoh pada Gambar 3.

Gambar. 3 Contoh Validasi Model [3]

METODA PENELITIAN Desain sistem secara global ditunjukkan pada gambar 3.1. Kondisi awal sistem perangkat lunak memiliki spesifikasi kebutuhan yang masih asli. Dengan adanya perkembangan teknologi yang pesat serta persaingan pasar yang begitu ketat maka spesifikasi kebutuhan tersebut dirubah oleh para stakeholder perusahaan yang berwenang. Perubahan kebutuhan yang akan diimplementasikan dikelola terlebih dahulu dengan mengklasifikasikan serta memberikan prioritas. Klasifikasi serta prioritas dari masing-masing stakeholder yang potensial untuk direalisasikan didaftar dan didokumentasikan. Daftar prioritas perubahan kebutuhan inilah yang menjadi input untuk memodelkan perubahan kebutuhan menggunakan LTS-RC (Labeled Transition System for Requirement Change) untuk memetakan alur perubahan kebutuhan. Sedangkan outputnya adalah peta yang menggambarkan model interaksi perubahan kebutuhan. Dengan LTS-RC ini akan mempermudah stakeholder untuk mengamati alur perubahan kebutuhan beserta penelusuran dampaknya. Dari hasil output model LTS-RC ini kemudian dilakukan estimasi biaya hingga menghasilkan alternatif budget sebagai pertimbangan untuk menentukan prioritas perubahan kebutuhan yang akan direalisasikan sesuai dengan resource yang tersedia.

ISBN : 978-979-99735-4-2 C-11-5


Adapun fokus dari penelitian dalam penelitian ini adalah pada pemodelan perubahan kebutuhan perangkat lunak menggunakan LTS-RC yang merupakan pengembangan dari LTS. Dalam pemodelan dengan LTS-RC ada beberapa komponen dan proses yang harus dilalui. Diantara komponen dan proses tersebut adalah pembuatan pola perubahan kebutuhan untuk LTS-RC sebagai bahan untuk perumusan rule-rule. Rule-rule tersebut dijadikan dasar membuat arsitektur sintetik dari setiap kejadian perubahan kebutuhan yang mungkin. Komposisi pararel digunakan untuk mengintegrasikan dan merelasikan berbagai kejadian sehingga terbentuklah model interaksi perubahan kebutuhan. Untuk lebih jelasnya dapat dilihat pada Gambar 4.

Gambar 4. Desain Global Sistem

Skenario Pemodelan LTS-RC Skenario pemodelan LTS-RC didasarkan pada pemodelan transisi sistem pada LTS. Dengan input berupa daftar prioritas perubahan kebutuhan perangkat lunak yang dihasilkan dari penelitian-penelitian sebelumnya, yaitu dengan metode card sorting atau yang lain, dibuatlah model LTS-RC yang dilakukan dalam beberapa tahap. Diantara tahapan tersebut adalah (1) pembuatan pola perubahan kebutuhan, (2) pembuatan rule-

ISBN : 978-979-99735-4-2 C-11-6


rule untuk kejadian yang mungkin, (3) pembuatan artitektur sintetik untuk parsial alur perubahan kebutuhan, serta (4) pembuatan komposisi pararel dengan menggabungkan parsial alur perubahan kebutuhan tersebut hingga menghasilkan output berupa model interaksi perubahan kebutuhan. Diharapkan hasil keluaran berupa model interaksi sistem dari LTS-RC dapat representatif untuk memetakan alur prioritas perubahan kebutuhan serta menelusuri dampaknya. Untuk lebih jelasnya dapat dilihat pada gambar 5.

Gambar 5. Skenario Pemodelan Perubahan Kebutuhan dengan LTS-RC

Implementasi Pemodelan LTS-RC LTS-RC digunakan untuk memodelkan masing-masing komponen dari spesifikasi kebutuhan perangkat lunak yang mengalami perubahan serta menggunakan label transisi untuk memodelkan tahapan perubahan kebutuhan inisial beserta tahapan selanjutnya. Dalam LTS-RC digunakan operasi dari LTS yang disebut komposis pararel untuk memodelkan sistem yang dihasilkan dari komposisi komponen perubahan kebutuhan. Definisi State dan Label State didefinisikan sebagai himpunan semesta dari state-state dimana state  dan  masing-masing didesain sebagai tahap error dan tahap akhir. Sedangkan Label didefinisikan sebagai himpunan semesta dari label pesan dan Labels = Labels{} dimana  melambangkan tindakan komponen internal yang tidak dapat diobservasi oleh komponen lainnya. LTS-RC terdiri dari struktur (S, L, , q) dimana:  S  State adalah himpunan berhingga dari states.  L = (P){} dimana (P)  Labels adalah himpunan labels yang melambangkan komunikasi dari alfabet P.    (S | {, }x L x S) menunjukkan transisi terlabeli antara state.  q  S adalah inisial state. LTS yang hanya memiliki state  - ({, Labels, {}, ) menunjukkan LTS error, dilambangkan dengan Π. LTS dari bentuk P=({ε}, L,{}, ε) menunjukkan LTS yang berakhir dengan sukses dan dilambangkan ΣL. LTS P dikatakan deterministik jika tidak ada transisi yang terlabeli dengan  dan (s, l, s1) ∈ ∆. dan (s, l, s2 ) ∈ ∆ maka s1=s2, selain itu dikatakan non deterministik. Sebagai tambahannya dikatakan bahwa label l terdapat dalam state s jika ada state s' sehingga (s, l, s' ) ∈ ∆.

ISBN : 978-979-99735-4-2 C-11-7


Gambar 6. Pemodelan Perubahan Kebutuhan dengan LTS-RC

Sebagai contoh, anggap LTS-RC berikut memodelkan komponen perubahan kebutuhan perangkat lunak sistem informasi FRS Online sederhana: FRS Online: ({0,1,2}, {performance, feature, security, content}, {(0, performance, 1), (1, feature, 2), (2, security, 3), (3, content, 0)}, 0). Gambar 6 merepresentasikan LTS-RC secara grafis. Angka yang digambarkan dalam state menunjukkan urutan state. State diberi nomor bilangan bulat dengan nol menunjukkan inisial state. Transisi dimulai dari insial state. Berawal dari state 0, tindakannya adalah melakukan perubahan performance dan kemudian berlanjut pada state 1; pada state 1, tindakannya adalah melakukan perubahan feature dan kemudian menuju state 2; pada state 2, tindakannya adalah melakukan perubahan security akhirnya pada state 3, perubahan kebutuhan kembali ke inisial state dengan melakukan perubahan content. KESIMPULAN LTS-RC dapat digunakan untuk memetakan perubahan kebutuhan perangkat lunak. Dengan adanya model tersebut akan membantu menentukan prioritas yang optimal terhadap perubahan kebutuhan yang akan direalisasikan. Serta dengan model LTS-RC stakeholder dapat mengetahui tahapan yang harus dilalui ketika inisial perubahan kebutuhan telah ditentukan. Namun ada beberapa hal yang perlu diperhatikan, diantaranya adalah masalah kompleksitas perubahan kebutuhan perangkat lunak yang menyebabkan perlu ditambahkannya definisi serta spesifikasi yang detail. Perubahan kebutuhan perangkat lunak bersifat kasuistik, untuk itu stakeholder perlu untuk memberikan validasi terhadap prioritas perubahan kebutuhan yang akan dimodelkan serta diperlukannya skenario spesifik terhadap perubahan kebutuhan yang akan direalisasikan. DAFTAR PUSTAKA Chatley, Robert., Uchitel, Sebastian., Kramer, Jeff., and Magee, Jeff., (2005), “FluentBased Web Animation: Exploring Goals for Requirements Validation”, in International Conference on Software Engineering (ICSE'05), May 15-21, St. Louis, Missouri, USA, ACM 1-58113-963-2/05/0005 Davis, Steven., (2006), Integrating People, Process and Technology: Effective and Efficient Requirements Management, Orasi Global Services

ISBN : 978-979-99735-4-2 C-11-8


Foster, Howard., (2006), A Rigorous Approach To Engineering Web Service Compositions, PhD Thesis, Department of Computing, University Of London, London Lane., Ann, Jo,. and Boehm, Barry,. (2007), “When Does Requirements Volatility Stop All Forward Progress”, in Practical Software and System Measurement User’s Group Conference, Golden, Colorado Uchitel, Sebastian., Chatley, Robert., Kramer, Jeff.,Magee, Jeff., (2004), “Fluent-Based Animation: Exploiting the Relation between Goals and Scenarios for Requirements Validation”, Proceedings of the 12th IEEE International Requirements Engineering Conference, IEEE Computer Society, 1090-705X/04 Williams, Susan P., Nurmuliani, Nur., Zowghi, Didar., (2004), “Using Card Sorting Technique to Classify Requirements Change”, Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04), IEEE Computer Society, 1090-705X/04 Williams, Byron J., Carver, Jeffrey., Vaughn, Ray., (2006), “Change Risk Assessment: Understanding Risks Involved in Changing Software Requirements”, in The 2006 International Conference on Software Engineering Research and Practice (SERP), Department of Computer Science and Engineering Mississippi State University, MS 39762

ISBN : 978-979-99735-4-2 C-11-9

LABELLED TRANSITION SYSTEM FOR REQUIREMENT CHANGE (LTS-RC): PEMODELAN PERUBAHAN KEBUTUHAN PERANGKAT LUNAK BERDASARKAN LABELLED TRANSITION SYSTEM

Recommend Documents