3. Praktek - Praktek Terbaik Rekayasa Perangkat Lunak dan Pengenalan RUP

Ukuran: px

Mulai penontonan dengan halaman:

Download "3. Praktek - Praktek Terbaik Rekayasa Perangkat Lunak dan Pengenalan RUP"

Ratna Muljana
7 tahun lalu
Tontonan:

1 3. Praktek - Praktek Terbaik Rekayasa Perangkat Lunak dan Pengenalan RUP SIF15001 Analisis dan Perancangan Sistem Informasi Agi Putra Kharisma, S.T., M.T. Genap 2014/2015 Desain slide ini dadaptasi dari University of San Fransisco

2 Mengapa butuh praktek terbaik?

3 Proyek Perangkat Lunak Di New Zealand

4 Gejala dan Penyebab Utama Apakah gejala pengembangan perangkat lunak yang bermasalah? Apakah penyebab utama terjadinya permasalahan tersebut?

5 Menelusuri Gejala dan Penyebab Utama Symptoms Root Causes Best Practices Needs not met Requirements churn Modules don t fit Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change IBM

6 Praktek - Praktek Terbaik (versi IBM) 1. Mengambangkan secara berulang (develop iteratively) 2. Mengelola kebutuhan 3. Menggunakan arsitektur berbasis komponen 4. Memodelkan secara visual 5. Memeriksa kualitas secara terus menerus 6. Mengelola perubahan

7 Praktek 1: Mengembangkan Secara Berulang (Develop Iteratively)

8 Profil Risiko Waterfall vs Iterative

9 Praktek 2: Mengelola Kebutuhan

11 Dalam Mengelola Kebutuhan... Pastikan: solve the right problem build the right system dengan pendekatan sistematis untuk: eliciting organizing documenting managing terhadap perubahan yang terjadi pada kebutuhan perangkat lunak.

12 Aspek Dalam Pengelolaan Kebutuhan Menganalisis permasalahan Memahami kebutuhan pengguna Mendefinisikan sistem Mengelola lingkup (scope) Menyempurnakan (refine) definisi sistem Mengelola perubahan kebutuhan

13 Peta Teritori

14 Praktek 3: Menggunakan Arsitektur Berbasis Komponen Apakah yang dimaksud dengan komponen? Mengapa menggunakan komponen?

15 Contoh Komponen Elektronika

16 Contoh Diagram Komponen Suatu Perangkat Lunak

17 Tujuan Arsitektur Berbasis Komponen Sebagai dasar untuk penggunaan ulang (reuse) Penggunaan ulang komponen Penggunaan ulang arsitektur Sebagai dasar untuk manajemen proyek Planning Staffing Delivery Kontrol intelektual Mengelola kompleksitas Memelihara integritas

18 Arsitektur Tahan Banting dan Berbasis Komponen Tahan Banting (Resilient) Memenuhi kebutuhan saat ini dan masa mendatang Meningkatkan extensibility Menyediakan penggunaan ulang Merangkum ketergantungan sistem (encapsulates system dependency) Berbasis Komponen Menggunakan ulang atau memodifikasi komponen Memilih komponen yang tersedia secara komersial Mengembangkan (evolve) perangkat lunak yang ada secara inkremental

19 Praktek 4: Memodelkan Secara Visual *Menggunakan UML

20 Mengapa memodelkan secara visual? Menangkap (capture) struktur dan perilaku (behavior) Menunjukkan bagaimana elemen sistem saling terhubung Menjaga konsistensi antara perancangan dan implementasi Menyembunyikan atau menjabarkan detail sesuai kebutuhan Membangun komunikasi yang tidak ambigu

21 Pemodelan Visual Dengan UML Allows multiple views Provides precise syntax and semantics Static Diagrams Sequence Diagrams Use-Case Diagrams Class Diagrams Object Diagrams Collaboration Diagrams Models Component Diagrams Dynamic Diagrams Statechart Diagrams Activity Diagrams Deployment Diagrams

22 Pemodelan Visual Dengan UML

23 Praktek 5: Memeriksa Kualitas Secara Terus Menerus Mengapa harus diperiksa terus menerus?

24 Software problems are 100 to 1000 times more costly to find and repair after deployment Cost to Repair Software Cost of Lost Opportunities Cost Cost of Lost Customers Development Phases

25 Dimensi Pengujian Pada Kualitas

26 Pengujian dilakukan pada setiap iterasi Iteration 1 Iteration 2 Iteration 3 Iteration 4 UML Model and Implementation Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 Tests

27 Praktek 6: Mengelola Perubahan

28 Apa yang dikelola? Mengamankan tempat kerja para pengembang Otomatisasi integration/build management Pengembangan secara paralel Workspace Management Parallel Development Configuration Management is more than just check-in and checkout. Process Integration REPORT ALERT Build Management

29 Aspek Aspek Dalam Pengelolaan Perubahan Change Request Management (CRM) Configuration Status Reporting Configuration Management (CM) Change Tracking Version Selection Software Manufacture

Iteratively Manage Requirements Use Component

30 RUP RUP mengimplementasikan praktek-praktek terbaik. Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

31 RUP Mencapai Praktek Terbaik Melalui Proses Pendekatan iteratif Petunjuk untuk aktivitas dan artifak Proses fokus pada arsitektur Perancangan dan implementasi mengacu pada use cases. Abstraksi terhadap sistem melalui model

32 Peran UML Pada RUP RUP dikembangkan bersama (hand-in-hand) dengan UML Banyak artifak pada RUP yang memiliki representasi dalam UML RUP juga memiliki petunjuk untuk beberapa konsep UML

34 Perubahan Fokus Pada Setiap Fase (1)

35 Perubahan Fokus Pada Setiap Fase (2)

36 Berapa lama waktu yang dibutuhkan pada setiap iterasi? Iterasi dimulai dari perencanaan dan analisis kebutuhan (planning and requirements) kemudian berakhir dengan rilis internal/eksternal. Idealnya, setiap iterasi dilakukan selama 2 6 minggu tergantung ukuran serta kompleksitas proyek. Faktor faktor yang memengaruhi durasi iterasi: Ukuran, stabilitas, dan kematangan suatu organisasi Kebiasaan (familiarity) terhadap proses iteratif Ukuran proyek Kesederhanaan teknis suatu proyek Tingkat otomatisasi untuk mengelola kode, mendistribusikan informasi, dan melakukan pengujian

37 Berapa banyaknya iterasi yang dibutuhkan? Rule of thumb: iterasi Phase Low Medium High Inception Elaboration Construction Transition Total 3 6 9

38 Kondisi yang mengakibatkan bertambahnya jumlah iterasi Inception Working with new functionality Unknown business environment Highly volatile scope Make-buy decisions Construction Lots of code to write and verify New technology or development tools Elaboration Working with new system environment (new architectural features) Untested architectural elements Need for system prototypes Transition Need for alphas and betas Conversions of customer base Incremental delivery to customers

39 Referensi Best Practices of Software Engineering and Introduction to RUP IBM Rational Software

dokumen-dokumen yang mirip

Rational Unified Process (RUP)

Rational Unified Process (RUP) Universitas IGM HD-UIGM-FK-01 Fakultas : Ilmu Komputer Pertemuan ke : 8 Program Studi : Teknik Informatika Handout ke : 1 Kode Matakuliah : Jumlah Halaman : 25 Matakuliah : Rekayasa Perangkat Lunak Mulai