Proses Software. Tujuan

9/26/2013

Proses Software Arna Fariza PENS-ITS

1 Rekayasa Perangkat Lunak

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 aktifitas proses software


1

9/26/2013

Materi

Model proses software Iterasi proses Agile Software Development Aktifitas Proses The Rational Unified Process Computer-aided software engineering


Proses Software Sekumpulan aktifitas terstruktur yang dibutuhkan untuk mengembangkan sistem software o o o o

Spesifikasi Desain Validasi Evolusi

Sebuah model proses perangkat lunak merupakan representasi abstrak dari proses. Menyajikan deskripsi proses dari beberapa perspektif tertentu. 4 Rekayasa Perangkat Lunak

2

9/26/2013

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 5 Rekayasa Perangkat Lunak

Model Waterfall Definisi persyaratan Desain sistem dan software Implementasi dan testing unit Integrasi dan testing sistem Operasi dan maintenance 6 Rekayasa Perangkat Lunak

3

9/26/2013

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.


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 (tempat). 8 Rekayasa Perangkat Lunak

4

9/26/2013

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 Aktifitas yang berjalan

Deskripsi outline

Spesifikasi

Versi inisial

Pengembangan

Versi menengah

Validasi

Versi akhir


5

9/26/2013

Pengembangan Evolusioner Permasalahan o o o

Kurangnya visibilitas proses; Struktur sistem buruk; Keahlian khusus (misalnya dalam bahasa pemrograman untuk prototipe cepat) mungkin diperlukan.

Aplikasi o o o

Untuk sistem interaktif berukuran kecil atau medium Untuk bagian dari sistem besar (misalnya user interface) 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 o o o

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

Pendekatan ini semakin banyak digunakan setelah beberapa standar komponen muncul.

6

9/26/2013

Pengembangan Reuse-oriented

Spesifikasi persyaratan

Analisa komponen

Modifikasi persyarata n

Desain sistem dengan reuse

Pengembangan dan integrasi

Validasi sistem


Materi



7

9/26/2013

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 15 Rekayasa Perangkat Lunak

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. 16 Rekayasa Perangkat Lunak

8

9/26/2013

Incremental development

Mendefinisikan persyaratan outline

Mengembangkan Increment sistem

Increment persyaratan

Desain arsitektur sistem

Validasi increment

Integrasi increment

Validasi sistem

Sistem final System incomplete


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 testing terbanyak


9

9/26/2013

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. 19 Rekayasa Perangkat Lunak

Model Spiral model pada Proses Software Menentukan alternatif dan batasan obyektif

Evaluasi identifikasi alternative, pemecahan resiko

Analisa resiko Analisa resiko Analisa resiko

Prototype 3

REVIEW Rencana persyaratan dan rencana daur hidup

Rencana Pengembangan Integrasi dan test plan Perencanaan fase berikutnya

Analisa resiko

Prototype operasional

Prototype 2 Prototype 1 Simulasi, model, benchmark

C onc e pt o f O pe r a ti on

Kebutuhan S/W

Validasi persyaratan Desain V&V

Servis

Tes penerimaan

Desain Produk

Desain detail Kode

Tes Integrasi

Tes Unit

Mengembangkan, verifikasi produk level berikutnya

20

Rekayasa Perangkat Lunak

10

9/26/2013

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. 21 Rekayasa Perangkat Lunak

Materi



11

9/26/2013

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

23

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

24

12

9/26/2013

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

25

Agile Process Models Extreme Programming (XP) Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) Scrum Crystal Feature Driven Development (FDD) Agile Modeling (AM)

26

13

9/26/2013

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 o o o

Planning Design Coding Testing

27

Extreme Programming (XP) user stories values acceptance test criteria iteration plan

simple design CRC cards

spike solutions prototypes

refactoring

pair programming Release

software increment project velocity computed

unit test continuous integration

acceptance testing 28

14

9/26/2013

Materi



Aktifitas Proses Spesifikasi Software Desain dan implementasi Software Validasi Software Evolusi Software

15

9/26/2013

Spesifikasi Software Proses penentukan layanan apa saja yang dibutuhkan dan kendala pada operasi dan pengembangan sistem. Proses rekayasa persyaratan o o o o

Studi kelayakan Perolehan dan analisa persyaratan Spesifikasi persyaratan Validasi persyaratan


Proses Rekayasa persyaratan Studi kelayakan

Mendapatkan dan analisa persyaratan Spesifikasi persyaratan

Laporan kelayakan

Validasi persyaratan Model sistem persyaratan sistem dan user Dokumen persyaratan


16

9/26/2013

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 33 Rekayasa Perangkat Lunak

Aktifitas Proses Desain

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


17

9/26/2013

Proses Desain Software

Spesifikasi persyarata n

Aktifitas desain

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

Produk desain


Metode Terstruktur Pendekatan sistematis untuk pengembangan desain software Desain biasanya terdokumentasi sebagai kumpulan model grafis Model yang mungkin o o o o o

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


18

9/26/2013

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


19

9/26/2013

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.


Proses Testing

20

9/26/2013

Tahapan Testing Testing Unit atau Komponen o o

Komponen individu diuji secara independen; 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

Perencanaan tes penerimaan

Servis

Tes penerimaan

Desain sistem

Perencanaan tes integrasi sistem

Desain detail

Perencanaan tes integrasi sub sistem

Tes integrasi sistem

Kode dan tes modul dan unit

Tes integrasi sub sistem


21

9/26/2013

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.


Evolusi Sistem

Menentukan persyaratan sistem

Menaksir sistem yang sudah ada

Menawarkan perubahan sistem

Sistem yang sudah ada

Modifikasi sistem

Sistem baru


22

9/26/2013

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 baik.

23

9/26/2013

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 o Memelihara sistem dalam lingkungan kerja.

24

9/26/2013

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



25

9/26/2013

Computer-aided software engineering Computer-aided software engineering (CASE) adalah software yang mendukung proses pengembangan dan evolusi software. Aktifitas Otomatis antara lain o o o o o

Editor Grafis untuk pengembangan model sistem; Data dictionary untuk mengelola desain entitas; Graphical UI builder untuk membangun user interface; Debugger untuk menemukan kegagalan program; Penterjemah otomatis untuk membangkitkan versi baru dari program.

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.


26

9/26/2013

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 53 Rekayasa Perangkat Lunak

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

Debugging tools

Interactive debugging systems

Documentation tools

Page layout programs, image editors

Re-engineering tools

Cross-reference systems, program re-structuring systems

27

9/26/2013

Klasifikasi Tool berbasis aktifitas

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 56 Rekayasa Perangkat Lunak

28

9/26/2013

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


29

9/26/2013

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 Teknologi CASE mendukung aktifitas proses software 59 Rekayasa Perangkat Lunak

30

Proses Software. Tujuan

Recommend Documents