15022-7-357516773412

Modul 7 Kuliah MPPL (e-Learning)

I. WORK BREAKDOWN STRUCTURE (WBS)

I. 1. Pendahuluan

Dalam bab terakhir, Anda belajar tentang mendefinisikan dan mengelola

proyek-lingkup pekerjaan yang harus dilakukan dalam rangka mencapai Moy

proyek atau tujuan. Mendefinisikan dan pemahaman apa yang harus Anda

lakukan adalah langkah penting pertama untuk menentukan bagaimana Anda

akan melakukan pekerjaan yang harus dilakukan. Dalam bab ini, kita akan

fokus pada menentukan tugas-tugas atau kegiatan yang perlu dilakukan

dalam rangka untuk menyelesaikan semua ruang lingkup terkait kiriman

seperti yang dijanjikan. Selain itu, kita juga perlu untuk memperkirakan atau

meramalkan jumlah waktu masing-masing kegiatan sehingga kita dapat

menentukan semua jadwal proyek.

Manajemen Proyek Tubuh Knowledge (PMBOK ®) menyebut time project

managament yang fokus pada proses yang diperlukan untuk membuat jadwal

proyek dan untuk memastikan bahwa proyek selesai tepat waktu.

Sebagaimana didefinisikan dalam panduan 'PMBOK, manajemen waktu

proyek meliputi:

o Definisi Aktivitas -mengidentifikasi kegiatan apa harus

diselesaikan untuk membuat ruang lingkup deliverable proyek.

o Urutan Aktivitas -menentukan apakah kegiatan dapat diselesaikan

secar serial atau paralel dan setiap dependensi yang mungkin ada

di antara mereka.

o Estimasi Sumber daya Aktivitas -mengidentifikasi jenis sumber

daya (orang, teknologi, fasilitas, dll) dan jumlah sumber daya yang

dibutuhkan untuk melaksanakan kegiatan proyek.

o Estimasi durasi Aktivitas - memperkirakan waktu untuk

menyelesaikan setiap aktivitas.

o Pembuatan Jadwal didasarkan pada ketersediaan sumber daya,

kegiatan-kegiatan,urutan kegiatan, dan perkiraan waktu, jadwal

untuk seluruh anggaran dapat dikembangkan

Manajemen Proyek Perangkat LunakMujiono Sadikin ST.,MT

Pusat Pengembangan Bahan AjarUniversitas Mercu Buana

‘12 1

o Kontrol Jadwal - memastikan bahwa proses yang tepat dan

prosedur tempat dalam rangka untuk mengontrol perubahan pada

jadwal proyek.

I. 2. WBS = Work Breakdown Structure

WBS merepresentasikan dekomposisi lojik dari suatu pekerjaan yang harus

diselesaikan pada suatu proyek untuk menghasilkan produk, jasa, atau hasil -

hasil yang lain yang secara natural terbagi - bagi.

Paket Pekerjaan (Work Package)

WBS dibagi – bagi menjadi bagian yang lebih kecil sehingga mudah dikelola

dan dikendalikan. Komponen ini disebut dengan paket pekerjaan (Work

Package)

Deliverables & Milestone

Milestone adalah event /kejadian / produk yang signifikan yang menyediakan

suatu bukti bahwa suatu delivarble telah selesai atau suatu fase dalam proyek

secara formal telah diserah terimakan. Contoh milestone misalnya:

penandantanganan SKPL, penyerahan DPPL, atau penyelesaian prototype

aplikasi.

Pembuatan WBS.

WBS bisa dibuat dengan beberapa versi dan tergantung sudut pandang.

WBS bisa dibuat berdasarkan produk/deliverable dari suatu proyek. WBS bisa

juga dibuat berdasarkan metodologi/tahapan, misalnya dalam SDLC. WBS

dapat dibuat berdasarkan DSC (Deliverable Structure Chart). Dari DSC ini



‘12 2

(lihat gambar di bawah) kemudian diturunkan aktivitas – aktivitas untuk

membuat masing – masing komponen dalam DSC.

Asumsikan bahwa kita telah mengidentifikasi dan membahas beberapa

kegiatan yang kita butuhkan lakukan dalam rangka untuk menghasilkan

dokumen hasil tes, sebagai berikut:

Tinjauan rencana uji dengan klien sehingga stakeholder kunci menjadi

jelas baginya untuk apa dan apa yang kita akan kita uji, bagaimana kita

akan melakukan tes, dan kapan tes akan dilakukan. Review ini dapat

dilakukan dengan alasan kesopanan atau karena kita membutuhkan

dukungan tertentu dari organisasi klien dan, karena itu, Harus

memberitahu mereka ketika dukungan yang akan dibutuhkan.

Setelah kita memberitahu klien bahwa kita akan menguji sistem, pada

dasarnya kita melaksanakan tes digariskan dalam rencana uji.

Setelah kita mengumpulkan hasil tes, kita perlu menganalisanya.

Setelah kita lakukan analisa atas hasil, kita perlu untuk meringkasnya

dalam bentuk laporan dan presentasi kepada klien.

Jika semua berjalan dengan baik, maka klien akan menyetujui atau signoff

pada hasil tes.



‘12 3

Kemudian, kita bisa melanjutkan ke tahap implementasi proyek kami. Jika

semua tidak berjalan dengan baik, kita harus mengatasi dan memperbaiki

masalah. Perlu diingat, bahwa fase tes tidak lengkap hanya karena kita

telah mengembangkan tesmerencanakan dan membuat laporan

pengujian. Klien akan menandatangani pada tes hasilnya hanya

jika sistem tersebut memenuhi kualitas standar tertentu yang telah

ditentukan.

Gambar 6.3 memberikan contoh dari WBS dengan rincian ditampilkan

untuk hanya untuk fase uji coba.



‘12 4

WBS berorientasi pada Deliperable. Ingat, fokus dari proyek

adalah untuk menghasilkan sesuatu, bukan hanya pada menyelesaikan

sejumlah tertentu kegiatan. Meskipun WBS tidak menyediakan untuk

setiap perulangan eksplisit, beberapa kegiatan hubungan mungkin harus

diulang sampai tonggak tercapai. Sebagai contoh, perangkat lunak

pengujian mungkin menemukan sejumlah masalah atau bug yang

membuat sistem perangkat lunak tidak dapat diterima klien. Akibatnya,

masalah ini harus diatasi dan tetap dan tes yang sama mungkin harus

dilakukan lagi. Proses ini dapat diulang beberapa kali (sambil

mengkonsumsi jadwal proyek dan anggaran) sampai standar kualitas

terpenuhi.

WBS Harus Mendukung MOV Proyek. WBS harus mencakup tugas-

tugas atau kegiatan yang memungkinkan untuk pengiriman penyerahan

proyek / penyelesaian deliverable.

Pembuatan WBS Harus melibatakan Orang yang Akan Melakukan

Kerja(WBS)

Salah satu cara untuk memastikan bahwa WBS memiliki tingkat detail

yang tepat adalah untuk memastikan bahwa orang-orang yang melakukan

pekerjaan yang terlibat dalam pembangunan. Seseorang yang memiliki

pengalaman dan keahlian dalam bidang tertentu mungkin memiliki rasa

yang lebih baik untuk kegiatan apa perlu dilakukan untuk menghasilkan

suatu proyek tertentu deliverable. Meskipun manajer proyek bertanggung

jawab untuk memastikan bahwa WBS realistis dikembangkan, orang-

orang yang harus melaksanakan kegiatan dan tugas-tugas mungkin lebih

berkomitmen untuk rencana jika mereka terlibat dalam pembangunan.

Siklus Belajar dan Lessons Learned Dapat Mendukung Pengembangan

WBS Dengan menggunakan konsep siklus belajar, tim proyek dapat fokus

pada apa yang mereka tahu (fakta), apa yang mereka pikir mereka tahu

(asumsi), dan apa yang mereka butuhkan untuk mengetahui (penelitian)

dalam rangka untuk mengembangkan WBS lebih berguna. Pelajaran dari



‘12 5

proyek-proyek sebelumnya dapat membantu dalam memastikan bahwa

WBS dan rencana proyek berikutnya adalah realistis dan lengkap. .

I. 3. Estimasi Proyek

Setelah deliverable proyek dan aktivitas telah didefinisikan, langkah

berikutnya dalam mengembangkan jadwal proyek dan anggaran untuk

memperkirakan durasi setiap kegiatan itu. Salah satu kegiatan yang sulit-yang

paling penting-dan dalam manajemen proyek adalah memperkirakan waktu

yang diperlukan untuk menyelesaikan tugas tertentu. Karena sumber daya

umumnya melakukan tugas tertentu, biaya yang terkait dengan sumber daya

tertentu harus dialokasikan sebagai bagian dari waktu yang dibutuhkan untuk

menyelesaikan tugas itu. Perkiraan waktu untuk menyelesaikan tugas tertentu

akan memiliki bantalan langsung terhadap anggaran proyek juga.

Sebagai T. Capers Jones (Jones 1998) menunjukkan:

Guesstimating

Awal permasalahan software yang besar biasanya dimulai dalam tiga bulan

pertama terhitung proyek perangkat lunak. Penjadwalan tergesa-gesa,

komitmen rasional, teknik memperkirakan tidak profesional, dan kecerobohan

dari fungsi manajemen proyek adalah faktor yang cenderung untuk

memperkenalkan masalah terminal. Setelah proyek membabi buta lurches

maju menuju tanggal pengiriman mustahil, sisa bencana akan terjadi hampir

pasti (120).

Delphi Technique

Diundang beberapa ahli yang mengerti di bidangnya. Kemudian para ahli

tersebut membuat konsesus solusi atas permasalahan yang diajukan. Dalam

hal ini adalah estimasi proyek.



‘12 6

Time Boxing

Adalah suatu teknik yang dianut jika telah dialokasikan waktu tertentu yang

fiexed untuk menyelesaikan pekerjaan (proyek).

I. 4. Software Engineering & S/W Metrice

Rekayasa Perangkat Lunak fukus pada prosess, tool, dan metode

pembangunan sauatu pendekatan kualitas dalam pembuatan s/w. Sedangkan

S/W metrice merupakan salah satu disiplin rekayasa perangkat lunak yang

fokus pada bagaimana mengukur nilai dari S/W seobyektif mungkin. Estimasi

nilai S/W ditentukan oleh ukursn, kompleksitas, serta batasan dan pengaruh.

Seperti gambar di bawah.



‘12 7

Line Of Code (LOC)

Menghitung jumlah baris kode dalam program komputer adalah perangkat

lunak yang paling tradisional dan banyak digunakan ukuran metrik untuk

aplikasi produk ini juga yang paling kontroversial.

Meskipun menghitung baris kode tampaknya bersifat intuitif, 1.000 LOC

program Java akan sepuluh kali lebih besar dari sebuah program Java 100



‘12 8

LOC, menghitung LOC tidaklah semudah itu. Pertama, apa yang dianggap

sebagai LOC? Apakah kode termasuk komentar?

Bagaimana mendeklarasikan variabel? Apakah dihitung sebagai LOC?

Selain itu, programmer berpengalaman cenderung untuk menulis kode lebih

ringkas dari programmer pemula.

Function Point Analysis(FPA)

Pada tahun 1979, Allan Albrecht dari IBM mengusulkan gagasan FPA pada

konferensi yang diselenggarakan oleh IBM di Monterey, California (Albrecht

1979). FPA adalah metrik sintetis, mirip dengan yang digunakan setiap

hari, seperti jam, kilo, ton, mil laut, derajat Celcius, dan sebagainya.

FPA didasarkan pada evaluasi dari lima data dan jenis transaksional yang

mendefinisikan batas aplikasi seperti yang diilustrasikan pada Gambar 6.5.:

Internal Logical File (ILF)- ILF adalah file logis yang menyimpan data

di dalam batas aplikasi. Sebagai contoh, setiap entitas dalam sebuah

Entity Relationship-Diagram (ERD) akan dianggap sebagai ILE



‘12 9

Kompleksitas dari ILF dapat diklasifikasikan sebagai rendah, rata-rata,

atau tinggi berdasarkan jumlah elemen data dan elemen data

subkelompok dipelihara oleh ILE Sebuah contoh dari subkelompok

akan menjadi pelanggan baru bagi entitas yang disebut pelanggan.

Contoh elemen data akan nomor pelanggan, nama, alamat, nomor

telepon, dan sebagainya. Singkatnya, ILFs dengan elemen data yang

lebih sedikit dan subkelompok akan kurang kompleks daripada ILFs

dengan unsur-unsur data yang lebih dan subkelompok.

Eksternal Interface File (EIF), sama dengan ILF. ILF merupakan file

dikelola oleh system di luar batas aplikasi. Kriteria kompleksitas EIF

sama dengan ILF

External Input (EI), EI mengacu pada proses atau data transaksional

yang berasal dari luar aplikasi

• Output Eksternal (EO)- EO adalah sebuah proses atau transaksi

yang memungkinkan data untuk keluar dari batas aplikasi. Contoh EO

meliputi laporan, pesan konfirmasi, total yang diperoleh atau dihitung,

dan grafik atau diagram. Data ini bisa pergi ke layar, printer, atau

aplikasi lainnya. Setelah jumlah Eos yang dihitung, mereka dinilai

berdasarkan pada kompleksitas mereka, seperti input eksternal (El).

Permintaan Eksternal (EQ)-Process atau transaksi yang mencakup

kombinasi dari input dan output untuk mengambil data baik dari dalam

file atau dari file eksternal untuk aplikasi. Persamaan tidak

memperbarui atau mengubah data yang disimpan dalam file. Mereka

hanya membaca informasi ini. Query dengan logika pengolahan yang

berbeda atau input yang berbeda atau format output dihitung sebagai

single EQ.Once Persamaan diidentifikasi, mereka diklasifikasikan

berdasarkan kompleksitas mereka sebagai rendah, rata-rata, atau

tinggi, sesuai dengan jumlah file kembali enced dan jumlah elemen

data yang disertakan dalam query.



‘12 10

ILF, EIF, EI, EO, EQ selanjutnya digunakan untuk menghitung rate

kompleksitas yang disebut Unadjusted Function Point (UAF). Sebagai contoh

setelah dilakukan review terhadap aplikasi diperoleh asumsi sebagai berikut :

ILF : 3 Low, 2 Average, 1 complex

EIF : 2 Average

EI : 3 Low, 5 Average, 4 complex

EO : 4 Low, 2 average, 1 complex

EQ : 2 Low, 5 average, 3 complex

Berikutnya menghitung Value Adjusted Factor (VAF). VAF dihitung

berdasarkan Degree of Influence (DI), seringkali disebut dengan PCA

(Processing Complexity Adjustment). PCA diturunkan dari 40 GSC seperti

tabel 6.2



‘12 11

Setiap GSC diberi penilaian berdasarkan skala 0 ...5 sbb:

0 = not present or no influence

1 = incidental influence

2 = moderate influence

3 = average influence

4 = significant influence

5 = strong influence



‘12 12

Pendekatan berikutnya adalah melakukan konversi dari nilai FPA ke Number

Line of Code yang ekivalen. Tabel berikut menunjukkann ekivalensi antare

FPA dan LOC.



‘12 13

Daftar Pustaka Wajib:

1. Marchewka, Jack T., 2006, Information Technology Project

Management, John Wiley & Sons, Inc, ISBN-13 978-0-471-71539-9

2. Pressman, R. 2000. Software Engineering : A Practioners Approach

5TH Editon. Boston : Mc Graw Hill.

Anjuran :1. Hughes, B., and Cotteral, M. 1999. Software Project Management

Second Edition. London : McGraw Hill.

2. ForsBerg, K., dkk. 1996. Visualizing Project Management 2TH. New

York : John Willey & sons.



‘12 14

Documents

15022-7-357516773412