Proses Software. Tujuan

(1)

Rekayasa Perangkat Lunak 1

Proses Software

Arna Fariza PENS-ITS

Tujuan

Memperkenalkan model proses software Menggambarkan beberapa model proses dan

kapan digunakan

Menggambarkan outline model proses untuk rekayasa persyaratan, pengembangan

software, testing dan evolusi

Mengenalkan model Rational Unified Process Mengenalkan teknologi CASE untuk mendukung

(2)

Rekayasa Perangkat Lunak

3

Materi

Model proses software Iterasi proses

Agile Software Development Aktifitas Proses

The Rational Unified Process

Computer-aided software engineering

4

Proses Software

Sekumpulan aktifitas terstruktur yang dibutuhkan untuk mengembangkan sistem software

o Spesifikasi

o Desain

o Validasi

o Evolusi

Sebuah model proses perangkat lunak

merupakan representasi abstrak dari proses. Menyajikan deskripsi proses dari beberapa perspektif tertentu.

(3)

5

Model Proses Software Generik

Model waterfall

o Memisahkan dan membedakan fase spesifikasi dan

pengembangan.

Pengembangan Evolusioner

o Spesifikasi, pengembangan dan validasi terpisah

Component-based software engineering

o Sistem dibangun dari komponen yang ada.

Ada banyak varian model ini misalnya mengembangkan proses waterfall, tetapi menggunakan spesifikasi

formal yang disempurnakan melalui beberapa tahap untuk implementasi desain

Model Waterfall

Definisi persyaratan Implementasi dan testing unit Desain sistem

dan software

Integrasi dan testing sistem

(4)

7

Fase model Waterfall

Analisa dan definisi persyaratan Desain sistem dan software Implementasi dan unit testing Integrasi dan testing sistem Operasi dan maintenance

Kelemahan utama dari model waterfall adalah sulitnya mengakomodasi perubahan setelah proses sedang berlangsung. Satu fase harus lengkap sebelum pindah ke tahap berikutnya.

8

Permasalahan Model Waterfall

Tidak fleksibel , sulit merespon kebutuhan konsumen yang berubah

Model ini hanya sesuai jika persyaratan/ kebutuhan dipahami dengan baik dan

perubahan selama proses desain hanya sedikit. Sistem bisnis memiliki persyaratan yang stabil. Model waterfall sebagian besar digunakan

untuk rekayasa sistem proyek besar di mana sistem dikembangkan di beberapa site

(5)

9

Pengembangan Evolusioner

Pengembangan Exploratory

o Ditujukan untuk bekerja dengan konsumen dan

mengembangkan dari spesifikasi awal. Dimulai dengan pemahaman persyaratan yang baik dan usulan fitur baru dari konsumen.

Throw-away prototyping

o Ditujukan untuk memahami persyaratan sistem.

Dimulai dengan persyaratan kurang dipahami sampapi mendapatkan yang benar-benar dibutuhkan.

Pengembangan Evolusioner

Versi inisial Versi menengah Aktifitas yang berjalan Deskripsi outline Spesifikasi Pengembangan

(6)

11

Pengembangan Evolusioner

Permasalahan

o Kurangnya visibilitas proses; o Struktur sistem buruk;

o Keahlian khusus (misalnya dalam bahasa pemrograman untuk prototipe cepat) mungkin diperlukan.

Aplikasi

o Untuk sistem interaktif berukuran kecil atau medium

o Untuk bagian dari sistem besar (misalnya user interface) o Untuk sistem dengan daur hidup pendek

Component-based software engineering

Berdasarkan systematic reuse dimana sistem

diintegrasikan dari dari komponen yang ada atau sistem COTS (Commercial-off-the-shelf). Tahapan proses

o Analisa komponen; o Modifikasi persyaratan; o Desain sistem dengan reuse; o Pengembangan dan integrasi.

Pendekatan ini semakin banyak digunakan setelah beberapa standar komponen muncul.

(7)

Pengembangan Reuse-oriented

Spesifikasi persyaratan Analisa komponen Modifikasi persyarata n Desain sistem dengan reuse Pengembangan

dan integrasi Validasi sistem

Materi

(8)

15

Iterasi Proses

Persyaratan sistem SELALU berkembang dalam perjalanan proyek sehingga proses iterasi di mana tahap-tahap yang dikerjakan sebelumnya menjadi bagian dari proses untuk sistem yang besar.

Iterasi dapat diaplikasikan untuk semua model proses generik

2 pendekatan :

o Pengembangan incremental

o Pengembangan spiral

16

Pengembangan Incremental

Delivery sistem bukan pengiriman tunggal, tetapi pengembangan dan pengiriman dipecah menjadi bertahap dengan setiap ‘increment’ memberikan bagian fungsional yang diperlukan.

Persyaratan user diprioritaskan dan persyaratan prioritas tertinggi dimasukkan dalam ‘increment’ awal.

Setelah pengembangan ‘increment’ dimulai, persyaratan dibekukan lebih dahulu dan

persyaratan untuk ‘increment’ selanjutnya dapat dikembangkan.

(9)

Incremental development

System incomplete Sistem final Mendefinisikan persyaratan outline Increment persyaratan Desain arsitektur sistem Mengembangkan Increment sistem Validasi increment Integrasi increment Validasi sistem

Keuntungan Pengembanan

Incremental

Software disampaikan ke konsumen pada setiap ‘increment’ sehingga fungsional sistem tersedia terlebih dahulu

‘increment’ awal bertindak sebagai prototype untuk membantu memperoleh persyaratan untuk ‘increment’ berikutnya

Resiko lebih rendah dari keseluruhan kegagalan proyek Layanan sistem prioritas tertinggi cenderung menerima

(10)

19

Pengembangan Spiral

Proses direpresentasikan sebagai spiral bukan sebagai urutan kegiatan dengan melihat sistem sebelumnya (backtracking).

Setiap loop dalam spiral merupakan fase dalam proses.

Tidak ada fase tetap seperti spesifikasi atau desain - loop dalam spiral dipilih tergantung pada apa yang dibutuhkan.

Risiko secara eksplisit dinilai dan diselesaikan selama proses berlangsung.

20

Model Spiral model pada Proses

Software

- C o n c e p t o f O p e r a t i o n Menentukan alternatif dan batasan obyektif

Evaluasi identifikasi alternative, pemecahan resiko Perencanaan fase berikutnya Mengembangkan, verifikasi produk level

berikutnya Analisa resiko Analisa resiko Analisa resiko Analisa resiko REVIEW _{type 1}Proto

Prototype 2 Prototype 3

Prototype operasional

Simulasi, model, benchmark

Desain detail Kode Tes Unit Tes Integrasi Tes penerimaan Servis Desain Produk Desain V&V Kebutuhan S/W Validasi persyaratan Rencana Pengembangan Integrasi dan test plan Rencana persyaratan dan

(11)

21

Sektor Model Spiral

Tujuan pengaturan

o Tujuan khusus untuk setiap tahap diidentifikasikan.

Penilaian dan pengurangan resiko

o Risiko dinilai dan aktifitas dimasukkan untuk

mengurangi risiko utama.

Pengembangan dan Validasi

o Model pengembangan untuk sistem dipilih yang

dari model generik.

Perencanaan

o Proyek direview dan tahap berikutnya dari spiral

direncanakan.

Materi

(12)

23

Agile Software Development

Respon efektif terhadap perubahan

Komunikasi efektif dengan semua stakeholder Melibatkan konsumen pada tim, menghilangkan

istilah "kami dan mereka"

Pengorganisasian tim sehingga pekerjaan terkendali

Rapid, incremental delivery of software

24

Agile Software Process – Tiga

Kunci Asumsi

Kesulitan dalam memprediksi perubahan persyaratan dan prioritas pelanggan

Untuk banyak jenis s / w, desain dan konstruksi disisipkan

Analisis, desain, konstruksi, dan pengujian yang tidak mudah ditebak

(13)

25

Agile Software Process

Sebuah agile process harus beradaptasi Beradaptasi secara bertahap (Incremental) Membutuhkan umpan balik pelanggan Katalis yang efektif untuk umpan balik

pelanggan sebagai prototipe operasional

Agile Process Models

Extreme Programming (XP)

Adaptive Software Development (ASD)

Dynamic Systems Development Method (DSDM) Scrum

Crystal

Feature Driven Development (FDD) Agile Modeling (AM)

(14)

27

Extreme Programming (XP)

Merupakan agile process yang digunakan secara luas, dikenalkan oleh Kent Beck [BEC99]

XP menggunakan pendekatan berorientasi obyek sebagai paradigma pembangunan Mendefinisikan 4 aktifitas o Planning o Design o Coding o Testing 28

Extreme Programming (XP)

refactoring user stories values

acceptance test criteria

iteration plan simple design CRC cards spike solutions prototypes pair programming unit test continuous integration acceptance testing software increment

project velocity computed

(15)

29

Materi

Aktifitas Proses

Spesifikasi Software

Desain dan implementasi Software Validasi Software

(16)

31

Spesifikasi Software

Proses penentukan layanan apa saja yang dibutuhkan dan kendala pada operasi dan pengembangan sistem.

Proses rekayasa persyaratan

o Studi kelayakan

o Perolehan dan analisa persyaratan

o Spesifikasi persyaratan

o Validasi persyaratan

32

Proses Rekayasa persyaratan

Studi

kelayakan Mendapatkan _{dan analisa} persyaratan Spesifikasi persyaratan Validasi persyaratan Laporan kelayakan Model sistem persyaratan sistem dan user

Dokumen persyaratan

(17)

33

Desain dan Implementasi Software

Proses mengubah spesifikasi sistem ke sistem yang dapat dieksekusi.

Desain software

o Merancang struktur software yang didapatkan dari

spesifikasi

Implementasi

o Mengubah struktur software ke dalam program

yang dieksekusi

Aktifitas desain dan implementasi saling berhubungan atau mungkin terpisah

Aktifitas Proses Desain

Desain arsitektur

Spesifikasi abstrak Desain antar muka Desain komponen Desain struktur data Desain algoritma

(18)

35

Proses Desain Software

Aktifitas desain Produk desain Spesifikasi persyarata n Desain arsitektur Spesifikasi abstrak Desain antar muka Desain komponen Desain struktur data Desain algoritma Arsitektur sistem Spesifikasi software Spesifikasi antar muka Spesifikasi komponen Spesifikasi struktur data Spesifikasi algoritma

36

Metode Terstruktur

Pendekatan sistematis untuk pengembangan desain software

Desain biasanya terdokumentasi sebagai kumpulan model grafis

Model yang mungkin

o Model Object; o Model Sequence; o Model State transition; o Model Structural; o Model Data-flow.

(19)

37

Pemrograman dan Debugging

Menerjemahkan desain ke dalam program dan

menghilangkan error dari program.

Pemrograman adalah aktivitas pribadi - tidak ada proses pemrograman generik.

Pemrogram melakukan beberapa pengujian program untuk menemukan kesalahan dalam program dan menghapus kesalahan dalam proses debugging.

Proses Debugging

Mencari error Desain perbaikan error Perbaikan error Re-test program

(20)

39

Validasi Software

Verifikasi dan validasi (V & V) dimaksudkan untuk menunjukkan bahwa sistem sesuai dengan spesifikasi dan memenuhi persyaratan dari konsumen.

Melibatkan review proses dan pengujian sistem.

Pengujian sistem melibatkan eksekusi sistem dengan uji kasus yang berasal dari spesifikasi data riil yang diproses oleh sistem.

(21)

41

Tahapan Testing

Testing Unit atau Komponen

o Komponen individu diuji secara independen;

o Komponen mungkin fungsi atau benda atau kelompok yang berhubungan dari entitas.

Testing Sistem

o Pengujian sistem secara keseluruhan.

Testing Penerimaan

o Pengujian dengan data konsumen untuk memeriksa bahwa sistem memenuhi persyaratan pelanggan.

Fase Testing

Spesifikasi persyaratan Spesifikasi sistem Desain sistem Desain detail Kode dan tes modul dan unit

Servis penerimaan Tes Tes integrasi Tes integrasi Perencanaan tes penerimaan Perencanaan tes integrasi sistem Perencanaan tes integrasi sub sistem

(22)

43

Evolusi Software

Software bersifat fleksibel dan dapat berubah Jika persyaratan berubah karena situasi bisnis

yang berubah, perangkat lunak yang

mendukung bisnis juga harus berkembang dan berubah.

Walaupun sudah ada batas antara

pembangunan dan evolusi (maintenance), sedikit demi sedikit sistem dapat menjadi benar-benar baru.

44

Evolusi Sistem

Sistem yang

sudah ada Sistem _baru

Modifikasi sistem Menawarkan

perubahan sistem Menaksir sistem

yang sudah ada Menentukan

(23)

45

Materi

The Rational Unified Process

Adalah model proses modern yang berasal dari UML dan proses yang terkait.

Secara normal digambarkan dari 3 perspektif

o Perspektif dinamis yang menunjukkan fase dari waktu ke waktu;

o Perspektif statis yang menunjukkan kegiatan proses; o Perspektif praktis yang menunjukkan praktik yang

(24)

Model Fase RUP

Fase RUP

Inception

o Membangun bisnis untuk sistem.

Elaboration

o Mengembangkan pemahaman domain masalah dan arsitektur sistem.

Construction

o Desain sistem, pemrograman dan testing.

Transision

(25)

RUP good practice

Mengembangkan perangkat lunak secara iteratif Mengelola persyaratan

Menggunakan arsitektur component-based Visualisasi model software

Verifikasi kualitas software Perubahan kontrol ke software

Materi

(26)

Computer-aided software engineering

Computer-aided software engineering (CASE) adalah software yang mendukung proses pengembangan dan evolusi software.

Aktifitas Otomatis antara lain

o Editor Grafis untuk pengembangan model sistem; o Data dictionary untuk mengelola desain entitas; o Graphical UI builder untuk membangun user interface; o Debugger untuk menemukan kegagalan program;

o Penterjemah otomatis untuk membangkitkan versi baru dari program.

52

Teknologi CASE

Teknologi Case membawa perbaikan signifikan dalam proses software

o Rekayasa software membutuhkan pemikiran

kreatif – hal ini tidak dapat diotomasi

o Rekayasa software adalah aktifitas tim dan untuk

proyek besar, banyak waktu dihabiskan untuk interaksi tim. Teknologi CASE tidak mendukung hal ini.

(27)

53

Klasifikasi CASE

Klasifikasi membantu mengerti perbedaan tipe tool CASE dan dukungan untuk aktifitas proses Perspektif Fungsional

o Tool diklasifikasi berdasarkan fungsi tertentu

Perspektif Proses

o Tool diklasifikasi berdasarkan aktifitas proses yang

didukung

Perspektif Integrasi

o Tool diklasifikasi berdasarkan organisasi ke dalam

unit integrasi

Klasifikasi tool berdasarkan fungsi

Tool type Examples

Planning tools PERT tools, estimation tools, spreadsheets Editing tools Text editors, diagram editors, word processors Change management tools Requirements traceability tools, change control systems Configuration management tools Version management systems, system building tools Prototyping tools Very high-level languages, user interface generators Method-support tools Design editors, data dictionaries, code generators Language-processing tools Compilers, interpreters

Program analysis tools Cross reference generators, static analysers, dynamic analysers Testing tools Test data generators, file comparators

(28)

Klasifikasi Tool berbasis aktifitas

56

Integrasi CASE

Tool

o Mendukung task proses individu seperti

pemeriksaan konsistensi desain, text editing dll

Workbench

o Mendukung fase proses seperti spesifikasi atau

desain. Biasanya melibatkan sejumlah tool integrasi

Lingkungan

o Mendukung semua atau bagian substansi dari

keseluruhan proses software. Biasanya melibatkan beberapa workbench terintegrasi

(29)

Tool, workbench, lingkungan

Key Points

Proses software adalah aktivitas yang terjadi dalam memproduksi dan menghasilkan sistem software. Direpresentasikan dalam model proses software Aktifitas umum adalah spesifikasi, desain dan

implementasi, validasi dan evolusi

Model proses generik menggambarkan organisasi dari proses software

Model proses iteratif menggambarkan proses software sebagai siklus aktifitas

(30)

59

Key point

Rekayasa persyaratan adalah proses mengembangkan spesifikasi software

Proses desain dan implementasi mengubah spesifikasi ke program eksekusi

Validasi melibatkan pemeriksaan bahwa sistem sesuai dengan spesifikasi dan keperluan user

Evolusi menyangkut modifikasi sistem setelah digunakan

Rational Unified Process adalah model proses umum yang membagi aktifitas berdasarkan fase