Memahami Konsep Agile pada Rekayasa Perangkat Lunak (Software Engineering)

Kali ini saya akan membahas salah satu konsep proses pengembangan perangkat lunak. Konsep tersebut adalah proses pengembangan perangkat lunak menggunakan pendekatan Agile Process.

Dalam era ekonomi modern seperti sekarang ini, seringkali kita mengalami kesulitan pada saat memprediksi, bagaimana sih sebaiknya bentuk sistem informasi yang diperlukan sesuai kebutuhan saat ini dan juga kebutuhan di masa mendatang. Hal itu terjadi karena kondisi pasar yang sangat cepat berubah, termasuk labilnya perubahan kebutuhan pengguna, dan juga serangan dari kompetitor baru yang datang tanpa peringatan. Pada saat tertentu, kita tidak mudah mendefinisikan keseluruhan requirements sebelum proyek mulai berjalan, sehingga menyebabkan terjadinya requirements yang tidak menggambarkan kebutuhan pengguna sistem informasi yang sesungguhnya, bahkan sering terjadi scope creep (cakupan requirements yang terlalu melebar). Untuk mengatasi hal tersebut, diperlukan suatu cara pendekatan pembangunan perangkat lunak yang mampu segera me-respons gejolak ketidakstabilan requirements bisnis. Salah satu pendekatan yang dimaksud adalah Agile Process.

Istilah Agile sendiri terdiri dari dua pengertian, yaitu: pertama pengertian dari segi filosofi, dan kedua pengertian dari segi pedoman pengembangan perangkat lunak. Dari segi filosofi, agile mempunyai arti antara lain:  mendorong demi terciptanya kepuasan pelanggan; mempercepat delivery perangkat lunak secara bertahap (incremental); tim proyek yang ramping dan mempunyai motifasi yang sangat tinggi; minimasi pekerjaan; serta menyederhanakan (birokrasi) keseluruhan proses pembangunan perangkat lunak. Sedangkan dari segi pedoman pengambangan perangkat lunak, agile mempunyai pengertian, bahwa secara aktif dan berkesinambungan, antara pengembang dengan pelanggan harus senantiasa menjalin kerjasama dan komunikasi dengan baik.

Menyinggung masalah Agile, terdapat suatu istilah yang disebut dengan Agility. Apa sih yang dimaksud Agility itu ? Menurut Ivar Jacobson, agility mengandung pengertian bahwa perubahan (change) merupakan "hati" dan "jiwa" dari perangkat lunak. Maksudnya adalah, bahwa perubahan terhadap requirements pelanggan, silih bergantinya anggota tim, dan perubahan kebutuhan teknologi yang berimplikasi terhadap produk yang dihasilkan merupakan suatu hal yang sangat wajar terjadi. Hampir semua proyek pengambangan perangkat lunak pasti mengalami hal tersebut. Sedangkan menurut Goldman et al, agility merupakan sesuatu yang dinamis, mempunyai kontent yang spesifik, menaggapi perubahan secara agresif, dan beroriantasi pada pertumbuhan.

Dari definisi menurut Ivar Jacobson dan Goldman et al, di atas dapat ditarik kesimpulan bahwa Agility merupakan suatu kemampuan atau "jiwa" yang harus dimiliki oleh tim pengambangan perangkat lunak. Kemampuan tersebut antara lain berupa: kemampuan segera menindaklanjuti terjadinya perubahan secara efektif; kemampuan berkomunikasi antar stakeholders secara efektif; menganggap bahwa pelanggan merupakan pihak yang berada di dalam tim yang sama; kemampuan mengorganisasikan tim (memberikan motivasi) agar mampu meningkatkan performa kinerja tim; secara tepat waktu dan berkesinambungan dapat men-deliver perangkat lunak yang telah dijadwalkan.

Setelah membahas mengenai Agile dan Agility, kemudian apa sih yang dimaksud dengan istilah Agile Process itu ? Agile Process merupakan sekelompok aktifitas pembangunan perangkat lunak secara iteratif yang menekankan pada aktifitas konstruksi (desain dan koding). Agile Process mengeliminasi sebagian besar waktu untuk melakukan perencanaan sistem dan berusaha sebisa mungkin mematuhi jadwal deliver sistem yang telah dijanjikan. Requirements yang dibutuhkan secara langsung di-drive oleh pelanggan itu sendiri, dan apabila terjadi perubahan terhadap requirements tersebut, pengembang dituntut mampu beradaptasi dengan perubahan yang terjadi.

Terus, sifat anggota tim yang bagaimana sih agar pendekatan Agile ini berhasil diterapkan ?. Tim yang agile harus memiliki sifat-sifat sebagai berikut: Pertama, dari segi kompetensi, anggota tim harus mempunyai bakat dan keterampilan yang berhubungan dengan pengembangan perangkat lunak di bidangnya masing-masing, terutama yang berkaitan dengan konstruksi perangkat lunak (desain dan pemrograman). Kedua, dari segi fokus perhatian, anggota tim harus berkonsentrasi pada ketepatan deliver produk yang telah dijanjikan dan dilakukan secara bertahap. Ketiga, dari segi kolaborasi, anggota tim harus mampu saling bekerjasama, baik itu dengan pelanggan maupun dengan manajer bisnis-nya. Keempat, dari segi kemampuan dalam berdiskusi, anggota tim senantiasa mendiskusikan isu-isu yang terjadi (apabila terjadi masalah, sesegera mungkin didiskusikan). Kelima, dari segi kemampuan menyelesaikan masalah, anggota tim harus terbiasa dengan ambiguitas dan mencari solusi yang tepat. Keenam, harus terjalin rasa saling percaya. Ketujuh, dari segi kesadaran keorganisasian, seorang anggota tim harus mampu bekerja dengan giat demi selesainya tugas  sesuai dengan jadwal yang dialokasikan.

Selanjutnya, saya akan membahas mengenai langkah-langkah dalam pengembangan perangkat lunak menggunakan pendekatan Agile. Secara mendasar, aktifitas-aktifitas umum dalam kerangka kerja agile antara lain: komunikasi dengan pelanggan, perencanaan, pemodelan, konstruksi, pengiriman (delivery), dan melakukan evaluasi. Kemudian aktifitas akan berulang, terutama untuk perencanaan deliver berikutnya. Semua aktifitas tersebut di buat seminimal mungkin, lebih memfokuskan dan konsentrasi pada konstruksi serta delivery.

Kemudian, seperti apa saja sih bentuk dari pendekatan Agile ini ? Terdapat banyak model pendekatan yang tergolong dalam Agile Process, namun tidak semua model saya bahas pada tulisan ini, saya hanya menjelaskan dua model yaitu: Extreme Programming (XP), dan Adaptive Software Development (ASD).

1. Extreme Programming (XP)
XP merupakan suatu model yang tergolong dalam pendekatan agile yang diusulkan oleh Kent Back. Menurut penjelasan dia, definisi XP adalah sebagai berikut: "Extreme Programming (XP) is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software". Model ini cenderung menggunakan pendekatan Object-Oriented. Tahapan-tahapan yang harus dilalui antara lain: Planning, Design, Coding, dan Testing.

 XP Process (Pressman, 2005)

Pada saat perencanaan, dimulai dengan membuat semacam "user strories" yang ditempatkan index card. User Story (cerita) merupakan deskripsi fitur-fitur fungsional yang akan disediakan perangkat lunak yang akan dibuat. Dari cerita-cerita yang telah dibuat, pelanggan memberikan semacam nilai (misalnya: prioritas). Kemudian tim XP mengkaji semua cerita tadi dan menentukan rincian biaya serta memperkirakan waktu yang dibutuhkan untuk membangun sistem. Apabila waktu yang dibutuhkan untuk mengimplementasikan cerita tersebut lebih dari tiga minggu, maka tim XP meminta pelanggan memecah cerita tersebut menjadi cakupan yang lebih kecil. Cerita-cerita yang telah dibuat dikelompokkan, sehingga dapat diperkirakan untuk melakukan deliverable increments. Meskipun telah dikelompokkan dan proses pembangunan perangkat lunak telah dimulai, pelanggan masih bisa menambah, merubah, memecah dan menghapus cerita-cerita tersebut, namun tentunya harus sesuai dengan persetujuan bersama.

Keuntungan dari model XP antara lain adalah: Pertama, dapat merepresentasikan situasi nyata yang sering terjadi, sehingga sistem yang akan dibuat mendukung sebagian besar operasional pengguna. Kedua, memudahkan pengguna memahami dan memberikan masukan terhadap cerita tersebut. Ketiga, dapat merepresentasikan fitur-fitur fungsional secara bertahap (incremental).

Sedangkan kekurangan dari model XP antara lain adalah: Pertama, cerita-cerita yang menunjukkan requirements tersebut kemungkinan besar tidak lengkap. Kedua, user strories lebih fokus kepada kebutuhan fungsional dari pada fokus kepada kebutuhan non fungsional. Ketiga, hubungan antara arsitektur sistem dengan user strories tidak jelas, sehingga perancangan arsitektur juga lebih sulit.


2. Adaptive Software Development (ASD)
ASD merupakan suatu model yang tergolong dalam pendekatan agile yang diusulkan oleh Jim Highsmith. ASD menekankan pada pengorganisasian tim secara mandiri, kolaborasi antar-perseorangan, dan terus belajar, baik secara individu maupun secara tim. ASD menggunakan tools yang disebut "time-boxing" - yaitu berupa aktifitas yang menentukan jangka waktu tertentu yang dialokasikan untuk menyelesaikan berbagai macam tugas. Apabila waktu yang ditentukan tersebut selesai, maka pembangunan sistem akan pindah ke tugas berikutnya, dengan harapan bahwa sebagian besar dari critical work telah berhasil diselesaikan sebelum waktu keseluruhan tugas berakhir. Terdapat tiga tahapan pada model ASD, yaitu: Speculation, Collaboration, dan Learning.

Adaptive Software Development (Pressman, 2005)

Pada tahap Speculation, proyek dimulai dan adaptive cycle planning diselenggarakan. Pada tahapan ini, didefinisikan visi dan misi pengguna terhadap sistem yang akan dibuat, selanjutnya mendefinisikan project constraints, misalnya: waktu deliver. dan selanjutnya mendefinisikan satu set dari requirements yang akan dikerjakan dalam suatu cycle. Pada tahap Collaboration, pada tahap ini diorganisasikan tim kerja untuk membangun sistem. Direkomendasikan menggunakan model Joint Application Development (JAD). Pada tahap Learning, terdapat tiga aktifitas yaitu: pelanggan atau end-user menyediakan feedback terhadap hasil incremental delivery, tim ASD melakukan review terhadap komponen perangkat lunak untuk memperbaiki dan meningkatkan kualitas perangkat lunak yang sedang dibuat.

Langkah-langkah untuk Memulai Proyek TI (Project Initiation)

Sebelum membahas lebih jauh tentang Project Initiation, timbul pertanyaan, Mengapa sih suatu organisasi atau perusahaan perlu membuat menyelenggarakan proyek TI ?, jawabanya adalah: pada zaman sekarang ini, yang "katanya" zaman paradigma ekonomi berbasis Jaringan (Network Economy Paradigm), organisasi atau perusahaan yang ingin tetap langgeng dalam menjalankan usahanya "wajib hukumnya" terus menciptakan  inovasi untuk menambah nilai bisnis baru, meningkatkan kreatifitas untuk meningkatkan kemampuan differentiation, dan memperluas relationship untuk menciptakan jaringan usaha yang kuat. Kalau tidak, mungkin organisasi atau perusahaan tersebut tinggal menunggu waktu untuk jatuh dan kalah dalam persaingan bisnis. Untuk memenuhi kebutuhan tersebut, hal yang paling memungkinkan adalah memanfaatkan kemampuan Teknologi Informasi. Teknologi Informasi tidak serta-merta dapat dimanfaatkan, akan tetapi harus direkayasa dan diatur sedemikian rupa, sehingga keberadaaanya sanggup memenuhi semua kebutuhan yang sudah saya sebutkan di atas. Dan untuk melakukan rekayasa dan pengaturan terhadap TI agar sesuai kebutuhan, perlu diselenggarakannya suatu proyek TI.  

Tulisan saya kali ini akan membahas mengenai langkah-langkah suatu organisasi atau perusahaan untuk merencanakan suatu proyek TI mereka, atau disebut dengan Project Initiation. Termasuk juga pembahasan mengenai aktifitas dan persiapan apa saja yang harus dilakukan supaya proyek yang dijalankan nanti sesuai dengan apa yang dicita-citakan.


Menurut Dennis et al, (2005) definisi inisiasi proyek adalah sebagai berikut. "Project Initiation is the point at which an organization creates and assesses the original goal and expectations for new system". Menurut penjelasan tersebut, project initiation berupa tahapan dalam perencanaan proyek TI organisasi dengan melakukan analisis kelayakan, menaksir tujuan utama dan harapan diselenggarkannya proyek TI, serta mempertimbangkan segala resiko yang mungkin terjadi. Jadi, inisiasi proyek merupakan tahapan yang sangat menentukan keberlangsungan proyek TI. Hal lain yang sangat menentukan keberlangsungan proyek adalah dukungan Project Sponsor. Project Sponsor merupakan pihak kunci yang mengusulkan pengembangan atau pengadopsian teknologi baru pada suatu instansi atau perusahaan. Project Sponsor juga sebagai pihak yang menyediakan atau mencari dana demi keberlangsungan penyelanggaraan proyek TI.

Untuk memulai Project Initiation, hal yang pertama kali dilakukan adalah mengidentifikasi nilai bisnis (identifying business value). Pada tahap ini, aktifitas-aktifitas yang perlu dilakukan antara lain: Pertama, perusahaan harus memastikan bahwa proyek TI yang akan diselenggarakan benar-benar berdasarkan kebutuhan bisnis. Kedua, project sponsor harus mengenali dan memahami kebutuhan bisnis perusahaan secara seksama, serta berkeinginan mengimplementasikan kebutuhan bisnis tersebut. Ketiga, kebutuhan bisnis yang dibuat harus mencerminkan fungsionalitas dari sistem yang akan dibuat (what it will do). Keemepat, nilai bisnis proyek TI harus dijabarkan secara jelas, baik tangible (terukur) maupun intangible (tidak terukur). Kelima, dan yang terakhir adalah menyusun dokumentasi kebutuhan sistem (system request).

Selanjutnya saya akan membahas mengenai system request. System Request merupakan suatu dokumen yang mendeskripsikan alasan bisnis terkait dengan pembangunan sistem informasi serta nilai bisnis yang akan dicapai. System Request merupakan dokumen yang harus mendapat persetujuan dari approval commitee untuk melanjutkan penyelenggaraan proyek TI. Terdapat tiga elemen penting yang harus ada dalam system request, yaitu: Pertama, Project Sponsor merupakan pihak yang mengusulkan proyek. Biasanya Project Sponsor adalah pemilik perusahaan, CIO, atau pimpinan utama perusahaan. Kedua, Kebutuhan bisnis (business need) perusahaan. Terdapat tiga komponen penting untuk menentukan kebutuhan bisnis, yaitu:  (1). Alasan bisnis terkait perlunya dibuat sistem informasi. Misalnya: meningkatkan penjualan, memperbaiki layanan pelanggan, dan mungurangi kecacatan produksi. (2). Kebutuhan fungsional untuk mendefinisikan fitur-fitur yang disediakan oleh sistem informasi. Misalnya: menyediakan layanan online, menyediakan laporan manajemen, menyediakan informasi demografik pelanggan. (3). Perkiraan nilai yang diharapkan (expected value) yang berupa keuntungan yang akan diraih setelah diterapkannya sistem informasi. Misalnya: 3 persen akan meningkatkan penjualan, dan 10 persen mengurangi kecacatan produksi. Ketiga, Special Issues, merupakan isu yang relevan untuk mengimplementasikan sistem informasi. Misalnya: sistem dibutuhkan menjelang hari raya lebaran, sistem informasi yang dibutuhkan menjelang tahun ajaran baru.

Apakah suatu perusahaan atau organisasi layak membangun suatu sistem informasi ? Pertanyaan ini dapat terjawab setelah perusahaan atau organisasi melakukan Feasibility Analysis atau analisis kelayakan.  Feasibility Analysis dilakukan setelah kebutuhan-kebutuhan sistem dan requirement bisnis terdefinisi. Feasibility Analysis bertujuan mendokumentasikan secara jelas dan detail tentang perbandingan biaya yang akan dikeluarkan dan keuntungan yang akan diraih. Terdapat tiga elemen untuk melakukan analisis kelayakan, yaitu: Pertama, Technical Feasibility (can we built it ?) memperkirakan apakah perusahaan sudah terbiasa dengan aplikasi dan teknologi yang akan diterapkan, serta layakkah mengerjakan proyek dengan size tertentu. Kedua, Economic Feasibility (should we built it ?) menganalisis apakah perusahaan secara keuangan mampu menyelenggarakan proyek TI. Terdapat beberapa langkah aktifitas untuk mendapatkan feasibility economy, yaitu: mengidentifikasi biaya dan keuntungan (cost benefit analysis), menempatkan nilai (values) yang akan diperoleh di samping mengidentifikasi biaya dan keuntungan, menetapkan cash flow, menentukan Net Present Value (NPV), memperkirakan Return on Investement (ROI), serta menghitung dan membuat grafik Break Event Point (BEP). Ketiga, Organizational Feasibility (if we built it, will they come ?) pada bagian ini menjawab apakah secara keorganisasian mampu membangun proyek TI. Terdapat dua aktifitas yang dilakukan pada tahap ini, yaitu: (1). perusahaan harus menganalisis sampai berapa jauh kesesuaian antara tujuan proyek dengan hasil yang akan diraih. (2). perusahaan harus menganalisis kelayakan dukungan dari pihak-pihak terkait (stakeholder).

Jadi, kesimpulan yang dapat diambil adalah, untuk memulai suatu proyek, perusahaan harus mendefinisikan semua kebutuhan sistem dan requirement bisnis dengan cara membuat dokumentasi System Request. Selanjutnya, perusahaan harus mengkaji dengan melakukan Feasibility Analisys, apakah proyek TI yang akan diselenggarakan nanti benar-benar mampu dan layak untuk dilanjutkan.

Mudah-mudahan tulisan ini bermanfaat bagi kita semua ..... terima kasih..........

Memahami Konsep Capability Maturiry Model (CMM)

Kali ini, saya akan membahas suatu konsep kematangan organisasi dari segi kemampuannya dalam mengembangkan perangkat lunak. Konsep kematangan pengembangan perangkat lunak yang saya maksud adalah Capability Maturity Model (CMM).

Sebelum membahas lebih lanjut mengenai CMM, saya mencoba menganalogikan pembangunan perangkat lunak sebagai permainan baseball. Apa yang menjadi pembeda, apabila bola baseball dipukul oleh pemain pemula dan dibandingkan dengan seseorang yang sudah mahir bermain baseball ?. Tentunya, apabila bola tersebut dipukul oleh seorang pemula dan pemain lainnya juga masih pemula, mereka akan berlarian tidak teratur, ada yang berlarian ke arah yang benar dan ada yang berlarian ke arah yang salah, karena bola yang dipukul belum tentu mengarah pada sasaran yang tepat. Namun, apabila bola tersebut tersebut dipukul oleh seseorang yang telah professional, dan tim yang professional pula dalam permainan baseball, mereka akan berlarian ke koordinat masing-masing berdasarkan pengalaman latihan yang telah dilakukan sebelumnya. Bisa saja para pemain professional tersebut melakukan sesuatu yang salah, akan tetapi hampir semua pemain proffesional selalu mencoba melakukan sesuatu dengan benar.

Dari analogi saya di atas dapat disimpukan, bahwa suatu tim yang professional dikatakan lebih "matang" (mature) dibandingkan dengan tim pemula. Karena, seorang tim yang professional mampu mengembangkan kualitas dirinya sendiri (self-perpetuating quality) dengan menunjukkan bahwa mereka bermain dengan baik, mampu mendidik pemain baru untuk bermain secara professional pula, dan selalu menggali strategi untuk menciptakan permainan yang terbaik. Begitu juga dengan proses pembuatan perangkat lunak, apabila tim yang melakukan proses pengembangan merupakan tim yang kurang professional, maka perangkat lunak yang dihasilkannya pun belum tentu sesuai dengan requirements pengguna. Akan tetapi, apabila tim pengembang perangkat lunaknya telah professional, akan lebih besar kemungkinannya perangkat lunak yang dihasilkannya sesuai dengan requirements pengguna.

Terus, apa sih yang dimaksud dengan CMM. Menurut wikipedia, "Capability Maturity Model (CMM) is a concept that was developed in the field of software development and which provides a model for understanding the capability maturity of an organization's software development business processes.". Jadi, CMM berupa konsep pengembangan perangkat lunak yang menuntun suatu organisasi atau perusahaan agar dalam proses pengembangan perangkat lunaknya lebih matang, atau dapat dikatakan lebih baik daripada proses pengambangan perangkat lunak sebelumnya. Konsep CMM didasarkan pada kepercayaan bahwa penggunaan perangkat lunak baru tidak dengan sendirinya diikuti hasil yang mampu meningkatkan produktifitas dan keuntungan organisasi atau perusahaan, karena yang menjadi permasalahan sebenarnya adalah tanda tanya besar mengenai.... "bagaimana kita me-manage proses perangkat lunak ?".

Selanjutnya, saya akan membahas mengenai peringkat (level) CMM yang digunakan untuk mengukur tingkat kematangan proses pengambangan perangkat lunak suatu organisasi atau perusahaan. Terdapat lima peringkat dalam CMM, yaitu sebagai berikut:

The Five Levels of Software Process Maturity

Setiap level mencerminkan maturity suatu organisasi atau perusahaan dalam proses pengembangan perangkat lunak. Semakin tinggi peringkat kematangannya, maka semakin optimal organisasi tersebut dalam melakukan proses pengambangan perangkat lunaknya, kualitas perangkat lunak yang dihasilkannya pun semakin tinggi, dan resiko kegagalannya pun semakin kecil. Berikut ini gambar yang mengilustrasikan hubungan antara peringkat-peringkat dalam CMM dengan produktifitas, kualitas, dan resiko.

 

CMM levels related to Productivity, Quality, and Risk

Pada gambar di atas diilustrasikan peringkat-peringkat dalam CMM dan hubungannya dengan produktifitas, kualitas, serta resiko. Selanjutnya, saya akan membahas deskripsi dari masing-masing peringkat di dalam CMM, yaitu:

• Level 1: disebut dengan istilah Initial. Pada level ini segala sesuatu dalam proses pengambangan perangkat lunak masih dilakukan secara add-hock dan semrawut. Kadangkala perangkat lunak yang dihasilkannya dapat dikatakan sukses, akan tetapi kemungkinan besar sering mengalami kegagalan dan keterlambatan deadline.
• Level 2: disebut dengan istilah Repeatable. Pada level ini proses pengembangan perangkat lunak telah terdefinisi, terdokumentasi, telah dipraktekkan, dan penggunanya telah dilatih sedemikian rupa. Namun, beberapa tim lain dalam organisasi tersebut belum menggunakan proses yang serupa / belum terstandarisasi dengan baik.
  
• Level 3: disebut dengan istilah Defined. Pada level ini proses pengambangan perangkat lunak telah konsisten dan terdifinisi, sehingga semua pihak di dalam suatu organisasi dapat memahami dan menerapkannya.
• Level 4: disebut dengan istilah Managed. Pada level ini proses pengambangan perangkat lunak terukur secara kuantitatif, dan semua proses selalu dievaluasi berdasarkan hasil analisis data yang dikumpulkan.
• Level 5: disebut dengan istilah Optimazing. Pada level ini proses pengambangan perangkat lunak secara terus menerus dilakukan optimalisasi. Organisasi akan selalu mempelajari pengalaman dan informasi tentang teknologi baru. Organisasi juga dapat merubah prosedur suatu proses apabila ditemukan prosedur baru yang dianggap lebih baik dari prosedur lama. 

Untuk setiap tingkat maturitas organisasi, terdapat suatu cluster yang membagi aktifitas-aktifitas dalam CMM yang disebut dengan Key Process Area (KPA). KPA telah disiapkan oleh Software Engineering Institute (SEI) yang berfungsi sebagai acuan untuk dapat naik ke peringkat berikutnya. SEI juga telah membuat kuesioner-kuesioner untuk melakukan assesement pada tingkat mana suatu organisasi berada.

Berikut ini tabel yang mendeskripsikan tetang KPA dari setiap level CMM.

 

Pada tabel di atas didefinisikan KPA yang berupa aktifitas-aktifitas yang harus dilakukan agar suatu organisasi berada di level tertentu. Suatu organisasi dapat meningkatkan peringkat CMM nya ke tingkat yang lebih tinggi apabila telah dilakukan assesement oleh accessor. Accessor tersebut akan menilai dan memutuskan, apakah suatu organisasi benar-benar layak berada di suatu level tertentu.

Berikut ini gambar yang mengilustrasikan ekspektasi kehandalan (performance) proyek dalam tingkat-tingkat level CMM.

 

Project Performance Expectation 

Dari gambar di atas dapat disimpulkan, semakin tinggi level CMM suatu organisasi, maka tingkat performa proses pengambangan perangkat lunak dan tingkat kemungkinan berhasilnya semakin meningkat. Sehingga secara otomatis biaya, jadwal, dan kualitas yang dihasilkan sesuai dengan kebutuhan pengguna.

Sementara sampai disini pembahasan pada blog ini tentang CMM... mungkin pada tulisan lain akan dilanjutkan....

Pengenalan tentang "Object-Oriented Systems Analysis and Design Approach"

Pada kesempatan ini, saya akan membahas mengenai salah satu pendekatan dalam melakukan pengembangan Rekayasa Perangkat Lunak (Software Engenering), yaitu pendekatan yang dinamakan "Object-Oriented Systems Analysis and Design" atau disingkat dengan OOSAD.

Mungkin kita sudah sering mendengar tentang metodologi-metodologi untuk melakukan pengembangan rekayasa perangkat lunak, seperti: System Development Life Cycle atau juga disebut dengan metodologi Waterfall; Rapid Appication Development (RAD); dan Agile Development (Extreme Programming).

Tujuan semua metodologi pegembangan sistem di atas adalah sama, yaitu membuat perangkat lunak yang sesuai dengan kebutuhan-kebutuhan (requirements) pengguna. Seiring dengan perkembangan zaman, dunia bisnis saat ini tidak dapat dipisahkan lagi dari kebutuhan TI, khususnya perangkat lunak. TI tidak lagi dipandang hanya sebagai pendukung, akan tetapi TI telah dianggap bagian strategi bisnis, yaitu menjadi garis depan layanan bagi konsumen. Dengan kata lain, kebutuhan pengambangan perangkat lunak sudah semakin kompleks. Oleh karena tuntutan tersebut, diperlukan suatu cara pengembangan sistem informasi untuk mengatasi kompleksitas kebutuhan.

Dari semua metodologi yang sudah saya sebutkan di atas (traditional approaches), saat ini sudah semakin tidak relevan menggunakan semua methodologi tersebut untuk mengatasi kompleksitas sistem. Sehingga dibutuhkan suatu pendekatan baru, maka muncullah suatu pendekatan yang disebut "Analisis dan Desain Sistem Berbasis Object". Perbedaan mencolok antara pendekatan tradisional dengan pendekatan berorientasi object terletak pada saat dilakukannya pendekomposisian permasalahan. Pada pendekatan tradisional, permasalahan didekomposisikan menjadi proses, yaitu process-centric atau data-centric. Pada saat memodelkan real-world system, kenyataanya proses dan data merupakan dua komponen yang sangat berkaitan, sehingga kita akan kesulitan untuk memilih salah satu yang menjadi fokus utama racangan.

OOSAD berusaha menyeimbangkan antara proses dan data dengan cara memfokuskan dekomposisi dari permasalahan-permasalahan menjadi object-object yang di dalamnya terkandung data dan proses-proses. Sehingga diharapkan, kesenjangan keterfokusan antara data atau proses dapat dihindari, dan memudahkan kita untuk memecahkan kompleksitas permasalahan menjadi bagian-bagian yang lebih kecil cakupan permasalahannya.

Menurut Grady Booch, Ivar Jacobson, dan James Rumbaugh, pengambangan sistem informasi dengan menggunakan pendekatan OOSAD harus mengikuti beberapa hal berikut, yaitu:

1. Use-Case Driven
Maksud dari use-case driven adalah, bahwa use cases merupakan alat pemodelan utama untuk mendefinisikan perilaku dari sistem. Use cases digunakan untuk mengidentifikasi dan mengkomunikasikan kebutuhan-kebutuhan sistem dengan semua programmer yang bertugas menulis code program.

2. Architecture Centric
Maksud dari architecture-centric adalah, bahwa pembangunan arsitektur sistem informasi harus didasarkan pada spesifikasi, konstruksi, dan dokumentasi dari sistem. Arsitektur tersebut setidaknya harus mendukung tiga sudut pandang, yaitu:

• Sudut pandang fungsional: merupakan tingkah laku eksternal dari sistem menurut perspektif pengguna.
• Sudut pandang statis: merupakan struktur dari sistem yang terdiri dari: atribut, method, kelas, dan relationship.
• Sudut pandang dinamis: merupakan tingkah laku internal sistem yang berupa lintas pertukaran pesan antar object.

3. Iterative and Incremental
Maksud dari iterative and incremental adalah, bahwa aktifitas analisis dan desain sistem informasi dilakukan secara iterasi (berulang) dan berkesinambungan (sedikit-demi-sedikit). Tujuannya adalah untuk memudahkan development untuk melakukan continuous testing dan perbaikan-perbaikan selama proyek berlangsung.

Mungkin demikian pembahasan saya tentang pengenalan pendekatan OOSAD. Mudah-mudahan penjelasan di atas berguna bagi kita semua.