Mata Kuliah Testing & Implementasi Sistem Program Studi Sistem Informasi 2014/2015 STMIK Dumai -- Pertemuan 2 --

Transkripsi

1 Mata Kuliah Testing & Implementasi Sistem Program Studi Sistem Informasi 2014/2015 STMIK Dumai -- Pertemuan 2 -- This presentation is revised STMIK, 2014

2 Acknowledgement Main materials: [Pressman, 2010] Pressman, Roger S. Software Engineering: A Practitioner s Approach. New York:McGraw-Hill Higher Education, Print Supplements: [Yud, 2012] Yudhoatmojo, Satrio Baskoro. Software & Software Engineering IKI Rekayasa Perangkat Lunak Term /2012. Faculty of Computer Science University of Indonesia Print [Sommerville, 2007] Sommerville, Ian, Software Engineering, 8 th Edition, Pearson Addison Wesley, England, [Dennis, 2010] Dennis, Alan, et al, System Analysis and Design, 4th Edition, John Wiley & Sons, New Jersey,

3 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 4

5 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

6 Apa itu PROSES? Proses merupakan kumpulan dari: aktivitas-aktivitas aksi-aksi, dan tugas-tugas yang dilakukan pada saat suatu produk akan dibuat. 6

7 Setelah mengerti arti PROSES Apakah yang dimaksud dengan SOFTWARE PROCESS (Proses Perangkat Lunak)??? 7

8 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

9 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

10 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

11 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

12 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

13 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

14 A Generic Process Model 14

15 Masih Ingat 5 Kerangka Aktifitas??? Disebut juga 5 Generic Framework Aktivities Apa-apa saja??? - Communication - Planning - Modeling - Construction - Deployment 15

16 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

17 1 - Linear Process Flow 17

18 2 - Iterative Process Flow 18

19 3 - Evolutionary Process Flow 19

20 4 - Parallel Process Flow 20

21 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

22 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

23 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

24 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

25 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

26 The Waterfall Model 26

27 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

28 The Waterfall Model [Dennis, 2010] Dengan metode pengembangan model Waterfall, para analis dan pengguna terus melalui satu fase ke fase lainnya secara berurutan. 28

29 The Incremental Model Incremental: dibangun per-bagian/potongan/modul secara fungsional Kebutuhan (requirement) perangkat lunak di tiap modul terdefinisi dengan baik [Sommerville, 2007] 29

30 The Incremental Model 30

31 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

32 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

33 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

34 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

35 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

36 Prototyping 36

37 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

38 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

39 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

40 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

41 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

42 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

43 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

44 The Spiral Model 44

45 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

46 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

47 Concurrent Models 47

48 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

49 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

50 Pertanyaan??? 50

51 Up Coming Next Unified Process Agile Development PR Individual 51

52 Terima Kasih 52