ESTIMATION-1 « Batam Education Support’s Blog
ESTIMATION – CASE
STUDY
Carl had been put in charge of version 1 of Giga –Safe’s
inventory control system (ICS). He had a general idea of the
capabilities desired when he attended the first meeting of the
oversight committee for the project. Bill was the head of the
oversight committee. “Carl, how long is ICS 1.0 going to take?”
he asked.
“ I think it will take about 9 months, but that’s just a rough
estimate at this point,” Carl said.
“that’s not going to work,”Bill said. “I was hoping you’d say 3 or
4 months. We absolutely need to bring that system in within 6
months. Can you do it in 6?”
“I’m not sure,”Carl said honestly.”I’d have to look the project
more carefully, but I can try to find a way to get it done in 6.”
“Treat 6 months as a goal then, “Bill said. “That’s what it’s got to
be, anyway.” The rest of committee agreed.
By week 5, additional work on the product concept had
convinced Carl that the project would take closer to his original
9-month guess than to 6 months, but he thought that with some
luck he still might be able to complete it in 6. He didn’t want to
be branded a troublemaker, so he decided to sit tight.
ESTIMATION – CASE
STUDY
STUDI KASUS (lanjutan):
Carl’s team made steady progress, but requirements analysis
took longer than they had hoped. “They were now almost 4
months into what was supposed to be a 6-month project.
“there’s no way we can do the rest of the work we have to do in
3 months, “he told Bill. He told Bill he needed a 2-month
schedule slip and rescheduled the project to take 8-months.
A few weeks later, Carl realized that design wasn’t proceeding as
quickly as he had hoped either. “Implement the parts you can do
easily,” he told the team. “We’ll worry about the rest of the parts
when get to them.”
Carl met with the oversight committee. “We’re now 7 months
into our 8-month project. Detailed design is almost complete,
and we’re making good progress. But we can’t complete the
project in 8 months.” Carl announced his second schedule slip,
this time to 10 months. Bill grumbled and asked Carl to look for
ways to bring the schedule back to around 8 months.
At the 9-month mark, the team had completed detailed design,
but coding still hadn’t begun on some modules. It was clear that
Carl coulddn’t make the 10-month schedule either. He
announced the third schedule slip number – to 12 months. Bill’s
face turned red when Carl announced the slip, and pressure from
ESTIMATION – CASE
STUDY
STUDI KASUS (lanjutan):
Coding proceeded fairly well, but a few areas needed redesign
and reimplementation. The team hadn’t coordinated design
details in those areas well, and some of their implementation
conflicted. At the 11-month oversight committee meeting, Carl
announced the fourth schedule slip – to 13 months . Bill became
livid, “Do you have any idea what you’re doing? He yelled. “You
obviously don’t have any idea! You obviously don’t have any
idea when the project is going to be done! I’ll tell you when it’s
going to be done! It’s going to be done by the 13-month mark, or
you’re going to be out of a job! I’m tired of being jerked around
by you software guys! You and your team are going to work 60
hours a week until you deliver! Carl felt his blood pressure rise,
especially since Bill had backed him into an unrealistic schedule
in the first place. But he knew that with four schedule slips under
his belt, he had no credibility left. He felt that he had to knuckle
under to mandatory overtime or he would lose his job.
Carl told his team about the meeting. They worked hard and
managed to deliver the software in just over 13 months.
Additional implementation uncovered additional design flaws,
but with everyone working 60 hours a week, they delivered the
product through sweat and sheer willpower.
ESTIMATION – CASE
STUDY
STUDI KASUS (PERTANYAAN):
1.Apa masalah utama yang ada pada kasus di atas?
2.Identifikasi kelemahan-kelemahan manajemen (Perencanaan,
Pengorganisasian, Kepemimpinan, Pengendalian) yang timbul
pada saat Carl menangani proyek tersebut!
3.Bila anda diangkat sebagai manajer proyek tersebut apa yang
akan anda lakukan?
ESTIMATION –
FUZZYNESS
ESTIMASI ADALAH PEKERJAAN YANG SULIT, KARENA
MENGANDUNG KETIDAKPASTIAN.
KITA HARUS MEMASTIKAN BAHWA SELURUH LEVEL MANAJEMEN
TELAH MENGETAHUI DENGAN PASTI MENGENAI PROYEK YANG
AKAN KITA LAKSANAKAN.
LEVEL FUZZYNESS -> LIHAT GAMBAR BERIKUT
"A whole year to
build
a house here?
No problem
"Good. Let's
get
started. I'm in
a hurry."
ESTIMATION – SAY
“It is the mark of an
instructed mind
to rest satisfied
with the degree of
precision •which the
nature of a subject
admits, and not to
seek exactness when
only an approximation
of the truth
is possible...”
Aristotle
ESTIMATION –
REFINEMENT
PENGEMBANGAN SOFTWARE ADALAH PROSES PENGHALUSAN
•
TINGKAT AKURASI YANG BIASA DAPAT DITERIMA OLEH
PIHAK MANAJEMEN ADALAH 10% DARI ESTIMASI
ANGGARAN.
•
PENGHALUSAN KONSEP DIMULAI DARI PERNYATAAN
KEBUTUHAN, RANCANGAN AWAL DAN SETERUSNYA
HINGGA PEMROGRAMAN.
ESTIMATION –
REFINEMENT
BEBERAPA HAL YANG HARUS DIPERHATIKAN DALAM PROSES
PENGHALUSAN
•
APAKAH PELANGGAN BUTUH FUNGSI “X” ?
•
APAKAH HARGA FUNGSI YANG DIBUTUHKAN MURAH ATAU
MAHAL ?
•
BILA SEKARANG DIBUTUHKAN, APAKAH NANTINYA MAU
YANG MAHAL UNTUK VERSI BERIKUTNYA?
•
BAGAIMANA FUNGSI TERSEBUT DIRANCANG ?
•
SAMPAI TINGKATAN MANA KUALITAS FUNGSI TERSEBUT ?
•
BERAPA LAMA UNTUK MEN-DEBUG DAN MENGKOREKSI
ERROR ?
•
BERAPA LAMA UNTUK MENGINTEGRASIKAN FUNGSI
TERSEBUT DENGAN FUNGSI LAINNYA ?
ESTIMATION – GRAPH
INITIAL
PRODUCT
DEFINITION
APPROVED
PRODUCT
DEFINITION
REQUIREMENT
SPECIFICATION
PRODUCT
DESIGN
SPECIFICATION
DETAIL DESIGN
SPECIFICATION
PRODUCT
COMPLETE
ESTIMATION – CONTROL
HUBUNGAN ESTIMASI DENGAN KENDALI
•
KEBANYAKAN PELANGGAN PERANGKAT LUNAK AWALNYA
MEMBUTUHKAN SESUATU LEBIH DARI YANG
SEBENARNYA
MEREKA BUTUHKAN.
•
PENGEMBANG PERANGKAT LUNAK SELALU DIHADAPKAN
PADA PILIHAN ANTARA KEAKURASIAN ESTIMASI DENGAN
KENDALI PROYEK.
ESTIMATION –
COOPERATION
KERJASAMA
•
PERLU DISAMPAIKAN KEPADA PEMAKAI DI TAHAP MANA
SAJA PENGEMBANG DAPAT MELAKUKAN ESTIMASI
DENGAN CUKUP AKURAT.
•
PEMAKAI PERLU DIBERITAHUKAN TINDAKAN / KEGIATAN
SELANJUTNYA
•
STRATEGI YANG AKAN DIPAKAI UNTUK MELAKSANAKAN
KEGIATAN TERSEBUT.
•
BILA ADA PERUBAHAN DARI KEBUTUHAN, RANCANGAN
AWAL RINCI, TERMASUK PERUBAHAN ANGGARAN.
TELL THEM "AS SOON AS I KNOW, YOU'LL KNOW."
ESTIMATION – REALITY
APPROACH
DEKATKAN ESTIMASI DENGAN KENYATAAN
•
BILA PEMAKAI INGIN MEMPERCEPAT, HINDARKAN
PENGEMBANG DARI KESALAHAN ESTIMASI YANG
TERLALU RENDAH ATAU MEMBERIKAN ESTIMASI YANG
MENYESATKAN.
•
TARGET PIMPINAN PROYEK ADALAH MENCOBA
MELAKUKAN ESTIMASI YANG TEPAT DAN SESUAI
DENGAN
ANGGARAN.
ESTIMATION – ACTUAL
VS ESTIMATION
Estimated
Schedule
“The trick is to try to estimate neither high nor low, but right on the
money.”
ESTIMATION – POINT
HAL YANG HARUS DIPERHATIKAN DALAM MELAKUKAN ESTIMASI
•
TIDAK ADA YANG DAPAT MENENTUKAN DENGAN TEPAT BERAPA
BIAYA YANG AKAN DIKELUARKAN KECUALI DAPAT TEPAT
MENGETAHUI APA YANG DIKEHENDAKI.
•
BILA INGIN BUAT ANGGARAN, BUATLAH KARAKTERISTIK PRODUK
YANG LENTUR
•
PROSES PENGEMBANGAN ADALAH PENGHALUSAN BERTAHAP
•
ESTIMASI DAPAT DIPERHALUS SEIRING DENGAN PELAKSANAAN
PROYEK
•
BEDAKAN PENGERTIAN AKURASI DENGAN PRESISI
AKURASI : SEBERAPA DEKAT DENGAN TETAPAN TERTENTU
PRESISI : SEBERAPA SIGNIFIKAN ANGKA DIGIT SEBUAH PENGUKURAN
PADA ESTIMASI PERANGKAT LUNAK, KESALAHAN PRESISI MERUPAKAN
MUSUH DARI AKURASI.
ESTIMATION – PROCESS
PROSES ESTIMASI
PROSES UNTUK MENCAPAI KEAKURATAN DALAM MENJADWAL
PENGEMBANGAN :
1.
ESTIMASIKAN UKURAN DARI PRODUK (SEBERAPA BESAR
FUNGSI YANG HARUS ADA)
2.
ESTIMASIKAN EFFORTS (YANG PERNAH DILAKUKAN)
3.
ESTIMASI JADWAL
4.
SAJIKAN
ESTIMASI
YANG
DIDAPAT
LINGKUP
DAN SECARA PERIODIK DIPERBAIKI
DALAM
RUANG
ESTIMATION – SIZE
MENGHITUNG ESTIMASI
DAPAT DILAKUKAN MELALUI BEBERAPA CARA :
1.
MENGGUNAKAN PENDEKATAN ALGORITMA (BESARNYA
PROGRAM ATAU FUNGSI YANG AKAN DIBUAT)
2.
BERDASARKAN DESKRIPSI PROGRAM (SCREENS,
DIALOGS, FILES, DATABASE TABLES)
3.
BANDINGKAN DENGAN PROYEK SEJENIS BILA TELAH
PUNYA PENGALAMAN
ESTIMATION – FUNCTION
POINT
ESTIMASI MENGGUNAKAN FUNCTION POINT
•
DIGUNAKAN PADA AWAL PROYEK
•
LEBIH MUDAH MENDASARKAN DARI SPESIFIKASI KEBUTUHAN
•
JUMLAH FUNCTION POINT SEBUAH PROGRAM DILIHAT DARI
JUMLAH DAN KOMPLEKSITAS SETIAP ITEM BERIKUT :
•
1. •
INPUT
2. •
OUTPUT
3. •
INQUIRIES
4. •
LOGICAL INTERNAL FILES
5. •
EXTERNAL INTERFACE FILES
KALIKAN JUMLAH FUNCTION POINT DENGAN ITEM ( INPUT,
OUTPUT, INQUIRIES, LOGICAL INTERNAL FILES, EXTERNAL INTERFACE
FILES ) YANG DISEBUTKAN DI ATAS.
ESTIMATION – TIPS
TIPS UNTUK MEMBUAT ESTIMASI
• AVOID OFF-THE-CUFF ESTIMATES.
• ALLOW TIME FOR THE ESTIMATE, AND PLAN IT.
• USE DATA FROM PREVIOUS PROJECTS.
• USE DEVELOPER-BASED ESTIMATES
• ESTIMATE BY WALK-THROUGH
• ESTIMATE BY CATEGORIES
• ESTIMATE AT A LOW LEVEL OF DETAIL
• DON'T OMIT COMMON TASKS
• USE SOFTWARE ESTIMATION TOOLS
• USE SEVERAL DIFFERENT ESTIMATION TECHNIQUES, AND COMPARE
THE RESULTS.
• CHANGE ESTIMATION PRACTICES AS THE PROJECT PROGRESSES
STUDY
Carl had been put in charge of version 1 of Giga –Safe’s
inventory control system (ICS). He had a general idea of the
capabilities desired when he attended the first meeting of the
oversight committee for the project. Bill was the head of the
oversight committee. “Carl, how long is ICS 1.0 going to take?”
he asked.
“ I think it will take about 9 months, but that’s just a rough
estimate at this point,” Carl said.
“that’s not going to work,”Bill said. “I was hoping you’d say 3 or
4 months. We absolutely need to bring that system in within 6
months. Can you do it in 6?”
“I’m not sure,”Carl said honestly.”I’d have to look the project
more carefully, but I can try to find a way to get it done in 6.”
“Treat 6 months as a goal then, “Bill said. “That’s what it’s got to
be, anyway.” The rest of committee agreed.
By week 5, additional work on the product concept had
convinced Carl that the project would take closer to his original
9-month guess than to 6 months, but he thought that with some
luck he still might be able to complete it in 6. He didn’t want to
be branded a troublemaker, so he decided to sit tight.
ESTIMATION – CASE
STUDY
STUDI KASUS (lanjutan):
Carl’s team made steady progress, but requirements analysis
took longer than they had hoped. “They were now almost 4
months into what was supposed to be a 6-month project.
“there’s no way we can do the rest of the work we have to do in
3 months, “he told Bill. He told Bill he needed a 2-month
schedule slip and rescheduled the project to take 8-months.
A few weeks later, Carl realized that design wasn’t proceeding as
quickly as he had hoped either. “Implement the parts you can do
easily,” he told the team. “We’ll worry about the rest of the parts
when get to them.”
Carl met with the oversight committee. “We’re now 7 months
into our 8-month project. Detailed design is almost complete,
and we’re making good progress. But we can’t complete the
project in 8 months.” Carl announced his second schedule slip,
this time to 10 months. Bill grumbled and asked Carl to look for
ways to bring the schedule back to around 8 months.
At the 9-month mark, the team had completed detailed design,
but coding still hadn’t begun on some modules. It was clear that
Carl coulddn’t make the 10-month schedule either. He
announced the third schedule slip number – to 12 months. Bill’s
face turned red when Carl announced the slip, and pressure from
ESTIMATION – CASE
STUDY
STUDI KASUS (lanjutan):
Coding proceeded fairly well, but a few areas needed redesign
and reimplementation. The team hadn’t coordinated design
details in those areas well, and some of their implementation
conflicted. At the 11-month oversight committee meeting, Carl
announced the fourth schedule slip – to 13 months . Bill became
livid, “Do you have any idea what you’re doing? He yelled. “You
obviously don’t have any idea! You obviously don’t have any
idea when the project is going to be done! I’ll tell you when it’s
going to be done! It’s going to be done by the 13-month mark, or
you’re going to be out of a job! I’m tired of being jerked around
by you software guys! You and your team are going to work 60
hours a week until you deliver! Carl felt his blood pressure rise,
especially since Bill had backed him into an unrealistic schedule
in the first place. But he knew that with four schedule slips under
his belt, he had no credibility left. He felt that he had to knuckle
under to mandatory overtime or he would lose his job.
Carl told his team about the meeting. They worked hard and
managed to deliver the software in just over 13 months.
Additional implementation uncovered additional design flaws,
but with everyone working 60 hours a week, they delivered the
product through sweat and sheer willpower.
ESTIMATION – CASE
STUDY
STUDI KASUS (PERTANYAAN):
1.Apa masalah utama yang ada pada kasus di atas?
2.Identifikasi kelemahan-kelemahan manajemen (Perencanaan,
Pengorganisasian, Kepemimpinan, Pengendalian) yang timbul
pada saat Carl menangani proyek tersebut!
3.Bila anda diangkat sebagai manajer proyek tersebut apa yang
akan anda lakukan?
ESTIMATION –
FUZZYNESS
ESTIMASI ADALAH PEKERJAAN YANG SULIT, KARENA
MENGANDUNG KETIDAKPASTIAN.
KITA HARUS MEMASTIKAN BAHWA SELURUH LEVEL MANAJEMEN
TELAH MENGETAHUI DENGAN PASTI MENGENAI PROYEK YANG
AKAN KITA LAKSANAKAN.
LEVEL FUZZYNESS -> LIHAT GAMBAR BERIKUT
"A whole year to
build
a house here?
No problem
"Good. Let's
get
started. I'm in
a hurry."
ESTIMATION – SAY
“It is the mark of an
instructed mind
to rest satisfied
with the degree of
precision •which the
nature of a subject
admits, and not to
seek exactness when
only an approximation
of the truth
is possible...”
Aristotle
ESTIMATION –
REFINEMENT
PENGEMBANGAN SOFTWARE ADALAH PROSES PENGHALUSAN
•
TINGKAT AKURASI YANG BIASA DAPAT DITERIMA OLEH
PIHAK MANAJEMEN ADALAH 10% DARI ESTIMASI
ANGGARAN.
•
PENGHALUSAN KONSEP DIMULAI DARI PERNYATAAN
KEBUTUHAN, RANCANGAN AWAL DAN SETERUSNYA
HINGGA PEMROGRAMAN.
ESTIMATION –
REFINEMENT
BEBERAPA HAL YANG HARUS DIPERHATIKAN DALAM PROSES
PENGHALUSAN
•
APAKAH PELANGGAN BUTUH FUNGSI “X” ?
•
APAKAH HARGA FUNGSI YANG DIBUTUHKAN MURAH ATAU
MAHAL ?
•
BILA SEKARANG DIBUTUHKAN, APAKAH NANTINYA MAU
YANG MAHAL UNTUK VERSI BERIKUTNYA?
•
BAGAIMANA FUNGSI TERSEBUT DIRANCANG ?
•
SAMPAI TINGKATAN MANA KUALITAS FUNGSI TERSEBUT ?
•
BERAPA LAMA UNTUK MEN-DEBUG DAN MENGKOREKSI
ERROR ?
•
BERAPA LAMA UNTUK MENGINTEGRASIKAN FUNGSI
TERSEBUT DENGAN FUNGSI LAINNYA ?
ESTIMATION – GRAPH
INITIAL
PRODUCT
DEFINITION
APPROVED
PRODUCT
DEFINITION
REQUIREMENT
SPECIFICATION
PRODUCT
DESIGN
SPECIFICATION
DETAIL DESIGN
SPECIFICATION
PRODUCT
COMPLETE
ESTIMATION – CONTROL
HUBUNGAN ESTIMASI DENGAN KENDALI
•
KEBANYAKAN PELANGGAN PERANGKAT LUNAK AWALNYA
MEMBUTUHKAN SESUATU LEBIH DARI YANG
SEBENARNYA
MEREKA BUTUHKAN.
•
PENGEMBANG PERANGKAT LUNAK SELALU DIHADAPKAN
PADA PILIHAN ANTARA KEAKURASIAN ESTIMASI DENGAN
KENDALI PROYEK.
ESTIMATION –
COOPERATION
KERJASAMA
•
PERLU DISAMPAIKAN KEPADA PEMAKAI DI TAHAP MANA
SAJA PENGEMBANG DAPAT MELAKUKAN ESTIMASI
DENGAN CUKUP AKURAT.
•
PEMAKAI PERLU DIBERITAHUKAN TINDAKAN / KEGIATAN
SELANJUTNYA
•
STRATEGI YANG AKAN DIPAKAI UNTUK MELAKSANAKAN
KEGIATAN TERSEBUT.
•
BILA ADA PERUBAHAN DARI KEBUTUHAN, RANCANGAN
AWAL RINCI, TERMASUK PERUBAHAN ANGGARAN.
TELL THEM "AS SOON AS I KNOW, YOU'LL KNOW."
ESTIMATION – REALITY
APPROACH
DEKATKAN ESTIMASI DENGAN KENYATAAN
•
BILA PEMAKAI INGIN MEMPERCEPAT, HINDARKAN
PENGEMBANG DARI KESALAHAN ESTIMASI YANG
TERLALU RENDAH ATAU MEMBERIKAN ESTIMASI YANG
MENYESATKAN.
•
TARGET PIMPINAN PROYEK ADALAH MENCOBA
MELAKUKAN ESTIMASI YANG TEPAT DAN SESUAI
DENGAN
ANGGARAN.
ESTIMATION – ACTUAL
VS ESTIMATION
Estimated
Schedule
“The trick is to try to estimate neither high nor low, but right on the
money.”
ESTIMATION – POINT
HAL YANG HARUS DIPERHATIKAN DALAM MELAKUKAN ESTIMASI
•
TIDAK ADA YANG DAPAT MENENTUKAN DENGAN TEPAT BERAPA
BIAYA YANG AKAN DIKELUARKAN KECUALI DAPAT TEPAT
MENGETAHUI APA YANG DIKEHENDAKI.
•
BILA INGIN BUAT ANGGARAN, BUATLAH KARAKTERISTIK PRODUK
YANG LENTUR
•
PROSES PENGEMBANGAN ADALAH PENGHALUSAN BERTAHAP
•
ESTIMASI DAPAT DIPERHALUS SEIRING DENGAN PELAKSANAAN
PROYEK
•
BEDAKAN PENGERTIAN AKURASI DENGAN PRESISI
AKURASI : SEBERAPA DEKAT DENGAN TETAPAN TERTENTU
PRESISI : SEBERAPA SIGNIFIKAN ANGKA DIGIT SEBUAH PENGUKURAN
PADA ESTIMASI PERANGKAT LUNAK, KESALAHAN PRESISI MERUPAKAN
MUSUH DARI AKURASI.
ESTIMATION – PROCESS
PROSES ESTIMASI
PROSES UNTUK MENCAPAI KEAKURATAN DALAM MENJADWAL
PENGEMBANGAN :
1.
ESTIMASIKAN UKURAN DARI PRODUK (SEBERAPA BESAR
FUNGSI YANG HARUS ADA)
2.
ESTIMASIKAN EFFORTS (YANG PERNAH DILAKUKAN)
3.
ESTIMASI JADWAL
4.
SAJIKAN
ESTIMASI
YANG
DIDAPAT
LINGKUP
DAN SECARA PERIODIK DIPERBAIKI
DALAM
RUANG
ESTIMATION – SIZE
MENGHITUNG ESTIMASI
DAPAT DILAKUKAN MELALUI BEBERAPA CARA :
1.
MENGGUNAKAN PENDEKATAN ALGORITMA (BESARNYA
PROGRAM ATAU FUNGSI YANG AKAN DIBUAT)
2.
BERDASARKAN DESKRIPSI PROGRAM (SCREENS,
DIALOGS, FILES, DATABASE TABLES)
3.
BANDINGKAN DENGAN PROYEK SEJENIS BILA TELAH
PUNYA PENGALAMAN
ESTIMATION – FUNCTION
POINT
ESTIMASI MENGGUNAKAN FUNCTION POINT
•
DIGUNAKAN PADA AWAL PROYEK
•
LEBIH MUDAH MENDASARKAN DARI SPESIFIKASI KEBUTUHAN
•
JUMLAH FUNCTION POINT SEBUAH PROGRAM DILIHAT DARI
JUMLAH DAN KOMPLEKSITAS SETIAP ITEM BERIKUT :
•
1. •
INPUT
2. •
OUTPUT
3. •
INQUIRIES
4. •
LOGICAL INTERNAL FILES
5. •
EXTERNAL INTERFACE FILES
KALIKAN JUMLAH FUNCTION POINT DENGAN ITEM ( INPUT,
OUTPUT, INQUIRIES, LOGICAL INTERNAL FILES, EXTERNAL INTERFACE
FILES ) YANG DISEBUTKAN DI ATAS.
ESTIMATION – TIPS
TIPS UNTUK MEMBUAT ESTIMASI
• AVOID OFF-THE-CUFF ESTIMATES.
• ALLOW TIME FOR THE ESTIMATE, AND PLAN IT.
• USE DATA FROM PREVIOUS PROJECTS.
• USE DEVELOPER-BASED ESTIMATES
• ESTIMATE BY WALK-THROUGH
• ESTIMATE BY CATEGORIES
• ESTIMATE AT A LOW LEVEL OF DETAIL
• DON'T OMIT COMMON TASKS
• USE SOFTWARE ESTIMATION TOOLS
• USE SEVERAL DIFFERENT ESTIMATION TECHNIQUES, AND COMPARE
THE RESULTS.
• CHANGE ESTIMATION PRACTICES AS THE PROJECT PROGRESSES