METODELOGI PENGEMBANGAN APLIKASI INTERPRISE

Pengertian metodelogi pengembangan enterprise

Secara garis besar, ERP bisa digambarkan sebagai perkakas manajemen yang menyeimbangkan persediaan dan permintaan perusahaan secara menyeluruh, berkemampuan untuk menghubungkan pelanggan dan supplier dalam satu kesatuan rantai ketersediaan, mengadopsi proses-proses bisnis yang telah terbukti dalam pengambilan keputusan, dan mengintegrasikan seluruh bagian fungsional perusahaan; sales, marketing,logistics, purchasing, finance, new product development, dan human resources. Sehingga bisnis dapat berjalan dengan tingkat pelayanan pelanggan dan produktifitas yang tinggi, biaya dan inventory yang lebih rendah, dan menyediakan dasar untuk e-commerce yang efektif.

Dari semua pengembangan teknologi sistem informasi dewasa ini, satu sistem informasi yang didesain untuk mendukung keseluruhan unit fungsional dari perusahaan adalah Enterprise Resource Planning atau ERP.

ERP adalah suatu paket piranti lunak (software) yang dapat memenuhi kebutuhan suatu perusahaan dalam mengintegrasikan keseluruhan aktivitasnya, dari sudut pandang proses bisnis di dalam perusahaan atau organisasi tersebut.

Sistem aplikasi ERP adalah salah satu sistem informasi yang tercanggih yang bisa didapatkan pada awal abad 21 ini. Untuk dapat mengadopsi teknologi ERP, suatu perusahaan tidak jarang harus menyediakan dana dari ratusan juta hingga milyaran rupiah. Dana sebesar itu harus disediakan untuk investasi paket software ERP, hardware berupa server dan desktop, database dan operating sistem software, high performance network, hingga biaya konsultasi untuk implementasi. Meskipun dihalangi oleh biaya investasi yang besar, banyak perusahaan di dunia dan tidak terkecuali di Indonesia seperti berlomba-lomba untuk mengadopsi sistem informasi ini. Hal ini karena paket software ERP yang diimplementasikan secara baik akan menghasilkan ”return” terhadap investasi yang layak dan dalam waktu cepat. Karena ERP menangani seluruh aktivitas dalam organisasi, membawa budaya kerja baru dan integrasi dalam organisasi. mengambil alih tugas rutin dari personel dari tingkat operator hingga manajer fungsional, sehingga memberikan kesempatan kepada sumber daya manusia perusahaan untuk berkonsentrasi dalam penanganan masalah yang kritis dan berdampak jangka panjang.

ERP juga membawa dampak penghematan biaya (cost efficiency) yang signifikan dengan adanya integrasi dan monitoring yang berkelanjutan terhadap performance organisasi. Secara implisit ERP bukan hanya suatu software semata, namun merupakan suatu solusi terhadap permasalahan informasi dalam organisasi.

Enterprise Resource Planning (ERP) dapat didefinisikan sebagai aplikasi sistem informasi berbasis komputer yang dirancang untuk mengolah dan memanipulasi suatu transaksi di dalam organisasi dan menyediakan fasilitas perencanaan, produksi dan pelayanan konsumen yang real-time dan terintegrasi.

ERP merupakan suatu sistem yang terintegrasi, sehingga sistem ERP mampu memberikan kepada organisasi penggunanya suatu model pengolahan transaksi yang terintegrasi dengan aktivitas di unit bisnis lain dalam organisasi. Dengan mengimplementasikan proses bisnis standar perusahaan dan database tunggal (single database) yang mencakup keseluruhan aktivitas dan lokasi di dalam perusahaan, ERP mampu menyediakan integrasi di antara aktivitas dan lokasi tersebut. Sebagai hasilnya, ERP sistem dapat mendorong ke arah kemampuan pengambilan keputusan yang lebih baik dengan parameter yang terukur secara kuantitatif. Sehingga keputusan yang dihasilkan tersebut dapat saling mendukung proses operasional perusahaan atau organisasi.

Implementasi ERP

Dalam implementasi ERP dibutuhkan orang-orang yang bisa menterjemahkan bahasa2 bisnis menjadi bahasa2 teknikal. Karena umumnya yang terlibat adalah orang internal perusahaan yang belum pernah melakukan hal yang sama sebelumnya, maka diperlukan konsultan. Dengan adanya konsultan plus project manager yang bekerja sama dengan orang internal perusahaan, maka scope yang sudah disetujui bersama dapat dilaksanakan dengan menggunakan metodologi yang tepat sehingga tujuan proyek dapat tercapai. Konsultan sering adalah orang yang juga mengetahui teknikal sampai detil. Disitu pun ada pembagian tugasnya, ada konsultan yang fokus pada functional, ada yang fokus pada teknikal. Pada proyek ini, software hanyalah salah satu komponen di dalam proyek. Hal lainnya yang justru paling penting adalah manusianya: user, manajernya sampai top manajemennya. Tidak heran kalau semua level perlu terlibat di dalamnya. Komunikasi antara semua level harus terjalin dengan benar dan baik. Termasuk prosedur eskalasinya, jika ada issue dan masalah.

Secara sederhana, setelah proyek dimulai, ada beberapa lapisan penting yang perlu ditangani dan ditindak-lanjuti :

1. Infrastruktur, Mulai dari hardware, server, network, printer dan berbagai alat teknologi lainnya.

2. Struktur organisasi: Menggambarkan bentuk organisasi setelah ERP go-live. Selalu ada perubahan yang dibutuhkan.

3. Master data: Tanpa data yang bersih, sistem tidak akan berjalan dengan baik. Istilahnya garbage in, garbage out.

4. Proses bisnis: Proses yang mengikuti practice yang benar (bukan yang ngawur) yang kemudian diterjemahkan menjadi prosedur dan instruksi kerja bagi setiap staff.

5. Report dan forms: Semua yang menyangkut print out, dokumen legal bisnis dan laporan untuk digunakan oleh manajemendalam menjalankan perusahaan.

6. Otorisasi: Hal ini menyangkut pembagian tugas, siapa yang melakukan apa. Tidak semua orang diperbolehkan melakukan semua hal di dalam sistem.

METODE XP

Pada penelitian kali ini metodologi pengembangan yang akan digunakan adalah metodologi pengembangan Agile dengan XP (Extreme Programming) yang disesuaikan untuk pengembangan bahan ajar berbasis web. Alasan digunakannya model Agile dalam pengembangan ini lebih dikarenakan sifat dari perangkat lunak yang dikembangkan.

Aplikasi berbasis web mempunyai karakteristik yang berbeda dengan aplikasi perangkat lunak konvensional, menurut Lowe dan Brian Henderson (2001) secara umum perbedaan antara web dengan aplikasi konvensional dikarenakan karena sifat unik dari sistem yang terkoneksi dengan internet yang teknis; berhubungan dengan teknologi spesifik yang digunakan dan bagaimana teknologi itu mempunyai dampak pada struktur aplikasi, dan perbedaan yang bersifat organisasional; berhubungan dengan bagaimana suatu organisasi menggunakan sistem tersebut. Perbedaan itulah yang menyebabkan pengembangan suatu aplikasi berbasis web perlu diperlakukan berbeda dengan pengembangan aplikasi konvensional, seperti yang dikatakan Lowe (2001) karakteristik unik dari web membutuhkan perubahan dari metodologi pengembangan. Tabel 3.3 memperlihatkan aspek dari sebuah metodologi pengembangan aplikasi berbasis web yang optimal menurut Ceglarek (2003).

XP Values

Intinya, XP itu punya values:

• Communication
• Simplicity
• Feedback
• Courage

XP menekankan pada Collaboration, Quick & Early Software Creation, dan Skillful Development Practices. Seperti halnya Agile Methods yang lain, XP juga menganut bahwa “Software is the primary measure of project progress”.

Core Practice

Adapun core-practices-nya adalah:

1. Planning Game
2. Small, frequent releases
3. System metaphors
4. Simple design
5. Testing (unit testing & TDD)
6. Frequent refactoring
7. Pair programming
8. Collective code ownership
9. Continuous integration
10. Sustainable pace
11. Whole team together
12. Coding standards

Metodologi yang ada sekarang ini terbentuk menjadi dua jenis metodologi klasik atau biasa dikenal dengan sebutan “heavyweight” dan metodologi baru yang lebih lincah atau yang dikenal dengan “Agile” atau “lightweight”. Metodologi klasik mengedepankan proses tradisional yang biasa digunakan dalam pengembangan sistem yang ditentukan oleh perencanaan yang linear, analisa, rancangan, pengujian dan implementasi yang terikat oleh dokumentasi. Ada beberapa kekurangan pada pendekatan klasik seperti masalah tidak akan teridentifikasi hingga proses pengujian dan akan memakan biaya yang tidak sedikit untuk memperbaiki. Metodologi pengembangan tradisional tidak begitu sesuai untuk diterapkan pada pengembangan web yang cepat berubah dan lebih dinamis serta pengembangan klasik yang terlalu restriktif dan kurang fleksibel untuk perubahan akan menghambat evolusi dari suatu web, metodologi yang lebih ringan dengan menggunakan model Agile dan metodologi XP (Extreme Programming) digunakan pada pengembangan bahan ajar berbasis web ini, karena merupakan metodologi yang ringan dan fleksibel terhadap perubahan.

Penggunaan model Agile juga didukung oleh survei yang dilakukan oleh www.agilealliance.com, dalam survey tersebut diperoleh hasil sebanyak 84.7% responden berpendapat bahwa mereka cukup mengetahui tentang model pengembangan Agile, hasil survey tersebut dapat dilihat pada gambar 3.1.

Gambar 3.1 Tingkat Pengetahuan Pengguna Terhadap Model

Model pengembangan Agile juga terbukti dapat meningkatkan kualitas dari perangkat lunak yang dibuat sebanyak 88% responden berpendapat bahwa penggunaan Agile meningkatkan kualitas perangkat lunak mereka dan 11% berpendapat tidak berpengaruh, dapat dilihat pada gambar 3.2.

Gambar 3.2 Pengaruh Agile Terhadap Kualitas

Pemilihan metodologi XP (Extreme Programming) dipilih karena merupakan metode dari model Agile yang paling banyak digunakan berdasarkan hasil survei dari www.agilealliance.com, yang menunjukan bahwa sebagian besar responden menggunakan metodologi XP sebagai metodologi Agile mereka.

Gambar 3.3 Metodologi Agile

Model pengembangan dari aplikasi berbasis web ini akan mengacu kepada siklus hidup proses dari XP yang telah disesuaikan untuk pengembangan situs ini yang dijelaskan sesuai dengan deskripsi menurut Beck’s (1999). Alasan dipilihnya metodologi XP dibanding metodologi Agile lainnya dikarenakan XP memungkinkan pengembangan perangkat lunak meskipun terjadi banyak perubahan kebutuhan menurut Abrahamsson dan Salo (2002), iterasi pendek dengan rilis kecil dan umpan balik yang cepat, partisipasi klien, komunikasi dan koordinasi, pengujian dan integrasi berkelanjutan, kepemilikan kode kolektif, dokumentasi yang tidak terlalu banyak dan pemrograman berpasangan merupakan karakterisitik dari XP yang membuat XP digunakan pada pengembangan situs ini.

Siklus hidup XP terdiri dari lima seperti deskripsi Beck’s (1999) fase tersebut adalah, fase eksplorasi, perencanaan, iterasi untuk publikasi, produksi, perawatan dan akhir dalam gambar 3.4.

Gambar 3.4 Siklus Hidup Proses XP dari Situs

Pada tahap eksplorasi, klien dalam hal ini Universitas Gunadarma menuliskan papan cerita yang akan disertakan dalam rilis pertama. Setiap papan cerita mendeskripsikan fitur yang akan disertakan di dalam situs. Pada waktu yang sama pengembang membiasakan diri mereka dengan alat yang digunakan dan teknologi yang digunakan dalam pengembangan. Teknologi yang akan digunakan akan diuji coba dan kemungkinan arsitektur untuk situs akan dieksplorasi dengan membangun suatu situs prototipe. Fase eksplorasi memakan waktu beberapa minggu hingga beberapa bulan tergantung pada seberapa biasa pengembang berinteraksi dengan teknologi yang digunakan.

Fase perencanaan menetapkan skala prioritas untuk cerita dan kesepakatan dari isi situs pada rilis kecil pertama. Pengembang memperkirakan berapa lama waktu yang diperlukan untuk setiap cerita dan kesepakatan akan dibuat berdasarkan hal tersebut. Rentang waktu dari jadwal rilis pertama biasanya tidak melebihi dua bulan. Fase perencanaan sendiri hanya memakan waktu beberapa hari.

Fase iterasi untuk publikasi mencakup beberapa iterasi dari situs sebelum rilis pertama. Jadwal yang dibuat pada fase perencanaan dipecah menjadi beberapa iterasi dimana setiap iterasi memakan waktu satu hingga empat minggu untuk diterapkan. Iterasi pertama membuat suatu situs dengan arsitektur dari situs secara keseluruhan, ini dicapai dengan memilih cerita yang akan mendorong pengembangan struktur dari keseluruhan situs. Klien memutuskan cerita mana yang akan dipilih untuk setiap iterasi, uji fungsional dibuat oleh klien dan dijalankan pada setiap akhir iterasi. Pada iterasi terakhir situs telah siap untuk publikasi.

Fase produksi membutuhkan pengujian ekstra dan pemeriksaan performa dari situs sebelum situs dapat dilepas ke khalayak umum. Pada fase ini perubahan-perubahan baru masih ditemui dan keputusan harus dibuat apakah perubahan tersebut disertakan pada rilis yang ada sekarang. Pada fase ini juga iterasi akan dipercepat dari tiga minggu menjadi satu minggu. Ide dan saran yang tertunda didokumentasikan untuk implementasi yang akan dating sebagai contoh pada saat fase perawatan.

Setelah rilis pertama dibuat untuk penggunaan umum, pengembangan harus tetap menjalankan situs yang telah ada berjalan sembari melakukan iterasi baru. Untuk melakukan hal ini fase perawatan membutuhkan usaha untuk tugas pendukungan pengguna, dan kecepatan pengembangan dapat diperlambat setelah situs telah dipublikasi. Fase perawatan mungkin membutuhkan personil baru di dalam tim dan mengubah struktur tim.

Fase akhir hidup mendekat pada saat pengguna tidak mempunyai cerita apapun untuk diimplementasikan. Ini membutuhkan suatu situs yang memenuhi keinginan pengguna dan juga pada hal lainnya seperti performa dan kehandalan. Ini adalah waktu pada proses XP ketika dokumentasi dari situs yang dibutuhkan pada akhirnya telah ditulis dan tidak ada perubahan yang terjadi pada arsitektur, rancangan, dan kode. Akhir hidup juga dapat terjadi jika situs tidak memberikan apa yang diinginkan pengguna atau jika situs menjadi terlalu mahal untuk pengembangan selanjutnya.

Capability Maturity Model (CMM)

Rekayasa perangkat lunak semata mata tidak menjadi jaminan sebuah proyek pengembangan perangkat lunak bisa berhasil dengan tepat waktu dan tepat budget. Perlu dilakukan manajemen atas proses dari pengembangannya yang meliputi lebih banyak disiplin ilmu manajemen ketimbang ilmu rekayasa perangkat lunak. Banyak pihak melakukan proses yang berbeda beda hingga terdapat berbagai macam model proses. Model yang paling banyak diadopsi oleh industri perangkat lunak adalah model Capability Maturity Model (CMM) yang dikeluarkan oleh Software Engneering Institute (SEI) pada tahun 1986.

Capability Maturity Model (CMM)

CMM ini kemudian diakui secara defacto sebagai standar setelah Departemen Pertahanan Amerika Serikat mensyaratkan perusahaan perusahaan yang boleh ikut tender pengembangan perangkat lunak dalam lingkungan departmennya harus mengantongi sertifikasi CMM minimal level 2. Mungkin ada pernah mendengar atau membaca tentang Capability Maturity Model (CMM) pada profil perusahaan yang bergerak dalam software development. Dan perusahaan itu menyebutkan dalam informasi profilnya telah mencapai CMM level 4. CMM ini merupakan mekanisme kualifikasi sebuah Software Development House yang dapat memberikan gambaran tentang kemampuan perusahaan tersebut dalam melakukan development software. Artikel ini adalah bagian pertama dari tulisan bersambung mengenai Capability Maturity Model (CMM).

Tujuan penulisan dokumen ini adalah untuk memberikan gambaran sederhana tentang CMM beserta kegunaanya. Capability Maturity Model adalah sebuah model yang dikembangkan oleh Software Engineering Institute atas permintaan Departement of Defense(DOD) Amerika Serikat dengan tujuan membuat ujian saringan masuk bagi kontraktor yang mendaftarkan diri untuk menjadi konsultan DOD.

Capability diterjemahkan menjadi kapabilitas yang berarti kemampuan yang bersifat laten. Capability lebih mengarah kepada integritas daripada kapabilitas itu sendiri. Definisi integritas adalah kemampuan untuk menepati janji. Maturity berarti matang atau dewasa. Matang merupakan hasil proses. Dewasa merupakan hasil pertumbuhan. Model didefinisikan sebagai suatu penyederhanaan yang representatif terhadap keadaan di dunia nyata.

Jadi secara keseluruhan CMM dapat didefinisikan sebagai berikut : CMM adalah sebuah penyederhanaan yang representatif yang digunakan untuk mengukur tingkat kematangan sebuah software development house dalam menyajikan/membuat/mengembangkan perangkat lunak sebagaimana telah dijanjikan secara tertulis dalam perjanjian kerja sama. Keyword utama dari CMM adalah mengukur. Mengukur didefinisikan sebagai suatu proses untuk memetakan sebuah kondisi ke dalam sebuah skala/ukuran. Berbicara mengukur kita berbicara :

• Apa yang diukur (parameter)

• Bagaimana cara mengukurnya (metode)

• Bagaimana standard penilaiannya (skala penilaian)

• Bagaimana interpretasinya (artinya bagi manusia)

Parameter adalah attribut dari sebuah entity yang akan diukur. Interpretasi adalah pemetaan dari hasil pengukuran ke dalam bahasa manusia. Mungkin sulit dipahami untuk itu saya beri ilustrasi sebagai berikut : Nilai rata-rata IP mahasiswa perguruan tinggi X adalah 3,5 dari nilai maximum 4. Fakta di atas dapat diinterpretasikan sebagai :

• Mahasiswanya pintar

• Materinya terlalu dangkal

• Mahasiswa jago nyontek

• Nilai bisa dibeli

Untuk mengukur tingkat kematangan sebuah organisasi tidaklah mudah. Proses ini melibatkan serangkaian parameter untuk diukur. Mekanisme yang digunakan adalah mekanisme oberservasi oleh lembaga sertifikasi independen yang melakukan pengamatan terhadap organisasi yang akan dinilai. Untuk menilainya digunakan metode analitical hirarki process (AHP). Sebagai ilustrasi dari metode AHP adalah sistem SKS di kampus kita masing- masing yaitu dengan ada sebuah parameter, nilai dan bobot (sks matakuliah) Capability Maturity Model membuat 5 level/skala kematangan yaitu :

• Initial

• Repeatable

• Defined

• Managed

• Optimized

Level initial bercirikan sebagai berikut :

• Tidak adanya manajemen proyek

• Tidak adanya quality assurance

• Tidak adanya mekanisme manajemen perubahan (change management)

• Tidak ada dokumentasi

• Adanya seorang guru/dewa yang tahu segalanya tentang perangkat lunak yang

dikembangkan.

• Sangat bergantung pada kemampuan individual

Level Repeatable bercirikan sebagai berikut :

• Kualitas perangkat lunak mulai bergantung pada proses bukan pada orang

• Ada manajemen proyek sederhana

• Ada quality assurance sederhana

• Ada dokumentasi sederhana

• Ada software configuration managemen sederhana

• Tidak adanya knowledge managemen

• Tidak ada komitment untuk selalu mengikuti SDLC dalam kondisi apapun

• Tidak ada statiskal control untuk estimasi proyek

• Rentan terhadap perubahan struktur organisasi.

Level Defined bercirikan :

• SDLC sudah dibuat dan dibakukan

• Ada komitmen untuk mengikuti SDLC dalam keadaan apapun

• Kualitas proses dan produk masih bersifat kwalitatif bukan kualitatif (tidak terukur hanya

kira-kira saja)

• Tidak menerapkan Activity Based Costing

• Tidak ada mekanisme umpan balik yang baku

Level Managed bercirikan :

• Sudah adanya Activity Based Costing dan dan digunakan untuk estimasi untuk proyek

berikutnya

• Proses penilaian kualitas perangkat lunak dan proyek bersifat kuantitatif.

• Terjadi pemborosan biaya untuk pengumpulan data karena proses pengumpulan data masih

dilakukan secara manual

• Cenderung bias. Ingat efect thorne, manusia ketika diperhatikan maka prilakunya cenderung

berubah.

• Tidak adanya mekanisme pencegahan defect

• Ada mekanisme umpan balik

Level Optimized bercirikan :

• Pengumpulan data secara automatis

• Adanya mekanisme pencegahan defect

• Adanya mekanisme umpan balik yang sangat baik

• Adanya peningkatan kualitas dari SDM dan peningkatan kualitas proses.

Ekivalensi CMM dengan programming. Programming atau pembuatan program dapat dibuat kesamaannya dengan CMM. Programming in small (coding red) ekivalen dengan CMM level 1. Programming in large (proyek managemen, documentasi, dll) ekivalen dengan CMM level 2. Keduanya dapat dikelompokan menjadi programming as art proccess karena tidak memiliki unsur engineering. Unsur engineering yang perlu ditambahkan adalah standarisasi (pembakuan) dan pengukuran. Jika sudah dilakukan standarisasi maka ekivalen dengan CMM level 3. Jika sudah ada pengukuran maka ekivalen dengan CMM level 4. Jika sudah sampai di level 4 maka programming dapat dianggap sebagai engineering process. Keseluruhan level dari 1-4 dapat dipandang sebagai programming as discreet process dimana tidak ada pengembangan berkelanjutan (life time quality improvment) . Baru pada level 5 programming dapat dianggap sebagai continues process dimana peningkatan kualitas sumber daya manusia dan proses dilakukan secara terus menerus. Kegunaan CMM meliputi :

• Menilai tingkat kematangan sebuah organisasi pengembang perangkat lunak

• Memfilter kontraktor yang akan menjadi pengembang perangkat lunak

• Memberikan arah untuk peningkatan organisasi bagi top managemen di dalam sebuah

organisasi pengembang perangkat lunak

• Sebagai alat bantu untuk menilai keunggulan kompetitif yang dimiliki sebuah perusahaa

Zachman Framework

Zachman Framework merupakan model enterprise architecture menyangkut hal-hal yang dibutuhkan untuk mendukung suatu struktur perusahaan dengan menggunakan model yang sederhana bagi segala macam subjek. Pengklasifikasian sistem dalam Zachman Framework

ditunjukkan secara grafis.

Dengan menggunakan pemodelan sistem informasi, akan dapat diperoleh pemahaman mengenai suatu organisasi. Sehingga, dapat dilakukan penilaian terhadap misi, tujuan, strategi bisnis serta apa yang dihasilkan oleh organisasi tersebut. Demikianlah kiranya sehingga Zachman

Framework dapat digunakan sebagai cara untuk mengorganisasi bisnis proses sehingga organisasi dapat memandang kondisi saat ini, visi masa depan dan masa transisinya.

Zachman Framework, dikeluarkan oleh Zachman Institut for Framework Advancement (ZIFA) sebagai hasil pemikiran dari John Zachman. John Zachman mempublikasikan pendekatan yang berbeda untuk system development.

Zachman Framework tidak menentukan dari mana aktifitas pengembangan aplikasi mulai dilakukan. Penggunaan asumsi dapat digunakan untuk menentukan kontrol terhadap ruang lingkup disain sistem. Untuk melakukan penegasan validasi asumsi, organisasi dapat menggunakan Zachman rows bersilangan dengan Zachman column untuk mendapatkan

true drivers yaitu:

1. What,

2. How,

3. Where,

4. Who,

5. When, dan

6. Why

John Zachman mendefinisikan kolom dalam matriks untuk menggambarkan data, fungsi, lokasi (dimana bisnis berada), orang-orang yang seharusnya ada dan terlibat dalam organisasi, waktu untuk peristiwa yang terjadi, dan motivasi yang menentukan bagaimana bisnis berjalan. Kemudian, pada bagian baris digambarkan mengenai aspek-aspek development process

yaitu: ruang lingkup, model bisnis, model sistem informasi, model teknologi, komponen model, dan sistem fungsi.

Zachman Framework menggambarkan arsitektur organisasi secara umum dan menguraikannya sebagai enterprise system yang kompleks. Dalam dunia bisnis, organisasi akan dituntut untuk melakukan manajemen terhadap perubahan. Tujuan dari manajemen perubahan berhubungan

dengan keunggulan bersaing antara organisasi dengan para pesaingnya. Zachman Framework diperkenalkan sebagai standar yang telah digunakan oleh organisasi-organisasi sukses dunia. Contohnya: Johnson and Johnson,

Federal Express, Hewlett-Packard, Microsoft, dan lain-lain. Berikut ini merupakan uraian matriks Enterprise Architecture Zachman Framework yang diimplementasikan di Fakultas Teknologi Informasi.

Model-driven architecture (MDA)

Model-driven architecture (MDA™) adalah sebuah pendakatan perancangan perangkat lunak yang diluncurkan oleh Object Management Group (OMG)^[1] in 2001.

MDA mendukung rekayasa model-driven dari sistem perangkat lunak. MDA menyediakan sekumpulan panduan untuk menstrukturkan spesifikasi yang dinyatakan sebagai model. Pendekatan MDA mendefinisikan fungsionalitas sistem menggunakan sebuah platform-independent model (PIM) dengan memakai sebuah domain-specific language yang sesuai. Kemudian, diberikan sebuah platform definition model (PDM) berupa CORBA, .NET, the Web, dll., PIM diterjemahkan ke dalam satu atau lebih platform-specific model (PSM) yang dapat dijalankan oleh komputer. PSM dapat menggukanan Domain Specific Language yang berbeda, atau sebuah General Purpose Language seperti Java, C#, PHP, Python, dll.. Kakas otomatis umumnya yang melakukan penerjemahan ini.

Organisasi OMG sekedar menyediakan spesifikasi kasar dan bukan implementasi, kadang-kadang merupakan jawaban atas Requests for Proposal (RFP). Implementasi datang dari perusahaan swasta atau kelompok open source.

Prinsip-prinsip MDA dapat juga diterapkan pada area lain sepertibusiness process modeling dimana PIM diterjemahkan ke dalam proses otomatis atau manual.

Pendekatan MDA

OMG memfokuskan Model-driven architecture pada rekayasa maju (forward engineering), yaitu, menghasilkan kode yang berasal dari abstraksi, spesifikasi pemikiran manusia. Grup ADTF (Analysis and Design Task Force) dari OMG memimpin usaha ini. Dengan sedikit candaan, grup tersebut memilih ADM (kebalikan dari MDA) sebagai nama dari studi reverse engineering. ADM kependekan dariArchitecture-Driven Modernization. Tujuan ADM adalah untuk menghasilkan standard-standard bagi rekayasa balik berbasis model untuk sistem lawas (legacy system) ^[2]. Knowledge Discovery Metamodel (KDM) adalah salah satu yang dicapai oleh usaha tersebut, dan mendeskripsikan sistem nformasi ke dalam pengertian dari beragam aset (program, spesifikasi, data, file-file uji, skema basis data, dll.).

Salah satu tujuan dari MDA adalah memisahkan rancangan dari arsitektur. Sebagaimana konsep dan teknologi yang digunakan untuk mewujudkan rancangan, dan, konsep dan teknologi yang digunakan untuk mewujudkan arsitektur telah berubah sendiri-sendiri, saling lepas antar keduanya memungkinkan pengembang sistem untuk memilih yang terbaik dan yang paling tepat dalam kedua ranah. Rancangan mengarah pada kebutuhan fungsional (use case) sedangkan arsitektur menyediakan infrastruktur yang diwujudkan melalui kebutuhan non-fungsional seperti skalabilitas, reliabilitas dan kinerja. MDA memandang bahwa platform independent model (PIM), yang merepresentasikan sebuah rancangan konseptual yang mewujudkan kebutuhan kebutuhan fungsional, akan bertahan terhadap perubahan dalam realisasi teknologi dan arsitektur perangkat lunak.

Hal yang penting dari model-driven architecture adalah pengertian transformasi model. Sebuah bahasa baku khusus untuk transformasi model yang telah didefinisikan oleh OMG disebut QVT.

Rational Unified Process

RUP, singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan mereka.