Mengenal Model Life Cycle dan Model Proses Klasik Waterfall Perangkat Lunak

Perkembangan perangkat lunak bisa dianggap sebagai lingkaran pemecahan masalah dimana terdapat empat keadaan berbeda yaitu:

  • status quo
  • definisi masalah
  • perkembangan teknis memecahkan masalah di keseluruhan aplikasi dari banyak teknologi
  • integrasi pemecahan menyampaikan hasil kepada siapa yang membutuhkan pertama kali

Lingkaran pemecahan masalah berlaku untuk kerja rekayasa perangkat lunak pada tingkat resolusi yang berbeda. Lingkaran tersebut dapat dipakai pada tingkat makro ketika bagian pada aplikasi dipakai; pada tingkat tengah jika komponen program direkayasa; dan bahkan pada tingkat kode sekalipun. Dengan demikian, perwakilan fraktal dapat dipakai untuk memberikan pandangan proses yang ideal (Pressman, 2002: 35).

 

Sejak tahun 1960-an banyak deskripsi tentang life cycle perangkat lunak klasik telah diperkenalkan oleh beberapa tokoh (sebagai contoh; Hosier 1961, Royce 1970, Boehm 1976, Distaso 1980, Scacchi 1984, Somerville 1999). Pada tahun 1970, Royce memperkenalkan formulasi life cycle perangkat lunak dengan menggunakan waterfall chart yang sampai sekarang masih banyak digunakan oleh kalangan praktisi. Model meringkas sebuah tampilan tunggal tentang bagaimana mengembangkan sistem perangkat lunak besar dengan tingkat kesulitan yang melibatkan tugas rancang-bangun kompleks yang memerlukan langkah berulang dan pengerjakan lagi sebelum dilakukan tahap penyelesaian. Model ini memerlukan presentasi pengantar khususnya kepada pemakai sistem yang mungkin tidak familier dengan berbagai strategi dan permasalahan teknis yang harus ditujukan ketika membangun sistem perangkat lunak besar (Royce dalam Scacchi, 2001: 1-2).

 

Lebih jauh Scacchi (2001) menjelaskan bahwa model life cycle perangkat lunak klasik pada umumnya meliputi sejumlah aktifitas sebagai berikut:

  • System Initiation/Planning: dari mana sistem tersebut datang?. Pada kebanyakan situasi, sistem mungkin baru menggantikan atau melengkapi mekanisme pengolahan informasi yang ada, apakah mereka sebelumnya diotomatkan, manual, atau informal.
  • Requirement Analysis and Specification: mengidentifikasi permasalahan pada suatu sistem perangkat lunak baru adalah dengan memperkirakan pemecahkan masalahnya, kemampuan operasional, karakteristik capaian diinginkan dan infrastruktur sumber daya yang memerlukan pengoperasian sistem pendukung dan pemeliharaan.
  • Functional Specification atau Prototyping: mengidentifikasi dan menyusun object perhitungan yang potensial, hubungan dan atribut mereka, operasi yang mengubah bentuk object tersebut, batasan yang membatasi perilaku sistem dan sebagainya.
  • Partition and Selection (Membangun vs Membeli vs Menggunakan kembali): kebutuhan yang diberikan dan spesifikasi fungsional, membagi sistem itu ke dalam potongan yang dapat dikendalikan sehingga menandakan subsistem logis kemudian menentukan apakah sistem baru, sistem yang telah ada atau sistem perangkat lunak bisa kembali sesuai dengan potongan yang diperlukan.
  • Architectural Design and Configuration Specification: menggambarkan sumber daya dan interkoneksi yang menghubungkan antara subsistem sistem, komponen dan modul dalam berbagai cara yang pantas untuk disain terperinci dan keseluruhan manajemen. Spesifikasi disain komponen yang terperinci menggambarkan metode tentang bagaiamana sumber daya data di dalam modul suatu komponen diubah dari masukan yang diperlukan ke dalam keluaran yang disajikan.
  • Component Implementation and Debugging: melakukan kodifikasi spesifikasi yang terdahulu ke dalam implementasi source program operasional dan mengesahkan operasi dasar mereka. Pengintegrasian perangkat lunak dan pengujian: menyatakan dan mendukung keseluruhan integritas sistem perangkat lunak dalam bentuk konfigurasi arsitektur sistem melalui verifikasi yang konsisten dan kelengkapan implementasi modul, membuktikan interkoneksi dan interface sumber daya terhadap spesifikasi di atas dan memvalidasi capaian sistem dan subsistem terhadap kebutuhan tersebut.
  • Documentation Revision and System Delivery: pengemasan dan rasionalisasi merekam uraian pengembangan sistem ke dalam pemakai dan dokumen yang sistematis dan user guides, semua yang ada di format yang pantas untuk diseminasi dan system support.
  • Deployment and Installation: menyediakan arah untuk instalasi perangkat lunak yang dikirimkan ke dalam lingkungan komputer lokal, konfigurasi parameter sistem operasi dan perlakuan khusus akses pemakai, dan menjalankan diagnose test cases untuk meyakinkan kelangsungan hidup dari operasi sistem basis dasar.
  • Training and Use: menyediakan para pemakai sistem dengan bantuan alat instruksi dan bimbingan untuk pemahaman kemampuan sistem dan pembatasannya dalam rangka menggunakan sistem secara efektif.
  • Software Maintenance: mendukung operasi yang bermanfaat pada suatu sistem dalam target (host) lingkungannya dengan menyediakan permintaan peningkatan fungsional, pekerjaan pembetulan dan capaiannya

 

Apa Model Life Cycle Perangkat Lunak?

Model life cycle perangkat lunak adalah suatu deskriptif atau penentuan karakteristik tentang bagaimana suatu perangkat lunak harus dikembangkan. Model deskriptif menjelaskan tentang sejarah bagaimana sistem perangkat lunak tertentu telah dikembangkan. Model deskriptif mungkin digunakan sebagai dasar untuk pemahaman dan peningkatan proses pengembangan software atau untuk membangun model dasar ( Curtis, Krasner, Iscoe dalam Scacchi, 2001: 8).

 

Deskriptif model life cycle, pada sisi lain, menandai bagaimana sistem perangkat lunak tertentu benar-benar dikembangkan dengan pengaturan tertentu. Demikian pula, mereka umumnya lebih sedikit dan sulit untuk mengartikulasikan dengan alasan yang jelas dan nyata. seseorang harus mengamati atau mengumpulkan data melalui seluruh life cycle suatu sistem perangkat lunak, masa waktu lampau sering terukur dalam hitungan tahun. Model deskriptif dikhususkan untuk mengamati sistem dan hanya men-generalisasi secara sistematis analisa komparatip. Dua karakteristik ini menyatakan bahwa ada beberapa tujuan untuk mengartikulasikan model life cycle perangkat lunak. Karakteristik-karakteristik tersebut meliputi:

  • Petunjuk untuk mengorganisir, merencanakan, mengorganisir, menganggarkan, menjadwalkan dan mengatur proyek perangkat lunak atas suatu organisasi waktu tertentu dan menghitung lingkungan yang mungkin mempengaruhinya.
  • Garis besar yang menentukan dokumen apa saja yang menghasilkan delivery to client.
  • Dasar untuk menentukan metodologi apa yang digunakan untuk rekayasa perangkat lunak dan rancang-bangun apa yang paling sesuai untuk mendukung aktivitas life cycle berbeda.
  • Kerangka untuk menganalisa atau menaksir pola alokasi sumber daya dan konsumsi selama life cycle perangkat lunak (Boehm, 1981: 89).
  • Dasar untuk melaksanakan studi empiris dalam menentukan apa saja yang mempengaruhi produktivitas perangkat lunak, biaya, dan keseluruhan mutunya.

 

Apa Model Proses Perangkat Lunak?

Sangat kontras dengan model life cycle perangkat lunak, model proses perangkat lunak sering menghadirkan suatu urutan aktivitas jaringan, objek, transformasi dan peristiwa yang berwujud strategi untuk memenuhi evolusi perangkat lunak. Model tersebut dapat digunakan untuk mengembangkan dan menyusun uraian aktivitas life cycle perangkat lunak yang lebih tepat. Kekuatannya adalah dari pemanfaatan suatu notasi, sintaksis atau semantik sesuai dengan proses komputasi.

 

Proses Perangkat lunak merupakan proses jaringan yang dapat dipandang sebagai perwakilan berbagai rangkaian tugas yang saling behubungan (Garg, 1989: 104). Serangkaian tugas tesebut menghadirkan suatu urutan tindakan yang tidak linier tapi terstruktur dan mengubah bentuk computasional object yang tersedia dalam sumber daya ke dalam intermediate atau produk jadi. Tidak linear tersebut memimplikasikan bahwa urutan tindakan mungkin non-deterministic dan iterative dengan mengakomodasikan alternatif paralel, seperti halnya perintah dalam kemajuan incremental. Tindakan tugas pada gilirannya dapat dipandang sebagai suatu urutan tidak linier dari tindakan primitif yang menandakan satuan terkecil untuk menghitung pekerjaan, seperti halnya suatu pemilihan pemakai, perintah atau masukan menu yang menggunakan mouse atau papan tombol. Winograd dan yang lainnya sudah menunjuk unit ini sebagai pekerjaan kerjasama antara orang dan komputer dalam suatu rangkaian tugas yang diberinama workflow (Bolcer, 1998: 234).

 

Serangkaian tugas dapat dilakukan untuk menandai dan menentukan urutan tindakan deskriptif. Rangkaian tugas tersebut diidealkan sebagai rencana dari tindakan yang harus terpenuhi dan di dalamnya terdapat pesanan. Sebagai contoh, suatu rangkain tugas untuk aktivitas perangkat lunak yang berorientasi objeck meliputi tindakan tugas sebagai berikut:

  1. Pengembangan suatu spesifikasi naratif informal dari suatu sistem.

  2. Identifikasi object termasuk atribut di dalamnya.

  3. Identifikasi operasi atas berbagai object.

  4. Identifikasi interface antara object, atribut atau operasi.

  5. Implementasi operasi-operasi tersebut (Scacchi, 2001: 5)

 

 

Model Life Cycle Perangkat Lunak Tradisional (Traditional Software Life Cycle Models)

 

Menurut Scacchi (2001), Evolusi Model perangkat lunak tradisional telah lama menjadi software engineering. Life cycle perangkat lunak yang klasik yang terkenal yaitu “Waterfall” dan model stepwise refinement secara luas tertulis dan dibahas oleh semua buku pada praktek pemrograman modern dan rekayasa perangkat lunak. Model incremental merilis model yang berhubungan erat dengan praktek industri yang sering terjadi di lapangan. Military standard mendasarkan pada model yang mempunyai format tertentu berdasarkan model life cycle klasik ke dalam praktek yang diperlukan untuk pemerintahan. Masing-masing empat model ini menggunakan hal-hal yang kasar atau karakteristik makroskopik ketika ingin menggambarkan evolusi perangkat lunak.Suatu langkah yang progresif, evolusi perangkat lunak sering dijelaskan dalam beberapa langkah, seperti spesifikasi kebutuhan, disain persiapan, dan implementasi. Hal tersebut pada umumnya hanya mempunyai sedikit atau tidak ada sama sekali karakteristik lebih lanjut selain dari daftar atribut produk dari langkah-langkah yang dilaluinya . Lebih lanjut, model ini adalah tidak terikat pada pengembangan organisasi, pilihan bahasa program, daerah aplikasi perangkat lunak dan lain lain. Singkatnya, model tradisional adalah context-free dibandingkan dengan context-sensitive. Tetapi semua life cycle model ini telah digunakan pada beberapa waktu yang lalu dan kita mengacu pada model tradisional serta memberikan karakteristik masing-masing pada gilirannya.

 

Life Cycle Perangkat Lunak Klasik (Classic Software Life Cycle)

Life cycle perangkat lunak klasik sering diwakili sebagai fase model perangkat lunak yang sederhana yaitu model “waterfall” dan evolusi perangkat lunak berproses melalui suatu urutan transisi rapi dari berfase tunggal hingga yang berikutnya dalam suatu urutan (Royce, 1990: 67). Lebih jauh Royce mengemukakan bahwa seperti model yang menyerupai uraian mesin, status evolusi perangkat lunak terbatas. Bagaimanapun, model ini telah menjadi model yang paling bermanfaat dalam membantu kegiatan yang terstruktur dan mengatur proyek pengembangan software besar dalam pengaturan organisasi yang kompleks yang merupakan salah satu tujuan yang utama. Sebagai alternatif, model klasik ini secara luas menandai kedua model yang menentukan dan menjelaskan bagaimana pengembangan software pada skala kecil dan besar terjadi. Gambar di bawah menjelaskan suatu pandangan “model waterfall” untuk pengembangan software yang digambarkan oleh Royce.

 

Lebih jauh tentang Model Waterfall

Model Waterfall adalah suatu jenis model pengembangan sistem teknologi informasi yang dikenalkan pada tahun 1970 oleh Winston W. Royce. Sebelum model tersebut ada, sejumlah kegagalan pemakaian dalam implementasi sistem proyek perangkat lunak sering terjadi karena ketiadaan parameter yang sesuai dan pendekatan mengenai cara serta kendali mengenai metode tugas manajemen proyek perangkat lunak.

 

Tujuan model ini adalah untuk memperkenalkan bagaimana proses desain sistem sebagai kerangka untuk pengembangan sistem dalam upaya membantu secara teratur dan efisien melalui suatu rangkaian tahapan dengan analisa kelayakan sistem termasuk atas release sistem dan pemeliharaannya.

 

Dinamakan waterfall karena model tersebut menggambarkan arah kemajuan sistem dari puncak ke bawah, seperti air yang terjun dari suatu ketinggian dengan berbagai panoramanya. Berfasa tunggal pada waktu yang sama ke arah bawah dalam suatu efek cascading. Sekarang ini, model waterfall dipertimbangkan sebagai suatu model klasik dan model jenis sistem konservatif tetapi bagaimanapun juga masih sangat dibutuhkan dan harus tetap ada untuk suatu pemahaman pokok pengembangan sistem dalam upaya merancang manajemen sistem perangkat lunak.

 

Dalam model waterfall, desain sistem dipecahkan dalam sejumlah langkah linier dan sequential di mana evolusi sistem dilihat bagaikan air yang mengalir semakin turun melalui fase-fase tertentu. Model waterfall mempunyai tujuan berbeda dari masing-masing fase (phase) pengembangan. Metoda pengembangan ini tidaklah membolehkan fase tertentu langsung menggantikan fase berikutnya sampai operasi fase yang terdahulu telah terpenuhi. Keluaran (output) dari fase masing-masing membentuk masukan (input) pada fase berikutnya. Oleh karena itu, masing-masing fase harus terpenuhi dahulu pada gilirannya untuk memelihara pertaliannya antara masukan dan keluaran (Bista, 2006).

Fase-fase dalam Model Waterfall

1. Requirements

 

  • Suatu statemen fungsi dan perilaku sistem yang diperlukan oleh para pemakai & operator
  • Kebutuhan Umum terdiri dari penjelasan secara detail & sasaran hasil yang terperinci dari sistem. Contoh dapat dipercaya, benar, efisien, mudah dioperasikan, dapat diperluas
  • Pemberian hubungan secara kualitatif & tujuan sistem secara kuantitatif

2. Specification

 

 

 

  • Daftar khusus, sistem tingkah laku yang terukur yang mencukupi kebutuhan sistem yang terinci.
  • Komunikasikan operasi sistem secara jelas dengan end user secara lengkap, terang, bisa teruji dan dapat dimengerti serta dengan kelengkapan referensi bersilang terindeks pada materi kebutuhan.
  • Gambarkan pengesahan disain tersebut & kriteria pengujian sistem akhir.
  • Sediakan mekanisme pemimpin untuk mengestimasikan kemajuan proyek

3. Design: Representation or model of a system

4. Coding & Debugging (Implementation)

  • Terjemahan dari desain ke dalam suatu bahasa program
  • Fenomena programmer sangat dibutuhkan
  • Buku catatan unit program

1. Dokumen tentang aktifitas pekerjaan programer
2. Dokumentasi pemeliharaan unit terkini
3. Uraian dari programer ke programer selama pengembangan

Kamus Data: Informasi Arsip dan rincian format fisik dari semua struktur, variabel, file dan lain-lain.

  • Kamus data melakukan pemetaan dokumentasi

Objek Data —- Struktur Sistem

Objek Data —- Parent Objects

Objek Data —- Modul Routins

 

  • Entri kamus data

Name : from the data-flow diagram or structure chart

Routine Usage : routines that access the object

Purpose : explanation

Derivation : where the data that the items holds comes from ex. files, user, other entries . . .

Subitems: Record components Notes: comments

5. Integration & Testing

 

 

  • Unit testing: modul/fungsi individu yang diuji terpisah dengan yang lain.
  • integration testing: modul sistem yang diuji secara bersama-sama

6. Deployment & maintenance

 

  • Fase kebutuhan sebelumnya untuk diulangi
  • Pembuatan 70%-90% dari biaya sistem keseluruhan
  • Mayoritas waktu pemeliharaan ( 50%) yang dikeluarkan pada pemahaman sistem
  • Tugas Pemeliharaan
  1. dokumentasi sistem
  2. Koleksi, Analisa dan Prioritas atas laporan atas user troubel
  3. Instalasi sistem baru
  4. Dokumentasi ( user’s manual) dan perubahannya
  5. Isu kontrol konfigurasi (Barnette ND & McQuain WD, 1998: 5)

 

Pada fase-fase di atas, sistem waterfall terdiri dari delapan fase berbeda dan masing-masing fase terbagi ke dalam dua divisi: divisi yang pertama meliputi tugas untuk dilaksanakan pada fase tersebut dan divisi kedua adalah justifikasi atau konfirmasi pemeriksaan prosedur pada pekerjaan spesifik tersebut. Dalam model ini, istilah konfirmasi dan justifikasi mempunyai maksud/arti yang spesifik:

 

Justifikasi berarti pengesahan atau pemeriksaan apakah hasil sesuai dengan misi operasional. Hal tersebut dilakukan dengan mengecek apakah produk benar-benar sedang dibuat atau tidak. Apakah produk yang dibuat benar sesuai yang diharapkan?. Sedangkan konfirmasi berarti verifikasi atau pemeriksaan mata rantai suatu hasil dan spesifikasi atas hasil tersebut. Dengan kata lain, suatu pengecekan bahwa hasil dibuat dengan cara yang benar. Apakah struktur sistem benar sesuai yang diharapkan?

 

Proses membangun aliran produk sistem dari fase ke fase dengan interaksi yang kecil diantara dua langkah terlepas dari perpindahan antara keluaran dan masukan. Urutan kemajuan fase menguatkan disiplin tiap-tiap fase yang mempunyai suatu awalan khusus dan akhiran tertentu serta kemajuan yang dengan pasti dapat diakui. Di dalam disain sistem perancangan modern, model waterfall digunakan untuk penyajian menurut urutan waktu yang dibagi menjadi fase yang berurutan dan struktur yang umum seperti model aslinya. Di sini, penamaan fase tidaklah penting demikian pula nama yang sesuai dapat digunakan untuk proyek tertentu yang sedang dikerjakan.

 

Apresiasi dan Kritik terhadap Model Waterfall

Model waterfall lemah dalam menentukan teknik penerapan manajemen pengendalian atas suatu proyek; perencanaan, pengendalian dan manajemen resiko tidaklah dibungkus dalam model tersendiri. Lebih dari itu, taksiran biaya dan waktu yang diperkirakan dipersulit untuk masing-masing langkah. Life cycle yang menggunakan kebutuhan asli kemungkinan tidak lagi sesuai dengan kemungkinan kecil dalam membuat prototipe.

 

Probem utama pada model waterfall adalah adanya penyekatan yang tidak fleksibel pada proyek ke dalam langkah-langkah berbeda membuat model ini sulit dalam bereaksi terhadap perubahan kebutuhan pelanggan sehingga Model ini hanya sesuai ketika kebutuhan dengan baik dipahami dan perubahan secara wajar terbatas sepanjang proses disain.

Model waterfall dalam pengembangan sistem bekerja dengan baik ketika pengerjaan kembali atas produk yang terbatas pada jumlah kecil dan sisa produk tanpa adanya perubahan. Model ini bermanfaat untuk jenis yang tidak mudah gagal dan proyek perangkat lunak yang kuat serta dengan mudah diterapkan sehingga menghasilkan biaya yang kecil dan dapat menghemat waktu. Jika sistem dilakukan maka akan terjadi perubahan penting dan jika kebutuhan sistem tak dapat diramalkan kemudian pendekatan berbeda maka direkomendasikan pada pendekatan model lainnya karena model ini tidak dapat melakukannya.

Daftar Pustaka:

 

 

Barnette ND & McQuain WD. (1998). Intro Data Structures & SE. Computer Science Dept Va Tech.

Bista, Bharat (2006). The Waterfall Model: IT Project Management Solutions. http://www.buzzle.com/chapters/waterfall-model-it-project-management-solutions.html

Boehm, B. W. (1981). Software Engineering Economics, Prentice-Hall, Englewood Cliffs.

 

Garg, P.K. and M. Jazayeri (eds.) (1996). Process-Centered Software Engineering Environment, IEEE. Computer Society.

 

Pressman, Roger S. (2002). Rekayasa Perangkat Lunak: Pendekatan praktisi (buku I). Andi.

 

Royce, W., (1990). TRW’s Ada Process Model for Incremental Development of Large Software Systems, Proc. 12th. Intern. Conf. Software Engineering, IEEE Computer Society.

 

Scacchi, Walt (2001). Process Models in Software Engineering. Institute for Software Research, University of California

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: