Waterfall Model

    Waterfall model pertama kali diperkenalkan oleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier. Output dari setiap tahap merupakan input bagi tahap berikutnya.

      Waterfall Model adalah sebuah metode pengembangan software yang bersifat sekuensial . selain ini Model ini merupakan model yang paling banyak dipakai oleh para pengembang software. Inti dari metode waterfall adalah pengerjaan dari suatu sistem dilakukan secara berurutan atau secara linear. Jadi jika langkah satu belum dikerjakan maka tidak akan bisa melakukan pengerjaan langkah 2, 3 dan seterusnya.  Secara otomatis tahapan ke-3 akan bisa dilakukan jika tahap ke-1 dan ke-2 sudah dilakukan. Berikut tahapan dari model waterfall:

      1. Analisis dan definisi persyaratan

                Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user, Dalam tahapan ini jasa, kendala dan tujuan dari konsultasi dengan pengguna sistem. Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. Dengan kata lain, dalam tahapn ini dilakukan analisa kebutuhan, kemudian diverifikasi klien dan tim SQA.

Beberapa macam requirement:

1. User Requirement (Kebutuhan Pengguna)

                Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya. Dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.

2. System Requirement (Kebutuhan Sistem)

                Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

3. Software Requirement Specification (Spesifikasi Kebutuhan Perangkat Lunak)

                Gambaran abstrak dari rancangan perangkat lunak yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.

      2. Perancangan sistem dan perangkat lunak

                Perancangan perangkat lunak adalah proses dimana analisa diterjemahkan menjadi “cetak-biru” untuk membangun perangkat lunak. Awalnya, cetak biru menggambarkan pandangan menyeluruh perangkat lunak. Yaitu, desain diwakili pada tingkat yang dapat langsung ditelusuri pada sistem tertentu objektif dan data yang lebih rinci, fungsional, dan persyaratan yang diperlukan. Seperti terjadi pengulangan desain, perbaikan dari desain sebelumnya.

                Kegiatan ini menentukan arsitektur sistem secara keseluruhan Fokus pada struktur data, arsitektur perangkat lunak, representasi interface, dan detail algoritma prosedural. Proses ini menerjemahkan syarat / kebutuhan ke dalam sebuah representasi perangkat lunak.

Metode Perancangan:

• Perancangan Data

                Yaitu transformasi model data yang dihasilkan oleh proses analisis menjadi struktur  data yang dibutuhkan pada saat implementasi.

Hasil perancangan data adalah:

- struktur data siap diprogram

- struktur basis data siap dibuat oleh pemrogram

- prosedur/operasi untuk mengakses data, siap   deprogram

• Perancangan Arsitektur

                Yaitu definisi keterkaitan antar elemen-elemen utama yang akan membentuk program.

Hasil perancangan arsitektural:

Structure Chart yang merepresentasikan gambaran menyeluruh struktur/ arsitektur perangkat lunak, beserta seluruh hierarki kendali/passing parameter, yang siap dituliskan dalam bentuk modul program.

• Perancangan Antarmuka

                Yaitu penjabaran komunikasi: internal perangkat lunak, antara perangkat lunak, dengan sistem diluarnya, dan antara perangkat lunak dengan usernya.

Hasil perancangan antarmuka adalah:

- definisi antarmuka modul yang siap untuk diprogram

- definisi / format rancangan layar yang siap diimplementasikan

• Perancangan Prosedur

                Yaitu transformasi elemen struktural dari arsitektur program menjadi deskripsi prosedur.

Hasil perancangan prosedur adalah:

- Flow-chart

- Algoritma/pseudocode/program design language

      3. Implementasi dan pengujian unit

            Pada tahap ini dilakukan kerja untuk membangun perangkat lunak berdasarkan analisa dan pemodelan yang telah dilakukan. Sehigga hasil dari tahap ini adalah basis data dan source code perangkat lunak.

            Selama tahap ini, desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Desain yang telah disetujui, diubah dalam bentuk kode-kode program. Tahap ini, kode-kode program yang dihasilkan masih pada tahap modul-modul. Diakhir tahap ini, tiap modul di testing tanpa diintegrasikan. Perancangan perangkat lunak direalisasikan sebagai serangkaian program

      4. Integrasi dan pengujian system

                  Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah terpenuhi 

                  Setelah source code dihasilkan, perangkat lunak harus diuji untuk menemukan (dan membenarkan) sebanyak mungkin kesalahan yang dibuat.

                  Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah uji coba, sistem disampaikan ke konsumen.

Metode pengetesan:

1. Black box testing

                Black box testing memperlakukan pengujian perangkat lunak sebagai “kotak hitam” – tanpa pengetahuan tentang pelaksanaan internal.

                 

2. White box testing

                White box testing adalah ketika penguji memiliki akses ke struktur data internal dan algoritma termasuk source code.

      5. Operasi dan pemeliharaan

                Merupakan fase siklus yang paling lama. Sistem diinstall dan dipakai. Perbaikan mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.

                Proses pemeliharaan perangkat lunak dan keseluruhan sistem bila terjadi kesalahan pada program, atau terjadi perubahan lingkungan perangkat lunak dan juga bila terjadi perubahan requirements dan maintenance yang bersifat preventif untuk mengantisipasi keadaan yang tidak diinginkan.

                Sistem diinstall dan dipakai. Perbaikan mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.

Kelebihan waterfall :

v  Developer dituntut bekerja secara disiplin

v  Simple dan mudah diimplementasikan

v  Dokumen lengkap

v  Selalu dalam kontrol SQA

v  Maintenance mudah, karena dokumen lengkap

Kekurangan Waterfall :

v  Konsumen kesulitan membaca dokumen, komunikasi menjadi sulit

v  Alur linier, proses lambat

v  Konsumen tidak dapat melihat hasil hingga akhir tahapan

v   Personil tidak bekerja optimal, karena ada waktu tunggu sebuah tahapan selesai

v   Model ini hanya pas jika requirement nya dapat dipahami dengan baik dan perubahan yang terjadi sangat terbatas selama proses desain berlangsung.

Sumber : http://angga17kireina.wordpress.com/about/

               http://materi-kuliah-q.blogspot.com/2011/04/waterfall-model.html

Read More

UML (Unified Modeling Language)

UML (Unified Modeling Language)

UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO (Object-Oriented).

Versi 2.0 dari UML mendefinisikan satu set dari empat belas teknik diagram yang digunakan untuk memodelkan sistem. Diagram yang digunakan dipecah menjadi dua kelompok utama: satu untuk pemodelan struktur dari sistem dan satu untuk pemodelan sifat. Diagram pemodelan struktur termasuk kelas, objek, paket, penyebaran, komponen, dan diagram struktur komposit. Diagram pemodelan sifat meliputi aktifitas, sequence, komunikasi, tinjauan interaksi, waktu, mesin perilaku negara, mesin penentu sifat, dan diagram use case.

A. Structure Diagrams

Seperti disebutkan di atas, diagram struktur termasuk kelas, objek, paket, penyebaran, komponen, dan diagram struktur komposit. Diagram struktur menyediakan cara untuk mewakili data dan hubungan statis yang berada dalam sistem informasi. Di bawah ini, akan digambarkan tujuan dasar dari masing-masing diagram struktur.

Class Diagram
Tujuan utama dari class diagram adalah untuk menciptakan sebuah kosa kata yang digunakan oleh analis dan pengguna. Diagram kelas biasanya merupakan hal-hal, ide-ide atau konsep yang terkandung dalam aplikasi. Misalnya, jika anda sedang membangun sebuah aplikasi penggajian, diagram kelas mungkin akan berisi kelas yang mewakili hal-hal seperti karyawan, cek, dan pendaftaran gaji. Diagram kelas juga akan menggambarkan hubungan antara kelas.

Object Diagram
Object diagram sangat mirip dengan diagram kelas. Perbedaan utama adalah bahwa diagram objek menggambarkan objek dan hubungan mereka. Tujuan utama dari diagram objek adalah untuk memungkinkan analis untuk mengungkap rincian tambahan kelas. Dalam beberapa kasus, penyataan variabel dari sebuah class diagram dapat membantu pengguna atau analis dalam menemukan atribut tambahan yang relevan, hubungan, dan atau operasi, atau mungkin menemukan bahwa beberapa atribut, hubungan, atau operasi yang salah tempat.

Package Diagram
Package diagram utamanya digunakan untuk mengelompokkan elemen diagram UML yang berlainan secara bersama-sama ke dalam tingkat pembangunan yang lebih tinggi yaitu berupa sebuah paket. Diagram paket pada dasarnya adalah diagram kelas yang hanya menampilkan paket, disamping kelas, dan hubungan ketergantungan, disamping hubungan khas yang ditampilkan pada diagram kelas. Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka.

Deployment Diagram
Deployment diagram digunakan untuk mewakili hubungan antara komponen-komponen hardware yang digunakan dalam infrastruktur fisik sistem informasi. Misalnya, ketika merancang suatu sistem informasi terdistribusi yang akan menggunakan jaringan luas, diagram penyebaran dapat digunakan untuk menunjukkan hubungan komunikasi antara node yang berbeda dalam jaringan. Mereka juga dapat digunakan untuk mewakili komponen perangkat lunak dan bagaimana mereka ditempatkan di atas arsitektur fisik atau infrastruktur sistem informasi. Dalam hal ini, diagram penyebaran merupakan lingkungan pelaksanaan perangkat lunak.

Component Diagram
Component diagram memungkinkan desainer untuk memodelkan hubungan fisik antara modul fisik dari kode. Diagram ini bila dikombinasikan dengan diagram penyebaran dapat digunakan untuk menggambarkan distribusi fisik dari modul perangkat lunak melalui jaringan. Misalnya, ketika merancang sistem client-server, hal ini berguna untuk menunjukkan mana kelas atau paket kelas akan berada pada node klien dan mana yang akan berada di server. Diagram komponen juga dapat berguna dalam merancang dan mengembangkan sistem berbasis komponen.

Composite Structure Diagram
UML 2.0 menyediakan diagram baru ketika struktur internal dari kelas bersifat kompleks maka disediakan composite structure diagram. Diagram struktur komposit ini digunakan untuk model hubungan antara bagian-bagian dari sebuah kelas. Sebagai contoh, ketika pemodelan pendaftaran penggajian, analis mungkin ingin kelas yang mewakili seluruh laporan serta kelas-kelas yang mewakili header, footer, dan garis-garis detail laporan. Dalam sebuah diagram kelas standar, ini akan membutuhkan analis untuk memodelkan pendaftaran penggajian menjadi empat kelas terpisah yang memiliki hubungan, kemudian menghubungkan mereka bersama-sama. Sebaliknya, diagram struktur komposit akan berisi tiga subclass: header, footer, dan garis detail. Diagram struktur komposit juga berguna ketika dilakukan pemodelan struktur internal komponen untuk sistem berbasis komponen.

B. Behavior Diagram

Diagram sifat yang termasuk dalam UML 2.0 adalah aktifitas, sequence, komunikasi, gambaran interaksi, waktu, mesin penentu sifat, mesin penentu protokol, dan diagram use case. Diagram pemodel sifat menyediakan analis dengan cara menggambarkan hubungan dinamis antara instansi atau benda yang mewakili sistem informasi bisnis. Diagram pemodel sifat juga memungkinkan pemodelan perilaku dinamik dari objek individu sepanjang masa aktifnya. Diagram sifat mendukung analis dalam memodelkan persyaratan fungsional agar sistem informasi berkembang.

Activity Diagram
Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel.

Interaction Diagram
Interaction diagram menggambarkan interaksi antara objek dari suatu sistem informasi berorientasi objek. UML 2.0 menyediakan empat diagram interaksi yang berbeda: sequence, komunikasi, gambaran interaksi, dan diagram waktu. Masing-masing diagram diperkenalkan di sini.

1. Sequence diagram memungkinkan analis untuk menggambarkan interaksi dinamis antara objek-objek dalam suatu sistem informasi. Sequence diagram sejauh ini merupakan jenis interaksi yang paling umum digunakan dalam pemodelan berorientasi objek. Sequence diagram menekankan penyusunan berbasis waktu untuk kegiatan yang dilakukan dengan satu set dari objek yang berkolaborasi. Sequence diagram sangat berguna dalam membantu analis, memahami spesifikasi real-time dan menggunakan kasus yang rumit (lihat di bawah). Diagram ini dapat digunakan untuk mendeskripsikan baik secara fisik dan logis interaksi antara objek. Dengan demikian, mereka berguna dalam kedua kegiatan analisis dan desain.

2. Communication diagram memberikan pandangan alternatif dari interaksi dinamis yang terjadi di antara objek dalam suatu sistem informasi berorientasi objek. Dimana sequence diagram menekankan penyusunan berbasis waktu dari suatu kegiatan, diagram komunikasi lebih berfokus pada suatu set pesan yang disampaikan dalam sekumpulan objek yang berkolaborasi. Dengan kata lain, diagram komunikasi menggambarkan bagaimana objek dapat berkolaborasi untuk mendukung beberapa aspek dari fungsi yang diperlukan dari sistem. Urutan atau penyusunan berdasarkan waktu dari pesan ditunjukkan melalui skema urutan penomoran.

3. Interaction overview diagram membantu analis memahami use case yang kompleks. Mereka memberikan gambaran aliran proses dari kontrol. Diagram gambaran interaksi memperluas diagram aktifitas melalui penambahan fragmen sequence dari sequence diagram. Akibatnya, urutan fragmen diperlakukan seolah-olah fragmen merupakan aktifitas dalam diagram aktifitas. Keuntungan utama menggunakan diagram gambaran interaksi adalah bahwa anda dapat dengan mudah memodelkan aliran urutan alternatif.

4. Timing diagram menggambarkan interaksi antara objek sepanjang sumbu waktu. Tujuan utama dari diagram waktu adalah untuk menunjukkan perubahan keadaan objek dalam menanggapi peristiwa-peristiwa yang terjadi dari waktu ke waktu. Diagram waktu cenderung sangat berguna ketika mengembangkan sistem real-time atau embedded.

State Machines
Dalam UML 2.0, ada dua state machines yang berbeda yaitu sifat dan protokol. Mesin penentu sifat digunakan untuk menjelaskan perubahan yang dialami objek selama masa aktifnya. Mesin penentu protokol menggambarkan urutan peristiwa tertentu yang objek dapat respon.

1. Mesin penentu sifat menyediakan metode untuk memodelkan keadaan yang berbeda, atau set dari nilainya, bahwa variabel dari kelas bisa pergi selama masa aktifnya. Sebagai contoh, seorang pasien bisa berubah statusnya dari waktu ke waktu misalnya seorang yang sebelumnya pasien baru bisa berubah menjadi pasien sekarang. Masing-masing “tipe” pasien benar-benar menunjukkan keadaan yang berbeda dari pasien yang sama. Keadaan yang berbeda dihubungkan dengan peristiwa yang menyebabkan dalam contoh yaitu pasien untuk berubah dari satu keadaan ke keadaan lainnya.

2. Mesin penentu protokol mendukung analis dalam merancang hubungan antara unsur-unsur antarmuka pada kelas. Sebagai contoh, biasanya anda harus membuka file atau database sebelum query atau memperbarui itu. Tidak seperti mesin penentu sifat, mesin penentu protokol bisa dikaitkan dengan port pada komponen atau interface pada kelas.

Use Case Diagram
Use case diagram memungkinkan analis untuk memodelkan interaksi antara sistem informasi dan lingkungannya. Lingkungan sistem informasi akan mencakup baik pengguna akhir dan setiap sistem eksternal yang berinteraksi dengan sistem informasi. Penggunaan utama dari diagram use case adalah untuk menyediakan sarana dalam mendokumentasikan dan memahami persyaratan sistem informasi yang sedang berkembang. Use case dan diagram use case adalah beberapa alat yang paling penting untuk digunakan dalam analisis dan desain sistem berorientasi objek.

Sumber : http://yosuaalvin.students-blog.undip.ac.id/2010/09/29/introduction-to-oosad-with-uml-version-2-part-2/

Read More