Teknik Estimasi - Panduan Cepat

Estimation adalah proses menemukan perkiraan, atau perkiraan, yang merupakan nilai yang dapat digunakan untuk beberapa tujuan meskipun data masukan mungkin tidak lengkap, tidak pasti, atau tidak stabil.

Estimasi menentukan berapa banyak uang, tenaga, sumber daya, dan waktu yang diperlukan untuk membangun sistem atau produk tertentu. Estimasi didasarkan pada -

  • Data Masa Lalu / Pengalaman Masa Lalu
  • Dokumen / Pengetahuan yang Tersedia
  • Assumptions
  • Risiko yang Diidentifikasi

Empat langkah dasar dalam Estimasi Proyek Perangkat Lunak adalah -

  • Perkirakan ukuran produk pengembangan.
  • Perkirakan upaya dalam orang-bulan atau orang-jam.
  • Perkirakan jadwal dalam bulan kalender.
  • Perkirakan biaya proyek dalam mata uang yang disepakati.

Pengamatan tentang Estimasi

  • Estimasi tidak perlu menjadi tugas satu kali dalam sebuah proyek. Ini dapat terjadi selama -

    • Mendapatkan Proyek.
    • Merencanakan Proyek.
    • Pelaksanaan Proyek sesuai kebutuhan.
  • Ruang lingkup proyek harus dipahami sebelum proses estimasi dimulai. Memiliki Data Proyek historis akan sangat membantu.

  • Metrik proyek dapat memberikan perspektif historis dan masukan berharga untuk menghasilkan perkiraan kuantitatif.

  • Perencanaan membutuhkan manajer teknis dan tim perangkat lunak untuk membuat komitmen awal karena mengarah pada tanggung jawab dan akuntabilitas.

  • Pengalaman masa lalu bisa sangat membantu.

  • Gunakan setidaknya dua teknik estimasi untuk sampai pada estimasi dan rekonsiliasi nilai yang dihasilkan. Lihat Teknik Dekomposisi di bagian selanjutnya untuk mempelajari tentang rekonsiliasi perkiraan.

  • Rencana harus berulang dan memungkinkan penyesuaian seiring berjalannya waktu dan lebih banyak detail diketahui.

Pendekatan Estimasi Proyek Umum

Pendekatan Estimasi Proyek yang banyak digunakan adalah Decomposition Technique. Teknik dekomposisi menggunakan pendekatan divide and conquer. Estimasi Ukuran, Upaya, dan Biaya dilakukan secara bertahap dengan memecah Proyek menjadi Fungsi utama atau Aktivitas Rekayasa Perangkat Lunak terkait.

Step 1 - Memahami ruang lingkup perangkat lunak yang akan dibangun.

Step 2 - Hasilkan perkiraan ukuran perangkat lunak.

  • Mulailah dengan pernyataan ruang lingkup.

  • Menguraikan perangkat lunak menjadi fungsi yang masing-masing dapat diperkirakan secara individual.

  • Hitung ukuran setiap fungsi.

  • Dapatkan perkiraan upaya dan biaya dengan menerapkan nilai ukuran ke metrik produktivitas dasar Anda.

  • Gabungkan perkiraan fungsi untuk menghasilkan perkiraan keseluruhan untuk keseluruhan proyek.

Step 3- Hasilkan perkiraan upaya dan biaya. Anda dapat mencapai perkiraan upaya dan biaya dengan memecah proyek menjadi aktivitas rekayasa perangkat lunak terkait.

  • Identifikasi urutan kegiatan yang perlu dilakukan untuk menyelesaikan proyek.

  • Bagilah aktivitas menjadi tugas-tugas yang dapat diukur.

  • Perkirakan upaya (dalam jam / hari orang) yang diperlukan untuk menyelesaikan setiap tugas.

  • Gabungkan perkiraan usaha dari tugas kegiatan untuk menghasilkan perkiraan kegiatan.

  • Dapatkan unit biaya (yaitu, biaya / unit usaha) untuk setiap aktivitas dari database.

  • Hitung total usaha dan biaya untuk setiap aktivitas.

  • Gabungkan perkiraan usaha dan biaya untuk setiap kegiatan untuk menghasilkan perkiraan usaha dan biaya secara keseluruhan untuk keseluruhan proyek.

Step 4- Rekonsiliasi perkiraan: Bandingkan nilai yang dihasilkan dari Langkah 3 dengan yang diperoleh dari Langkah 2. Jika kedua kumpulan perkiraan setuju, maka angka Anda sangat dapat diandalkan. Sebaliknya, jika terjadi perkiraan yang sangat berbeda, lakukan penyelidikan lebih lanjut mengenai apakah -

  • Ruang lingkup proyek tidak cukup dipahami atau telah disalahartikan.

  • Perincian fungsi dan / atau aktivitas tidak akurat.

  • Data historis yang digunakan untuk teknik estimasi tidak sesuai untuk aplikasi, atau usang, atau telah diterapkan secara salah.

Step 5 - Tentukan penyebab divergensi dan kemudian rekonsiliasi perkiraannya.

Akurasi Estimasi

Akurasi adalah indikasi seberapa dekat sesuatu dengan kenyataan. Setiap kali Anda membuat perkiraan, semua orang ingin tahu seberapa dekat angkanya dengan kenyataan. Anda ingin setiap perkiraan menjadi seakurat mungkin, mengingat data yang Anda miliki saat Anda membuatnya. Dan tentu saja Anda tidak ingin menyajikan perkiraan dengan cara yang menginspirasi rasa percaya diri yang salah pada angka.

Faktor penting yang mempengaruhi keakuratan perkiraan adalah -

  • Keakuratan semua data masukan perkiraan.

  • Keakuratan perhitungan perkiraan apa pun.

  • Seberapa cocok data historis atau data industri yang digunakan untuk mengkalibrasi model dengan proyek yang Anda perkirakan.

  • Prediksi proses pengembangan perangkat lunak organisasi Anda.

  • Kestabilan persyaratan produk dan lingkungan yang mendukung upaya rekayasa perangkat lunak.

  • Apakah proyek yang sebenarnya direncanakan, dipantau, dan dikendalikan dengan cermat atau tidak, dan tidak ada kejutan besar yang terjadi yang menyebabkan penundaan yang tidak terduga.

Berikut adalah beberapa pedoman untuk mencapai perkiraan yang andal -

  • Berdasarkan perkiraan pada proyek serupa yang telah diselesaikan.
  • Gunakan teknik dekomposisi yang relatif sederhana untuk menghasilkan perkiraan biaya dan upaya proyek.
  • Gunakan satu atau lebih model estimasi empiris untuk estimasi biaya dan usaha perangkat lunak.

Lihat bagian Pedoman Estimasi di bab ini.

Untuk memastikan keakuratannya, Anda selalu disarankan untuk memperkirakan menggunakan setidaknya dua teknik dan membandingkan hasilnya.

Masalah Estimasi

Seringkali, manajer proyek menggunakan perkiraan jadwal melompati untuk memperkirakan ukuran. Ini mungkin karena jadwal yang ditetapkan oleh manajemen puncak atau tim pemasaran. Namun, apapun alasannya, jika ini dilakukan, maka pada tahap selanjutnya akan sulit memperkirakan jadwal untuk mengakomodasi perubahan ruang lingkup.

Saat memperkirakan, asumsi tertentu dapat dibuat. Semua asumsi ini penting untuk dicatat di lembar estimasi, karena beberapa asumsi masih belum didokumentasikan di lembar estimasi.

Bahkan perkiraan yang baik memiliki asumsi, risiko, dan ketidakpastian yang melekat, namun sering diperlakukan seolah-olah akurat.

Cara terbaik untuk menyatakan perkiraan adalah sebagai kisaran hasil yang mungkin dengan mengatakan, misalnya, bahwa proyek akan memakan waktu 5 hingga 7 bulan alih-alih menyatakan akan selesai pada tanggal tertentu atau akan selesai dalam no tetap. bulan. Berhati-hatilah saat berkomitmen pada rentang yang terlalu sempit karena setara dengan berkomitmen pada tanggal tertentu.

  • Anda juga bisa memasukkan ketidakpastian sebagai nilai probabilitas yang menyertai. Misalnya, ada kemungkinan 90% bahwa proyek akan selesai pada atau sebelum tanggal tertentu.

  • Organisasi tidak mengumpulkan data proyek yang akurat. Karena keakuratan perkiraan bergantung pada data historis, ini akan menjadi masalah.

  • Untuk proyek apa pun, ada jadwal sesingkat mungkin yang memungkinkan Anda menyertakan fungsionalitas yang diperlukan dan menghasilkan keluaran yang berkualitas. Jika ada batasan jadwal oleh manajemen dan / atau klien, Anda dapat menegosiasikan cakupan dan fungsionalitas yang akan dikirimkan.

  • Setuju dengan klien dalam menangani cakupan creep untuk menghindari pembengkakan jadwal.

  • Kegagalan dalam mengakomodasi kontingensi dalam perkiraan akhir menyebabkan masalah. Misalnya, rapat, acara organisasi.

  • Pemanfaatan sumber daya harus dianggap kurang dari 80%. Ini karena sumber daya hanya akan produktif untuk 80% dari waktu mereka. Jika Anda menetapkan sumber daya dengan penggunaan lebih dari 80%, pasti ada selip.

Pedoman Estimasi

Seseorang harus mengingat pedoman berikut saat memperkirakan proyek -

  • Selama estimasi, tanyakan pengalaman orang lain. Juga, letakkan pengalaman Anda sendiri di tugas.

  • Asumsikan sumber daya akan produktif hanya untuk 80 persen dari waktu mereka. Oleh karena itu, selama estimasi mengambil pemanfaatan sumber daya kurang dari 80%.

  • Sumber daya yang mengerjakan banyak proyek membutuhkan waktu lebih lama untuk menyelesaikan tugas karena waktu yang hilang saat berpindah antar proyek.

  • Sertakan waktu manajemen dalam perkiraan apa pun.

  • Selalu membangun kontingensi untuk pemecahan masalah, rapat, dan kejadian tak terduga lainnya.

  • Berikan waktu yang cukup untuk melakukan perkiraan proyek yang tepat. Estimasi terburu-buru tidak akurat, estimasi berisiko tinggi. Untuk proyek pembangunan besar, langkah estimasi harus benar-benar dianggap sebagai proyek mini.

  • Jika memungkinkan, gunakan data terdokumentasi dari proyek serupa milik organisasi Anda sebelumnya. Ini akan menghasilkan perkiraan yang paling akurat. Jika organisasi Anda belum menyimpan data historis, sekaranglah saat yang tepat untuk mulai mengumpulkannya.

  • Gunakan perkiraan berbasis pengembang, karena perkiraan yang disiapkan oleh orang selain mereka yang akan melakukan pekerjaan akan kurang akurat.

  • Gunakan beberapa orang yang berbeda untuk memperkirakan dan menggunakan beberapa teknik perkiraan yang berbeda.

  • Rekonsiliasi perkiraan. Amati konvergensi atau sebaran di antara perkiraan. Konvergensi berarti Anda telah mendapatkan perkiraan yang baik. Teknik Wideband-Delphi dapat digunakan untuk mengumpulkan dan mendiskusikan perkiraan menggunakan sekelompok orang, dengan maksud untuk menghasilkan perkiraan yang akurat dan tidak bias.

  • Perkirakan ulang proyek beberapa kali sepanjang siklus hidupnya.

SEBUAH Function Point(FP) adalah unit pengukuran untuk menyatakan jumlah fungsionalitas bisnis, yang disediakan oleh sistem informasi (sebagai produk) kepada pengguna. FP mengukur ukuran perangkat lunak. Mereka diterima secara luas sebagai standar industri untuk ukuran fungsional.

Untuk mengukur perangkat lunak berdasarkan FP, beberapa standar dan / atau spesifikasi publik yang diakui telah ada. Pada 2013, ini adalah -

Standar ISO

  • COSMIC- ISO / IEC 19761: 2011 Rekayasa perangkat lunak. Metode pengukuran ukuran fungsional.

  • FiSMA - ISO / IEC 29881: 2008 Teknologi informasi - Rekayasa perangkat lunak dan sistem - Metode pengukuran ukuran fungsional FiSMA 1.1.

  • IFPUG - ISO / IEC 20926: 2009 Rekayasa perangkat lunak dan sistem - Pengukuran perangkat lunak - Metode pengukuran ukuran fungsional IFPUG.

  • Mark-II - ISO / IEC 20968: 2002 Rekayasa perangkat lunak - Analisis Titik Fungsi Ml II - Manual Praktik Penghitungan.

  • NESMA - ISO / IEC 24570: 2005 Rekayasa perangkat lunak - Metode pengukuran ukuran fungsi NESMA versi 2.1 - Definisi dan pedoman penghitungan untuk aplikasi Analisis Titik Fungsi.

Spesifikasi Grup Manajemen Objek untuk Titik Fungsi Otomatis

Object Management Group (OMG), sebuah keanggotaan terbuka dan konsorsium standar industri komputer nirlaba, telah mengadopsi spesifikasi Automated Function Point (AFP) yang dipimpin oleh Consortium for IT Software Quality. Ini memberikan standar untuk mengotomatiskan penghitungan FP sesuai dengan pedoman International Function Point User Group (IFPUG).

Function Point Analysis (FPA) techniquemengukur fungsi yang terkandung dalam perangkat lunak dalam istilah yang berarti bagi pengguna perangkat lunak. FP mempertimbangkan jumlah fungsi yang dikembangkan berdasarkan spesifikasi persyaratan.

Function Points (FP) Countingdiatur oleh seperangkat aturan, proses, dan pedoman standar seperti yang didefinisikan oleh International Function Point Users Group (IFPUG). Ini dipublikasikan di Manual Praktik Penghitungan (CPM).

Sejarah Analisis Titik Fungsi

Konsep Titik Fungsi diperkenalkan oleh Alan Albrecht dari IBM pada tahun 1979. Pada tahun 1984, Albrecht menyempurnakan metode tersebut. Pedoman Titik Fungsi pertama diterbitkan pada tahun 1984. Kelompok Pengguna Titik Fungsi Internasional (IFPUG) adalah organisasi pengguna perangkat lunak metrik Analisis Titik Fungsi di seluruh dunia yang berbasis di AS. ItuInternational Function Point Users Group (IFPUG)adalah organisasi nirlaba yang diatur oleh anggota yang didirikan pada tahun 1986. IFPUG memiliki Analisis Titik Fungsi (FPA) sebagaimana didefinisikan dalam standar ISO 20296: 2009 yang menentukan definisi, aturan, dan langkah-langkah untuk menerapkan metode pengukuran ukuran fungsional (FSM) IFPUG. IFPUG mempertahankan Manual Praktik Penghitungan Titik Fungsi (CPM). CPM 2.0 dirilis pada tahun 1987, dan sejak itu telah terjadi beberapa kali pengulangan. Rilis CPM 4.3 di tahun 2010.

CPM Rilis 4.3.1 dengan revisi editorial ISO dimasukkan pada tahun 2010. Standar ISO (IFPUG FSM) - Pengukuran Ukuran Fungsional yang merupakan bagian dari CPM 4.3.1 adalah teknik untuk mengukur perangkat lunak dalam hal fungsionalitas yang diberikannya. CPM adalah standar yang disetujui secara internasional di bawah ISO / IEC 14143-1 Teknologi Informasi - Pengukuran Perangkat Lunak.

Proses Dasar (EP)

Proses Dasar adalah unit terkecil dari kebutuhan pengguna fungsional yang -

  • Berarti bagi pengguna.
  • Merupakan transaksi yang lengkap.
  • Mandiri dan membiarkan bisnis aplikasi dihitung dalam keadaan yang konsisten.

Fungsi

Ada dua jenis fungsi -

  • Fungsi Data
  • Fungsi Transaksi

Fungsi Data

Ada dua jenis fungsi data -

  • File Logika Internal
  • File Antarmuka Eksternal

Fungsi Data terdiri dari sumber daya internal dan eksternal yang mempengaruhi sistem.

Internal Logical Files

Internal Logical File (ILF) adalah grup yang dapat diidentifikasi pengguna dari data terkait secara logis atau informasi kontrol yang berada sepenuhnya dalam batas aplikasi. Maksud utama dari ILF adalah untuk menyimpan data yang disimpan melalui satu atau lebih proses dasar dari aplikasi yang sedang dihitung. Sebuah ILF memiliki arti inheren yang dipelihara secara internal, ia memiliki beberapa struktur logis dan disimpan dalam sebuah file. (Lihat Gambar 1)

External Interface Files

External Interface File (EIF) adalah grup yang dapat diidentifikasi pengguna dari data terkait secara logis atau informasi kontrol yang digunakan oleh aplikasi untuk tujuan referensi saja. Data sepenuhnya berada di luar batas aplikasi dan dikelola dalam ILF oleh aplikasi lain. EIF memiliki arti inheren yang dipelihara secara eksternal, antarmuka harus dikembangkan untuk mendapatkan data dari file. (Lihat Gambar 1)

Fungsi Transaksi

Ada tiga jenis fungsi transaksi.

  • Input Eksternal
  • Output Eksternal
  • Pertanyaan Eksternal

Fungsi transaksi terdiri dari proses yang dipertukarkan antara pengguna, aplikasi eksternal, dan aplikasi yang diukur.

External Inputs

Input Eksternal (EI) adalah fungsi transaksi di mana Data masuk "ke" aplikasi dari luar batas ke dalam. Data ini datang dari luar aplikasi.

  • Data dapat berasal dari layar input data atau aplikasi lain.
  • EI adalah bagaimana aplikasi mendapatkan informasi.
  • Data dapat berupa informasi kontrol atau informasi bisnis.
  • Data dapat digunakan untuk memelihara satu atau lebih File Logika Internal.
  • Jika data adalah informasi kontrol, itu tidak harus memperbarui File Logika Internal. (Lihat Gambar 1)

External Outputs

External Output (EO) adalah fungsi transaksi dimana data keluar dari sistem. Selain itu, EO dapat memperbarui ILF. Data membuat laporan atau file keluaran yang dikirim ke aplikasi lain. (Lihat Gambar 1)

External Inquiries

External Enquiry (EQ) adalah fungsi transaksi dengan komponen input dan output yang menghasilkan pengambilan data. (Lihat Gambar 1)

Definisi RETs, DETs, FTRs

Jenis Elemen Rekaman

Record Element Type (RET) adalah subgrup terbesar yang dapat diidentifikasi pengguna dari elemen dalam ILF atau EIF. Cara terbaik adalah melihat pengelompokan data yang logis untuk membantu mengidentifikasinya.

Jenis Elemen Data

Jenis Elemen Data (DET) adalah subkelompok data dalam FTR. Mereka unik dan dapat diidentifikasi pengguna.

Jenis File yang Dirujuk

File Type Referenced (FTR) adalah subgrup terbesar yang dapat diidentifikasi pengguna dalam EI, EO, atau EQ yang dirujuk.

Fungsi transaksi EI, EO, EQ diukur dengan menghitung FTR dan DET yang mengandung aturan penghitungan berikut. Demikian pula, fungsi data ILF dan EIF diukur dengan menghitung DET dan RET yang berisi aturan penghitungan berikut. Ukuran fungsi transaksi dan fungsi data digunakan dalam penghitungan FP yang menghasilkan ukuran fungsional atau titik fungsi.

Proses Penghitungan FP melibatkan langkah-langkah berikut -

  • Step 1 - Tentukan jenis hitungan.

  • Step 2 - Tentukan batas hitungan.

  • Step 3 - Identifikasi setiap Elementary Process (EP) yang dibutuhkan oleh pengguna.

  • Step 4 - Tentukan EP unik.

  • Step 5 - Mengukur fungsi data.

  • Step 6 - Mengukur fungsi transaksional.

  • Step 7 - Hitung ukuran fungsional (jumlah titik fungsi tidak disesuaikan).

  • Step 8 - Tentukan Value Adjustment Factor (VAF).

  • Step 9 - Hitung jumlah titik fungsi yang disesuaikan.

Note- Karakteristik Sistem Umum (GSC) dibuat opsional di CPM 4.3.1 dan dipindahkan ke Lampiran. Oleh karena itu, Langkah 8 dan Langkah 9 dapat dilewati.

Langkah 1: Tentukan Jenis Hitungan

Ada tiga jenis hitungan titik fungsi -

  • Hitungan Titik Fungsi Pengembangan
  • Hitungan Titik Fungsi Aplikasi
  • Jumlah Poin Fungsi Peningkatan

Hitungan Titik Fungsi Pengembangan

Titik fungsi dapat dihitung di semua fase proyek pengembangan mulai dari persyaratan hingga tahap implementasi. Jenis penghitungan ini terkait dengan pekerjaan pengembangan baru dan mungkin termasuk prototipe, yang mungkin diperlukan sebagai solusi sementara, yang mendukung upaya konversi. Jenis hitungan ini disebut hitungan titik fungsi dasar.

Hitungan Titik Fungsi Aplikasi

Jumlah aplikasi dihitung sebagai titik fungsi yang dikirimkan, dan mengecualikan upaya konversi apa pun (prototipe atau solusi sementara) dan fungsionalitas yang mungkin ada.

Jumlah Poin Fungsi Peningkatan

Ketika perubahan dilakukan pada perangkat lunak setelah produksi, itu dianggap sebagai peningkatan. Untuk mengukur proyek peningkatan seperti itu, Hitungan Titik Fungsi akan Ditambahkan, Diubah atau Dihapus dalam Aplikasi.

Langkah 2: Tentukan Batasan Hitungan tersebut

Batas tersebut menunjukkan batas antara aplikasi yang sedang diukur dan aplikasi eksternal atau domain pengguna. (Lihat Gambar 1)

Untuk menentukan batas, pahami -

  • Tujuan penghitungan titik fungsi
  • Cakupan aplikasi yang sedang diukur
  • Bagaimana dan aplikasi mana yang memelihara data apa
  • Area bisnis yang mendukung aplikasi

Langkah 3: Identifikasi Setiap Proses Dasar yang Diwajibkan oleh Pengguna

Buat dan / atau uraikan persyaratan pengguna fungsional menjadi unit aktivitas terkecil, yang memenuhi semua kriteria berikut -

  • Berarti bagi pengguna.
  • Merupakan transaksi yang lengkap.
  • Mandiri.
  • Meninggalkan bisnis aplikasi yang dihitung dalam keadaan konsisten.

Misalnya, Persyaratan Pengguna Fungsional - "Menjaga informasi Karyawan" dapat diuraikan menjadi aktivitas yang lebih kecil seperti menambah karyawan, mengganti karyawan, menghapus karyawan, dan menanyakan tentang karyawan.

Setiap unit kegiatan yang diidentifikasi adalah Proses Dasar (EP).

Langkah 4: Tentukan Proses Dasar yang Unik

Membandingkan dua EP yang telah diidentifikasi, hitung sebagai satu EP (EP yang sama) jika -

  • Memerlukan kumpulan DET yang sama.
  • Membutuhkan set FTR yang sama.
  • Memerlukan rangkaian logika pemrosesan yang sama untuk menyelesaikan EP.

Jangan memisahkan EP dengan berbagai bentuk logika pemrosesan menjadi beberapa Eps.

Misalnya, jika Anda telah mengidentifikasi 'Tambah Karyawan' sebagai EP, itu tidak boleh dibagi menjadi dua EP untuk memperhitungkan fakta bahwa seorang karyawan mungkin atau mungkin tidak memiliki tanggungan. EP masih 'Tambah Karyawan', dan ada variasi dalam logika pemrosesan dan DET untuk memperhitungkan tanggungan.

Langkah 5: Ukur Fungsi Data

Klasifikasikan setiap fungsi data sebagai ILF atau EIF.

Fungsi data harus diklasifikasikan sebagai -

  • File Logika Internal (ILF), jika dikelola oleh aplikasi yang sedang diukur.

  • File Antarmuka Eksternal (EIF) jika dirujuk, tetapi tidak dikelola oleh aplikasi yang sedang diukur.

ILF dan EIF dapat berisi data bisnis, data kontrol, dan data berbasis aturan. Misalnya, switching telepon dibuat dari ketiga jenis - data bisnis, data aturan, dan data kontrol. Data bisnis adalah panggilan sebenarnya. Data aturan adalah bagaimana panggilan harus dialihkan melalui jaringan, dan data kontrol adalah bagaimana sakelar berkomunikasi satu sama lain.

Pertimbangkan dokumentasi berikut untuk menghitung ILF dan EIF -

  • Tujuan dan kendala untuk sistem yang diusulkan.
  • Dokumentasi mengenai sistem saat ini, jika sistem seperti itu ada.
  • Dokumentasi tentang tujuan, masalah dan kebutuhan yang dirasakan pengguna.
  • Model data.

Langkah 5.1: Hitung DET untuk Setiap Fungsi Data

Terapkan aturan berikut untuk menghitung DET untuk ILF / EIF -

  • Hitung DET untuk setiap bidang unik yang dapat diidentifikasi pengguna, tidak berulang yang disimpan di atau diambil dari ILF atau EIF melalui pelaksanaan EP.

  • Hitung hanya DET yang digunakan oleh aplikasi yang diukur ketika dua atau lebih aplikasi memelihara dan / atau mereferensikan fungsi data yang sama.

  • Hitung DET untuk setiap atribut yang dibutuhkan oleh pengguna untuk membangun hubungan dengan ILF atau EIF lain.

  • Tinjau atribut terkait untuk menentukan apakah mereka dikelompokkan dan dihitung sebagai satu DET atau apakah mereka dihitung sebagai beberapa DET. Pengelompokan akan bergantung pada bagaimana EP menggunakan atribut dalam aplikasi.

Langkah 5.2: Hitung RET untuk Setiap Fungsi Data

Terapkan aturan berikut untuk menghitung RET untuk ILF / EIF -

  • Hitung satu RET untuk setiap fungsi data.
  • Hitung satu RET tambahan untuk setiap subkelompok logis tambahan DETs berikut.
    • Entitas asosiatif dengan atribut non-kunci.
    • Sub-tipe (selain sub-tipe pertama).
    • Entitas atributif, dalam hubungan selain wajib 1: 1.

Langkah 5.3: Tentukan Kompleksitas Fungsional untuk Setiap Fungsi Data

RETS Jenis Elemen Data (DETs)
1-19 20-50 >50
1 L L SEBUAH
2 sampai 5 L SEBUAH H.
> 5 SEBUAH H. H.

Kompleksitas Fungsional: L = Rendah; A = Rata-rata; H = Tinggi

Langkah 5.4: Mengukur Ukuran Fungsional untuk Setiap Fungsi Data

Kompleksitas Fungsional Hitungan FP untuk ILF Hitungan FP untuk EIF
Rendah 7 5
Rata-rata 10 7
Tinggi 15 10

Langkah 6: Mengukur Fungsi Transaksional

Untuk mengukur fungsi transaksional berikut adalah langkah-langkah yang diperlukan -

Langkah 6.1: Klasifikasikan setiap Fungsi Transaksional

Fungsi transaksional harus diklasifikasikan sebagai Input Eksternal, Output Eksternal atau Permintaan Eksternal.

Input Eksternal

External Input (EI) adalah Proses Elementer yang memproses data atau mengontrol informasi yang berasal dari luar batas. Maksud utama dari EI adalah untuk mempertahankan satu atau lebih ILF dan / atau untuk mengubah perilaku sistem.

Semua aturan berikut harus diterapkan -

  • Data atau informasi kontrol diterima dari luar batas aplikasi.

  • Setidaknya satu ILF dipertahankan jika data yang memasuki batas tidak mengontrol informasi yang mengubah perilaku sistem.

  • Untuk EP yang teridentifikasi, salah satu dari tiga pernyataan harus berlaku -

    • Logika pemrosesan unik dari logika pemrosesan yang dilakukan oleh IE lain untuk aplikasi tersebut.

    • Kumpulan elemen data yang diidentifikasi berbeda dari set yang diidentifikasi untuk IE lain dalam aplikasi.

    • ILF atau EIF yang direferensikan berbeda dari file yang direferensikan oleh EI lain dalam aplikasi.

Output Eksternal

Output Eksternal (EO) adalah Proses Dasar yang mengirimkan data atau informasi kontrol di luar batas aplikasi. EO mencakup pemrosesan tambahan di luar permintaan eksternal.

Maksud utama dari EO adalah untuk menyajikan informasi kepada pengguna melalui logika pemrosesan selain atau sebagai tambahan untuk pengambilan data atau informasi kontrol.

Logika pemrosesan harus -

  • Berisi setidaknya satu rumus atau perhitungan matematika.
  • Buat data turunan.
  • Pertahankan satu atau lebih ILF.
  • Ubah perilaku sistem.

Semua aturan berikut harus diterapkan -

  • Mengirimkan data atau informasi kontrol di luar batas aplikasi.
  • Untuk EP yang teridentifikasi, salah satu dari tiga pernyataan harus berlaku -
    • Logika pemrosesan unik dari logika pemrosesan yang dilakukan oleh EO lain untuk aplikasi tersebut.
    • Kumpulan elemen data yang diidentifikasi berbeda dari EO lain dalam aplikasi.
    • ILF atau EIF yang dirujuk berbeda dari file yang dirujuk oleh EO lain dalam aplikasi.

Selain itu, salah satu aturan berikut harus diterapkan -

  • Logika pemrosesan berisi setidaknya satu rumus atau perhitungan matematika.
  • Logika pemrosesan mempertahankan setidaknya satu ILF.
  • Logika pemrosesan mengubah perilaku sistem.

Pertanyaan Eksternal

Permintaan Eksternal (EQ) adalah Proses Dasar yang mengirimkan data atau mengontrol informasi di luar batas. Maksud utama dari EQ adalah untuk menyajikan informasi kepada pengguna melalui pengambilan data atau informasi kontrol.

Logika pemrosesan tidak berisi rumus matematika atau penghitungan, dan tidak membuat data turunan. Tidak ada ILF yang dipertahankan selama pemrosesan, juga perilaku sistem tidak diubah.

Semua aturan berikut harus diterapkan -

  • Mengirimkan data atau informasi kontrol di luar batas aplikasi.
  • Untuk EP yang teridentifikasi, salah satu dari tiga pernyataan harus berlaku -
    • Logika pemrosesan unik dari logika pemrosesan yang dilakukan oleh EQ lain untuk aplikasi.
    • Kumpulan elemen data yang diidentifikasi berbeda dari EQ lain dalam aplikasi.
    • ILF atau EIF yang direferensikan berbeda dari file yang direferensikan oleh EQ lain dalam aplikasi.

Selain itu, semua aturan berikut harus berlaku -

  • Logika pemrosesan mengambil data atau mengontrol informasi dari ILF atau EIF.
  • Logika pemrosesan tidak mengandung rumus atau perhitungan matematika.
  • Logika pemrosesan tidak mengubah perilaku sistem.
  • Logika pemrosesan tidak mempertahankan ILF.

Langkah 6.2: Hitung DET untuk Setiap Fungsi Transaksional

Terapkan Aturan berikut untuk menghitung DET untuk EI -

  • Tinjau segala sesuatu yang melintasi (masuk dan / atau keluar) batas.

  • Hitung satu DET untuk setiap atribut unik yang dapat diidentifikasi dan tidak berulang pengguna yang melintasi (masuk dan / atau keluar) batas selama pemrosesan fungsi transaksional.

  • Hitung hanya satu DET per fungsi transaksional untuk kemampuan mengirim pesan respons aplikasi, meskipun ada beberapa pesan.

  • Hitung hanya satu DET per fungsi transaksional untuk kemampuan memulai tindakan meskipun ada beberapa cara untuk melakukannya.

  • Jangan hitung item berikut sebagai DETs -

    • Atribut yang dihasilkan dalam batas oleh fungsi transaksional dan disimpan ke ILF tanpa keluar dari batas.

    • Literal seperti judul laporan, pengidentifikasi layar atau panel, judul kolom, dan judul atribut.

    • Perangko yang dihasilkan aplikasi seperti atribut tanggal dan waktu.

    • Variabel halaman, nomor halaman dan informasi posisi, misalnya, 'Baris 37 hingga 54 dari 211'.

    • Alat bantu navigasi seperti kemampuan untuk menavigasi dalam daftar menggunakan "sebelumnya", "berikutnya", "pertama", "terakhir" dan grafis yang setara.

Terapkan aturan berikut untuk menghitung DET untuk EO / EQ -

  • Tinjau segala sesuatu yang melintasi (masuk dan / atau keluar) batas.

  • Hitung satu DET untuk setiap atribut unik yang dapat diidentifikasi dan tidak berulang pengguna yang melintasi (masuk dan / atau keluar) batas selama pemrosesan fungsi transaksional.

  • Hitung hanya satu DET per fungsi transaksional untuk kemampuan mengirim pesan respons aplikasi, meskipun ada beberapa pesan.

  • Hitung hanya satu DET per fungsi transaksional untuk kemampuan memulai tindakan meskipun ada beberapa cara untuk melakukannya.

  • Jangan hitung item berikut sebagai DETs -

    • Atribut yang dihasilkan di dalam batas tanpa melewati batas tersebut.

    • Literal seperti judul laporan, pengidentifikasi layar atau panel, judul kolom, dan judul atribut.

    • Perangko yang dihasilkan aplikasi seperti atribut tanggal dan waktu.

    • Variabel halaman, nomor halaman dan informasi posisi, misalnya, 'Baris 37 hingga 54 dari 211'.

    • Alat bantu navigasi seperti kemampuan untuk menavigasi dalam daftar menggunakan "sebelumnya", "berikutnya", "pertama", "terakhir" dan grafis yang setara.

Langkah 6.3: Hitung FTR untuk Setiap Fungsi Transaksional

Terapkan aturan berikut untuk menghitung FTR untuk EI -

  • Hitung FTR untuk setiap ILF yang dipertahankan.
  • Hitung FTR untuk setiap pembacaan ILF atau EIF selama pemrosesan EI.
  • Hitung hanya satu FTR untuk setiap ILF yang dipertahankan dan dibaca.

Terapkan aturan berikut untuk menghitung FTR untuk EO / EQ -

  • Hitung FTR untuk setiap ILF atau EIF yang dibaca selama pemrosesan EP.

Selain itu, terapkan aturan berikut untuk menghitung FTR untuk EO -

  • Hitung FTR untuk setiap ILF yang dipertahankan selama pemrosesan EP.
  • Hitung hanya satu FTR untuk setiap ILF yang dipertahankan dan dibaca oleh EP.

Langkah 6.4: Tentukan Kompleksitas Fungsional untuk Setiap Fungsi Transaksional

FTR Jenis Elemen Data (DETs)
1-4 5-15 >=16
0-1 L L SEBUAH
2 L SEBUAH H.
> = 3 SEBUAH H. H.

Kompleksitas Fungsional: L = Rendah; A = Rata-rata; H = Tinggi

Tentukan kompleksitas fungsional untuk setiap EO / EQ, dengan pengecualian bahwa EQ harus memiliki minimal 1 FTR -

EQ harus memiliki minimal 1 FTR

FTR

Jenis Elemen Data (DETs)
1-4 5-15 > = 16
0-1 L L SEBUAH
2 L SEBUAH H.
> = 3 SEBUAH H. H.

Kompleksitas Fungsional: L = Rendah; A = Rata-rata; H = Tinggi

Langkah 6.5: Mengukur Ukuran Fungsional untuk Setiap Fungsi Transaksional

Ukur ukuran fungsional untuk setiap IE dari kompleksitas fungsionalnya.

Kompleksitas Hitungan FP
Rendah 3
Rata-rata 4
Tinggi 6

Ukur ukuran fungsional untuk setiap EO / EQ dari kompleksitas fungsionalnya.

Kompleksitas Hitungan FP untuk EO Hitungan FP untuk EQ
Rendah 4 3
Rata-rata 5 4
Tinggi 6 6

Langkah 7: Hitung Ukuran Fungsional (Jumlah Titik Fungsi Tidak Disesuaikan)

Untuk menghitung ukuran fungsional, seseorang harus mengikuti langkah-langkah yang diberikan di bawah ini -

Langkah 7.1

Ingat kembali apa yang telah Anda temukan di Langkah 1. Tentukan jenis penghitungan.

Langkah 7.2

Hitung ukuran fungsional atau jumlah titik fungsi berdasarkan jenisnya.

  • Untuk hitungan titik fungsi pengembangan, lanjutkan ke Langkah 7.3.
  • Untuk hitungan titik fungsi aplikasi, lanjutkan ke Langkah 7.4.
  • Untuk jumlah poin fungsi penyempurnaan, lanjutkan ke Langkah 7.5.

Langkah 7.3

Development Function Point Count terdiri dari dua komponen fungsionalitas -

  • Fungsionalitas aplikasi termasuk dalam persyaratan pengguna untuk proyek tersebut.

  • Fungsionalitas konversi termasuk dalam persyaratan pengguna untuk proyek tersebut. Fungsionalitas konversi terdiri dari fungsi-fungsi yang disediakan hanya pada instalasi untuk mengonversi data dan / atau menyediakan persyaratan konversi yang ditentukan pengguna lainnya, seperti laporan konversi khusus. Misalnya, aplikasi yang ada dapat diganti dengan sistem baru.

DFP = ADD + CFP

Dimana,

DFP = Hitungan Titik Fungsi Pengembangan

ADD = Ukuran fungsi yang dikirimkan ke pengguna oleh proyek pengembangan

CFP = Ukuran fungsi konversi

ADD = Jumlah FP (ILF) + Jumlah FP (EIF) + Jumlah FP (EI) + Jumlah FP (EO) + Jumlah FP (EQ)

CFP = Jumlah FP (ILF) + Jumlah FP (EIF) + Jumlah FP (EI) + Jumlah FP (EO) + Jumlah FP (EQ)

Langkah 7.4

Hitung Jumlah Titik Fungsi Aplikasi

AFP = ADD

Dimana,

AFP = Jumlah Titik Fungsi Aplikasi

ADD = Ukuran fungsi yang dikirim ke pengguna oleh proyek pengembangan (tidak termasuk ukuran fungsi konversi), atau fungsionalitas yang ada setiap kali aplikasi dihitung.

ADD = Jumlah FP (ILF) + Jumlah FP (EIF) + Jumlah FP (EI) + Jumlah FP (EO) + Jumlah FP (EQ)

Langkah 7.5

Jumlah Poin Fungsi Peningkatan mempertimbangkan empat komponen fungsionalitas berikut -

  • Fungsi yang ditambahkan ke aplikasi.
  • Fungsi yang dimodifikasi dalam Aplikasi.
  • Fungsi konversi.
  • Fungsi yang dihapus dari aplikasi.

EFP = ADD + CHGA + CFP + DEL

Dimana,

EFP = Jumlah Poin Fungsi Peningkatan

ADD = Ukuran fungsi yang ditambahkan oleh proyek peningkatan

CHGA = Ukuran fungsi yang diubah oleh proyek peningkatan

CFP = Ukuran fungsi konversi

DEL = Ukuran fungsi yang dihapus oleh proyek peningkatan

ADD = Jumlah FP (ILF) + Jumlah FP (EIF) + Jumlah FP (EI) + Jumlah FP (EO) + Jumlah FP (EQ)

CHGA = Jumlah FP (ILF) + Jumlah FP (EIF) + Jumlah FP (EI) + Jumlah FP (EO) + Jumlah FP (EQ)

CFP = Jumlah FP (ILF) + Jumlah FP (EIF) + Jumlah FP (EI) + Jumlah FP (EO) + Jumlah FP (EQ)

DEL = Jumlah FP (ILF) + Jumlah FP (EIF) + Jumlah FP (EI) + Jumlah FP (EO) + Jumlah FP (Persamaan)

Langkah 8: Tentukan Faktor Penyesuaian Nilai

GSC dibuat opsional di CPM 4.3.1 dan dipindahkan ke Lampiran. Oleh karena itu, Langkah 8 dan Langkah 9 dapat dilewati.

Faktor Penyesuaian Nilai (VAF) didasarkan pada 14 GSC yang menilai fungsionalitas umum dari aplikasi yang sedang dihitung. GSC adalah batasan bisnis pengguna yang tidak bergantung pada teknologi. Setiap karakteristik memiliki deskripsi terkait untuk menentukan tingkat pengaruhnya.

Karakteristik Sistem Umum Deskripsi singkat
Komunikasi Data Berapa banyak fasilitas komunikasi yang ada untuk membantu transfer atau pertukaran informasi dengan aplikasi atau sistem?
Pemrosesan Data Terdistribusi Bagaimana data terdistribusi dan fungsi pemrosesan ditangani?
Performa Apakah pengguna memerlukan waktu respons atau throughput?
Konfigurasi yang Sangat Digunakan Seberapa sering digunakan platform perangkat keras saat ini di mana aplikasi akan dijalankan?
Tingkat Transaksi Seberapa sering transaksi dilakukan harian, mingguan, bulanan, dll.?
Entri Data On-Line Berapa persentase informasi yang dimasukkan secara online?
Efisiensi Pengguna Akhir Apakah aplikasi dirancang untuk efisiensi pengguna akhir?
Pembaruan Online Berapa ILF yang diperbarui melalui transaksi online?
Pemrosesan Kompleks Apakah aplikasi memiliki pemrosesan logika atau matematika yang ekstensif?
Dapat digunakan kembali Apakah aplikasi dikembangkan untuk memenuhi satu atau banyak kebutuhan pengguna?
Kemudahan Instalasi Seberapa sulit konversi dan pemasangan?
Kemudahan Operasional Seberapa efektif dan / atau otomatis prosedur start-up, back-up, dan pemulihan?
Beberapa Situs Apakah aplikasi secara khusus dirancang, dikembangkan, dan didukung untuk dipasang di banyak situs untuk banyak organisasi?
Fasilitasi Perubahan Apakah aplikasi dirancang, dikembangkan, dan didukung secara khusus untuk memfasilitasi perubahan?

Derajat rentang pengaruh berada pada skala nol hingga lima, dari tanpa pengaruh hingga pengaruh kuat.

Peringkat Tingkat Pengaruh
0 Tidak hadir, atau tidak berpengaruh
1 Pengaruh insidental
2 Pengaruh sedang
3 Pengaruh rata-rata
4 Pengaruh signifikan
5 Pengaruh yang kuat di seluruh

Tentukan tingkat pengaruh untuk masing-masing dari 14 GSC.

Jumlah nilai dari 14 GSC yang diperoleh disebut sebagai Tingkat Pengaruh Total (TDI).

TDI = ∑14 Degrees of Influence

Selanjutnya, hitung Faktor Penyesuaian Nilai (VAF) sebagai

VAF = (TDI × 0.01) + 0.65

Setiap GSC dapat bervariasi dari 0 hingga 5, TDI dapat bervariasi dari (0 × 14) hingga (5 × 14), yaitu 0 (jika semua GSC rendah) hingga 70 (jika semua GSC tinggi) yaitu 0 ≤ TDI ≤ 70. Oleh karena itu, VAF dapat bervariasi dalam kisaran dari 0,65 (ketika semua GSC rendah) hingga 1,35 (ketika semua GSC tinggi), yaitu 0,65 ≤ VAF ≤ 1,35.

Langkah 9: Hitung Jumlah Titik Fungsi yang Disesuaikan

Sesuai pendekatan FPA yang menggunakan VAF (versi CPM sebelum V4.3.1), ini ditentukan oleh,

Adjusted FP Count = Unadjusted FP Count × VAF

Di mana, jumlah FP yang tidak disesuaikan adalah ukuran fungsional yang telah Anda hitung di Langkah 7.

Karena VAF dapat bervariasi dari 0,65 hingga 1,35, VAF memberikan pengaruh ± 35% pada jumlah FP akhir yang disesuaikan.

Manfaat Titik Fungsi

Titik fungsi berguna -

  • Dalam mengukur ukuran solusi, bukan ukuran masalah.

  • Karena persyaratan adalah satu-satunya hal yang diperlukan untuk penghitungan titik fungsi.

  • Karena tidak bergantung pada teknologi.

  • Karena tidak bergantung pada bahasa pemrograman.

  • Dalam memperkirakan proyek pengujian.

  • Dalam memperkirakan biaya proyek secara keseluruhan, jadwal dan usaha.

  • Dalam negosiasi kontrak seperti itu memberikan metode komunikasi yang lebih mudah dengan kelompok bisnis.

  • Karena mengukur dan memberikan nilai pada penggunaan aktual, antarmuka, dan tujuan fungsi dalam perangkat lunak.

  • Dalam membuat rasio dengan metrik lain seperti jam, biaya, jumlah staf, durasi, dan metrik aplikasi lainnya.

Repositori FP

International Software Benchmarking Standards Group (ISBSG) mengembangkan dan memelihara dua repositori untuk data TI.

  • Proyek Pengembangan dan Peningkatan
  • Aplikasi Perawatan dan Dukungan

Ada lebih dari 6.000 proyek di repositori Proyek Pengembangan dan Peningkatan.

Data dikirimkan dalam format Microsoft Excel, sehingga memudahkan analisis lebih lanjut yang ingin Anda lakukan dengannya, atau Anda bahkan dapat menggunakan data tersebut untuk tujuan lain.

Lisensi repositori ISBSG dapat dibeli dari: http://www.isbsg.com/

ISBSG menawarkan diskon 10% bagi anggota IFPUG untuk pembelian online ketika kode diskon “Anggota IFPUGM” digunakan.

Pembaruan Rilis Data Proyek Perangkat Lunak ISBSG dapat ditemukan di: http://www.ifpug.org/isbsg/

COSMIC dan IFPUG berkolaborasi untuk menghasilkan Daftar Istilah untuk Perangkat Lunak Non-fungsional dan Persyaratan Proyek. Ini dapat diunduh dari - cosmic-sizing.org

SEBUAH Use-Case adalah rangkaian interaksi terkait antara pengguna dan sistem yang memungkinkan pengguna mencapai suatu tujuan.

Use-Case adalah cara untuk menangkap persyaratan fungsional suatu sistem. Pengguna sistem ini disebut sebagai 'Aktor'. Use-Case pada dasarnya dalam bentuk teks.

Use-Case Points - Definisi

Use-Case Points (UCP)adalah teknik estimasi software yang digunakan untuk mengukur ukuran software dengan use case. Konsep UCP mirip dengan FP.

Jumlah UCP dalam sebuah proyek didasarkan pada:

  • Jumlah dan kompleksitas kasus penggunaan dalam sistem.
  • Jumlah dan kompleksitas pelaku dalam sistem.
    • Berbagai persyaratan non-fungsional (seperti portabilitas, performa, pemeliharaan) yang tidak ditulis sebagai kasus penggunaan.

    • Lingkungan tempat proyek akan dikembangkan (seperti bahasa, motivasi tim, dll.)

Estimasi dengan UCP mengharuskan semua kasus penggunaan ditulis dengan tujuan dan pada tingkat yang kurang lebih sama, memberikan jumlah detail yang sama. Oleh karena itu, sebelum estimasi, tim proyek harus memastikan bahwa mereka telah menulis kasus penggunaan mereka dengan tujuan yang ditentukan dan pada tingkat yang terperinci. Kasus penggunaan biasanya diselesaikan dalam satu sesi dan setelah tujuan tercapai, pengguna dapat melanjutkan ke aktivitas lainnya.

Sejarah Poin Use-Case

Metode estimasi Use-Case Point diperkenalkan oleh Gustav Karner pada tahun 1993. Karya tersebut kemudian dilisensikan oleh Rational Software yang digabungkan ke dalam IBM.

Proses Penghitungan Poin-Kasus Penggunaan

Proses penghitungan Use-Case Points memiliki langkah-langkah berikut -

  • Hitung UCP yang tidak disesuaikan
  • Sesuaikan dengan kerumitan teknis
  • Sesuaikan dengan kompleksitas lingkungan
  • Hitung UCP yang disesuaikan

Langkah 1: Hitung Poin Kasus Penggunaan yang Tidak Disesuaikan.

Anda menghitung Poin Kasus Penggunaan yang Tidak Disesuaikan terlebih dahulu, dengan langkah-langkah berikut -

  • Tentukan Bobot Kasus Penggunaan yang Tidak Disesuaikan
  • Tentukan Bobot Aktor yang Tidak Disesuaikan
  • Hitung Poin Kasus Penggunaan yang Tidak Disesuaikan

Step 1.1 - Tentukan Bobot Kasus Penggunaan yang Tidak Disesuaikan.

Step 1.1.1 - Temukan jumlah transaksi di setiap Use-Case.

Jika Kasus Penggunaan ditulis dengan Tingkat Sasaran Pengguna, transaksi setara dengan langkah dalam Kasus Penggunaan. Temukan jumlah transaksi dengan menghitung langkah-langkah dalam Use-Case.

Step 1.1.2- Klasifikasikan setiap Use-Case sebagai Sederhana, Rata-rata atau Kompleks berdasarkan jumlah transaksi dalam Use-Case. Juga, tetapkan Use-Case Weight seperti yang ditunjukkan pada tabel berikut -

Kompleksitas Kasus Penggunaan Jumlah Transaksi Berat Kasus Penggunaan
Sederhana ≤3 5
Rata-rata 4 sampai 7 10
Kompleks > 7 15

Step 1.1.3- Ulangi untuk setiap Use-Case dan dapatkan semua Use-Case Weight. Bobot Kasus Penggunaan yang Tidak Disesuaikan (UUCW) adalah jumlah dari semua Bobot Kasus Penggunaan.

Step 1.1.4 - Temukan Berat Kasus Penggunaan yang Tidak Disesuaikan (UUCW) menggunakan tabel berikut -

Kompleksitas Kasus Penggunaan Berat Kasus Penggunaan Jumlah Kasus Penggunaan Produk
Sederhana 5 NSUC 5 × NSUC
Rata-rata 10 NAUC 10 × NAUC
Kompleks 15 NCUC 15 × NCUC
Unadjusted Use-Case Weight (UUCW) 5 × NSUC + 10 × NAUC + 15 × NCUC

Dimana,

NSUC adalah no. Kasus Penggunaan Sederhana.

NAUC adalah no. Kasus Penggunaan Rata-rata.

NCUC adalah no. Kasus Penggunaan yang Kompleks.

Step 1.2 - Tentukan Bobot Aktor yang Tidak Disesuaikan.

Aktor dalam Use-Case dapat berupa orang, program lain, dll. Beberapa aktor, seperti sistem dengan API yang ditentukan, memiliki kebutuhan yang sangat sederhana dan hanya sedikit meningkatkan kompleksitas Use-Case.

Beberapa aktor, seperti sistem yang berinteraksi melalui protokol memiliki lebih banyak kebutuhan dan meningkatkan kompleksitas Use-Case sampai batas tertentu.

Aktor lain, seperti pengguna yang berinteraksi melalui GUI memiliki dampak yang signifikan terhadap kompleksitas Use-Case. Berdasarkan perbedaan ini, Anda dapat mengklasifikasikan aktor sebagai Sederhana, Rata-rata, dan Kompleks.

Step 1.2.1 - Klasifikasikan Aktor sebagai Sederhana, Rata-rata dan Kompleks dan tetapkan Bobot Aktor seperti yang ditunjukkan pada tabel berikut -

Kompleksitas Aktor Contoh Bobot Aktor
Sederhana Sistem dengan API yang ditentukan 1
Rata-rata Sistem berinteraksi melalui Protokol 2
Kompleks Seorang Pengguna berinteraksi melalui GUI 3

Step 1.2.2- Ulangi untuk setiap Aktor dan dapatkan semua Bobot Aktor. Bobot Aktor yang Tidak Disesuaikan (UAW) adalah jumlah dari semua Bobot Aktor.

Step 1.2.3 - Temukan Bobot Aktor yang Tidak Disesuaikan (UAW) menggunakan tabel berikut -

Kompleksitas Aktor Bobot Aktor Jumlah Aktor Produk
Sederhana 1 NSA 1 × NSA
Rata-rata 2 NAA 2 × NAA
Kompleks 3 NCA 3 × NCA
Unadjusted Actor Weight (UAW) 1 × NSA + 2 × NAA + 3 × NCA

Dimana,

NSA adalah no. Aktor Sederhana.

NAA adalah no. Aktor Rata-rata.

NCA adalah no. Aktor Kompleks.

Step 1.3 - Hitung Poin Kasus Penggunaan yang Tidak Disesuaikan.

Bobot Kasus Penggunaan yang Tidak Disesuaikan (UUCW) dan Bobot Pelaku yang Tidak Disesuaikan (UAW) bersama-sama memberikan ukuran sistem yang tidak disesuaikan, yang disebut sebagai Poin Kasus Penggunaan yang Tidak Disesuaikan.

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

Langkah selanjutnya adalah menyesuaikan Unadjusted Use-Case Points (UUCP) untuk Technical Complexity dan Environmental Complexity.

Langkah 2: Sesuaikan Untuk Kompleksitas Teknis

Step 2.1 - Pertimbangkan 13 Faktor yang berkontribusi terhadap dampak Kompleksitas Teknis suatu proyek pada Poin Kasus Penggunaan dan Bobotnya yang sesuai seperti yang diberikan dalam tabel berikut -

Faktor Deskripsi Bobot
T1 Sistem Terdistribusi 2.0
T2 Waktu respons atau tujuan kinerja hasil 1.0
T3 Efisiensi pengguna akhir 1.0
T4 Pemrosesan internal yang kompleks 1.0
T5 Kode harus dapat digunakan kembali 1.0
T6 Mudah dipasang 0,5
T7 Mudah digunakan 0,5
T8 Portabel 2.0
T9 Mudah diubah 1.0
T10 Bersamaan 1.0
T11 Termasuk tujuan keamanan khusus 1.0
T12 Memberikan akses langsung untuk pihak ketiga 1.0
T13 Fasilitas pelatihan pengguna khusus diperlukan 1.0

Banyak dari faktor-faktor ini mewakili kebutuhan nonfungsional proyek.

Step 2.2 - Untuk masing-masing dari 13 Faktor, nilai proyek dan nilai dari 0 (tidak relevan) hingga 5 (sangat penting).

Step 2.3 - Hitung Dampak Faktor dari Bobot Dampak Faktor dan Nilai Nilai untuk proyek sebagai

Impact of the Factor = Impact Weight × Rated Value

Step (2.4)- Hitung jumlah Dampak dari semua Faktor. Ini memberikan Total Technical Factor (TFactor) seperti yang diberikan pada tabel di bawah ini -

Faktor Deskripsi Berat (W) Nilai Nilai (0 hingga 5) (RV) Dampak (I = W × RV)
T1 Sistem Terdistribusi 2.0
T2 Waktu respons atau tujuan kinerja hasil 1.0
T3 Efisiensi pengguna akhir 1.0
T4 Pemrosesan internal yang kompleks 1.0
T5 Kode harus dapat digunakan kembali 1.0
T6 Mudah dipasang 0,5
T7 Mudah digunakan 0,5
T8 Portabel 2.0
T9 Mudah diubah 1.0
T10 Bersamaan 1.0
T11 Termasuk tujuan keamanan khusus 1.0
T12 Memberikan akses langsung untuk pihak ketiga 1.0
T13 Fasilitas pelatihan pengguna khusus diperlukan 1.0
Total Technical Factor (TFactor)

Step 2.5 - Hitung Faktor Kompleksitas Teknis (TCF) sebagai -

TCF = 0.6 + (0.01 × TFactor)

Langkah 3: Sesuaikan Untuk Kompleksitas Lingkungan

Step 3.1 - Pertimbangkan 8 Faktor Lingkungan yang dapat mempengaruhi pelaksanaan proyek dan Bobotnya yang sesuai seperti yang diberikan dalam tabel berikut -

Faktor Deskripsi Bobot
F1 Akrab dengan model proyek yang digunakan 1.5
F2 Pengalaman aplikasi 0,5
F3 Pengalaman berorientasi objek 1.0
F4 Kemampuan analis utama 0,5
F5 Motivasi 1.0
F6 Persyaratan yang stabil 2.0
F7 Staf paruh waktu -1.0
F8 Bahasa pemrograman yang sulit -1.0

Step 3.2 - Untuk masing-masing dari 8 Faktor, nilai proyek dan nilai dari 0 (tidak relevan) hingga 5 (sangat penting).

Step 3.3 - Hitung Dampak Faktor dari Bobot Dampak Faktor dan Nilai Nilai untuk proyek sebagai

Impact of the Factor = Impact Weight × Rated Value

Step 3.4- Hitung jumlah Dampak dari semua Faktor. Ini memberikan Faktor Lingkungan Total (EFactor) seperti yang diberikan dalam tabel berikut -

Faktor Deskripsi Berat (W) Nilai Nilai (0 hingga 5) (RV) Dampak (I = W × RV)
F1 Akrab dengan model proyek yang digunakan 1.5
F2 Pengalaman aplikasi 0,5
F3 Pengalaman berorientasi objek 1.0
F4 Kemampuan analis utama 0,5
F5 Motivasi 1.0
F6 Persyaratan yang stabil 2.0
F7 Staf paruh waktu -1.0
F8 Bahasa pemrograman yang sulit -1.0
Total Environment Factor (EFactor)

Step 3.5 - Hitung Faktor Lingkungan (EF) sebagai -

1.4 + (-0.03 × EFactor)

Langkah 4: Hitung Poin Kasus Penggunaan yang Disesuaikan (UCP)

Hitung Titik Kasus Penggunaan yang Disesuaikan (UCP) sebagai -

UCP = UUCP × TCF × EF

Keuntungan dan Kerugian dari Use-Case Points

Keuntungan dari Use-Case Points

  • UCP didasarkan pada kasus penggunaan dan dapat diukur di awal siklus hidup proyek.

  • UCP (perkiraan ukuran) tidak bergantung pada ukuran, keterampilan, dan pengalaman tim yang melaksanakan proyek.

  • Estimasi berbasis UCP ditemukan mendekati aktual ketika estimasi dilakukan oleh orang yang berpengalaman.

  • UCP mudah digunakan dan tidak memerlukan analisis tambahan.

  • Kasus penggunaan digunakan secara luas sebagai metode pilihan untuk mendeskripsikan persyaratan. Dalam kasus seperti itu, UCP adalah teknik estimasi yang paling sesuai.

Kerugian dari Use-Case Points

  • UCP hanya dapat digunakan jika persyaratan ditulis dalam bentuk use case.

  • Bergantung pada kasus penggunaan yang berorientasi pada tujuan dan ditulis dengan baik. Jika kasus penggunaan tidak terstruktur dengan baik atau seragam, UCP yang dihasilkan mungkin tidak akurat.

  • Faktor teknis dan lingkungan berdampak tinggi pada UCP. Perhatian perlu diberikan saat menetapkan nilai pada faktor teknis dan lingkungan.

  • UCP berguna untuk perkiraan awal dari keseluruhan ukuran proyek tetapi mereka jauh kurang berguna dalam mendorong pekerjaan iterasi-ke-iterasi sebuah tim.

Delphi Methodadalah teknik komunikasi terstruktur, awalnya dikembangkan sebagai metode prakiraan sistematis dan interaktif yang bergantung pada panel ahli. Para ahli menjawab kuesioner dalam dua putaran atau lebih. Setelah setiap putaran, fasilitator memberikan ringkasan anonim dari perkiraan para ahli dari putaran sebelumnya beserta alasan penilaian mereka. Para ahli kemudian didorong untuk merevisi jawaban mereka sebelumnya dengan mempertimbangkan jawaban dari anggota panel lainnya.

Diyakini bahwa selama proses ini kisaran jawaban akan berkurang dan kelompok akan menyatu menuju jawaban yang "benar". Akhirnya, proses dihentikan setelah kriteria berhenti yang telah ditentukan (misalnya jumlah putaran, pencapaian konsensus, dan stabilitas hasil) dan nilai rata-rata atau median dari putaran final menentukan hasil.

Metode Delphi dikembangkan pada 1950-1960-an di RAND Corporation.

Teknik Wideband Delphi

Pada 1970-an, Barry Boehm dan John A. Farquhar menciptakan Varian Pita Lebar dari Metode Delphi. Istilah "pita lebar" digunakan karena, dibandingkan dengan Metode Delphi, Teknik Pita Lebar Delphi melibatkan interaksi yang lebih besar dan lebih banyak komunikasi antara peserta.

Dalam Wideband Delphi Technique, tim penaksir terdiri dari manajer proyek, moderator, ahli, dan perwakilan dari tim pengembangan, yang terdiri dari 3-7 tim anggota. Ada dua pertemuan -

  • Pertemuan Kickoff
  • Estimasi Rapat

Teknik Wideband Delphi - Langkah

Step 1 - Pilih tim Estimasi dan moderator.

Step 2- Moderator melakukan pertemuan awal, di mana tim disajikan dengan spesifikasi masalah dan daftar tugas tingkat tinggi, asumsi atau batasan proyek. Tim membahas masalah dan estimasi masalah, jika ada. Mereka juga memutuskan unit estimasi. Moderator memandu seluruh diskusi, memantau waktu dan setelah pertemuan awal, menyiapkan dokumen terstruktur yang berisi spesifikasi masalah, daftar tugas tingkat tinggi, asumsi, dan unit estimasi yang diputuskan. Dia kemudian meneruskan salinan dokumen ini untuk langkah berikutnya.

Step 3 - Setiap anggota tim Estimasi kemudian secara individu menghasilkan WBS terperinci, memperkirakan setiap tugas di WBS, dan mendokumentasikan asumsi yang dibuat.

Step 4- Moderator memanggil tim Estimasi untuk pertemuan Estimasi. Jika ada anggota tim Estimasi yang menanggapi dengan mengatakan bahwa perkiraan belum siap, moderator memberikan lebih banyak waktu dan mengirim ulang Undangan Rapat.

Step 5 - Seluruh tim Estimasi berkumpul untuk rapat estimasi.

Step 5.1 - Di awal pertemuan Estimasi, moderator mengumpulkan estimasi awal dari masing-masing anggota tim.

Step 5.2- Dia kemudian membuat grafik di papan tulis. Dia memplot perkiraan proyek total setiap anggota sebagai X pada baris Putaran 1, tanpa mengungkapkan nama yang sesuai. Tim Estimasi mendapat gambaran tentang kisaran estimasi, yang awalnya mungkin besar.

Step 5.3- Setiap anggota tim membacakan dengan lantang daftar tugas terperinci yang dia buat, mengidentifikasi asumsi apa pun yang dibuat dan mengajukan pertanyaan atau masalah apa pun. Perkiraan tugas tidak diungkapkan.

Daftar tugas terperinci individu berkontribusi ke daftar tugas yang lebih lengkap saat digabungkan.

Step 5.4 - Tim kemudian mendiskusikan keraguan / masalah yang mereka miliki tentang tugas yang telah mereka capai, asumsi yang dibuat, dan masalah estimasi.

Step 5.5- Setiap anggota tim kemudian meninjau kembali daftar tugas dan asumsinya, dan membuat perubahan jika perlu. Perkiraan tugas juga mungkin memerlukan penyesuaian berdasarkan diskusi, yang dicatat sebagai + N Jam. untuk usaha lebih dan –N Jam. untuk sedikit usaha.

Anggota tim kemudian menggabungkan perubahan dalam perkiraan tugas untuk sampai pada perkiraan proyek total.

Step 5.6 - Moderator mengumpulkan perkiraan yang diubah dari semua anggota tim dan memplotnya di baris Putaran 2.

Pada babak ini, rentangnya akan lebih sempit dibandingkan dengan yang sebelumnya, karena lebih berbasis konsensus.

Step 5.7 - Tim kemudian membahas modifikasi tugas yang telah mereka buat dan asumsinya.

Step 5.8- Setiap anggota tim kemudian meninjau kembali daftar tugas dan asumsinya, dan membuat perubahan jika perlu. Perkiraan tugas mungkin juga memerlukan penyesuaian berdasarkan diskusi.

Anggota tim kemudian sekali lagi menggabungkan perubahan dalam perkiraan tugas untuk sampai pada perkiraan proyek total.

Step 5.9 - Moderator mengumpulkan estimasi yang diubah dari semua anggota lagi dan memplotnya di baris Putaran 3.

Sekali lagi, di babak ini, jangkauannya akan lebih sempit dibandingkan dengan babak sebelumnya.

Step 5.10 - Langkah 5.7, 5.8, 5.9 diulang sampai salah satu kriteria berikut terpenuhi -

  • Hasil digabungkan ke kisaran sempit yang dapat diterima.
  • Semua anggota tim tidak mau mengubah perkiraan terbaru mereka.
  • Waktu pertemuan Estimasi yang dialokasikan telah berakhir.

Step 6 - Manajer Proyek kemudian mengumpulkan hasil dari pertemuan Estimasi.

Step 6.1 - Dia menyusun daftar tugas individu dan perkiraan terkait ke dalam daftar tugas utama tunggal.

Step 6.2 - Dia juga menggabungkan daftar asumsi individu.

Step 6.3 - Dia kemudian meninjau daftar tugas akhir dengan tim Estimasi.

Keuntungan dan Kerugian Teknik Wideband Delphi

Keuntungan

  • Wideband Delphi Technique adalah teknik estimasi berbasis konsensus untuk memperkirakan usaha.
  • Berguna saat memperkirakan waktu untuk mengerjakan suatu tugas.
  • Partisipasi orang-orang yang berpengalaman dan mereka memperkirakan secara individual akan menghasilkan hasil yang dapat diandalkan.
  • Orang-orang yang akan melakukan pekerjaan membuat perkiraan sehingga membuat perkiraan yang valid.
  • Anonimitas dipertahankan sepanjang memungkinkan semua orang untuk mengekspresikan hasil mereka dengan percaya diri.
  • Teknik yang sangat sederhana.
  • Asumsi didokumentasikan, dibahas dan disetujui.

Kekurangan

  • Dukungan manajemen diperlukan.
  • Hasil estimasi tersebut mungkin tidak sesuai dengan keinginan manajemen.

Estimasi Tiga Poin melihat tiga nilai -

  • perkiraan paling optimis (O),
  • perkiraan yang paling mungkin (M), dan
  • perkiraan pesimis (perkiraan paling mungkin (L)).

Ada beberapa kebingungan tentang Estimasi Tiga Poin dan PERT di industri. Namun, tekniknya berbeda. Anda akan melihat perbedaannya saat Anda mempelajari kedua teknik tersebut. Juga, pada akhir teknik PERT, perbedaan disusun dan disajikan. Jika Anda ingin melihatnya terlebih dahulu, Anda bisa.

Perkiraan Tiga Titik (E) didasarkan pada rata-rata sederhana dan mengikuti distribusi segitiga.

E = (O + M + L) / 3

Standar Deviasi

Dalam Distribusi Segitiga,

Rata-rata = (O + M + L) / 3

Deviasi Standar = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2]

Langkah Estimasi Tiga Poin

Step 1 - Tiba di WBS.

Step 2 - Untuk setiap tugas, temukan tiga nilai - perkiraan paling optimis (O), perkiraan paling mungkin (M), dan perkiraan pesimistis (L).

Step 3 - Hitung Mean dari tiga nilai.

Mean = (O + M + L) / 3

Step 4- Hitung Perkiraan Tiga titik tugas. Perkiraan Tiga Poin adalah Mean. Karenanya,

E = Mean = (O + M + L) / 3

Step 5 - Hitung Deviasi Standar tugas.

Standard Deviation (SD) = √ [((O − E)2 + (M − E)2 + (L - E)2)/2]

Step 6 - Ulangi Langkah 2, 3, 4 untuk semua Tugas di WBS.

Step 7 - Hitung Perkiraan Tiga poin proyek.

E (Project) = ∑ E (Task)

Step 8 - Hitung Deviasi Standar proyek.

SD (Project) = √ (∑SD (Task)2)

Ubah Perkiraan Proyek menjadi Tingkat Keyakinan

Perkiraan Tiga Poin (E) dan Deviasi Standar (SD) yang dihitung digunakan untuk mengubah perkiraan proyek menjadi "Tingkat Keyakinan".

Konversi tersebut didasarkan sedemikian rupa sehingga -

  • Tingkat Keyakinan di E +/– SD sekitar 68%.
  • Tingkat Keyakinan dalam nilai E +/– 1.645 × SD kira-kira 90%.
  • Tingkat Keyakinan dalam nilai E +/– 2 × SD kira-kira 95%.
  • Confidence Level pada nilai E +/– 3 × SD kira-kira 99,7%.

Umumnya, Tingkat Keyakinan 95%, yaitu, Nilai E + 2 × SD, digunakan untuk semua perkiraan proyek dan tugas.

Estimasi Project Evaluation and Review Technique (PERT) mempertimbangkan tiga nilai: estimasi paling optimis (O), estimasi paling mungkin (M), dan estimasi pesimistik (estimasi paling kecil (L)). Ada beberapa kebingungan tentang Estimasi Tiga Poin dan PERT di Industri. Namun, tekniknya berbeda. Anda akan melihat perbedaannya saat Anda mempelajari kedua teknik tersebut. Selain itu, di akhir bab ini, perbedaan disusun dan disajikan.

PERT didasarkan pada tiga nilai - perkiraan paling optimis (O), perkiraan paling mungkin (M), dan perkiraan pesimis (perkiraan paling mungkin (L)). Estimasi yang paling mungkin terjadi berbobot 4 kali lebih banyak daripada dua estimasi lainnya (optimis dan pesimis).

Perkiraan PERT (E) didasarkan pada rata-rata tertimbang dan mengikuti distribusi beta.

E = (O + 4 × M + L)/6

PERT sering digunakan bersama dengan Metode Jalur Kritis (CPM). CPM menceritakan tentang tugas-tugas yang sangat penting dalam proyek tersebut. Jika ada penundaan dalam tugas ini, proyek akan tertunda.

Standar Deviasi

Standar Deviasi (SD) mengukur variabilitas atau ketidakpastian dalam estimasi.

Dalam distribusi beta,

Rata-rata = (O + 4 × M + L) / 6

Standar Deviasi (SD) = (L - O) / 6

Langkah Estimasi PERT

Step (1) - Tiba di WBS.

Step (2) - Untuk setiap tugas, temukan tiga nilai perkiraan paling optimis (O), perkiraan paling mungkin (M), dan perkiraan pesimis (L).

Step (3) - PERT Berarti = (O + 4 × M + L) / 6

PERT Berarti = (O + 4 × M + L) / 3

Step (4) - Hitung Deviasi Standar tugas.

Standar Deviasi (SD) = (L - O) / 6

Step (6) - Ulangi langkah 2, 3, 4 untuk semua tugas di WBS.

Step (7) - Hitung perkiraan PERT proyek.

E (Proyek) = ∑ E (Tugas)

Step (8) - Hitung Deviasi Standar proyek.

SD (Proyek) = √ (ΣSD (Tugas) 2 )

Ubah Perkiraan Proyek menjadi Tingkat Keyakinan

Perkiraan PERT (E) dan Standar Deviasi (SD) sehingga dihitung digunakan untuk mengubah perkiraan proyek ke tingkat kepercayaan.

Konversi itu didasarkan pada hal itu

  • Tingkat kepercayaan di E +/– SD sekitar 68%.
  • Tingkat kepercayaan dalam nilai E +/– 1.645 × SD kira-kira 90%.
  • Tingkat kepercayaan pada nilai E +/– 2 × SD kira-kira 95%.
  • Tingkat kepercayaan pada nilai E +/– 3 × SD kira-kira 99,7%.

Umumnya, tingkat kepercayaan 95%, yaitu, Nilai E + 2 × SD, digunakan untuk semua perkiraan proyek dan tugas.

Perbedaan antara Estimasi Tiga Poin dan PERT

Berikut adalah perbedaan antara Three-Point Estimation dan PERT -

Estimasi Tiga Poin NAKAL
Rata-rata sederhana Rata-rata tertimbang
Mengikuti Distribusi segitiga Mengikuti Distribusi beta
Digunakan untuk proyek berulang kecil Digunakan untuk proyek besar yang tidak berulang, biasanya proyek R&D. Digunakan bersama dengan Metode Jalur Kritis (CPM)

E = Rata-rata = (O + M + L) / 3

Ini rata-rata sederhana

E = Rata-rata = (O + 4 × M + L) / 6

Ini adalah rata-rata tertimbang

SD = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2] SD = (L - O) / 6

Analogous Estimationmenggunakan informasi proyek masa lalu yang serupa untuk memperkirakan durasi atau biaya proyek Anda saat ini, oleh karena itu kata, "analogi". Anda dapat menggunakan estimasi analogi jika informasi terbatas mengenai proyek Anda saat ini.

Seringkali, akan ada situasi ketika manajer proyek akan diminta untuk memberikan perkiraan biaya dan durasi untuk proyek baru karena eksekutif membutuhkan data pengambilan keputusan untuk memutuskan apakah proyek tersebut layak dilakukan. Biasanya, baik manajer proyek maupun orang lain dalam organisasi tidak pernah melakukan proyek seperti yang baru tetapi eksekutif masih menginginkan perkiraan biaya dan durasi yang akurat.

Dalam kasus seperti itu, estimasi analog adalah solusi terbaik. Ini mungkin tidak sempurna tetapi akurat karena didasarkan pada data masa lalu. Estimasi analogi adalah teknik yang mudah diterapkan. Tingkat keberhasilan proyek bisa mencapai 60% dibandingkan dengan perkiraan awal.

Estimasi Analog - Definisi

Estimasi analogi merupakan suatu teknik yang menggunakan nilai-nilai parameter dari data historis sebagai dasar untuk mengestimasi parameter serupa untuk kegiatan di masa mendatang. Contoh parameter: Cakupan, biaya, dan durasi. Ukuran contoh skala - Ukuran, berat, dan kompleksitas.

Karena manajer proyek, dan mungkin pengalaman dan penilaian tim diterapkan pada proses estimasi, ini dianggap sebagai kombinasi informasi historis dan penilaian ahli.

Persyaratan Estimasi Analog

Untuk estimasi analog, berikut adalah persyaratannya -

  • Data dari proyek sebelumnya dan yang sedang berlangsung
    • Jam kerja per minggu dari setiap anggota tim
    • Biaya yang dikeluarkan untuk menyelesaikan proyek
  • Proyek dekat dengan proyek saat ini
  • Jika Proyek saat ini baru, dan tidak ada proyek sebelumnya yang serupa
    • Modul dari proyek sebelumnya yang serupa dengan yang ada di proyek saat ini
    • Kegiatan dari proyek masa lalu yang serupa dengan proyek saat ini
    • Data dari yang terpilih ini
  • Partisipasi manajer proyek dan tim estimasi untuk memastikan penilaian berpengalaman atas estimasi.

Langkah Estimasi Analog

Manajer proyek dan tim harus secara kolektif melakukan estimasi analog.

  • Step 1 - Identifikasi domain proyek saat ini.

  • Step 2 - Identifikasi teknologi proyek saat ini.

  • Step 3- Cari di database organisasi jika data proyek serupa tersedia. Jika tersedia, lanjutkan ke Langkah (4). Jika tidak, lanjutkan ke Langkah (6).

  • Step 4 - Bandingkan proyek saat ini dengan data proyek masa lalu yang teridentifikasi.

  • Step 5- Tiba pada perkiraan durasi dan biaya proyek saat ini. Ini mengakhiri estimasi analog dari proyek.

  • Step 6 - Lihat di database organisasi jika ada proyek sebelumnya yang memiliki modul serupa dengan yang ada di proyek saat ini.

  • Step 7 - Cari di database organisasi jika ada proyek masa lalu yang memiliki aktivitas serupa dengan proyek saat ini.

  • Step 8 - Kumpulkan semua itu dan gunakan penilaian ahli untuk sampai pada perkiraan durasi dan biaya proyek saat ini.

Keuntungan Estimasi Analog

  • Estimasi analog adalah cara estimasi yang lebih baik pada tahap awal proyek ketika sangat sedikit detail yang diketahui.

  • Tekniknya sederhana dan waktu yang dibutuhkan untuk estimasi sangat sedikit.

  • Tingkat keberhasilan organisasi dapat diharapkan tinggi karena teknik ini didasarkan pada data proyek organisasi sebelumnya.

  • Estimasi analogi dapat digunakan untuk memperkirakan upaya dan durasi tugas individu juga. Karenanya, di WBS saat Anda memperkirakan tugas, Anda dapat menggunakan Analogy.

Work Breakdown Structure (WBS), dalam Manajemen Proyek dan Rekayasa Sistem, adalah dekomposisi proyek yang berorientasi hasil menjadi komponen yang lebih kecil. WBS adalah penyampaian proyek utama yang mengatur pekerjaan tim ke dalam bagian yang dapat dikelola. Badan Pengetahuan Manajemen Proyek (PMBOK) mendefinisikan WBS sebagai "dekomposisi hirarkis berorientasi hasil dari pekerjaan yang akan dilaksanakan oleh tim proyek."

Elemen WBS dapat berupa produk, data, layanan, atau kombinasinya. WBS juga menyediakan kerangka kerja yang diperlukan untuk estimasi biaya rinci dan kontrol bersama dengan memberikan panduan untuk pengembangan dan kontrol jadwal.

Representasi WBS

WBS direpresentasikan sebagai daftar hierarki dari aktivitas pekerjaan proyek. Ada dua format WBS -

  • Outline View (Format Indentasi)
  • Tampilan Struktur Pohon (Bagan Organisasi)

Mari kita bahas terlebih dahulu bagaimana menggunakan tampilan garis besar untuk menyiapkan WBS.

Tampilan Garis Besar

Tampilan garis besar adalah tata letak yang sangat ramah pengguna. Ini menyajikan pandangan yang baik dari keseluruhan proyek dan memungkinkan modifikasi yang mudah juga. Ini menggunakan angka untuk mencatat berbagai tahapan proyek. Ini terlihat agak mirip dengan berikut -

  • Software Development

    • Scope

      • Tentukan ruang lingkup proyek
      • Amankan sponsor proyek
      • Tentukan sumber daya awal
      • Amankan sumber daya inti
      • Cakupan selesai
    • Analysis/Software Requirements

      • Lakukan analisis kebutuhan
      • Buat draf spesifikasi perangkat lunak awal
      • Kembangkan anggaran awal
      • Tinjau spesifikasi / anggaran perangkat lunak dengan tim
      • Sertakan umpan balik tentang spesifikasi perangkat lunak
      • Kembangkan jadwal pengiriman
      • Dapatkan persetujuan untuk melanjutkan (konsep, jadwal, dan anggaran)
      • Amankan sumber daya yang dibutuhkan
      • Analisis selesai
    • Design

      • Tinjau spesifikasi perangkat lunak awal
      • Kembangkan spesifikasi fungsional
      • Dapatkan persetujuan untuk melanjutkan
      • Desain selesai
    • Development

      • Tinjau spesifikasi fungsional
      • Identifikasi parameter desain modular / berjenjang
      • Kembangkan kode
      • Pengujian pengembang (debugging utama)
      • Pengembangan selesai
    • Testing

      • Kembangkan rencana pengujian unit menggunakan spesifikasi produk
      • Kembangkan rencana uji integrasi menggunakan spesifikasi produk
    • Training

      • Kembangkan spesifikasi pelatihan untuk pengguna akhir
      • Identifikasi metodologi penyampaian pelatihan (online, ruang kelas, dll.)
      • Kembangkan materi pelatihan
      • Selesaikan materi pelatihan
      • Kembangkan mekanisme penyampaian pelatihan
      • Materi pelatihan selesai
    • Deployment

      • Tentukan strategi penerapan akhir
      • Kembangkan metodologi penerapan
      • Sumber daya penyebaran yang aman
      • Latih staf pendukung
      • Terapkan perangkat lunak
      • Penerapan selesai

Sekarang mari kita lihat tampilan struktur pohon.

Tampilan Struktur Pohon

Tampilan Struktur Pohon menyajikan tampilan keseluruhan proyek yang sangat mudah dipahami. Ilustrasi berikut memperlihatkan bagaimana tampilan struktur pohon terlihat. Jenis struktur bagan organisasi ini dapat dengan mudah digambar dengan fitur-fitur yang tersedia di MS-Word.

Jenis-jenis WBS

Ada dua jenis WBS -

  • Functional WBS- Pada WBS fungsional, sistem dipecah berdasarkan fungsi pada aplikasi yang akan dikembangkan. Ini berguna dalam memperkirakan ukuran sistem.

  • Activity WBS- Dalam aktivitas WBS, sistem dipecah berdasarkan aktivitas di sistem. Kegiatan tersebut selanjutnya dipecah menjadi tugas. Ini berguna untuk memperkirakan upaya dan jadwal dalam sistem.

Perkiraan Ukuran

Step 1 - Mulailah dengan WBS fungsional.

Step 2 - Perhatikan ruas daun.

Step 3 - Gunakan Analogy atau Wideband Delphi untuk mendapatkan perkiraan ukuran.

Perkirakan Upaya

Step 1- Gunakan Teknik Wideband Delphi untuk membangun WBS. Kami menyarankan agar tugas tidak lebih dari 8 jam. Jika tugas memiliki durasi yang lebih lama, pisahkan.

Step 2 - Gunakan Teknik Wideband Delphi atau Estimasi Tiga Titik untuk sampai pada Estimasi Upaya untuk Tugas.

Penjadwalan

Setelah WBS siap dan ukuran serta perkiraan upaya diketahui, Anda siap untuk menjadwalkan tugas.

Saat menjadwalkan tugas, hal-hal tertentu harus dipertimbangkan -

  • Precedence - Sebuah tugas yang harus terjadi sebelum yang lain dikatakan didahulukan dari yang lain.

  • Concurrence - Tugas bersamaan adalah tugas yang dapat terjadi pada waktu yang sama (secara paralel).

  • Critical Path - Kumpulan tugas berurutan tertentu yang menjadi dasar tanggal penyelesaian proyek.

    • Semua proyek memiliki jalur kritis.
    • Mempercepat tugas tidak penting tidak secara langsung mempersingkat jadwal.

Metode Jalur Kritis

Metode Jalur Kritis (CPM) adalah proses untuk menentukan dan mengoptimalkan jalur kritis. Tugas jalur non-kritis dapat dimulai lebih awal atau lebih lambat tanpa memengaruhi tanggal penyelesaian.

Harap dicatat bahwa jalur kritis dapat berubah ke jalur lain saat Anda mempersingkat jalur saat ini. Misalnya, untuk WBS pada gambar sebelumnya, jalur kritisnya adalah sebagai berikut -

Karena tanggal penyelesaian proyek didasarkan pada serangkaian tugas berurutan, tugas ini disebut tugas kritis.

Tanggal penyelesaian proyek tidak didasarkan pada pelatihan, dokumentasi, dan penerapan. Tugas semacam itu disebut tugas tidak kritis.

Hubungan Ketergantungan Tugas

Waktu tertentu, saat menjadwalkan, Anda mungkin harus mempertimbangkan hubungan ketergantungan tugas. Hubungan Ketergantungan Tugas yang penting adalah -

  • Selesai-untuk-Mulai (FS)
  • Selesai-sampai-Selesai (FF)

Selesai-untuk-Mulai (FS)

Dalam hubungan ketergantungan tugas Selesai-untuk-Mulai (FS), Tugas B tidak dapat dimulai hingga Tugas A selesai.

Selesai-sampai-Selesai (FF)

Dalam hubungan ketergantungan tugas Selesai-untuk-Selesai (FF), Tugas B tidak dapat diselesaikan hingga Tugas A selesai.

Bagan Gantt

Bagan Gantt adalah jenis bagan batang, diadaptasi oleh Karol Adamiecki pada tahun 1896 dan secara independen oleh Henry Gantt pada tahun 1910-an, yang menggambarkan jadwal proyek. Bagan Gantt mengilustrasikan tanggal mulai dan selesai dari elemen terminal dan elemen ringkasan sebuah proyek.

Anda dapat mengambil Format Garis Besar pada Gambar 2 ke dalam Microsoft Project untuk mendapatkan Tampilan Bagan Gantt.

Tonggak Sejarah

Tonggak pencapaian adalah tahapan penting dalam jadwal Anda. Mereka akan memiliki durasi nol dan digunakan untuk menandai bahwa Anda telah menyelesaikan serangkaian tugas tertentu. Tonggak sejarah biasanya ditampilkan sebagai berlian.

Misalnya, di Bagan Gantt di atas, Desain Selesai dan Pengembangan Selesai ditampilkan sebagai pencapaian, diwakili dengan bentuk berlian.

Tonggak pencapaian dapat dikaitkan dengan Persyaratan Kontrak.

Keuntungan Estimasi menggunakan WBS

WBS sangat menyederhanakan proses estimasi proyek. Ini menawarkan keuntungan berikut dibandingkan teknik estimasi lainnya -

  • Di WBS, seluruh pekerjaan yang harus dilakukan oleh proyek diidentifikasi. Oleh karena itu, dengan meninjau WBS dengan pemangku kepentingan proyek, Anda akan cenderung mengabaikan pekerjaan apa pun yang diperlukan untuk memberikan hasil proyek yang diinginkan.

  • WBS menghasilkan perkiraan biaya dan jadwal yang lebih akurat.

  • Manajer proyek mendapatkan partisipasi tim untuk menyelesaikan WBS. Keterlibatan tim ini menimbulkan antusiasme dan tanggung jawab dalam proyek.

  • WBS memberikan dasar untuk penugasan tugas. Karena tugas yang tepat dialokasikan kepada anggota tim tertentu yang akan bertanggung jawab atas pencapaiannya.

  • WBS memungkinkan pemantauan dan pengendalian pada tingkat tugas. Ini memungkinkan Anda mengukur kemajuan dan memastikan bahwa proyek Anda akan selesai tepat waktu.

Perencanaan Estimasi Poker

Perencanaan Poker adalah teknik berbasis konsensus untuk memperkirakan, sebagian besar digunakan untuk memperkirakan usaha atau ukuran relatif dari cerita pengguna di Scrum.

Perencanaan Poker menggabungkan tiga teknik estimasi - Teknik Wideband Delphi, Estimasi Analog, dan Estimasi menggunakan WBS.

Perencanaan Poker pertama kali didefinisikan dan dinamai oleh James Grenning pada tahun 2002 dan kemudian dipopulerkan oleh Mike Cohn dalam bukunya "Agile Estimating and Planning", yang perdagangan perusahaannya menandai istilah tersebut.

Perencanaan Teknik Estimasi Poker

Dalam Teknik Estimasi Poker Perencanaan, perkiraan untuk cerita pengguna diperoleh dengan bermain poker perencanaan. Seluruh tim Scrum terlibat dan ini menghasilkan perkiraan yang cepat namun dapat diandalkan.

  • Perencanaan Poker dimainkan dengan setumpuk kartu. Saat deret Fibonacci digunakan, kartu memiliki angka - 1, 2, 3, 5, 8, 13, 21, 34, dll. Angka-angka ini mewakili “Poin Cerita”. Setiap penaksir memiliki setumpuk kartu. Angka pada kartu harus cukup besar agar dapat dilihat oleh semua anggota tim, ketika salah satu anggota tim memegang sebuah kartu.

  • Salah satu anggota tim dipilih sebagai Moderator. Moderator membaca deskripsi dari cerita pengguna yang sedang dibuat perkiraannya. Jika estimator memiliki pertanyaan, product owner menjawabnya.

  • Setiap penaksir secara pribadi memilih kartu yang mewakili perkiraannya. Kartu tidak akan ditampilkan sampai semua penaksir telah membuat pilihan. Pada saat itu, semua kartu secara bersamaan dibalik dan diangkat sehingga semua anggota tim dapat melihat perkiraan masing-masing.

  • Pada babak pertama, kemungkinan besar estimasi bervariasi. Estimator tinggi dan rendah menjelaskan alasan estimasi mereka. Harus diperhatikan bahwa semua diskusi dimaksudkan untuk pemahaman saja dan tidak ada yang dianggap pribadi. Moderator harus memastikan hal yang sama.

  • Tim dapat mendiskusikan cerita dan perkiraan mereka selama beberapa menit.

  • Moderator dapat membuat catatan tentang diskusi yang akan membantu saat cerita tertentu dikembangkan. Setelah pembahasan, setiap estimator melakukan estimasi ulang dengan memilih kembali sebuah kartu. Kartu sekali lagi dirahasiakan sampai semua orang memperkirakan, pada titik mana mereka akan diserahkan pada waktu yang sama.

Ulangi proses tersebut hingga perkiraan bertemu dengan satu perkiraan yang dapat digunakan untuk cerita. Jumlah putaran estimasi dapat bervariasi dari satu cerita pengguna ke cerita pengguna lainnya.

Manfaat Perencanaan Estimasi Poker

Perencanaan poker menggabungkan tiga metode estimasi -

Expert Opinion- Dalam pendekatan estimasi expert opinion based, seorang expert ditanyai berapa lama sesuatu akan berlangsung atau seberapa besar akan terjadi. Pakar memberikan perkiraan berdasarkan pengalaman atau intuisi atau firasatnya. Estimasi Opini Ahli biasanya tidak memakan banyak waktu dan lebih akurat dibandingkan dengan beberapa metode analisis.

Analogy- Estimasi analogi menggunakan perbandingan cerita pengguna. Kisah pengguna yang diperkirakan dibandingkan dengan kisah pengguna serupa yang diterapkan sebelumnya, memberikan hasil yang akurat karena perkiraan didasarkan pada data yang terbukti.

Disaggregation- Estimasi disagregasi dilakukan dengan membagi cerita pengguna menjadi cerita pengguna yang lebih kecil dan lebih mudah diperkirakan. Cerita pengguna yang akan dimasukkan dalam sprint biasanya dalam rentang dua hingga lima hari untuk dikembangkan. Oleh karena itu, cerita pengguna yang mungkin membutuhkan durasi lebih lama perlu dipecah menjadi Kasus penggunaan yang lebih kecil. Pendekatan ini juga memastikan bahwa akan ada banyak cerita yang bisa dibandingkan.

Upaya pengujian tidak didasarkan pada kerangka waktu yang pasti. Upaya berlanjut hingga beberapa jadwal yang ditentukan sebelumnya ditetapkan, terlepas dari penyelesaian pengujian.

Hal ini sebagian besar disebabkan oleh fakta bahwa secara konvensional, test effort estimation adalah bagian dari development estimation. Hanya dalam hal teknik estimasi yang menggunakan WBS, seperti Wideband Delphi, Three-point Estimation, PERT, dan WBS, Anda dapat memperoleh nilai estimasi dari aktivitas pengujian.

Jika Anda telah memperoleh perkiraan sebagai Titik Fungsi (FP), maka menurut Caper Jones,

Number of Test Cases = (Number of Function Points) × 1.2

Setelah Anda memiliki jumlah kasus pengujian, Anda dapat mengambil data produktivitas dari database organisasi dan sampai pada upaya yang diperlukan untuk pengujian.

Persentase Metode Upaya Pengembangan

Upaya uji yang diperlukan adalah proporsional atau persentase langsung dari upaya pengembangan. Upaya pengembangan dapat diperkirakan menggunakan Lines of Code (LOC) atau Function Points (FP). Kemudian, persentase usaha untuk pengujian diperoleh dari Database Organisasi. Persentase yang diperoleh digunakan untuk sampai pada perkiraan upaya untuk pengujian.

Memperkirakan Proyek Pengujian

Beberapa organisasi sekarang menyediakan layanan verifikasi dan validasi independen kepada klien mereka dan itu berarti aktivitas proyek sepenuhnya akan menjadi aktivitas pengujian.

Memperkirakan proyek pengujian memerlukan pengalaman pada berbagai proyek untuk siklus hidup pengujian perangkat lunak. Saat Anda memperkirakan proyek pengujian, pertimbangkan -

  • Keterampilan tim
  • Pengetahuan Domain
  • Kompleksitas aplikasi
  • Data historis
  • Siklus bug untuk proyek tersebut
  • Ketersediaan sumber daya
  • Variasi produktivitas
  • Lingkungan sistem dan waktu henti

Menguji Teknik Estimasi

Teknik estimasi pengujian berikut terbukti akurat dan banyak digunakan -

  • Teknik estimasi pengujian perangkat lunak PERT
  • Metode UCP
  • WBS
  • Teknik Wideband Delphi
  • Analisis titik fungsi / titik pengujian
  • Distribusi persentase
  • Teknik estimasi pengujian berbasis pengalaman

Teknik Estimasi Pengujian Perangkat Lunak PERT

Teknik estimasi pengujian perangkat lunak PERT didasarkan pada metode statistik di mana setiap tugas pengujian dipecah menjadi sub-tugas dan kemudian tiga jenis estimasi dilakukan pada setiap sub-tugas.

Rumus yang digunakan oleh teknik ini adalah -

Test Estimate = (O + (4 × M) + E)/6

Dimana,

O = Perkiraan optimis (skenario kasus terbaik di mana tidak ada yang salah dan semua kondisi optimal).

M = Perkiraan yang paling mungkin (kemungkinan besar durasi dan mungkin ada beberapa masalah tetapi sebagian besar hal akan berjalan lancar).

L = Perkiraan pesimis (skenario kasus terburuk di mana semuanya berjalan salah).

Deviasi Standar untuk teknik ini dihitung sebagai -

Standard Deviation (SD) = (E − O)/6

Metode Use-Case Point

Metode UCP didasarkan pada kasus penggunaan di mana kami menghitung bobot aktor yang tidak disesuaikan dan bobot kasus penggunaan yang tidak disesuaikan untuk menentukan estimasi pengujian perangkat lunak.

Use-case adalah dokumen yang menentukan pengguna, sistem, atau pemangku kepentingan lain yang berinteraksi dengan aplikasi terkait. Mereka disebut sebagai "Aktor". Interaksi tersebut mencapai beberapa tujuan yang ditentukan melindungi kepentingan semua pemangku kepentingan melalui perilaku atau aliran yang berbeda yang disebut sebagai skenario.

Step 1- Hitung tidak. aktor. Aktor termasuk positif, negatif dan luar biasa.

Step 2 - Hitung bobot aktor yang tidak disesuaikan sebagai

Unadjusted Actor Weights = Total no. of Actors

Step 3 - Hitung jumlah kasus penggunaan.

Step 4 - Hitung bobot kasus penggunaan yang tidak disesuaikan sebagai

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 - Hitung poin kasus penggunaan yang tidak disesuaikan sebagai

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6- Tentukan faktor teknis / lingkungan (TEF). Jika tidak tersedia, anggap sebagai 0,50.

Step 7 - Hitung titik kasus penggunaan yang disesuaikan sebagai

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 - Hitung usaha total sebagai

Total Effort = Adjusted Use-Case Point × 2

Struktur rincian kerja

Step 1 - Buat WBS dengan memecah proyek uji menjadi bagian-bagian kecil.

Step 2 - Bagilah modul menjadi sub-modul.

Step 3 Bagilah sub-modul lebih lanjut menjadi beberapa fungsi.

Step 4 - Membagi fungsionalitas menjadi sub-fungsi.

Step 5 - Tinjau semua persyaratan pengujian untuk memastikannya ditambahkan di WBS.

Step 6 - Cari tahu jumlah tugas yang harus diselesaikan tim Anda.

Step 7 - Perkirakan upaya untuk setiap tugas.

Step 8 - Perkirakan durasi setiap tugas.

Teknik Wideband Delphi

Dalam Metode Wideband Delphi, WBS didistribusikan ke tim yang terdiri dari 3-7 anggota untuk memperkirakan ulang tugas. Estimasi akhir adalah hasil estimasi yang dirangkum berdasarkan konsensus tim.

Metode ini lebih banyak berbicara tentang pengalaman daripada rumus statistik apa pun. Metode ini dipopulerkan oleh Barry Boehm untuk menekankan pada iterasi kelompok untuk mencapai konsensus di mana tim memvisualisasikan berbagai aspek masalah sambil memperkirakan upaya pengujian.

Analisis Titik Fungsi / Titik Pengujian

FP menunjukkan fungsionalitas aplikasi perangkat lunak dari perspektif pengguna dan digunakan sebagai teknik untuk memperkirakan ukuran proyek perangkat lunak.

Dalam pengujian, estimasi didasarkan pada dokumen spesifikasi kebutuhan, atau pada prototipe aplikasi yang dibuat sebelumnya. Untuk menghitung FP suatu proyek, diperlukan beberapa komponen utama. Mereka adalah -

  • Unadjusted Data Function Points - i) File Internal, ii) Antarmuka Eksternal

  • Unadjusted Transaction Function Points - i) Masukan Pengguna, ii) Keluaran Pengguna & iii) Pertanyaan Pengguna

  • Capers Jones basic formula -

    Jumlah Kasus Uji = (Jumlah Titik Fungsi) × 1.2

  • Total Actual Effort (TAE) -

    (Jumlah Kasus Uji) × (Persentase Upaya Pengembangan / 100)

Distribusi Persentase

Dalam teknik ini, semua fase Siklus Hidup Pengembangan Perangkat Lunak (SDLC) diberikan usaha dalam%. Ini dapat didasarkan pada data sebelumnya dari proyek serupa. Misalnya -

Tahap % of Effort
Project Management 7%
Requirements 9%
Design 16%
Coding 26%
Testing (all Test Phases) 27%
Documentation 9%
Installation and Training 6%

Next, % of effort for testing (all test phases) is further distributed for all Testing Phases −

All Testing Phases % of Effort
Component Testing 16
Independent Testing 84
Total 100
Independent Testing % of Effort
Integration Testing 24
System Testing 52
Acceptance Testing 24
Total 100
System Testing % of Effort
Functional System Testing 65
Non-functional System Testing 35
Total 100
Test Planning and Design Architecture 50%
Review phase 50%

Experience-based Testing Estimation Technique

This technique is based on analogies and experts. The technique assumes that you already tested similar applications in previous projects and collected metrics from those projects. You also collected metrics from previous tests. Take inputs from subject matter experts who know the application (as well as testing) very well and use the metrics you have collected and arrive at the testing effort.