Pada pertemuan kedua ini, 23 Februari 2012, disampaikan 6
hal yang terbukti membawa keberhasilan dalam pengembangan sistem software. Adanya gejala dan akar
permasalahan yang muncul dalam software
development inilah yang
melatarbelakangi munculnya best practise
yang akan mengatasi akar permasalahan yang ada.
Survey terhadap project-project IT di Amerika
dan Kanada pada tahun 1997 dilaporkan bahwa project
yang selesai tuntas (completed)
berjumlah 68% sedangkan yang di-cancelled
berjumlah 32%. Dari project yang completed,
yang on-budget 17% dan yang over-budget 51%.
Ada 9 gejala kegagalan dalam
pengembangan software:
- Inaccurate understanding of end-user needs
- Inability to deal with changing requirements
- Modules that don’t fit together
- Software that’s hard to maintain or extend
- Late discovery of serious project flaws
- Poor software quality
- Unacceptable software performance
- Team members in each other’s way, unable to reconstruct, who changed what, when, where, why
- An untrustworthy build-and-release process
Yang akan diatasi oleh best practise adalah akar permasalahannya
(root causes) bukan gejala-gejalanya
(symptoms). Berikut adalah penjelasan
dari 6 best practise.
Practice 1:
Develop Software Iteratively
Pengembangan software secara iteratif berguna untuk
mengakomodasi perubahan requiremement,
secara progresif mengintegrasi elemen-elemen ke dalam end-product dan menekan resiko lebih dini. Proses pengembangan
dapat di-improve dan di-refine sepanjang siklus, masukan di awal
dari end-user dan reuse fasilitas akan menghasilkan arsitektur yang sangat kuat.
Root
Causes
|
Solutions
|
|
√
|
Insufficient requirements
|
Enables and encourages
user feedback
|
√
|
Ambiguous communications
|
Serious misunderstandings
evident early in the life cycle
|
Brittle architectures
|
||
√
|
Overwhelming complexity
|
Development focuses on
critical issues
|
√
|
Subjective
assessment
|
Objective assessment thru
testing
|
√
|
Undetected
inconsistencies
|
Inconsistencies detected
early
|
√
|
Poor
testing
|
Testing starts earlier
|
√
|
Waterfall development
|
Risks identified and
addressed early
|
Uncontrolled change
|
||
Insufficient
automation
|
||
Practice 2:
Manage Requirements
Memahami problem berarti sudah mencapai 50%
keberhasilan. Mengelola kebutuhan adalah langkah-langkah sistematis untuk
melakukan elicitasi, mengorganisasi, mendokumentasi, mengelola, establishing and maintaining agreement on
the changing requirements of a software application. Pemahaman terhadap
kebutuhan itu penting supaya kita menghasilkan deliverable yang sesuai dengan keinginan end-user.
Root Causes
|
Solutions
|
|
√
|
Insufficient requirements
|
A disciplined approach is built into requirements management
|
√
|
Ambiguous communications
|
Communications are based on defined requirements
|
Brittle architectures
|
||
√
|
Overwhelming complexity
|
Requirements can be prioritized, filtered, and traced
|
√
|
Subjective
assessment
|
Objective assessment of functionality and performance
|
√
|
Undetected
inconsistencies
|
Inconsistencies are more easily detected RM tool provides a repository
for requirements, attributes and tracing, with automatic links to documents
|
√
|
Poor
testing
|
Objective assessment of functionality and performance
|
Waterfall development
|
||
Uncontrolled change
|
||
√
|
Insufficient
automation
|
Inconsistencies are more easily detected RM tool provides a repository
for requirements, attributes and tracing, with automatic links to documents
|
Practice 3: Use
Component-Base Architectures
Arsitektur software adalah sebuah struktur yang
terdiri dari komponen-komponen yang saling terintegrasi. Arsitektur software meliputi keputusan penting
tentang organisasi sistem software.
Berikut adalah root causes dan solutions-nya.
Root
Causes
|
Solutions
|
|
Insufficient requirements
|
||
Ambiguous communications
|
||
√
|
Brittle architectures
|
Components facilitate
resilient architectures
|
Reuse of commercially
available components and frameworks is facilitated
|
||
√
|
Overwhelming complexity
|
Modularity enables
separation of concerns
|
Subjective
assessment
|
||
Undetected
inconsistencies
|
||
Poor
testing
|
||
Waterfall development
|
||
√
|
Uncontrolled change
|
Components provide a
natural basis for configuration
management
|
√
|
Insufficient
automation
|
Visual modeling tools
provide automation for componentbased design
|
Practice 4:
Visually Model Software
Memvisualkan
model software menggunakan UML (Unified Modeling Language). UML berperan
untuk: specifying, visualizing, constructing, documenting
artefak dari software-intensive system.
Menurut UP, yang disebut arsitektur adalah 5 sisi pandang (4+1 view model).
1 untuk kebutuhan user dan 4 untuk kebutuhan internal.
Berikut adalah root causes dan solutions-nya.
Root
Causes
|
Solutions
|
|
√
|
Insufficient requirements
|
Use-cases and scenarios
unambiguously specify behavior
|
√
|
Ambiguous communications
|
Models capture software
designs unambiguously
|
√
|
Brittle architectures
|
Non-modular or inflexible
architectures are exposed
|
√
|
Overwhelming complexity
|
Unnecessary detail hidden
when appropriate
|
Subjective
assessment
|
||
√
|
Undetected
inconsistencies
|
Unambiguous designs reveal
inconsistencies more rapidly
|
√
|
Poor
testing
|
Application quality starts
with good design
|
Waterfall development
|
||
Uncontrolled change
|
||
√
|
Insufficient
automation
|
Visual modeling tools
provide support for UML modeling
|
Practice 5:
Verify Software Quality
Permasalahan software, cost-nya bisa mencapai 100 sampai 1000 kali lipat jika telah
dikembangkan. Jika permasalahan ditemukan di awal, maka cost-nya relatif lebih kecil. Pengembangan secara iterative memungkinkan pengujian yang continue.
Berikut adalah root causes dan solutions-nya.
Root
Causes
|
Solutions
|
|
Insufficient requirements
|
||
Ambiguous communications
|
||
Brittle architectures
|
||
Overwhelming complexity
|
||
√
|
Subjective
assessment
|
Testing provides objective
project status assessment
|
√
|
Undetected
inconsistencies
|
Objective assessment
exposes inconsistencies early
|
√
|
Poor
testing
|
Testing and verification
are focused on high risk areas
|
Defects are found earlier
and are less expensive to fix
|
||
Waterfall development
|
||
Uncontrolled change
|
||
√
|
Insufficient
automation
|
Automated testing tools
provide testing for reliability, functionality and performance
|
Practice 6: Control Changes to Software
Yang harus dikontrol antara lain: multiple developers, multiple teams, multiple
sites, multiple iterations, multiple releases, multiple projects, dan multiple
platforms sehingga tidak menyebabkan chaos.
Berikut adalah root causes dan solutions-nya.
Root
Causes
|
Solutions
|
|
√
|
Insufficient requirements
|
Requirements change
workflow is defined and repeatable
|
√
|
Ambiguous communications
|
Change requests facilitate
clear communication
|
Brittle architectures
|
||
√
|
Overwhelming complexity
|
Isolated workspaces reduce
interference from parallel work
|
√
|
Subjective
assessment
|
Change rate statistics are
good metrics for objectively assessing project status
|
√
|
Undetected
inconsistencies
|
Workspaces contain all
artifacts, facilitating consistency
|
Poor
testing
|
||
Waterfall development
|
||
√
|
Uncontrolled change
|
Change
propagation is controlled
|
√
|
Insufficient
automation
|
Changes maintained in a
robust, customizable system
|
6 best practise
disesain untuk memungkinkan high-performance
teams menjadi berhasil dalam software
projects mereka.
Tiga hal yang diperlukan untuk suksesnya
software development adalah Team-Based Development, Modeling Language dan Unified Process.
