Chapter

7
117006018
117006026
117006031
117006042
117006050

Deppy Sontani Ikbaludin

Irfan Pujiana
Yuki Rizki Adam Nugraha
Muhammad Faisal Sofyan
Holilur Rahman

Pengembangan perangkat lunak melibatkan dua proses konkuren: yaitu

dengan membangun perangkat lunak dan mengujinya. Tidak peduli apakah
pengujian dilakukan oleh pengembang atau independen, yang penting adalah
bahwa seseorang bertanggung jawab untuk pengujian.
Bab ini mendefinisikan tugas untuk mempersiapkan pengujian dan untuk
mengatur tim uji.
Jika pengembang melakukan pengujian, itu mungkin tidak diperlukan tes
untuk memastikan estimasi proyek memadai dan untuk mengembangkan
proses melacak status proyek. Namun, ketika penguji independen melakukan
pengujian, kecuali mereka dapat mengontrol anggaran tes sendiri dan tim
proyek memiliki proses pelaporan status proyek yang efektif, penguji harus
melakukan tugas terakhir.

Objective
Pengujian dapat jatuh jauh dari harapan karena dua alasan. Pertama,
persiapan yang diperlukan mungkin tidak tercapai. Kedua, banyak tugas
pengujian yang tidak pernah selesai karena kurangnya sumber daya yang
dialokasikan.
Tujuan dari bab ini adalah untuk memungkinkan Anda untuk menentukan
ruang lingkup pengujian dan memastikan bahwa waktu yang memadai dan
sumber daya yang tersedia untuk pengujian. Jika pengujian disertakan
dalam anggaran pengembang, manajer uji perlu memastikan bahwa perkiraan
tersebut memadai untuk pengujian. Manajer tes juga harus memastikan
bahwa overruns dalam pengembangan proyek tidak akan membatasi jumlah
pengujian sebagaimana didefinisikan dalam rencana uji.

Workbench
Gambar 7-1 menunjukkan meja kerja untuk mengatur untuk pengujian. Meja
kerja masukan adalah dokumentasi saat ini untuk sistem perangkat lunak
yang diuji. Lima tugas yang terdaftar, namun beberapa tugas mungkin telah
selesai sebelum memulai tugas pertama. Output dari langkah ini adalah tim
uji terorganisir, siap untuk memulai pengujian.
#Gambar

Input
Dua input berikut diperlukan untuk menyelesaikan langkah ini:
1. dokumentasi Proyek. Ini termasuk rencana proyek, tujuan, ruang
lingkup, dan output yang didefinisikan.
2. proses pengembangan perangkat lunak. Ini termasuk prosedur dan
standar untuk diikuti selama pelaksanaan proyek.

Do Procedure
Kelima tugas berikut direkomendasikan untuk mengatur proses pengujian:
1. Menunjuk manajer tes. Jika pengujian merupakan bagian dari upaya pembangunan di-rumah,
pemimpin proyek harus menentukan siapa yang bertanggung jawab untuk pengujian. Jika
pengujian dilakukan oleh penguji independen, manajemen TI harus menunjuk tes manager.
2. Tentukan lingkup pengujian. Manajer uji mendefinisikan ruang lingkup pengujian, meskipun
semua atau sebagian dari lingkup dapat didefinisikan oleh standar pengujian.
3. Menunjuk tim uji. Manajer pengujian, manajer proyek, atau manajemen TI harus menunjuk
tim uji.
4. Pastikan dokumentasi pembangunan. Manajer pengujian harus memverifikasi bahwa
dokumentasi pembangunan yang memadai tersedia untuk melakukan pengujian yang efektif.
5. Validasi proses Status uji estimasi dan proyek. Perkiraan uji dapat dikembangkan oleh salah
satu manajer tes atau manajer proyek.

Tugas 1: Menunjuk Test Manager

Terlepas dari apakah pengujian dilakukan dengan di rumah pengembang
atau independen penguji, seseorang harus bertanggung jawab untuk
pengujian. Manajer pengujian memiliki berikut tanggung jawab:
Menentukan ruang lingkup pengujian
Menunjuk tim uji
Tentukan proses pengujian dan kiriman yang dihasilkan
Menulis / mengawasi rencana uji
Menganalisis hasil tes dan menulis laporan pengujian (s)
Jika manajer tes tidak dapat memenuhi tanggung jawab ini saja, orang
lain harus diserahkan kepada tim uji untuk membantu dia. Tanggung jawab
bisa berubah berdasarkan pada ukuran proyek.

Langkah 1:
Pengorganisasian keterampilan Pengujian dibutuhkan untuk menjadi
manajer tes bervariasi dengan ukuran proyek. Untuk proyek-proyek kecil
(1-2 penguji), tester lebih berpengalaman dapat memenuhi peran manajer,
untuk medium sized proyek (3-5 penguji), manajer uji harus menjadi
seorang tester dan manajer, dan untuk proyek yang lebih besar (6 atau
lebih penguji), keterampilan manajerial yang lebih penting daripada tes
keterampilan.

Tugas 2: Tentukan Lingkup Pengujian

Pasal 1-3 membahas pilihan yang tersedia untuk lingkup pengujian. Secara tradisional,
software pengujian divalidasi bahwa spesifikasi dilaksanakan sebagaimana ditentukan. diskusi
sebelumnya pada lingkup pengujian memperluas definisi yang mencakup menentukan apakah
pengguna kebutuhan terpenuhi, mengidentifikasi apakah proyek dilaksanakan di paling efektif
dan efisien, memastikan sistem perangkat lunak telah memenuhi faktor kualitas yang diinginkan,
dan pengujian untuk atribut perangkat lunak khusus, seperti kecukupan sistem pengendalian
internal, dan sebagainya.
Ruang lingkup pengujian dapat didefinisikan dalam misi uji. Dengan kata lain, jika penguji
adalah untuk memastikan bahwa sistem tersebut memenuhi kebutuhan pengguna, manajer tes
tidak akan menetapkannya dalam lingkup uji. Demikian juga, jika penguji adalah untuk membantu
pengguna dalam mengembangkan dan melaksanakan rencana tes penerimaan, tidak harus
didefinisikan dalam lingkup pengujian untuk proyek tertentu.
Jika misi tes tidak spesifik tentang ruang lingkup pengujian dan / atau ada tujuan khusus
harus diselesaikan dari pengujian, manajer uji harus mendefinisikan ruang lingkup itu. Sekarang
penting untuk memahami ruang lingkup pengujian sebelum mengembangkan rencana uji.

Tugas 3: Menunjuk Test Team

Tim uji merupakan bagian integral dari proses pengujian. Tanpa
formalisasi tim uji, sulit untuk memperkenalkan konsep pengujian formal
dalam pengembangan Proses. Luas "meja pemeriksaan" oleh individu yang
mengembangkan pekerjaan tidak hemat biaya metode pengujian. Kelemahan
seseorang memeriksa sendiri kerja adalah sebagai berikut:
1. Kesalahpahaman tidak akan terdeteksi, karena checker akan
menganggap apa yang ia diberitahu benar.
2. Penggunaan yang tidak benar dari proses pembangunan mungkin tidak
terdeteksi, karena individu mungkin tidak mengerti proses.
3. Individu dapat "buta" untuk menerima hasil tes yang salah karena ia
jatuh ke dalam perangkap yang sama selama pengujian yang
menyebabkan pengenalan cacat di tempat pertama.

Tugas 3: Menunjuk Test Team .

1. Staf IT optimis dalam kemampuan mereka untuk melakukan pekerjaan
bebas cacat dan dengan demikian kadang-kadang meremehkan
kebutuhan untuk pengujian ekstensif.
2. Tanpa divisi formal antara pengembangan perangkat lunak dan
pengujian perangkat lunak, seorang individu mungkin tergoda untuk
memperbaiki
struktur
sistem
dan
dokumentasi
bukannya
mengalokasikan waktu dan usaha untuk proses pengujian.
Bagian ini menjelaskan empat pendekatan untuk menunjuk tim uji (lihat
Gambar 7-2)
#Gambar

Pendekatan Tim internal

Dalam pendekatan tim uji internal, para anggota tim proyek menjadi
anggota dari tim uji. Dalam kebanyakan kasus, pemimpin proyek
pengembangan sistem adalah Tes pemimpin proyek tim. Hal ini tidak perlu
memiliki semua anggota tim pengembangan berpartisipasi pada tim uji,
meskipun tidak ada alasan mengapa mereka tidak bisa. Apa penting adalah
bahwa salah satu anggota dari tim uji akan terutama bertanggung jawab
untuk pengujian kerja anggota lain. Tujuan tim ini adalah untuk membentuk
suatu proses pengujian yang independen orang-orang yang mengembangkan
bagian tertentu dari proyek yang sedang diuji.

Pendekatan Tim internal...

Keuntungan dari pendekatan tim uji internal IT adalah bahwa hal itu
meminimalkan biaya tim uji. Tim proyek sudah bertanggung jawab untuk
pengujian, sehingga dengan anggota proyek di tim uji hanyalah metode
alternatif untuk melakukan tes. Pengujian menggunakan pendekatan tim uji
tidak hanya melatih orang-orang proyek dalam metode pengujian yang baik,
lintas-melatih mereka dalam aspek-aspek lain dari proyek. Tim uji internal
IT Pendekatan menggunakan orang-orang dalam pengujian yang paling luas
tentang proyek.
Kerugian potensial dari pendekatan tim uji internal adalah bahwa tim
tidak akan mengalokasikan waktu yang tepat untuk pengujian. Selain itu,
anggota tim proyek mungkin kurang independensi dan objektivitas dalam
melakukan tes.

Pendekatan Tim Eksternal

Pengujian oleh tim eksternal tidak membebaskan personil proyek tanggung jawab
kebenaran sistem aplikasi. Pendekatan tim eksternal menyediakan extra jaminan
kebenaran pengolahan. Biasanya, pengujian eksternal terjadi setelah tim proyek telah
melakukan pengujian yang dianggap perlu. Para memverifikasi tim pengembangan
bahwa struktur sistem yang benar, dan tim uji independen memverifikasi bahwa
Sistem memenuhi kebutuhan pengguna.
Pengujian eksternal biasanya dilakukan oleh salah satu personil jaminan kualitas
atau Kelompok pengujian profesional di departemen IT. Sementara tim proyek yang
terlibat dalam semua aspek pembangunan, tim uji jaminan kualitas spesialis dalam
pengujian Proses (meskipun sebagian besar individu dalam kelompok-kelompok
pengujian memiliki pengalaman dalam sistem desain dan programming).

Keuntungan dan Kerugian

Keuntungan penguji eksternal adalah perspektif independen mereka bawa ke
proses pengujian. Kelompok ini terdiri dari para profesional TI yang memiliki
spesialisasi di daerah pengujian. Selain itu, kelompok-kelompok ini memiliki
pengalaman pengujian di beberapa proyek dan, dengan demikian, lebih mampu
membangun dan melaksanakan tes dibandingkan orang-orang yang menguji hanya
berkala.
Kerugian pengujian TI eksternal adalah biaya tambahan yang dibutuhkan untuk
membangun dan mengelola fungsi pengujian. Selain itu, tim pengembangan dapat
menempatkan terlalu banyak ketergantungan pada tim uji dan dengan demikian gagal
untuk melakukan pengujian yang memadai sendiri. Selain itu, persaingan antara tim uji
dan tim proyek dapat menyebabkan kerusakan yang kerjasama, sehingga sulit bagi
tim uji berfungsi dengan baik.

Tim Pendekatan non-IT

Pengujian juga dapat dilakukan oleh kelompok-kelompok eksternal untuk
departemen IT. Tiga kelompok umum itu adalah pengguna, auditor, dan
konsultan. Kelompok-kelompok ini mewakili organisasi kebutuhan dan uji atas
nama organisasi. Keuntungan dari tim uji non-IT adalah bahwa mereka
memberikan penilaian independen. Kelompok non-IT tidak dibatasi oleh
kesetiaan untuk melaporkan hasil yang tidak menguntungkan hanya untuk
departemen IT. Kelompok non-IT memiliki kapasitas yang lebih besar untuk
menyebabkan tindakan untuk terjadi sekali masalah yang terdeteksi dari
kelompok dalam departemen IT.
Kerugian dari pengujian non-IT adalah biaya. Umumnya, kelompok ini tidak
terbiasa dengan aplikasi tersebut dan harus terlebih dahulu mempelajari
aplikasi, dan kemudian belajar bagaimana untuk menguji dalam organisasi.

Tim Pendekatan Kombinasi

Dalam pendekatan uji kombinasi tim, salah satu atau semua kelompok sebelumnya dapat
berpartisipasi pada tim uji. Tim Kombinasi dapat dirakit untuk memenuhi kebutuhan pengujian
tertentu. Sebagai contoh, jika proyek memiliki implikasi keuangan yang signifikan, auditor bisa
ditambahkan ke tim uji, jika proyek memiliki masalah komunikasi, komunikasi konsultan bisa
ditambahkan.
Keuntungan dari menggambar pada beberapa keterampilan untuk tim uji untuk
memungkinkan multi-disiplin pendekatan untuk pengujian. Dengan kata lain, keterampilan dan
latar belakang individu dari berbagai disiplin ilmu dapat ditarik ke dalam proses pengujian. Untuk
beberapa tes peserta, khususnya pengguna, dapat membantu untuk membuat mereka sadar dari
kedua sistem dan perangkap potensial dalam sistem otomatis. Selain itu, tim uji kombinasi
memiliki pengaruh yang lebih besar dalam menyetujui, setuju, atau memodifikasi sistem aplikasi.
Kerugian dari tim uji kombinasi adalah biaya yang terkait dengan perakitan dan mengelola
tim uji. Hal ini juga dapat menimbulkan beberapa masalah penjadwalan menentukan ketika tes
akan terjadi. Akhirnya, latar belakang dari tim uji dapat membuat penentuan pendekatan tes
diterima bersama sulit.

Tugas 4: Verifikasi Dokumentasi

Pembangunan
Penguji mengandalkan dokumentasi pengembangan untuk mempersiapkan tes dan
menentukan hasil yang diinginkan. Jika dokumentasi pembangunan tidak jelas, penguji
tidak dapat menentukan hasil yang diharapkan. Sebagai contoh, sebuah harapan
bahwa sistem harus "mudah digunakan "tidak cukup spesifik untuk menguji. Hal ini
tidak praktek yang baik untuk tester untuk menentukan hasil yang diharapkan atau
untuk menunjukkan hasil yang "memadai."
Hal ini penting sebelum perencanaan pengujian untuk menentukan kelengkapan
dan kebenaran dokumentasi pembangunan. Dalam organisasi dokumentasi
pembangunan mana yang baik standar yang ada, dan manajemen TI memberlakukan
kepatuhan terhadap standar tersebut, tugas ini tidak diperlukan. Namun dalam kasus
yang perlu bagi para penguji untuk memiliki pemahaman yang mendalam tentang
standar dokumentasi pengembangan.

Pencegahan Kegagalan
Penguji harus peduli bahwa proses dokumentasi akan gagal, untuk mencegahnya
yaitu dengan melakukan cara :
1. Membantu dalam perencanaan dan pengelolaan sumber daya
2. Bantuan untuk merencanakan dan melaksanakan prosedur pengujian
3. Bantuan untuk mentransfer pengetahuan tentang pengembangan perangkat lunak
di seluruh siklus hidup
4. Mempromosikan pemahaman bersama dan harapan tentang sistem dalam
organisasi dan-jika software yang dibeli-antara pembeli dan penjual
5. Tentukan apa yang diharapkan dan memverifikasi bahwa adalah apa yang
disampaikan
6. Menyediakan manajer dengan dokumen teknis untuk meninjau di perkembangan
yang signifikan tonggak, untuk menentukan bahwa persyaratan telah dipenuhi
dan sumber daya harus terus dikeluarkan

Tahap Pembangunan
Program dan sistem yang dikembangkan secara bertahap, dari ide awal untuk sebuah sistem
untuk Sistem bekerja dengan benar. Terminologi yang digunakan untuk mengidentifikasi masukan,
fase, dan tahap dalam fase ini didefinisikan dalam daftar berikut:
1. Inisiasi
2. Pembangunan
3. Definition
4. Desain
5. Programming
6. Testing
7. Operasi
8. Permintaan Project
9. Studi kelayakan
10. Analisis biaya / manfaat
11. Ringkasan Software

Tahap Pembangunan...
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Persyaratan fungsional
persyaratan data
Sistem spesifikasi / subsistem
spesifikasi Program
spesifikasi database
Panduan pengguna
Panduan Operasional
petunjuk pemeliharaan Program
rencana uji
Uji laporan analisis

Mengukur Dokumentasi Kebutuhan Proyek

Formalitas, lingkup, dan tingkat detail dari dokumentasi yang harus
dipersiapkan tergantung pada praktek manajemen TI organisasi dan proyek
ukuran, kompleksitas, dan risiko. Apa yang memadai untuk satu proyek
mungkin tidak memadai untuk yang lain. Terlalu banyak dokumentasi juga
bisa boros. Merupakan bagian penting dari pengujian-dokumen pemikiran
adalah untuk menentukan pertama bahwa dokumentasi yang tepat disiapkan;
ada sedikit nilai dalam mengkonfirmasikan bahwa dokumentasi yang tidak
diperlukan adalah cukup siap.

Metodologi pengujian menggunakan 12 kriteria untuk

menetapkan kebutuhan untuk dokumentasi:
1.
2.

Orisinalitas diperlukan. Keunikan dari aplikasi dalam organisasi.

Tingkat umum. Jumlah kekakuan yang berhubungan dengan aplikasi dan kebutuhan untuk menangani berbagai situasi
selama pemrosesan.
3. Span operasi. Persentase total kegiatan perusahaan dipengaruhi oleh sistem.
4. Perubahan lingkup dan tujuan. Frekuensi perubahan diharapkan persyaratan selama hidup dari sistem.
5. kompleksitas peralatan. Kecanggihan perangkat keras dan komunikasi yang jalur yang dibutuhkan untuk mendukung
aplikasi.
6. Personil yang ditugaskan. Jumlah orang yang terlibat dalam mengembangkan dan main- yang memuat sistem aplikasi.
7. biaya Pembangunan. Total dolar yang dibutuhkan untuk mengembangkan aplikasi.
8. Kekritisan. Pentingnya sistem aplikasi untuk organisasi.
9. waktu respon rata-rata untuk program perubahan. Jumlah rata-rata waktu yang tersedia sangat menginstal
perubahan ke sistem aplikasi.
10. Waktu respon rata-rata untuk memasukkan data. Jumlah rata-rata waktu yang tersedia untuk memproses transaksi
aplikasi.
11. Bahasa pemrograman. Bahasa yang digunakan untuk mengembangkan aplikasi.
12. pengembangan perangkat lunak serentak. Aplikasi lain dan sistem pendukung yang perlu dikembangkan secara
bersamaan untuk memenuhi total misi.

Tingkat Dokumentasi
Mengilustrasikan metode sederhana untuk menentukan tingkat
dokumentasi yang diperlukan. Ada empat tingkat dokumentasi, yaitu:
1. Minimal
2. Internal
3. Dokumen Kerja
4. publikasi Formal

Menentukan Apa Dokumen Harus

Diproduksi
Gambar 7-5 berhubungan total kriteria tertimbang skor Kerja Kertas 7-1 dengan dokumen perangkat
lunak yang dijelaskan sebelumnya dan merekomendasikan yang penguji dokumen harus pra pare.
Kebutuhan beberapa dokumen tergantung pada situasi. (Sebagai contoh, spesifikasi basis data dan
dokumen persyaratan data yang biasanya diperlukan untuk sistem-sistem yang menggunakan teknologi
database.) Sebuah dokumen permintaan proyek diperlukan dalam organisasi yang membutuhkan
persetujuan resmi sebelum melakukan studi kelayakan. Dokumen analisis biaya / manfaat yang diperlukan
dalam organisasi yang mengharuskan analisis tersebut akan per- terbentuk sebelum proyek dimasukkan
ke dalam pembangunan. Dengan total kriteria tertimbang skor dikembangkan, Gambar 7-5 dapat
digunakan sebagai berikut:
1. Baris yang tepat untuk memilih dokumen ditentukan oleh referensi silang skor dikembangkan Kerja
Kertas 7-1 untuk skor dalam total kolom kriteria yang tertimbang. Beberapa nilai di kolom tumpang
tindih ini untuk mengakomodasi proyek yang sangat penting, terlepas dari nilai mereka.
2. Untuk baris yang dipilih, kolom menunjukkan dokumen mana yang diperlukan. Jika proyek tidak
menghasilkan dokumen tersebut, tim uji harus mempertanyakan dokumentasi. Jika dokumen tidak
diperlukan disiapkan, tim uji harus menantang kebutuhan untuk mempertahankan mereka.

Menentukan Kelengkapan Dokumen

Individu
Penguji harus menggunakan Kerja Kertas 7-2 untuk mendokumentasikan hasil tes kelengkapan. Jika
dokumentasi tidak memenuhi kriteria, Komentar kolom harus digunakan untuk menjelaskan kekurangan. Kolom ini
menjadi laporan uji kelengkapan dokumentasi. 12 Kriteria yang digunakan untuk mengevaluasi kelengkapan
dokumen adalah sebagai berikut:
Konten. Konten yang disarankan untuk semua dokumen (kecuali ringkasan software) termasuk dalam bagian
selanjutnya. Atable isi untuk setiap dokumen diikuti dengan penjelasan singkat dari setiap elemen dalam dokumen.
Pedoman isi dokumen ini harus digunakan untuk menentukan apakah pemerintah-dokumen berisi semua informasi
yang dibutuhkan.
1. Pemirsa
2. Redudansi
3. Fleksibilitas
4. Ukuran
5. Format
6. Konten Urutan
7. Mendokumentasikan beberapa program atau beberapa file
8. Judul Bagian
9. Flowchart dan Tabel Keputusan
10. Bentuk

Tugas 5: Validasi Test Memperkirakan dan

Proses Pelaporan Status proyek
Proyek bermasalah memiliki dua karakteristik umum: Perkiraan proyek tidak memadai dan
laporan status dari upaya pembangunan menyesatkan.
Tujuan validasi estimasi proyek adalah untuk menentukan sumber daya apa yang akan
tersedia untuk memproduksi dan menguji perangkat lunak. Sumber daya mencakup staf,
komputer, dan waktu berlalu. Karena perkiraan yang baik menunjukkan kapan dan bagaimana biaya
akan dikeluarkan, itu dapat digunakan tidak hanya untuk membenarkan pengembangan perangkat
lunak dan pengujian tetapi juga sebagai manajemen kontrol Alat.
Penguji perlu mengetahui kemajuan sistem dalam pengembangan. Tujuan sistem manajemen
proyek dan sistem akuntansi adalah untuk memantau kemajuannya. Namun, banyak dari sistem ini
lebih penganggaran dan jadwal berorientasi dari penyelesaian proyek oriented.
Hal utama yang perlu diperhatikan tester selama pengembangan adalah bahwa sumber daya
yang memadai dan waktu akan dialokasikan untuk pengujian. Karena banyak pengujian akan
dilakukan setelah pembangunan selesai, periode waktu antara menyelesaikan pembangunan dan
tanggal jatuh tempo untuk produksi mungkin tidak memadai untuk pengujian.

Ada tiga masalah umum mengenai waktu yang

tersedia dan sumber daya untuk pengujian:
Estimasi akurat. Perkiraan sumber daya dalam waktu tidak akan cukup
untuk menyelesaikan proyek seperti yang ditentukan.
Proses pembangunan yang tidak memadai. Alat dan prosedur tidak
akan mengaktifkan pengembang untuk menyelesaikan proyek dalam
batasan waktu.
Pelaporan Status salah. Para pemimpin proyek tidak akan mengetahui
status yang benar dari proyek selama tahap perkembangan awal dan
dengan demikian tidak dapat mengambil tindakan perbaikan yang
diperlukan pada waktunya untuk memenuhi tanggal penyelesaian yang
dijadwalkan.

Memvalidasi Test Estimate

Banyak proyek software pada dasarnya inovatif, dan
sejarah serta logika menyarankan bahwa biaya yang
membengkak mungkin untuk hasil dari sistem estimasi
efektif. Biaya perangkat lunak estimasi adalah proses
yang rumit karena pengembangan proyek dipengaruhi
oleh sejumlah besar variabel, banyak yang subjektif,
non-kuantitatif, dan saling terkait dalam cara yang
kompleks.

Beberapa alasan untuk tidak mendapatkan

perkiraan yang baik meliputi:

Kurangnya pemahaman tentang proses pengembangan perangkat lunak dan

pemeliharaan
Kurangnya pemahaman tentang efek dari berbagai teknis dan kendala
manajemen
Setiap proyek adalah unik, yang menghambat proyek-to-proyek perbandingan
Kurangnya data historis terhadap yang model dapat diperiksa
Kurangnya data historis untuk kalibrasi
Definisi yang tidak memadai dari tujuan perkiraan dan pada tahap apa perkiraan
diperlukan sehingga input dan output dapat dipilih tepat
Spesifikasi yang tidak memadai lingkup perkiraan (apa yang termasuk dan apa
yang dikecualikan)
Pemahaman memadai tempat yang perkiraan tersebut didasarkan

Strategi untuk Software Estimasi Biaya

Ada lima metode yang umum digunakan untuk memperkirakan biaya pengembangan dan pemeliharaan sistem perangkat lunak:
1. Seat-of-the-pants method. Metode ini, yang sering berdasarkan pengalaman pribadi, masih sangat populer karena
tidak ada metode yang lebih baik telah terbukti. Salah satu masalah adalah bahwa masing-masing perkiraan ini
didasarkan pada pengalaman yang berbeda, dan karena itu perkiraan yang berbeda biaya proyek tunggal dapat
bervariasi. Masalah kedua adalah bahwa estimator harus memiliki pengalaman dengan proyek serupa, dengan ukuran
yang sama.
2. Constraint method. Metode kendala setara dengan mengambil tebakan. Berdasarkan jadwal, biaya, atau kendala
staf, manajer setuju untuk mengembangkan perangkat lunak dalam batasan. Metode ini akan menghasilkan
pengiriman perangkat lunak dalam batasan tertentu, tetapi dengan spesifikasi yang disesuaikan agar sesuai dengan
kendala.
3. Percentage-of-hardware method. Metode ini didasarkan pada dua asumsi:

Biaya perangkat lunak adalah persentase tetap dari biaya hardware.

Perkiraan biaya hardware biasanya cukup akurat.

4. Simulation method. Simulasi banyak digunakan dalam memperkirakan biaya dukungan untuk sistem perangkat keras,
tetapi tidak sesuai untuk biaya perangkat lunak, karena didasarkan pada analisis statistik dari tingkat kegagalan
hardware dan mengabaikan logistik yang ada.
5. Parametric modeling method. Model parametrik terdiri dari metode estimasi yang paling sering digunakan dan
dijelaskan di bagian berikut.

Parametrik Model
Model parametrik dapat dibagi menjadi tiga kelas: Regresi, Heuristik, dan Fenomenologis.
1. Model regresi. Kuantitas yang diperkirakan secara matematis terkait dengan satu set
parameter masukan. Mungkin ada lebih dari satu hubungan untuk menangani database yang
berbeda, berbagai jenis aplikasi, dan karakteristik pengembang yang berbeda.
2. Model heuristik. Dalam model heuristik, observasi dan interpretasi data historis yang
dikombinasikan dengan anggapan dan pengalaman. Keuntungan dari model heuristik yaitu
tidak perlu menunggu hubungan formal yang akan didirikan yang menggambarkan bagaimana
variabel biaya terkait. Selama periode waktu, model tertentu dapat menjadi sangat efektif
dalam lingkungan prediksi.
3. Model fenomenologis. Model fenomenologis didasarkan pada hipotesis bahwa proses
pengembangan perangkat lunak dapat dijelaskan dalam hal beberapa proses atau ide yang
lebih luas. Sebagai contoh, model Putnam didasarkan pada keyakinan bahwa distribusi usaha
selama siklus hidup perangkat lunak memiliki karakteristik yang sama dengan distribusi
usaha yang dibutuhkan untuk memecahkan sejumlah tertentu.

1. Estimate the software size. Kebanyakan model mulai dari perkiraan ukuran proyek, meskipun beberapa
model termasuk algoritma untuk ukuran komputasi dari berbagai karakteristik sistem lainnya, seperti unit
kerja.
2. Convert the size estimate (function points or lines of code) to an estimate of the person-hours
needed to complete the test task. Beberapa model mengkonversi dari ukuran tenaga kerja, sedangkan
yang lain langsung dari ukuran perkiraan uang.
3. Sesuaikan perkiraan karakteristik proyek khusus. Pada beberapa model, ukuran efektif dihitung dari
perkiraan ukuran dasar yang diperoleh yang meliputi efek volatilitas persyaratan, perangkat lunak yang
berbeda, kesulitan di atas tingkat proyek dalam database, atau metode yang berbeda dalam menangani
biaya dukungan, sering didasarkan pada hubungan intuitif dan tidak didukung oleh verifikasi statistik.
4. Membagi total perkiraan ke dalam fase proyek yang berbeda. Setiap model berurusan dengan jadwal
proyek membuat asumsi tentang alokasi usaha dalam fase proyek yang berbeda. Asumsi sederhana
mendefinisikan persentase upaya untuk setiap tahap, misalnya, yang banyak dikutip 40 persen desain, 20
Kode persen, dan aturan uji 40 persen. Beberapa penelitian memperkirakan menunjukkan bahwa persentase
lain mungkin lebih tepat, dan persentase dalam setiap fase tergantung pada perangkat lunak lain
karakteristik.
5. Estimate the computer time and non-technical labor costs . Dimana biaya ini secara eksplisit dimasukkan,
sering dihitung sebagai persentase dari teknis biaya tenaga kerja. Kadang-kadang biaya tersebut termasuk
implisit karena mereka termasuk dalam database.
6. Jumlah biaya. Biaya tenaga kerja non-teknis dan biaya waktu komputer, di mana ini termasuk dalam
perkiraan, ditambahkan dengan biaya teknis dari fase yang berbeda dari siklus hidup perangkat lunak untuk
mendapatkan perkiraan biaya agregat.

Perkiraan Biaya Pengujian Validitas

Software
Perkiraan biaya yang tidak tepat dapat melakukan lebih banyak
kerusakan pada kualitas proyek perangkat lunak hampir dari semua faktor
lainnya. Orang-orang cenderung melakukan apa yang mereka ukur . Jika
mereka diukur pada pemenuhan perkiraan biaya perangkat lunak, mereka
biasanya akan memenuhi perkiraan itu. Jika perkiraan ini benar, tim proyek
akan membuat kompromi apapun yang memenuhi perkiraan itu. Proses
kompromi dapat secara signifikan melemahkan kualitas proyek yang
disampaikan.

Hasil yang kurang baik meningkat biaya pemeliharaan, pelanggan yang

tidak puas, peningkatan upaya di daerah pelanggan untuk mengimbangi
kelemahan sistem perangkat lunak, dan putus asa, personil proyek
demoralisasi. Memperkirakan biaya perangkat lunak itu hanya estimasi.
Tidak ada yang bisa menjamin bahwa estimasi perangkat lunak akan benar
untuk pekerjaan yang harus dilakukan. Namun, pengujian dapat meningkatkan
validitas perkiraan, dan dengan demikian merupakan upaya yang bermanfaat.
Pengujian perkiraan perangkat lunak adalah proses tiga bagian, sebagai
berikut :
1. Validasi kewajaran model estimasi.
2. Validasi bahwa model mencakup semua faktor yang dibutuhkan.
3. Pastikan kebenaran estimasi model biaya-memperkirakan

Validasi Model
Dibutuhkan

Termasuk

Semua

Faktor

Faktor-faktor yang mempengaruhi biaya proyek software dapat dibagi sesuai dengan yang
disumbangkan oleh pengembangan dan pemeliharaan organisasi. Model-model terbaru berbeda
sehubungan dengan faktor-faktor yang diperlukan sebagai masukan tertentu. Banyak faktor yang
berbeda dapat dimasukkan dalam satu parameter dalam beberapa model, khususnya parameter
yang lebih subjektif.
Tergantung pada informasi yang diumpankan ke model, estimasi yang dihasilkan dapat
bervariasi secara signifikan. Yang penting adalah semua faktor yang mempengaruhi biaya
perangkat lunak yang benar dimasukkan ke dalam model. Model dapat menghasilkan hasil yang
salah dalam dua cara. Pertama, faktor dapat dikecualikan dari model, sehingga perkiraan yang
salah. Kedua, faktor dapat tidak lengkap atau salah memasukkan ke dalam model, sekali lagi
menyebabkan perkiraan biaya perangkat lunak yang tidak benar untuk diproduksi.

Pada Lembar kerja 7-4 daftar faktor-faktor yang dapat mempengaruhi biaya perangkat
lunak. Penguji harus menentukan apakah faktor yang hilang akan secara signifikan mempengaruhi
biaya yang sebenarnya membangun perangkat lunak. Faktor-faktor yang mempengaruhi sistem
perangkat lunak meliputi :
Ukuran perangkat lunak. Ukuran favorit untuk ukuran sistem perangkat lunak pada baris
kode ational operation, atau kode penyampaian (kode operasional ditambah kode pendukung,
misalnya, untuk diagnosa hardware) yang diukur baik dalam pernyataan kode objek atau
pernyataan kode sumber. Hal ini jarang ditentukan apakah pernyataan kode sumber
termasuk kode non-executable, seperti komentar dan deklarasi data.
Persentase desain dan atau kode yang baru. Hal ini relevan ketika mengeset sistem
perangkat lunak yang ada untuk hardware baru, ketika merencanakan perpanjangan atau
modifikasi sistem perangkat lunak yang ada, atau saat menggunakan prototipe perangkat
lunak.
Kompleksitas perangkat lunak. Proyek perangkat lunak yang berbeda memiliki derajat yang
berbeda kompleksitas, biasanya diukur dengan jumlah interaksi antara bagian-bagian yang
berbeda-beda dari sistem perangkat lunak, dan antara perangkat lunak dan lingkungan luar.
Kompleksitas mempengaruhi produktivitas programmer dan merupakan masukan
parameteran untuk beberapa model.

Kesulitan menerapkan persyaratan perangkat lunak. Area aplikasi yang berbeda dianggap
memiliki tingkat kesulitan yang berbeda dalam desain dan coding, mempengaruhi
produktivitas programmer. Sebagai contoh, perangkat lunak sistem operasi biasanya
dianggap lebih sulit daripada aplikasi komersial. Proyek perangkat lunak mungkin diberikan
kesulitan atau rating campuran aplikasi, menurut sejauh mana mereka masuk ke dalam salah
satu (atau lebih) dari bidang-bidang berikut :
o sistem operasi
o Proyek real-time mandiri
o Standalone, aplikasi non-real-time
o Modifikasi sistem perangkat lunak yang ada
Tentu saja ada kategori lainnya. Setiap model mempunyai kesulitan dengan
sendiri, beberapa perkiraan memerlukan persentase setiap jenis perangkat lunak
sistem, yang lain meminta nomor pada skala yang telah ditetapkan.

Kualitas. Kualitas, dokumentasi, pemeliharaan, dan keandalan standar yang dibutuhkan semua
termasuk dalam faktor tunggal. Faktor ini kadang-kadang disebut jenis platform, mencerminkan
fakta bahwa dokumentasi dan kehandalan persyaratan untuk perangkat lunak dalam pesawat ruang
angkasa berawak yang lebih tinggi daripada di standalone station paket tistical. Dokumentasi dan
persyaratan keandalan dapat diberikan skala numerik yang ditentukan, misal dari 1 sampai 10.
Beberapa model memperkirakan termasuk parameter untuk sejumlah lokasi yang berbeda di mana
perangkat lunak akan dijalankan.
Bahasa yang akan digunakan. Pilihan bahasa pemrograman mempengaruhi biaya, ukuran, skala
waktu, dan usaha dokumentasi.
Klasifikasi keamanan. Semakin tinggi klasifikasi keamanan proyek, maka akan semakin bnyak biaya
karena tindakan pencegahan tambahan yang dibutuhkan. Klasifikasi keamanan bukan merupakan
faktor input dalam kebanyakan model.
Volatilitas dari kebutuhan. Ketegasan dari spesifikasi kebutuhan dan antarmuka antara
pengembang dan pelanggan mempengaruhi jumlah pengerjaan ulang yang akan dibutuhkan sebelum
perangkat lunak disampaikan. Faktor yang sangat subjektif tapi tetap penting ini merupakan faktor
masukan untuk beberapa model. Berikut ini termasuk dalam faktor ini :
o Jumlah perubahan yang diharapkan dalam persyaratan
o Jumlah detail dihilangkan dari spesifikasi kebutuhan
o Pengembangan bersamaan perangkat keras yang terkait, menyebabkan perubahan dalam
spesifikasi perangkat lunak
o Target perangkat keras yang tidak ditentukan

Faktor organisasi-dependent adalah sebagai

berikut :
-

Jadwal proyek. Upaya untuk menghemat waktu dengan menambahkan lebih banyak orang
untuk sebuah proyek terbukti kontraproduktif karena lebih banyak waktu dan usaha yang
dikeluarkan dalam komunikasi antara anggota tim proyek daripada yang bisa diperoleh
dengan menambahkan orang-orang tambahan. Oleh karena itu harus ada waktu minimum
dimana project dapat diselesaikan atau setidaknya waktu yang sedikit tidak menjadi
penghalang. Sebaliknya, jika lebih banyak waktu yang dialokasikan untuk proyek dari yang
dibutuhkan, telah berpendapat bahwa biaya berkurang. Bagaimanapun, model lain
menunjukkan meningkatnya biaya jika lebih dari beberapa waktu optimum dialokasikan
karena lebih banyak personil yang dikonsumsi. Salah satu efek dari kompresi rentang waktu
adalah pekerjaan yang harus dilakukan dalam seri di paralel, dengan peningkatan risiko
bahwa beberapa pekerjaan akan dibatalkan (misalnya, jika coding dimulai sebelum desain
selesai).

Faktor organisasi-dependent adalah sebagai

berikut.....
Jadwal proyek. Upaya untuk menghemat waktu dengan menambahkan lebih banyak orang untuk
sebuah proyek terbukti kontraproduktif karena lebih banyak waktu dan usaha yang dikeluarkan
dalam komunikasi antara anggota tim proyek daripada yang bisa diperoleh dengan menambahkan
orang-orang tambahan. Oleh karena itu harus ada waktu minimum di bawah pengerjaan project yang
dapat diselesaikan . Sebaliknya, jika lebih banyak waktu yang dialokasikan untuk proyek dari yang
dibutuhkan, telah berpendapat bahwa biaya berkurang. Bagaimanapun, model lain menunjukkan
meningkatnya biaya jika lebih dari beberapa waktu optimum yang dialokasikan karena lebih banyak
pekerja. Salah satu efek dari kompresi rentang waktu adalah pekerjaan yang harus dilakukan dalam
seri dilakukan di paralel, dengan peningkatan risiko bahwa beberapa pekerjaan akan dibatalkan
(misalnya, jika coding dimulai sebelum desain selesai).
Kompetensi teknis. Proyek yang efektif, staf dan personil dengan kompetensi yang
dibutuhkan untuk menyelesaikan proyek dengan sukses. Seorang staf yang kurang kompeten
akan meningkatkan biaya dan jadwal tugas pengujian ditetapkan.
Staf non-teknis. Perkiraan tingkat tenaga non-teknis yang diperlukan oleh proyek sering
dibuat sebagai persentase dari tingkat tenaga teknis.

Faktor organisasi-dependent adalah sebagai

berikut...
-

Lingkungan pengembangan. Kecukupan lingkungan pengembangan, baik dalam hardware dan software,
tergantung pada manajemen organisasi pengembangan. Faktor ini biasanya tidak diminta sebagai masukan
untuk model eksplisit, tetapi mungkin tersirat dalam kalibrasi model, atau dalam beberapa parameter
manajemen umum. Berikut ini adalah tiga aspek Pengembangan lingkungan yang kadang-kadang diperlukan
sebagai masukan :
o
Mesin pembangunan. Kecukupan mesin pembangunan sebagai tuan rumah untuk mengembangkan
perangkat lunak untuk target yang dipilih, dan ketersediaan mesin pengembangan untuk personil
pengembangan perangkat lunak, akan mempengaruhi jadwal dan biaya pengembangan perangkat lunak.
Hasil penelitian menunjukkan bahwa pembagian waktu, di mana mesin pengembangan terus-menerus
tersedia, adalah 20 persen lebih produktif daripada sistem batch selama pengembangan perangkat
lunak.
o

Ketersediaan perangkat lunak dan perangkat keras yang terkait. Proyeksi keterlambatan
pengiriman beberapa item perangkat keras atau perangkat lunak terkait dapat mempengaruhi jadwal
dan biaya.

Perangkat lunak dan teknik yang digunakan selama desain sistem dan pengembangan. Alat dan
teknik baru, diterapkan dengan benar, dapat mengurangi biaya pembangunan.

Faktor organisasi-dependent adalah sebagai

berikut...
-

Tingkat tenaga kerja. Jika model memperkirakan biaya dalam bentuk

uang bukan jam staf, hubungan biaya tenaga kerja untuk staf dalam
pengembangan organisasi mungkin diperlukan oleh model. Model
mungkin mampu mencerminkan tingkat peningkatan untuk staf yang
diperlukan untuk bekerja dengan jam kerja yang tidak teratur karena
penurunan dalam skala waktu pengembangan atau kurangnya
ketersediaan alat-alat pembangunan.
Inflasi. Estimasi biaya dalam bentuk uang bukan jam staf harus
mencakup tingkat inflasi jika proyek akan bertahan lebih dari 12 bulan.

Verifikasi Kebenaran
Biaya Model Estimate

dari

Memperkirakan

Jumlah pengujian estimasi yang dihasilkan akan tergantung pada kewajaran model estimasi
dan kelengkapan faktor yang mempengaruhi dimasukkan dalam model. Semakin sedikit tester
dapat mengandalkan model, semakin banyak pengujian yang perlu dibentuk pada validitas estimasi
yang dihasilkan oleh model. Empat langkah berikut ini disarankan saat pengujian validitas
estimasi yang dihasilkan oleh perangkat lunak model biaya estimasi :
- Menghitung ulang perkiraan. Tester dapat memfalidasi pengolahan estimasi dengan
menjalankan lagi model estimasi. Tujuan dari ini adalah untuk :

Mempalidasi masukan itu dimasukkan dengan benar

Mempalidasi input itu wajar

Palidasi perhitungan matematis dilakukan dengan benar

Tes ini dapat dilakukan dalam totalitas atau sebagian. Sebagai contoh, tester sepenuhnya dapat
menghitung ulang perkiraan, periksa bahwa masukan masuk ke model estimasi benar, menguji
kewajaran beberapa tes input dengan menghitung ulang semua atau bagian dari perkiraan, dan
sebagainya.

Bandingkan dihasilkan estimasi untuk proyek serupa. Tester dapat menentukan

berapa lama waktu yang dibutuhkan untuk mengembangkan proyek-proyek dengan
ukuran yang sama dan kompleksitas. Sebenarnya project biaya ini harus tersedia dari
sistem akuntansi organisasi. Pasangan estimasi yang dihasilkan oleh sistem estimasi
kemudian dibandingkan dengan biaya yang sebenarnya untuk proyek-proyek seperti
diselesaikan di masa lalu. Jika ada perbedaan yang signifikan, tester dapat
menantang keabsahan perkiraan. Tantangan ini dapat mengakibatkan perhitungan
atau perubahan perkiraan berdasarkan pengalaman sebelumnya
Penguji bijaksana. Tes ini mirip dengan tes sebelumnya di bahwa pengalaman yang lalu
digunakan. Tester mendokumentasikan faktor yang mempengaruhi perkiraan biaya,
dokumen estimasi yang dihasilkan oleh sistem estimasi, dan kemudian memvalidasi
kewajaran estimasi bahwa dengan meminta pimpinan proyek yang dialami pendapat
mereka mengenai validitas perkiraan. Hal ini direkomendasikan untuk tiga pemimpin
proyek berpengalaman diminta untuk memvalidasi perkiraan. Jika satu atau lebih
tidak merasa bahwa perkiraan yang wajar, validitas estimasi harus ditantang.

Redundansi dalam biaya perangkat lunak estimasi. Tes ini tester telah
menghitung ulang estimasi dengan menggunakan model biaya yang
memperkirakan. Sebagai contoh, asumsikan bahwa organisasi Anda telah
mengembangkan model biaya-memperkirakan. Orang-orang proyek telah
menggunakan model tersebut untuk mengembangkan perkiraan biaya. Tester
menggunakan metode lain, misalnya, paket perangkat lunak-memperkirakan. Jika
dua sistem memperkirakan menghasilkan sekitar perkiraan yang sama,
ketergantungan pada perkiraan yang meningkat. Di sisi lain, jika ada perbedaan
yang signifikan antara perkiraan dengan menggunakan dua metode, maka tester
perlu untuk mengejar penyelidikan tambahan.
Sumber model memperkirakan perangkat lunak meliputi :
o Model organisasi yang dikembangkan memperkirakan
o Model memperkirakan termasuk dalam metodologi pengembangan system
o Paket perangkat lunak untuk mengembangkan perkiraan software
o Fungsi poin dalam mengestimasi biaya perangkat lunak

Menghitung Status
Sistem Titik

Proyek

Menggunakan

Tes status proyek yang diusulkan didasarkan pada sistem poin-akumulasi

sederhana. Poin tersebut kemudian dibandingkan dengan laporan manajemen proyek
atau kemajuan sistem akuntansi. Jika hasil dari dua sistem pengukuran kemajuan
berbeda, penguji bisa Tantangan keabsahan hasil yang dihasilkan oleh manajemen
proyek dan / atau akuntabilitas sistem.
Titik sistem menyediakan tujuan, akurat, efisien berarti pengumpulan dan
pelaporan data kinerja dalam bidang teknik yang sering kekurangan visibilitas.
Metode ini menggunakan data berdasarkan item software penyampaian dan
dikumpulkan sebagai bagian normal dari proses pembangunan. Hasilnya mudah
diinterpretasikan dan dapat disajikan dalam berbagai format dan sub-divisi. Skema
ini bersifat fleksibel dan dapat dimodifikasi untuk memenuhi kebutuhan proyek, baik
besar maupun kecil.

Metode khas Mengukur Kinerja

Kinerja dalam pengembangan perangkat lunak diukur biasanya baik dengan memperkirakan persentase tugas
selesai atau dengan menghitung jumlah tonggak yang telah ditetapkan yang telah dicapai. Dalam estimasi metode
persen selesai, orang - membentuk pekerjaan memperkirakan persen dari pekerjaan yang telah dicapai dalam
reach-ing tonggak atau menyelesaikan tugas. Persentase Metode selesai memiliki beberapa kesalahan. Kesalahan
utama adalah bahwa pengukuran adalah subyektif. Manajer meminta seseorang dengan kepentingan dalam
menyelesaikan tugas sedini mungkin untuk membuat tebakan tentang bagaimana kelengkap itu. Kebanyakan orang
cenderung optimis dalam kemampuan mereka untuk menyelesaikan tugas, terutama jika manajer mereka secara
halus mendorong optimisme. Lama tugas menjadi 95 persen lengkap untuk bulan ini semua terlalu benar.
Kelemahan potensial dari metode ini bila digunakan dengan tugas daripada tonggak adalah bahwa definisi
penyelesaian tidak selalu menyatakan. Oleh karena itu, orang yang membuat estimasi mungkin memiliki satu
persepsi apa tugas meliputi, sedangkan manajer mungkin memiliki yang lain. Oleh karena itu, ketika programmer
menyatakan tugas adalah 100 persen complete- ditulis, diuji, dan didokumentasikan manajer mungkin memiliki
kejutan yang tidak menyenangkan ketika ia meminta untuk melihat panduan instalasi. Oleh karena itu, karena
tugas akhir tidak dapat didefinisikan dengan jelas, perkiraan penyelesaian mungkin cukup akurat. Karena
perkiraan subjektif, interpretasi hasil mungkin juga subyektif. Dalam mencoba untuk memastikan tingkat
kelengkapan pekerjaan, manajer mungkin bertanya siapa yang membuat estimasi dan kemudian menerapkan
"faktor koreksi" perkiraan untuk orang tersebut untuk mendapatkan nomor ia merasa nyaman dengan.

Metode kedua, metode tonggak, upaya untuk mengatasi masalah ini dengan mendefinisikan tonggak
tertentu yang harus dipenuhi dan mengukur kinerja dengan menjumlahkan jumlah tonggak yang telah dipenuhi.
Metode ini jauh lebih objektif, cenderung untuk menggambarkan tugas keseluruhan lebih lengkap, dan, sebagai
akibatnya, lebih mudah untuk menafsirkan. The kekurangan tersebut dari metode ini lebih di bidang resolusi
pengukuran terhadap efisiensi pengumpulan, menyusun, dan menyajikan hasil dalam cara yang berarti.
Untuk mendapatkan resolusi pengukuran yang baik cukup untuk menunjukkan kemajuan tambahan secara
periodik, berbagai tonggak perlu didefinisikan. Namun, sejumlah besar tonggak membuatnya lebih sulit untuk
mengumpulkan dan menyajikan data secara tepat waktu dan bermakna. Sebuah metode yang umum adalah untuk
menyajikan data pada grafik batang, tetapi pada proyek besar dengan ribuan tonggak, pemeliharaan grafik batang
bisa menjadi lambat, upaya sive expen.
Masalah lain yang potensial adalah bahwa tonggak mungkin tidak secara akurat mencerminkan tugas nyata.
Jika perawatan tidak diambil untuk menentukan tonggak tersebut, tonggak mungkin tidak didasarkan pada item
penyampaian, tetapi pada sesuatu yang tampaknya menunjukkan kemajuan, seperti baris kode yang dihasilkan.
Juga, jika tonggak tidak dipilih dengan hati-hati, mungkin sulit untuk menentukan apakah tonggak telah tercapai.
yuki modol ramen mayasi.
Alat pengukuran kinerja dan teknik menekankan fungsi terbentuk di awal kehidupan proyek. Informasi
kurang tersedia pada fungsi pengelolaan berkelanjutan kontrol. Kontrol dapat dianggap sebagai proses tiga
langkah: Sebuah atribut atau karakteristik bunga diukur, nilai terukur dibandingkan dengan nilai yang diharapkan
atau dasar, dan tindakan yang tepat diambil jika deviasi tidak dapat diterima ada. Setiap jumlah item yang
menarik selama pengembangan perangkat lunak dapat dikendalikan dengan cara ini. Waktu pengembangan, biaya
pengembangan, penggunaan memori komputer, dan waktu komputer adalah beberapa item yang lebih umum.

Sebuah skema pengukuran kinerja harus memenuhi beberapa kriteria. Pertama dan yang
paling penting, skema harus objektif. Kinerja mengklaim orang tidak harus diminta untuk
memperkirakan tingkat penyelesaian. Demikian juga, orang yang memantau kinerja yang harus
tahu persis apa yang merupakan pengukuran kinerja. Idealnya, negara pembangunan harus cukup
terlihat dan pengukuran berarti cukup jelas untuk memungkinkan setiap anggota proyek untuk
membuat pengukuran yang sebenarnya.
Kedua, skema harus mengukur kinerja dalam menyelesaikan tugas yang sebenarnya (yaitu,
pengembangan perangkat lunak penyampaian). Selanjutnya, resolusi skema pengukuran harus
cukup baik untuk mengukur kemajuan tambahan secara mingguan atau bulanan, dan pengukuran
harus tepat waktu dalam hal mengukur keadaan saat ini pembangunan. Menyediakan informasi
yang akurat dan kinerja saat ini secara odic peri dapat menjadi faktor pendorong positif bagi
staf pemrograman. Akhirnya, skema harus efisien. Ini harus membutuhkan sumber daya minimal
untuk mengumpulkan, menyusun, dan melaporkan data kinerja dan harus membutuhkan waktu
minimum untuk menginterpretasikan hasil. Sistem yang membutuhkan input konstan dari staf
pemrograman, update oleh personel administrasi, atau integrasi data dalam jumlah besar oleh
manajemen tidak boleh digunakan.

Menggunakan Sistem Titik

Titik sistem benar-benar perpanjangan sistem tonggak yang cocok untuk otomatisasi. Dalam bentuk yang
paling sederhana, diasumsikan bahwa setiap modul software berjalan melalui proses perkembangan yang sama dan
bahwa proses terdiri batu jelas diidentifikasi. Sebagai contoh, asumsikan sepuluh modul akan dikembangkan dan
empat tonggak akan menentukan proses pembangunan. Tonggak mungkin merupakan desain ditinjau dan diterima,
kode walkthrough selesai, hasil tes diverifikasi, dan modul dirilis.
Dalam kasus sederhana, setiap tonggak untuk setiap item software bernilai 1 poin. Dalam kasus sistem
dengan sepuluh modul, 40 poin dapat diterima. Sebagai bagian dari setiap review desain, kode walkthrough,
verifikasi pengujian, atau audit rilis, tonggak dicapai dan titik yang sesuai diperoleh. Dengan termasuk tonggak
dicapai (poin yang diterima) dan menciptakan generator sederhana, Anda bisa mendapatkan tujuan, akurat, dan
tepat waktu mengukur kinerja. Gambar 7-7 menunjukkan apa laporan status yang sederhana mungkin terlihat
seperti.
Skema sederhana ini bekerja dengan baik untuk satu set homogen modul, di mana semua modul dari
kompleksitas yang sama dan masing-masing tonggak merupakan jumlah yang kira sama kira-kerja. Melalui
pengenalan faktor pembobotan, Anda dapat dengan mudah menangani modul dari berbagai kompleksitas atau
tonggak yang mewakili usaha yang tidak sama untuk menyelesaikan.

Sebelum ini dan lainnya ekstensi dibahas, namun, penjelasan singkat dari implementasi adalah dalam
rangka. Jantung dari sistem adalah file data komputer dan beberapa generator laporan sederhana. File
data hanyalah sebuah kumpulan catatan, satu untuk setiap item yang akan dilacak, yang berisi kolom untuk
menunjukkan apakah suatu tonggak tertentu telah dipenuhi. Biasanya, hal ini menguntungkan untuk
memasukkan bidang-bidang berikut: Item deskripsi tion, analis bertanggung jawab, identifikasi paket
pekerjaan, serta berbagai berkas identifi- kasi bidang. Seringkali file tersebut akan melayani beberapa
kegunaan, terutama jika bidang tambahan beberapa ditambahkan. Penggunaan secara khusus mencakup
definisi keluarga pohon, spesifikasi ences lintas referendum, daftar kontrol konfigurasi, dan dokumentasi
referensi silang.
Mempertahankan atau memperbarui file dapat sesederhana memodifikasi catatan dengan editor
line atau serumit membangun tujuan khusus pembaruan interaktif pro gram. Beberapa sarana akses
terbatas harus digunakan untuk membatasi Modifikasi tidak sah, terutama jika beberapa kegunaan lain
dari file sensitif terhadap perubahan.
Setelah file diperbarui untuk menyertakan entri dari modul dalam pengembangan, bidang Status
tonggak diperbarui sebagai tonggak terpenuhi. Dalam beberapa kasus ini dapat menjadi proses manual;
setelah suatu peristiwa telah terjadi dan tonggak yang dicapai, pustakawan program atau orang lain yang
berwenang update file status. Dalam kasus lain, dalam sistem yang lebih canggih, sebuah program
komputer bisa menentukan bahwa peristiwa tonggak telah terjadi dan secara otomatis memperbarui
status tonggak.

Ekstensi

Sejumlah ekstensi dapat ditambahkan ke skema seperti yang dijelaskan sejauh ini. Yang pertama adalah
untuk menambahkan metode modul pembobotan tonggak. Sementara bobot semua modul yang sama pada program
besar di mana banyak (lebih dari 1.000) modul yang ada tampaknya memberikan hasil yang baik, program yang
lebih kecil dengan beberapa modul mungkin perlu berat modul untuk memberikan pengukuran kinerja yang cukup
akurat. Selain itu, tergantung pada tingkat visibilitas sistem pengukuran dan sikap personel yang terlibat, mungkin
ada kecenderungan untuk melakukan semua "mudah" modul pertama yang menunjukkan kinerja awal.
Argumen yang sama dapat dibuat untuk pembobotan tonggak. Tergantung pada kriteria serah terima,
beberapa tonggak mungkin melibatkan lebih banyak pekerjaan daripada yang lain. Oleh karena itu, achiev- ing
mereka tonggak mewakili mencapai jumlah yang lebih besar dari pekerjaan daripada dalam memenuhi tonggak lain.
Selanjutnya, mungkin ada kasus di mana kombinasi berat modul dan berat tonggak dapat berinteraksi. Contohnya
adalah modul yang sebelumnya ditulis pada proyek lain dalam bahasa yang berbeda. Jumlah karya desain untuk
modul yang mungkin jauh kurang dari modul dirancang dari awal, tetapi jumlah usaha untuk kode rutin mungkin
lebih karena seorang satu bahasa asing mungkin terlibat.
Skema pembobotan mudah diimplementasikan dengan menetapkan poin masing-masing tonggak untuk semua
modul. Kemudian, sebagai tonggak sejarah diperoleh, poin ditugaskan ditambahkan ke jumlah yang diterima dan
dibagi dengan total poin didefinisikan untuk menghitung persen selesai. Jumlah poin ditugaskan untuk setiap
tonggak adalah sebanding dengan kesulitan dalam achiev- ing tonggak, dan, pada kenyataannya, berhubungan
langsung dengan perkiraan jumlah jam yang dibutuhkan untuk menyelesaikan tonggak. Ketika menetapkan poin,
dianjurkan bahwa poin pertama ditugaskan untuk masing-masing modul dan kemudian reapportioned ke tonggak.

Sebuah ekstensi kedua adalah untuk menambah memilih dan pilihan penyortiran untuk programprogram yang gender erate laporan. Pilihan memilih memungkinkan pengguna untuk memilih semua entri
dalam file oleh beberapa bidang, seperti jumlah paket pekerjaan, nama file, komponen pohon keluarga
perangkat lunak, atau analis yang bertanggung jawab. Setelah entri bunga yang dipilih, opsi semacam
memungkinkan pengguna untuk memesan entri dengan beberapa tombol. Poin yang diterima dan ditetapkan
poin dijumlahkan dari entri yang dipilih dan persen lengkap dihitung. Oleh karena itu, laporan dapat
dicetak daftar semua modul dan persen lengkap untuk analis tertentu, paket pekerjaan, atau kriteria
yang dipilih lainnya. Telah ditemukan berharga untuk memungkinkan operasi Boolean pada bidang
pemilihan tersebut (analis A dan subsistem B) dan untuk menyediakan bidang semacam besar dan kecil
(misalnya, untuk daftar modul dalam urutan abjad oleh analis).
Sebuah ekstensi ketiga adalah untuk menambahkan tanggal sasaran dan tanggal penyelesaian
sebenarnya untuk setiap record modul. Dalam ekstensi ini bidang Status tonggak individu digantikan oleh
dua tanggal. Bidang tanggal pertama adalah target yang menunjukkan kapan tonggak harus dipenuhi.
Tanggal Target tidak harus digunakan untuk semua modul atau tonggak tetapi berguna di mana
interdependensi ada antara tonggak modul tertentu dan beberapa elemen lain dalam sistem. Saling
ketergantungan ini mungkin ada dalam tahap desain sampai batas tertentu, tetapi mereka menjadi sangat
penting selama fase integrasi proyek.

Bidang tanggal penyelesaian yang sebenarnya menjadi bendera mengidentifikasi ketika tonggak tercapai.
Dengan menambahkan poin ditugaskan ke tonggak yang memiliki tanggal yang sebenarnya masuk dalam file, persen
lengkap dapat dihitung.
Menggunakan dua bidang tanggal memiliki dua keuntungan: Anda dapat memantau jadwal interde- pendence
dan catatan sejarah ada untuk analisis masa depan. Dengan membuat bidang tanggal yang dipilih dan diurutkan,
laporan tambahan dapat dihasilkan. Dengan asumsi bahwa tion tonggak integra telah diidentifikasi, daftar semua
modul yang menarik dapat dipilih dengan nomor paket pekerjaan, identifikasi pohon keluarga, atau nama modul
individu. Tanggal target untuk tonggak yang menarik kemudian dapat dimasukkan. Sebagai tanggal tonggak
integrasi datang lebih dekat, daftar semua modul yang menarik yang memiliki tanggal jatuh tempo tertentu dan
belum selesai dapat diberikan kepada analis atau paket-kerja manager usia bertanggung jawab. Bijaksana
penggunaan daftar ini secara periodik dapat digunakan untuk memantau dan memotivasi staf program untuk
memastikan bahwa tonggak terpenuhi. Biasanya, beberapa daftar ini dalam berbagai tahap aktif sekaligus sebagai
tonggak utama yang datang. Telah ditemukan bahwa memilih sekitar satu tonggak utama bulan dan mulai daftar
beberapa bulan sebelum tanggal target sangat efektif. Tonggak lebih dari ini cenderung mengatur beberapa atau
bertentangan tujuan untuk analis individu. Juga, daftar harus dimulai cukup baik di muka untuk memberikan waktu
yang cocok untuk pekerjaan yang harus diselesaikan dan untuk memungkinkan Anda untuk melembagakan
workarounds jika muncul masalah.
Perlu dicatat bahwa pertemuan tanggal interdependensi ini benar-benar terpisah dari pengukuran kinerja.
Ada kemungkinan bahwa dalam subsistem mengingat kinerja yang mungkin sepenuhnya memadai, mengatakan 75
persen selesai, namun acara integrasi kunci mungkin telah terjawab. Manajer harus menyadari kedua elemen. Jika
kinerja di mana ia harus tapi acara integrasi telah terjawab, hal ini dapat berarti orang yang ager mandat 's tidak
berkonsentrasi pada barang yang tepat dan perlu diarahkan.

Bergulir Dasar
Masalah potensial dengan sistem poin yang dijelaskan sejauh ini ada hubungannya dengan efek yang dikenal
sebagai dasar bergulir. Baseline bergulir terjadi selama masa program sebagai item baru yang terus didefinisikan
dan ditambahkan ke file status. Ini memiliki efek Chang-ing dasar, yang menyebabkan persen lengkap untuk
bervariasi secara independen dari tonggak diterima. Selama periode ketika beberapa item baru ditambahkan ke
file, persen selesai secara akurat mencerminkan kinerja yang sesungguhnya. Di lain waktu, item baru ditambahkan
secepat tonggak ditetapkan sebelumnya terpenuhi, melaporkan perkembangan cenderung untuk meratakan keluar.
Dalam beberapa kasus di mana lebih item baru yang ditambahkan dari item lama selesai, kemajuan negatif
dilaporkan.
Masalah ini diatasi dengan membebaskan baseline untuk unit kerja atau paket pekerjaan dan melaporkan
kemajuan pada unit. Artinya, sekali paket pekerjaan didefinisikan, tidak ada poin baru yang dialokasikan untuk
paket. Jika, untuk beberapa alasan, maka diputuskan modul tertentu harus berpisah demi modularitas atau
efisiensi komputasi, titik-titik tersebut juga berpisah. Dalam contoh di mana ruang lingkup perubahan kerja
karena kekhilafan atau mengubah saluran con, upaya ini memprogram dan baik paket pekerjaan baru diciptakan
atau paket pekerjaan yang ada diperluas dengan peningkatan yang sesuai poin.
Ini memiliki efek mengukur kinerja pada paket pekerjaan aktif atau terbuka saja, bukan pada sistem
secara keseluruhan. Namun, karena kinerja yang dibandingkan dengan jadwal yang ditetapkan, yang juga terdiri
dari unit kerja, perbandingan tersebut valid dan berguna.

Laporan
Beberapa informatif detail dan ringkasan laporan dapat dihasilkan dari data file. Laporan detail paling
menyeluruh, tentu saja, adalah daftar dari semua elemen. Daftar tersebut dapat berguna dalam membuat daftar
inventaris barang software yang akan disampaikan dan dapat digunakan selama audit konfigurasi fisik. Daftar lain
dapat diurutkan dan / atau dipilih oleh paket pekerjaan atau nomor identifikasi pohon keluarga. Daftar tersebut
menunjukkan status modul tertentu dalam himpunan bagian dari struktur rincian kerja atau barang-barang
fungsional dari sistem. Jenis lain atau pilihan oleh analis menunjukkan status yang bertanggung jawab usaha
individu tertentu. Gambar 7-8 melalui laporan ringkasan sampel 7-11 acara. Mengumpulkan data dari beberapa
ringkasan berjalan memungkinkan tingkat penyelesaian yang akan dihitung, di mana tren atau prediksi kinerja
masa depan dapat dibuat.