1. MODEL WATERFALL KOMUNIKASI Permulaan proyek Teknik untuk mendapatkan spesifikasi kebutuhan pengguna
PERENCANAAN Membuat perkiraanperkiraan , penjadwalan dan pelacakan
PENYERAHAN KE PELANGGAN / PENGGUNA Pengiriman Dukungan terhadap pengguna Umpan balik
PEMODELAN Analisis perancangan
KONSTRUKSI Penulisan kode-kode program Pengujian
REKAYASA PERANGKAT LUNAK 3 sks Sri Rezeki Candra Nursari
reezeki2011.wordpress.com
Referensi Rekayasa Perangkat Lunak – Pendekatan Praktisi, Roger S. Pressman, Ph.D, Andi Jogyakarta, 2012 – Buku 1 Rekayasa Perangkat Lunak – Pendekatan Praktisi, Roger S. Pressman, Ph.D, Andi Jogyakarta, 2012 – Buku 2 Rekayasa Perangkat Lunak – Analisa Kebutuhan Dalam, Daniel Siahaan, Andi Jogyakarta, 2012
Materi • Perancangan, pembuatan, pengujian dan perawatan perangkat lunak serta pemrograman dengan bahasa tingkat tinggi. • Siklus hidup perangkat lunak, Waterfall model, V model, Spiral model, Prototyping, prinsip dasar analisis kebutuhan, alur data, struktur data DSSD, Sistem Jackson, perangkat pembantu. • Computer Aided Software Engineering (CASE) tools. • Perancangan real time system. • Analisis berorientasi objek, Pemodelan data, Metode formal, Pengantar perancangan dan implementasi
MODEL PROSES RPL 1. 2. 3. 4. 5. 6. 7. 8.
Model Air Terjun (Waterfall) Model Proses Inkremental Model Prototipe (Prototyping) Model Proses Evolusioner Model Spiral Model RAD (Rapid Application Development) Model-Model Konkuren Model Metode Formal
2. Model Proses Inkremental • Spesifikasi kebutuhan perangkat lunak saat awal sudah terdefinisi dengan baik, tetapi lingkup keseluruhan usaha pengembangan perangkat lunak tidak dapat dilakukan secara linier. • Usaha pengembangannya dengan melakukan penambahan sedikit demi sedikit (ikremental) • Merupakan model yang menggabungkan elemen aliran-aliran proses linier dan paralel • Contoh : perangkat lunak “word processing”, dimana pengolahan berkas sedikit demi sedikit bertambah fungsinya
2. Model Proses Inkremental F u n g s i o n a l i t a s
Versi Perangkat Lunak #n
Rekayasa Sistem Informasi
Komunikasi
Perencanaan
Konstruksi
(Analisis, Perancangan)
(Penulisan Kode-Kode Program, Pengujian)
Penyerahan Sistem/Perangkat Lunak Ke Para Pelanggan / Pengguna (Pengiriman, Umpan Balik)
Versi Perangkat Lunak #3
Komunikasi
Perencanaan
& F i t u r P L
Pemodelan
Pemodelan
Konstruksi
(Analisis, Perancangan)
(Penulisan Kode-Kode Program, Pengujian)
Penyerahan Sistem/Perangkat Lunak Ke Para Pelanggan / Pengguna (Pengiriman, Umpan Balik)
Versi Perangkat Lunak #2 Perencanaan
Komunikasi
Pemodelan
Konstruksi
(Analisis, Perancangan)
(Penulisan Kode-Kode Program, Pengujian)
Penyerahan Sistem/Perangkat Lunak Ke Para Pelanggan / Pengguna (Pengiriman, Umpan Balik)
Versi Perangkat Lunak #1 Komunikasi
Perencanaan
Waktu kalender
Pemodelan
Konstruksi
(Analisis, Perancangan)
(Penulisan Kode-Kode Program, Pengujian)
Penyerahan Sistem/Perangkat Lunak Ke Para Pelanggan / Pengguna (Pengiriman, Umpan Balik)
3. Model Prototipe • Metode ini sering digunakan pada dunia riil. Karena metode ini secara keseluruhan akan mengacu kepada kepuasan user. • Bisa dikatakan bahwa metode ini merupakan metode waterfall yang dilakukan secara berulang-ulang.
Langkah-langkah Prototyping 1. Pengumpulan Kebutuhan/Komunikasi & Perencanaan – Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat. 2. Membangun Prototyping/Analisis, Perancangan – Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format serta output
Langkah-langkah Prototyping 3. Pengkodean dan Pengujian Sistem / Konstruksi – Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai. – Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan
4. Evaluasi Prototyping / Konstruksi – Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. – Jika sudah sesuai maka langkah ini (langkah 4) akan diambil. – Jika tidak prototyping direvisi dengan mengulang langkah demi langkah (langkah 1, 2 dan 3)
Langkah-langkah Prototyping 5. Mengevaluasi Sistem / Konstruksi – Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5. 6. Menggunakan Sistem / Penyerahan Sistem, Umpan Balik – Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan . 7. Pemeliharaan / Penyerahan Sistem, Umpan Balik
PRARADIGMA PEMBUATAN PROTIPE PERENCANAAN secara cepat
PEMODELAN KOMUNIKASI
Penyerahan Sistem/ perangkat lunak ke para pelanggan/pengguna Pengiriman & Umpan Balik
Perancangan secara cepat
KONSTRUKSI Pembentukan prototipe
Jenis-jenis Prototyping • Feasibility prototyping. – Digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system informasi yang akan disusun.
• Requirement prototyping. – Digunakan untuk mengetahui kebutuhan aktivitas bisnis user. Misalnya dalam sebuah perusahaan terdapat user direktur, manajer, dan karyawan. Maka penggunaan sistem dapat dibedakan berdasarkan user tersebut sesuai dengan kebutuhannya.
Jenis-jenis Prototyping • Desain Prototyping. – Digunakan untuk mendorong perancangan system informasi yang akan digunakan.
• Implementation prototyping. – Merupakan lanjutan dari rancangan protipe, prototype ini langsung disusun sebagai suatu system informasi yang akan digunakan.
Kelebihan Prototyping • Adanya komunikasi baik antara pengembang dengan pelanggan. • Pengembang dapat bekerja lebih baik untuk memenuhi kebutuhan pelanggan. • Pelanggan berperan aktif dalam pengembangan sistem. • Menghemat waktu dalam pengembangannya. • Penerapan lebih mudah karena pemakai akan mengetahui apa yang diharapkan.
Kekurangan Prototyping • Kualitas sistem kurang baik karena hanya mengedepankan aspek kenyamanan user. • Pengembang kadang-kadang menggunakan implementasi yang sembarangan. • Tidak mencerminkan proses perancangan yang baik.
Kondisi agar prototyping berhasil • Prototyping akan bekerja dengan baik bila diterapkan dalam kondisi :
– Resiko tinggi yaitu untuk masalah-masalah yang tidak terstruktur dengan baik, ada perubahan yang besar dari waktu ke waktu, dan adanya persyaratan data yang tidak menentu. – Interaksi pemakai sangat penting. – Sistem harus menyediakan dialog on-line antara pelanggan dan komputer. – Perlunya penyelesaian yang cepat – Perilaku pemakai yang sulit ditebak – Sitem yang inovatif. Sistem tersebut membutuhkan cara penyelesaian masalah dan penggunaan perangkat keras yang mutakhir
4. Model Proses Evolusioner • Metode/Model ini bersifat iteratif dan bersifat penambahan sedikit demi sedikit (Inkremental). • Cirinya memungkinkan kita mengembangkan perangkat lunak yang semakin kompleks pada versi-versi berikutnya • Dirancang untuk mengakomodasi suatu produk yang akan berubah secara perlahan (berevolusi) sepanjang waktu
Pertimbangan menggunakan Model Proses Evolusioner 1. Dalam pembentukan prototipe memiliki masalah dalam hal perencanaan proyek sebab didalamnya ada sejumlah siklus yang tidak pasti dan diperlukan untuk mengkonstruksi produk 2. Tidak menetapkan kecepatan maksimum pada evolusi 3. Harus berfokus pada fleksibilitas dan perluasaan dan pada kualitas yang tinggi
5. Model Spiral • Ditemukan oleh Barry Boehm dalam artikelnya “A Spiral Model of Software Development and Enhancement ” 1988. • Boehm mengusulkan sebuah model yang secara explisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum
5. Model Spiral • Model yang diusulkan Boehm berbentuk spiral dan merupakan kombinasi dari Prototyping Model dengan Waterfall Model. • Setiap tahapan model ini selalu dilakukan Risk Analisys dan verifikasi atau testing.
5. Model Spiral • Setiap loop dalam model ini mewakili sebuah tahap dari proses perangkat lunak. • Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek ke dalam tahap-tahap. • Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masalah-masalah ditemukan selama pembuatan proyek.
Setiap loop dibagi dalam 4 sektor sebagai berikut : 1. Determine objectives – Menentukan permasalahan, menentukan alternatif dan obyek yang mendesak. – Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek harus ditentukan. – Rencana rinci manajemen harus ditulis lengkap. – Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.
Setiap loop dibagi dalam 4 sektor sebagai berikut : 2. Risk Analysis – Analisis resiko, evaluasi, dan mencari solusi. – Jika resiko tidak dapat ditemukan solusinya, maka proses berhenti. – Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkahlangkah untuk mengurangi resiko tersebut. – Contohnya, jika ada resiko bahwa persyaratanpersyaratan tidak tepat, maka sebuah model contoh mungkin dapat dikembangkan.
Setiap loop dibagi dalam 4 sektor sebagai berikut :
3. Engineering / develop
Melakukan proses rekayasa perangkat lunak. Setelah evaluasi resiko, sebuah model pengembangan untuk sistem harus dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evalusioner 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
Setiap loop dibagi dalam 4 sektor sebagai berikut : 4. Plan next phase – Penentuan rencana-rencana untuk tahap selanjutnya. – Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya
5. Model Spiral • Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasi-kan dengan yang lain. • Pemodelan waterfall, yang sangat bagus dalam menentukan sejumlah titik dalam waktu pengembangan perangkat lunak (milestones) dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.
PERENCANAAN Pembuatan prakiraan-prakiraan penjadwalan analisis terhadap resiokoresiko perangkat lunak
KOMUNIKASI
Penyerahan sistem/perangkat luar ke para pelanggan/pengguna Pengiriman, umpan balik
PEMODELAN Analisis perancangan
KONSTRUKSI Penulisan kode-kode program pengujian
Risk Analysis • Risk Analysis yang dilakukan pada metode spiral adalah : – Project risk, mempengaruhi rencana proyek, contoh kekurangan sumber daya – Technical risk, mempengaruhi tahap aktual, contoh : personil tidak terlatih di tahap tersebut – Bussines risk, mempengaruhi keinginan perusahaan untuk membuat software, contoh : software tidak diperlukan
Prioritas resiko • Catastropik (luar biasa), contoh : penurunan kualitas yang luar biasa, biaya yang tidak terkontrol • Critical (kritis), contoh : tidak tepat waktu, biaya di luar perkiraan • Marginal (ringan), contoh : penjadwalan yang terlambat • Negligible (tidak berarti), contoh : penggunaan waktu proyek tidak optimal
Kelebihan Metode Spiral Penekanan pada alternatif dan kendala mendukung penggunaan kembali solusi yang ada. Target pengujian dengan memperlakukannya sebagai risiko, yang harus ditangani. Perkiraan (anggaran dan jadwal) lebih realistis sejalan pekerjaan berlangsung, karena isu-isu penting yang ditemukan sebelumnya. Hal ini lebih mampu mengatasi dengan (hampir tak terelakkan) perubahan pengembangan perangkat lunak yang umum dan berarti. Pengembang, dapat mulai bekerja pada proyek
Kekurangan Metode Spiral • Hanya ditujukan untuk proyek internal (di dalam perusahaan), karena risiko dinilai saat proyek dikembangkan. • Hampir tidak cocok untuk pengembangan perangkat lunak yang bersifat kontrak. • Dalam hal pengembangan perangkat lunak kontrak, semua analisis risiko harus dilakukan dengan baik oleh klien dan pengembang sebelum kontrak ditandatangani dan tidak seperti dalam model spiral. • Model spiral lebih berfokus pada resiko. Oleh karena itu membutuhkan staf yang berpengetahuan. • Hanya cocok untuk pengembangan perangkat lunak skala besar.
6. Model RAD (Rapid Application Development • Rapid Aplication Development (RAD) adalah sebuah proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan dalam waktu yang singkat (60 sampai 90 hari) dengan pendekatan konstruksi berbasis komponen.
Langkah-langkah RAD 1. 2. 3. 4. 5.
Business Modelling Data Modelling Process Modelling Application Generation Testing and Turnover
Langkah-langkah RAD 1. Business Modelling – Fase ini untuk mencari aliran informasi yang dapat menjawab pertanyaan berikut: • Informasi apa saja yang dapat mengendalikan proses bisnis? • Informasi apa yang diinginkan/muncul? • Di mana informasi tersebut digunakan ? • Siapa yang akan memprosesnya ?
Langkah-langkah RAD 2. Data Modelling – Fase ini menjelaskanobjek data yang dibutuhkan dalam proyek. – Karakteristik (atribut) masing-masing data diidentifikasikan dan hubungan antar objek didefinisikan.
Langkah-langkah RAD 3. Process Modelling – Aliran informasi pada fase data modelling ditransformasikan untuk mendapatkan aliran informasi yang diperlukan pada implementasi fungsi bisnis. – Pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau untuk mendapatkan kembali objek data tertentu.
Langkah-langkah RAD 4. Application Generation – Selain menggunakan bahasa pemrograman generasi ketiga, RAD juga memakai komponen program yang telah ada atau menciptakan komponen yang bisa digunakan kembali. – Ala-alat bantu bisa dipakai untuk memfasilitasi konstruksi perangkat lunak.
Langkah-langkah RAD 5. Testing and Turnover – Karena menggunakan kembali komponen yang telah ada, maka akan mengurangi waktu pengujian. – Tetapi komponen baru harus diuji dan semua interface harus diuji coba secara penuh.
Kelebihan RAD • Setiap fungsi inti dapat dimodulkan dalam waktu tertentu kurang dari 3 bulan dan dapat dibicarakan oleh tim RAD yang terpisah dan kemudian diintegrasikan sehinnga waktunya lebih efesien. • RAD mengikuti tahapan pengembangan sistem sepeti umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali komponen yang ada (reusable object) sehingga pengembang tidak perlu membuat dari awal lagi dan waktunya lebih singkat .
Kekurangan RAD • Proyek yang besar dan berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan tim yang baik. • RAD menuntut pengembang dan pelanggan nya untuk memiliki komitmen dalam aktivitas yang diperlukan untuk melengkapi sebuah sistem dalam waktu yang singkat. • Jika komitmen tersebut tidak ada maka proyek RAD akan gagal.
7. Model Konkuren • Menggunakan unsur-unsur yang bersifat berulang (iteratif) dan konkuren (berjalan bersamaan) dalam setiap model proses • Aktifitas pemodelan konkuren memungkinkan ada dalam salah satu keadaan pada suatu waktu tertentu
7. Model Konkuren • Komunikasi atau Konstruksi berada pada keadaan yang sama • Mendefinisikan sejumlah event berurutan yang akan memicu transisi dari suatu keadaan (state) ke keadaan yang lainnya pada masing-masing aktifitas, tindakan atau pekerjaan rekayasa perangkat lunak (RPL)
7. Model Konkuren • Dapat diterapkan pada smua hal yang berkaitan dengan pengambangan perangkat lunak (PL) dan menyediakan gambaran yang akurat tentang keadaan proyel saat ini • Digambarkan dalam bentuk jaringan proses. Artinya masing-masing aktifitas, tindakan atau pekerjaan dalam jejaring hadir secara bersamaan dengan aktifitas-aktifitas, tindakan-tindakan atau pekerjaan-pekerjaan yang lainnya
8. Model Metode Formal • Menggunakan sejumlah aktifitas yang sesuai dengan spesifikasi formal matematis dari suatu perangkat lunak komputer • Dimungkinkan untuk melakukan spesifikasi, pengembangan dan verifikasi suatu sistem berbasis komputer dengan menerapka notasi-noasi matematika • Untuk pengembangan perangkat lunak yang sangat kritis dalam kaitannya dengan keamanan (misalnya pengembangan PL untuk pengendalian pesawat udaraatau yang bekerja pada sarana-sarana kesehatan)
8. Model Metode Formal • Menawarkan perangkat lunak (PL) yang bebas cacat (defect-free-software) • Alasan mengapa metode ini jarang digunakan karena : 1. Pengembangan metode formal memerlukan waktu yang sangat banyak dan sangat mahal 2. Karena hanya sedikit pengembangan PL yang memiliki latar belakang yang cukup untuk menerapkan metode-metode formal, maka dibutuhkan pelatihan-pelatihan yang ekstensif 3. Meruapakan hal yang sulit untuk menggunakan model formal ini sebagai mekanisme komunikasi para pelanggan yang secara teknis tidak canggih
Tugas 2 • Batas terakhir kirimkan ke email ..... 2012 jam 24.00 wib ke
[email protected] • Buat dengan metode RAD berdasarkan topik Anda masing-masing
