Proyek Rekayasa Perangkat Lunak

Proyek Rekayasa Perangkat Lunak

Software Development Plan (SDP)

Gamabran mengenai informasi yang terdapat dalam dokumen ini meliputi :

1.Introduction

Menjelaskan tentang fungsi dan tujuan dari pembuatan dokumen Software Development Plan secara detail sesuai dengan kbutuhan yang telah menjadi bagian dari permasalahan dari pengguna.

2.Project Purpose

Menjelaskan secara detail tentang kebutuhan produk yang akan dibangun sehingga kebutuhan dari permasalahan pengguna dapat terpecahkan. Menjelaskan fitur-fitur yang akan di sediakan dan kelebiha serta manfaat yang akan dimiliki oleh produk yang akan dibangaun yang nantinya akan dinikmati oleh pengguna.

3.Project Organisation

Menjelaskan tebtang struktur organisasim aturan seta tanggung jawab yang diberikan kepada staf perusahaan tersebut yang nanantinya akan menjelaskan secara detail tentang perusahaan yang menjadi tempat project yang sedang dikembangan.

4.Manajement Proses

Menjelaskan tentang bagaimana perencanaan sebuah pembuatan produk yang sedang dibanagun sehingga tercipta gambaran secara detail tentang bagaimana perencanaan dari segi waktu,biaya, serta biaya yang menjadikan pengembanga terhindar dari kesalahaan fatal yang dapat terjadi disaat proses pelaksanaan project.

5.Technical Process Plan

Menjelaskan proses tekinik yang digunakan untuk melaksanakan project ini.

6.Supporting Procss Plan

Menjelaskan pemberian suppor yang dilakkan guna pelaksanaan dari pengerjaan project menjadi semakin terkendalli dan memiliki kwalitas yang baik.

TAHAP ANALISA KEBUTUHAN (Requirements Analysis)

Tahap ini merupakan awal mula siklus pembuatan produk Perangkat Lunak (PL) sistem. Pada tahap ini dilakukan inisiasi proyek pengembangan PL yang mempertemukan visi antara calon pengguna dengan pengembang. Pada tahap ini juga, pengembang harus memiliki inisiatif untuk membuka wawasan calon pengguna agar tidak mengalami kesenjangan pengetahuan dengan tim pengembang. Ada beberapa hal yang dijadikan sebagai topik pembicaraan antara calon pengguna dengan pengembang, antara lain :

· Tujuan sistem

· Lingkup/batasan sistem

· Gambaran umum kebutuhan PL.

Dari topik-topik tersebut, pengguna menjadi tahu bahkan sangat tahu apa yang diinginkannya baik dari sisi penggunaan maupun dari sisi teknologi yang ada yang dapat disesuaikan dengan kemampuannya dalam menginvestasikan sumber daya.

Penyusunan dokumen pada tahap ini dapat mengikuti standar yang telah di tetapkan oleh IEEE dengan nomor dokumen 830 tahun 1984 atau dapat disusun dengan format yang kurang lebih mirip dengan itu.

Berikut ini merupakan link panduan penyusunan dokumen SRS sesuai standar IEEE sekaligus contoh SRS yang telah dibuat oleh salah satu tim pengembang PL.

http://blog.binadarma.ac.id/syafari/?p=73

Tahap Sofware Arsitekture Desain (SAD)

Konsep desain

1. Abstraction adalah gambaran dari fungsi suatu program. Gambaran ini bias bertingkat-tingkat. Tingkat yang paling atas adalah gambaran suatu fungsi program dengan menggunakan bahasa alami. Pada tingkat terendah, menghasilkan abstraksi yang bersifat prosedural/ langkah perlangkah dengan menggunakan istilah yang teknis dan bisa diimplementasikan menjadi fungsi program.

Pada saat beralih dari tingkat ke tingkat, kita menggunakan procedural dan data abstraction. Procedural abstraction adalah urutan instrasi yang mempunyai tujuan khusus,dan data abstraction adalah koleksi data yang digunakan pada fungsi tersebut.

2. refinement—penjelasan detil dari abstraction

Refinement membantu designer untuk memperlihatkan detil dari lowest level dari abstraction. Abstraction dan refinement merupakan konsep yang saling melengkapi.

3. Smodularity—membagi software menjadi modul

Software dibagi-bagi menjadi beberapa component yang disebut modul-modul. Modul-modul ini nantinya disatukan/diintegrasikan untuk memenuhi kebutuhan sistem.

lecturer.ukdw.ac.id/othie/softdesign.pdf

Tahapan Testing/ Testing Life Cycle

1. Start –> review test case

2. Perform testing : pengetesan test case yang biasanya di awali dengan smoke test (pengetesan tanpa prosedur dalam test case, hanya berdasarkan pengetahuan software tester secara umum saja), lalu kemudian di lanjutkan dengan execution test (yang menggunakan test case). Tujuan dari smoke test ini adalah untuk meminimalisasikan jumlah error apalagi error yang bersifat trivial (salah penulisan, warna atau posisi button/tulisan/form, dan bug-bug kecil lainnya) sebelum execution test.

3. Review and Verify test result, yaitu pelaporan hasil testing kepada team developer.

4. Do Bug fixing, dimana bug-bug atau error yang ditemukan dalam sistem akan di perbaiki oleh developer.

5. Re-test and Regression testing, yaitu testing yang dilakukan setelah bug fixing.

6. Produce validation report and release note, yaitu pelaporan kepada developer ketika sistem sudah dinyatakan bersih dari bug.

7. UAT (user acceptance test) yaitu test case yang dibuat untuk kemudian di test oleh end user sistem tersebut.

Programmer:

Langkah 1. Rencana Penggabungan (Plan The Integration)

Menurut akal sehat anda tidak akan dapat membuat semua program sekaligus dan kemudian membuang semuanya – ini memerlukan rangkaian langkah demi langkah. Rencanakan urutan dimana anda akan menggabungkannya. Bab 9 ini merinci beberapa metode untuk menggabungkan bagian-bagian tersebut, tetapi anda harus merencanakan urutan penggabungan ini sekarang, karena anda harus menulis program supaya dapat digabungkan. Ini disebut Rencana Tes Sistem (System Test Plan).

Langkah 2. Mendisain Modul (Design The Module)

Programmer menerima beberapa tingkatan disain dari fase disain. Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih rendah sampi mencapai keadaan programmer siap untuk melakukan pemrograman. Ini disebut disain modul.

Langkah 3. Telusuri Disain Modul(Walk Through The Module Design)

Seperti pada tingkat atas dan menengah dari disain, pertukaran harus dibuat sebaiknya pada tingkat yang paling rendah. Telusuri disain dari masing-masing modul sebelum melakukan pengkodean. Penelusuran ini sangat kecil : hanya programmer yang tepat, supervisor dan mungkin programmer lainnya yang perlu diperhatikan. Kegunaan dari penelusuran disain modul adalah untuk memastikan bahwa disain yang terbaik yang telah dilakukan, semua fungsi telah dialamatkan dan semua bagian telah ditangani.

Langkah 4. Rencana Bagaimana Menguji Modul (Plan How To Test The Module)

Programmer harus menyiapkan rencana pengujian modul dan data pengujian sebelum dikodekan. Rencana pengujian dilakukan setelah kode ditetapkan. Mereka cenderung hanya menguji bagian kode yang paling ‘sulit’. Pimpinan proyek bisa saja melakukan tuntutan pada penelusuran rencana pengujian sepanjang disain modul sedang dilaksanakan. Kerjakan penelusuran ini bersama-sama.

Langkah 5. Kode Setiap Modul (Code Each Module)

Standar pengkodean akan ditetapkan pada saat disain sistem (lihat bagian 7.12). Kita tidak membahas bagaimana membuat program – lihat Referensi 12 (tulisan ini membahas disain sama baiknya dengan pemrograman) dan Referensi 13 untuk lebih jelasnya.

Berikut ini adalah ringkasan dari sebuah program terstruktur, yaitu :

· Jika berukuran kecil. Aturan dasarnya adalah kira-kira 100 baris kode yang dapat dieksekusi dan listingnya tidak lebih dari 2 halaman.

· Satu entry, satu exit.

· Referensi secara keseluruhan sedikit.

· Konstruksi terstruktur yang digunakan : berurutan, IF/THEN/ELSE, CASE, WHILE, UNTIL, CALL (bukan GO TO).

Langkah 6. Menguji Modul (Test The Module)

Programmer menguji modul dengan menetapkan lingkungan yang tepat, menyediakan beberapa input, membiarkan modul langsung memproses secara logik dan mendapatkan hasilnya. Beberapa input mungkin tidak sebenarnya, terutama jika modul tersebut tidak menyediakan input yang sebenarnya.

Modul seharusnya diuji dalam dua tahap, yaitu :

· Tahap Pertama disebut pengujian “White Box”. Programmer harus mengetahui isi di dalam modul dan menyediakan data pengujian, sehingga masing-masing path logical dalam program dapat dieksekusi.

· Tahap Kedua atau pengujian “Black Box” dapat dilakukan. Dalam pengujian ini, programmer mengabaikan bagian dalam dari modul – data disediakan secara berurut dan dianggap seperti pemakaian sebenarnya.

Langkah 7. Menguji Level Terendah dari Integrasi (Test The Lowest Levels Of Integration)

Jika modul utama memanggil sub-modul, programmer harus menggabungkan dan menguji semua modul secara bersama-sama. Bahkan jika programmer tidak bertanggung jawab untuk menulis sub-modul, programmer harus menguji perintah CALL dan RETURN dari seluruh modul.

Metode terbaik untuk melakukan hal ini adalah membuat sebuah “program stub” (potongan program) sebagai pengganti sub-modul. Potongan program ini dapat terdiri dari empat baris program yang menunjukkan bahwa kontrol sudah diterima dengan baik, tampilkan parameter penerima, jika perlu lakukan pengontrolan kembali dengan beberapa parameter yang tidak sebenarnya.

Langkah 8. Menyimpan Semua Hasil Pengujian; Penggabungan Modul-modul Yang Telah Diuji (Save The Results Of All Tests; Submit Finished Modules To Integration)

Hasil pengujian digunakan untuk menyusun statistik yang menunjukkan penyebab, cara perbaikan serta biaya-biaya yang dibutuhkan untuk memperbaiki kesalahan-kesalahan program. Pimpinan proyek biasanya menguasai/mengepalai penggabungan ini pada sistem berukuran kecil sampai sedang.

Software seperti CMS (Code Management System) sangat berguna untuk menajemen konfigurasi – menjamin program tetap berjalan sesuai versinya dan mengubah ke source code (lihat bagian 9.4).

Langkah 9. Memulai Dokumentasi User (Get Started On The User Documentation)

Apakah programmer bertanggung jawab pada dokumentasi user atau tidak, tahapan ini adalah waktu terbaik untuk menjawabnya.

Software Development Plan (SDP)

Software Development Plan (SDP) ini adalah sebuah dokumen yang menmabntu mennerangkan tentang bagaimana proses-proses perencanaan projek yang terjadi berdasarkan projeck yang tengah diajukan dengan judul Rancang Bangun Aplikasi Penentuan Bencana Banjir Menggunakan Metode AHP dengan studi kasus pada Balai Besar Sungai Brantas. Yang menjadi pembahasan pada dokumen ini menjelaskan tentang gambaran project yang akan di bangun. Penjelasan mengenai detail projek yang akan dibuat. Organisasi perusahaan menjelaskan struktur organisasi, peran serta tugas dari masing-masing dari individu yang mempunyai relasi dengan system yang akan dibangun. Manajemen proses yang akan menjelaskan tentang perkiraan estimasi waktu yang akan digunakan untuk pelaksanaan projek, jadwal tahapan proses pelaksanaan projek dan juga perkiraan waktu projek yang akan di rilis. Technical proses menerangkan tentang penggunaan metode yang digunakan, spesifikasi perlengkapan serta menyusun perencanaan teknis projek yang akan dibangun. Serta suppoting plan.

SRS :

SRS (System Requirement Specification) adalah dokumen yang menyediakan panduan mengenai spesifikasi requirement sistem yang diinginkan oleh client/user secara lengkap terhadap suatu bagian/keseluruhan aplikasi. Di dalam SRS ini terdapat bahasan mengenai use case description, level, included form, extend, primary actor, precondition, scope, dan sebagainya.

• sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh perangkat lunak

• mencantumkan deskripsi perangkat lunak dengan lingkungannya (Mencakup antarmuka untuk perangkat keras, perangkat lunak, komunikasi dan pemakai).

• SRS umumnya dikembangkan bersama oleh calon pengguna dan para pengembang system/perangkat lunak

Fungsi dokumen SRS:

mencatat semua kebutuhan calon pengguna perangkat lunak.
sebagai kontrol saat proses pengembangan perangkat lunak dilakukan, sehingga setiap tahapan pengerjaan pengembangan sesuai dengan yang diharapkan.
Digunakan sebagai acuan pada saat pengujian dilakukan sehingga hasil akhir sesuai dengan yang dibutuhkan.
Dijadikan pedoman jika terdapat perbedaan pendapat antara calon pemakai dengan pengembang sistem terhadap hasil dari pengembangan perangkat lunak
Bukti bahwa pengembang telah melakukan tahap software reguirements analysis.

Kriteria dokument SRS yang baik:

Benar (correct)
Tepat (precise)
Unambiguouity
Lengkap (complete)
Bisa diverifikasi (verifiable)
Konsisten
Understandable
Bisa dimodifikasi (modifiedable)
Dapat ditelusuri (traceable)
Harus dapat dibedakan bagian what (bagian spesifikasi) dan how (bagian yang menjelaskan bagaimana menjelaskan what tadi)
Dapat mencakup dan melingkupi seluruh sistem
Dapat melingkupi semua lingkungan operasional, misalnya interaksi fisik dan operasional.
Bisa menggambarkan sistem seperti yang dilihat oleh pemakai.
Harus toleran (bisa menerima) terhadap ketidaklengkapan, ketidakpastian (ambiguous) dan ketidak konsistenan.
Harus bisa dilokalisasi dengan sebuah coupling, yaitu hubungan ketergantungan antara dua model yang tidak terlalu erat.

SAD (Software Architecture Document)

SAD (Software Architecture Document) adalah dokumen yang menggambarkan desain arsitektur (flow process) secara umum dari modul yang ada dalam sebuah sistem. SAD memuat spesifikasi yang lebih rinci dari dokumen SRS. Di dalam SAD ini terdapat bahasan mengenai overview software, references, architectural representation (screen map, CS Management, Flow chart, database model, sequence diagram, dan class diagram), architectural goals dan constraints, use-case view, logical view, process view, deployment view serta size and performance.

Tes plan

Tugas utama dari seorang software tester adalah melakukan pengecekan atau testing terhadap bug di dalam sebuah aplikasi atau program. Jadi, keberhasilan software tester adalah kegagalan bagi developer, sebaliknya demikian. Namun, pada dasarnya keberhasilan software tester ataupun keberhasilan developer memiliki tujuan yang sama, yaitu untuk membuat sebuah aplikasi atau software bebas dari bug (meskipun sebenarnya tidak ada aplikasi yang bisa benar-benar bebas dari bug).

Banyak orang yang berpikir bahwa tugas software tester adalah tugas yang sangat mudah, namun pada kenyataannya tugas software tester adalah tugas yang sulit dan memiliki tanggungjawab yang besar terhadap keberhasilan sebuah produk IT. Selain harus memiliki kesabaran dan ketelitian, seorang softawre tester juga dituntut untuk proaktif dan memiliki kreatifitas imajinasi yang tinggi. Tidak percaya? Silahkan simak ulasan berikut mengenai A-Z nya software tester.

Software Tester dan Dokumen Makanan sehari-hari seorang software tester adalah dokumen. Berkutat dengan dokumen-dokumen adalah hal yang biasa dan lumrah, karena tanpa dokumen, software tester tidak dapat membuat test scenario yang baik. Dokumen apa saja yang dibutuhkan oleh software tester :

1 SRS (System Requirement Specification)

2 SAD (Software Architecture Document)

Dari semua dokumen inilah si software tester kemudian akan mengetahui seperti apa sistem yang akan di testing. Setelah mengetahui proses bisnis dari sistemnya, maka software tester harus membuat test case yang terdiri dari langkah-langkah pengetesan terhadap sistem yang dibagi-bagi kedalam tiap modul/unit sistem. Disinilah kreatifitas dan imajinasi seorang software tester diperlukan, yaitu ketika mereka harus membuat skenario test dari sistem yang belum pernah mereka sentuh sebelumnya. Atau lebih tepatnya jika dapat digambarkan, software tester harus dapat mentransfer seluruh ‘isi kepala’ business analyst atau system analyst mengenai sistem tersebut ke dalam pikiran/otak mereka

Dokumentasi proyek

Dokumentasi adalah suatu hal yang pertama-tama harus ditentukan dan diselesaikan. Hal yang penting agar dokumentasi dapat disusun dengan sukses adalah dilakukan dengan cara mengintegrasikan dokumentasi ini dengan metodologi, sehingga proses dokumentasi dilakukan ketika setiap langkah development dilakukan, daripada melakukannya setelah selesai. Bentuk dasar dari dokumentasi ini sebaiknya juga dilakukan untuk proyek-proyek yang lainnya. Pada suatu proyek biasanya terdapat enam proses yang saling terkait dan dinamis. Proses ini adalah

1. Pendefinisian

2. Perencanaan

3. Organisasi

4. Pengawasan

5. Penyelesaian

6. Leading

Setiap proses akan memiliki keluaran yang akan menjadi masukan bagi proses yang lainnya. Proses-proses ini memberikan beberapa keuntungan termasuk :

• Mengetahui dampak teknologi dan bisnis

• Menghitung estimasi biaya sesungguhnya

• Menentukan tingkat usaha

• Mencapai suatu penyelesaian yang paling efektif biayanya.

• Memilih perangkat bantu dan teknik terbaik

Proyek Rekayasa Perangkat Lunak

Rabu, 05 Oktober 2011

Dokumen PRPL

Kamis, 29 September 2011

SDP

Rabu, 21 September 2011

Proposal

Rabu, 14 September 2011

Proyek Rekayasa Perangkat Lunak (PRPL)

Mengenai Saya

Arsip Blog