Model-Model Life Cycle pada software

Nama: Sudarmono
Nim   : 8020110168
Kls     : 05PT5

Tugas Interaksi Manusia dan Komputer

1. MODEL WATERFALL

Sejarah Model Waterfall

Model Waterfall ini awalnya ditemukan oleh Winston W. Royce pada tahun 1970 . Dia menulis sebuah artikel ilmiah yang berisi pandangan pribadinya pada pengembangan perangkat lunak . Pada paruh pertama dari artikel, ia membahas sebuah proses yang dia sebut ” megah ” . Dia bahkan menggambar sosok model , dan lain yang menunjukkan mengapa hal itu tidak bekerja ( karena persyaratan selalu berubah ) . Model ini adalah air terjun . Dia menggunakannya sebagai contoh dari proses yang sama sekali tidak bekerja . Di paruh kedua artikel ia menggambarkan proses berulang-ulang bahwa ia dianggap jauh lebih baik .

         Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Berikut gambar model waterfall.

waterfall

Gambar: Model Waterfall

Pengertian Waterfall

Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan.

Langkah-langkah yang harus dilakukan pada metodologi Waterfall

1.      Requirement Analysis

Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.

2.  System Design

Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.

3.  Implementation

Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.

4.  Integration & Testing

Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.

5.  Operation & Maintenance

Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki  kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.

Keuntungan  Waterfall

  • Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.
  • Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi  setiap fase atau tahapan akan mempunyai dokumen tertentu.
  • Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.
Kelemahan Waterfall
  • Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.
  • Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.
  • Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.
  • Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.
  • Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru.

Kapan Model Waterfall digunakan?

Teori-teori lama menyimpulkan ada beberapa hal, yaitu:

  1. Ketika semua persyaratan sudah dipahami dengan baik di awal pengembangan.
  2. Definisi produk stabil dan tidak ada perubahan saat pengembangan untuk alasan apapun seperti perubahan eksternal, perubahan tujuan, perubahan anggaran atau perubahan teknologi. Untuk itu, teknologi yang digunakan pun harus sudah dipahami dengan baik.
  3. Menghasilkan produk baru, atau versi baru dari produk yang sudah ada. Sebenarnya, jika menghasilkan versi baru maka sudah masuk incremental development, yang setiap tahapnya sama dengan Waterfall kemudian diulang-ulang.
  4. Porting produk yang sudah ada ke dalam platform baru.

Dengan demikian, Waterfall dianggap pendekatan yang lebih cocok digunakan untuk proyek pembuatan sistem baru. Tetapi salah satu kelemahan paling dasar adalah menyamakan pengembangan perangkat keras dengan perangkat lunak dengan meniadakan perubahan saat pengembangan. Padahal, galat diketahui saat perangkat lunak dijalankan, dan perubahan-perubahan akan sering terjadi.

2. V MODEL

Pengertian V Model

Merupakan model pengembangan perangkat lunak yang didasarkan pada hubungan antara setiap fase pengembangan siklus hidup yang tercantum dalam model Watterfall yang merupakan pengembangan perangkat lunak dan fase yang terkait pengujian. Bisa dikatakan model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang.

v model

Gambar: V Model

Tahapan dalam  V Model

Tahapan pada V Model dibagi menjadi 2 garis besar yaitu tahap Verifikasi dan Validasi atau testing.

Tahap Verfiikasi mengacu kepada usaha penyesuaian spesifikasi software dengan kebutuhan klien/konsumen, tahapan ini meliputi serangkaian kegiatan sebagai berikut:

  1. Business Case: Merupakan tahapan awal yang menggambarkan kebutuhan/harapan konsumen terhadap sistem yang akan dikembangkan, termasuk manfaat sistem terhadap konsumen dan perkiraan biaya yang harus disediakan.
  2. Requirement: pada fase ini klien mendapatkan gambaran atau diminta memberikan gambaran kebutuhan yang diharapkan dapat dipenuhi oleh software, baik kebutuhan fungsional maupun non fungsional.
  3. Analisis Informasi: Setelah diperoleh spesifikasi sistem dari fase requirement, selanjutnya aktivitas difokuskan bagaimana cara kerja software untuk memenuhi kebutuhan tersebut, termasuk metode, hardware dan software apa saja yang diperlukan untuk mencapai kebutuhan yang sudah didefinisikan.
  4. Perancangan Sistem: pada tahapan ini akan dibuat rancangan software secara lebih terinci sesuai spesifikasi yang sudah disepakati.
  5. Unit Design: merancang setiap elemen/unit software termasuk rancangan modul/program, antarmuka, database dan lain-lain.
  6. Development: merealisasikan hasil rancangan menjadi satu aplikasi/program tertentu.

Tahapan Validasi merupakan serangkaian tahapan yang mengacu kepada kesesuaian software dengan spesifikasi yang sudah ditetapkan. Tahapan ini dicapai melalui serangkaian pengujian/testing sebagai berikut:

  • Unit test: menguji setiap komponen/unit program apakah sesuai dengan rancangan unit yang sudah ditetapkan. Secara teoritis seharusnya pengujian dilakukan oleh orang tertentu yang bertugas sebagai software tester, tetapi dalam kenyataannya seringkali unit testing dilakukan oleh programmer sendiri.
  • Interface test: setelah semua komponen diuji secara terpisah, tahapan selanjutnya dilakukan interface test untuk melihat sejauh mana setiap komponen dapat berinteraksi satu sama lain sesuai dengan fungsi yang diharapkan.
  • System test: setelah semua interface berjalan dengan baik, selanutnya dilakukan system test untuk melihat sejauh mana sistem/software dapat memenuhi kebutuhan secara keseluruhan. System testing bersifat menyeluruh dan tidak dapat dilakukan berdasarkan fungsionalitas sistem yang diuji secara terpisah. Aktivitas pada system testing termasuk melakukan pengujian hal-hal berikut:
    1. Performance – apakah kinerja sistem sesuai dengan target yang sudah didefinisikan sebelumnya.
    2. Volume – apakah software/sistem dapat menampung volume informasi yang cukup besar.
    3. Stress – apakah software/sistem dapat menampung sejumlah informasi pada waktu-waktu tertentu.
    4. Documentation – apakah semua dokumentasi penting sudah disiapkan.
    5. Robustness – apakah software/sistem cenderung stabil pada berbagai kondisi diluar dugaan/ekstrim.
  • Acceptance test merupakan aktivitas untuk menguji sejauh mana sistem/software dapat membantu memecahkan business case, dalam artian apakah sistem/software tersebut sudah sesuai dengan harapan konsumen/klien dan sejauh mana manfaat sistem/software ini bagi klien. Test ini sering kali disebut sebagai User Acceptance Test (UAT).
  • Release testing: test ini dilakukan untuk menguji sejauh mana sistem/software dapat mendukung aktivitas organisasi dan berjalan dengan harmonis sesuai dengan kegiatan rutin organisasi. Beberapa pertanyaan coba dijawab pada fase ini misalnya apakah software tersebut mempengaruhi sistem lain? Apakah software tersebut kompatibel dengan sistem lain? Bagaimana kinerja sistem sebenarnya di dalam organisasi?
 Kelebihan V model:
  •  V model sangat fleksibel. V model ini bisa digunakan untuk project tailoring serta penambahan pengurangan method dan tool secara dinamik.
  •   V model dikembangkan dan di maintain oleh publik. User dari V model berpartisipasi dalam change board yang memproses semua change request terhadap V model.
Kekuranagn V model
  •  V model hanya bisa digunakan sekali dalam suatu proyek hal tersebut disebabkan kerena V model merupakan model yang project oriented.
  • V model bersifat terlalu fleksibel sehingga mengakibatkan beberapa aktivitas-aktivitas yang digambarkan dalam V model menjadi terlalu abstrak. Hal tersebut mengakibatkan tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.

Dimana saja V Model Diterapkan?

  1. Dalam proyek teknologi informasi di Jerman
  2. V Model dibandingkan dengan CMM
  3. V Model didesain untuk mengembangkan sistem yang didalamnya terdapat dua komponen
  4. Pengembangan V Model dalam bidang industri dapat dilakukan dengan mudah

3. MODEL RAD

Pengertian RAD

Rapid Application Development (RAD) atau Rapid Prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini.  Rapid application development menggunakan metode interatif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.
Rapid Application Development (RAD)
Model RAD menekankan pada fase-fase berikut :
  1. Business modeling. Pada tahap ini, aliran informasi (information flow) pada fungsi-fungsi bisnis dimodelkan untuk mengetahui informasi apa yang mengendalikan proses bisnis, informasi apa yang hasilkan, siapa yang membuat informasi itu, kemana saja informasi mengalir, dan siapa yang mengolahnya.
  2. Data modeling. Aliran informasi yang didefinisikan dari business modeling, disaring lagi agar bisa dijadikan bagian-bagian dari objek data yang dibutuhkan untuk mendukung bisnis tersebut. Karakteristik (atribut) setiap objek ditentukan beserta relasi antar objeknya.
  3. Process modeling. Objek-objek data yang didefinisikan sebelumnya diubah agar bisa menghasilkan aliran informasi untuk diimplementasikan menjadi funsi bisnis. Pengolahan deskripsi dibuat untuk menambah, merubah, menghapus, atau mengambil kembali objek data.
  4. Application generation. RAD bekerja dengan menggunakan fourth generation techniques (4GT). Sehingga pada tahap ini sangat jarang digunakan pemrograman konvensional menggunakan bahasa pemrograman generasi ketiga (third generation programming languages), tetapi lebih ditekankan pada reuse komponen-komponen (jika ada) atau membuat komponen baru (jika perlu). Dalam semua kasus, alat bantu untuk otomatisasi digunakan untuk memfasilitasi pembuatan perangkat lunak.
  5. Testing and turnover. Karena menekankan pada penggunaan kembali komponen yang telah ada (reuse), sebagian komponen-komponen tersebut sudah diuji sebelumnya. Sehingga mengurangi waktu testing secara keseluruhan. Kecuali untuk komponen-komponen baru.
Kelebihan RAD Model :
  • RAD memang lebih cepat dari  Waterfall. Jika kebutuhan dan batasan proyek sudah diketahui dengan baik. Juga jika proyek memungkinkan untuk dimodularisasi.
Kekurangan RAD Model
  • Tidak semua proyek bisa dipecah (dimodularisasi), sehingga belum tentu RAD dipakai pada semua proyek
  • Karena proyek dipecah menjadi beberapa bagian, maka dibutuhkan banyak orang untuk membentuk suatu tim yang mengerjakan tiap bagian tersebut.
  • Membutuhkan komitmen antara pengemang dengan pelanggan.
  • Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar.
  • Resiko teknis yang tinggi kurang cocok untuk model ini.
  • Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.
  • Karena dibuat dengan reuse komponen-komponen yang sudah ada, fasilitas-fasilitas pada tiap komponen belum tentu digunakan seluruhnya oleh program yang me-reuse-nya sehingga kualitas program.

4. MODEL SIKLUS HIDUP STAR (HARTSON & HIX, 1998)

Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design ) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama akan lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user.
Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.

star-model

  1. Analisa
    Identifikasi kemampuan user, strategi yang digunakan untuk meningkatkan ketrampilannya, alat yang saat ini dipakai, masalah-masalah yang dialami, perubahan yang diinginkan baik dalam ketrampilan maupun peralatan.
    Metode : tanya kemampuan user dan buat daftar dengan skala prioritas, observasi ketrampilan di lapangan.
  2. Evaluasi kompetisi
    Tentukan kekuatan dan kelemahan rancangan
    Metode : pengguna diminta untuk mencoba menggunakan berbagi produk dan minta untuk menyebutkan kelebihan dan kelemahan dari masing-masing produk.
  3. Rancangan sambil jalan
    Gunakan hasil analisa untuk membuat alternatif solusi, minta masukan sampai dengan penentuan pilihan yang terbaik.
    Metode : tanyai user sehubungan dengan pengalaman menggunakan prototipe.
  4. Evaluasi dan Validasi
    Secara periodik user memberikan masukan selama pengembangan dan perancangan akan diulang berdasarkan masukan tadi.
    Metode : amati kebutuhan pokok user dalam menggunakan sistem.
  5. Benchmark
    Memadukan hal-hal terbaik yang dimiliki pesaing untuk diterapkan dalam sistem yang dibangun Metode : menggali informasi dari user hal-hal yang sebaiknya ada dibandingkan dengan kompetitor, contoh : situs IBM.

5. MODEL RANCANGAN INTERAKSI SEDERHANA

interaksi-sederhana

Pada model rancangan interaksi sederhana ini input atau masukan hanya memiliki satu titik. yang mana masukan tersebut diidentifikasikan apakah sesuai engan kebutuhan, lalu didesain sesuia dengan persyaratan yang telah ditetap kan. Setelah diDesain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah racangan tersebut dievaluasi.
Evaluasi dapat dilaukan dimana saja, rancangan yang telah di evakuasi dapat kambali didesain ulang atau apakah rancanagn tersebut tidak sesuai dengan kebutuhan user, maka alur tersebut akan terus berbupar hingga pada tahap evaluasi tidak lagi terjadi kesalahan, baik dalam penetapan kebutuhan user maupun pendesainannya, sehingga pada tahap evaluasi terciptalah sebuah hasil akhir yang valid.

 

 

Referensi

http://tarmo.fi/blog/2005/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/

http://www.suburanugerah.com/2011/10/kapan-waterfall-model-digunakan.html

http://tonyjustinus.wordpress.com/2007/11/11/waterfall-process-model/

http://citrahuang99.wordpress.com/2013/01/21/citrahuang09-tugas-imk-model-siklus-hidup-software-wordpress-com/

http://imk-a.blogspot.com/2013/06/topik-3-paradigma-interaksi-prinsip.html

Tinggalkan komentar