Mata Kuliah Testing & Implementasi SistemProgram Studi Sistem Informasi 2013/2014

STMIK Dumai-- Pertemuan 2 --

This presentation is revised by Hazlinda A., STMIK, 2013

Acknowledgement

2

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 thEdition, Pearson-Addison Wesley, England, 2007.

[Dennis, 2010] Dennis, Alan, et al, System Analysis and Design, 4th Edition, John Wiley & Sons, New Jersey, 2010.

Mengapa Perlu PROSES MODEL? Banyak sistem gagal yang akhirnya ditinggalkan karena

para analis mencoba membangun sebuah sistem yang hebat tanpa mengerti bagaimana sistem yang seharusnyasesuai dengan tujuan perusahaan

Tujuan utama dari sistem informasi adalah untukmembuat sistem yang bernilai untuk perusahaan (dalamartian memberi keuntungan bagi perusahaan)

3

4

Prolog Membangun perangkat lunak komputer merupakan suatu

proses pembelajaran yang mengandung unsur sosial(iterative social learning process) dan menghasilkansebuah 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 lunakyang high-quality [Pressman, 2010].

Suatu struktur dari kumpulan aktivitas yang dibutuhkan untukmembangun sebuah sistem perangkat lunak [Sommerville,2007]: Specification Design & Implementation Validation Evolution

8

Karakteristik Software ProcessMenurut [Sommerville, 2007]: Menentukan aktivitas-aktivitas secara mayor Memanfaatkan sumber (resources), untuk

mengoptimalkan jadwal, dalam mencapai hasil perangkatlunak

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 denganstakeholders) 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 menghasilkansebuah produk kerja secara mayor (contoh: model disainarsitektur)

11

Software Process - Tugas

Suatu tugas yang berfokus ke tugas berskala kecil, namuntujuannya 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 bagaimanamembangun perangkat lunak komputer.

Ia adalah bentuk pendekatan yang dapat disesuaikanuntuk menentukan aksi-aksi dan tugas-tugas yang tepat.

Tujuan akhirnya adalah untuk menghasilkan perangkatlunak dengan tepat waktu dan dengan kualitas yang memuaskan pihak yang akan menggunakan perangkatlunak 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 aktivitasterorganisir 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 denganbaik

Supportable: Adanya dukungan otomatis untuk tiap aktivitas

Usable: Proses dapat diterima dan digunakan oleh developer

21

Proses Model PreskriptifWhat ?

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 Preskriptif1. Waterfall Model

2. Incremental ProcessModels

3. Evolutionary ProcessModels– Prototyping– The Spiral Model– The Concurrent Model

4. Specialized ProcessModels– Component-BasedDevelopment– The Formal Methods Model– Aspect-Oriented Software

Development

5. The Unified Process

24

The Waterfall ModelAlias: 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 ModelThe 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 pengembangansaja.

27

The Waterfall Model

28

[Dennis, 2010]

Dengan metode pengembanganmodel Waterfall, para analis danpengguna terus melalui satu faseke fase lainnya secara berurutan.

The Incremental Model

29

Incremental: dibangun per-bagian/potongan/modulsecara fungsional Kebutuhan (requirement) perangkat lunak di tiap modul

terdefinisi dengan baik [Sommerville, 2007]

The Incremental Model

30

The Incremental Model Baik digunakan pada saat:

kita ingin menyajikan sejumlah fungsionalitas perangkatlunak untuk user dengan cepat untuk kemudiandikembangkangkan hingga pada saat perangkat lunaktersebut diluncurkan (release).

Merupakan kombinasi dari alur proses (process flow)yang linear dan paralel.

Tiap alur linear menghasilkan “tambahan fungsi” dariperangkat lunak. Disebut juga sebagai “increments” of the software.

31

The Incremental ModelKarakteristik lain… Tidak membangun sistem langsung menjadi satu sistem besar yang utuh,

namun memcahnya menjadi beberapa “increment” sistem, dimana tiapincrement-nya menyajikan bagian kebutuhan fungsionalitas yang diminta.

Kebutuhan fungsional yang dibangun terlebih dahulu adalah kebutuhanyang tingkat prioritasnya paling tinggi.

Increment sistem yang pertama biasa disebut sebagai core product.

Tiap pengembangan dari satu increment dimulai, semua kebutuhanfungsional yang sudah ada dibekukan. Jika ada kebutuhan fungsional baru, maka itu akan menjadi kebutuhan

fungsional untuk increment selanjutnya.

32

Keuntungan Incremental ModelThe 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 sebagaiprototipe untuk mengklarifikasi kebutuhan pada increment berikutnya.

Rendahnya resiko kegagalan proyek secara keseluruhan.

Fungsi sistem yang memiliki prioritas tinggi dapat dites lebihawal, dan dapat lebih sering dites.

33

Evolutionary Process Models Bersifat iteratif (adanya pengulangan aktivitas) Proses model evolutionary ini memungkinkan para

pengembang untuk meningkatkan kompleksitasperangkat lunak ke versi yang lebih tinggi.

Masih ingat 3 contoh proses model evolutionary???Prototyping

The Spiral ModelConcurrent

34

Contoh Kasus… (Prototyping) Customer seringkali hanya mendeskripsikan kebutuhan

tentang software yang akan dibangun secara umum, tidak detail menjelaskan input, proses atau output yangdiinginkan

Di lain pihak, developer masih ragu akan efisiensialgoritma, 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 padasaat kebutuhannya masih belum jelas.

Kustomer akan dapat gambaran tentang sistem yang akandibangun (get a feel for the actual system) dan paradeveloper dapat segera memulai membangun sistemnya.

37

Prototyping Prosesnya:

quick design, build prototype, evaluate, refine prototype, … engineer product

Bentuk prototipe yang dibangun tergantung dari analisisyang 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 maslaahyang terjadi pada saat sistem dibuat secara utuhfungsinya.

Para developer membuat implementasi sistem secara“kompromi” untuk membuat dengan cepat prototipesistem 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 menjadibagian dari sistem sesungghnya.

40

Prototyping Walaupun dengan masalah yang mungkin terjadi, namun

model Prototipe tetap bisa menjadi model paradigmayang efektif.

Kuncinya adalah “to define the rules of the game at the beginning”

Semua stakeholders menyetujui bentuk sistem yang akandibangun selanjutnya.

41

PrototypingMenurut [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 ModelThe 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 sistemyang lebih baik.

Pendekatan yang lebih realistis untuk sistem perangkatlunak berskala besar.

45

The Spiral Model Problems… Sulit untuk meyakinkan kustomer (dalam hal kontrak)

bahwa proses evaluasi sistem akan terus berjalan secarateratur sepanjang masa pembuatan perangkat lunak

Kebutuhan sistem (dan resiko yang mungkin terjadi) harusbenar-benar dilihat dari awal, dan ini membutuhkankeahlian/pengalaman proyek perangkat lunak

46

Concurrent Models

47

Evolutionary Process ModelSecara Keseluruhan… Dapat diadaptasi untuk diaplikasikan ke pembangunan

perangkat lunak bahkan yang berskala besar sekalipun.

Tim pengembang perangkat lunak dapatmerepresentasikan 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 ProcessAgile Development

PR Individual

51

Terima Kasih…

52