UNIT 4 Kelompok 6 - The Work Breakdown Structure[1]

Strukur Rincian KerjaPert 11-14

Matakuliah : M0134 - Project ManagementTahun : 2010

Information Technology Project Management – Third Edition

By Jack T. MarchewkaNorthern Illinois University

Copyright 2009 John Wiley & Sons, Inc. all rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without the express permission of the copyright owner is unlawful. Request for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages caused by the use of these programs or from the use of the information contained herein.

The Work Breakdown Structure (WBS)

Chapter 6

Learning Objectives

Mengembangkan struktur rincian kerja. Jelaskan perbedaan antara penyampaian dan

tonggak sejarah.Jelaskan dan menerapkan beberapa metode estimasi proyek. Ini termasuk teknik Delphi, tinju waktu, estimasi top-down, dan estimasi bottom-up.

Menjelaskan dan menerapkan beberapa estimasi pendekatan rekayasa perangkat lunak. Ini termasuk baris kode (LOC), analisis fungsi titik, COCOMO, dan heuristik.

Project Time ManagementPMBOK®

Definisi Kegiatan Mengidentifikasi kegiatan apa yang harus diselesaikan untuk

menghasilkan ruang lingkup proyek yang deliverable.

Aktivitas sequencing Menentukan apakah kegiatan dapat diselesaikan secara berurutan atau

paralel dan setiap dependensi yang mungkin ada di antara mereka.

Aktivitas sumber daya estimasi Mengidentifikasi jenis sumber daya (orang, teknologi, fasilitas, dll) dan

kuantitas sumber daya yang dibutuhkan untuk melaksanakan kegiatan proyek.

Kegiatan estimasi durasi Memperkirakan waktu untuk menyelesaikan setiap aktivitas

Jadwal pembangunan. Berdasarkan perkiraan ketersediaan sumber daya, kegiatan, urutan, dan

waktu, jadwal untuk seluruh anggaran dapat dikembangkan.

Jadwal kontrol Memastikan bahwa proses dan prosedur yang tepat pada tempatnya

untuk mengontrol perubahan pada jadwal proyek.

Struktur Pekerjaan Terinci(WBS)

WBS merupakan dekomposisi atau penguraian secara logis dari pekerjaan yang harus dilakukan dan berfokus pada bagaimana produk, jasa, atau hasil dibagi secara alami. Ini adalah garis besar pekerjaan apa yang dilakukan.

PMBOK Guide® (17).

Paket Pekerjaan

Deliverables versus Milestones

Deliverables. Berwujud, produk kerja diverifikasi. Laporan, presentasi, prototipe, dll

Milestones. Peristiwa Penting atau prestasi. Penerimaan kiriman atau tahap penyelesaian.

Keuntungan Milestones Menjaga fokus tim Merngurangi resiko proyek dengan bertindak

sebagai Cruxes (bukti konsep). Pengendalian kualitas

Pengembangan WBS Paket kerja adalah pengembangan untuk masing-masing tahapan

dan penyerahan, didefinisikan dalam Deliverable Bagan Struktur (DSC).

Deliverable: Hasil pengujian laporan.

Logical Kegiatan:1. Review rencana uji dengan klien sehingga stakeholder adalah

kunci yang jelas tentang apa yang akan diuji, bagaimana tes akan dilakukan, dan ketika tes akan dilakukan.

2. Melaksanakan tes yang dituangkan dalam rencana.3. Setelah hasil tes dikumpulkan, kita perlu untuk menganalisa.4. Hasilnya harus diringkas dalam bentuk laporan dan presentasi

kepada klien.5. Jika semua berjalan dengan baik, klien akan sign-off atau

menyetujui hasil tes dan kemudian kita bisa melanjutkan ke tahap pelaksanaan proyek. Jika tidak, maka kita perlu untuk membahas dan memperbaiki masalah.

Contoh Jadwal Kerja Rinci

WBS harus mengikuti konsep paket kerja

The WBS…

Harus "deliverable-oriented". Harus mendukung proyek MOV Memiliki cukup detail untuk mendukung

perencanaan dan kontrol. Harus melibatkan orang-orang yang akan

melakukan pekerjaan. Harus mencakup siklus belajar dan pelajaran

masa lalu harus dipelajari.

Estimasi pertanyaan

Bagaimana Anda memperkirakan?

Apa yang akan Anda perkirakan?

Darimana Anda memulai?

Estimasi teknik - pendekatan proyek Manajemen Tradisional

Guesstimating. Teknik delphi. Waktu tinju. Top - Down. Bottom - Up. Analog perkiraan (pengalaman lalu). Pemodelan parametrik (statistik).

Guestimating

Estimasi dengan menebak atau hanya mengambil nomor dari udara bukan cara terbaik untuk mendapatkan jadwal proyek dan anggaran. Sayangnya, banyak manajer proyek berpengalaman cenderung mengira-ngira angka, atau menebak pada perkiraan, karena cepat dan mudah.

Delphi Technique

Melibatkan beberapa, anonim ahli. Setiap ahli membuat perkiraan. Perkiraan dibandingkan.

Jika dekat, bisa rata-rata. Jika tidak, lakukan iterasi lain sampai konsensus dicapai.

Time Boxing (Waktu Tinju)

Sebuah "kotak" waktu yang dialokasikan untuk suatu aktivitas tertentu, tugas, atau deliverable.

Bisa fokus jika tim digunakan secara efektif.

Dapat menurunkan moral tim jika tidak digunakan secara efektif.

Top-Down

Manajer Terbaik & menengah menentukan jadwal proyek secara keseluruhan & / atau biaya.

Manajer tingkat yang lebih rendah diharapkan untuk menjadwalkan kerusakan / perkiraan anggaran ke dalam kegiatan tertentu (WBS).

Bottom-Up

Jadwal & anggaran dibangun dari WBS.

Mulai dengan orang-orang yang akan melakukan pekerjaan.

Jadwal & anggaran adalah keseluruhan kegiatan-kegiatan rinci & biaya.

Analog perkiraan

Mirip dengan pendekatan Top-Down. Gunakan informasi dari sebelumnya, proyek

serupa sebagai dasar untuk estimasi.

Parametric Modeling

karakteristik proyek Gunakan (parameter) dalam model matematis untuk estimasi.

Contoh: $ 50 / LOC berdasarkan: Bahasa pemrograman. Tingkat keahlian. Ukuran & kompleksitas.

6.2 Test Results Report6.2.1 Review test plan with client 1

day6.2.2 Carry out test plan 5

days6.2.3 Analyze results 2

days6.2.4 Prepare test results report and presentation 3

days6.2.5 Present test results to client 1

day6.2.6 Address any software issues or problems 5

days

Estimates are made for each activity in the WBSPerkiraan dibuat untuk setiap kegiatan dalam WBS.

Bagaimana kita datang dengan perkiraan tersebut? Dengan menggunakan teknik, atau kombinasi teknik, dengan pengecualian guestimating!

Teknik Memperkirakan - Software pendekatan rekayasa.

Baris kode (LOC). Fungsi poin. COCOMO. Heuristik.

Software engineering teknik yang terfokus pada estimasi ukuran sistem yang akan dikembangkan.

Mengestimasi penentu deliverable terbesar dari proyek - Sistem aplikasi.

Analisa Fungsi Titik

Allan Albrecht, IBM - 1979. Sintetik metrik. Teknologi Independen. IFPUG standar (www.ifpug.org). 5 elemen primer.

Input. Keluaran. Pertanyaan. Logical file. Antarmuka.

Batas aplikasi untuk analisis fungsi titik.

  Complexity  

Low Average High Total

Internal Logical Files

(ILF)_3 x 7 = 21 _2 x 10 = 20 _1 x 15 = 15 56

External Interface Files

(EIF)__ x 5 = __ _2 x 7 = 14 __ x 10 = __ 14

External Input (EI) _3 x 3 = 9 _5 x 4 = 20 _4 x 6 = 24 53

External Output (EO) _4 x 4 = 16 _2 x 5 = 10 _1 x 7 = 7 33

External Inquiry (EQ) _2 x 3 = 6 _5 x 4 = 20 _3 x 6 = 18 44

  Total Unadjusted Function Points (UAF)200

General System Characteristic Degree of Influence

Data Communications 3

Distributed Data Processing 2

Performance 4

Konfigurasi berat yang digunakan 3

Tingkat transaksi 3

On-line Data Entry 4

End User Efficiency 4

Online Update 3

Complex Processing 3

Reusability 2

Installation Ease 3

Operational Ease 3

Multiple Sites 1

Facilitate Change 2

Total Degrees of Influence 40

Value Adjustment Factor VAF = (TDI * 0.01) + .65 VAF = (40 * .01) + .65 = 1.05

Total Adjusted Function Points = FP = UAF * VAF FP = 200 * 1.05 = 210

Language Average Source LOC per Function Pont

Average Source LOC for a 210 FP Application

Access 38 7,980

Basic 107 22,470

C 128 26,880

C++ 53 11,130

COBOL 107 22,470

Delphi 29 6,090

Java 53 11,130

Machine Language 640 134,440

Visual Basic 5 29 6,090

Source: http://www.spr.com/library/0langtbl.htm

COCOMO

Konstruktif Model Biaya Dikembangkan oleh Barry Boehm, Telah diperpanjang untuk COCOMO II http://sunset.usc.edu/csse/research/COCOMOII

/cocomo_main.html

Model COCOMO (Usaha)

Organik – Rutin Orang Bulan = 2.4 * KDSI1.05

Embedded – Challenging Orang Bulan = 3.6 * KDSI1.20

Semi-Terpisah – Middle Orang Bulan = 3.0 * KDSI1.12

COCOMO – Contoh Usaha Semi-Detached

10,600 Java LOC = 200 FP * 53

Person Months = 3.0 * KDSI1.12

= 3.0 * (10.6) 1.12

= 42.21

Model COCOMO - Durasi Organic

Duration = 2.5 * Effort0.38

Semi-Detached Duration = 2.5 * Effort0.35

Embedded Duration = 2.5 * Effort0.32

Contoh COCOMO DurasiDuration = 2.5 * Effort0.35

= 2.5 *(42.21)0.35

= 9.26 months

People Required = Effort / Duration= 42.21 / 9.26= 4.55

Heuristik (Rules of Thumb)

Ketika software melakukan penjadwalan tugas:

1 / 3 - Perencanaan1 / 6 - Coding1 / 4 - Uji Komponen dan uji sistem awal.1 / 4 - Sistem uji, semua komponen di tangan.

Bencana utama software biasanya ditaburkan dalam tiga bulan pertama saat software dimulai. Penjadwalan Hasty, komitmen tidak rasional, teknik estimasi tidak profesional, dan kecerobohan dari fungsi manajemen proyek merupakan faktor yang cenderung untuk memperkenalkan masalah utama. Setelah proyek lurches maju secara membabi buta menuju sebuah tanggal pengiriman yang mustahil, sisa bencana akan pasti hampir terjadi.

T. Capers Jones, 1988 Page 120

Hukum Brook’s

Menambahkan tenaga kerja untuk nanti membuat sebuah software proyek yang terlambat.

The Man Month

People

Mon

ths

Mon

ths

People

Sisa vs jumlah pekerja, tugas sempurna partitionable - yaitu, Tidak ada komunikasi di antara mereka misalnya, menuai gandum.

Ketika tugas yang tidak dapat dipartisi karena kendala sekuensial, penerapan upaya lebih tidak berpengaruh pada jadwal.

Menambahkan Orang

Meningkatkan jumlah usaha yang diperlukan. Pekerjaan & gangguan

melakukan evaluasi ulang.

Pelatihan orang baru. Ditambahkan

pergaulan.

Apa yang bisa menyebabkan estimasi yang tidak akurat?

Lingkup perubahan. Mengabaikan tugas. Kurangnya pengembang-

pengguna komunikasi. Kurangnya pemahaman

tentang tujuan proyek Kurangnya analisis...

Tidak ada metodologi (miskin). Perubahan dalam tim. Red tape. Kurangnya kontrol proyek. Tidak mengidentifikasi atau

pemahaman dampak risiko.

Faktor lain yang perlu dipertimbangkan ketika memperkirakan.

Tingkat di mana persyaratan bisa berubah. Pengalaman & kemampuan tim proyek. Proses atau metode yang digunakan dalam pengembangan. kegiatan khusus yang akan dilakukan. Bahasa pemrograman atau alat pengembangan yang akan

digunakan. Kemungkinan jumlah bug atau cacat & metode

penghapusan. Ergonomi lingkungan atau ruang kerja. Geografis pemisahan tim di lokasi. Jadwal tekanan ditempatkan pada tim.

Bagaimana perkiraan diperbaiki?

Pengalaman! Pelajaran. Praktik terbaik.

Revisi atau perbaikan Pengawasan Fokus pada hasil Pengendalian

Case Study

Discussion: case, Marchewka, pp.177-178

Bina Nusantara University

44