REVIEW (1) Perangkat Lunak : terdiri dari

instruksi (program komputer yang ketika dieksekusi akan memberi fungsi dan hasil yang diinginkan),

struktur data (yang diolah oleh program untuk menjadi informasi), dan

dokumen (yang menggambarkan operasi dan penggunaan program).

REVIEW (2)

Rekayasa Perangkat Lunak (Software Engineering) : Ilmu yang mempelajari pembuatan software yang baik dengan pendekatan tehnik (Engineering approach)

Munculnya krisis perangkat lunak pada era 65-85 karena banyaknya kegagalan proyek perangkat lunak (over budget, over schedule, programming error dll)

DASAR – DASAR SOFTWARE PROCESS

PROSES PERANGKAT LUNAK

Sekumpulan aktifitas yang memiliki tujuan untuk pengembangan ataupun evolusi perangkat lunak.

Aktifitas generik dalam semua proses perangkat lunak adalah: Spesifikasi – apa yang harus dilakukan oleh

perangkat lunak dan batasan/kendala pengembangannya

Pengembangan – proses memproduksi sistem perangkat lunak

Validasi – pengujian perangkat lunak terhadap keinginan penggunak

Evolusi – perubahan perangkat lunak berdasarkan perubahan keinginan.

5

WHAT IS IT? When you build a product or system, it’s important

to go through a series of predictable steps—a road map that helps you create a timely, high-quality result. The road map that you follow is called a ‘software process.’

Ketika kita membangun sebuah produk atau sistem, penting untuk melalui serangkaian langkah-langkah yang dapat diprediksi, yaitu sebuah road map yang membantu kita membuat sebuah hasil berkualitas tinggi dan jelas waktunya. Road map itulah yang kita sebut sebagai proses s/w.

WHO DOES IT? Software engineers and their managers

adapt the process to their needs and then follow it. In addition, the people who have requested the software play a role in the software process.

Insinyur s/w dan manajernya menyesuaikan proses terhadap kebutuhan dan kemudian melaksanakannya. Sebagai tambahan, pihak yang meminta dibuatkan s/w memiliki peran penting dalam proses s/w.

6

7

WHY IS IT IMPORTANT? Because it provides stability, control, and

organization to an activity that can, if left uncontrolled, become quite chaotic.

Karena proses s/w memberikan stabilitas, kendali dan organisasi terhadap aktifitas yang seandainya dibiarkan begitu saja akan menjadi sangat kacau.

8

WHAT ARE THE STEPS? At a detailed level, the process that you adopt

depends on the software you’re building. One process might be appropriate for creating software for an aircraft avionics system, while an entirely different process would be indicated for the creation of a Web site.

Pada tingkat detil, proses yang kita pakai tergantung pada s/w yang dibuat. Sebuah proses mungkin cocok untuk membuat s/w sistem pengendali pesawat, sementara untuk membuat sebuah web site akan digunakan proses yang benar-benar berbeda.

9

WHAT IS THE WORK PRODUCT? From the point of view of a software

engineer, the work products are the programs, documents, and data produced as a consequence of the software engineering activities defined by the process.

Dari sudut pandang insinyur, produk kerjanya adalah program, dokumen, dan data sebagai konsekuensi dari aktivitas RPL yang didefinisikan oleh prosesnya.

10

HOW DO I ENSURE THAT I’VE DONE IT RIGHT? A number of software process assessment

mechanisms enable organizations to determine the “maturity” of a software process. However, the quality, timeliness, and long-term viability of the product you build are the best indicators of the efficacy of the process that you use.

Sejumlah mekanisme penilaian memungkinkan organisasi menentukan kedewasaan sebuah proses s/w. Bagaimanapun juga, kualitas, ketepatan waktu dan ketersediaan jangka panjang produk yang kita bangun adalah indikator terbaik dari kemujaraban proses yang dipakai.

ATRIBUT PERANGKAT LUNAK YANG BAIK: Maintanability (Dapat Dirawat)

PL harus dapat memenuhi perubahan kebutuhan

DependabilityPL harus dapat dipercaya

EfisiensiPL harus efisien dalam penggunaan

resource Usability

PL harus dapat digunakan sesuai dengan yang direncanakan

MODEL PROSES PL YANG GENERIC Model Air terjun (Water fall)

Memisahkan dan membedakan antara spesifikasi dan pengembangan

Pengembangan yang berevolusi Spesifikasi dan pengembangan saling bergantian

Pengembangan sistem Formal Menggunakan suatu model sistem matematika

yang ditransformasikan ke implementasi,

Pengembangan berbasis Re-use (penggunaan ulang) Sistem dibangun dari komponen yang sudah ada.

MODEL AIR TERJUN (WATER FALL)

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

Fase Model Air Terjun1. Analisis Kebutuhan dan pendefinisiannya2. Perancangan sistem dan Perangkat Lunak3. Implementasi dan unit testing4. Integrasi dan pengujian sistem5. Pengoperasian dan perawatan

Proses kembali ke state sebelumnya untuk mengantisipasi perubahan adalah sangat sulit.

Masalah pada Model Air Terjun: Partisi projek ke stages yang berbeda tidak

fleksibel. Hal ini mengakibatkan sulitnya untuk merespon

perubahan kebutuhan pengguna Oleh sebab itu model ini hanya cocok digunakan

apabila kebutuhan pengguna sudah dimengerti dengan baik,

PENGEMBANGAN YANG BEREVOLUSI (EVOLUTIONARY DEVELOPMENT)

Berdasarkan pada ide untuk mengembangkan implementasi awal, memperlihatkannya pada user untuk dikomentari, lalu memperbaikinya versi demi versi.

Tidak ada kegiatan spesifikasi, validasi, dan pengembangan yang terpisah

Ada 2 jenis: Pengembangan eksploratori (bekerja dgn

pelanggan untuk menyelidiki kebutuhan pelanggan dgn mengirimkan sistem akhir)

Prototype yang dapat dibuang (throw-away / eksperimen dengan kebutuhan pelanggan yang tidak dipahami dgn baik)

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

Concurrentactivities

Permasalahan evolutionary development: Kekurangan visibilitas prosesModel sistem biasanya tidak terstrukturMembutuhkan kemampuan khusus (mis.:

bahasa pemrograman untuk rapid prototyping).

Pemakaian model pengembangan yang berevolusi cocok untuk:Untuk sistem interaktif yang kecil atau

menengahUntuk salah satu bagian dari sistem yang

besar (mis. User Interface)Untuk sistem yang digunakan tidak terlalu

lama (short lifetime).

PENDEKATAN PENGEMBANGAN SISTEM FORMAL

Berbasiskan pada transformasi spesifikasi secara matematik melalui representasi yang berbeda untuk suatu program yang dapat dieksekusi,

Trasformasi menyatakan spesifikasi program Menggunakan pendekatan ‘Cleanroom’ untuk

pengembangan PL.

Requirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing

Perbedaan FTR dengan waterfall: Spesifikasi kebutuhan PL diperbaiki menjadi

spesifikasi formal yang rinci, dinyatakan secara matematis

Proses pengembangan perancangan, implementasi, dan pengujian unit digantikan dengan pendekatan transformasional untuk menjadi program

Jarak transformasi notasi matematis ke program lebih kecil dibandingkan dengan jarak transformasi dari spesifikasi ke program

FTR tidak praktis untuk dikembangkan pada proyek berskala besar.

PENDEKATAN PENGEMBANGAN RE-USABLE

Pendekatan ini sangat tergantung pada sejumlah komponen PL yang re-usable, kadangkala merupakan COTS (Commercial-Off The Shelf System).

Keuntungannya: mengurangi besarnya PL yg dikembangkan, serta memperkecil biaya dan resiko.

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

PROSES DENGAN ITERASI Dapat digunakan pada setiap model proses

generic Terdapat dua pendekatan:

Pengembangan Incremental : Pengembangan sistem berdasarkan model sistem yang dipecah sehingga model pengembangannya secara increment/bertahap

Model Spiral : Proses direpresentasikan sebagai model spiral (bukan berupa barisan aktfitas yang dapat ditrack mundur)

MODEL PENGEMBANGAN INCREMENTAL Customer mengidentifikasi kebutuhan, layanan yang

hendak dilakukan sistem, yang paling penting dan kurang penting

Alokasi layanan pada setiap increment bergantung prioritas layanan. Layanan dengan prioritas tertinggi dikerjakan lebih dulu.

Setelah increment diidentifikasi, increment tersebut dikerjakan. Pada saat pengembangan, analisa kebutuhan untuk increment lanjutannya dapat dilakukan, tetapi untuk increment yang sedang dikembangkan tidak bisa.

Setelah increment dideliver ke pelanggan, pelanggan dapat melakukan percobaan dari increment tersebut untuk menentukan kebutuhan increment selanjutnya.

Diusulkan oleh Mills (1980) sebagai cara untuk mengurangi pengerjaan ulang pada proses pengembangan dan memberi kesempatan pada pengguna untuk menunda keputusan rinci mereka sampai memperoleh pengalaman dengan sistem

Valida teincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Valida tesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem

KeuntunganPelanggan tidak perlu menunggu sampai

keseluruhan sistem selesai dikerjakan. Increment pertama menyelesaikan permasalahan mereka yang sangat kritis, shg aplikasi tsb dpt sgr digunakan.

Increment awal berupa prototype bisa membantu pelanggan memahami kebutuhan pada increment berikutnya,

Memiliki risiko lebih rendah terhadap keseluruhan pengembangan sistem,

Kemungkinan kecil bagi pelanggan untuk menemui kegagalan pada increment sistem yang paling penting.

MODEL PENGEMBANGAN SPIRAL Proses direpresentasikan sebagai model spiral

(bukan berupa barisan aktfitas yang dapat ditrack mundur)

Setiap loop dalam model spiral menyatakan fase proses,

Tidak terdapat fase tertentu seperti spesifikasi atau perancangan, tetapi loop dalam spiral ditentukan pada apa yang dibutuhkan

Dilakukan pertimbangan resiko secara eksplisit. Contoh: Jika yang digunakan dalam pengembangan adalah bhs pemrograman yg baru, resikonya: kode baris program tidak efisien, akibatnya: over budget dan over schedule

SEKTOR PADA MODEL SPIRAL Menentukan Tujuan

Mengidentifikasikan spesifikasi tujuan setiap fase Menilai Resiko dan Pengurangannya

Dilakukan analisis rinci untuk setiap resiko yang teridentifikasi dan langkah – langkah untuk mengurangi resiko tsb.

Pengembangan dan validasi Setelah evaluasi resiko, langkah selanjutnya adl

memilih metode pengembangan (prototipe evolusioner, transformasi formal, waterfall)

Perencanaan Project di review dan dibuat rencana untuk fase

proyek selanjutnya

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

SUMMARY Proses perangkat lunak :

(WHAT?) serangkaian langkah-langkah yang dapat diprediksi, yang membantu kita membuat sebuah software berkualitas tinggi dan jelas waktunya.

(WHO?)Software Engineer, manager dan customer (WHY?) Untuk mendapatkan stabilitas, kendali dan

organisasi terhadap aktifitas pembuatan software Model Proses Generik (menggambarkan

organisasi proses perangkat lunak) : Waterfall, Evolutionary Development, Formal Development, Re-usable Development

Model proses Iteratif (menggambarkan proses PL sebagai siklus kegiatan) : Incremental dan Spiral

LATIHAN Sarankan (dan berikan penjelasan yang rinci)

model proses generik yang paling sesuai yang dapat dipakai sebagai dasar pengembangan manajemen pengembangan sistem : Sistem akutansi universitas yang menggantikan

sistem yang ada Sistem untuk mengontrol pengereman pada mobil.

Jelaskan permasalahan yang sering muncul pada evolutionary development

Jelaskan bagaimana metode waterfall dan metode pengembangan formal dapat diakomodasi pada model proses spiral