Perencanaan proyek perangkat lunak meliputi aktivitas awal seperti penetapan ruang lingkup, estimasi sumber daya yang dibutuhkan, dan penjadwalan proyek. Ruang lingkup mendefinisikan cakupan pekerjaan, fungsi, dan batasan proyek. Estimasi melibatkan perkiraan ukuran produk, upaya, jadwal, dan biaya. Struktur pekerjaan terurai (work breakdown structure/WBS) membagi proyek menjadi bagian-bagian lebih kecil

1. INITIATION PROYEK,
MANAJEMEN SCOPE, DAN
PERENCANAAN PROYEK

2. Project Charter
• Typical outline
– Overview
• Business need
• Objectives
• Method or approach
– General scope of work
– Rough schedule & budget
– Roles & responsibilities
– Assumptions

3. Manajemen Proyek Perangkat Lunak dimulai
dengan serangkaian kegiatan yang secara
kolektif disebut PERENCANAAN PROYEK,
Sebelum proyek dapat mulai, manager proyek
dan team harus mengESTIMASIkan :
• Pekerjaan yang harus diselesaikan
• Resources yang dibutuhkan
• Waktu yang dibutuhkan
Pressman

4. TUJUAN PERENCANAAN
PROYEK PERANGKAT LUNAK
Menyediakan sebuah kerangka kerja
yang memungkinkan manager untuk
membuat estimasi yang dapat
dipertanggung jawabkan tentang sumber
daya, biaya, dan jadwal
Pressman

5. www.columbia.edu
Project Planning: A 12 Step Program
1) Set goal and scope
2) Select lifecycle
3) Set org./team form
4) Start team
selection
5) Determine risks
6) Create WBS
7) Identify tasks
8) Estimate size
9) Estimate effort
10)Identify task
dependencies
11)Assign resources
12)Schedule work

6. 12 Langkah Perencanaan Proyek
• Tentukan tujuan dan ruang lingkup
• Pilih siklus hidup
• Setel bentuk org./team
• Mulai pemilihan tim
• Tentukan risiko
• Buat WBS
• Identifikasi tugas
• Perkirakan ukuran
• Perkirakan upaya
• Identifikasi dependensi tugas
• Tetapkan sumber daya
• Jadwalkan pekerjaan

7. MPSI - STIKOM
That’s hard, because you won’t really know until the
project has been complete. However, if you have
experience and follow a systematic approach, generate
estimates using solid historical data, you can feel
confident that you’ve given it your best shot (*Roger S.
Pressman)

8. RUANG LINGKUP PERANGKAT LUNAK
Sebagai aktivitas pertama dalam perencanaan proyek
perangkat lunak, yang mana menggambarkan :
• Data dan Kontrol yang diproses
• Fungsi,
• Kinerja,
• Batasan.
Mendefinisikan dan mengontrol apa yang termasuk dan tidak
termasuk pada proyek
Pressman

9. Penentuan Ruang Lingkup Proyek maka seorang analyst dapat
bertanya (Relatif) :
• Siapa di belakang permintaan kerja ini ?
• Siapa yang akan memakai solusi ini ?
• Apakah yang menjadi keuntungan ekonomi dari sebuah solusi
yang sukses ?
• Adakah sumber daya lain bagi solusi ini ?
• Bagaimanakah anda menandai output yang baik yang akan
dimunculkan oleh sebuah solusi yang baik ?
• Masalah apa yang akan dituju oleh solusi ini ?
• Dapatkah anda gambarkan lingkungan dimana solusi ini dipakai ?
Pressman
RUANG LINGKUP PERANGKAT LUNAK

10. Salah satu proses utama dalam manajemen ruang
lingkup sebuah proyek adalah “DEFINISI RUANG
LINGKUP”, dimana pada bagian ini sebuah proyek yang
besar dibagi kebagian-bagian yang lebih kecil. (WORK
BREAKDOWN STRUCTURE (WBS))
WBS  Tentukan ruang lingkup total proyek
Work Breakdown Structure (WBS) digunakan untuk
menyediakan kerangka kerja untuk mengatur dan
mengelola pekerjaan
Pressman & Kathy
RUANG LINGKUP PERANGKAT LUNAK
SCOPE DEFINITION

11. Work Breakdown Structure
• Hierarchical list of project’s work activities
• 2 Formats
Outline (indented format)
Graphical Tree (Organizational Chart)
• Uses a decimal numbering system
Ex: 3.1.5
• 0 is typically top level
• Includes
Development, Mgmt., and project support tasks
• Shows “is contained in” relationships
• Does not show durations

12. WBS Chart Example

13. WBS Outline Example
0.0 Retail Web Site
1.0 Project Management
2.0 Requirements Gathering
3.0 Analysis & Design
4.0 Site Software Development
4.1 HTML Design and Creation
4.2 Backend Software
4.2.1 Database Implementation
4.2.2 Middleware Development
4.2.3 Security Subsystems
4.2.4 Catalog Engine
4.2.5 Transaction Processing
4.3 Graphics and Interface
4.4 Content Creation
5.0 Testing and Production

14. Work Breakdown Structure
• Task – Oriented / Produk
Membaginya berdasarkan pekerjaan atau dari
major produk  work package (The lowest
level of the WBS)
• Project Phase / Process
Membaginya berdasarkan phase dari project
yang sedang ditangani hingga work package
Kathy Schwalbe Ph.D, PMP

15. Kathy Schwalbe Ph.D, PMP
Product WBS

16. Kathy Schwalbe Ph.D, PMP
Process WBS

17. Kathy Schwalbe Ph.D, PMP
Outline WBS w/Gantt

18. WBS
• List of Activities, not Things
• List of items can come from many sources
– brainstorming, stakeholders, team
• Describe activities using “bullet language”
– Meaningful
• All WBS paths do not have to go to the same
level
• Do not plan more detail than you can manage

19. WBS Techniques
Top-Down
– Start at highest level
– Systematically develop increasing level of detail
– Best if
• The problem is well understood
• Technology and methodology are not new
• This is similar to an earlier project or problem
– But is also applied in majority of situations
Bottom-Up
– Start at lowest level tasks
– Aggregate into summaries and higher levels
– Time consuming
– Needs more requirements complete
– Detailed
Analogy
Base WBS upon that of a “similar” project, Use a template
Kathy Schwalbe Ph.D, PMP

20. Kathy Schwalbe Ph.D, PMP
WBS – Basis of Many Things
• Network scheduling
• Costing
• Risk analysis
• Organizational structure
• Control & Measurement

21. ESTIMASI
Seorang eksekutif yang sedang memimpin suatu
saat ditanya “Apa karakteristik utama yang
penting saat memilih seorang manajer proyek ?“
“Orang yang memiliki kemampuan untuk
mengetahui kesalahan atau apapun berkaitan
dengan proyek yang akan terjadi, sebelum hal
itu benar-benar terjadi”

22. Estimation
“Predictions are hard, especially about
the future”, Yogi Berra
2 Types: Lucky or Lousy?
Setelah Scope Definition
 Estimasi

23. Akurasi estimasi tergantung pada :
• Prediksi ukuran produk yang akan
dikembangkan
• Cara mentranslasikan ukuran ke dalam
effort orang, kalender, kegiatan, serta
biaya
• Sejauh mana rencana proyek
sesuai dengan tim yang sudah ada
• Stabilitas “software requirement”

24. Untuk lebih meningkatkan akurasi estimasi, ada
beberapa pilihan :
• tunda estimasi selambat mungkin
• lakukan estimasi berbasis proyek lain yang mirip dan
pernah dilakukan
• gunakan model empiris untuk memperoleh estimasi biaya
dan effort
Estimasi software tidak pernah dapat dilakukan dengan
tepat, karena melibatkan terlalu banyak variabel : manusia,
teknis, lingkungan pengembangan, politis, dan lain-lain.
Bagaimanapun estimasi ini harus dinyatakan dengan suatu
urutan langkah yang sistematis

25. Estimations
Very difficult to do, but needed often
The four basic steps in software project estimation are:
1. Estimate the size of the development product. This
generally ends up in either Lines of Code (LOC) or
Function Points (FP).
2. Estimate the effort in person-months or person-hours.
3. Estimate the schedule in calendar months.
4. Estimate the project cost in dollars (or local currency)
Kathleen Peters, Independent Software Engineering Consultant, Software Project Estimation

26. Kathleen Peters, Independent Software Engineering Consultant, Software Project Estimation

27. Empirical Estimation Model  The Structure of Estimation Models
Sebuah tipe model estimasi diturunkan dari analisa regresi, dengan
rumus :
Effort (person-month)  A + B x (ev)C
A, B, dan C adalah Konstanta turunan empiris
ev = estimation variable (LOC / FP)
LOC-oriented estimation :
E = 5.2 x (KLOC)0.91
 Walston-Felix model
E = 5.5 x 0.73 x (KLOC)1.16
 Bailey-Basily model
E = 3.2 x (KLOC)1.05
 Boehm Simple Model
E = 5.288 x (KLOC)1.047
 Doty Model (KLOC>9)
FP-oriented estimation :
E = -13.39 + 0.0545 FP  Albrecht and Gaffney model
E = 60.62 x 7.728 x 10-8
FP3
 Kemerer Model
E = 585.7 + 15.12 FP  Matson, Barnett, & Mellichamp

28. Empirical Estimation Model  Model COCOMO
Barry Boehm memperkenalkan model estimasi hirarki
yang dikenal sebagai COCOMO (Constructive Cost
Model)
Ada 3 model :
Model 1. Basic COCOMO, berbasis LOC
Model 2. Intermediate COCOMO, berbasis function of program
size dan set of “cost drivers”
Model 3. Advance COCOMO, menggabungkan semua
karakteristik model 2 dengan dampak cost driver pada setiap
tahap proses engineering.

29. Tiga Kelas Proyek pada COCOMO
Organic Mode. Relatif kecil, tim kecil dengan
pengalaman yang baik pada aplikasi tertentu,
requirement tidak terlalu ketat.
Semi-detached Mode. Kompleksitas dan ukuran
menengah, tim terdiri dari gabungan orang dengan
tingkat pengalaman yang berlainan, req lebih ketat.
Embeded Mode. Software yang memerlukan
hardware, platform software, dan constraint operasional
yang khusus.

30. Basic COCOMO
Step 1 : Hitung Function Point ( FP=CT*[0.65+0.01*(Fi)] )
Step 2 : Memilih bahasa pemrograman lalu hitung
KLOC, berdasarkan estimasi kasar LOC/FP
Step 3 : Hitung Effort dan Development Time
berdasarkan Basic Cocomo Model

31. Programming Language LOC / FP
Assembly 320
C 128
Pascal 90
V.Basic 32
Power Builder 16
SQL 12
C++ 64

32. Basic COCOMO Model
Effort is measured in pm (person-month)  152 Working hours
Waspada dalam menggunakan formula estimasi orang lain dengan lingkungan
yang berbeda dengan kita, termasuk COCOMO !
(Bob Hughes, Software Project Management)

33. Contoh COCOMO
Estimasi :
KLOC = 20
Mode Kelas Proyek : Organic
Avg $/PM = 500
Maka diperoleh Hasil :
Effort = ?
Productivitas = ?
Cost = ?
Dev_time = ?

34. Intermediate COCOMO Model
Mode a b
________________________________________
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
________________________________________
Formula : Effort = a KLOCb
x EAF
EAF = Effort Adjusment Factor (Calculated using
15 cost drivers)
Kategori Cost Driver :
Product, Computer, Personnel, and Project

35. FAKTOR-FAKTOR YANG
MEMPENGARUHI ESTIMASI BIAYA
• Tenaga kerja
• Perangkat Keras dan Perangkat Lunak
(Lingkungan Rekayasa Perangkat Lunak)
• Bepergian untuk tujuan pertemuan / pengujian
• Kompensasi
• Telekomunikasi
• Kursus pelatihan
• Ruang Kantor
• Dll
Kathleen Peters, Independent Software Engineering Consultant, Software Project Estimation