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
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 Symptoms
Root Causes
Needs not met
Insufficient requirements
Requirements churn
Ambiguous communications
fit Modules don’t fit
Brittle architectures
Hard to maintain
Overwhelming complexity
Late discovery
Undetected inconsistencies
Poor quality
Poor testing
Poor performance
Subjective assessment
Colliding developers
Waterfall development
Build-and-release
Uncontrolled change Insufficient automation
Best Practices Develop Iteratively Manage Requirements Use Component Architectures
Model Visually (UML) Continuously Verify Quality Manage Change IBM
Praktek - Praktek Terbaik (versi IBM)
1. 2. 3. 4. 5. 6.
Mengambangkan secara berulang (develop iteratively) Mengelola kebutuhan Menggunakan arsitektur berbasis komponen Memodelkan secara visual Memeriksa kualitas secara terus menerus 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.electronicsandyou.com/blog/wp-content/uploads/2013/06/Electronic-Components.jpg
http://www.technologystudent.com/images5/sw6.gif
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://www.tutorialspoint.com/images/uml_class_diagram.jpg
http://agilemodeling.com/images/models/useCaseDiagram.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 • Allows multiple views • Provides precise syntax and semantics
Sequence Diagrams
Collaboration Diagrams
Dynamic Diagrams
Statechart Diagrams
Static Diagrams Class Diagrams
Use-Case Diagrams
Object Diagrams
Component Diagrams
Models
Activity Diagrams
Deployment Diagrams
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
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
Dimensi Pengujian Pada Kualitas
Pengujian dilakukan pada setiap iterasi Iteration 1
Iteration 2
Iteration 3
Iteration 4
Test Suite 1
Test Suite 2
Test Suite 3
Test Suite 4
UML Model and Implementation
Tests
Praktek 6: Mengelola Perubahan
Apa yang dikelola?
• Mengamankan tempat kerja para pengembang • Otomatisasi integration/build management • Pengembangan secara paralel Parallel Development
Workspace Management
Configuration Management is more than just check-in and checkout.
Process Integration
REPORT ALERT
Build Management
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
3
6
9
Total
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
Referensi
Best Practices of Software Engineering and Introduction to RUP – IBM Rational Software
