Mata Kuliah Testing & Implementasi Sistem Program Studi Sistem Informasi 2014/2015 STMIK Dumai -- Pertemuan 2 --
This presentation is revised by @hazlindaaziz, STMIK, 2014
Acknowledgement Main materials: [Pressman, 2010] Pressman, Roger S. Software Engineering: A Practitioner’s Approach. New York:McGraw-Hill Higher Education, 2010. Print Supplements: [Yud, 2012] Yudhoatmojo, Satrio Baskoro. “Software & Software Engineering” IKI30202 - Rekayasa Perangkat Lunak Term 1 2011/2012. Faculty of Computer Science University of Indonesia. 2012. Print [Sommerville, 2007] Sommerville, Ian, Software Engineering, 8 th Edition, Pearson‐Addison Wesley, England, 2007. [Dennis, 2010] Dennis, Alan, et al, System Analysis and Design, 4th Edition, John Wiley & Sons, New Jersey, 2010. 2
Mengapa Perlu PROSES MODEL? Banyak sistem gagal yang akhirnya ditinggalkan karena para analis mencoba membangun sebuah sistem yang hebat tanpa mengerti bagaimana sistem yang seharusnya sesuai dengan tujuan perusahaan Tujuan utama dari sistem informasi adalah untuk membuat sistem yang bernilai untuk perusahaan (dalam artian memberi keuntungan bagi perusahaan)
3
4
Prolog Membangun perangkat lunak komputer merupakan suatu proses pembelajaran yang mengandung unsur sosial (iterative social learning process) dan menghasilkan sebuah kumpulan pengetahuan (knowledge) yang terorganisir sebagai proses. Today, we focus on SOFTWARE PROCESS.
5
Apa itu PROSES? Proses merupakan kumpulan dari: aktivitas-aktivitas aksi-aksi, dan tugas-tugas yang dilakukan pada saat suatu produk akan dibuat.
6
Setelah mengerti arti PROSES… Apakah yang dimaksud dengan SOFTWARE PROCESS (Proses Perangkat Lunak)???
7
Software Process Software process adalah kerangka untuk aktivitas, aksi, dan
tugas yang dibutuhkan untuk membangun perangkat lunak yang high-quality [Pressman, 2010]. Suatu struktur dari kumpulan aktivitas yang dibutuhkan untuk
membangun sebuah sistem perangkat lunak [Sommerville, 2007]: Specification
Design & Implementation Validation Evolution
8
Karakteristik Software Process Menurut [Sommerville, 2007]: Menentukan aktivitas-aktivitas secara mayor Memanfaatkan sumber (resources), untuk mengoptimalkan jadwal, dalam mencapai hasil perangkat lunak Membatasi dan mengatur aktivitas, sumber, dan produk membatasi aktivitas: waktu, biaya, peralatan (tools) mengatur aktivitas: manajemen konfigurasi, laporan
9
Software Process - Aktivitas Suatu aktivitas yang diusahakan untuk mendapatkan tujuan besar (contoh: berkomunikasi dengan stakeholders) dan menentukan: tipe aplikasi/perangkat lunak yang akan dibuat ukuran proyek tingkat kompleksitas usaha yang dikeluarkan, atau tipe pengambangan perangkat lunak apa yang akan digunakan
10
Software Process - Aksi Suatu aksi (contoh: membuat disain arsitektur) yang meliputi kumpulan tugas-tugas untuk menghasilkan sebuah produk kerja secara mayor (contoh: model disain arsitektur)
11
Software Process - Tugas Suatu tugas yang berfokus ke tugas berskala kecil, namun tujuannya dapat dipahami (contoh: merancang unit test) dan menghasilkan produk yang nyata.
12
Software Process Di dalam software engineering, suatu proses bukan hanya merupakan persepsi baku tentang bagaimana membangun perangkat lunak komputer. Ia adalah bentuk pendekatan yang dapat disesuaikan untuk menentukan aksi-aksi dan tugas-tugas yang tepat.
Tujuan akhirnya adalah untuk menghasilkan perangkat lunak dengan tepat waktu dan dengan kualitas yang memuaskan pihak yang akan menggunakan perangkat lunak tersebut. 13
A Generic Process Model
14
Masih Ingat 5 Kerangka Aktifitas??? Disebut juga 5 Generic Framework Aktivities Apa-apa saja??? - Communication - Planning - Modeling - Construction - Deployment
15
Process Flow Mendeskripsikan bagaimana aktivitas , aksi-aksi, dan tugas-tugas yang muncul di tiap kerangka aktivitas terorganisir secara waktu dan urutannya (sequence) Ada 4 jenis Process Flow, menurut [Pressman, 2010], diilustrasikan pada slide berikutnya….
16
1 - Linear Process Flow
17
2 - Iterative Process Flow
18
3 - Evolutionary Process Flow
19
4 - Parallel Process Flow
20
Process Model secara Umum [Sommerville, 2007] Sebuah “Software Process Model” adalah representasi abstrak dari sebuah proses, yang menyajikan deskripsi proses dari beberapa perspektif. Proses itu harus: Visible: Aktivitas harus menyajikan indikasi progres dengan jelas (deadlines/milestones) Understandable: Aktivitas dan eksekusinya harus dapat dimengerti dengan
baik
Supportable: Adanya dukungan otomatis untuk tiap aktivitas
Usable: Proses dapat diterima dan digunakan oleh customer
21
Proses Model Preskriptif What ? Mendefinisikan aturan yang jelas tentang aktivitas, aksi-aksi, tugas, milestone, dan hasil kerja (work product) yang diperlukan untuk mengembangkan software berkualitas tinggi Who does it? Software Engineer dan managernya Client yang memesan software
Why is it important? Menjamin stabilitas, kontrol dan organisasi terhadap kegiatan pengembangan software 22
Proses Model Preskriptif …(2) What are the steps? Proses ini menuntun tim developer dalam melaksanakan framework activities yang diorganisasi menjadi process flow yang mungkin linier, incremental atau evolutionary What is work product? Program Dokumen Data
23
Contoh Proses Model Preskriptif 1. Waterfall Model
2. Incremental Process Models 3. Evolutionary Process Models – Prototyping – The Spiral Model – The Concurrent Model
4. Specialized Process Models – Component-Based Development – The Formal Methods Model – Aspect-Oriented Software Development 5. The Unified Process 24
The Waterfall Model Alias: Classic life cycle Menyarankan pendekatan yang sistematis dan sequential dalam pengembangan software Merupakan paradigma tertua dalam software engineering Efektif dalam situasi: Permasalahan sudah terdefinisi dengan baik Alur kerja (work flow) mulai dari komunikasi hingga
deployment mempunyai kecendrungan linier 25
The Waterfall Model
26
Kekurangan Waterfall Model The problems [Sommerville, 2007]: Tidak fleksibel, sulit untuk dilakukan perubahan requirement oleh kustomer. Requirements harus sudah terdefinisi secara detil di awal proyek. Pada kenyataannya, sedikit sekali fungsi bisnis yang stabil di awal proses requirement. Kebanyakan digunakan di proyek perangkat lunak yang sudah ada sebelumnya , jadi hanya untuk pengembangan saja. 27
The Waterfall Model [Dennis, 2010]
Dengan metode pengembangan model Waterfall, para analis dan pengguna terus melalui satu fase ke fase lainnya secara berurutan. 28
The Incremental Model
Incremental: dibangun per-bagian/potongan/modul secara fungsional Kebutuhan (requirement) perangkat lunak di tiap modul terdefinisi dengan baik [Sommerville, 2007]
29
The Incremental Model
30
The Incremental Model Baik digunakan pada saat: kita ingin menyajikan sejumlah fungsionalitas perangkat lunak untuk user dengan cepat untuk kemudian dikembangkangkan hingga pada saat perangkat lunak tersebut diluncurkan (release). Merupakan kombinasi dari alur proses (process flow) yang linear dan paralel. Tiap alur linear menghasilkan “tambahan fungsi” dari perangkat lunak. Disebut juga sebagai “increments” of the software. 31
The Incremental Model Karakteristik lain… Tidak membangun sistem langsung menjadi satu sistem besar yang utuh, namun memcahnya menjadi beberapa “increment” sistem, dimana tiap increment-nya menyajikan bagian kebutuhan fungsionalitas yang diminta. Kebutuhan fungsional yang dibangun terlebih dahulu adalah kebutuhan
yang tingkat prioritasnya paling tinggi.
Increment sistem yang pertama biasa disebut sebagai core product. Tiap pengembangan dari satu increment dimulai, semua kebutuhan
fungsional yang sudah ada dibekukan.
Jika ada kebutuhan fungsional baru, maka itu akan menjadi kebutuhan
fungsional untuk increment selanjutnya.
32
Keuntungan Incremental Model The advantages [Sommerville, 2007] Apa yang diinginkan kustomer di tiap increment dapat tercapai sehingga fungsionalitas sistem dapat tersedia lebih cepat. Increment sistem yang sudah jadi dapat berperan sebagai
prototipe untuk mengklarifikasi kebutuhan pada increment berikutnya.
Rendahnya resiko kegagalan proyek secara keseluruhan. Fungsi sistem yang memiliki prioritas tinggi dapat dites lebih
awal, dan dapat lebih sering dites.
33
Evolutionary Process Models Bersifat iteratif (adanya pengulangan aktivitas) Proses model evolutionary ini memungkinkan para pengembang untuk meningkatkan kompleksitas perangkat lunak ke versi yang lebih tinggi.
Masih ingat 3 contoh proses model evolutionary??? Prototyping The Spiral Model Concurrent 34
Contoh Kasus… (Prototyping) Customer seringkali hanya mendeskripsikan kebutuhan tentang software yang akan dibangun secara umum, tidak detail menjelaskan input, proses atau output yang diinginkan Di lain pihak, developer masih ragu akan efisiensi algoritma, adaptabilitas OS, atau format sistem interaksi yang akan digunakan
Dalam hal ini, pendekatan prototyping merupakan pilihan yang tepat
35
Prototyping
36
Prototyping Membantu analis dan stakeholders lain untuk mengerti lebih baik sistem seperti apa yang akan dibangun pada saat kebutuhannya masih belum jelas. Kustomer akan dapat gambaran tentang sistem yang akan dibangun (get a feel for the actual system) dan para developer dapat segera memulai membangun sistemnya.
37
Prototyping Prosesnya: quick design, build prototype, evaluate, refine prototype, … engineer product Bentuk prototipe yang dibangun tergantung dari analisis yang dilakukan, yang ditulis di “forms of analysis” Paper spec from functional analysis or requirements gathering through FAST (Facilitated Application Specification Techniques) Koding prototipe (tidak full functional!!) Persiapan user manual Story boards 38
Prototyping Problems... Prototyping can be problematic: Stakeholders hanya melihat apa yang dilakukan oleh prototipe sistem, tidak melihat kemungkinan maslaah yang terjadi pada saat sistem dibuat secara utuh fungsinya. Para developer membuat implementasi sistem secara “kompromi” untuk membuat dengan cepat prototipe sistem agar bekerja.
39
Prototyping Problems… [Sommerville, 2007] Proses fungsi sistem secara keseluruhan tidak terlihat Sistem biasanya kurang terstruktur. Diperlukan skill yang baik (dalam hal koding untuk membuat prototipe dengan cepat). Kustomer sudah melihat prototipe, kemudian ingin sistem secara keseluruhan bisa cepat diselesaikan. Implementasi sering kali dibuat benar-benar hanya untuk prototipe, namun tidak dipertimbangkan untuk menjadi bagian dari sistem sesungghnya. 40
Prototyping Walaupun dengan masalah yang mungkin terjadi, namun model Prototipe tetap bisa menjadi model paradigma yang efektif. Kuncinya adalah “to define the rules of the game at the beginning” Semua stakeholders menyetujui bentuk sistem yang akan dibangun selanjutnya. 41
Prototyping Menurut [Sommerville, 2007], model Prototipe dapat diaplikasikan : Untuk sistem berukuran kecil-menengah Untuk bagian dari sistem besar (contoh: user interface) Untuk sistem yang tidak digunakan dalam jangka waktu
lama
42
The Spiral Model The Spiral Model [Sommerville, 2007] Proses direpresentasikan seperti bentuk spiral Tiap putaran dalam spiral merepresentasikan sebuah fase dalam proses Semua resiko didapatkan dan diselesaikan dalam tiap proses.
43
The Spiral Model
44
The Spiral Model Model evolutionary ini melakukan pengulangan proses secara teratur dan sistematik dari proses waterfall model. Berpotensi untuk dapat dilakukan pengembangan yang lebih cepat, untuk kemudian di-upgrade ke versi sistem yang lebih baik. Pendekatan yang lebih realistis untuk sistem perangkat lunak berskala besar. 45
The Spiral Model Problems… Sulit untuk meyakinkan kustomer (dalam hal kontrak) bahwa proses evaluasi sistem akan terus berjalan secara teratur sepanjang masa pembuatan perangkat lunak Kebutuhan sistem (dan resiko yang mungkin terjadi) harus benar-benar dilihat dari awal, dan ini membutuhkan keahlian/pengalaman proyek perangkat lunak
46
Concurrent Models
47
Evolutionary Process Model Secara Keseluruhan… Dapat diadaptasi untuk diaplikasikan ke pembangunan perangkat lunak bahkan yang berskala besar sekalipun. Tim pengembang perangkat lunak dapat merepresentasikan tiap elemen dari proses model yang sudah didefinisikan sebelumnya.
48
Other Process Models Component based development – model pengembangan dengan sistem reuse dari komponen yang sudah ada Formal methods – menekankan pada konsep matematika untuk membuat spesifikasi requirement AOSD (Aspect Oriented Software Development) – Pendekatan pada aspek pendefinsian, spesifikasi, disain, dan konstruksi Unified Process - a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) 49
Pertanyaan???
50
Up Coming Next…
Unified Process Agile Development PR Individual 51
Terima Kasih…
52
