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....

Rancangan Tatakelola Teknologi Informasi

Sekalian nyantai di mall Ambasador, rasanya ingin menulis blog yang membahas salah satu matakuliah di MTI UI, yaitu tentang Tatakelola Teknologi Informasi yang diajarkan oleh Bapak Budi Yuwono. Kali ini saya akan membahas mengenai Rancangan Tatakelola Teknologi Informasi, yang berisi antara lain tentang: fokus tatakelola TI; tips tatakelola TI perusahaan yang sukses; ciri-ciri tatakelola TI yang efektif; elemen-elemen inti dalam tatakelola TI; dan bidang-bidang yang perlu ditatakelola.

Menurut Weill & Ross (2004), fokus tatakelola TI bukan pada teknik pengambilan keputusan, akan tetapi penugasan kepada siapa yang secara sistematis melakukan dan memberikan pendapat pada pengambilan kebutusan tersebut, dengan cara menerapkan mekanisme yang mendorong perilaku yang selaras dengan misi, strategi, nilai, norma, dan budaya perusahaan. Perusahaan yang berusaha meraih tatakelola TI yang baik, seharusnya memiliki keyakinan dan budaya yang mencerminkan pernyataan tentang nilai-nilai, prinsip-prinsip, misi dan strategi perusahaan yang telah ditentukan.

Selanjutnya, saya akan membahas mengenai langkah-langkah yang harus ditempuh agar perusahaan dapat mencapai tatakelola TI yang sukses. Langkah-langkah tersebut antara lain adalah: Pertama, pihak eksekutif harus dapat memastikan bahwa investasi TI bermanfaat bagi bisnis. Karena prediksi mengenai tingkat kemanfaatan TI dapat dilihat dari bagaimana perusahaan tersebut melakukan tatakelola terhadap TI-nya. Kedua, dalam pengambilan keputusan tentang TI selalu melibatkan pihak-pihak lain, terutama pihak-pihak yang memang berkompeten di bidang TI. Ketiga, memiliki cara yang efektif untuk mengambil keputusan tentang TI dan teknik yang efektif untuk mengimplementasikan keputusan-keputusan tersebut. Keempat, perusahaan dengan jelas menyatakan peran TI dalam mendukung strategi bisnisnya. Kelima, selalu melakukan pengukuran dan pengelolaan investasi dan manfaat dari penerapan TI. Keenam, perusahaan harus menentukan siapa saja yang bertanggungjawab terhadap perombakan bisnis guna dapat memanfaatkan keunggulan layanan TI baru. Ketujuh, perusahaan harus selalu mau untuk belajar melalui pengalaman-pengalaman dari setiap proyek implementasi TI, sehingga dapat menentukan aset-aset TI yang dapat di-sharing/di-reuse kembali.

Terus, bagaimana sih ciri-ciri suatu perusahaan mempunyai tatakelola TI yang efektif. Ciri-cirinya antara lain adalah: Pertama, tatakelola TI perusahaan harus mampu digunakan menjembatani perdebatan tentang cara baru dalam memanfaatkan TI; Kedua, dalam melakukan pemilihan kualitas TI tidak hanya berprioritas pada nilai tambah TI yang direncanakan, akan tetapi harus memperhatikan proses cara pemilihannya; Ketiga, adanya pendelegasian terhadap pengambilan keputusan TI kepada pihak yang mengerti kebutuhan TI secara transparan, tentunya dengan memperhatikan arahan pimpinan; Kelima, tatakelola TI mampu mengakomodasi secara transparan dilema dalam keputusan-keputusan TI. 

Selanjutnya, saya akan membahas mengenai elemen-elemen dalam tatakelola TI. Secara garis besar, terdapat tiga elemen utama dalam tatakelola TI yang efektif, yaitu tatakelola TI tersebut harus mengatur antara lain: Pertama, (what) bidang-bidang keputusan apa saja yang harus diambil untuk memastikan bahwa pemanfaatan TI benar-benar efektif. Kedua, (who) siapa saja orang yang harus memutuskan bidang-bidang kebutusan tersebut. Ketiga, (how) bagaimana prosedur pengambilan keputusan-keputusan tersebut dan bagaimana prosedur monitoring terhadap implementasi hasil keputusan.

Terdapat lima bidang keputusan kunci yang perlu ditatakelola. Pada gambar berikut, saya akan menampilkan lima bidang tersebut.

Lima bidang yang harus ditatakelola (Weill & Ross, 2004)

Pada gambar di atas mengilustrasikan kelima wilayah pembagian, dimana perusahaan harus melakukan tatakelola. Kelima bidang tersebut antara lain:

1. Bidang prinsip-prinsip TI
Prinsip-prinsip TI merupakan pernyataan terperinci tentang ekspektasi/harapan terhadap TI dalam mendukung strategi bisnis perusahaan. Perusahaan yang ingin sukses dalam penerapan TI-nya harus mampu mengeksplisitkan prinsip-prinsip kunci tentang bagaimana perusahaan memanfaatkan TI. Idealnya adalah, prinsip-prinsip tersebut dapat dinyatakan sebagai berikut: "Bagaimana konsep operasi (operation model) perusahaan ?", "Bagaimana TI mendukung konsep operasi tersebut ?", "Terus, bentuk investasi TI apa yang akan dipilih ?".

2. Bidang arsitektur TI
Pada bidang ini, tatakelola TI harus berperan dalam menentukan keputusan dalam rancangan arsitektur TI. Termasuk didalamnya adalah standarisasi proses, arsitektur data, dan juga arsitektur teknologi. Selain itu, dalam bidang ini tatakelola TI harus berperan dalam menentukan kebijakan  tentang apa saja yang termasuk dalam kategori infrastruktur dan suprastruktur (aplikasi), dengan pertimbangan efisiensi dan fleksibilitas.

3. Bidang infrastruktur TI
Pada bidang ini, tatakelola TI harus berperan dalam menentukan kemampuan infrastruktur TI yang tinggi, sehingga memiliki kemampuan time-to-market, tingkat pertumbuhan, tingkat penjualan produk yang tinggi pula. Selain itu, bidang yang harus ditatakelola TI adalah keputusan-keputusan tentang infrastruktur TI, termasuk antara lain: "Siapa pemilik layanan infrastruktur TI ?", "Apakah layanan infrastruktur TI memilih untuk di-outsource ?",  "Berapa biaya layanan infrastruktur ?", "Kapan layanan infrastruktur perlu di-update ?".

4. Bidang aplikasi bisnis
Pada bidang ini, tatakelola TI harus berperan dalam menentukan aplikasi-aplikasi yang diperlukan untuk mendukung bisnis perusahaan. Terdapat dua tujuan yang bertolak belakang dalam identifikasi aplikasi bisnis, yaitu: Kreatifitas, melakukan eksperimental untuk mencari tahu cara baru yang lebih efektif untuk meningkatkan nilai tambah bagi konsumen atau merealisasikan strategi bisnis. Pada tujuan ini, perusahaan lebih fokus terhadap bagaimana meningkatkan efektifitas proses utama (core). Disiplin, pada tujuan ini, perusahaan berusaha menjaga integritas arsitektur aplikasi bisnis, perusahaan lebih memfokuskan dalam membangun aplikasi bisnis yang sudah dimiliki.
Selain itu, pada bidang aplikasi bisnis ini perlu dilakukan manajemen proyek pengembangan yang berfungsi untuk mengelola resiko-resiko yang positif.

5. Bidang investasi TI dan prioritasi
Pada bidang ini, tatakelola TI harus berperan dalam menentukan keputusan investasi dan prioritasi. Secara umum terdapat tiga isu utama dalam menentukan keputusan investasi, antara lain: "Berapa total investasi yang harus dikeluarkan ?", "Investasi dikeluarkan untuk kebutuhan apa ?", "Bagaimana cara mengakurkan kebutuhan investasi terhadap pihak-pihak yang berbeda ?"
Untuk menentukan prioritas investasi TI, perusahaan dapat menentukannya berdasarkan return (kembalian) dan risk (resiko). Portofolio investasi TI dapat digunakan untuk membantu kita dalam memprioritaskan investasi TI.

Portofolio Investasi TI (Weill & Ross, 2004)

Dari portofolio investasi di atas, terdapat empat kwadran yang menggambarkan kategori investasi proyek-proyek TI, yaitu: Strategis, investasi untuk menciptakan keunggulan yang kompetitif. Informasional, investasi TI yang diperuntukkan untuk penyedia informasi. Transaksional, investasi TI yang diperuntukkan untuk pemrosesan dan otomasi transaksi. Infrastruktur, investasi yang diperuntukkan untuk layanan umum dan infrastruktur.
Dari kategori-kategori tersebut, perusahaan tinggal memilih, bagian mana yang lebih diprioritaskan untuk dilakukan investasi. Tentunya sangat bergantung pada kebutuhan bisnis perusahaan tersebut.


Demikian uraian saya tentang Rancangan Tatakelola TI. Mudah-mudahan, tulisan ini bermanfaat bagi kita semua....

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.