Chapter

Chapter 117006018 Deppy Sontani Ikbaludin117006026 Irfan Pujiana117006031 Yuki Rizki Adam Nugraha117006042 Muhammad Faisal Sofyan117006050 Holilur Rahman7Pengembangan 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.ObjectivePengujian 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.WorkbenchGambar 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.#GambarInputDua input berikut diperlukan untuk menyelesaikan langkah ini:dokumentasi Proyek. Ini termasuk rencana proyek, tujuan, ruang lingkup, dan output yang didefinisikan.proses pengembangan perangkat lunak. Ini termasuk prosedur dan standar untuk diikuti selama pelaksanaan proyek.

Do ProcedureKelima tugas berikut direkomendasikan untuk mengatur proses pengujian: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.Tentukan lingkup pengujian. Manajer uji mendefinisikan ruang lingkup pengujian, meskipun semua atau sebagian dari lingkup dapat didefinisikan oleh standar pengujian.Menunjuk tim uji. Manajer pengujian, manajer proyek, atau manajemen TI harus menunjuk tim uji.Pastikan dokumentasi pembangunan. Manajer pengujian harus memverifikasi bahwa dokumentasi pembangunan yang memadai tersedia untuk melakukan pengujian yang efektif.Validasi proses Status uji estimasi dan proyek. Perkiraan uji dapat dikembangkan oleh salah satu manajer tes atau manajer proyek.Tugas 1: Menunjuk Test ManagerTerlepas 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 pengujianMenunjuk tim ujiTentukan proses pengujian dan kiriman yang dihasilkanMenulis / mengawasi rencana ujiMenganalisis 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 PengujianPasal 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 TeamTim 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:Kesalahpahaman tidak akan terdeteksi, karena checker akan menganggap apa yang ia diberitahu benar.Penggunaan yang tidak benar dari proses pembangunan mungkin tidak terdeteksi, karena individu mungkin tidak mengerti proses.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 .Staf IT optimis dalam kemampuan mereka untuk melakukan pekerjaan bebas cacat dan dengan demikian kadang-kadang meremehkan kebutuhan untuk pengujian ekstensif.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 internalDalam 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 EksternalPengujian 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 KerugianKeuntungan 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-ITPengujian 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 KombinasiDalam 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 PembangunanPenguji 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 KegagalanPenguji harus peduli bahwa proses dokumentasi akan gagal, untuk mencegahnya yaitu dengan melakukan cara :Membantu dalam perencanaan dan pengelolaan sumber dayaBantuan untuk merencanakan dan melaksanakan prosedur pengujianBantuan untuk mentransfer pengetahuan tentang pengembangan perangkat lunak di seluruh siklus hidupMempromosikan pemahaman bersama dan harapan tentang sistem dalam organisasi dan-jika software yang dibeli-antara pembeli dan penjualTentukan apa yang diharapkan dan memverifikasi bahwa adalah apa yang disampaikanMenyediakan manajer dengan dokumen teknis untuk meninjau di perkembangan yang signifikan tonggak, untuk menentukan bahwa persyaratan telah dipenuhi dan sumber daya harus terus dikeluarkanTahap PembangunanProgram 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:InisiasiPembangunanDefinitionDesainProgrammingTestingOperasiPermintaan ProjectStudi kelayakanAnalisis biaya / manfaatRingkasan Software

Tahap Pembangunan...Persyaratan fungsionalpersyaratan dataSistem spesifikasi / subsistemspesifikasi Programspesifikasi databasePanduan penggunaPanduan Operasionalpetunjuk pemeliharaan Programrencana ujiUji laporan analisisMengukur Dokumentasi Kebutuhan ProyekFormalitas, 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:Orisinalitas diperlukan. Keunikan dari aplikasi dalam organisasi. Tingkat umum. Jumlah kekakuan yang berhubungan dengan aplikasi dan kebutuhan untuk menangani berbagai situasi selama pemrosesan. Span operasi. Persentase total kegiatan perusahaan dipengaruhi oleh sistem. Perubahan lingkup dan tujuan. Frekuensi perubahan diharapkan persyaratan selama hidup dari sistem. kompleksitas peralatan. Kecanggihan perangkat keras dan komunikasi yang jalur yang dibutuhkan untuk mendukung aplikasi. Personil yang ditugaskan. Jumlah orang yang terlibat dalam mengembangkan dan main- yang memuat sistem aplikasi. biaya Pembangunan. Total dolar yang dibutuhkan untuk mengembangkan aplikasi. Kekritisan. Pentingnya sistem aplikasi untuk organisasi. waktu respon rata-rata untuk program perubahan. Jumlah rata-rata waktu yang tersedia sangat menginstal perubahan ke sistem aplikasi.Waktu respon rata-rata untuk memasukkan data. Jumlah rata-rata waktu yang tersedia untuk memproses transaksi aplikasi. Bahasa pemrograman. Bahasa yang digunakan untuk mengembangkan aplikasi. pengembangan perangkat lunak serentak. Aplikasi lain dan sistem pendukung yang perlu dikembangkan secara bersamaan untuk memenuhi total misi.Tingkat DokumentasiMengilustrasikan metode sederhana untuk menentukan tingkat dokumentasi yang diperlukan. Ada empat tingkat dokumentasi, yaitu:MinimalInternalDokumen Kerjapublikasi FormalMenentukan Apa Dokumen Harus DiproduksiGambar 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: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. 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 IndividuPenguji 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. PemirsaRedudansiFleksibilitasUkuranFormatKonten UrutanMendokumentasikan beberapa program atau beberapa fileJudul BagianFlowchart dan Tabel KeputusanBentukTugas 5: Validasi Test Memperkirakan dan Proses Pelaporan Status proyekProyek 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 EstimateBanyak 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 pemeliharaanKurangnya pemahaman tentang efek dari berbagai teknis dan kendala manajemenSetiap proyek adalah unik, yang menghambat proyek-to-proyek perbandinganKurangnya data historis terhadap yang model dapat diperiksaKurangnya data historis untuk kalibrasiDefinisi yang tidak memadai dari tujuan perkiraan dan pada tahap apa perkiraan diperlukan sehingga input dan output dapat dipilih tepatSpesifikasi yang tidak memadai lingkup perkiraan (apa yang termasuk dan apa yang dikecualikan)Pemahaman memadai tempat yang perkiraan tersebut didasarkanStrategi untuk Software Estimasi BiayaAda lima metode yang umum digunakan untuk memperkirakan biaya pengembangan dan pemeliharaan sistem perangkat lunak: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. 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.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.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.Parametric modeling method. Model parametrik terdiri dari metode estimasi yang paling sering digunakan dan dijelaskan di bagian berikut.

Parametrik ModelModel parametrik dapat dibagi menjadi tiga kelas: Regresi, Heuristik, dan Fenomenologis.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.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. 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.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.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.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.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. 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.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 SoftwarePerkiraan 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 Termasuk Semua Faktor DibutuhkanFaktor-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 operasio Proyek real-time mandirio Standalone, aplikasi non-real-timeo 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 :Jumlah perubahan yang diharapkan dalam persyaratanJumlah detail dihilangkan dari spesifikasi kebutuhanPengembangan bersamaan perangkat keras yang terkait, menyebabkan perubahan dalam spesifikasi perangkat lunakTarget 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. o 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 dari Memperkirakan Biaya Model EstimateJumlah 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 benarTes 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 memperkirakano Model memperkirakan termasuk dalam metodologi pengembangan systemo Paket perangkat lunak untuk mengembangkan perkiraan softwareo Fungsi poin dalam mengestimasi biaya perangkat lunakMenghitung Status Proyek Menggunakan Sistem TitikTes 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 KinerjaKinerja 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 TitikTitik 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.EkstensiSejumlah 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 program-program 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 DasarMasalah 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.LaporanBeberapa 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.