Desain slide ini dadaptasi dari University of San Fransisco

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

Mengapa butuh praktek terbaik?

Proyek Perangkat Lunak Di New Zealand

Gejala dan Penyebab Utama

• Apakah gejala pengembangan perangkat lunak yang

bermasalah?

• Apakah penyebab utama terjadinya permasalahan

tersebut?

Menelusuri Gejala dan Penyebab Utama

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

Symptoms Root Causes Best Practices

Ambiguous communications

Undetected inconsistencies

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change

Modules don’t fit

IBM

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

Praktek 1: Mengembangkan Secara Berulang

(Develop Iteratively)

Profil Risiko Waterfall vs Iterative

Praktek 2: Mengelola Kebutuhan

http://share.its.ac.id/pluginfile.php/10959/course/section/4551/Requirements%20Def%20Toolbox%20website.jpg

http://2.bp.blogspot.com/-8A0bZCN58gQ/UgURjvomuUI/AAAAAAAAADo/VH5ae-ivjTE/s1600/Agile+Software+Requirements.jpg

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.

Aspek Dalam Pengelolaan Kebutuhan

• Menganalisis permasalahan

• Memahami kebutuhan pengguna

• Mendefinisikan sistem

• Mengelola lingkup (scope)

• Menyempurnakan (refine) definisi sistem

• Mengelola perubahan kebutuhan

Peta Teritori

Praktek 3: Menggunakan Arsitektur Berbasis

Komponen

Apakah yang dimaksud dengan komponen?

Mengapa menggunakan komponen?

Contoh Komponen Elektronika

http://www.technologystudent.com/images5/sw6.gif

http://www.electronicsandyou.com/blog/wp-content/uploads/2013/06/Electronic-Components.jpg

Contoh Diagram Komponen Suatu Perangkat Lunak

http://www.cragsystems.co.uk/uml_tutorial/graphics/componentdiag.jpg

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

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

Praktek 4: Memodelkan Secara Visual

*Menggunakan UML

http://agilemodeling.com/images/models/useCaseDiagram.jpg

http://www.tutorialspoint.com/images/uml_class_diagram.jpg

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

Pemodelan Visual Dengan UML

Dynamic

Diagrams

Static

Diagrams

Activity Diagrams

Models

Sequence Diagrams

Collaboration Diagrams

Statechart Diagrams

Deployment Diagrams

Component Diagrams

Object Diagrams

Class Diagrams

Use-Case Diagrams

• Allows multiple views

• Provides precise syntax and semantics

Pemodelan Visual Dengan UML

Praktek 5: Memeriksa Kualitas Secara Terus Menerus

Mengapa harus diperiksa terus menerus?

http://rs1img.memecdn.com/Quality-Control_o_97721.jpg

Cost

Development Phases

Software problems are

100 to 1000 times more costly

to find and repair after deployment

Cost to Repair Software

Cost of Lost Opportunities

Cost of Lost Customers

Dimensi Pengujian Pada Kualitas

Pengujian dilakukan pada setiap iterasi

UML Model and

Implementation

Tests

Iteration 1

Test Suite 1

Iteration 2

Test Suite 2

Iteration 4

Test Suite 4

Iteration 3

Test Suite 3

Praktek 6: Mengelola Perubahan

Apa yang dikelola?

• Mengamankan tempat kerja para pengembang

• Otomatisasi integration/build management

• Pengembangan secara paralel

ALERT REPORT

Workspace

Management

Process

Integration

Parallel

Development

Build

Management

Configuration Management is more than just check-in and check-out.

Aspek – Aspek Dalam Pengelolaan Perubahan

• Change Request Management (CRM)

• Configuration Status Reporting

• Configuration Management (CM)

• Change Tracking

• Version Selection

• Software Manufacture

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

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

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

Perubahan Fokus Pada Setiap Fase (1)

Perubahan Fokus Pada Setiap Fase (2)

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

Berapa banyaknya iterasi yang dibutuhkan?

Rule of thumb: 6 + 3 iterasi

Phase Low Medium High

Inception 0 1 1

Elaboration 1 2 3

Construction 1 2 3

Transition 1 1 2

Total 3 6 9

Kondisi yang mengakibatkan bertambahnya jumlah

iterasi

Inception Working with new functionality

Unknown business environment

Highly volatile scope

Make-buy decisions

Elaboration Working with new system

environment (new architectural features)

Untested architectural elements

Need for system prototypes

Construction Lots of code to write and verify

New technology or development tools

Transition Need for alphas and betas

Conversions of customer base

Incremental delivery to customers

Referensi

Best Practices of Software Engineering and Introduction to

RUP – IBM Rational Software