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.

Presentasi berjudul: "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."— Transcript presentasi:

1

2 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.

3 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 him became more intense. Carl began to feel that his job was on the line.

4 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.

5 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?

6 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

7 "A whole year to build a house here? No problem "Good. Let's get started. I'm in a hurry."

8 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

9 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.

10 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 ?

11 ESTIMATION – GRAPH INITIAL PRODUCT DEFINITION APPROVED PRODUCT DEFINITION REQUIREMENT SPECIFICATION PRODUCT DESIGN SPECIFICATION DETAIL DESIGN SPECIFICATION PRODUCT COMPLETE

12 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.

13 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."

14 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.

15 ESTIMATION – ACTUAL VS ESTIMATION Estimated Schedule “The trick is to try to estimate neither high nor low, but right on the money.”

16 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.

17 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 DALAM RUANG LINGKUP DAN SECARA PERIODIK DIPERBAIKI

18 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

19 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.

20 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