Dynamic Systems Development Dan SDLC Metode Agile

Pembuatan sistem informasi yang lengkap secara keseluruhan memakan waktu lama dengan tingkat resiko kegagalan yang tinggi. Salah satu metodologi dalam pembuatan sistem informasi adalah Dynamic Systems Development Method (DSDM), dengan konsep dasar pengembangan secara berulang dan bertambah. Berkembang pula metode pengembangan sistem berbasis open source, yaitu di mana pengembang dan pengguna saling bekerja sama secara longgar menggunakan media Internet. Modifikasi dari DSDM diperlukan sedemikian rupa sehingga model pengembangan open source dapat dimanfaatkan secara optimal.

1. Pendahuluan

Pembuatan sistem informasi yang lengkap secara keseluruhan memakan waktu lama dengan tingkat resiko kegagalan yang tinggi. Metodologi yang telah mapan seperti Waterfall tidak selalu cocok dengan kondisi pembuatan sistem di mana perubahan adalah cepat, anggaran dan waktu yang tersedia terbatas. Berkembang teknik pembuatan prototip (prototyping) dan pengembangan secara bertambah (incremental development) dengan membangun model-model percontohan dari sistem dan memecah pengerjaannya dalam tahapan-tahapan sesuai skala prioritas. Salah satu metodologi yang menggunakan teknik ini adalah Dynamic Systems Development Method (DSDM), dengan konsep dasar pengembangan secara berulang dan bertambah.

Berkembang pula pengembangan sistem berbasis open source, yaitu di mana pengembang dan pengguna saling bekerja sama secara longgar menggunakan media Internet. Metode ini dapat membantu mempercepat pengembangan sistem informasi mengingat sumber daya yang tersedia di Internet sedemikian melimpah. Modifikasi dari DSDM diperlukan sedemikian rupa sehingga model pengembangan open source dapat dimanfaatkan secara optimal. Teknik yang berkembang dalam rekayasa perangkat lunak, yaitu rekayasa pemakaian ulang, dapat digunakan untuk memodifikasi sistem yang telah ada sehingga tidak perlu membangun dari awal.

Pada bab 2 akan dijelaskan teori-teori yang berkaitan dengan pengembangan sistem informasi, DSDM dan model open source. Bab 3 akan menganalisa studi kasus, yaitu sistem editorial majalah Z, beserta modifikasi metodologi yang diperlukan. Penerapan dan pembahasan akan disampaikan pada bab 4. Kesimpulan dari makalah ini ada pada bab 5.

2. Landasan Teori

2.1. Information System Development Methodology (ISDM)

Menurut Buckingham et al. (1987), sistem informasi adalah suatu sistem yang merakit, menyimpan, memproses, dan menghasilkan informasi yang relevan untuk suatu organisasi (atau komunitas), sedemikian rupa sehingga informasi dapat dijangkau dan bermanfaat bagi mereka yang menggunakan, termasuk manager, staf, klien dan masyarakat. Sebuah sistem informasi adalah sistem aktivitas manusia (sosial) yang mungkin atau tidak melibatkan penggunaan dari sistem komputer.

Beberapa bagian dari sistem informasi, merupakan suatu cara dari melihat komponen-komponen yang saling berinteraksi, yaitu:

• Orang, misalnya analis sistem, pemakai, dan pengurus.
• Obyek, misalnya perangkat komputer, antarmuka pemakai, jaringan telekomunikasi, Internet atau situs web.
• Prosedur, misalnya proses bisnis, ISDM, dan aturan bisnis.
• Organisasi, misal: perusahaan, satuan kerja atau komunitas.

Menurut Avison dan Fitzgerald, ISDM adalah: “Suatu koleksi dari prosedur, teknik, perangkat, dan dokumentasi yang membantu pengembang sistem dalam usahanya untuk menerapkan sistem informasi yang baru. Sebuah metodologi terdiri dari tahap-tahap, berikut pula sub tahap, yang memandu para pengembang sistem pada teknik yang dipilih yang mungkin sesuai pada tiap tahapan proyek, juga membantu mereka dalam merencanakan, mengelola, mengatur dan mengevaluasi proyek-proyek dalam sistem informasi.” [5]

Metodologi tidak hanya koleksi dari yang disebutkan, tetapi merupakan pandangan filosofikal, dengan kata lain merupakan sebuah metode atau resep. Teknik dan alata bantu atau perangkat kerja berperan dalam setiap metodologi. Teknik adalah cara dalam melakukan suatu kegiatan dalam proses pengembangan sistem informasi. Suatu metodologi mungkin menyarankan suatu teknik tertentu. Setiap teknik dapat melibatkan penggunaan satu atau lebih perangkat yang merupakan artefak dalam pengembangan sistem informasi. Suatu metodologi juga bisa menyarankan suatu alat dalam melakukan prosesnya.

Beberapa tujuan dari metodologi sebagai berikut:

• Mencatat secara akurat kebutuhan untuk sebuah sistem informasi.
• Menyediakan metode pengembangan secara sistematis sehingga perkembangan yang terjadi dapat diawasi secara efektif.
• Menyediakan sebuah sistem informasi dalam waktu yang memadai dan biaya yang dapat diterima atau disetujui.
• Menghasilkan sebuah sistem yang terdokumentasi dengan baik dan mudah untuk dipelihara.
• Menyediakan sebuah petunjuk perubahan yang dibutuhkan secepatnya dalam proses pengembangan.
• Menyediakan sebuah sistem yang disukai dari pihak yang terlibat dalam sistem tersebut.

ISDM, dalam usaha untuk membuat efektif penggunaan teknologi informasi, juga berusaha membuat efektif teknik dan perangkat yang tersedia. Bisa dikatakan ISDM juga tentang bagaimana menyeimbangkan aspek teknis dan aspek tingkah laku (dengan orientasi pada orang). Keseimbangan antara dua aspek tersebut adalah salah satu tema berkelanjutan dalam pengembangan sistem informasi.

2.2. Dynamic Systems Development Method (DSDM)

DSDM adalah suatu kerangka kerja awalnya didasarkan pada Rapid Application Development (RAD). DSDM mengutamakan keterlibatan pemakai secara berkesinambungan dengan pendekatan pengembangan secara berulang dan bertambah, tanggap terhadap perubahan, untuk membangun sistem perangkat lunak yang memenuhi kebutuhan bisnis tepat waktu dan tepat anggaran. DSDM merupakan salah satu metode Agile untuk pengembangan perangkat lunak, dan bagian dari Agile Alliance. DSDM pertama kali diperkenalkan pada tahun 1995, di mana merupakan satu-satunya publikasi penggunaan metode RAD di dunia [4].

Sebagai perluasan dari RAD, DSDM memusatkan pada proyek sistem informasi yang dicirikan oleh jadwal dan anggaran yang ketat. DSDM berupaya mengatasi penyebab-penyebab kegagalan proyek, di antaranya melebihi anggaran, terlambat dari jadwal, kurangnya keterlibatan pengguna, dan lemahnya komitmen dari para pimpinan. Kerangka kerja DSDM menyediakan dasar ideal bagi proses pengembangan dan penerapan sistem informasi, meliputi orang (misal organisasi, staf, keahlian), teknologi pendukung (misal teknologi informasi, otomatisasi kantor, komunikasi) dan proses yang menyatukan keduanya (dalam rangkaian strategi bisnis).

DSDM terdiri dari 3 tahapan utama, dan 5 sub tahap. Tahapan utama adalah:

1. Sebelum proyek, di mana kandidat proyek diidentifikasi, pembiayaan proyek terpenuhi, dan jaminan proyek dipastikan. Penanganan hal-hal tersebut pada tahap ini menghindari masalah pada tahap-tahap berikutnya.
2. Siklus hidup proyek, merupakan inti dari DSDM, yang terdiri dari 5 sub tahap yaitu i) studi kelayakan; ii) studi bisnis; iii) perulangan model fungsional; iv) perulangan perancangan dan pembuatan; v) penerapan.
3. Setelah proyek, yaitu memastikan sistem berjalan secara efektif dan efisien. Hal ini diwujudkan dengan perawatan, peningkatan dan perbaikan sesuai prinsip-prinsip DSDM. Perawatan dapat dilihat sebagai usaha meneruskan pengembangan berdasarkan sifat alami DSDM, yaitu perulangan dan pertambahan.

Terdapat 9 prinsip mendasar dari DSDM, yang menjadikan kekuatan dari DSDM, yaitu:

1. Keterlibatan pengguna adalah kunci utama dalam menjalankan proyek secara efisien dan efektif. Pengguna dan pengembang saling bekerja sama sehingga keputusan dapat diambil secara tepat dan akurat.
2. Tim pengembang proyek diberi wewenang untuk membuat keputusan yang penting untuk kemajuan proyek, tanpa menunggu persetujuan dari tingkat di atasnya.
3. Memusatkan pada seringnya produk dihasilkan, dengan anggapan menghasilkan sesuatu ‘cukup baik’ lebih awal adalah lebih baik daripada menghasilkan keseluruhan ‘sempurna’ pada akhirnya. Dengan seringnya penyampaian produk pada tahap-tahap awal proyek, produk tersebut dapat diujicoba dan ditinjau di mana hasilnya merupakan pertimbangan untuk maju ke putaran atau tahap berikutnya.
4. Kesesuaian dari tujuan bisnis merupakan kriteria utama dalam penerimaan hasil. Menghasilkan suatu sistem yang memenuhi semua kemungkinan dari kebutuhan bisnis adalah kurang penting dibanding memusatkan pada fungsi-fungsi yang kritis.
5. Pengembangan secara berulang dan bertambah adalah penting, dilandasi masukan dari pengguna untuk mencapai solusi bisnis yang efektif.
6. Seluruh perubahan yang terjadi dalam pengembangan dapat dikembalikan (reversible).
7. Setiap persyaratan dan kebutuhan harus sudah ditentukan sebelum proyek dimulai.
8. Pengujian dilakukan pada keseluruhan siklus hidup proyek. Dalam hal ini ujicoba bukan kegiatan terpisah dalam pengembangan. Tinjauan dari pengembang dan pengguna adalah penting untuk memastikan proyek berjalan baik dari sisi bisnis maupun teknis.
9. Kerjasama yang efektif dan efisien dari setiap pihak yang berkepentingan adalah penting.

Gambar 1. Siklus hidup DSDM.

Siklus hidup proyek terdiri dari 5 sub tahap, untuk selanjutnya disebut tahap mengingat ini adalah inti dari DSDM, yang menggambarkan 5 tingkatan proyek yang harus dilalui untuk menghasilkan suatu sistem informasi. Dua tahap awal, yaitu studi kelayakan dan studi bisnis merupakan tahap yang berurutan dan keduanya saling melengkapi. Selanjutnya sistem dibangun secara berulang dan bertambah melalui tahap perulangan model fungsional, perulangan perancangan dan pembuatan dan diakhiri pada penerapan.

Kegiatan	Sub Kegiatan	Penjelasan
Studi	Studi Kelayakan	Menilai kelayakan pengerjaan suatu proyek, termasuk kecocokan proyek tersebut dengan penggunaan DSDM. Dihasilkan laporan kelayakan, kelayakan prototip, skema global perencanaan berikut rencana pengembangan dan catatan resiko.
	Studi Bisnis	Analisa karakteristik dari sisi bisnis dan teknologi. Pendekatan utama adalah pengadaan lokakarya, di mana pengguna ahli berkumpul dan menghasilkan hal-hal yang relevan dari sistem serta menyetujui skala prioritas dalam pengembangan. Dihasilkan daftar prioritas kebutuhan, definisi dari wilayah bisnis, definisi arsitektur sistem, dan garis besar rencana prototip.
Perulangan Model Fungsional	Mengenali prototip fungsional	Menentukan fungsionalitas yang akan dikerjakan pada prototip. Dihasilkan sebuah model fungsional menurut hasil dari tingkat studi bisnis.
	Menyetujui jadwal	Setuju pada bagaimana dan kapan untuk membangun fungsionalitas tersebut.
	Membuat prototip fungsional	Membangun prototip fungsional, sesuai jadwal yang disetujui dan model fungsional.
	Meninjau prototip fungsional	Mengecek kebenaran dari prototip yang dibangun. Hal ini dilakukan melalui pengujian oleh pemakai akhir dan / atau melihat dokumentasi. Dihasilkan sebuah dokumen tinjauan prototip model fungsional.
Perulangan Perancangan dan Pembuatan	Mengenali prototip rancangan	Mengenali kebutuhan fungsional dan non-fungsional yang diperlukan dalam sistem yang diujikan. Dihasilkan suatu strategi penerapan, yang juga didasari catatan pengujian dari perulangan sebelumnya.
	Menyetujui jadwal	Setuju pada bagaimana dan kapan memenuhi persyaratan yang ada.
	Membuat prototip rancangan	Membuat sebuah sistem (prototip rancangan) yang dapat secara aman diserahkan kepada pengguna akhir untuk penggunaan harian, juga sebagai ujicoba.
	Meninjau prototip rancangan	Mengecek kebenaran hasil rancangan sistem, melalui serangkaian teknik ujicoba dan peninjauan. Dokumentasi pengguna maupun catatan pengujian akan dibuat.
Penerapan	Persetujuan pemakai dan garis pedoman	Pengguna akhir menyetujui sistem yang telah diuji untuk diterapkan and sebagai pedoman, dengan mematuhi ketentuan sistem yang telah dibuat.
	Melatih pengguna	Melatih calon pengguna dalam penggunaan sistem. Dihasilkan sekelompok pengguna yang terlatih.
	Penerapan	Menerapkan sistem yang telah teruji (tested system) di lokasi pengguna akhir, disebut juga sistem yang tersampaikan.
	Tinjauan bisnis	Meninjau dampak dari penerapan sistem pada bisnis, dengan isu pokok apakah sistem memenuhi tujuan yang ditentukan pada awal proyek. Berdasarkan hal ini proyek akan menuju tahap selanjutnya, yaitu setelah proyek, atau kembali ke salah satu tahap sebelumnya untuk perbaikan lebih lanjut. Hasil peninjauan ini akan didokumentasikan dalam dokumen tinjauan proyek.

Terdapat banyak teknik-teknik pengembangan yang dapat digunakan pada suatu proyek. Tidak ada satu teknik yang sesuai (dengan cara seragam) untuk seluruh proyek, sebaliknya tidak seluruh teknik perlu digunakan untuk setiap proyek. Berikut beberapa teknik penting yang sangat menentukan keberhasilan dari DSDM:

• Pengadaan lokakarya, di mana teknik penting untuk menjaga kemajuan proyek secara cepat dan dalam arah yang tepat, baik dari sisi bisnis maupun teknis. Lokakarya digunakan menyeluruh pada proyek untuk menciptakan produk dan membuat keputusan dengan cepat, serta mengumpulkan pandangan luas dari pihak-pihak terkait.
• MoSCoW, menyajikan cara dalam memprioritaskan persyaratan. Ini adalah suatu singkatan yang berarti:
• Must, persyaratan ini harus ada demi tuntutan bisnis.
• Should, persyaratan ini ada bilamana mungkin, tetapi keberhasilan proyek tidak bergantung padanya.
• Could, persyaratan ini bisa ada, dan tidak mempengaruhi kemampuan dari tuntutan bisnis.
• Would, persyaratan ini dipenuhi di masa depan bila terdapat sisa waktu atau pada pengembangan sistem selanjutnya.
• Pembuatan prototip, yang mendasari keberhasilan dari proyek DSDM. Teknik ini memungkinkan keterlibatan nyata dari pengguna dalam kegiatan pengembangan sejak tingkatan paling awal, dengan demikian memungkinkan pengguna mengendalikan pengembang untuk mencapai keuntungan bisnis yang maksimal. Pembuatan prototip dapat mendorong kreativitas, tetapi hal itu juga perlu dikendalikan.
• Timeboxing, digunakan untuk mendukung tujuan utama dari DSDM dalam mewujudkan pengembangan sistem informasi tepat waktu, sesuai anggaran dan kualitas yang diinginkan. Ide utama pada timeboxing adalah memecah proyek dalam bagian-bagian, masing-masing dengan anggaran dan waktu yang tetap. Bagi setiap bagian ditentukan sejumlah persyaratan yang diutamakan sesuai prinsip MoSCoW. Mengingat waktu dan anggaran bersifat tetap, hanya tersisa persyaratan sebagai variabel, sehingga bila proyek kehabisan waktu atau uang, persyaratan dengan prioritas rendah akan diabaikan. Sesuai prinsip pareto, di mana 80% proyek berasal dari 20% persyaratan, sepanjang 20% hal terpenting dari persyaratan tercapai, dengan demikian telah memenuhi kebutuhan bisnis (dan tidak ada sistem yang terbangun sempurna pada usaha pertama).
• Teknik-teknik pemodelan. Panduan diberikan tentang apa yang dimodelkan, kapan dan bagaimana, memungkinkan setiap organisasi dan proyek menentukan kumpulan terbaik dari model-model yang sesuai keadaan: satu ukuran tidak cocok untuk semua.
• Pengujian, yang dilakukan sepanjang DSDM dalam rangka memastikan bahwa penyelesaian proyek sesuai dengan kualitas yang disyaratkan. Bagian ini menyediakan panduan tentang bagaimana menguji dengan pemusatan pada apa yang harus diselesaikan ketimbang apa yang bisa diselesaikan bila waktu tersedia.
• Pengelolaan konfigurasi, sebagai faktor kunci dalam mengelola perkembangan produk (baik perangkat lunak dan dokumentasi) yang dibuat sepanjang siklus hidup DSDM, dari permulaan proyek hingga hasil akhir dikirimkan. Bagian ini mencakup bagaimana untuk menentukan apa yang dikendalikan dalam pengelolaan konfigurasi, siapa yang bertanggungjawab, dan kapan melaksanakannya.
• Lingkungan pendukung, misalnya alat bantu yang digunakan pengembang dalam membuat produk teknis dari proyek. Lingkungan pendukung adalah faktor penting dalam mempercepat pencapaian hasil. Alat bantu yang buruk akan menghambat kreativitas dari pengembang dalam tim. Panduan disajikan tentang alat apa yang diutamakan, bagaimana memilih yang paling tepat untuk pengembangan secara berulang dan bertambah dari DSDM.

2.3. Pengembangan Sistem Berbasis Open Source

Perangkat lunak berbasis open source menampilkan pendekatan baru dibanding cara-cara tradisional atau pendekatan closed source. Secara metodologi, elemen paling dikenal dari open source adalah tinjauan luas dari sebaya (peer) dan kontribusi yang terdesentralisasi [10]. Sebuah pengertian kunci adalah “berikan cukup bola mata, maka seluruh kesalahan menjadi dangkal”. Metodologi ini terutama dipelopori oleh Linus Torvalds pada pembuatan sistem operasi Linux, yaitu: menciptakan sendiri kode inti; membuatnya tersedia di Internet untuk ditinjau; saring perubahan terhadap kode dasar; dan ketika kode dasar menjadi terlalu besar untuk dikelola oleh satu orang, serahkan tanggungjawab atas komponen utama pada orang yang terpercaya. Dengan demikian kekuatan dari pendekatan open source berasal dari tinjauan besar-besaran dan luas atas program yang disajikan.

Berlawanan dengan dunia akademis dari rekayasa perangkat lunak, komunitas pengembangan open source tidak terlihat siap mengadopsi atau mempraktekkan proses rekayasa perangkat lunak modern. Komunitas tersebut membangun perangkat lunak yang bermanfaat, secara umum handal, tersedia luas, dan siap digunakan untuk kepentingan komunitas pengguna sejawatnya [7]. Komunitas terbentuk dari mereka yang mengidentifikasi diri dalam pengembangan suatu perangkat lunak. Para peserta biasanya mengambil bagian dalam peran berbeda dan memberi kontribusi tersendiri (program, artifak, ujicoba, tinjauan kode, komentar, dll) melalui situs web yang tersedia pada setiap komunitas.

Terdapat 5 jenis tahapan proses dalam pengembangan secara open source. Setiap proses berbeda dari ketentuan rekayasa perangkat lunak tradisional, meski begitu tidak satupun yang berlaku bebas atau lebih penting dari lainnya. Proses-proses ini dapat berlangsung serempak, tidak mesti berurutan seperti pada model siklus hidup tradisional. Berikut tahapan tersebut:

1. Analisa persyaratan dan spesifikasi.
2. Kendali versi yang terkoordinasi, pembuatan sistem, dan penjadwalan hasil secara bertahap.
3. Perawatan sebagai pengembangan ulang yang revolusioner, perbaikan dan penyebaran ulang.
4. Pengelolaan proyek.
5. Transfer teknologi perangkat lunak.

Scacchi menjelaskan organisasi untuk proyek open source sebagai “komunitas longgar dari pengembang dan pengguna yang saling tertarik”. Hal ini khususnya berlaku untuk aplikasi di mana pengguna memiliki pengetahuan luas tentang bidang yang ditanganinya tetapi kurang dari segi teknis, sebaliknya pengembang sangat menguasai teknis aplikasi tapi tidak memiliki pengalaman terhadap pengunaan aplikasi tersebut. Contohnya pada aplikasi perpustakaan dan pengelolaan informasi.

Scacchi juga menyatakan salah satu kelebihan mendasar dari metode pengembangan open source adalah pembentukan dan pembuatan perangkat lunak yang rumit melalui koordinasi lepas dari pengembang dan penyokong yang (dapat) tersebar secara global. Para pelaku ini dapat berupa pegawai yang ditunjuk dan dibayar penuh oleh perusahaan, maupun mereka yang bekerja secara sukarela meluangkan waktu, tenaga dan sumber daya yang tersedia untuk terlibat dalam proyek.

Gacek et al. membuat ilustrasi kebanyakan komunitas open source seperti di bawah (berdasarkan studi kasus Apache, Cocoon, dan NetBSD) [6]. Dalam model diperlihatkan berbagai tugas berkaitan dengan proyek dilakukan dalam peran berbeda, menunjukkan pula keterlibatan orang dalam suatu proyek dapat berganti menurut waktu.

Gambar 2. Ilustrasi komunitas open source.

Eric S. Raymond membedakan metode pengembangan perangkat lunak secara open source menjadi 2 jenis [9], yaitu:

• Katedral. Merupakan cara pengembangan secara konvensional, yaitu tertutup atau closed source, perencanaan secara terpusat, organisasi yang kaku, satu proses dari mulai hingga selesai, dan pengembang menghabiskan waktu pada pencarian kesalahan dan memenuhi permintaan fasilitas.
• Bazar. Merupakan proses utama dalam pengembangan open source, tumbuh secara organik, setiap orang dapat memberi masukan dan berdiskusi tentang itu, pengguna diperlakukan sebagai rekan pengembang, dan pengguna dapat menunjuk langsung pada kesalahan, bahkan membetulkannya.

Beberapa keuntungan dari metode pengembangan open source:

• Mengurangi kerja ganda, mengingat setiap orang dapat memperoleh kode sumber dari program, pengembangan dilakukan pada hal-hal yang belum ada atau memenuhi kebutuhan.
• Pembangunan atas dasar kerja yang lain. Keberhasilan dari proyek open source adalah komunitas yang saling bekerja sama untuk menghasilkan yang lebih besar.
• Kendali kualitas yang lebih baik. Semakin banyak pihak turut serta dalam pengembangan, maka kekurangan-kekurangan dari sistem dapat lebih terlihat.
• Mengurangi biaya perawatan, mengingat beban pengerjaan dipikul bersama.

Metode pengembangan open source sebagai kerja kolaboratif antara para pengembang maupun pengguna, dapat menggunakan teknik-teknik yang berkembang dalam rekayasa perangkat lunak.

Berikut beberapa pokok dari rekayasa pemakaian ulang menurut Ian Sommerville [10]:

• Perancangan dengan pemakaian ulang melibatkan rancangan yang baik dari perangkat lunak dan komponen yang ada.
• Keuntungan yang didapat adalah biaya murah, pengembangan lebih cepat, dan kecenderungan resiko yang rendah.
• Komponen pakai ulang harus bebas, mencerminkan penjabaran stabil dari bidang permasalahan, dan menyediakan akses melalui operasi antarmuka.
• Kelompok aplikasi yang terkait dibangun menggunakan inti bersama.

3. Analisa Masalah

3.1. Sistem Editorial Majalah Z

Sistem Editorial Majalah Z (SEMZ) adalah suatu sistem pengelolaan naskah pada sebuah perusahaan media cetak yang menerbitkan majalah dwi mingguan. Lingkungan kerjanya adalah jaringan intranet perusahaan dan dimungkinkan pengoperasian lewat Internet. Perangkat keras yang digunakan adalah Personal Computer standar, baik sebagai client maupun server.

Berikut tujuan yang ingin dicapai oleh SEMZ:

• Berbiaya murah. Pembuatan sistem sejak awal disyaratkan menggunakan perangkat lunak dengan lisensi yang non komersil, sehingga berbiaya murah, baik itu dibuat sendiri ataupun menggunakan perangkat lunak berbasis open source.
• Mudah digunakan. Pertimbangan utama adalah keterampilan pengguna dalam menggunakan perangkat yang ada, terutama pada era Internet berbasiskan web.
• Mudah diperlihara. Agar terjadi pengelolaan sistem yang berkesinambungan, maka pembuatan perangkat lunak diselaraskan dengan kemampuan petugas Teknologi Informasi (TI) yang tersedia di perusahaan tersebut. Digunakan bahasa pemrograman yang banyak dikuasai, sederhana, mudah dibuat dan dipelihara.
• Mendukung kerja secara keseluruhan redaksional majalah, dimulai dari tahap perencanaan hingga dokumentasi naskah. Sistem diharapkan membuat pengelolaan naskah lebih terpadu dan terkontrol dengan baik.
• Memungkinkan pengembangan dan integrasi dengan sistem lain. Mengingat terdapat beberapa sistem lain, diharapkan sistem yang dihasilkan nantinya dapat dikembangkan dan terintegrasi dengan sistem-sistem tersebut.

Sistem diharapkan mencakup hal-hal utama berikut:

• Alur pengisian naskah, sejak tahap usulan s/d terbit di majalah, baik berupa tulisan maupun foto. Seluruh tahap dalam pengisian naskah sepenuhnya menggunakan komputer.
• Pengisian item penilaian untuk reporter dan fotografer.
• Arsip untuk internal karyawan maupun bagian riset dan dokumentasi.
• Pelaporan dan evaluasi dari statistik naskah untuk pemilik perusahaan dan pihak terkait.

Kondisi yang sedang berjalan adalah pengelolaan naskah menggunakan komputer, dengan program pengolah kata yang tersedia, dan mekanisme pemisahan bagian menggunakan sharing folder yang berbeda-beda sesuai tahapan naskah. Setiap petugas dari masing-masing bagian mengambil naskah dari folder yang bersangkutan, mengolahnya, dan menyimpannya ke folder yang lain. Alur naskah dan folder yang ada tergambar dari bagan berikut.

Gambar 3. Alur naskah dan folder sistem berjalan.

Berdasarkan hasil analisa alur naskah yang berjalan, didapat 8 jenis pembagian kerja dalam pengisian naskah, yaitu:

1. Reporter, yaitu petugas pencari berita. Reporter mendapat tugas liputan dari Koordinator Reporter.
2. Fotografer, yaitu petugas pencari foto. Fotografer mendapat tugas liputan dari Redaktur Foto.
3. Periset, yaitu petugas yang melakukan riset arsip maupun dokumentasi. Periset mendapat tugas riset dari Manager Riset.
4. Penulis, yaitu petugas yang membuat tulisan untuk suatu rubrik. Bahan untuk tulisan berasal dari Reporter, Fotografer dan Periset.
5. Redaktur Kompartemen, yaitu petugas yang melakukan pengecekan tulisan dari Penulis. Redaktur Kompartemen merupakan petugas dengan kewenangan tertinggi yang bertanggungjawab penuh atas pemuatan suatu tulisan.
6. Editor Naskah, yaitu petugas yang melakukan editing final tulisan. Editing meliputi keseluruhan teks, baik berupa tulisan maupun keterangan foto atau gambar.
7. Petugas Tata Muka, yaitu petugas yang membuat layout final tulisan untuk dicetak dalam majalah.
8. Redaktur Eksekutif, yaitu petugas yang menentukan garis besar isi yang akan dibahas dalam majalah. Secara alur berperan dalam finalisasi outline isi.

Pembuatan sistem yang baru tidak mengubah cara kerja menurut sistem yang lama. Hasil analisa permasalahan yang ada pada sistem yang berjalan sebagai berikut:

• Sistem pengelompokan naskah menggunakan sharing folder, sehingga tidak terdapat kontrol terhadap waktu maupun pengawasan atas jalannya naskah atau tulisan.
• Pengaturan kewenangan yang ada sangat terbatas, yaitu sebatas pengaturan hak akses terhadap operasi file, yaitu tidak ada akses (none), hanya baca (read only), dan baca / tulis (read write).
• Arsip untuk bagian Riset dan Dokumentasi dilakukan secara manual. Mengingat perpindahan naskah dilakukan oleh petugas pada masing-masing folder, setiap akhir penerbitan majalah petugas dari bagian TI perlu memindah file-file tersebut baik sebagai arsip maupun kepentingan penerbitan berikutnya.
• Pencarian teks pada naskah maupun foto tidak dapat dilakukan, karena teknik penyimpanan yang berupa file. Petugas TI perlu mengolah secara manual agar file dapat ditemukan.
• Ketergantungan yang tinggi terhadap program pengolah kata, seperti Microsoft Word atau Open Office. Selain itu isi dari file tersebut sulit dipindahkan (non portable) karena menggunakan format dari program pengolah kata tersebut.
• Penilaian berjalan secara terbatas, yaitu manual melalui kertas yang disediakan, hingga tidak berjalan efektif karena pengawasan yang kurang dan tidak terintegrasi.
• Tidak bisa dikerjakan dari tempat lain atau lewat Internet, mengingat sharing folder hanya tersedia dalam jaringan Intranet kantor.
• Keterlibatan proses secara manual, yang dilakukan melalui kertas berjalan, masih cukup tinggi, mengingat teknik penyimpanan file yang sederhana. Dalam prakteknya kebutuhan terhadap kertas dan pencetakan menjadi tidak terhindarkan.
• Lingkungan pengembangan perangkat lunak yang dikuasai oleh petugas TI didominasi oleh bahasa scripting, seperti Perl, ASP, atau PHP. Beberapa aplikasi yang sudah ada dan berjalan menggunakan bahasa tesebut.

3.2. Modifikasi DSDM

Melihat hasil dari analisa permasalahan, DSDM dapat digunakan sebagai metodologi dalam proses pengembangan sistem. Hal yang menjadi perhatian utama dari DSDM adalah menghasilkan sistem secara tepat waktu dan tepat anggaran, dengan melakukan pengerjaan secara berulang dan bertambah menurut skala prioritas dari bagian-bagian dari sistem. DSDM juga tanggap terhadap perubahan yang cepat, dan bisa digunakan pada tim yang kecil. Menghasilkan produk sesuai dengan jadwal adalah faktor penting dalam keberhasilan pengerjaan proyek sistem informasi.

Namun demikian, terdapat 2 hal tambahan yang menjadi pertimbangan lain, yaitu sistem sejenis sudah pernah dibuat untuk majalah yang lain dan berkembangnya metode pengembangan sistem berbasis open source. Diperlukan modifikasi lebih lanjut terhadap DSDM agar bisa mengakomodasi 2 hal tersebut, yang membantu mempercepat pengerjaan sistem. Modifikasi ini dapat dinyatakan sebagai Rekayasa Pemakaian Ulang (reusability engineering).

Rekayasa Pemakaian Ulang dapat dibagi menjadi 4 bagian:

1. Mengenali yang ada (identify existing), berupa pencarian sistem atau sub sistem dari yang telah ada, bersumber dari proyek terdahulu maupun yang ada di Internet.
2. Rekayasa terbalik (reverse engineering), melakukan dekomposisi fungsional dari sistem menjadi komponen-komponen terpisah.
3. Penyusunan ulang (restructuring), melakukan penyusunan ulang struktur dari komponen, disesuaikan dengan kerangka besar aplikasi maupun database.
4. Rekayasa maju (forward engineering), menyiapkan komponen agar siap pakai untuk kebutuhan sistem.

Gambar 4. Modifikasi dari DSDM.

Tahapan Rekayasa Pemakaian Ulang ini pada dasarnya dapat disisipkan pada banyak tahap dari DSDM. Mengingat sifat siklus hidup DSDM adalah dapat dikembalikan (reversible), maka tahap rekayasa ini lebih efektif ditempatkan setelah tahap Perulangan Model Fungsional. Hasil dari rekayasa adalah mempercepat tahap berikutnya, yaitu Perulangan Perancangan dan Pembuatan.

Gambar 5. Konsep pembuatan sistem menggunakan komponen.

Pemanfaatan kembali perangkat lunak atau komponen-komponennya memberikan beberapa keuntungan, yaitu:

• Peningkatan kualitas, akibat perbaikan kesalahan dari tiap-tiap kali pemakaian ulang. Hal ini bila pemakaian komponen disertai dengan melakukan peninjauan dan perawatan.
• Peningkatan produktivitas, mengingat lebih sedikit kode yang dibuat. Berkurangnya tenaga dan waktu yang dibutuhkan yang secara keseluruhan menekan pengeluaran biaya.
• Perbaikan unjuk kerja. Menggunakan komponen yang dipakai berulang-ulang dan teruji baik akan lebih memberi jaminan daripada komponen yang hanya sekali pakai.
• Keandalan lebih baik. Penggunaan komponen secara berulang pada berbagai sistem menyebabkan kesalahan lebih mudah diketahui sehingga kepercayaan meningkat.
• Interoperabilitas lebih tinggi. Berbagai sistem dapat bekerja baik bila antarmuka komponen dirancang secara konsisten untuk pemakaian lebih luas.

4. Penerapan dan Pembahasan

Penggunakan DSDM yang telah dimodifikasi dalam pengembangan SEMZ akan dibahas tahap demi tahap sesuai urutan kegiatan.

4.1. Sebelum Proyek

Tahap sebelum proyek berupa pengajuan proposal pembuatan sistem editorial di majalah Z. Proposal ini pada intinya berisi hal berikut:

1. Pengajuan pembuatan program beserta spesifikasi sistem.
2. Biaya yang ditawarkan.
3. Waktu yang dibutuhkan.

Proposal diberikan kepada pemilik perusahaan. Persetujuan atas proposal yang diajukan merupakan komitmen dasar mengenai 3 hal di atas, sekaligus menandai dimulainya proses pengembangan sistem yang ditawarkan.

4.2. Studi Kelayakan

Tahap ini terpusat pada persiapan di lingkungan internal pengembang. Teknik kunci yang digunakan adalah mengadakan pertemuan dari seluruh anggota yang akan terlibat. Hasil yang dicapai dari pertemuan ini yaitu:

• Peninjauan kelayakan metodologi pengembangan sistem yang akan digunakan, dalam hal ini DSDM. Berdasarkan hasil analisa dan tujuan-tujuan yang ingin dicapai, dinyatakan proyek dapat dibuat menggunakan DSDM, dengan catatan perlu tambahan tahap Rekayasa Pemakaian Ulang.
• Komitmen dari setiap anggota untuk bekerja hingga proyek selesai, disertai konsekuensi bila anggota mangkir dari tugasnya. Mengingat tim pengembang bersifat ad-hoc, yaitu dibuat hanya untuk kepentingan proyek, maka komitmen ini harus disepakati dan dipatuhi sebaik-baiknya.
• Dibuat garis besar rencana, menyangkut tata cara pengerjaan proyek, penjadwalan, dan pembagian tugas bagi tiap-tiap anggota tim. Pengaturan waktu menjadi penting, mengingat DSDM mensyaratkan tidak ada kompromi soal waktu dalam pengerjaan proyek. Kesepakatan soal waktu juga menjadi dasar dari kemampuan pengerjaan dari tim, sehingga fasilitas yang akan ditawarkan disesuaikan dengan waktu yang tersedia.
• Penentuan pembagian hasil untuk tiap-tiap anggota. Transparansi dalam pembagian hasil bertujuan memperjelas pengeluaran yang akan dikeluarkan, dilihat dari anggaran yang tersedia. Selain itu memperjelas lingkup tugas dan beban kerja masing-masing anggota tim.
• Membuat catatan resiko, yaitu kendala-kendala yang dapat terjadi, beserta cara-cara penanggulangannya.

Mengingat pentingnya hubungan antara pengembang dan pengguna, maka kejelasan personil dari kedua pihak sangat menentukan keberhasilan dari proyek. Pengerjaan pun dibagi menjadi 2 pihak dengan rincian:

• Tim pengembang, terdiri dari 5 orang, yaitu 1 analis sistem, 2 pembuat program, 1 pembuat desain web dan 1 pendukung. Penugasan dari tiap-tiap orang tidak bersifat kaku, dapat merangkap yang lain disesuaikan dengan kemampuan yang ada.
• Pengguna perwakilan, yaitu perwakilan dari perusahaan yang mempunyai akses menentukan dalam penerapan sistem dan memiliki pemahaman luas terhadap operasional sistem. Terdiri dari petugas Teknologi Informasi dari perusahaan dan pengguna setingkat redaktur kompartemen (dikenal juga sebagai redaktur pelaksana).

4.3. Studi Bisnis

Tahap ini terpusat pada membuat kesepakatan tentang apa yang ingin dibuat dari sistem, antara tim pengembang dan calon-calon pengguna. Teknik paling penting yang dilakukan adalah mengadakan lokakarya. Berikut teknik-teknik yang digunakan dalam tahap ini:

• Lokakarya atau rapat. Bertemunya tim pengembang dengan calon-calon pengguna. Mengingat sistem melibatkan banyak bagian, diambil perwakilan yang berkompeten dari masing-masing bagian. Pengguna yang memiliki kewenangan tinggi dan pengetahuan yang luas tentang aturan-aturan bisnis sangat dibutuhkan dalam rapat ini. Dari rapat ini akan diketahui kebutuhan ataupun keinginan pengguna dari sistem yang baru.
• Membicarakan sistem yang diusulkan. Usulan sistem terutama berasal dari sistem sejenis yang pernah dibuat sebelumnya. Mengingat telah berjalannya sistem editorial naskah beserta alur naskahnya, maka usulan sistem merupakan paduan dari sistem yang pernah dibuat dan sistem yang sedang berjalan. Dari sini akan didapat daftar keperluan yang akan dibangun di sistem yang baru.
• Membuat daftar prioritas kebutuhan yang akan dikerjakan, menggunakan teknik MoSCoW. Daftar ini yang kemudian berlaku sebagai rencana pengembangan sistem. Pembuatan sistem dilakukan secara bertahap, dengan bagian terpenting dikerjakan lebih dahulu.
• Memecah pengerjaan sistem ke dalam bagian-bagian pekerjaan, menggunakan teknik timeboxing. Tujuan utama agar sesuai dengan waktu dan anggaran yang tersedia.
• Menentukan dengan jelas batasan-batasan pengerjaan dari proyek, yang merupakan wilayah bisnis yang ingin dicakup oleh sistem. Pada SEMZ maka ini meliputi hal-hal yang berkaitan dengan alur naskah pada sisi editorial majalah. Batasan jelas ini perlu ditetapkan secara pasti dan mengikat agar pengerjaan proyek tidak melebar dan menghambat pekerjaan.
• Memperbarui catatan resiko sesuai hasil rapat.

Menurut prinsip dari DSDM yang berulang dan bertambah, suksesnya pembangunan sistem adalah keterlibatan dan dukungan pengguna atas sistem yang baru. Mengupayakan agar sistem yang baru hadir dan digunakan secepatnya merupakan cara jitu untuk membangkitkan gairah dari pengguna. Berdasarkan daftar prioritas dan keperluan, maka diusahakan secepatnya agar fungsionalitas sistem berjalan, yaitu menggantikan sistem lama dengan sharing folder dengan sistem baru, meliputi usulan naskah hingga terbit di majalah. Dengan fungsi inti sistem berjalan dan pengguna terbiasa menggunakan, diharapkan perubahan cara kerja dapat berjalan lancar.

Melihat hasil analisa masalah, maka ditentukan arsitektur sistem sebagai berikut:

• Sistem berbasis web, yang berjalan pada intranet kantor maupun diakses lewat Internet.
• Pembuatan program menggunakan bahasa scripting PHP. Direncanakan nantinya petugas TI dapat merawat dan mengembangkan sistem lebih lanjut.
• Menggunakan perangkat yang tersedia saat ini, dengan catatan server akan ditingkatkan kemampuannya bila sistem sudah berjalan penuh.
• Sistem dibuat secara terbuka dengan lisensi bebas. Seluruh komponen sistem menggunakan produk-produk dari open source, yaitu sistem operasi Linux (server dan client), server web dengan Apache dan server database menggunakan MySQL.

Pengerjaan sistem dilakukan menurut 3 prioritas sesuai teknik MoSCow seperti berikut:

1. Pengisian dan alur naskah. Mengingat fungsi pokok dari editorial adalah pengelolaan naskah maka didahulukan sistem fungsional untuk pengiriman naskah sesuai alur dan pengawasan jalannya naskah.
2. Pengisian penilaian untuk reporter dan fotografer. Walaupun fasilitas ini ikut tertanam dalam form-form isian naskah, tetapi mengingat kerumitan dan kebutuhan laporan akan cukup tinggi serta sifatnya tidak mendesak maka hal ini akan dikerjakan belakangan.
3. Arsip dan fasilitas-fasilitas pendukung, seperti pesan, forum, dll. Fasilitas ini akan dibuat bila secara fungsional alur naskah dan penilaian telah berjalan baik.

Alur naskah menurut skema yang diberikan (dari perusahaan), dan secara teoritis sudah berjalan, adalah rumit dan panjang. Setelah melalui serangkaian diskusi dengan pihak-pihak terkait maka skema tersebut dapat disederhanakan tanpa mengubah struktur maupun kewenangan dari tiap-tiap bagian. Penyederhanaan ini penting agar mudah diwujudkan dalam bentuk program. Komitmen dari pihak-pihak terkait juga diperlukan agar alur naskah dalam bentuk tersistem tidak bisa dikompromikan atau dilewati. Namun pada situasi tertentu, petugas TI atau yang ditunjuk tetap dapat melakukan tindakan-tindakan yang perlu untuk mengatasi kemacetan aliran naskah. Bentuk penyerhanaan ini seperti alur naskah dan folder pada gambar 5.

Melihat pola kerja dan alur naskah dari redaksional majalah, diputuskan bahwa sistem menggunakan konsep ‘ban berjalan’ dalam menyampaikan naskah dari awal hingga akhir. Makna ‘ban berjalan’ adalah proses diawali dengan data-data awal (dalam hal ini naskah) yang kemudian bergerak sesuai alur sistem yang menyebabkan data-data tersebut semakin lengkap dan matang. Dalam hal ini terdapat 3 jenis kondisi:

• Data tersedia untuk diolah, bisa berasal dari proses sebelumnya maupun sumber-sumber luar (misalnya laporan, foto, hasil riset).
• Data selesai diolah dan bergerak maju.
• Data ditolak dan bergerak mundur, yang mencerminkan perlu perbaikan dari data.

4.4. Perulangan Model Fungsional

Pada tahap ini dipusatkan pada pembentukan model dari sistem. Teknik utama yang digunakan adalah pembuatan prototip. Mengingat sistem adalah berbasis web, maka pembuat desain web terlebih dahulu membuat bentuk dan model dari prototip sistem, berupa dokumen-dokumen statis berformat HTML. Dokumen statis ini dibuat secara lengkap, memperlihatkan seluruh kemungkinan dari tampilan sistem. Hal yang menjadi perhatian dari desain web adalah tampilan yang menarik dan komunikatif, mencakup informasi yang lengkap dengan struktur mudah dipahami.

Hasil tampilan sistem selanjutnya ditinjau oleh calon pengguna sistem. Diadakan rapat khusus yang memperkenalkan contoh sistem dengan tujuan mendapatkan masukan-masukan dari mereka. Tinjauan meliputi banyak hal, seperti bentuk menu, susunan item, jenis huruf, tampilan gambar, alur dokumen, susunan form, dst. Mengingat calon pengguna terdiri dari banyak bagian, maka perwakilan tiap bagian ataupun yang berkompeten turut serta memberikan penilaian.

Salah satu masalah yang mengemuka pada tahap ini adalah terjadi ketidakjelasan pembagian wewenang atas penggunaan sistem. Dengan kata lain menentukan siapa berhak mengakses apa. Mengingat teknik pembagian menurut folder adalah sederhana, mencoba membuat rumusan baku dari semua kewenangan ke dalam sistem menciptakan sistem yang rumit dan kaku, apalagi bila tertanam di program (hardcoding). Sebagai jalan tengah, dibuat sebuah tabel matriks kewenangan yang berlaku menyeluruh dalam program. Tabel ini dapat diubah oleh administrator sistem, sesuai perkembangan sistem.

 

Gambar 6. Tampilan isian menu untuk mengatur kewenangan hak akses sistem.

Pada form isian menu di atas, terdapat pembagian kewenangan sebagai berikut:

• Pengaturan hak akses per halaman atau form. Seperti gambar di atas adalah menentukan hak akses untuk form Penulis.
• Terdapat 3 jenis mode akses, yaitu tulis (insert), ubah (update) dan hapus (delete).
• Terdapat 8 jenis pembagian kerja, sesuai bagian-bagian yang ada di alur naskah.
• Terdapat 3 tingkat kewenangan per bagian, yaitu level 1 (tingkat user), level 2 (tingkat koordinator), dan level 3 (tingkat administrator).

Sesuai hasil studi bisnis di mana terdapat 3 kondisi dari naskah, maka pada setiap form terdapat input standar yang merupakan mekanisme dari pergerakan naskah:

• Simpan, isi form disimpan tetapi belum diteruskan ke proses berikutnya. Naskah untuk selanjutnya hanya dapat dibaca/tulis oleh pengguna tersebut atau tingkat lebih tinggi.
• Lanjut, isi form disimpan dan diteruskan ke proses selanjutnya. Naskah tidak lagi dapat dibaca atau tulis oleh pengguna yang bersangkutan.
• Revisi, isi form dikembalikan ke proses sebelumnya untuk perbaikan. Naskah tidak lagi dapat dibaca atau tulis oleh pengguna.
• Drop, isi form dibatalkan untuk kemudian disimpan sebagai arsip. Naskah tidak dapat dibaca atau tulis oleh siapapun, kecuali dalam pencarian arsip.

Sesuai teknik kunci dari DSDM, pengujian dilakukan secara menyeluruh terhadap sistem. Sehingga baik tampilan maupun aturan bisnis senantiasa diselaraskan sesuai kebutuhan dan persyaratan. Daftar persyaratan dan catatan resiko juga diperbaharui sesuai perkembangan yang ada.

4.5. Rekayasa Pemakaian Ulang

Pada tahap ini berusaha mewujudkan hal-hal yang telah berbentuk model-model fungsional. Diawali dengan mengenali ketersediaan sumber daya yang ada, yang berasal dari proyek terdahulu maupun pencarian di Internet. Pencarian bisa melalui mesin pencari seperti Google, ataupun situs penyimpan open source, seperti sf.net, freshmeat.net atau hotscripts.net. Setiap aplikasi yang didapat dinilai apakah layak untuk digunakan, disesuaikan dan dikembangkan lebih lanjut, atau dibuat lagi dari awal. Bila diputuskan untuk dibuat baru, maka proses pada tahap ini dihentikan, untuk dilanjutkan ke tahap Perancangan dan Pembuatan.

Setelah didapat sumber daya yang bisa dimanfaatkan ulang, selanjutnya dilakukan proses rekayasa terbalik yang menghasilkan komponen-komponen fungsional secara terpisah. Pemecahan aplikasi dapat mencakup seluruh fungsionalitas yang ada, baik itu fungsi-fungsi, tampilan, gambar, script,

struktur database, maupun alur sistem. Pemilahan dan pemilihan komponen-komponen siap pakai juga menghindari aplikasi yang bengkak oleh hal-hal yang tidak perlu (bloated) yang bisa mempengaruhi keandalan sistem.

Gambar 7. Pemilahan dan pemilihan komponen yang siap pakai.

Sebagai contoh dari proses rekayasa terbalik adalah mengurai suatu Content Management System (CMS) hingga didapat komponen-komponen siap pakai, seperti modul otorisasi dan editor teks berformat Rich Text Format (RTF). Teks dengan format RTF memungkinkan bentuk huruf bermacam-macam, seperti miring (italic), tebal (bold), dan garis bawah (underline). Diperoleh pula fungsi-fungsi Asynchronous Java Script Access (AJAX), yang melakukan akses tak serempak ke server web, sehingga pengisian input dari form berjalan lebih interaktif. Bila tahap rekayasa dianggap gagal, kebutuhan yang ada akan dibuat baru dan dilanjutkan ke tahap berikutnya.

Gambar 8. Tampilan form isian usulan 1 dengan editor Rich Text Format.

Setelah komponen-komponen siap pakai didapat, perlu dilakukan penyusunan ulang. Penyusunan mencakup pembenahan program, script, dan pengubahan struktur database. Proses ini juga dimanfaatkan untuk memoles dan memperbaiki komponen dari kesalahan, termasuk membuatnya bekerja lebih efisien. Mengingat pengembangan bermetode open source dikerjakan oleh banyak pihak, kualitas dari perangkat lunak yang dihasilkan bisa sangat beragam. Dengan penyusunan ulang diharapkan memperbaiki unjuk kerja komponen tersebut.

Proses akhir pada tahap ini adalah melakukan rekayasa maju, yaitu mempersiapkan komponen agar dapat diintegrasikan secara mulus ke dalam sistem. Beberapa langkah agar penggabungan berjalan mulus yaitu menentukan definisi yang konsisten dari tiap-tiap fungsi dan antarmuka komponen. Pengembangan sistem dengan pemakaian ulang mensyaratkan rancangan yang baik dari aplikasi dan komponen, dengan demikian rekayasa maju juga berfungsi mempersiapkan komponen untuk penggunaan dalam jangka panjang.

4.6. Perancangan dan Pembangunan

Tahap ini merupakan inti dari pengembangan sistem sesungguhnya. Di sini segala persyaratan yang dibutuhkan sudah tersedia, yaitu model-model fungsional, komponen-komponen siap pakai, dan aturan bisnis. Diawali dengan mengenali prototip rancangan, baik secara fungsional maupun non fungsional. Bila tahap rekayasa pemakaian ulang telah menghasilkan komponen siap pakai, proses ini memastikan prototip yang dihasilkan telah sesuai kebutuhan. Bila diputuskan dibuat baru, rancangan diterjemahkan dalam bentuk struktur tampilan dan kode-kode program.

Penting untuk disepakati mengenai jadwal pengerjaan pada proses pembangunan. Setiap pihak, baik pengembang maupun calon pengguna, harus berkomitmen pada bagaimana dan kapan untuk mengerjakan persyaratan yang ingin dipenuhi. Proses ini dapat dilewati bila telah tersedia komponen siap pakai hasil dari tahap rekayasa pemakaian ulang.

Selanjutnya proses pembangunan dilakukan. Proses ini menyatukan berbagai subsistem yang telah tersedia, termasuk membangun subsistem baru sesuai kebutuhan. Mengingat tim pengembang bersifat ad-hoc di luar perusahaan, pengerjaan dilakukan di tempat pembuat program. Komunikasi dan koordinasi antar anggota tim dilakukan menggunakan media Internet. Dalam hal berhubungan dengan calon pengguna, tenaga analis dan pendukung secara bergantian atau bersama-sama mengadakan rapat di kantor Z. Pertemuan diadakan sedikitnya sekali dalam seminggu. Sasaran dari proses ini adalah sistem yang sudah teruji.

Gambar 9. Tampilan Sistem Editorial Majalah Z.

Pada tahap pembangunan, sesuai teknik kunci DSDM, pengujian dan peninjauan dilakukan sepanjang pengerjaan program. Bila dirasa rancangan sistem dirasa matang, calon pengguna dipersilakan untuk mencoba dan memberikan masukan. Proses ini menandai pula proses terakhir dari tahap ini, yaitu tinjauan dari prototip rancangan. Kebenaran dari hasil rancangan sistem ditentukan di sini. Dibuat pula dokumentasi maupun catatan hasil pengujian.

Bila pengembang dan pengguna telah sepakat sistem berjalan baik, dapat dilanjutkan ke tahap berikutnya. Tidak tertutup sistem yang dihasilkan tidak memenuhi persyaratan awal, sehingga perlu kembali ke tahap sebelumnya, yaitu pembuatan model fungsional atau rekayasa pemakaian ulang. Keseluruhan tahap ini membutuhkan dukungan penuh dari Senior Management dalam melibatkan dan memastikan komitmen pengguna akhir terhadap sistem terus berlanjut.

4.7. Penerapan

Pada akhir dari siklus hidup DSDM, sistem yang sudah teruji siap untuk digunakan di lapangan. Sebelumnya petugas TI telah melakukan tinjauan akhir dan sepenuhnya menguasai pengoperasian sistem. Penyaringan ketat dari petugas TI bersifat strategis, karena merekalah yang nantinya terjun langsung dalam pengawasan pelaksanaan sistem. Selanjutnya perwakilan dari calon pengguna melakukan penilaian akhir. Hasil dari penilaian ini adalah persetujuan dari pengguna akhir bahwa sistem sudah memenuhi kriteria yang disepakati di awal proyek, menetapkan pedoman pengoperasian, dan mematuhi ketentuan sistem yang telah dibuat. Dibuat pula dokumentasi lengkap baik sisi teknis maupun pengoperasian.

Setelah persetujuan didapat, dilakukan pelatihan terhadap keseluruhan calon pengguna. Pelatihan ini dilakukan secara bertahap, melihat kemampuan pelatih maupun yang dilatih. Pembagian tahapan pelatihan dibagi per kompartemen, yang mewakili pengelompokan bidang kerja menurut rubrikasi majalah. Saat pelatihan ini tim pengembang diwakili oleh petugas pendukung, sedangkan pihak perusahaan oleh petugas TI. Hasil akhir dari proses ini adalah sekelompok pengguna yang terlatih.

Setelah sistem, sarana pendukung dan pengguna telah siap, sistem yang baru dilakukan sepenuhnya dijalankan. Seluruh penggunaan sistem yang lama dihentikan untuk mencegah kerja ganda dan kesimpangsiuran pelaksanaan. Pada proses ini baik tim pengembang dan petugas TI secara ketat mengawasi jalannya sistem dan siap terjun langsung ke lapangan. Hingga waktu yang dirasa cukup, yaitu hingga minimal 3x penerbitan majalah, maka sistem dianggap berjalan baik dan sepenuhnya di bawah kendali petugas TI perusahaan.

Proses akhir dari tahap ini adalah tinjauan bisnis, dengan isu pokok adalah penilaian apakah sistem secara keseluruhan memenuhi tujuan yang ditentukan di awal proyek. Berdasarkan penilaian ini ditentukan apakah proyek berlanjut ke tahap berikutnya, atau kembali ke tahap-tahap sebelumnya untuk diperbaiki lebih lanjut. Pada pengerjaan menurut prioritas pengerjaan, selesainya suatu bagian berarti berputar lagi ke awal siklus untuk meneruskan prioritas pekerjaan yang lain.

4.8. Setelah Proyek

Setelah siklus hidup DSDM dilakukan berulang-ulang hingga keseluruhan sistem terbangun lengkap, tahap akhir yang perlu dilakukan adalah memastikan sistem berjalan secara efektif dan efisien. Perawatan, peningkatan dan perbaikan di sisi aplikasi maupun infrastruktur pendukung dilakukan. Hal yang perlu ditinjau secara periodik adalah operasional database. Seiring berjalannya waktu data yang tersimpan di database akan semakin membesar. Struktur data yang tidak efisien maupun indeks yang keliru menjadi bom waktu yang berakibat kegagalan sistem di masa depan. Tujuan yang ingin dicapai pada tahap ini adalah jaminan bahwa sistem berjalan dengan baik.

Melalui perawatan sistem yang teratur dan berkesinambungan, setelah sistem sekian lama berjalan dapat dilakukan penijauan kembali, sebagai upaya melakukan pembangunan yang berkelanjutan. Bila dirasa ada hal-hal baru yang belum tercakup dari sistem yang telah dibuat, dapat dilakukan pertimbangan untuk pengajuan pengembangan sistem lebih lanjut. Hal ini berdasarkan sifat alami DSDM, yaitu perulangan dan pertambahan.

MODEL – MODEL SDLC

Agile

 

adalah membuang beberapa tahapan yang tidak mempunyai nilai/value dan menekankan pada pengembangan sederhana dan iterative/berulang. Beberapa jenis Agile SDLC antara lain Extreme Programming, Kanban, Scrum, DSDM, FDD, OpenUP, dll.

Dari berbagai jenis SDLC tersebut tentunya tidak mudah untuk menentukan methode SDLC mana yang akan dipakai dalam sebuah pengembangan product system informasi. Banyak faktor yang akan mempengaruhi dalam penentuan tersebut, antara lain:

1. kejelasan kebutuhan pengguna

2. pengetahuan user terhadapa teknologi

3. kompleksitas system

4. waktu

5. kejelasan jadwal

6. sering nya perubahan terhadap product

7. dll

Tapi kami menentukan jenis SDLC yang akan dibahas lebih mendalam dalam virtuemagz ini adalah Agile Development.

Agile lebih menawarkan fleksibilitas dalam menangani perubahan, dan dalam era sekarang ini, dimana perubahan adalah sebuah keharusan maka mau tidak mau kita harus “agile” terhadap perubahan tersebut. Organisasi/team yang tanggap terhadap perubahan akan menjadi juara sedangkan yang tetap lambat (penuh procedural) menghadapinya akan tertindas dengan sendirinya.

 

Anamorphic Pembangunan, cenderung fokus pada suatu bentuk pembangunan yang dipandu oleh lingkup proyek dan adaptif iterasi pengembangan fitur.

Evolutionary

keuntungan
• Analisis risiko lebih baik.
• Mendukung perubahan kebutuhan.
• Waktu Operasi awal kurang.
• Lebih baik cocok untuk proyek-proyek besar dan mission-critical.
• Selama siklus hidup perangkat lunak diproduksi awal yang memfasilitasi evaluasi pelanggan dan umpan balik.

kekurangan
Tidak cocok untuk proyek-proyek yang lebih kecil •.
• Manajemen kompleksitas lebih.
• Akhir proyek tidak dapat mengetahui yang merupakan risiko.
• Dapat menjadi mahal untuk digunakan.
• sumber daya yang sangat terampil diperlukan untuk analisis risiko.
• Kemajuan Proyek sangat tergantung pada tahap analisis resiko.

  V-Model

• The V model (Model Validasi & Verifikasi) [11] adalah versi modifikasi dari metode Waterfall
• Berbeda dengan metode Waterfall, yang satu ini tidak dirancang dalam sumbu linear, melainkan tahap kembali ke atas setelah fase coding dilakukan.
• Proses perkembangan yang seimbang dan bergantung pada verifikasi dari langkah sebelumnya sebelum melanjutkan ke depan.
• Produk dari setiap tahap perlu diperiksa dan disetujui sebelum bergerak maju.
• Dalam model pengembang v dan tester bekerja paralel.
• Dalam model V, berdasarkan persyaratan kasus Sistem tes yang disiapkan, dan berdasarkan HLD (dokumen tingkat tinggi) kasus Integrasi Uji siap, dan berdasarkan (dokumen tingkat rendah) LLD kasus Integrasi Test siap . Dan kemudian coding dilakukan. Setelah coding selesai, unit, integrasi dan pengujian sistem yang terjadi dalam urutan.
• Pada V-model, memberikan hubungan antara masing-masing tahap pengembangan dan tahap Pengujian.

Gambar 2: V-Model Life Cycle
Catatan: Ekor kiri "V" merupakan 'fase spesifikasi', ekor kanan "V" merupakan 'tahap pengujian', bagian bawah "V" di mana ekor bertemu mewakili 'fase pembangunan'.
3.2.1 Pro
• Sama seperti model Waterfall
• V-Model, keuntungan adalah bahwa peran Tester akan terlibat dalam fase persyaratan itu sendiri.
• Perubahan Syaratnya mungkin dalam fase apapun.

3.2.2 Kontra
• Kerugian terbesar dari V-Model adalah bahwa hal itu sangat kaku dan paling fleksibel.
• Jika ada perubahan terjadi pertengahan jalan, tidak hanya dokumen persyaratan tetapi juga dokumentasi uji perlu diperbarui.
• Hal ini tidak diusulkan untuk proyek-proyek jangka pendek karena membutuhkan ulasan pada setiap tahap.

Dalam persyaratan studi kasus kami, jika klien perlu mengubah persyaratan setiap kemungkinan untuk memperbarui tapi dokumentasi dibuat dari fase persyaratan seperti Spesifikasi fungsional, desain tingkat tinggi, desain tingkat rendah, unit testing, pengujian sistem, pengujian integrasi harus diperbarui.
Sebagian V-Model digunakan dalam Organisasi yang lebih besar karena membutuhkan jumlah lebih banyak sumber daya.

Stage Gate Model

Sepertinya proyek menggunakan model ini mungkin akan gagal karena sifat berurutan dari tahap digambarkan di sini, keluhan dari beberapa rekan tentang keprihatinan model proses siklus hidup berurutan. Namun, banyak pekerjaan dilakukan secara paralel untuk foreshorten waktu pengembangan dan memastikan penyelesaian tepat waktu. Juga, apa yang terjadi dalam setiap tahap yang diresepkan oleh deskripsi proses yang diadopsi oleh tim pengembangan. Misalnya, pasangan pemrograman, penelusuran, dan pengujian terus menerus semua bisa digunakan serta metode dan teknik lainnya.
Gerbang Tahap Model siklus hidup datang dalam berbagai rasa, beberapa di antaranya telah merek dagang dengan judul Model ini memiliki asal-usul di sektor manufaktur "Gerbang Tahap.". Idenya adalah relatif sederhana: Bagian dan subassemblies yang dipentaskan. Ketika semua bagian yang diperlukan, subassemblies, signoffs inspektur, dan setiap tes yang diperlukan telah selesai, mereka melewati gerbang virtual dan dirakit menjadi subsistem terbesar berikutnya atau mungkin sistem final. Dalam arena perangkat lunak, pendekatan ini membahas persyaratan sebagai berikut:
• Mengurangi risiko proyek yang dihasilkan dari out-of-control pembangunan
• Meningkatkan kualitas deliverable
• Pastikan bahwa proses diletakkan di tempat yang diikuti
• Mengurangi waktu mengalir melalui proses pembangunan
• Fokus pada semua aspek dari perangkat lunak yang diproduksi
• Apakah yang jelas dinyatakan set tujuan dan tugas-tugas tertentu yang dicapai dalam jangka pendek
Pada pandangan pertama, pendekatan ini mungkin tampak agak lama sekolah, dan itu. Tapi pikirkan kembali sejenak. Berapa kali harian atau mingguan membangun telah dibawa turun oleh fakta bahwa seseorang berubah dalam kode yang seharusnya unit diuji dan regresi diuji sebelum penerimaan? Model siklus hidup memberlakukan kebijakan organisasi, mencegah masalah, dan mengurangi ulang dan kesalahan.
Ide gerbang mungkin konsep baru untuk beberapa manajer. Gates diposisikan pada titik-titik kritis dalam siklus hidup. Mereka memiliki peran penting dalam bahwa sebelum proyek dapat dilanjutkan ke tahap berikutnya, sebuah komite tinjauan meneliti artefak (seperti presentasi, dokumen, uji kasus) sesuai dengan tahap itu dan mengevaluasi mereka terhadap standar yang ditetapkan untuk proyek itu dan untuk perusahaan secara keseluruhan . Panitia membuat salah satu dari empat keputusan:
Go Semuanya adalah dalam rangka, dan proyek dapat dilanjutkan ke tahap berikutnya.
Membatalkan proyek ini dalam kesulitan yang cukup serius sehingga harus dibubarkan di sini dan sekarang. Ya, beberapa proyek akan menjadi lebih baik jika mereka telah dibatalkan!
Tahan Pada titik ini akan lebih baik untuk menghentikan proyek untuk sementara waktu (misalnya, pasar untuk produk memburuk, pelanggan sedang mempertimbangkan membatalkan, dan sebagainya).
Daur ulang Arahkan proyek untuk memperbaiki / meningkatkan hasil saat ini dan mencoba untuk mendapatkan persetujuan lagi.
Pengalaman saya dengan tahap siklus hidup gerbang melibatkan pengembangan sebagian sistem meja layanan. Kesulitan kami sedang mendapatkan stabilitas dalam upaya sebelumnya bisa ditelusuri kembali secara langsung ke beberapa programmer tidak mengikuti manajemen konfigurasi dan praktek konten lainnya kontrol diadopsi di perusahaan-orang kami balik dalam kode yang belum berjalan melalui dengan rekan-rekan mereka, yang belum teruji, dan sebagainya. Meskipun melembagakan pendekatan siklus hidup sebagai percobaan menyebabkan banyak mengeluh dari anggota tim kami, hal itu mengakibatkan pasar-tercepat untuk-, bug terendah menghitung kita sudah berpengalaman. Hal ini terjadi meskipun ini adalah produk baru.
Tantangan bagi manajer proyek perangkat lunak menggunakan pendekatan ini adalah untuk "tetap saja" dan tidak menyerah pada keluhan dari tim pengembangan tentang harus bergerak melalui proses yang ketat tersebut. Aspek metode gerbang panggung adalah sumber keluhan yang paling tentang hal itu dari manajer dan pengembang sama.

 

5. Kesimpulan

Modifikasi DSDM dengan menambahkan tahap Rekayasa Pemakaian Ulang dapat menjembatani antara tahap Perulangan Model Fungsional dan tahap Perulangan Perancangan dan Pembuatan. Melalui teknik pemakaian ulang maka sumber daya dari proyek-proyek terdahulu maupun open source dapat digunakan secara optimal, sehingga mengurangi waktu pengerjaan dan meningkatkan keandalan dari sistem. Dengan semakin tepat waktu maupun tepat anggaran maka tingkat keberhasilan dalam pengembangan sistem informasi akan semakin tinggi dan mendapat kepercayaan lebih baik dari penggunanya.