Mengatasi Progressive Elaboration dalam

mengelola proyek perangkat lunak

Konferensi Nasional Informatika (KNIF)

ITB, Bandung, 23 November 2011

Presentasi makalah pada Konferensi Nasional Informatika 2011.

Mengatasi Progressive Elaboration dalam

mengelola proyek perangkat lunak

Adib Toriq (adib.toriq@gmail.com),

Adi Mulyanto (adi.m@stei.itb.ac.id)

Studi Menunjukkan...

Dua dari tiga proyek perangkat lunak dapat

dikategorikan gagal (Chaos Report, 2009)

Hampir semua publikasi tentang kesuksesan

perangkat lunak mencantumkan kata “fail”

(Vogelezang, 2007)

Sifat Perangkat lunak yang :

Abstrak

Progressive

Elaboration

lingkup yg luas

Progressive ElaborationProgressive elaboration adalah sifat dari pengembangan perangkat lunak

dimana pelengkapan informasi sejalan dengan proyek.

Pada awal proyek informasi yang didapat masih sedikit. Seiring dengan

berjalannya proyek informasi yang didapat semakin rinci dan lengkap

Progressive Elaboration

dapat menyebabkan.......

Melebarnya lingkup perangkat lunak

Bertambahnya

Resource....

BIAYA MEMBENGKAK!

Sebelum Akhirnya

PROYEK GAGAL!!!

Progressive Elaboration

Tidak bisa dihindari

Bisa diminimalisir

Manajemen perangkat lunak yang konkrit

Mengatasi curse of knowledge pada

komunikasi verbal

Menentukan Measureable

Organization Value (MOV)

Mendekomposisi proyek secara efektif

Menentukan deliverable dan

Acceptence untuk tiap sub-proyek

1

2

3

4

Mengantisipasi

curse of knowledge

pada komunikasi verbal

Concrete Project Management

1

Curse of knowledge adalah suatu kondisi dimana ketika

seseorang berusaha untuk menyampaikan informasi, dengan

tanpa disadari orang tersebut menganggap lawan bicaranya

memiliki latar belakang pengetahuan yang sama

dengannnya

“

“heath brothers

Curse Of Knowledge

Contoh Curse Of Knowledge

klien “mas developer, tolong buatkan data mining bisa

? “

pengembang “bisa pak. Data Mining buat apa ya?”

Klien “untuk mengolah data penelitian”

pengembang (agak curiga dengan definisi data mining menurut

klien).

“Data mining-nya untuk apa ya pak?”

klien “Pokoknya bisa tambah, hapus, edit, delete data

penelitian. Cuman itu saja.”

pengembang “Oh....bisa pak.”

Menghilangkan asumsi

Menginformasikan potensi terjadinya

curse of knowledge kepada semua

anggota tim proyek

Menentukan

Measureable Organization

Value (MOV)

Concrete Project Management

2

Measureable Organization Value (MOV) adalah suatu pernyataan

kesuksesan proyek perangkat lunak dimana pernyataan tersebut harus

memiliki sifat:

Terukur,

Singkat (tidak lebih dari dua kalimat)

Memiliki nilai tambah pada organisasi,

Disetujui oleh pengembang dan klien, dan

Dapat diverivikasi.

Measureable Organization Value

Contoh MOV yg Baik

Our goal is to land a

man on the moon and

return him safely by the

end of the decade

“

“John F Kennedy (1960)

Our goal is to land a man on the moon and return him

safely by the end of the decade““

Kriteria kesuksesan yang pertama dari proyek

ini adalah mendaratkan manusia ke

bulan, bukan mendaratkan robot atau simpanse

Our goal is to land a man on the moon and return him

safely by the end of the decade““

Kriteria kesuksesan kedua adalah manusia

yang dikirimkan ke bulan harus kembali

dengan selamat

Our goal is to land a man on the moon and return him

safely by the end of the decade““

Kriteria kesuksesan yang ketiga adalah

proyek ini harus selesai sebelum akhir

dekade (1970).

Mengapa menggunakan MOV?

Sebagai pemandu dalam mengambil

keputusan

Sebagai patokan dalam merespon

permintaan perubahan lingkup klien

Sebagai alat untuk mengukur

kesuksesan proyek

1

2

3

Mendekomposisi Proyek

dengan efektif

Concrete Project Management

3

You can’t manage what you can’t measure““Tom DeMarco

Dengan memecah proyek menjadi sub-proyek,

tim proyek memiliki gambaran yang lebih jelas

tentang apa yang harus dilakukan.

“

“

Pendekatan dalam dekomposisi proyek

Menggunakan standar pedoman khusus seperti standar

departement of defense (DOD)

Mengadaptasi dari proyek yang serupa

Dengan melihat proyek secara global lalu membaginya menjadi

proyek-proyek kecil. Menentukan deliverable dan milesone untuk

Dengan menemukan proyek-proyek kecil lalu menariknya ke atas

menjadi proyek yang lebih umum.

Dengan menggunakan mind map

Membagi proyek berdasarkan deliverablenya

1

2

3

4

5

6

Menentukan

Deliverable dan

Acceptance untuk tiap

sub-proyek

Concrete Project Management

4

Acceptance

Deliverable

bukti pencapaian selesainya suatu sub-proyek dan kemana

harus meminta persetujuan.

Contoh : disetujuinya protoype oleh klien.

produk yang dihasilkan setelah selesainya sub proyek.

Contoh : Prototype, modul, dokumen

Keuntungan menentukan deliverable dan acceptance

Manajer proyek dapat melihat “apa saja yang

sudah didapatkan” dan bukan hanya “apa saja

yang sudah dilakukan”.

mengurangi peluang terjadinya kebingungan

dan miskomunikasi di antara anggota team

masing-masing anggota dapat melihat target

produk apa yang harus dihasilkan dan harus

kemana untuk mendapatkan persetujuan bahwa

produk tersebut sudah benar

1

2

3

KesimpulanPada makalah ini telah dipaparkan empat langkah untuk mengurangi

progressive elaboration :

Menghilangkan “curse of knowledge” pada komunikasi verbal,

Menentukan Measureable Organization Value (MOV),

Mendekomposisi proyek dengan efektif, dan

Menentukan deliverability dan acceptance untuk tiap sub-

proyek

Referensi1 Vogelezang, Frank. Scope Management - How Uncertain is Your Certainty. In International Workshop on

Software Measurement (IWSM) ( 2007), International Workshop on Software Measurement (IWSM).

2 Galorath, Daniel D and Evans, Michael W. Software Sizing, Estimation and Risk Management. Aurbach

Publication (2006).

3 PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK

guide). Project Management Institute, Newtown Square, 2008.

4 Wysocki, Robert K and McGary, Rudd. Effective Project Management. Wiley, Canada, 2003.

5 Heath, Chip and Heath, Dan. Made To Stick. Random House, New York, 2007.

6 Marchewka, Jack T. Project Information Management. 2007.

7 Demarco, T. Why Does Software Cost So Much. Dorset House Publishing, 1995.

8 Schwable, Katty. Information Technology Project Management. cengage, canada, 2011.

9 FINNISH INFORMATION PROCESSING ASSOCIATION (FIPA). Tivi-projektien johtaminen (ICT Project

Management). FiPA, Helsinski, 2005.

Photo Credit

• http://www.flickr.com/photos/the-g-uk/3890598744/sizes/o/in/photostream/

• http://www.flickr.com/photos/thehappyrobot/1413968365/sizes/z/in/photostream/

• http://www.flickr.com/photos/emagic/56206868/sizes/l/in/photostream/

• http://www.flickr.com/photos/43492691@N00/516724172/

• http://images.fineartamerica.com/images-small/broken-light-bulb-michal-boubin.jpg

• http://jdshankles.files.wordpress.com/2011/10/4800broken_lamp.jpg

• http://www.flickr.com/photos/37108241@N00/61056391/

• http://fc01.deviantart.net/fs71/i/2010/311/b/0/burst_light_bulb_ii_by_linsenschuss-d32c8ve.jpg

Terima Kasih