Best Practices of Software Engineering

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:

1. Inaccurate understanding of end-user needs
2. Inability to deal with changing requirements
3. Modules that don’t fit together
4. Software that’s hard to maintain or extend
5. Late discovery of serious project flaws
6. Poor software quality
7. Unacceptable software performance
8. Team members in each other’s way, unable to reconstruct, who changed what, when, where, why
9.  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.

Berikut adalah root causes dan solutions-nya. 

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.

Berikut adalah root causes dan solutions-nya.

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.