INTERAKSI MANUSIA KOMPUTER

“MODEL-MODEL DESAIN PERANGKAT LUNAK”

DISUSUN OLEH :

KELOMPOK : 3

YANUAR FADHLI (09111002014)

RIYAN ALFA RIZKIE (091110020 )

DEVI WAHYUNI LESTARI (09111002036)

DOSEN PEMBIMBING : NOVI YUSLIANI, M.T

FAKULTAS ILMU KOMPUTER

JURUSAN TEKNIK INFORMATIKA

UNIVERSITAS SRIWIJAYA2012-2013

MODEL-MODEL DESAIN PERANGKAT LUNAK

1. Model Air Terjun (Waterfall)

Pada tahun 1960-an dan 1970-an, proyek pengembangana perangkat lunak merupakan pekerjaan yang sangat memakan biaya dan waktu karena pengembangan perangkat lunak ini difokuskan pada perencanaan dan pengendalian (Basili dan Musa,1991). Kemunculan model air terjun adalah untuk membantu mengatasi kerumitan yang terjadi akibat proyek-proyek pengembangan perangkat lunak (Boehm,1976). Seperti gambar dibawah ini, sebuah model air terjun memacu tim pengembang untuk memerinci apa yang seharusnya perangkat lunak lakukan (mengumpulkan dan menentukan kebutuhan sistem) sebelum sistem tersebut dikembangkan.

Gambar 1.1. Penyajian sederhana dari model pengembangan air terjun

Kebutuhan Sistem

Spesifikasi Kebutuhan

Perangkat Lunak

Desain Perangkat Lunak

Implementasi Perangkat Lunak

Uji Mesin Formal Integrasi

Perangkat Lunak

Operasi dan Perawatan

Kemudian, model ini memungkinkan pemecahan misi pengembangan yang rumit menjadi beberapa langkah logis (desain, kode, pengujian dan seterusnya) dengan beberapa langkah yang pada akhirnya akan menjadi produk akhir yang siap pakai. Untuk memastikan bahwa sistem bisa dijalankan, setiap langkah akan membutuhkan validasi, masukan dan kriteria yang ada.

Paradigma Entry-Task-Validation (ETVX) adalah kunci karakteristik dari model air terjun dengan beberapa keuntungan. Paradigma ini memungkinkan pelacakan yang lebih akurat dengan kemajuan proyek dan dapat mengidentifikasi dengan jelas apabila terjadi kesalahan. Hal ini memaksa organisasi untuk mengembangkan sistem perangkat lunak yang lebih rapid an mudah diatur.

Model air terjun (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, serta mengambil kegiatan dasar seperti spesifikasi , pengembangan validasi, evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak , implementasi , pengujian dan seterusnya.

Model ini menggunakan milestone sebagai titik transisi dan pengujian, artinya setiap aktivitas pada tahap pengembangan harus diselesaikan sebelum menuju tahap pengembangan berikutnya. Sehingga model ini sangat sesuai untuk perangkat lunak dengan syarat-syarat yang telah didefinisikan secara lengkap sebelumnya karena besar kemungkinan tidak adanya perubahan aplikasi dimasa yang akan datang. Kondisi semacam ini akan sangat berpengaruh pada perangkat lunak dan menimbulkan masalah terhadap kebutuhan iterasi dimana aplikasi akan terus berkembang dengan penyesuaian-penyesuaian terhadap kebutuhan, proses bisnis dan lingkungan aplikasi yang terus berubah dari waktu kewaktu.

- Fase Model Air Terjun (Waterfall)

Seperti dikatakan sebelumnya model air terjun telah terstruktur pada beberapa fase terutama untuk membantu perusahaan konstruksi perangkat lunak untuk mengembangkan sistem konstruksi yang terorganisir. Dengan mengikuti metode ini, proyek ini akan dibagi menjadi beberapa tahapan sehingga lebih efisien dari segi proses.Misalnya Anda mulai dengan Tahap I dan menurut model ini, harus dilalui tahapan demi tahapan. Ini salah satu cara bergerak secara progresif ke tahap akhir dan sekali titik itu tercapai, Anda tidak bisa kembali, mirip dengan air di air terjun. Pada model Waterfall atau disebut  model air terjun, ada beberapa fase yang harus kita terapkan,yaitu:

1. Analisi kebutuhan lalu pendefenisiannya

Analisis dan Definisi Persyaratan melingkupin Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user sistem.

2. Perancangan Sistem dan Perangkat lunaknya

Perancangan sistem dan Perangkat Lunak  melingkupin  Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras atau perangkat lunak,lalu menentukan arsitektur sistem secara keseluruhan.

3. Implementasi dan unit testing

Implementasi dan pengujian unit : Perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.

4. Integrasi dan pengujian sistem

Integrasi dan Pengujian Sistem dimana Unit program atau program individual diintegrasikan dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi.

5. Pengoprasian dan perawatan

Operasi dan Pemeliharaan  Biasanya sih merupakan fase siklus yg paling lama (walaupun tidak seharusnya).dimana Sistem diinstall dan di pakai. Pemeliharaan pun mencakup koreksi dan berbagai error yg tdk ditemukan pada tahap-tahap sebelumnya, perbaikan atas implementasi unit sistem dan pengembangan pelayanan sistem.

- Rekayasa dan Pemodelan Sistem/Informasi

Karena perangkat lunak merupakan bagian dari suatu sistem maka langkah pertama dimulai dengan membangun syarat semua elemen sistem dan mengalokasikan ke perangkat lunak dengan memeperhatiakn hubungannya dengan manusia, perangkat keras dan database.

1. Analisis Kebutuhan Perangkat LunakProses menganalisis dan pengumpulan kebutuhan sistem yang sesuai dengan domain

informasi tingkah laku, unjuk kerja, dan antar muka (interface) yang diperlukan. Kebutuhan-kebutuhan tersebut didokumentasikan dan dilihat lagi dengan pelanggan.

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

3. Pengkodeaan (Coding)Pengkodean merupakan prses menerjemahkan desain ke dalam suatu bahasa yang bisa

dimengerti oleh komputer.

4. PengujianProses pengujian dilakukan pada logika internal untuk memastikan semua pernyataan

sudah diuji. Pengujian eksternal fungsional untuk menemukan kesalahan-kesalahan dan memastikan bahwa input akan memberikan hasil yang aktual sesuai yang dibutuhkan

5. Pemeliharaan

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

- Kelebihan dan Kekurangan

Kelebihan Model Waterfall

1. Bisa digunakan jika suatu persyaratan untuk membuat suatu software sudah dipahami dengan baik dan sudah lengkap semua persyaratan yang ada.

2. Setiap tahap dikerjakan dengan lengkap dan jelas.

3. Dokumentasi sangat baik.

4. Mudah diaplikasikan.

5. Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan pemeliharaan.

6. Ketika semua kebutuhan sistem dapat didefinisikan secara utuh , eksplisit, dan benar di awal project, maka software engineering dapat berjalan dengan baik dan tanpa masalah.

7. Efisiensi waktu dan teknis kerja.

8. karena adanya titik transisi yang jelas pada setiap tahap, maka akan memudahkan tim pengembang perangkat lunak dalam memonitor penjadwalan proyek, menetapkan tanggung jawab dan akuntabilitas peran personal dalam proyek perangkat lunak.

9. Metode Waterfall ini juga dikenal di kalangan pengembang perangkat lunak sehingga mudah digunakan. Hal ini lebih mudah untuk mengembangkan berbagai perangkat lunak melalui metode ini dalam kurun waktu singkat.

Kekurangan Model Waterfall

1. Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses. Hal ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan pengguna (user).

2. Jarang sekali proyek riil mengikuti aliran sekuensial yang dianjurkan model karena model ini bisa melakukan itersi tidak langsung . Hal ini berakibat ada perubahan yang diragukan pada saat proyek berjalan.

3. Pelanggan sulit untuk menyatakan kebutuhan secara eksplisit sehingga sulit untuk megakomodasi ketidakpastian pada saat awal proyek.

4. Pelanggan harus bersikap sabar karena harus menunggu sampai akhir proyek dilalui. Sebuah kesalahan jika tidak diketahui dari awal akan menjadi masalah besar karena harus mengulang dari awal.

5. Pengembang sering malakukan penundaan yang tidak perlu karena anggota tim proyek harus menunggu tim lain untuk melengkapi tugas karena memiliki ketergantungan hal ini menyebabkan penggunaan waktu tidak efesien.

6. Model air terjun harus digunakan hanya ketika persyaratan dipahami dengan baik.

2. Model Spiral

Proses model yang lain, yang cukup populer adalah Spiral Model. Model ini juga cukup baru ditemukan, yaitu pada sekitar tahun 1988 oleh Barry Boehm pada artikel A Spiral Model of Software Development and Enhancement. Spiral model adalah salah satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki oleh model prototyping dan digabungkan dengan aspek sistimatis yang dikembangkan dengan model waterfall. Tahap desain umumnya digunakan pada model Waterfall, sedangkan tahap prototyping adalah suatu model dimana software dibuat prototype (incomplete model), “blue-print”-nya, atau contohnya dan ditunjukkan ke user / customer untuk mendapatkan feedback-nya. Jika prototype-nya sudah sesuai dengan keinginan user / customer, maka proses SE dilanjutkan dengan membuat produk sesungguhnya dengan menambah dan memperbaiki kekurangan dari prototype tadi.

Model ini juga mengkombinasikan top-down design dengan bottom-up design, dimana top-down design menetapkan sistem global terlebih dahulu, baru diteruskan dengan detail sistemnya, sedangkan bottom-up design berlaku sebaliknya. Top-down design biasanya diaplikasikan pada model waterfall dengan sequential-nya, sedangkan bottom-up design biasanya diaplikasikan pada model prototyping dengan feedback yang diperoleh. Dari 2 kombinasi tersebut, yaitu kombinasi antara desain dan prototyping, serta top-down dan bottom-up, yang juga diaplikasikan pada model waterfall dan prototype, maka spiral model ini dapat dikatakan sebagai model proses hasil kombinasi dari kedua model tersebut. Oleh karena itu, model ini biasanya dipakai untuk pembuatan software dengan skala besar dan kompleks.

Spiral model dibagi menjadi beberapa framework aktivitas, yang disebut dengan task regions. Kebanyakan aktivitas2 tersebut dibagi antara 3 sampai 6 aktivitas. Berikut adalah aktivitas-aktivitas yang dilakukan dalam spiral model:

Customer communication. Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.

Planning. Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.

Analysis risk. Aktivitas analisis resiko ini dijalankan untuk menganalisis baik resiko secara teknikal maupun secara manajerial. Tahap inilah yang mungkin tidak ada pada model proses yang juga menggunakan metode iterasi, tetapi hanya dilakukan pada spiral model.

Engineering. Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.

Construction & Release. Aktivitas yang dibutuhkan untuk develop software, testing, instalasi dan penyediaan user / costumer support seperti training penggunaan software serta dokumentasi seperti buku manual penggunaan software.

Customer evaluation. Aktivitas yang dibutuhkan untuk mendapatkan feedback dari user / customer berdasarkan evaluasi mereka selama representasi software pada tahap

engineering maupun pada implementasi selama instalasi software pada tahap construction and release.

Berikut adalah gambar dari spiral model secara umum :

Satu lingkaran dari bentuk spiral pada spiral model dibagi menjadi beberapa daerah yang disebut dengan region. Region tersebut dibagi sesuai dengan jumlah aktivitas yang dilakukan dalam spiral model. Tentunya lingkup tugas untuk project yang kecil dan besar berbeda. Untuk project yang besar, setiap region berisi sejumlah tugas-tugas yang tentunya lebih banyak dan kompleks daripada untuk project yang kecil. SE berjalan dari inti spiral berjalan mengitari sirkuit per sirkuit. Sebagai contoh untuk sirkuit pertama dilakukan untuk pembangunan dari spesifikasi dari software dengan mencari kebutuhan dari customer. Untuk sirkuit pertama harus menjalani semua aktivitas yang didefinisikan. Setelah 1 sirkuit terlewati lanjut ke tugas selanjutnya misalnya membangun prototype. Tugas ini juga harus mengitari 1 sirkuit dan begitu terus selanjutnya sampai project selesai.

Tidak seperti model-model konvesional dimana setelah SE selesai, maka model tersebut juga dianggap selesai. Akan tetapi hal ini tidak berlaku untuk spiral model, dimana model ini dapat digunakan kembali sepanjang umur dari software tersebut. Pada umumnya, spiral model digunakan untuk beberapa project seperti Concept Development Project (proyek pengembangan konsep), New Product Development Project (proyek pengembangan produk baru), Product Enhancement Project (proyek peningkatan produk), dan Product Maintenance Project (proyek pemeliharaan proyek). Keempat project tersebut berjalan berurutan mengitari sirkuit dari spiral. Sebagai contoh setelah suatu konsep dikembangkan dengan melalui aktivitas2 dari spiral model, maka dilanjutkan dengan proyek selanjutnya yaitu pengembangan produk baru, peningkatan produk, sampai pemeliharaan proyek. Semuanya melalui sirkuit2 dari spiral model.

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan

dalam model tersebut. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak. Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek. Setiap loop dibagi dalam 4 sektor,yaitu

1. Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan.

3. Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe) Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.

4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya.

Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan bagian-bagian sistem yang memiliki persyaratan keselamatan yang

tinggi dan pendekatan reuse digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

- Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru (new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan. Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

- Mengapa spiral model begitu populer?

Pendekatan dengan model ini sangat baik digunakan untuk pengembangan sistem software dengan skala besar. Karena progres perkembangan dari SE dapat dipantau oleh kedua belah pihak baik developer maupun user / customer, sehingga mereka dapat mengerti dengan baik mengenai software ini begitu juga dengan resiko yang mungkin didapat pada setiap aktivitas yang dilakukan. Selain dari kombinasi 2 buah model yaitu waterfall dan prototyping, kelebihan dari software ini ada pada analisis resiko yang dilakukan, sehingga resiko tersebut dapat direduksi sebelum menjadi suatu masalah besar yang dapat menghambat SE.

Model ini membutuhkan konsiderasi langsung terhadap resiko teknis, sehingga diharapkan dapat mengurangi terjadinya resiko yang lebih besar. Sebenarnya dengan menggunakan prototype juga bisa menghindari terjadinya resiko yang muncul, tetapi kelebihan dari model ini yaitu dilakukannya proses prototyping untuk setiap tahap dari evolusi produk secara kontinu. Model ini melakukan tahap2 yang sudah sangat baik didefinisikan pada model waterfall dan ditambah dengan iterasi yang menyebabkan model ini lebih realistis untuk merefleksikan dunia nyata. Hal-hal itulah yang menjadi kelebihan menggunakan spiral model. Meskipun banyak kelebihan tetapi tentu masih ada kekurangannya. Kekurangannya ada pada masalah pemikiran user / customer dimana mereka pada umumnya tidak

- Kelebihan dan Kekurangan

Kelebihan model Spiral

1. Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.

2. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar3. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko

setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .4. Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap

keadaan di dalam evolusi produk.5. Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya

ke dalam kerangka kerja iteratif .6. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi

resiko sebelum menjadi permaslahan yang serius.

Kelemahan model Spiral

1. Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.2. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang

serius jika resiko mayor tidak ditemukan dan diatur.3. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolute.