MODEL PENGEMBANGAN PERANGKAT LUNAK

well sekarang ni ane ngeblog untuk ngerjain tugas individu mata kuliah IMK, dan saat ini pertemuan ke 9.

saat ini ane mau ngejelasin beberapa model-model yang di gunakan dalam Rekayasa perangkat lunak.

Berikut model modelnya :

A. Model Waterfall (air terjun)

• pengertian

       Waterfall model adalah model yang melakukan pendekatan pada perkembangan perangkat lunak secara seistematik dan sekuensial. Yang artinya kegiatan pada model ini dilakukan secara terurut berdasarkan panduan proses mulai dari komunikasi kepada client atau pelanggan sampai dengan aktifitas sampai pengorderan setelah masalah dipahami secara lengkap dan berjalan stabil sampai selesai.

   Ada 2 fase dalam model ini 

1.   Menurut Referensi Pressman

        

  2. Menurut Referensi Sommerville (ini yang sering digunakan)

  

   

Kedua fase-fase menggunakan nama yang berbeda pada tiap fasenya, tetapi pada dasarnya inti dari kedua fase-fase tersebut adalah sama. Tahapan-tahapan yang yang sering dijumpai adalah menurut refrensi dari Sommerville karena lebih terperinci perbedaan pada tiap fasenya.

a. Requirements definition

     Langkah ini merupakan analisa terhadap kebutuhan sistem. Pengumpulan data dalam tahap ini bisa melakukan sebuah penelitian, wawancara atau study literatur. Seorang sistem analis akan menggali informasi sebanyak-banyaknya dari user sehingga akan tercipta sebuah sistem komputer yang bisa melakukan tugas-tugas yang diinginkan olehuser tersebut. Tahapan ini akan menghasilkan dokumen user requirment atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan sistem. Dokumen ini lah yang akan menjadi acuan sistem analis untuk menterjemahkan ke dalam bahasa pemprogram.

b. System and software design

      Proses desain akan menerjemahkan syarat kebutuhan ke sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada : struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirment. Dokumen inilah yang akan digunakan proggrammer untuk melakukan aktivitas pembuatan sistemnya.

c. Implementation and unit testing

        Coding merupakan penerjemahan design dalam bahasa yang bisa dikenali oleh komputer. Dilakukan oleh programmer yang akan meterjemahkan transaksi yang diminta oleh user.Tahapan ini lah yang merupakan tahapan secara nyata dalam mengerjakan suatu sistem. Dalam artian penggunaan komputer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap sistem yang telah dibuat tadi. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki.

d. Integration and system testing

     Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau sistem operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional.

e. Operation and maintenance

    Perangkat lunak sudah dioperasikan oleh pelanggan dan jika ada kendala maka pengembang harus memperbaikinya

3. Keuntungan dan kelemahan model Waterfall

a. Keuntungan 

• Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.
• Dokumen pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi  setiap fase atau tahapan akan mempunyai dokumen tertentu.

b. Kekurangan 

• Waterfall model bersifat kaku sehingga sulit untuk melakukan perubahan pada sistem perangkat 
• Diperlukan manajemen yang baik, karena proses pengembangan tidak bisa dilakukan secara berulang sebelum  terjadinya suatu 
•  Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan
• Pelanggan sulit menyatakan kebutuhan, sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan

4. Pemakaian Waterfall model

Waterfall model digunakan untu pembuatan sistem perangkat lunak yang berukuran besardan pembuatannya secara terpisah.

-----------------------------------------------------------------------------------
B. The incremental model

      

1.    Pengertian 

• Dalam model Incremental ini proses pengerjaan perangkat lunak akan dilakukan perbagian sehingga bagian selanjutnya akan dikerjakan setelah bagian awal telah selesai dan selanjutnya sampai menghasilkan perangkat lunak yang lengkap dengan semua fungsi yang diperlukan dan pengerjaan perangkat lunak berakhir. Sebelum pengerjaan perangkat lunak akan dilakukan perancangan arsitektur software sebagai kerangka dalam pengerjaan perbagian 

   2.  Tahapan dari Incremental Model :

          Requirement -> penentuan kebutuhan perangkat lunak yang akan dibangun.

         Specification -> spesifikasi bagian dari perangkat lunak.

         Architecture Design -> pembuatan perancangan perangkat lunak (dasar dari kerangka kerja) 

  3. Kelebihan incremental model

         
a. Resiko yang rendah pada pengembangan sistem.

 b. Mengutamakan fungsi-fungsi pada sistem perangkat lunak sehingga kemudahan pemakaian sistem yang    paling di utamakan.

 c. Tahap awal adalan dasar dari pembuatan tahap berikutnya (dikerjakan secara terurut)

                                            

                     incremental model

      C. RAD (Rapid Application Development)

    1. Pengertian

         Rapid Application Development (RAD) adalah sebuah model proses perkembangan software                 sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan     sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai             dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik,        proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode      waktu yang sangat pendek (kira-kira 60 sampai 90 hari).

2. fase dalam RAD :

 a.       Bussiness Modelling
              Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut :
Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang memunculkannya?  Kemana informasi itu pergi ? Siapa yang memprosesnya?

b.       Data Modelling
          Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modeling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut.

c.       Process Modelling
              Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali  objek data.

d.       Application Generation
            RAD mengasumsikan pemakaian teknik generasi keempat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD telah banyak memproses kerja untuk memakai lagi komponen program yang ada atau menciptakan komponen yang bisa digunakan lagi.

e.       Testing and Turnover
               Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus diuji dan semua interface harus dilatih secara penuh.

D. V MODEL

 1. Pengertian

        Model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang yang dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linier, maka dalam model V proses dalikukan bercabang dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

      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. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya. 

2. Fase fase dalam V model

a.  Requirement Analysis & Acceptance Testing

     Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan pengguna.

Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.

b.  System Design & System Testing

     Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.

c.  Architecture Design & Integration Testing

    Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti: pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.

d.  Module Design & Unit Testing

Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.

e.  Coding

Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.

V Model memiliki beberapa kelebihan. Kelebihan-kelebihan tersebut secara garis besar dapat dijelaskan seperti berikut:

•   V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dan tool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.
• ·V Model dikembangkan dan di-maintain oleh publik. User dari V Model berpartisipasi dalam change control board yang memproses semua change request terhadap V Model. 

3. Kekurangan V model

V Model juga memiliki beberapa kekurangan. Kekurangan-kekurangan tersebut yaitu:

• V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.
• V Model terlalu fleksibel dalam arti ada beberapa activity dalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.

F. STAR LIFECYCLE MODEL

 Pada tahun 1989, Star siklus hidup model yang
diusulkan oleh Hartson dan Hix seperti yang ditunjukkan pada gambar.

Hal ini muncul dari beberapa pekerjaan empiris mereka melihat bagaimana desainer antarmuka

pergi tentang pekerjaan mereka. Mereka mengidentifikasi dua mode yang berbeda dari aktivitas:

 modus analitik dan sintetis modus. 

Yang pertama ditandai dengan pengertian seperti top-down,

pengorganisasian, peradilan, dan formal, bekerja dari pandangan sistem terhadap pengguna

pandangan.

 yang terakhir ditandai dengan pengertian seperti bottom-up, bebas berpikir, kreatif

dan adhoc, bekerja dari pandangan pengguna terhadap pandangan sistem. antarmuka

desainer bertugas di desainer perangkat lunak.

Berbeda dengan model siklus hidup diperkenalkan di atas, siklus hidup bintang tidak menentukan apapun

pemesanan kegiatan. Bahkan, kegiatan yang sangat saling berhubungan: Anda dapat memindahkan

dari kegiatan apapun kepada lainnya, asalkan Anda pertama kali pergi melalui kegiatan evaluasi.

Hal ini mencerminkan temuan dari studi empiris. Evaluasi merupakan pusat model ini,

dan setiap kali suatu kegiatan selesai, hasilnya (s) harus dievaluasi. Jadi proyek

mungkin mulai dengan pengumpulan persyaratan, atau mungkin mulai dengan mengevaluasi yang ada

situasi, atau dengan menganalisis tugas yang ada, dan sebagainya.





G. MODEL RANCANGAN  INTERAKSI SEDERHANA

Pada model rancangan interaksi sederhana ini input atau masukan hanya memiliki satu titik. yang mana

masukan tersebut diidentifikasikan apakah sesuai dengan kebutuhan, lalu didesain sesuai dengan persyaratan yang telah ditetapkan. Setelah diDesain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah rancangan tersebut dievaluasi.

Evaluasi dapat dilakukan dimana saja, rancangan yang telah di evakuasi dapat kambali didesain ulang atau apakah rancangan tersebut tidak sesuai dengan kebutuhan user, maka alur tersebut akan terus berputar 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.




H. THE STAR MODEL (HARTSON DAN HIX,1989)

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

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

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

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

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

   Evaluasi di pusat kegiatan Tidak ada pemesanan tertentu kegiatan. Pembangunan dapat dimulai pada salah satu Berasal dari studi empiris desainer antarmuka UCD adalah filosofi yang sangat umum yang instantiates dirinya dalam konteks sebuah proyek desain. Dalam HCI ada banyak usaha untuk datang dengan siklus hidup yang sebenarnya, dimana pengguna sangat penting. Contohnya termasuk Rubinstein dan iterasi Hersch berturut-turut 5 tahap, (collecion info), (desain), (implementasi), (evaluasi) dan (penyebaran) Yang satu di sini diambil dari Hartson dan Hix.  Model terjadi dengan menganalisis bagaimana desain terjadi dalam praktek Evaluasi merupakan pusat: hasil setiap kegiatan dievaluasi sebelum pergi ke yang berikutnya baik bottom-up dan top-down diperlukan dalam gelombangdesainer

perangkat lunak yang akrab dengan ini dalam pekerjaan mereka dan menyebutnya 'yo-yoing' penting untuk melakukan keduanya struktur dan detail pada saat yang sama dalam praktek ini adalah apa yang dilakukan - tapi hasil akhirnya menunjukkan sebaliknya persyaratan perusahaan mendikte = pendekatan top down yang adalah apa yang akan direkam