PROSES TESTING

PROSES TESTING

oleh: Tumar

Proses testing proyek pengembangan piranti lunak adalah siap untuk dilaksanakan. Termasuk kegiatan rencana tes dan tes implementasi program. Maksud dari rencana aktivitas tes adalah untuk menentukan cara yang resmi didemonstrasikannya piranti lunak komputer sampai memuaskan hasilnya berdasarkan perjanjian dan menurut kinerjanya Persyaratan Spesifikasi Piranti Lunak telah disetujui. Aktivitas ini adalah bagian dari rancangan, tapi dilakukan bersamaan dengan aktivitas rancangan pendahuluan dan sangat bergantung pada rancangannya. Elemen yang esensial pada rencana tes adalah difinisi pada awal tes itu harus sukses dilaksanakan untuk penerimaan produk piranti lunak – produk diterima pada tes akhir. Tes ini dan persyaratan penerimaan yang lain akan didifinisikan dan yang telah disetujui sampai dengan awal pelanggan ( prioritas untuk PDR jika mungkin, tentu saja prioritas untuk CDR).
Perencanaan dan prosedur untuk testing / uji coba adalah pada awal tulisan dalam siklus pengembangan dan dibawa selama implementasi. Suatu tes / uji coba mempunyai tiga tujuan utama yaitu :
1. Verifikasi produk kinerja piranti lunak seperti yang ditentukan dalam dokumentasi rancangan.
2. Verifikasi produk kinerja piranti lunak yang memuaskan seluruh persyaratan yang ditentukan dalam Spesifikasi Persyaratan Piranti Lunak, dan
3. Asalkan Manajemen Proyek dengan status laporan proyek kecermatan implementasi piranti lunak.

Proses tes konsisten pada dua tahap tes dan empat tingkatan tes yaitu :

1. Tes / uji coba Pengembangan
   a. Program Unit Tes
   b. Modul Tes Integrasi,
2. Tes Validasi
   a. Verifikasi Tes,
   b. Tes diterima,

Tes Pengembangan pada program komputer adalah didifinisikan yang prosesnya interaktiv ditentukan apakah setiap langkah pada suatu Jenis Konfigurasi Program Komputer (a Computer Program Cunfiguration Item / CPCI) penyelesaian proses pengembangan seluruhnya pada persyaratan menurut langkah sebelumnya. Kinerja piranti lunak didemonstrasikan seperti yang ditetapkan dalam dokumentasi rancangan dan kinerjanya proses implementasi adalah cermat. Aktivitas tes pengembangan terutama adalah kontrol oleh organisasi pengembangan piranti lunak.

Definisi validasi adalah evaluasi, intergrasi dan aktivitas tes mengangkat keluar tingkat sub sistem piranti lunak hingga memastikan pengembangan piranti lunak itu memuaskan persyaratan kinerjanya dan kriteria rancangannya memuaskan dalam Persyaratan Spesifikasi Piranti Lunak. Validasi piranti lunak terutama adalah kontrolnya oleh organisasi penjamin kualitas. Catatan tes itu dukungan organisasi tersendiri, di bawah pengawasan proyek, utilitas boleh untuk validasi tes yang telah didiskusikan dalam modul 4. Pada modul ini, bagaimanapun, fungsinya kami terima adalah kinerjanya leh organisasi penjamin kualitas.
Hasil tes/uji coba adalah dgunakan sebagai laporan selama kejadian penting pada implementasi piranti lunak. Kejadian penting adalah mudah didifinisikan oleh kesuksesan yang lengkap sebuah definisi tes dan secara lengkap didokumentasikan dalam laporan hasil tes / uji coba.
Proses tes / uji coba, kumpulan dokumentasi, dan tinjauan program formal adalah digambarkan dalam bagian yang berturut-turut.


8.1 PROSES TES

Proses tes / uji coba adalah kinerja menjelaskan tahap pengembangan piranti lunak dan konsisten terhadap tiga (3) dasar aktivitas antara lain :

1. generasi rencana tes secara rinci dan prosedurnya,
2. kinerja pada aktivitas tes/uji coba, termasuk resolusinya dan tes ulang pada kekurangan piranti lunak, dan
3. dokumentasi hasil tes / uji coba untuk mengikuti jejak laporan.

Gambar 8.1 diilustrasikan waktu yang relativ pada tiga aktivitas ini dalam tahap proyek, produk dokumentasi, dan tinjauan persyaratan sampai pada verifikasi hasilnya proses tes / uji coba.
Rencana Tes / Uji Coba digambarkan lengkap program tes / uji coba piranti lunak dan basis dalam Persyaratan Spesifikasi Piranti Lunak. Ini adalah disampaikan dalam format pendahuluan dan tinjauan pada PDR . Selama Tahap Rancangan Rinci, komentar dari PDR dalam rencana

Tes Pendahuluan adalah yang tergabung kedalam Rencana Tes / Uji Coba, dan tambahan rinci mengenai konfigurasi tes uji coba, piranti lunak tes / uji coba dan tes/uji coba khusus adalah pengembangan dan tergabung kedalam dokumen. Rencana Tes / Uji Coba disampaikan dalam format akhir pada CDR. Setelah CDR Rencana Tes / Uji Coba di bawah konfigurasi formal kontrol dirubah. Pada basis Rencana Tes dan Dokumen Rancangan Rinci, Prosedur Tes Pendahuluan adalah tertulis dan ditinjau pada Tinjauan Prosedur Tes ( The Test Prosedure Review/ TPR). Prosedur Tes / Uji Coba adalah diperbarui dalam basis TPR dan disampaikan dalam format akhir lebih dulu sampai tes/ uji coba formal. Selama proses tes / uji coba, Prosedur Tes / Uji Coba adalah di bawah kontrol konfigurasi, tapi dapat dimodifikasi jika berdasarkan ketidak tepatan. Laporan Tes / Uji Coba adalah turunan selama proses tes / uji coba dan tinjauan pada Penyerahan Tinjauan Piranti Lunak (Software Acceptance Review/ SAR).
Multi organisasi adalah termasuk di dalam proses tes/ uji coba, keduanya dalam grup yang memproduksi piranti lunak yang dihasilkan dan digunakannya. Yang berikutnya dalam diskusi, organisasi pemakai bertanggung jawab untuk diterimanya produk akhir piranti lunak akan sebagai referensi pemakai. Organisasi ini biasanya konsisten pada keduanya personil penjaminan kualitas dan aktual sistem mudah digunakan.

Sebagaian besar berpengaruh pada organisasi dalam proses tes/uji coba adalah organisasi penjamin kualitas untuk grup produksi piranti lunak. Sejumlah metoda verifikasi dikerjakan itu untuk menguji organisasi. Pilihan di mana metoda verifikasi pada penggunaannya akan tergantung pada kebutuhan itu yang dibuktikan dan tingkatan pengujian dilakukan. Uji organisasi, dengan metoda verifikasi, dan bagian tingkatan test yang diuraikan sebagai berikut :

8.1.1 Jaminan Kualitas (Quality Assurance-QA)
Dalam rangka memaksimalkan efektivitas penjaminan kualitas (QA) program, personil QA harus tidak terikat pada organisasi yang bertanggung jawab untuk pengembangan produk. Ini dapat terpenuhi dengan penetapan organisasi QA itu yang secara langsung di bawah pengendalian manajemen perusahaan, bukannya di bawah manajemen proyek piranti lunak. Bagian yang berikut menguraikan suatu program jaminan mutu dan suatu alternatif ke QA formal.

Tanggung Jawab Penjamin Kualitas dan Otoritas (Quality Assurance Responsibility and Authority)
Mutu Tanggung jawab Penjaminan Dan Otoritas. Organisasi QA dilibatkan dalam semua tahap pengembangan program, dari persiapan proposal sampai penyerahan dan penerimaan akhir. Otoritas Dan Tanggung jawab yang spesifiknya diringkas gambar 8.2. Kemerdekaan QA yang organisatoris meyakinkan bahwa pengecekkan dan keseimbangan yang penting bagi suatu QA program sukses yang tidak bisa dipisahkan di dalam struktur manajemen. Karena tanggung jawab yang terakhir untuk produk yang disampaikan pada umumnya terletak di tangan organisasi pengembangan itu, QA yang mandiri menyediakan suatu saluran laporan terpisah untuk monitoring kemajuan pengembangan. Organisasi QA mempunyai otoritas untuk menerima atau menolak semua produk bisa disampaikan, seperti halnya untuk melakukan audit yang sedang dikerjakan dan tinjauan ulang. Dalam hal konflik antara QA dan organisasi pengembang, resolusi harus terpenuhi di tingkatan manajemen perusahaan.

Penjamin Kualitas Piranti lunak (Software Quality Assurance)
Mutu hanya dapat dibangun ke dalam piranti lunak oleh para programmer dan para perancangnya, tetapi tinjauan ulang mandiri dapat berperan untuk mutu piranti lunak dengan menemukan dan melaporkan permasalahan, atau permasalahan potensial, dan dengan berikut yang berdasar pada resolusi. Seperti permasalahan. Dengan penggunaan teknik pemrograman yang modern dan mencakup personil QA di dalam tinjauan ulang teknis sering, kesalahan dapat terbongkar lebih awal dan yang dikoreksi sebelum efek air terjun kecil mereka sampai pada sistem. Sepert yang dibahas pada bab 9, manajemen konfigurasi piranti lunak di dalam memelihara melalui suatu Perpustakaan Program Komputer (CPL). Piranti lunak personil penjamin kualitas menggunakan CPL itu yang melaporkan prosedur permasalahan dokumen piranti lunak dan perubahan jejak untuk mengoreksi kesalahan. Piranti lunak Grup QA adalah bertanggung jawab untuk:

1. Melihara Pengendalian yang tegas atas spesifikasi, dokumentasi disain, kode piranti lunak, dan konfigurasi test untuk meyakinkan capaian dan persyaratan disain yang disatukan dan kemampuan jejak persyaratan itu ke spesifikasi tingkat yang lebih tinggi didokumentasikan.
2. Tinjauan ulang disain piranti lunak sebelum coding.
3. Ambil bagian audit dan tinjauan ulang teknis disain dan aktivitas pengembangan.
4. Melaksanakan tinjauan ulang untuk memastikan kesetiaan ke standard dan prosedur piranti lunak.
5. Melaporkan permasalahan piranti lunak dan pertentangan dan monitoring tindakan korektif.
6. Tinjauan ulang dan rencana test kecakapan yang disetujui dan memeriksa prosedur.
7. Melakukan monitoring test untuk memastikan bahwa prosedur diikuti dan semua ukuran-ukuran sukses dicukupi.

Piranti lunak QA Test Tinjauan ulang memeriksa prosedur untuk memastikan bahwa mereka adalah konsisten dengan rencana pengujian piranti lunak dan arus dokumentasi, yang mereka uji itu semua kebutuhan, dan bahwa mereka berisi ukuran-ukuran penerimaan dan cukup sukses. Kecakapan menguji piranti lunak mendorong ke arah penerimaan program yang dimonitor oleh piranti lunak QA untuk memastikan bahwa:

1. Uji prosedur disetujui sebelum start pengujian.
2. Uji perangkat keras dan lunak adalah dikendalikan dan bisa diterima.
3. Semua test yang diselenggarakan sesuai dengan prosedur pemeriksaan dan memenuhi test.
4. Semua piranti lunak dan definisi test yang ditemukan dalam pengujian direkam.
5. Semua koreksi piranti lunak ddikoreksi kembali.
6. Semua data test direkam dan yang mencerminkan penemuan nyata perjanjian
7. Semua dokumentasi test dirawat untuk mengijinkan pengulangan kemampuan test itu.
8. Status uji laporan dirawat dengan teliti.
9. Uji laporan yang mencerminkan persyaratan perjanjian
10. Semua dokumentasi disain diperbaharui untuk mencerminkan perubahan buat yang menguji.
11. Semua pengujian adalah lengkap, permasalahan dipecahkan, dan piranti lunak adalah bisa diterima untuk tahap yang berikutnya menguji atau untuk penyerahan.

Di dalam melakukan dari tiap test, pengukuran, pengamatan, dan keluaran untuk prosedur test yang direkam dan dibuktikan oleh QA. Laporan Test ditinjau dan bersertifikat oleh QA untuk memastikan korelasi antara sasaran hasil test dan hasil. Piranti lunak QA meninjau ulang dokumentasi piranti lunak yang berikut dengan konsistensi, kelengkapan, pemenuhan dengan standard, dan informasi perubahan perusahaan :

1. Merancang Rencana
2. Spesifikasi Kebutuhan piranti lunak.
3. Menghubungkan Spesifikasi
4. Dokumen Rancangan Fungsional
5. Pengujian rencana
6. Pengujian prosedur
7. Pengujianlaporan
8. Dokumen Rancangan Rinci
9. Dokumen Instruksi Operasi
10. Dokumen Uraian Versi

Semua program komputer bisa menyampaikan oleh perangkat lunak QA yang bersertifikat. Sertifikasi ini dibuat sebelum diedarkan kepada pemakai itu. Perangkat lunak CPCI secara formal bersertifikat ketika kondisi-kondisi yang berikut ini dicukupi:

1. Semua dokumen relevan dan pekerjaan yang digambarkan adalah lengkap, sekarang, dan di bawah pengendalian perubahan.
2. Tembusan arsip QA dikendalikan menurut format prosedur yang telah mapan.
3. Semua pengujian kecakapan diselesaikan, dokumentasi test diperbaharui dan dilepaskan ketika diperlukan.
4. Semua laporan masalah piranti lunak telah tertutup.

Alternatif ke QA formal

Proyek lebih kecil, dengan suatu staff piranti lunak kurang dari appromimately 20 orang-orang, dapat dengan sukses diatur tanpa jaminan mutu formal, seperti yang telah diuraikan di atas. Suatu penyelamatan biaya substansiil adalah mungkin dengan memodifikasi prosedur QA yang formal seperti yang diuraikan sebagai berikut:

1. Manager proyek, bukannya suatu QA organisasi QA yang mandiri, memberi hak penyerahan dokumen dan piranti lunak.
2. Tidak ada tinjauan ulang mandiri atau monitoring kemajuan teknis pekerjaan.
3. Tidak ada jejak audit QA yang diproduksi.
4. Tinjauan ulang material terpenuhi melalui pengamatan tinjauan ulang dan tinjauan ulang manajemen proyek.

8.1.2 Metoda Verifikasi (Verification Method)

Verifikasi harus dilakukan untuk semua kebutuhan subsistem perangkat lunak oleh penggunaan satu atau lebih metoda yang diperkenalkan di bawah:

1. Inspection. Metoda ini digunakan untuk memverifikasi bahwa piranti lunak menemukan kebutuhan yang tidak bisa dipertunjukkan melalui pengujian operasional. Itu meliputi pengujian hirarki piranti lunak dan diagram alir fungsional, program yang terdaftar, Bahasa Disain Program (Program Design Language (PDL)), dan berhubungan uraian naratif. Kebutuhan ini meliputi format perangkat keras dan piranti lunak dan kesetiaan bagi pemmrogram dan standard disain.
2. Comparison. Metoda ini membandingkan pelaksanaan unsur piranti lunak yang baru dengan suatu program baku yang dikenal, diikuti oleh hasil analisa.
3. Analysis. Metoda ini meliputi suatu analisa keluaran program untuk mengevaluasi capaian algoritma pada berbagai langkah-langkah proses. Itu digunakan untuk mengesahkan logika dan apa yang dihasilkan persamaan yang kompleks tidaklah secara langsung dihubungkan dengan masukan. Analisa terdiri dari perhitungan yang mandiri dari hasil yang diharapkan dan membandingkannya hasil ini dengan hasil program yang sebenarnya.
4. Prior Kecakapan. Metoda ini didasarkan pada suatu demonstrasi bahwa unsur-unsur CPCI sudah lulus lewat kecakapan di dalam sistem lain pemakai.
5. Demonstration. Metoda ini meliputi pengamatan atas capaian sistem di dalam suatu lingkungan yang dikendalikan. Itu menyediakan verifikasi dalam real-time dari fungsi yang terpisah, seperti memasang cahaya atau mulai, membunyikan alarm, warna display yang bervariasi, dan seterusnya.
6. Usage. Metoda ini melibatkan pelaksanaan yang diulangi bersama piranti lunak dengan satu atau lebih metoda uraikan di atas.
7. Test. Metoda ini terpenuhi dengan pelaksanaan satu rangkaian test dengan masukan yang dikenal perlu menghasilkan keluaran dikenal. Hasil percobaan harus mampu untuk menyelesaikan pengujian setelah test.

8.1.3 Menguji Tingkatan (Test Levels)

Pengujian Unit Program dilakukan oleh programmer dan adalah yang diharapkan untuk memverifikasi unit program yang dilaksanakan tunggal itu menurut rancanngan yang diharapkannya. Pengujian pengintegrasian modul dilakukan oleh pengembang organisasi dan dimaksudkan untuk memverifikasi unit program yang individu itu menghubungkan satu sama lain dengan tepat dan bahwa, sebagai kelompok, mereka melaksanakan fungsi yang menggambarkan dokumentasi disain. Pengujian Verifikasi dilakukan oleh organisasi penjamin kualitas dan yang diharapkannya untuk memverifikasi bahwa "as-built" sistem yang dibuat memuaskan kebutuhan seperti yang ditetapkan dalam dokumentasi kebutuhan, Tiga tingkatan ini dilakukan di lokasi pengembangan, yang sering berbeda dengan lokasi operasional itu.

Pengujian Penerimaan dilakukan di lingkungan operasional pemakai, sebagai usaha yang dihubungkan antara organisasi penjamin kualitas dan pemakai, dan yang dimaksudkan untuk menyediakan jaminan yang akhir pemakai itu dengan yang sistemnya dilaksanakan seperti yang ditetapkan dalam lingkungan yang diharapkan. gambar 8.3 menguraikan yang empat tingkatan test piranti lunak yang dibahas pada paragraph yang berikut.

Unit Program Pengujian (Program Unit Testing)
Tujuan Pengujian Unit Program adalah untuk memverifikasi bahwa "as-built" unit program yang dilaksanakan seperti yang ditetapkan pada Dokumentasi Rancangan rinci. Suatu unit yang digambarkan sebagai program komputer tunggal yang dapat diuraikan dalam kaitannya dengan masukan, proses, dan keluaran. Sebagai contoh, di dalam unit Fortran akan sesuai dengan suatu program utama atau suatu subroutine. Test formal merencanakan, memeriksa prosedur, dan menghasilkan untuk Pengujian Unit Program yang tidak dihasilkan kecuali jika test unit memverifikasi bahwa piranti lunak tidak menemukan suatu kebutuhan yang kemudian membuktikan dalam program test.

Test informal merencanakan, memeriksa prosedur, dan hasil dihasilkan oleh programmer ketika perancangan dan coding unit program adalah yang didokumentasikan sesuaian dengan pola unit Pengembangan. Masukan yang utama kepada rencana test dan prosedur adalah Dokumen Rancangan Rinci. Pengujian Unit Program dilakukan secara terpisah dari uji coba unit lain dan terdiri dari dua tahap. Tahap yang pertama melibatkan penyusunan unit itu dan ia mengoreksi kesalahan yang ditandai oleh compiler itu.

Ini menggunakan yang meliputi penggunaan compiler lain yang membantu, seperti daftar referensi silang, untuk memverifikasi bahwa tidak ada definisi variabel kesalahan telah dibuat. Tahap yang kedua dimaksudkan untuk menemukan apapun kesalahan logika di dalam unit itu. Tujuannya adalah untuk memverifikasi bahwa masing-masing cabang program, masing-masing persamaan, dan arus logika dengan baik dieksekusi. Pengujian dilanjutkan sampai semua mengetahui kesalahan telah dihapus dan logika unit program yang disainnya kode matematika.Rancangan tak efisien mempengaruhi dokumentasi yang disampaikan harus ditangani sesuai standar jaminan kualitas yang digambarkan. Secara umum, rancangan yang tak efisien tidak mempengaruhi fungsi selain dari yang ada dalam sistem piranti lunak kodenya dikoreksi, dan perubahannya adalah " red-lined" di dalam suatu salinan Bagian Dokumen Rancangan Rinci yang sesuai, yang mana adalah Folder Pengembangan Unit terpelihara. Ketika kekurangan rancangan yang mempengaruhi antarmuka dengan lain organisasi atau memerlukan suatu spesifikasi perubahan, proses perubahan yang formal dimulai dengan seketika.

Walaupun pengujian adalah informal yaitu, diselenggarakan tanpa prosedur tertulis formal, ini merupakan suatu aktivitas yang direncanakan. Perencanaan adalah yang penting bagi penggunaan komputer yang efisien dan waktu programmer itu. Perencanaan yang diperlukan meliputi penjelasan apa yang programmer berniat untuk memenuhi test yang ditentukan, masukan apa yang diperlukan, keluaran apa yang diharapkan, dan bagaimana test akan jadi diselenggarakan. Program-mer perlu mempersiapkan daftar test untuk dilaksanakan untuk unit masing-masing dan memelihara daftar ini di dalam folder. Test Unit Program diselesaikan sebagai berikut:

1. ketika programmer telah menyelesaikan program test yang direncanakannya dan dicukupi kode yang memenuhi disain itu,
2. ketika semua mengetahui kesalahan telah dihapuskan, dan
3. ketika kode telah ditinjau oleh suatu tim tinjauan ulang melalui kode yang sedang berjalan.

Tinjauan ulang Tim dapat terdiri dari satu atau banyak penulis resensi buku, dengan beberapa di antara mereka terutama lebih disukai dari tim pengembangan. Terkecuali menemukan finding bug. Di dalam kode, tinjauan ulang mempunyai keuntungan tambahan yang menyediakan para programmer lain dengan pengetahuan cukup untuk mengambil alih lebih lanjut uji coba modul jika siapa programmer yang menulis program itu adalah memberikan beberapa alasan dari sesuatu yang tersedia. Suatu daftar nama untuk mengkonfirmasikan bahwa Pengujian Unit Program adalah lengkap meliputi yang berikut:

1. Masing-Masing persamaan telah diuji menggunakan semua parameter yang bisa diterapkan dengan nilai nominal, nilai di batas yang ditetapkan, dan nilai di luar batas itu di mana jika sesuai. Persamaan ini perlu meliputi persamaan pengulangan yang dikendalikan.
2. Tiap-Tiap program cabang telah dieksekusi.
3. Semua mengetahui persandian dan kesalahan disain telah dikoreksi.
4. Semua test yang sukses telah direkam di dalam folder Pengembangan Unit.
5. Hasil percobaan dari test sukses telah diselamatkan.
6. Semua pekerjaan tulis menulis untuk perubahan disain telah diaktipkan.

Sekali ketika Pengujian Unit Program diselesaikan, programmer mengisi suatu Format Pengiriman Perpustakaan Program Komputer (Computer Program Library Transmittal Form (CTF)) dan menyampaikan CTF itu dan kode kepada pustakawan program komputer (lihat bab 9). Unit kemudian adalah mengkombinasikan dengan Pengintegrasian Modul dan unit terkait yang mulai menguji.

Menguji Pengintegrasian Modul (Module Integration Testing)
Menguji Pengintegrasian Modul yang konsis diri dari membangun keseluruhan subsistem perangkat lunak dengan menambahkan pengulangan-pengulangan unit program, kemudian ketika unit program terintegrasi, pengujian untuk memastikan bahwa subsistem piranti lunak yang diterapkan memenuhi satu yang diuraikan dokumentasi disain. ( Pengintegrasian Modul Pengujian adalah juga dikenal sebagai Modul yang diuji, Menguji Pengintegrasian atau Kualifikasi Uji Pendahuluan). Jika perangkat lunak yang penggunaannya diterapkan adalah suatu pendekatan top-down, Menguji Pengintegrasian Modul yang terdiri dari mengintegrasikan unit program yang tertinggi yang pertama dan penggunaan modul yang diuji sebagai bingkai yang bekerja untuk menguji masing-masing unit program secara berurutan.
Menguji Pengintegrasian Modul yang digunakannya adalah suatu building-block yang mengintegrasikan mendekati dan membangun program komputer itu dan, jika bisa diterapkan, subsistem piranti lunak. Modul yang hirarkinya tertinggi yang dulu subsistem piranti lunaknya terintegrasi. Pengintegrasian maju langkah demi langkah menurut suatu jadual berdasarkan pada fungsi itu untuk dilakukan oleh modul, inter ketergantungan mereka, ketersediaan mereka, dan data antarmuka masukan. Potongan yang digantikan untuk rutin tingkat bawah untuk mengisolasikan fungsi itu di bawah Potongan perjanjian uang digantikan langkah demi langkah oleh modul yang nyata sampai subsistem perangkat lunak adalah lengkap. Suatu keuntungan yang utama top-down pengintegrasian dan menguji pendekatan adalah bahwa alat penghubung subsistem yang utama digambarkan pada suatu tingkat tinggi hirarki, dan kemudian dibuktikan pada awal proyek itu. Sekali ketika alat penghubung dibuktikan, implementasinya dan diuji coba subsistem yang berbeda bisa dilakukan dengan bebas. Tujuan Pengujian Pengintegrasian Modul adalah untuk memverifikasi bahwa:

1. Unit Program yang individu menghubungkan satu sama lain dengan tepat untuk membentuk modul itu yang diuraikan dalam Dokumen Disain Rinci.
2. Modul telah menjadi dengan baik coded, sedemikian sehingga semua persamaan berfungsi dengan baik dan semua alur logika beroperasi seperti yang dirancang.
3. Modul menghubungkan satu sama lain untuk membentuk subsistem perangkat lunak itu yang diuraikan dalam Dokumen Disain Rinci.
4. Ada suatu kemajuan rapi ke arah kemampuan piranti lunak yang akhirnya akan jadi dibuktikan menguji Verifikasi.

Prosedur Test formal disiapkan bersama-sama oleh pengembangan software dan perusahaan penjaminan kualitas piranti lunak dan didokumentasikan, ditinjau, dan disetujui. Perusahaan penjaminan kualitas piranti lunak perlu melaksanakan suatu tinjauan ulang prosedur sebelum penggunaan mereka oleh organisasi pengembangan software. QA piranti lunak perlu memastikan bahwa semua test yang diselenggarakan sesuai dengan prosedur yang terpenuhi didokumentasikan. Apapun penyimpangan harus didokumentasikan.

Test Pengintegrasian Modul diselenggarakan menggunakan data masukan dinamis dan yang statis diperlukan untuk melaksanakan inter modul dan eksekutip yang menghubungkan dan untuk berlatih fungsi operasional. Itu adalah yang diinginkan untuk mempunyai akses pada kenyataan atau pengolah target selama Pengujian Pengintegrasian Modul. Dalam posisi ini, sistem operasi harus secara penuh mampu untuk mendukung test ini. Di mana jika Sistem Pengintegrasian Modul yang diselenggarakan penggunaannya adalah suatu simulasi pengolah target, target pengolah harus dibuat bertahap ke dalam pengujian yang secepat itu menjadi tersedia. Test kembali cukup harus terpenuhi untuk memastikan kecocokan penuh.
Suatu komplemen matematika yang penuh dan rutin digunakan, mencakup test dan bantuan debugging, harus tersedia untuk Menguji Pengintegrasian Modul. Test Perangkat keras yang diperlukan meliputi semua sekeliling keperluan: terminal pemakai, pencetak garis, disk dan pengontrol tape dan pengarah, operator menghibur, dan seterusnya. Test ini lengkap di lingkungan yang tidak mungkin diperlukan sepanjang langkah-langkah awal pengujian, tetapi akan diperlukan ketika menguji kemajuan.

Masukan Test Data yang diperlukan datang dari perangkat keras/ piranti lunak yang nyata menghubungkan, jika tersedia. Cara lainnya, masukan data harus mewakil contoh antarmuka yang nyata itu. Pengarah Test dan lain program test yang memerlukan untuk memverifikasi dan Penerimaan Pengujian harus digunakan Pengujian Pengintegrasian Modul. Ini disahihkan untuk menggunakan Verifikasi formal yang menguji sebagai hasil operasi sukses selama Menguji Pengintegrasian Modul. Menguji Pengintegrasian Modul terdiri dari dua unsur-unsur: Menguji Pengintegrasian dan Menguji Verifikasi Fungsional.

Menguji Pengintegrasian yang memverifikasi ketepatan antarmuka program dengan pengujian bahwa masing-masing program dapat dipanggil dan dihubungi oleh program itu menghubungkan dengan, dan lewat parameter dengan baik. Tujuan Pengujian Pengintegrasian Modul yang utama adalah :

1. untuk menetapkan kecocokan antara modul dan program komputer saling berinteraksi, dan
2. untuk menetapkan kecocokan program dengan antar muka eksternal mereka.

Menguji Verifikasi Fungsional yang terdiri dari menguji koleksi unit program telah diterapkan dan pengujian untuk melihat bahwa mereka berfungsi sebagai suatu modul yang terintegrasi dan melaksanakan fungsi itu yang ditugaskan kepada mereka di dalam Dokumen Disain Rinci. Menguji Verifikasi Fungsional yang terdiri dari menguji koleksi unit program yang telah diterapkan dan pengujian untuk melihat bahwa mereka berfungsi sebagai suatu modul yang terintegrasi dan melaksanakan fungsi itu yang ditugaskan kepada mereka di dalam Dokumen Disain Rinci. Pengujian Verifikasi Fungsional pada umumnya dilakukan betapapun unit program yang berisikan suatu modul, suatu yang digambarkan pada dokumentasi disain, sudah lulus lewat Pengujian Pengintegrasian.

Penyelesaian Pengintegrasian Modul yang memuaskan pengujian yang menetapkan bahwa perangkat lunak yang diterapkan dengan baik melaksanakan fungsi itu menetapkan dokumentasi disain dan adalah menyisiapkannya untuk dibuktikan melawan terhadap kebutuhan yang ditetapkan Kebutuhan spesifikasi perangkat lunak.
Menguji Verifikasi (Verification Testing)
Menguji Verifikasi yang terdiri dari test, demonstrasi, dan melakukan analisa untuk mengkonfirmasikan bahwa piranti lunak membuat puas semua kebutuhan terasang permanen dan yang diperoleh dari Spesifikasi Persyaratan Piranti lunak. Spesifikasi Disain Rinci, yang digunakan pengujian lebih awal, hanya suatu permainan peran pelajaran pelengkap di dalam menguji verifikasi. Sebagai gantinya, awal dokumen yang menyatakan kebutuhan sistem atau perangkat lunak dan sasaran hasil produk atau misi itu adalah sumber yang utama dari kasus test yang diperoleh. Suatu korelasi antara Spesifikasi Persyaratan Piranti lunak dan Rencana Test Verifikasi disiapkan dalam bentuk Rencana Test. Prosedur Dan Rencana Test formal tertulis untuk Verifikasi pengujian. Analisa dilakukan untuk kebutuhan adalah terlalu mahal untuk memverifikasi dengan pengujian atau demonstrasi.
Test Verifikasi diselenggarakan di lingkungan test yang sama sebagai Test Pengintegrasian Modul, Penggunaan komplemen piranti lunak pendukungnya penuh, perangkat keras sekelilingnya, dan alat operator, lebih pengolah target, dengan kemampuan sistem operasi penuh dan perangkat keras nyata atau realistis menghubungkan data.
Sebelum dimulai Pengujian Verifikasi, program komputer daftar harus dilepaskan, kode program komputer harus di bawah pengendalian konfigurasi formal di dalam Program Komputer Perpustakaan , dan test prosedur harus disetujui semuanya. Semua Pengujian Verifikasi diselenggarakan di bawah pengawasan proyek yang digolongkan pejamin kualitas. Oleh karena pengujian yang luas mendahului test ini, itu diharapkan bahwa secara relatif sedikit kesalahan yang terjadi akan terbongkar dan terbuka pada Pengujian Verifikasi.
Pengulangan test dan pengujian yang berlebih-lebihan harus dengan bebas dihindarkan. Disimpulkan dari test ini, semua kebutuhan yang dapat dibuktikan pada tingkatan ini akan dibuktikan dan hasil percobaan dianalisa dan melepaskan. Test memverifikasi antarmuka eksternal, mempertunjukkan bahwa program komputer membuat kepuasan fungsional yang ditetapkan dan kebutuhan tercapai, dan mempertunjukkan capaian program komputer di bawah yang menirukan kondisi-kondisi operasional yang serupa bagi mereka yang mengharapkan operasi nyata. Ke tiga tingkatan test diuraikan di atas yang diterapkan serial berkenaan dengan unit program tertentu , tetapi dilakukan secara serempak pada seluruh tahap pengujian proyek itu. Suatu unit program masuk Pengujian Pengintegrasian Modul itu yang tahapannya secepat itu telah lulus lewat Pengujian Unit Program. Pada setiap waktu selama implementasi piranti lunak, suatu Verifikasi Test mungkin adalah dijumpai. Yang dipertunjukan bahwa tujuannya tercapai pada keseluruhan kebutuhan subsistem piranti lunak.

Pengujian Penerimaan
Banyak dari Test Verifikasi yang diulangi Pengujian Penerimaan untuk memverifikasi bahwa perangkat lunak yang dilaksanakan di lingkungan yang operasionalnya sebagai di dalam lingkungan test. Di dalam kejadiannya banyak orang, Pengujian Penerimaan adalah satu-satunya pengujian di mana perangkat lunak beroperasi dengan alat penghubung eksternal yang nyata, dibandingkannya dengan perangkat lunak test dan perangkat keras. Pada PDR persetujuan harus dicapai dengan pemakai bahwa pelaksanaan dari kasus test ini di dalam suatu cara menguraikan Test yang menggunakan rencana suatu data base yang disetujui dan memproduksi hasil percobaan yang mencukupi penerimaan yang digambarkan kriteia yang akan mengakibatkan penerimaan terhadap sistem perangkat lunak

Disimpulkan Menguji Penerimaan dan setelah Test Laporan telah tertulis, Tinjauan ulang Penerimaan perangkat lunak (Software Acceptance Review ( SAR)) dipegang. Pada tinjauan ulang ini produk perangkat lunak, kode, dokumen, dan hasil percobaan ditinjau. Jika semua materi adalah memuaskan dan sesuai penerimaan yang merencanakan tercakup di Test perencanaannya, perangkat lunak diterima. Kebutuhan SAR diuraikan bagian 8.3.3.
Dokumentasi akhir harus direncanakan untuk penyerahan setelah pelaksanaan sukses dari semua Test Penerimaan sedemikian rupa sehingga koreksi yang diharuskan oleh kesalahan yang terdeteksi akhirnya di dalam program test yang formal dapat dimasukkan.

Alternatif adalah untuk menyampaikan dokumen itu yang lebih awal dan mempunyai biaya dan tidak menyenangkan untuk mengeluarkan lembaran kesalahan yang tertulis atau halaman perubahan. Pendekatan yang belakangan tidaklah direkomendasikan. Oleh karena itu, pada waktu penerimaan, yang akhir itu "asbuilt" Dokumen Disain Rinci yang harus disiapkan dan Dokumen instruksi beroperasi harus diselesaikan. Dengan penyerahan masing-masing perangkat lunak, suatu Uraian Versi Dokumen adalah juga diperlukan.

8.1.4 Pengendalian Tes (Test Control)
Pengujian Unit Program dilakukan dan dikendalikan oleh programmer siapa yang menerapkan unit itu. Sebelum persandian unit, programmer perlu mepelajari Uraian Dokumen Disain Rinci unit program dan siapkan rencana test informal dan memeriksa prosedur. Ini disatukan pada Folder Pengembangan Unit. Sekali ketika unit lewat Menguji Unit Program, itu disampaikan kepada Perpustakaan Program Komputer. Unit kemudian adalah mengintegrasikan ke dalam sistem, dan Pengujian Pengintegrasian modul dilakukan oleh kelompok pengembangan, yang dibantu oleh QA organisasi. Bila ada permasalahan yang ditemukan, mereka didokumentasikan pada suatu Laporan Masalah Perangkat lunak (Software Problem Report ( SPR)) Format ( lihat bab 9) dan unit itu dikembalikan ke programmer untuk dimodifikasi dan unit program yang berikutnya diuji kembali.

Jika Pengujian Pengintegrasian Modul untuk suatu program yang membongkar suatu masalah di dalam program yang telah duji , program ini harus dipindahkan dari tempat alas test ( koleksi dari modul perangkat lunak yang diuji) dan dikembalikan ke programmer itu untuk dimodifikasi dan diuji. Masalahmya tergantung pada kesungguhan hati, semua dari bagian dari Pengujian Pengintegrasian Modul harus diulangi yang melibatkan program yang salah/cacat itu. Keputusan dari apa yang telah ditest perlu untuk pengulangan adalah dibuat oleh organisasi pengembangan software. Sekali melengkapi program;menyudahi Pengujian Pengintegrasian Modul itu yang menjadi bagian dari dasar test sistem yang dan digunakan sebagai bagian dari bingkai yang bekerja untuk menguji lain program.
Ketika keseluruhan sub system perangkat lunak telah lulus lewat Pengujian Pengintegrasian Modul, Pengujian Verifikasi dilakukan. Pemakai harus dilibatkan sedapat sebanyak mungkin di dalam Uji Verifikasi agar supaya menjadi terbiasa dengan operasi perangkat lunak. Organisasi Penjamin kualitas melaksanakan Pengujian Verifikasi. Bila ada permasalahan yang terbongkar / terbuka, mereka mendokumentasikan adalah suatu Laporan Masalah Perangkat lunak ( lihat bab 10), dan programnya salah/cacat terisolasi dan dikembalikan ke para programmer itu. Program harus ditetapkan;perbaiki dan diuji kembali menurut prosedur itu seperti yang ditetapkan di atas. Verifikasi yang gagal test kemudian adalah diulangi sampai masalahnya terpecahkan.
Itu adalah tanggung jawab penjamin kualitas yang perorangan untuk memutuskan penyelesaian Verifikasi Test yang perlu untuk diulangi untuk tidak memastikan bahwa apapun efek samping adalah disebabkan oleh perubahan perangkat lunak yang dibuat untuk memecahkan permasalahan yang dikenali itu. Perangkat lunak harus dirancang untuk yang memerlukan saling ketergantungan minimal antara modul, sedemikian rupa sehingga perubahan satu modul tidak akan mempengaruhi lain modul. Ini akan mengijinkan pengujian untuk dilanjutkan ke area yang tidak bertalian dengan perangkat lunak yang sedang ada permasalahan ditetapkan diperbaiki. Pengujian Penerimaan diselenggarakan oleh organisasi penjamin kualitas dan pemakai di dalam lingkungan yang operasional itu. Bila ada permasalahan yang ditemukan, pemakai mempunyai hak untuk meminta bahwa keseluruhan Prosedur Test Penerimaan dimulai kembali ( kecuali jika lain prosedur yang telah ditetapkan pada Rencana Test).
Pengendalian Proses Pengujian oleh dokumentasi test yang berikut:

1. Rencana Test Unit Program informal dan Meriksa prosedur Folder Pengembangan Unit dan
2. Rencana Test formal dan Prosedur untuk Pengujian Pengintegrasian Modul, Pengujian Verifikasi, dan Pengujian Penerimaan.

Itu adalah tanggung jawab organisasi penjamin kualitas untuk memastikan bahwa semua pengujian adalah sesuai dengan dokumen ini dan bahwa semua hasil didokumentasikan. Pengendalian konfigurasi yang menempatkan pada dokumen ini diuraikan bab 9.


8.2 PROSES TEST DOKUMENTASI (TEST PROCESS DOCUMENTATION)

Tujuan aktivitas perencanaan test adalah bermakna untuk menetapkan untuk secara formal yang mempertunjukkan bahwa perangkat lunak komputer untuk dikirimkan membuat kepuasan kebutuhan yang susuai kontrak dan kinerjanya menurut Spesifikasi Persyaratan Piranti lunak yang telah disetujui.
Produk aktivitas perencanaan test adalah dokumentasi test. Dokumentasi Test formal yang diperlukan terdiri dari suatu Rencana Test, Menguji Prosedur Documen, dan Menguji Laporan. gambar 9.4 menyediakan suatu ringkasan parameter yang berhubungan dengan dokumentasi test yang formal.
Tujuan Rencana Test adalah untuk menetapkan kebutuhan terperinci, ukuran-ukuran, metoda umum, tanggung-jawab, dan perencanaan menyeluruh untuk mengkonfirmasikan bahwa "sebab yang dibangun" sistem memenuhi kebutuhan yang ditetapkan Spesifikasi Persyaratan Piranti lunak. Itu menggambarkan aktivitas test itu untuk dilakukan oleh pengembang piranti lunak untuk mencapai penerimaan piranti lunak oleh pemakai. Tujuan Prosedur Test adalah untuk menggambarkan secara detil prosedur yang nyata untuk dipekerjakan untuk melaksanakan test itu yang menggambarkan Test itu direncanakan. Dokumen Laporan Test hasil proses pengujian dan digunakan untuk secara formal untuk meyakinkan pemakai bahwa sistem yang beroperasi seperti yang ditetapkan.
Muatan yang terperinci dari tiap dokumen ini adalah mungkin ditemukan Catatan tambahan B.

8.2.1 Rencana Tes (Test Plan).
Rencana Test menguraikan program test piranti lunak yang lengkap. Itu menggambarkan pengujian pengembangan apa yang akan dilakukan oleh programmer, Pengintegrasian Modul apa, Verifikasi, dan Test Penerimaan akan dieksekusi, dan kondisi-kondisi di bawah masing-masing unsur-unsur program test yang mana akan terpenuhi.

Rencana Test yang menggambarkan bentuk wujud test itu, menguji jadual, dan test mengukur, mengidentifikasi peralatan test diperlukan suatu test piranti lunak, menggambarkan peran berbagai organisasi di dalam memproses test, menggambarkan pengendalian konfigurasi itu untuk diterapkan pada tingkatan masing-masing pengujian, dan mengidentifikasi kasus test untuk dieksekusi pada tingkatan test masing-masing. Uraian yang terperinci kasus test disiapkan dalam bentuk Prosedur Test itu. Yang secara rinci, Rencana Test menguraikan:

1. Tanggung-Jawab yang organisatoris untuk berbagai tugas di dalam program test.
2. Metoda untuk dipekerjakan untuk meninjau ulang rencana test dan prosedur, monitor dan pengendalian pelaksanaan test, laporan dan mengoreksi pertentangan test, melaporkan hasil percobaan, dan menentukan kesiap-siagaan untuk penerimaan.
3. Tujuan Dan Konsep yang tertinggi untuk pengembangan dan Pengujian Penerimaan dan strategi untuk memenuhi tujuan ini, mencakup suatu uraian test mengukur dan filosofi pengembangan.
4. Generator Data, menguji pengarah, simulator lingkungan dan program analisa test memerlukan untuk masing-masing tingkatan yang diuji. (Catatan : Seluruh pengujian piranti lunak harus dibuktikan dan di bawah konfigurasi pengendalian sebelum penggunaannya untuk verifikasi formal.)
5. Konsep Dan Metoda menekankan piranti lunak ( e.g., dengan sibuk dan jika tidak ada data masukan tidak sempurna, atau dengan data puncak yang mengisi) selama tingkatan pengujian masing-masing.
6. Jadual Test, Yang menyediakan suatu uraian yang terperinci urutan dari semua aktivitas test. Jadual Test harus dibentuk mapan untuk memastikan bahwa pengujian yang diperlukan akan diselesaikan di dalam periode waktu yang dibagikan. Jadual Test harus kompatibel dengan:
   (a) Ketersediaan fasilitas komputer.
   (b) Ketersediaan piranti lunak untuk diuji
   (c) Ketersediaan pendukung piranti lunak test
   (d) Ketersediaan intefacing piranti lunak dan perangkat keras
   (e) Ketersediaan dari peralatan test khusus
   (f) Keseluruhan proyek menguji jadual
7. Lingkungan Test, mencakup bentuk wujud perangkat keras, menguji konfigurasi piranti lunak, dan memerlukan pembuktian unsur-unsur piranti lunak baru. Lingkungan Test harus dibentuk mapan sebagai bagian dari proses perencanaan test di depan kasus test dapat digambarkan. Diagram blok, mempertunjukkan kemajuan pengujian konfigurasi, yang harus disiapkan untuk masing-masing tingkatan pengujian.
8. Test yang individu untuk dilakukan untuk mempertunjukkan pemenuhan dengan kebutuhan. Uraian dari tiap kasus test meliputi kebutuhan itu untuk dibuktikan,konfigurasi test untuk digunakan, dan piranti lunak test yang diperlukan. Prosedur Test akan disiapkan yang kemudiannya untuk masing-masing mengenali kasus test.
9. Suatu subset kasus test yang menggambarkan Test direncanakan. Test ini harus dikenali seperti Kasus Test Penerimaan untuk menyediakan tujuan penerimaan piranti lunak. Kasus ini harus disetujui dengan pelanggan ketika Rencana Test Penerimaan.

Sebagai contoh table untuk Perencanaan Pengujian/Test adalah disediakan pada gambar 8.5.

8.2.2 Prosedur Pengujian (Test Procedures)

Test Dokumen Prosedur dikembangkan untuk menguraikan Pengintegrasian Modul itu, Verifikasi, dan Prosedur Test Penerimaan. Prosedur ini mungkin adalah dikombinasikan ke dalam satu dokumen untuk program komputer kecil, satu dokumen untuk prosedur pada masing-masing menguji tingkatan, atau, karena sistem besar, volume tambahan terpisah.
Karena masing-masing kasus test mengenali Test yang direncanakan, Prosedur Test menggambarkan bentuk wujud test itu, test yang dilakukan, dan hasil percobaan. Bentuk wujud Test menetapkan material test yang spesifik, masukan data, test rutin, dan konfigurasi perangkat keras. Test yang dilakukan itu menguraikan secara bertahap berurutan diikuti untuk melakukan penyelenggaraan test, bagaimana dan kapan menguji data yang diharapkan untuk masuk, dan mengharapkan hasil. Hasil yang diharapkan meliputi toleransi yang bisa diterima dan suatu pendukung diskusi bagaimana hasil ini menunjukkan bahwa sasaran test telah dicukupi. Di mana jika informasi tambahan bisa dilaksanakan pada pilihan program dan yang diperkirakan waktu dijalankan harus dikenali. Suatu tabel contoh isi Dokumen Prosedur Test ditunjukkan pada gambar 8.6.

Di mana seperti Rencana Test yang memberi suatu ikhtisar program test, Dokumen Prosedur Test memberinya secara bertahap prosedur yang terperinci yang diperlukan untuk menguji perangkat lunak itu. Karena sejak Rencana Test dikirimkan format akhir pada CDR, itu tidak bisa meliputi suatu uraian yang terperinci dari semua pemakai yang memerlukan hubungan. Prosedur Test berisi acuan kepada Test yang direncanakan, di mana jika sesuai, untuk menghindari duplikasi informasi. Mereka mempunyai banyak dari bagian yang sama sebagai Rencana Test, tetapi berisi yang lebih detil tentang kenyataan perancangan test itu.
Karena merampas perkerjaan mengikuti jalan dan dokumen itu menguji proses, masing-masing tingkatan test dapat dipecah ke dalam tahap test. Di dalam Pengujian Pengintegrasian Modul, tahap test ini menghadirkan peristiwal fungsional yang utama di dalam proses pengembangan. Di dalam Verifikasi Dan Pengujian Penerimaan, tahap ini menghadirkan peristiwa yang utama utama di dalam menguji proses itu. Tahap yang dapat digambarkan oleh modul yang diselesaikan atau oleh peristiwa fungsional di dalam satu subsistem ketika suatu kemampuan yang bisa menguji baru ditambahkan kepada subsistem itu. Test bertahap harus yang cukup kecil untuk pengujian terpenuhi dua sampai empat jam.


ISI : DOKUMEN RENCANA PENGUJIAN

Bagian 1 Pengenalan
1.1 Lingkup
1.2 Maksud
1.3 Ringkasan

Bagian 2 Dokumen Keterkaitan
1.1 Referensi yang dapat diterapkan
1.2 Dokumen Pengembangan

Bagian 3 Konsep Pengujian
1.1 Filosofi Pengujian
1.2 Verifikasi Metode
1.3 Tingkatan Pengujian
1.3.1 Unit Pengujian Program
1.3.2 Pengujian Integrasi Modul
1.3.3 Verifikasi Pengujian
1.3.4 Penerimaan Pengujian

1.4 Peraturan Organisasi
1.4.1 Pengembangan Piranti Lunak
1.4.2 Penjamin Produk
1.4.3 Pengendalian Produk
1.4.4 Verifikasi dan Sertifikasi
1.4.5 Integrasi dan Pengujian
1.4.6 Human Engineering

1.5 Pengendalian Pengujian
1.5.1 Penjamin Kualitas
1.5.2 Memonitor Pengujian
1.5.3 Pengendalian Konfigurasi Pengujian

Bagian 4 Verifikasi Persyaratan dan Kriteria
4.1 Pengujian ke I
1.1.1 Deskripsi Pengujian
1.1.2 Pelaksanaan Pengujian
1.1.3 Hasil yang diharapkan
…….
4.n Pengujian n
4.n.1 Deskripsi Pengujian
4.n.2 Pengujian Masukan
4.n.3 Pelaksanaan Pengujian
4.n.4 Hasil yang diharapkan

Bagian 5 Persyaratan dan Ringkasan Tahap Pengujian

Bagian 6 Pengujian Integrasi Modul
1.1 Pengenalan
1.2 Lokasi dan Jadual
1.3 Pembatasan dan Komentar Umum
1.4 Persipan Masukan
1.5 Pengujian Dilakukan
1.6 Hasil Analisis
1.7 Pengujian Lingkungan
1.8 Persyaratan Personil

Bagian 7 Verifikasi Pengujian
1.1 Pengenalan
1.2 Lokasi dan Jadual
1.3 Pembatasan dan Komentar Umum
1.4 Persipan Masukan
1.5 Pengujian Dilakukan
1.6 Hasil Analisis
1.7 Pengujian Lingkungan
1.8 Persyaratan Personil

Bagian 8 Penerimaan Pengujian
8.1 Pengenalan
8.2 Lokasi dan Jadual
8.3 Pembatasan dan Komentar Umum
8.4 Persipan Masukan
8.5 Pengujian Dilakukan
8.6 Hasil Analisis
8.7 Pengujian Lingkungan
8.8 Persyaratan Personil

Bagian 9 Pengendalian dan Prosedur Pelaporan
9.1 Pengendalian Pengujian Program
9.2 Dokumentasi Prosedur PengujianDokumentasi Laporan Pengujian

8.2.3 Laporan Pengujian (Test Reports)
Dokumen Laporan Test hasil untuk masing-masing tahap pengujian kasus yang menggambarkan Rencana Test dan yang diuraikan secara detil di dalam Prosedur Test. Hasil percobaan untuk masing-masing kasus test diuraikan dengan suatu ringkasan permasalahan yang ditemukan, SPRs menulis lagi test, yang disposisi SPRs, dan disposisi keluaran test yang berhasil pada pelaksanaan yang terakhir. Juga dimasukkan adalah yang manapun direkomendasikan perubahan pada dokumentasi yang sebelumnya, yang mencakup halaman perubahan dan permintaan surat pelepasan tuntutan. Suatu daftar isi contoh untuk Dokumen Laporan Test disiapkan dalam bentuk gambar 8.7.


8.3 TEST TINJAUAN ULANG (TEST REVIEWS)

Tiga jenis tinjauan ulang diadakan untuk pendukung pengujian:

1. Rancangan Kritis Dan persiapan tinjauan ulang untuk meninjau ulang rancangan dan Perencanaan Test,
2. Menguji Tinjauan ulang (Prosedur Test Procedures Review (TPR)), yang sebelum ditangani pengujian formal (mungkin adalah dtangani kenaikannya), dan
3. Tinjauan ulang Penerimaan Piranti lunak (SAR)

ISI : DOKUMEN PROSEDUR PENGUJIAN

Bagian 1 Pengenalan
1.1 Maksud
1.2 Lingkup
1.3 Ringkasan

Bagian 2 Dokumen Keterkaitan
1.1 Referensi yang dapat diterapkan
1.2 Dokumen Pengembangan

Bagian 3 Pengujian Obyektiv

Bagian 4 Orang yan Bertanggung Jawab

Bagian 5 Perlengkapan dan Persyaratan program Komputer

Bagian 6 Prosedur Operasi Pengujian
6.1 Inisiatif Sistem Operasi
6.2 Pemeliharaan Sistem Operasi
6.3 Mengakhiri dan Mengulang Sistem Operasi

Bagian 7 Prosedur Rinci Pengujian : Pengujian Integrasi Modul
3. Pengujian ke I
4. Deskripsi Modul
5. Pengujian Masukan
6. Pengujian Dilakukan
7. Hasil yang diharapkan
…..
7.n Pengujian ke n
7.n.1 Deskripsi Modul
7.n.2 Pengujian Masukan
7.n.3 Pengujian Dilakukan
7.n.4 Hasil yang diharapkan

Bagian 8 Penerimaan Pengujian
8.1 Pengujian ke I
8.2 Deskripsi Modul
8.3 Pengujian Masukan
8.4 Pengujian Dilakukan
8.5 Hasil yang diharapkan
…..
8.n Pengujian ke n
8.n.1 Deskripsi Modul
8.n.2 Pengujian Masukan
8.n.3 Pengujian Dilakukan
8.n.4 Hasil yang diharapkan

Bagian 9 Pengendalian dan Prosedur Pelaporan
9.1 Pengujian ke I
9.2 Deskripsi Modul
9.3 Pengujian Masukan
9.4 Pengujian Dilakukan
9.5 Hasil yang diharapkan
…..
9.n Pengujian ke n
9.n.1 Deskripsi Modul
9.n.2 Pengujian Masukan
9.n.3 Pengujian Dilakukan
9.n.4 Hasil yang diharapkan

Bagian 10 Analisis dan Reduksi Data
10.1 Mencatat dan Persyaratan Reduksi
10.2 Reduksi Data dan Prosedur Analisis

Appendix A Akronim dan Singkatan
Appendix B Definisi dan Nomenklatur

Gambar 8.6 Contoh table isi untuk Dokumen Prosedur Pengujian


ISI : DOKUMEN PELAPORAN

Bagian 1 Pengenalan
1.1 Maksud
1.2 Lingkup
1.3 Ringkasan

Bagian 2 Dokumen Keterkaitan
2.1 Referensi yang dapat diterapkan
2.2 Dokumen Pengembangan

Bagian 3 Pengujian Obyektiv dan Hasil

Bagian 4 Laporan Pengujian : Pengujian Integrasi Modul
1.1 Pengujian ke I
……
4.n Pengujian ke n

Bagian 5 Perlengkapan dan Persyaratan program Komputer
5.1 Pengujian ke I
…..
5.n Pengujian ke n

Bagian 6 Prosedur Operasi Pengujian
6.1 Pengujian ke I
…..
6.n Pengujian ke n

Bagian 7 Prosedur Rinci Pengujian : Pengujian Integrasi Modul
7.1 Revisi Dokumen
7.2 Pengujian Tambahan
7.3 Permintaan Surat Pelepasan tuntutan

Bagian 8 Attachment untuk Laporan Pengujian

Appendix A Akronim dan Singkatan
Appendix B Definisi dan Nomenklatur
Appendix C Data Pendukung

Gambar 8.7 Contoh table isi untuk Dokumen Prosedur Pengujian

Yang ditangani Setelah Pengujian Penerimaan dengan sukses diselesaikan dan semua diperlukan dokumentasi yang telah disiapkan atau diperbaharui kepada" as-built" bentuk wujud. Organisasi penjamin kualitas menghadiri semua tinjauan ulang untuk memastikan bahwa program penjamin kualitas diterapkan. Isi, Format, dan yang diharapkan hasil dari tinjauan ulang ini dibahas pada subseksi yang berikut ini.

8.3.1 Disain Kritis Dan Persiapan Tinjauan Ulang (Preliminary and Critical Design Reviews)

Format rencana test ditinjau dalam persiapan Disain Kritis dan persiapan tinjauan ulang (Preliminary Design Review ( PDR)) dan di dalam format terakhir Tinjauan ulang Disain Kritis (Critical Design Reviews (CDR)). Tujuan Tinjauan ulang Rencana Test adalah untuk memastikan bahwa semua corak disain penting akan diuji dan bahwa semua kebutuhan spesifikasi akan dibuktikan. Filosofi Program Test memperkenalkan Rencana Test yang telah dipersiapkan ditinjau secara detil di PDR itu. Detil test yang nyata adalah di dalam Rencana Test yang akhirnya peninjauan pada CDR.

8.3.2 Menguji Tinjauan ulang Prosedur (Test Procedures Review)
Prosedur Test Perangkat lunak ditinjau pada Tinjauan ulang Prosedur Test untuk memastikan bahwa pengujian cukup akan dilakukan pada komponen masing-masing. Tinjauan ulang ini menyediakan persetujuan formal untuk prosedur untuk digunakan di dalam menguji dan memastikan bahwa mereka menyelesaikan tujuan Test yang telah direncanakan.
Dua rangkaian Tinjauan ulang Prosedur Test diselenggarakan: Prosedur Test Pengembangan Tinjauan ulang. Ini harus diselenggarakan secara terpisah. Tinjauan ulang Prosedur Test Pengembangan diselenggarakan sebelum Pengujian Pengintegrasian Modul dan tinjauan ulang prosedur itu untuk diikuti Sistem Pengintegrasian Modul. Tinjauan ulang Prosedur Test Pengesahan diselenggarakan sebelum Pengujian Verifikasi untuk meninjau ulang prosedur untuk diikuti Verifikasi Dan Pengujian Penerimaan. Test Pengembangan diselenggarakan untuk memastikan bahwa program komputer yang diselesaikan yang membuat kepuasan kebutuhan tercapai yang dinyatakan nya. Seperti itu, test pengembangan mengevaluasi program komputer itu lagi kebutuhan di dalam Spesifikasi Kebutuhan Perangkat lunak. Materi untuk diuji mengevaluasi prosedur test ini seperti daftar di bawah ini:

1. Uji Procedures/Plan Kecocokan. Prosedur harus konsisten dengan Test Rencanakan dan meliput semua area test diperlukan.
2. Menguji Masukan. Test Masukan harus digambarkan; masukan menggambarkan untuk test melakukan harus mampu untuk menguji disain pada batas nya.
3. Menguji Kelengkapan. Test yang didokumentasikan [perlu] mencukupi semua sasaran hasil test. Semua aspek/pengarah [yang] penting perangkat lunak disain harus dicoba-coba pengujian dan harus didokumentasikan.
4. Meriksa prosedur Kejelasan. Operator Instruksi harus dinyatakan dengan jelas, dengan singkat, dan secara terang.
5. Kofigurasi Piranti lunak. Bentuk wujud piranti lunak untuk diuji harus dengan teliti dan secara menyeluruh uraikan.
6. Ukuran-Ukuran Sukses. Sukses Ukuran-Ukuran harus digambarkan untuk masing-masing langkah pada setiap prosedur test; mereka harus konsisten dengan sasaran hasil ia perjanjian
7. Konfigurasi Perangkat keras. Perangkat keras Test Bentuk wujud harus cukup untuk melakukan test dan menggambarkan dalam detail yang jelas untuk mengevaluasi ketercukupan nya.
8. Menguji Konfigurasi Piranti lunak. Piranti lunak Test yang diperlukan konfigurasi harus cukup digambarkan. Pemenuhan perlu meliputi susunan test, masukan data, sekeliling, display, ukuran-ukuran sampling data, tingkat data rate, dan seterusnya.

8.3.3 Penerimaan Tinjauan Ulang Piranti lunak (Software Acceptance Review)

Tinjauan ulang Penerimaan Piranti lunak adalah suatu pertemuan formal diadakan untuk audit produk piranti lunak sebelum diterima pemakai. Penyelesaian dari audit ini menandakan bahwa perangkat lunak adalah siap untuk dioperasikan dan tahap pengembangan itu adalah lengkap. Tinjauan ulang yang secara normal terdiri dari dua audit: suatu Audit Konfigurasi Fungsional (Functional Configuration Audit (FCA)) dan suatu Audit Konfigurasi Phisik (Physical Configuration Audit (PCA)). Audit ini mungkin adalah diselenggarakan incrementally sebagai informasi yang perlu menjadi tersedia. Jika mereka diselenggarakan incrementally, kebanyakan materi tinjauan ulang akan merupakan suatu perihal merekam pada ketika pertemuan yang formal itu. SAR akan kemudian berisi sebagian besar menguji arsip untuk memastikan bahwa semua audit materi telah diselesaikan.

Audit Konfigurasi Fungsional (Functional Configuration Audit (FCA))
Sasaran FCA adalah untuk memverifikasi bahwa capaian piranti lunak mematuhi persyaratan capaian spesifikasi perangkat lunak itu. Ini adalah terpenuhi dengan tinjauan ulang data test itu yang mengumpulkan pengujian piranti lunak. Masing-Masing konfigurasi piranti lunak untuk disampaikan mungkin adalah tunduk kepada suatu FCA. Audit perlu menentukan yang berikut:

1. Kelengkapan Verifikasi. FCA perlu meliputi suatu audit test merencanakan, memeriksa prosedur, dan menghasilkan untuk mengkonfirmasikan bahwa data test dan hasilnya mematuhi rencana test itu dan memeriksa prosedur. Jika defisiensi dicatat, mengulangi test atau pengujian tambahan harus direkomendasikan. Di mana jika ada penyelesaian kebutuhan verifikasi parsial, status harus dibentuk mapan dan rencana untuk penyelesaian harus diperkenalkan
2. Kebenaran Simulasi. FCA perlu mengkonfirmasikan simulasi antarmuka perangkat keras dan piranti lunak itu menggunakan melakukan test telah disahihkan.
3. Kebenaran Penelitian. Di mana jika analisa telah digunakan sebagai suatu pengganti untuk menguji, metoda analisa dan hasilnya harus disahihkan.
4. Kebenaran Konfigurasi. fungsional Dan Memerinci Dokumen Disain dan Uraian dokumen Versi akan ditinjau untuk memastikan bahwa konfigurasi piranti lunak yang mengaudit adalah sama ketika itu dibuktikan.
5. Status Disain Perubahan. Semua perubahan, seperti ketika didokumentasikan oleh Laporan Masalah Piranti lunak, harus ditinjau untuk memastikan bahwa mereka telah disatukan dan dibuktikan.

Audit Konfigurasi Phisik (Physical Configuration Audit (PCA))
PCA diselenggarakan sebelum penyerahan item. Itu terdiri dari dari suatu pengujian dokumentasi disain yang terperinci melawan terhadap "as-built" konfigurasi perangkat lunak. Itu diselenggarakan untuk memastikan ketercukupan, kelengkapan, dan ketelitian dokumentasi disain yang teknis. Tinjauan ulang juga meliputi suatu audit status perubahan yang sekarang, perubahan arsip, dan arsip uraian versi untuk memastikan bahwa "as-built" konfigurasi adalah kompatibel dengan dokumen yang dilepaskan. Tim PCA perlu meninjau ulang itemnya seperti yang diuraikan di bawah. Dan Dokumen yang perlu Arsip harus disajikan oleh organisasi pengembangan piranti lunak.

1. Dokumentasi Rancangan. Suatu audit disain dokumentasi harus dilakukan untuk memastikan bahwa mereka persisnya itu menghadirkan untuk dikirimkan konfigurasi. Dokumentasi Disain terdiri dari Disain Yang fungsional, Menghubungkan pengendalian, dan Dokumen Disain Rinci. Pengujian dokumen perlu memastikan yang berikut: korelasi modul mengalir ke tingkat yang tertinggi, masukan sesuai ke aliran, dan korelasi data alat penghubung ke ICDs. Pengujian perlu juga memastikan definisi data base yang cukup karakteritiknya, ketentuan alokasi penyimpanan, pemilihan waktu dan karakteristik peruntukan, dan yang perlu cross-checking mengalir ke listing program computer.
2. Dokumentasi Test. Dokumentasi Test untuk ditinjau terdiri dari Perencanaan Test, Prosedur Test. Dan Laporan perubahan Test. untuk Menguji Prosedur yang membuat pengujian harus ditinjau untuk menentukan kebenaran test yang dilakukan menggunakan prosedur yang berkembang itu. Test Data harus diuji untuk meyakinkan bahwa semua data yang di test diperlukan hadir dan yang bersertifikat oleh organisasi penjamin kualitas. Perencanaan Test ditinjau untuk memastikan bahwa semua perubahan disetujui untuk Test Perencana telah dicerminkan Prosedur Test.
3. Uraian Dokumen Versi. Uraian Dokumen Versi harus teraudit untuk memastikan kelengkapan uraian versi yang dikirimkan itu. Suatu daftar lengkap dokumen, angka-angka versi, dan subroutine identifiers memerlukan untuk membangun versi program komputer itu harus dimasukkan
4. Dokumen Instruksi Operasi. Dokumen Instruksi operasi harus bersertifikat untuk penggunaan operasional.
5. Pendukung Dokumentasi. Semua pendukung bisa menyampaikan/kirim dokumentasi harus ditinjau untuk memastikan kelengkapan mereka.
6. Perubahan Status. Daftar semua perubahan disain yang menyatukan dengan program komputer itu karena sejak start menguji harus ditinjau untuk memastikan kelengkapannya.
7. Konfigurasi Materi. Konfigurasi Paket Item harus ditinjau untuk menjamin bahwa semua tape, kartu, dokumen, daftar, dan seterusnya hadir dan memberi label dengan identifikasi dan tanda-tanda yang diperlukan.

8.4 PENGUJIAN PROSES DAFTAR (TESTING PROCESS CHECKLIST)
Daftar nama yang berikut menyediakan suatu ringkasan mengenai pokok-pokok informasi yang harus tersedia dokumentasi test. Informasi ini memastikan bahwa perangkat lunak yang terakhir ditemukan kebutuhan itu yang menyatakan Spesifikasi Persyaratan Piranti lunak dan disain yang diuraikan Dokumen Persyaratan Disain Rinci.

1. Uji filosofi dan metodologi pekerja dan mengubah test methode yang dipertimbangkan untuk mencapai penerimaan terhadap perangkat lunak itu.
2. Memerlukan Personil untuk mendukung program test itu, yang mencakup banyaknya orang-orang dan kecakapan mereka dalam kaitannya dengan pelatihan, keanggotaan organisatoris, dan pengalaman.
3. Fasilitas Komputer yang diperlukan, mencakup suatu blok diagram sebagai tempat test yang di atasnya perangkat lunak akan jadi diuji.
4. Uji perangkat lunak yang diperlukan untuk mendukung program test itu.
5. Uji jadual, mencakup penempatan, menguji konfigurasi, dan diagram arus test.
6. Korelasi dari semua perangkat lunak dan kebutuhan disain ke test individu.
7. Capaian, Alat penghubung, dan kebutuhan test atas mana rencana test didasarkan.
8. Uji rencana untuk gerbang keluar dari tiap modul perangkat lunak menulis, seperti halnya suatu test merencanakan untuk memverifikasi bahwa sistem menemukan kebutuhan sistem itu.
9. Uraian dari semua pengujian untuk dilakukan mencakup masukan, melakukan test, dan mengharapkan hasil. Hasil yang diharapkan diperlukan meliputi ukuran-ukuran penerimaan dan toleransi pengukuran itu.
10. Hasil percobaan diperoleh pada setiap perjanjian

Dokumentasi Pengujian ditinjau pada sebagian pada PDR, CDR, TPR dan SAR. Ketika meninjau ulang dokumentasi ini, tim tinjauan ulang perlu memastikan bahwa:

1. Perencana Test meliputi suatu test terintegrasi beredar dari sistem meratakan kepada test yang paling rendah mengukur.
2. Masing-Masing test memverifikasi sedikitnya satu kebutuhan dan masing-masing kebutuhan dibuktikan dalam suatu perjanjian
3. Semua test dapat terpenuhi dengan perangkat lunak test dan peralatan mengenali.
4. Test yang dilakukan adalah suatu urutan yang logis, sedemikian rupa sehingga penggunaan yang maksimum hasil awal percobaan dapat direalisir test kemudiannya.
5. Test memverifikasi kecocokan alat penghubung.
6. Tidak ada area di atas pengujian atau di bawah pengujian.
7. Semua sumber daya pendukung dikenali.
8. Tanggung-Jawab peserta test dikenali.
9. Uraian dari tiap test adalah cukup untuk test yang benar-benar dilakukan.
10. Ukuran-Ukuran untuk sukses atau kegagalan dari tiap test secara jelas dikenali.
11. Masukan Test Dan Keluaran dikenali dan terdaftar.
12. Pertimbangan cukup diberikan kepada penyimpanan data dan pengurangan data.
13. Jadual Test adalah kompatibel dengan disain yangberedar.
14. Hasil yang nyata dari tiap test didaftarkan dan dibandingkan dengan hasil yang diramalkan itu. Hasil percobaan menemukan ukuran-ukuran penerimaan itu.

Referensi

Bob Hughes and Mike Cotterell, 2002, Software Project Management, McGraw Hill, London.
Philip Bruce, Sam M. Pederson, 1982 The Software Development Project, John Wiley and Sons, New York.
Steve McConnell, 1996, Rapid Development Taming Wild Software Schedule, Microsoft Press, Washington.
Tumar, 2002, Information System Strategic, Universitas Bina Nusantara, Jakarta.

MENGELOLA PROYEK SISTEM INFORMASI DAN ATAU PIRANTI LUNAK

MENGELOLA PROYEK SISTEM INFORMASI DAN PROYEK PIRANTI LUNAK

oleh: Tumar

Evolusi manajemen proyek piranti lunak cukup lambat yang berakhir pada dua dekade yang lalu. Alasan utama untuk ini adalah kegigihan itu nampak lebih pada programming adalah bagian dari seni dan ilmu pengetahuan. Ini nampak tetap hidup diantara perusahaan, sistem teknisi proyek, dan personil manajemen serta mempunyai kontribusi kelambatan dalam pengembangan baik-definisi, baik metodologi struktur manajemen piranti lunak. Permasalahan berlangsung meskipun kemajuan baik pada teknologi piranti keras komputer, pengenalan rekayasa piranti lunak, pendefinisian pendekatan pengembangan baru, sebagaimana dekomposisi rancangan, struktur rancangan, struktur programming, hirarki defines masukan-keluaran, dan kepala programmer tim konsep manajemen.

Faktor ini yang membantu perkembangan prespektif dalam perusahaan dan manajemen proyek itu manajemen piranti lunak harus dengan berhati-hati memperkembangan dan merubah untuk melanjutkan kemajuan dalam pengembangan teknologi piranti lunak.Ya, ini kesimpulannya adalah manajemen jarang meng aplikasikan dengan cepat kemajuan elektronik menjawabnya. Mengapa proyek piranti keras berkembang, pada pertengahan luar biasa kemajuan teknologi, adalah dsiplinnya manajemen, caranya sistimatik dasarnya pada dekade yang lalu yaitu pengalaman manajemen proyek sementara proyek piranti lunak rupanya tidak dapat ???
Kontribusinya secara umum salah pengertian manajemen piranti lunak adalah banyak pandangan memperkenalkan programmer sebagai yang tak terkendalikan/terkekang kreatifnya genius, siapa yang punya kreativitas sementara proses dibuat tak berdaya oleh beberapa rekomendasi pengendalian manajemen proyek, rancangan standar, programming standar. Terpaksa puas dengan pandangan ini manajer piranti lunak, baru-baru ini seringkali mempromosikan analis atau programmer siapa yang punya pekerjaan dalam memanaj proyek sebagai koleksi seni kreativitas tindakan mereka yang independen disukai. Job Manajemen dalam proyek ini adalah untuk percobaan, bagaimanapun juga, untuk memimpin koleksi ini individu dalam keadaannya itu menunjukan juga produk mereka akan menyelesaikan tujuan proyek, adalah sanggup hingga setiap antar muka dengan yang lainnya, dalam penyelesaiannya biaya proyek dan jadual dipaksakan, dan barangkali sebagian besar perhatian, agaknya akan kembali tertutup untuk penyelesaiannya apakah pelanggan dalam pikirannya untuk piranti lunak. Khusus manajer piranti lunak baru saja tahun-tahun ini mengalami kemajuan bagaimana proyek tidak akan dimanaj, tapi punya sedikit pembukaan atau pelatihan yang digunakan efektif teknik manajemen piranti lunak.

Maksud pada bagian ini adalah untuk mengetahui latar belakang dan pengertian peryaratan untuk memanaj suksesnya proyek pengembangan piranti lunak. Metodologinya diperkenalkan yang dapat dipakai untuk seluruh proyek piranti lunak, komersial atau pemerintah sponsornya, besar atau kecil. Untuk beberapa proyek, Rencana Proyek yang baik adalah tiga halaman memorandum, persyaratan yang baik didomentasikan dalam cara yang serupa, dan rancangannya diperkenalkan dalam 30 halaman dokumen. Untuk yang lainnya, Rencana Proyek akan konsisten pada tiga jilid untuk pengalamatan yang rinci persyaratan pengembangan, konfigurasi manajemen, dan aspek pemeliharaan proyek. Untuk proyek ini, persyaratan boleh mengharuskan 100 halaman dokumen, dan rancangan rinci terdiri dari enam jilid, 3000 halaman per jilid dokumen. Salah satu perbedaan, dan di mana-mana diantara fungsi kinerjanya , produk dokumen, serta tipe persyaratan perencanaan adalah sama.Pada bagian ini didiskusikan pembuatan proyek dan gambaran antara lain kebutuhan untuk mengerjakan yang lebih baik ( banyak disukai inisialnya, variable dan tabel dimuka eksekusi blok dan kode). Sementara itu kami menggambarkan proses manajemen proyek pertanyaan berikut jawabannya. Apakah yang dikerjakan selama proyek? Bagaimana manajer akan membelanjakannya atau waktu yang diberikan berapa hari? Bagaimana manajer analis mengerjakan membuat laporan, apa saja? Akhirnya, apakah diskusi kami akan dikerjakan selamanya dan proyek selesai untuk menyediakan warisan itu benefit yang baik untuk proyek masa depan.

4.1. TITIK PERMULAAN (STARTING POINT)

Untuk setiap pengembangan proyek piranti lunak ada dua titik permulaan yaitu :

1. Satu untuk perusahaan dan
2. Satunya lagi untuk proyek.

Yang pertama adalah kebutuhan yang bisa dijadikan contoh yang kedua. Dua elemen utama itu menetapkan titik permulaan perusahaan adalah :

1. Proses keputusan proyek (dalam beberapa kasus ini adalah keputusan sampai komplit, dan proses sampai keputusan adalah benar-benar dibuat oleh pelanggan dalam memilih proposal yang dimenangkannya) dan,
2. Penyeleksian manajer proyek. Penyeleksian manajer proyek biasanya mempunyai tanggung jawab untuk kebutuhan kondisi permulaan proyek.
   

4.1.1 Titik Permulaan Perusahaan (Starting Point Company)
Proses keputusan dengan internal proyek yang meliputi banyak faktor, sebagaimana biaya versus benefit perdagangan mempertim bangkan pendekatan alternativ varian, persyaratan definisi untuk memilih pendekatan, dan menyususun keperluan yang diusahakan dan komitmen dari pendukung dan organisasi menggunakannya. Sebagian besar perusahaan-perusahan tidak bisa memungkirinya ptosedur alokasi sumber daya perusahaan untuk investigasi proyek internal bilamana kemungkinan untuk meneruskan point keputusan dan membuat komitmen pembiayaan. Komitmen pembiayaan adalah syarat utama untuk memutuskan proyek. Sumberdaya harus dialokasikan untuk persiapan untuk proses keputusan. Perusahaan akan sepenuhnya komit dengan laporan paling akhir secukupnya dengan mengerti lingkup rancangan dan kerumitan-kerumitan proyek serta harga yang diperlukan. Dalam tidakannya juga, perusahaan harus mempersiapkan untuk memperlakukan invesment sumberdaya sebagai ongkos kebutuhan untuk pendukung proses pembuatan keputusan, dan tidak sebagai pembenaran untuk diproses karena juga banyaknya “yang telah diluarkan” dalam proyek. Seperti yang ditetapkan dalam kata pengantar, maksud buku ini adalah untuk menggambarkan pada pendekatan untuk memanaj proyek piranti lunak, tidak untuk menggambarkan prosedur itu peranan penting untuk memutuskan proyek. Karena itu, yang lainnya tidak akan dibicarakan di sekitar elemen utama ini.

Demikian pula, untuk proposal yang kompetitif keputusan penawaran meliputi analisis jumlah faktornya besar, sebagaimana posisi kompetitif perusahaan sebagai dasar analisis perusahaan dan persaingan kelemahan dan, kekuatan, analisis berikutnya potensi bisnis, analisis menyamakan persyaratan sumber daya proyek untuk perusahaan sumber daya yang sudah diperhitungkan kapabel, dan analisis factor resiko proyek. Deskripsi lebih lanjut tawaran proses keputusan yang juga meninggalkan dengan publikasi yang lainnya.

Elemen kedua pada penyusunan titik permulaan perusahaan, memilih manajer proyek, membenarkan diskusinya untuk menyediakan kelengkapan analisis manajemen proyek. Pemilihan staf proyek yang baik adalah sebagian besar faktornya kritis dalam persamaan untuk suksesnya proyek sistem informasi dan piranti lunak. Pemilihan manajer proyek dapat gagasan sampai elemen eksponensial kalau tidak persamaan kuadrat. Sebuah proyek bisa mempunyai beberapa ukuran sukses dengan segolongan kecil tak berproduksinya analis atau programmer, tapi proyek tidak akan sukses dengan manajer proyek yang buruk.

Pemilihan manajer proyek adalah tugas istimewa yang sulit, sejak setiap proyek sistem informasi piranti lunak mempunyai seperangkat keunikan masalah itu cenderung pada permintaan tertentu kualifikasi manajer tidak wajib bisa proyek lain. Kualifikasi wajib untuk beberapa piranti keras atau sistem manajer proyek yang juga menggunakan untuk manajer proyek : kepemimpinan, mengerti teknik, kemampuan manajemen, kesiapan dan ketegasan, kepandaian yang beraneka ragam dan fleksibel integritas tinjauan kemasa depan

Kepemimpinan (Leadership)
Persyaratan kepemimpinan untuk berbagai posisi manajemen, tapi perhatian utama untuk manajer proyek, siapa yang harus memotivasi koleksi bermacam-macam bakat orang yang untuk sementara bekerjasama sebagai sebuah tim. Manajer pada sebuah departemen dalam organisasi fungsional boleh memanaj yang banyak atau berlainan orangnya, Tapi kebanyakan lain lingkungan yang seimbang yang lainnya karakternya homogen (e.g., grup analis dalam departemen akuntansi). Manajer proyek, pada sisi lain, harus stimulan dukungannya untuk proyek dan tim proyek untuk sementara dalam lingkungan proyek. Dia harus menyelesaikan ini dengan tim mempunyai latar belakang tidak sama dan ketrampilan yang luas, pada lingkungan bilamana perubahan yang lainnya sering dan acapkali sangat frustasi untuk anggota tim percobaan untuk rancangan pada elemen piranti lunak.

Mengerti Teknik (Technical Understanding)
Manajer proyek harus mampu untuk berkomunikasi dengan personil teknis proyek dan administrasi yang professional, sama baiknya dengan pelanggan dan manajemen tingkat atas perusahaan. Dia harus cukup genggamannya pada isu besar teknik, dan isu lainnya yang tajam teknik tingkat dua, itu dengan melihat teknik membuat keputusannya baik. Seperti banyak pada tipe proyek lainnya, isu teknologinya menonjol. Untuk manajer dengan membangkitkan atau mengevaluasi estimasi biaya, jadual, dan persyaratan staf, dia harus mempunyai pengertian permasalahan teknik dan mengetahui siapa yang menilai/mempertimbangkan isu kritis teknik, yang mana dia akan mencari advis ke ahli teknik. Dia tidak memerlukan kreativitas yang terlalu tinggi, tapi harus mampu untuk mengevaluasi produk lainnya yang kreatif, teknik membuat, biaya, dan jadual penjualan, komunikasi dengan staf teknik senior.

Kemampuan Manajemen (Management Competence)
Proyek tingkat teknologinya independen, manajer harus mengerti dasar ketrampilan manajemen dan artinya dengan suksesnya proyek. Terlalu seringkali teknisi yang sangat tinggi manajer proyek menurunkan pemeliharaan mengawasi banyak untuk prioritas rendah, hasilnya dalam teknik penyelesaiannya bagus sekali untuk sebuah proyek yang tertunda haknya untuk biaya atau berlebihnya jadual. pada seluruh proyek, baik kecil maupun besar, biaya dan jadual dimonitor adalah sama perhatiannya dengan teknik analisis. Untuk proyek yang kecil, data biaya dan jadual adalah juga yang terus terang dan visible itu sedikit memerlukan persyaratan khusus oleh manajer proyek. Untuk proyek yang besar kekomplekannya, banyak manajer harus mencurahkan waktunya untuk aktivitas manajemen nonteknik ini. Ini adalah penyebab besar mengapa banyak perusahaan memberikan sebuah chief engineer atau deputi manajer proyek untuk menyediakan waktu sepenuhnya untuk keperluan petunjuk teknis. Ini sungguh kasus, manajer proyek biasanya mempunyai sisa kemampuan teknik, tapi yang lainnya administrasi dan ketrampilan manajemen.

Kesiapan dan Ketegasan (Alertness and Decisiveness)
Manajer proyek harus mengobservasi, mengevaluasi dan tegas . Dia harus mengintegrasikan data dan mengenai terdedianya pelbagai personil proyek, termasuk staf supervisi teknik staf personil administrasi, dengan menyediakan data yang formal dan pengendalian sistem informal. Dia harus mengidentifikasi, menaksir, dan mengevaluasi data dampak proyek, berkomentar, dan kecenderungan serta memutuskan apakah beberapa kegiatan baik. Manajer proyek harus mengakui bilamana diperlukan keputusan untuk membuat, menghimpun data yang diperlukan untuk membuat keputusan, dan tidak menangguhkan keputusan yang tidak seharusnya. Tidak bergaya atau banyak membuat keputusan pada tingkat manajer proyek itu adalah yang diperhatikan, tapi prosentase membuat keputusan yang baik. Beberapa manajer akan diminta tanggung jawabnya rinci teknik keputusan hari ke hari, yang lainnya saat banyak yang akan didelegasikan ini kewenangan keputusan. Tiap metode dapat sukses , tergantung pada gaya manajer dan kecakapan tekniknya. Pendapat yang baik, dua-duanya orang dan dengan rasa hormat untuk teknisi dan keputusan manajemen, ini adalah kunci. Pendelegasian peranan penting boleh untuk diabaikan jika manajer adalah dinilai orang jelek dan pendelegasian banyak kewenangan keputusannya untuk anggota staf dengan keputusan yang jelek. Sisi lainnya, terlalu kuat kewenangan pembuat keputusan dapat gagalnya proyek ini yang ditunggu untuk manajer proyek untuk banyak membuat perincian teknik keputusan.

Kepandaian yang beraneka ragam dan Fleksibel (Versatility and Flexibility)
Perencanaan itu awalnya adalah kunci suksesnya proyek. Perencanaan yang baik dan persyaratan kecakapan manajemen untuk mengantisipasi dan mengatur pada perubahan yang tak diduga-duga itu terdapat di atas setiap proyek yang sebenarnya. Manajer proyek harus kapabel mengatur menempatkan kejadian kedalam prespektif, analisisnya dampak realistis dalam setiap aspek proyek, dan mempunyai keluwesan untuk perubahan yang dipersyaratkan. Ini tidak sedang dalam perubahan setiap waktu rencana deviasi biaya actual dari anggaran. Pembatasan ini sedang hingga proyek diperkenalkan obyektif dengan rencana yang berjalan, tapi dengan kemauan untuk menyelesaikan, bilamana persyaratan, untuk menjamin rencana itu terhadap yang mana status tindakannya adalah realistis dan akurat dasarnya untuk aktivitas manajemen.

Integritas (Integrity)
Untuk suksesnya perekrutan orang yang baik dan untuk menambah kepercayaan pelanggan manajer proyek harus mempunyai reputasi untuk kejujuran dan integritas. Dia jobnya mendorong yang lainnya dengan hasil proyek yang baik lengkap. Tipudaya, operator yang cerdas yang pertama boleh dipandang baik pada pemandangan sekilas, tapi bilamana timbul karakter permasalahan proyek manajer proyek akan terbatas pada bagian proyek. Jika kesulitan proyek disembunyikan, dampaknya akan semakin membesar bilamana jangkauan mereka terbatas bilamana mereka tidak dapat bersembunyi lama. Jika dia memutuskannya memikirkan kepentingan pelayanan dirinya sendiri, daripada kepentingan besar proyek dan perusahaan, ini akan segera kelihatan pada staf proyek. Permasalahan akhlak akan dengan cepat, menghasilkan staf yang keluar masuk.

Tinjauan kemasa depan (Foresight)
Kecakapan yang terlihat di depan, mengantisi permasalahan yang berpotensi dan jalan untuk penyelesaian, adalah perhatian untuk suksesnya proyek. Pengalaman adalah kontribusinya besar untuk tinjauan manajemen kemasa depan.

4.1.2 Titik Permulaan Proyek (Project Starting Point)

Dalam tahap definisi proyek untuk proyek internal hendaknya selekasnya, atau selama aktivitas proposal yang dipersaingkan diusahakan untuk mendapatkannya, pemilihan manajer proyek akan menerima peranan penting dalam kebutuhan titik permulaan proyek. Tugas ini antara lain termasuk :

1. Mengidentifikasi area yang beresiko tinggi dan
2. Kebutuhan biaya,
3. Jadual,
4. Perencanaan staff,
5. Pengalokasian tugas,
6. Dukungan persyaratan organisasi, dan
7. Proyek/pelanggan pendekatan antar muka.

Hasil aktivitas ini akan termasuk di dalam proposal manajemen dan Rencana Proyek. Rencana Proyek, digambarkan dalam Modul 3 definisi titik permulaan proyek. Bilamanakah memprakarsai

• mengupayakan pengembangan internal atau,
• kontrak untuk pengembangan piranti lunak atau,
• sistem untuk informasi pelanggan

Yang telah didefinisikan dalam Bab 3 yang akan didapat dalam Rencana Proyek Yang ditetapkan sebelumnya adalah sebagai berikut :

• rencana ini memberikan definisi apakah yang akan dikerjakan,
• bagaimana,
• oleh siapa,
• jadual dalam apa, dan yang mana
• manajemen dan alat pengembangan dan
• teknik yang akan digunakan

Pengawasan manajer proyek pada aktivitas pengembangan piranti lunak di dalam dasar persiapan rencana pada awal proyek dan diperbarui sebagai persyaratan. Kelengkapan manajemen ini ada beberapa orang yaitu assisten manajer proyek yang dengan suskses menyeluruhnya proyek pengembangan piranti lunak :

Ø Jadual,
Ø WBS,
Ø Dokumentasi,
Ø Tinjauan,
Ø Konfigurasi Pengawasan,
Ø Standar dan
Ø Konvensi/rapat-rapat,
Ø Organisasi fleksibel, dan
Ø Sub kontraktor

Bagian Rencana Proyek termasuk di dalam untuk setiap areal, yang menggambarkan maksud ini digunakan oleh setiap kelengkapan manajemen untuk mendukung tugas manajer proyek antara lain :

• Perencanaan,
• Analisis Laporan,
• Pemecahan Problem, dan
• Koordinasi Proyek.

Setiap kelengkapan menggambarkan dalam selekasnya bagian, kecuali untuk organisasi yang fleksibel dan sub kontraktor, yang mana didiskusikan dalam sesi 4.2 dan 4.3


4.2 ORGANISASI FLEKSIBEL

Sebelum itu mempunyai ketetapan dasar sumber untuk pengembangan piranti lunak adalah manusia, dan telah didiskusikannya filosofi dasar organisasi dalam perusahaan yang mana proyek harus beroperasi. Pengalamatan modul ini menggunakan organisasi fleksibel dalam proyek sebagai suatu pelengkapan manajemen sampai pendistribusian tanggung jawab dan personil proyek sebagai sumber dengan hasil yang baik lagi.
Dalam diskusi perkiraan biaya dan definisi Rencana Proyek, menarik perhatian untuk dimengerti yaitu :

• Tahap pengembangan,
• Lay out sekumpulan kegiatan, atau
• Langkah-langkah kejadian berlawanan dengan waktu, dan
• Perkiraan sumber syarat-syarat proyek sampai tugas selelesai.

Aktivitas ini sama merupakan pengembangan pertama yang teratur organisasi proyek yang efektiv. Untuk proyek pengembangan piranti lunak, mengenai ukuran dan keruwetan piranti lunak, prosesnya termasuk selesainya transisi pada tingkat berikutnya anarata lain :

1. Definisi Piranti Lunak (Software Definition). Identifikasi persyaratan piranti lunak dan antar muka dan definisi pendekatan rancangan sampai memenuhi syarat-syarat (Tahap Rancangan Awal).
2. Rancangan Piranti Lunak (Software Design). Perilaku analis, rancangan antar muka, kebutuhan rancangan rinci piranti lunak sampai persiapan untuk kode piranti lunak (Tahap rancangan rinci).
3. Kode dan Uji Coba (Code and Test). Seringkali menyerahkan sampai implemtasi dan validasi, termasuk kode, debug, uji coba programmer tingkat rendah dan piranti lunak formal verifikasi dan validasi (Tahap Implementasi dan Operasi).
4. Dukungan Operasi (Operational Support). Pemeliharaan piranti lunak diperlakukan dan dukungan operasi setelah piranti lunak diterima oleh pelanggan (Tahap Implementasi dan Operasi).

Tahap pengembangan piranti lunak tepat teridentifikasi adalah ringkasan dalam bab 2 dan digambarkan secara detail pada Bab 5-8. Untuk setiap tahap ini, barangkali kebutuhannya untuk struktur organisasi menyesuaikan dengan kinerja pekerja itu dalam tahap. Bagian berikutnya organisasi proyek selama didiskusikan pada tiap tahap ini.

4.2.1 Organisasi Rancangan Awal (Pleminary Design Organization)

Suatu organisasi yang khas sampai dengan sekumpulannya menyelesaikan tugas Tahap Rancangan Awal ini diperlihatkan dalam gambar 4.1. Manajer Proyek Piranti Lunak harus menegaskan persyaratan analisis antara lain :

• Identifikasi antar muka (interface) dan
• Definisi dan
• Fungsi Perencanaan Perancangan sampai
• meningkatnya kualitas piranti lunak yang dihasilkan dan probalitasnya sukses.
• Untuk proyek sistem yang besar,
• banyak inisial aktivitasnya termasuk di dalamnya mendukung persyaratan tugas analis tingkat sistem,
• tugas berikutnya oleh analis sistem atau piranti lunak.
• Untuk proyek yang kenyataannya terbukti keras sebagai aktivitas pengembangan piranti lunak,
• banyak analis sistem level aktivitasnya mendahului pembukaan proyek

Setiap aktivitas utama yang teridentifikasi pada elemen organisasi untuk Tahap Rancangan Awal dalam Gambar 4.1 adalah sebagai berikut :

1. Sub Kontrak Manajemen ( Subcontract Management). Sebuah SubKontrak fungsi manajemen akan segera diadakan setelah kebutuhan yang tidak bisa dipungkiri selesai dibuat atau beli perencanaan, Tanggung jawab utama fungsi manajemen sub kontrak adalah sampai dukungan menyeleksi subkontrak dan memberikan pengawasan dan konsumen antarmuka untuk piranti lunak dan piranti lunak dan piranti keras berhubungan subkontraktor.
2. Sistem Rekayasa Piranti Lunak (Software System Engineering). Fungsi Sistem Rekayasa Piranti Lunak adalah bertanggung jawab untuk definisi persyaratan dokumen, sistem analis, dan dasar rancangan piranti lunak. Organisasi ini mempunyai pertanggungan jawab untuk Persyaratan Spesifikasi Piranti Lunak yang dihasilkan dan Fungsi Dokumen Rancangan. Ini adalah tanggung jawab untuk perencanaan dan memimpin Tinjauan Persyaratan Piranti Lunak dan Tinjauan Rancangan Awal.
3. Jaminan Kualitas (Quality Assurance). Fungsi jaminan kualitas adalah organisai yang terbaik untuk terjaminya pengembangan dan penyerahan berdasarkan perjanjian penerimaan hasilnya. Assiten ini dengan program jadualnya, pemantauan rancangan vs persyaratan, tingkat persyaratan tingkat uji coba rencana pengembangan. Seluruh dokumen akan diaudit oleh penjamin kualitas, memerksa kembali dokumen standar dan persyaratan kontrak.
4. Produk Pengawasan (Control Product) . Fungsi Produk Pengawasan mempunyai fungsi utama pertanggungan jawab untuk mekanisme konfigurasi manajemen piranti lunak. Ini juga rencana prosedur untuk proyek Komputer Program Perpustakaan.

4.2.2 Organisasi Rancangan Rinci

Bilamana Rancangan Awal ditinjau kelengkapannya, terutama dari pergantian syarat-syaratnya dan fungsi analis sampai dengan rancangan analis serta pembuktian perencanaan. Organisasi yang khas sampai menyelesaikan sekumpulan tugasnya dengan tahap ini yang diilustrasikan dalam Gambar 4.2. Peralihan dari tipe organisasi diperlihatkan dalam Gambar 4.1 biasanya akan terjadi secara berangsur-angsur, dengan menyelesaikan pergantian dari fungsi sistem rekayasa piranti lunak sampai pada format fungsi pengembangan piranti lunak baru.
Aktivitas utama setiap elemen organisasi adalah mengedintivikasi Tahap Rancangan Rinci antara lain :

• Subkontrak Manajemen
• Sistem Rekayasa Piranti Lunak
• Jaminan Kualitas
• Pengembangan Piranti Lunak
• Control Product.

Fungsinya jaminan kualitas diperlihatkan dalam Gambar 4.3 dilakukan secara independen pemantauan kualitasnya

1. Manajemen Subkontrak. Fungsi ini tinggal sangat utama yang sama, kecuali pemilihan pemborong bawahan, yang harus diselesaikan sepanjang Tahap Disain Persiapan.
2. Rekayasa Sistem Piranti lunak. Perubahan sebagai hasil Disain persiapan Tinjauan ulang harus di gabungkan ke dalam dokumen yang telah diproduksi sepanjang Tahap Disain Persiapan. Sistem Perangkat lunak fungsi rancang-bangun melanjut monitoring disain piranti lunak dan kebutuhan, dan mengkoordinir produksi Dokumen Disain Yang terperinci bersama dengan pengembangan piranti lunak/software berfungsi. Sistem Piranti lunak fungsi rancang-bangun juga merencanakan Tinjauan ulang Disaen Kritis.
3. Penjamin Kualitas. Selama desain terperinci, fungsi jaminan menyiapkan rencana untuk semua pengujian formal diuji. Ini memerlukan monitoring pengembangan piranti lunak/software dan rancang-bangun sistem piranti lunak itu berfungsi. Itu juga memulai persiapan verifikasi program komputer dan penerimaan pengujian prosedur.
4. Pengembangan Piranti Lunak/Software. Fungsi Pengembangan software diformat untuk menyiapkan disain piranti lunak yang terperinci. Persandian informal mungkin dilaksanakan dan simulasi pengembangan untuk memperoleh pengertian yang mendalam ke dalam unsur desain. Fungsi Pengembangan piranti lunak/software menyiapkan rencana pengujian untuk semuanya dieksekusi oleh programmer pengembangan sebelum verifikasi formal pengujian. Fungsi juga mengambil bagian Tinjauan ulang Desain Kritis.
5. Pengawasan Produksi. Tanggung-Jawab fungsi pengawasan produksi sangat utama sama halnya selama Tahap Desain pendahunan bagaimanapun, jumlah aktivitas meningkat menurut perbandingan dengan kemajuan langkah-langkah program.

4.2.3 Implementasi Organisasi
Seteleh Tinjauan Rancangan Kritis, perhatian proyek berganti lagi. Pengembangan piranti lunak berfungsi kontinyu sampai pemeliharaannya, memberikan tambahan dukungan programer sampai selesainya kode dan percobaan yang ditugaskannya. Organisasi mencoba berhubungan yang menekankan pada persiapan dan untuk penyelesaian uji coba piranti lunak secara formal. Sampai menyelesaikan tugasnya yang diimplementasikan, suatu ke-khas-an organisasi termasuk di dalamnya tentang fungsi yang diilustrasikan dalam Gambar 4.3.
Setiap aktivitas utama element organisasi diidentifikasi untuk periode implementasi adalah digambarkan sebagai berikut :

1. Manajemen Subkontrak . Manajemen subkontrak berfungsi kontinyu dengan perbedaan yang relatif sedikit dari Tahap Rancangan Rinci.
2. Sistem Rekayasa Pintai Lunak. Diutamakan sampai tahap permulaan ini, seluruh spesifikasi pertama dan kelengkapan dokumen. Sistem rekayasa piranti lunak dalam perusahaan berfungsi menghasilkan Tinjauan Rancangan Kritis dan meninjau kembali spesifikasi dan dokumen yang hanya menyusun perubahan rancangan piranti lunak. Persiapan akhir persyaratan Dokumen Instruksi Operasi sampai pada dukungan penerimaan dan pemesanan piranti lunak bagian terakhir dan persiapan untuk menyelesaikan Fungsi dan Audit Konfigurasi Fisik dengan pelanggan.
3. Jaminan Kualitas. Besarnya fungsi ini bertambah terkenal selama tahap ini sampai dengan memelihara pengawasan pada pelbagai aktivitas uji coba. Fungsi jaminan kualitas adalah bertanggung jawab untuk memberikan verifikasi program komputer dan penerimaan aktivitas uji coba. Ini juga bertanggung jawab untuk kesaksian dan pelaporan kinerja uji coba oleh berfungsinya pengembangan piranti lunak dan seluruh uji coba dikerjakan oleh subkontraktor.
4. Pengembangan Piran Lunak. Tugas yang besar peng-kode-an program komputer dan pemeriksaan informal yaitu kode adalah inisial kinerja tuganya oleh fungsi ini. Pada persiapan pengembangan (unit dan tingkat modul) prosedur uji cobanya dan yang akan memimpin kinerja uji coba oleh fungsi utama pengembangan piranti lunak sampai piranti lunak ditransfer dan dukungan material hingga Program Komputer Kepustakaan. Yang berikutnya uji coba tingkat tinggi adalah didukung oleh fungsi pengembangan piranti lunak sebagai persyaratan.
5. Pengawasan Produk. Aktivitasnya kontinyu dengan bertambahnya perhatian dalam pangawasan dan status pelaporannya.

Fungsi jaminan kualitas diperlihatkan dalam Gambar 4.3 independen kualitas kinerjanya termonitor dan fungsi uji coba dalam mendukung proyek piranti lunak. Dalam gambar ini fungsinya adalah pelaporan yang diperlihatkan untuk manajer program. Fungsi ini barangkali kinerjanya oragnisasi independen dalam organisasi, perusahaan terpisah pembayarannya oleh pelanggan seperti asosiasi kontraktor untuk fungsi kinerja ini, atau oleh grup pada organisasi pelanggan. Verifikasi dan penerimaan uji coba fungsinya adalah seringkali terpisah dari kualitas tinjauan fungsi dan barangkali terpisah organisasinya, sebagaimana yang dihubungkan nama-nama pada :

• Uji Coba Formal,
• Uji Coba Sistem,
• Uji Coba Verifikasi,
• Uji Coba Independent, atau
• Verifikasi Independen dan Validasi.

Struktur organisasi organisasi setelah penerimaan piranti lunak adalah sangat tergantung pada tingkat pendidikan dan peningkatan aktivitas itu pelanggan memilih yang dimasukan sebagai bagian operasi dan aktivitas pemeliharaan. Proyek mungkin konsis pada grup programming yang kecil untuk memelihara kode, dengan dukungan dari fungsi pengendalian produk (Operasi Komputer Program Library, pengendalian konfigurasi, dan permasalahan status pelaporan). Jika peningkatan aktivitas adalah termasuk, sistem rekayasa piranti lunak yang kecil dan pengembangan piranti lunak fungsinya juga boleh diwajibkan.

4.2.4 Ringkasan Pertanggungan Jawab Organisasi
Gambar 4.4 dan 4.5 memberikan ringkasan pertanggung jawaban organisasi untuk dokumentasi dan uji coba fungsi oleh tahap pengembangan. Gambar ini adalah basis dalam suatu definisi struktur organisasi dalam Gambar 4.1, 4.2 dan 4.3. banyak variasinya dalam suatu struktur organisasi adalah memungkinkan, mempercayai dalam ketelitiannya pada suatu proyek.barangkali sebagian besar berat berlatihnya adalah suatu definisi uji coba struktur organisasi. Suatu organisasi disini mendefinisikan gambaran pengawasan programmer pada unit tingkat uji coba dan organisasi pengawasan pada modul yang uji cobanya terintegrasi, dengan memantau dan dukungan dari fungsi jaminan kualitas, pada grup yang indepeenden dalam proyek. Persyaratan uji coba sekali lagi, verifikasi uji coba, dan penerimaan uji coba adalah kinerjanya organisasi penjamin kualitas.Banyak variasi pada tema ini adalah memungkinkan. Untuk latihan, uji coba kewajiban yang telah diberikan fungsi penjamin kualitas dalam Gambar 4.3 dan Gambar 4.5 adalah dapat ditangani oleh fungsi sistem uji coba, dengan dipantau oleh penjamin kualitas. Alternativ, dalam uji coba yang independen dan grup verifikasi paling lama pengembangan proyek piranti lunak diperbolehkan syarat-syaratnya oleh kontrak atau manajer proyek. Dalam proyek yang berskala kecil, kegiatannya, fungsi penjamin kualitas independen tidak boleh dipersyaratkan, dengan kewajiban yang khas ini adalah tanggung jawab manajer proyek, dengan tambahan dukungan dari fungsi pengembangan piranti lunak.

Maksud uji coba yang independen adalah sampai diberikannya tambahan jaminan kualitas sampai berhasilnya piranti lunak. Beberapa kesalahan adalah hak subyektivitas perancang atau programer, dan uji coba yang independen adalah cara kompensasi untuk subyektivitas. Faktor hingga pertimbangan dalam pembatasan keperluan untuk uji coba yang independen termasuk di dalamnya : biaya, kuantitas kepercayaan itu akan memperoleh keuntungan, kekritisan piranti lunak sampai uji coba, ukuran pada pengembangan piranti lunak diupayakan, pada pengembang piranti lunak yang kapabel, derajatnya yang mana sampai menyatakan tidak langsung rencana uji coba adalah berterus terang (karena itu lebih lanjut bebas menginterprestasikan hasil uji coba subyektiv).

Keuntungan yang utama pada grup uji coba independen adalah :

1. Komprehensif/ meliputi banyak hal dan luas uji cobanya,
2. Subyektivitasnya dieliminir dan tetap interes dalam prosedur uji coba,
3. Kekurangan yang dikhawatiran diketahui pada implementasinya yang tidak baik, dan
4. Berpengalaman dalam kedisiplinan uji coba piranti lunak dan ini adalah sekumpulan dan verifikasi peralatan.

Yang terpenting keadaan merugikan pada pelaksanaan uji coba yang independen adalah sebagai berikut :

• Biaya secara keseluruhan besar,
• Persyaratan waktu yang panjang, dan
• Beberapa kemungkinan termasuk tak realistik atau tak relevan uji cobanya.

Secara umum keadaan merugikan pada uji coba independen jauh lebih berat dari pada keadaan merugikan bilamana menyisihkan faktor biaya. Uji coba independen selalu akan menolong jika tim uji coba adalah sungguh-sungguh independen dalam pertanggung jawabnya dan terpisah dari fungsi pengembangan sistemm informasi dan piranti lunak.
Bagaimana persoalan bukan pada uji coba dan seluruh fungsi lainnya dalam diskusi yang terdahulu adalah telah diatur alokasinya, ini adalah yang diperhatikan sampai dengan jelas digambarkan setiap fungsi dan memberikan tanggung jawab. Pemilihan organisasi harus dengan jelas definisi Rencana Proyek.


4.3 SUBKONTRAKTOR PIRANTI LUNAK

Ini adalah yang sebenarnya bukan perbedaan diantara manajemen piranti lunak dan manajemen subkontrak piranti lunak. Peraturan sama pengembangan piranti lunak akan sukses diaplikasikan sampai subkontraktor, adalah mereka yang baru saja dipergunakan sampai seluruh elemen lain proyek. Berikutnya kunci garis pedoman yang akan diikuti oleh manajer proyek siapa subkontraktornya pada beberapa pekerjaan pengembangan piranti lunak adalah sebagai berikut :

1. manajer proyek akan memberikan sebuah kontak titik tunggal sampai memanaj subkontraktor : manajer subkontrak,
2. manajer subkontrak akan menunjuk sampai setepat mungkin praktis pengembangan piranti lunak dalam subkontraktor (lihat bag.2), benar-benar manajer proyek menentukan mereka yaitu : supervisor, group leaders, assisten manajer proyek, atau paket kerja manajer proyek.
3. Subkontraktor Rencana Proyek, yang isinya sama dengan Rencana Proyek, persyaratan subkontraktor. Rencana itu akan didefinisikan dengan jelas sebagai berikut :
   a. Apa yang akan dikerjakan (persyaratan & WBS).
   b. Oleh siapa akan dikerjakan (perencanaan organisasi),
   c. Tanggal berapa (schedule)
   d. Biayanya banyak akan bagaimana (budget)

4.3.1 Pertimbangan Subkontraktur
Jenis pertimbangan berikutnya jenis perhatian yang akan dipertimbangkan bilamana penyeleksian perusahaan sebagai subkontrak piranti lunak antara lain

1. Perusahaan tertarik dan solider,
2. Skil Manajemen Perusahaan dan derajat komitmen dukungan manajemen terhadap proyek anda.
3. Reputasi perusahaan dengan pelanggan lain.
4. Pengalaman dan reputasi ketelitian individu sampai ditentukannya job anda (pertimbangan biasanya kebanyakan lebih berat daripada yang lain).
5. Pengalaman perusahaan dan prosedur formal dengan respek hingga pengembangan piranti lunak.
6. Kecakapannya didemonstrasikan sampai orang baru yang menarik hingga persyaratan perusahaan memuaskan.
7. Biaya yang efektif.

4.3.2 Seleksi Subkontraktor
Dua jalan utama yang ditempuh sampai digunakannya subkontraktor pengembang sistem informasi dan piranti lunak antara lain :

1. Konsultan dan body-shop kontraktor (tiap jam : personil subkontraktor sebagian kembali ke tim di rumah adalah dimanaj khas oleh staff proyek.
2. Kontraktor didefinisikan untuk suatu job porsinya tetap.

Belakangan menguasai satu teknik dari dua terutama yang tak menguntungkan subkontraktor : kekurangan pengawasan kinerjanya belebihan. Kedua Yang tidak menguntungkan subkontraktor masalah biaya. Sejak kontraktor yang terbaik melaksanakan administrasinya ongkos dan keuntungan sampai biaya subkontraktor, dan sejak kontraktor yang baik mensuplai personil khusus hingga memantau penunjukan subkontrak, didapat hasil bersih besarnya biaya sampai pada pelanggan. Akan tetapi besarnya biaya, barangkali, jika diimbangi :
1. Kontraktor yang baik tak dapat bekerja (kekurangan staff atau skil),
2. Subkontraktor kinerjanya dapat bekerja dan lagi sangat effisien karena berpengalaman atau lainya yaitu pangsa pasar menguntungkan, atau
3. Subkontraktor mempunyai tenaga kerja yang ongkosnya murah.

Penyeleksian subkontraktor adalah yang dapat memperhatikan tugasnya itu, dan seringkali prosesnya panjang. Gambar 4.6 ilustrasi flow aktivitas formal termasuk di dalamnya kompetitif dalam penyeleksian subkontrak atau nonkompetitif subkontrak ini tahapnya formal tidak diperoleh persyaratannya, pada chart akan ditinjau sampai diingatkan manajer proyek biasanya tahap persyaratan dalam penyeleksian subkontrakor.

4.3.3 Manajemen Subkontraktor
Waktu subkontraktor diseleksi, sub kontrak dimanaj oleh subkontraktor dengan cara yang sama itu assisten manajer proyek atau paket pekerjaan manajer dilaporkan sampai manajer proyek dalam memanaj setiap proyek yang mereka tugaskan. Manajer subkontrak akan kerja berikutnya adalah :

1. Syarat subkontraktor Struktur Pekerjaan Diuraikan dengan Rinci,
2. Syarat dalam aktivitas jaringan kerja itu ditampilkan ketergantungan kegiatan internal dan kegiatan eksternal. Ketergantungan subkontraktor pada kegiatan eksternal kembali pada tanggung jawab manajer subkontrak.
3. Subkontraktor yakin mengawasi sebagaimana mestinya pendistribusian pekerjaan sampai organisasinya mendapatkan yang selayaknya, teknik yang digunakan sunguh-sungguh sebagai suatu otorisasi pekerjaan proyek. Otorisasi Pekerjaan Proyek adalah pada kontrak yang intraorganisasi, dan definisinya sama tepatnya dengan Rencana Proyek siapakah yang mengerjakan, oleh siapa, bilamana, dan berapa banyak.
4. Menentukan syarat-syarat untuk memproduksi sebuah master schedule peristiwa penting dalam subkontrak. Schedule ini adalah diproduksi dalam hubungannya biasa dan biasanya dengan bagian subkontraktor Rencana Proyek.
5. Menentukan persyaratan subkontraktor itu yang memberikan status laporan biaya dan tinjauan dan mengerti seluruh penyimpangannya. Formatnya akan konsisten dengan perjanjian proyek komitmen laporannya.
6. Kelakuan seluruh subkontrak ditinjau, biasanya ini akan mengidentifikasi sekumpulan tinjauan dalam Bab 2 (Gambar 2,5) dan digambarkan secara rinci dalam Bagian II.
7. Mengetahui siapa personil kunci subkontraktor dan subkontraktor mengerti rencana untuk dapat dipakai sebagai pengganti.

Subkontraktor Pengembangan Piranti Lunak dapat menugaskan yang sangat produktiv jika subkontraktor adalah dengan hati-hati menyeleksinya dan dimanaj sama dengan teliti cara penugasannya dalam proyek.

4.4 PROSES MANAJEMEN

Satu atribut utama membedakan pengembangan sistem informasi dan piranti lunak dari pengembangan piranti keras adalah kekurangan hal referensi fisik untuk membantu mengukur pelaporan. Menambah permasalahan manajemen dan membuat proses manajemen banyak kekomplekan lainnya. Bagaimana memanaj waktu itu mengerjakannya bermacam proyek? Bagian sebelumnya menyediakan jawaban: perencanaan yang hati-hati, realistis harganya, efektif organisasinya, dan konstrukstif menggunakan dokumen dan tinjauan. Bagian ini mengalamatkan elemen lainnya sangat diperhatikan pada proyek pengembangan sistem informasi dan piranti lunak proses manajemen : mengerti job manajer proyek sistem informasi dan piranti lunak, manajer pelaksana proyek, manajemen personil, manajement teknisi, manajemen biaya, dan efektif digunakan mendukung pelayanan.

4.4.1 J o b
Sebagai manajer proyek, adalah bertanggung jawab untuk perencanaan proyek, staf, pelaporan analisis, pemecahan masalah dan coordination. Anda membuat keputusan pendekatan itu menentukan yang diterima tim proyek dan akhirnya menentukan proyek yang sukses. Apa keputusan anda yang diperlukan untuk mengerjakan, bilamana akan mengerjakan, dan siapa atau organisasi proyek yang mana baik kinerja tugasnya. Satu pada kebanyakan kesulitan konsep untuk manajer proyek baru untuk mengerti itu adalah tidak memutuskan bagaimana tugas yang telah terjadi.

Untuk proyek kecil, kinerja anda dari pada yang lainnya satu aturan. Barangkali anda Chief engneer atau peranan teknisi, sama baiknya dengan manajer proyek. Dalam kasus ini, anda akan sungguh-sungguh berbelit-belit bagaimana tugas yang telah terjadi dan teknisi itu menjual peranan penting untuk menyeleksi penyelesaian. Seringkali terlalu, bagaimanapun pendekatan ini adalah mengangkat keluar untuk proyek besar, bilamana manajer proyek tak dapat hasil yang baik menyediakan kedua-duanya tekninisi dan kepemimpinan administrasi. Keinginan tahu kualitas teknisi dan kinerjanya, yang mana peranan penting untuk promosi ke manajer proyek, harus surprise. Ini harus menempatkan lagi dengan yang asosiasi kualitas dengan manajemen, yang menentang dengan kinerja, tugas teknisi. Sebagaimana suatu kinerja, kualitas itu membawa perhatian dan mungkin promosi yang mempunyai pengetahuan dan spesial teknisi, ketrampilan teknisi yang dipercaya, bergairan dan keinginan tahu teknisi, dengan kecakapan bekerja walaupun dengan petunjuk yang minimum dan tugas menyelesaikan permasalahan. Ini adalah kualitas. Ini adalah kualitas anda sukai itu untuk melihat seseorang dalam proyek. Tapi sebagai manajer proyek, mereka kualitas mereka tidak luas itu baik keputusannya anda sukses atau gagal. Dalam fakta , mereka mungkin memperoleh jalan pada job anda.
Bilamana cocok menjadi manajer proyek, tujuan, dan prespektif harus dirubah :

1. Harus terfokus perhatiannya pada hasil, bukan bagaimana caranya mereka menghasilkan. Anda mengijinkan untuk membiarkan keputusan yang lainnya bagaimana bagian job dikerjakan dengan baik, terjadi lebih dulu ketrampilan teknis anda ceriterakan bagaimana mereka “ sebaiknya” untuk mengerjakannya.
2. Harus menentang godaan untuk mengerjakan banyak job bagi dirimu sendiri (belajar untuk delegasi). Anda harus memperhatikan yang lainnya harus dikerjakan job anda “tahu” akan mengerjakan makin baik dan cepat.
3. Tidak dapat lama menyandarkan diri pada yang lainnya untuk memberitahu pekerjaan selanjutnya.
4. Kebaikan tak sebanyak kesempatan yang digunakan ketrampilan teknis seperti pindah ke proyek yang besar.
5. Perhatian besar yang baik adalah masalah manajemen orang dan motivasi orang bukan masalah teknisi.

Beberapa outline ini realistis langkahnya untuk manajemen proyek. Bagaimana mengerjakan satu dari pada membuat transisi ini ? Sebagian besar oleh point kesadaran adil kedengarannya dan utilitas penunjuk garis dan ceklis disediakan oleh persahaan anda kebijakan pengendalian proyek, banyak artikel jurnal pada subyek, dan buku sebagaimana yang satu ini. Gambar 4.7 disediakan pada cek list tambahan pertimbangan untuk empat job manajer proyek piranti lunak. Manajer sangat baik yang akan mempunyai ceklis yang serupa, yang mana dapat berhubungan secara tetap, dalam laci menja tulisnya dia surat peringatan Tanggung jawab manajer proyek.
Esensi list yang disediakan dalam gambar 4.7 adalah rencana manajer proyek harus, meninjau laporan, penyelesaian masalah, dan koordinasi (peranan penting) aktivitas proyek.

4.4.2 Manajer Pelaksana Proyek

Sebagai manajer proyek untuk proyek piranti lunak atau beberapa proyek lainnya, langkah utama terhadap kesuksesan adalah belajar untuk memananj diri sendiri. Ini termasuk belajar bagaimana untuk memanaj waktu, bilamana untuk actual, bilamana rencana diulang, dan bagaimana untuk memperoleh tinjauan ke belakang proyek termasuk prespektifnya.

• Persiapan dan pemeliharaan suatu penulisan rencana petunjuk, tapi bukan kinerja, tugas teknisi
• Pendengaran untuk personil proyek
• Tersedianya untuk penyelesaian masalah
• Dengan jelas definisi tugasnya
• Menganjurkan kreatif berfikir, pendekatan, dan penyelesaian
• Pengendalian kontrak pelanggan: penahan/penyangga campur tangan
• Penyangga organisasi hal-hal yang sepele
• Seperangkat kejadian penting yang berarti
• Periksa laporan yang bertentangan dengan rencana
• Menuntut dengan tegas pada tinjauan tetap proyek dengan bos anda
• Promosi karier pengembangan dan pelatihan staf
• Menafsikan/mengartikan kontrak
• Mendesak aktivitas dengan yang disyaratkan itu berdasarkan perjanjian
• Menggunakan pertemuan, dan tinjauan yang berguna
• Menyusun standar proyek dan persyaratan kompilasi
• Sumberdaya utilitas perusahaan sebagaimana kontrak, penjamin produk, dan relasi industri.
• Tersedianya untuk kemungkinan
• Memanaj waktu yang sewajarnya efektif.
  

Gambar 4.7, Tanggung jawab Manajer Proyek Piranti Lnak

Manajemen Waktu
Bagian utama job sebagai manajer proyek adalah untuk promosi keefektipan dalam proyek yang lainnya. Ini adalah pandai oleh banyaknya waktu anda untuk orang, termasuk kesediaan untuk konsultasi pada beberapa subyek dan memelihara sentuhan dengan personil proyek pada setiap hari. Pada proyek yang besar ini adalah mudah untuk manajer proyek menjadi terpencil dari aktivitas proyek sebagai antar muka dia dengan pelanggan, subkontraktor, dan organisasi perusahaan lainnya. Sebagai suatu akibat, dia tidak punya waktu untuk memanaj atau petunjuk proyek. Untuk menghindari keterpencilan ini, manajer proyek harus mengambil langkah untuk dia memanaj waktu yang selayaknya.

Manajemen waktu adalah dengan suatu analisis waktu anda yang diminta, evaluasi yang signifikan setiap tipe persediaan, dan anda menggunakannya optimal yang disediakan. Untuk manajer proyek piranti lunak, ini mendapat kepandaian oleh tiga klas definisi aktivitas dan daripada alokasi setiap waktu yang diminta atau aktivitas untuk satu kelas ini. Tiga kelas ini adalah sebagai berikut :

1. Aktivitas Pertama
Aktivitas yang mempunyai efek signifikan pada proyek dan dapat tiada seorangpun yang didelegasikan maupun disisihkan.

2. Aktivitas Kedua
Aktivitas siapa yang efeknya proposional dengan waktu yang disyaratkan untuk mereka selesaikan. Aktivitas ini dapat dan akan didelegasikan untuk proyek besar. Untuk proyek kecil mereka akan didelegasikan untuk keperluan yang luas untuk menyelesaikan tugas utama.

3. Pekerjaan Sibuk
Yang mana aktivitasnya mempunyai efek sedikit pada proyek. Aktivitas ini seluruhnya akan didelegasikan atau disisihkan.

Manajemen yang baik waktu yang disyaratkan manajer proyek untuk petunjuk porsinya waktu besar untuk aktivitas utama, pendelegasian cukup pada aktivitas sekunder dengan menyediakan waktu untuk kelengkapan aktivitas utama, dan mengeliminir atau mendelegasikan seluruh aktivitas kerja yang sibuk. Contoh tipe aktivitas yang dialokasikan untuk setiap kelas adalah seperti yang tersedia dalam Gambar 4.8.

Ironis, satu permasalahan pada beberapa proyek engineering, sama halnya dengan manajer proyek, adalah tendesinya kuat dengan kecepatan yang berkongsi besar yang didapat waktu pekerjaan sibuk, bilamana kejadian mereka yang mengetahuinya ini adalah masalah serius untuk yang mana kebutuhan mereka akan langsung diteliti aktivitas utama dan aktivitas sekunder. Ini adalah ungkapan itu yang menggambarkan fenomena ini: “grazing on concrete.” Ungkapan datang dari analog fenomena dalam industri sapi. Bilamana sapi adalah mengakibatkan untuk pemuatan kandang dan lainnya adalah dengan mengendarai di atas ramp termasuk jalan kereta api persediaan mobil, mereka seringkali memindahkan untuk sudut paling ujung pada rumput dan kandang, kejadian yang lebih dulu ini adalah rumput. Mereka yang mengetahui ramp itu adalah permasalahan riil untuk mereka, mereka juga memilih dengan mengabaikan tanggung jawab ini yang hampir menyerupai kenyataan.

Aksi versus Reaksi
Menajemen waktu yang baik membantu untuk mereduksi tendensi manajer proyek dengan reaksi atau manajer pemadam kebakaran. Mempunyai waktu yang tersedia untuk mempelajari permasalahan dan rencana mereduksi penyelesaian ketegangan itu promosi dengan reaksi yang tergesa-gesa. Seringkali kualitas reaksi cepat dan meyakinkan untuk seluruh permasalahan, beberapa waktu dengan informasi yang cukup, kasus subordinat dengan menyembunyikan permasalah yang potensial.

Ini dapat terjadi jika mereka adalah ketakutan manajer proyek akan cepat mengambil, menentukan reaksi daripada mendengarkan dengan rencananya untuk menahan permasalahan yang berpotensi. Manajer proyek yang baik adalah harus sanggup untuk menentukan untuk perbuatan dia bilamana dengan mendukung aksi pada subordinat. Pada kasus yang belakangan, dia akan memonitor situasi, dia menentukan posisinya jika diperlukan, dan membawa sumberdaya proyek yang lainnya yang permasalahannya hanyapersyaratan. Begitu bijaksana reaksinya yang membesarkan hati secepatnya teridentifikasi permasalahan yang berpotensi. Subordinat yang baik daripada situasi begitu teridentifikasi, karena mereka itu yang mengetahui manajer proyek yang baik tidak berlebihan reaksinya dalam mempertahankan tugas yang dibawakan kecuali kalau realita permasalahan yang membenarkan aksi seperti itu. Mereka baik juga menganjurkan dengan situasi permukaan begitu secepatnyasejak mereka mengetahuinya permasalahan itu di pending baik bantuan dengan membuatnya prioritas untuk sumberdaya proyek dan waktu manajer proyek.

Yang tidak bisa dipungkirinya dirinya sendiri yang pada satu manajer beraksi siapa yang akan mengetahuinya permasalahan kecil lainnya dengan dukungan penyelesaian mereka oleh subordinat, daripada reaksinya yang cukup dengan mendadak permasalahan besar ditemukan manajer proyek harus menyaring kemampuannya untuk mempertimbangkan status permasalahan yang berpotensi. Patnya baik pada seluruh aksi/kegiatan di bawah samaran permasalahan yang ditahan terus subordinat adalah hampir sama buruknya dengan reaksi untuk setiap permasalahan sebagai satu krisis. Seorang manajer mengapa menolak untuk membuat keputusan keras yang dapat cepat alirannya dari air yang tenang memasuki aliran yang deras. Daripada dengan reaksi, mengambil pendukung aksi, atau memonitor aksi subordinat yang tergantung pada keseriusan permasalahan dan ini adalah dampak terletak pada usaha pengembangan. Manajemen waktu yang baik akan mengijinkan manajer proyek untuk mengalihkan waktu untuk mengerti permasalahan dan mengevaluasi alternatif, tanpa gangguan menghentikan proyek. Ini adalah bilamana waktu tidak untuk alasan mengevaluasi, tekanan dari area permasalahan dan yang lainnya mengganggu area penerangan yang baik sama sebuah seri yang berurutan bersentuhan melakukan pekerjaan berbahaya, berturut-turut yang lainnya serius sampai pada krisis pengembangan.

Direncanakan Ulang Kembali
Ini adalah mandatory proyek yang mempunyai rencana realistis yang mana menentang dengan ukuran pelaporan. Ini juga adalah sifat manusia yang tidak seharusnya lihatlah dalam kesulitan olehnya untuk kemajuan pelaporan itu mengecewakan rencana. Tendensi beberapa manajer adalah yang mendeklarasikan rencananya invalid dan direncanakan ulang untuk membuat keadaan nyata yang seimbang. Sebagaian besar proyek, bagaimanapun, sebagaian kecil mempunyai kunci anggaran selama peristiwa penting, sebagaimana pembiayaan tahun fiscal dan anggaran total, itu tidak berubah.terus menerus direncanakan ulang hanya diperketat waktu dan anggaran yang tersedia untuk tahap proyek yang belakangan. Pendekatan ini mendapat peranan penting dengan keadaan yang mana dua pertiga berjalan proyek selesai (menurut rencana yang terakhir) jadual atau anggaran tiba-tiba menjadi kritis, dan mengakhiri proyek dengan penyampaian setahun terlambat dan dengan biaya yang membengkak.

Jika kegiatan pelanggan adalah sepenuhnya tak dibuat-buat dengan betul-betul mengijinkan direncanakan ulang, manajer proyek harus mencari penyebab pokok permasalahan pada jadual atau anggaran. Perencanaan ulang biasanya adalah atas permintaan bilamana perubahan proyek besar terjadi, sebagaimana pada antar muka, terlambat penerimaan data dari luar organisasi, perubahannya dalam pembiayaan tahun fiscal, atau perubahan pada pesyaratan. Catatan itu sebagias besar ini biasanya hasil perubahan yang tertulis dalam perubahan kontrak. Bagaimanapun, bilamana permasalahan teknisi atau permasalahan staf adalah terjadi deviasi dari rencana, ini adalah kenyataan yang akan terus menerus untuk dilaporkan dan dimonitor.

Mereka tidak akan berkedok dengan penjadualan ulang.
Sebagai manajer proyek, anda harus dengan hati-hati menaksir motiv dan dampak seluruh rancana ulang. Tidak mencoba untuk melihat hari ini yang baik pada biaya hari esok. Yang akbibatnya anda menekankan hari ini, itu juga bilamana sebagian besar peristiwa penting diperhatikan penyampaiannya diperiksa, proyek yang baik ini dijumpai.

Perspektiv Ulang Kembali
Manajer proyek cenderung untuk menjadi ruwet sekali pada proyek di bawah pengendalian mereka, seringkali bilamana ujung-ujungnya mereka mempunyai kesulitan kalau sudah melihat tanda peringatan. Pada area teknisi, manajer proyek yang baik mendapatkan bantuan dari tinjauan teknisi oleh pakar dari luar, kejadiannya jika mereka adalah tidak dipersyaratkan pelanggan. Dalam area administrasi proyek, ini adalah bukan sebagai kemudahan atau otomatis. Sebagian besar perusahaan sekarang mempunyai standar evolusi proyek piranti lunak itu dipersyaratkan tinjauan teknisi untuk seluruh proyek, tapi seringkai terlalu persyaratan tidak serupa dan lainnya tinjauan manajemen sering. Manajer seringkali harus membujuk bosnya untuk mempertahankan tinjauan reguler atau percobaan untuk merubah prespektivnya pada interval reguler. Kami ini menetapkannya berhubungan dengan sebuah prespektiv ulang.
Jika sebagai bos tidak dipersyaratkan tinjauan reguler proyek untuk anda atau yang seringkali terlalu sibuk untuk menghadiri tinjauan, ini adalah terserah anda untuk memanaj diri anda sendiri. Pada kebanyakan jalan yang sama sepertinya anda mengevaluasi permintaan waktu pada anda, anda harus berbalik langkah dari rincian permasalah harian untuk menaksir status proyek yang benar. Melihat dengan hari-hati pada peristiwa penting tingkat atas, rencana staf, dan anggaran. Realistis taksirannya proyek berlawanan dengan rencana. Menanyakan pada diri anda sendiri yang agak menyelidik pertanyaannya anda akan mengharapkan dari bos anda atau tinjauan tim manajemen perusahaan.

Ini kembali prespektif anda giliran menaruh barang pada ruang yang layak. Tujuan anda proyek adalah sampai lengkap pengembangannya sebagai perencana dan sebagai bagian pada sebuah kontrak, yang salah satunya dengan resmi tertulis pelanggan sebelah luar atau dokumen internal yang disetujui diantara organisasi. Batas permulaannya prespektiv diulang kembali harus dilihat kontraknya dan analisis aktivitas proyek, rencana, dan permasalahan berlawanan dengan komitmen berdasarkan perjanjian. Ini adalah mudah untuk rekayasa piranti lunak sampai pada penambahan fasilitas ekstra yang mana mereka rasanya memerlukannya, kejadian yang lebih dulu tak disediakan di dalam kontrak. Kecuali kalau mereka dipersyaratkan rancangannya yang baik atau ini adalah alasan yang baik untuk mereka tambahkan (dan ini dapat dikerjakan sampai anggaran dan jadual), diskusi mereka dengan pelanggan. Jika pelanggan ingin mereka, perubahan dalam kontrak barangkali beres.

Untuk menyelesaikan pengulangan kembali prespektiv yang penuh dengan arti itu akan memperbaiki manajemen proyek anda, menanyakan kepada diri anda banyak pertanyaan proyek lainnya, rencana anda, staf, dan anda mengerti tugas proyek. Gambar 4.9, menyediakan dalam contoh benyediakan bermacam pertanyaan itu yang akan ditinjau.

Penjadualan
Penjadualan yang Optimis, adalah jadual yang dipaksakan tidak melihat dari aspek-aspek proyek antara lain sumber daya manusia yang terlibat langsung dalam proyek pengembangan piranti lunak apakah tersedia cukup seperti programmer, teknisi analis dan staf pendukungnya, serta tingkat kesulitan dari proyek itu sendiri dimana aktivitas proyek itu tiap-tiap kegiatan saling ketergantungan sehingga diperlukan ketelitian secermat mungkin.
Mengatasi penjadualan yang optimis, untuk mengatasi hal ini diperlukan

Penjadualan Optimis

• Jadual yang terlalu optimis telah menjadi bahan diskusi selama lebih dari 20 tahun, tetapi tetap saja terjadi.
• Merupakan jadual yang membuat stress tim pengembang.
• 50% dari proyek menetapkan jadual proyek sebelum keputusan kebutuhan sebenarnya ditetapkan.

Contoh :
Microsoft Word for Windows 1.0 ditetapkan dibangun dengan waktu : 395 hari. Padahal lintasan kritisnya 460 hari. Sasaran yang ingin dicapai :
1. Membuat Pengolah kata terbaik di dunia.
2. Dibuat dalam 12 bulan.

Kenyataan : 5 tahun, 660 man-months, 249.000 baris program.

• Proyek mengalami banyak turn-over (dari 4 orang pemimpin proyek : 2 orang mengundurkan diri dan 1 mundur karena alasan kesehatan).
• Karena jadual ketat, tim pengembang merubah kemampuannya, kualitasnya jadi rendah dan tidak lengkap. Sebab-sebab Penjadualan Optimis

Penyebab penjadualan optimis adalah adanya pengaruh eksternal yakni:

• Adanya pameran
• Perubahan pajak
• Hari raya

Manajer proyek dan pelanggan enggan memakai suatu estimasi rangkuman sehingga memakai estimasi tunggal. Manajer proyek dan tim menganggap ringan atau memang ingin bekerja di bawah tekanan. Pimpinan, bagian pemasaran atau pelanggan menginkan tanggal tertentu proyek dapat diselesaikan dengan baik dan bisa segera dioperasikan sedangkan pemimpin proyek tidak bisa berbuat apa-apa.Proyek diestimasi dengan buruk baik penjadualan dan biaya.

Gambar 4.9 Jadwal khusus pengembang. Pengembang yang secara khusus menaksir 20 sampai 30 persen lebih rendah dari keperluan nyata mereka. Hanya menggunakan perkiraan yang normal mereka menaruh kesempatan melengkapi tepat waktu di bawah 50 persen· Kualitas perencanaan proyek berakibat pada perencanaan lainnya seperti personil, pemilihan staf, modul yang harus dibuat dokumentasi, integrasi, pengujian.

• Proyek berjalan tanpa rencana yang jelas
• Waktu yang digunakan analisis dan perancangan menjadi lebih sedikit.
• Terlalu focus pada kemajuan proyek daripada kualitas kegiatannya sendiri.
• Mengurangi tingkat kepercayaan pelanggan.
• Penggabungan sehingga proses debug ini lebih sedikit.
• Hilangnya wibawa pemimpin proyek atau manajer proyek.
  

Mengatasi Jadual yang Optimis
Jadual optimis tidak dapat dipecahkan oleh pengembang secara cepat, kecuali dipecahkan lebih dulu masalah ketatnya jadual.

3 faktor yang dapat memunculkan masalah pada penjadualan :

1. Terlalu banyak berharap
   · Ingin dapat uang secepatnya.
   · Terlalu ambisius.
2. Mengabaikan atau belum pernah dengar cerita tentang estimasi pembuatan piranti lunak atau pengaruh sesungguhnya dari jadual yang ketat.
3. Lemahnya kemampuan saat negoisasi.
   · Pengembangnya introvert.
   · Kalah bernegoisasi dengan pihak pimpinan atau pihak marketing.
   · Pengembang tidak suka bernegoisasi.

Karena itu ketiga faktor tersebut harus dapat diatasi oleh tim pengembang. Faktor 1 dan 2 sudah dibahas pada pertemuan-pertemuan sebelumnya.

Strategi Negoisasi
Terdiri dari 4 bagian yaitu :

1. Pisahkan faktor manusia dengan faktor masalah. Bila kepribadian negoisator (pengembang vs pemasaran) berbeda jauh maka negoisasi akan sulit mendapatkan titik temu. Karena itu kemampuan untuk memahami pihak lawan sangat penting.
   o Perbaiki hubungan dengan pelanggan dengan membuka kerjasama.
   o Jangan emosi saat bernegoisasi.
2. Fokuskan pada minat, bukan posisi. Dengan menempatkan diri pada posisi, maka kondisi negoisasi adalah kalah-menang.
   § Tunjukan kelebihan pengembang secara cepat.
   § Tunjukan meningkatnya peluang keberhasilan.
   § Tunjukan keberhasilan pengalaman perusahaan.
3. Temukan pilihan-pilihan untuk mendapat kan manfaat bersama. Ada 3 hal yang bisa dinegoisasikan: jadual, biaya dan produk. Galilah dari 3 hal tersebut, faktor yan dapat dibuat pilihan negoisasi.
4. Minta ketegasan terhadap kriteria obyektif.
   o Jangan negoisasi tentang estimasi.
   o Bila perlu estimasi dilakukan oleh pakar.
   o Minta alasan prosedur estimasi

4.4.3 Manajemen Personil
Pada Bagian 4.1, kami diskusikan yang sebagian besar esensinya elemen yang pada awalnya ketepatan manajer proyek dalam penyeleksian sebuah proyek. Waktu ini mempunyai kepandaian, tugas individu itu adalah untuk merekrut staf proyek dan untuk memanaj nya ini sampai proyek sukses dengan kelengkapannya.

Perekrutan
Definisi persyaratan proyek biasanya adalah yang dikerjakan sebagai bagian persiapan proposal. Jika tidak, ini adalah sebagian besar harus diperhatikan jenisnya pada agenda manajer proyek pada awal proyek. Ketergantungan pada struktur organisasi perusahaan, manajer proyek harus merekrut dari dalam perusahaan, dan mungkin juga dari luar perusahaan, untuk memenuhi staf proyek yang diperlukan. Ini adalah harus diperhatikan oleh manajer proyek untuk mengidentifikasi areal resiko yang tinggi itu baik dipersyaratkan fakta-fakta orang yang berbakat atau berpengalaman unik. Penekanan dapat dari tempatnya mendapatkan orang kunci untuk menutup area proyek yang spesifik.

Pendekatan yang digunakan untuk merekrut staf untuk proyek dapat mempunyai efek yang abadi dalam sikapnya staf proyek. Kontak pertama yang dibuat oleh manajer proyek, pendekatan yang digunakan, informasi yang disediakan dalam proyek, dan deskripsi kandidat proyek berkewajiban akan memutuskan jika manajer proyek yang baik sukses dalam mentransfer kandidat untuk proyek atau menyewa kandidat dari luar perusahaan. Faktor ini baik juga mempengaruhi sikap kandidat suatu kejadian yang ditempatkan pada proyek. Kebijakan rekrutmen yang akan distandarkan dan disetujui pada kemajuan manajemen bawah. Komitmen dengan rasa hormat untuk tingkat job (promosi), kondisi pekerjaan, kompensasi, dan susunan administrasi yang berhubungan dengan perjalanan, relokasi, jam khusus bekerja, dan lembur yang akan mendapatkan prioritas untuk permulaan keperluan rekrutmen dengan konsisten menjamin komitmen untuk seluruh staf proyek.
Rekrutmen yang didiskusikan atau interview akan dimasukan yang paling sedikit seperti berikut ini :

1. Informasi umum lainnya latar belakang proyek, ini adalah tujuan dan tipe umum pekerjaan yang berbelit-belit.
2. Informasi organisasi proyek bagaimana yang baik ini interaksinya dengan aktivitas perusahaan lainnya banyaknya orang dengan segala keruwetan, siapa yang menentukan untuk teknisi besar dan posisi administrasi.
3. Deskripsi proyek menetapkan penawran.
4. Alasan penyeleksian kandidat sudah ditetapkan.
5. Deskripsi perubahan kompensasi dan perubahan klasifikasi job, jika apa saja, dimasukan dengan ketetapan proyek.
6. Diskusikan bahan administrasi yang berhubungan dengan relokasi, jam kerja, dan lembur yang pantas.
7. Yang bersangkutan dengan informasi lainnya yang berkenaan dengan proyek barangkali tidak sama dari proyek perusahaan lainnya yang mana kandidat barangkali familier.

Banyak identifikasi material untuk rekrutmen ini didiskusikan adalah keadaan dengan sebagian besar posisi itu adalah untuk dasar. Ini akan tertulis di bawah untuk menghindari salah pengertian dan dengan konsisten disediakan bilamana yang lainnya daripada supervisor atau anggota staf senior proyek adalah yang ruwet pada proses perekrutan proyek.

Setelah Perekrutan – Langkah Selanjutnya
Perekrutan mempunyai inisial staf proyek, manajer proyek harus memulai satu yang sebagaian besar manajemen berkepentingan pada aktivitas manajemen personil itu. Peranan penting manajer proyek terhadap staf harus bersama tujuan pengembanan khusus yang lengkap diperlukan. Pada suhu yang kondusif untuk membuka komunikasi, kebanggan, umpan balik yang positif, sikap yang konstruktiv telah dapat dengan ulungnya menyelesaikan kepemimpinan dengan baik, perlakuan yang fair, dan diperlukan kejujuran pada bagian manajemen proyek untuk bersama-sama bangga dengan staf proyek siapa yang membuat terjadi. Orang adalah banyak yang termotivasi oleh yang tidak dinyatakan secara jelas itu tergantung pada sikap pemimpin proyek terhadap individu pada proyek. Probalitias proyek sukses adalah mempertinggi signifikan bilamana orang dalam proyek yang tepat kontribusi mereka adalah diperhatikan. Ini adalah job manajer proyek, sewaktu dia merekrut sebuah grup individu untuk proyek, dengan memberikan mereka setiap perasaan penting dan membuatnya masuk tim proyek. Langkah pertama ini dalam proses terjadi selama aktivitas perekrutan. Oleh pemberitaan individu kenapa mereka telah mempunyai seleksi untuk proyek dan jelas definisi job-nya pada proyek, perasaan penting dan dimulainya spirit tim proyek. Yang telah dapat mengasuh selama proyek dengan banyaknya konsep manajemen personil yang sederhana :

1. Ingat komitmen yang dibuat selama proyek merekrut dan memikirkannya dalam rencana proyek.
2. Menganjurkan berkomunikasi dalam tim kegiatan yang konflik. Konflik yang keliru hingga memburuk akhirnya akan muncul ke permukaan dengan cara yang destruktif. Membawa secepatnya keluar dalam lingkungan penyelesaian permasalahan, konflik dapat diselesaikan ulang yang konstruktif, cara untuk menghindarkan malu.
3. Mengumpulkan ide dari anggota tim proyek.
4. Tersedianya peluang untuk anggota tim proyek untuk mendemonstrasikan keahliannya atau pengetahuannya di hadapan kawan sebaya mereka, pelanggan, dan manajemen tingkat atas.
5. Manajemen mungkin menyediakan pengakuann prestasi individu dan lengkap peristiwa pentingnya (i.e., tidak diperlihatkan interesnya hanya pada area persoalan). Yang demikian umpan balik yang positif adalah pendorong moral yang baik dan disediakan insentif yang meyakinkan untuk melanjutkan kinerja yang tinggi.
6. Jadi konsisten pada kebijakan administrasi personil.
7. Berikan kredit untuk kinerja personil proyek yang tidak mendapat kredit dari anda sendiri. Kredit akan datang untuk manajer proyek bilamana proyek telah lengkap dengan jadual dan biaya.
8. Menyediakan waktu pada jadual anda sebagai manajer proyek untuk orang yang bermasalah

Konsep ini, kombinasi dengan organisasi, yang akan diperlukan perencanaan, kontribusi yang baik sebagian besar sampai proyek berhasil. Untuk proyek yang besar, bagaimanapun, ini adalah tidak cukup untuk manajer proyek dengan menggunakan konsep manajement personil ini. Berhati-hati memilih manajer subproyek, paket pekerjaan manajer, pimpinan grup, atau tingkat apapun manajemen adalah menetapkan untuk proyek yang dipersyaratkan untuk promosi spirit tim dan sikap yang positif sepanjang proyek.

Penugasan Ulang
Satu pendekatan yang juga seringkali diberikan oleh manajer proyek, yang mana personil proyek frustasi, itu adalah frekuensi penugasan ulang. Manajer proyek yang mempercayakan itu oraginisasi harus direkstruturisasi, atau pada yang paling sedikit jumlah penugasan ulang dibuat, sampai pada setiap pertemuan proyek krisis. Berulang-ulang penugasan ulang staf dari satu tugas untuk yang lainnya signifikan

Langkah Selanjutnya
Kapan tugas individu proyek diselesaikan, manajer proyek berfungsi sebagai manajemen personalia tidak mungkin menyelesaikan. Tergantung pada kebijakan perusahaan itu, struktur organisasi, dan komitmen yang dilakukan di awal proyek, manager proyek mungkin mempunyai beberapa tanggung jawab untuk membantu personil perusahaan lain di dalam mengidentifikasi tugas yang baru yang sesuai untuk proyek yang ditinggalkan orang. Tanggung jawab ini, jika diabaikan, akan menghasilkan suatu hambatan pada pihak karyawan untuk menerima tugas proyek yang akan datang. Karyawan menghormati manager proyek siapa yang melanjutankan atas semua komitmen manajemen personalia dan tanggung-jawab, seperti halnya teknis dan tanggung-jawab manajemen adminitratif

4.4.4 Manajemen Teknik.
Tingkat manajemen teknik mengarahkan diperlukannya suatu manager proyek adalah suatu fungsi ukuran proyek dan jenis proyek. Karena proyek sangat kecil, manager proyek menyediakan teknis seperti halnya manajemen adminitratif. Karena proyek besar, manager proyek harus, seperti yang diuraikan bagian 4.4.1, memusatkan aktivitasnya pada yang lainnya bukan isu teknis proyek. Pada umumnya suatu sistem subprojek manajer rancang-bangun, dikepalai seorang engineer, atau seorang analis proyek senior didelegasikan kebanyakan dari otoritas dan tanggung jawab untuk aspek yang teknis proyek itu. Bagaimanapun, keputusan teknis yang utama berdampak pada biaya-biaya, jadual, antarmuka, atau lainnya unsur-unsur proyek tidak bisa didelegasikan dan harus dipecahkan oleh manager proyek itu sendiri. Teknis, sesuai kontrak, dan informasi administratif memerlukan untuk pembuatan keputusan dan rekomendasi yang harus disiapkan oleh spesialis perancang untuk dipertimbangkan oleh manager proyek.

Peralatan (tools), Konsep, dan teknik untuk manajemen teknik telah dibahas Bab 2 dan 3. penggunaan dokumentasi yang bersifat membangun dan tinjauan ulang disain barangkali yang paling kritis. Lingkungan itu menyediakan di mana jika proyek tidak dapat bermanfaat bagi spesialis teknis yang berpengalaman secara langsung mendukung usaha pengembangan itu untuk mengesahkan kebutuhan, disain, dan informasi test. Karena sejak beberapa konsep pengembangan menyediakan jarak penglihatan yang lebih teknis dibanding orang lain, pengembangan yang memilih pendekatan berdampak pada manajemen teknik. Bagaimanapun, konsep manajemen teknik yang utama diterapkan berlaku untuk semua orang. Suatu lingkungan harus menyediakan untuk teknis berkomunikasi, dokumentasi, tinjauan ulang, dan pengendalian. Standard untuk masing-masing harus dibentuk dan diperkuat oleh manager proyek. Buku ini menyediakan dokumentasi dan petunjuk tinjauan ulang ini yang diperlukan sebagai pendukung manajemen teknik yang sukses, dan test standard diperlukan juga dibentuk. Tingkatan formalitas dan kompleksitas standard harus konsisten dengan ukuran, kompleksitas, dan resiko usaha pengembangan.

Kemajuan Penilaian
Perencanaan yang baik memudahkan pelaporan dan penilaian kemajuan teknis untuk membantu manager proyek itu di dalam mengalokasikan personil yang memenuhi tugas teknis yang diperlukan. Faktor penting di dalam perencanaan teknis adalah tujuan dari pos pemeriksaan cara mengukurnya terpenuhi, penetapan suatu kemajuan yang mekanisme pelaporannya yang sesuai kepada ukuran proyek, dan penetapan suatu masalah yang dilaporkan dan rencana perkerjaan mengikuti jalannya pola terhadap kebutuhan proyek.
Untuk teknis membuat laporan internal pekerjaan, tanggung jawab dari semua anggota staff di dalam melaporkan kemajuan harus diperkuat dan tergambar dengan jelas. Mata rantai yang lemah di dalam siklus pelaporan proyek adalah seringnya anggota tim mengalami kegagalan atau para supervisor tingkat pertama untuk memahami arti kemajuan sistem pelaporan dan bagaimana digunakan dalam membantu manajer proyek menetapkan prioritas dan mengalokasikan sumber daya proyek. Ini sering mengakibatkan 90% sindrom penyelesaiannya, dengan anggota tim yang melaporkan tugas itu ketika 90% yang diselesaikan setelah berminggu-minggu.

Suatu pendekatan yang lebih baik adalah untuk keperluan yang diperkirakan usaha dan waktu untuk menyelesaikan tugas itu. Sedangkan yang lebih kuantitatif dan terukur, ini disediakan oleh manager proyek dengan informasi yang mana ia dapat lebih teliti dengan cara membaca untuk menentukan skala bahwa untuk menaksir kemampuan dari tiap anggota tim dan yang lebih secara realistis menginterpretasikan arti dari status informasi. Kemudian manager proyek, bekerjasama dengan staff teknis yang sesuai, dapat menentukan tindakan korektif yang sesuai.

Pertemuan-Pertemuan.
Gunanya pertemuan-pertemuan teknis dapat berperan untuk penyelesaian proyek atau memboroskan waktu dari banyak orang-orang kunci dan merintangi aktivitas administratif, seperti halnya kemajuan teknis. Manager proyek harus mengendalikan kecenderungan itu untuk mencoba memenuhi pekerjaan teknis dengan pertemuan-pertemuan. Pertemuan-pertemuan, dengan baik ditangani, dapat dimanfaatkan untuk :

1. mendidik mereka yang harus mengetahui lebih banyak tentang status yang sekarang perancangan unsur piranti lunak dengan produk mana mereka akan menghubungkan,
2. melayani untuk mengkoordinir disain atau keputusan antarmuka (dengan cepat dan mau mendengarkan dibandingkan dengan cara merancang nota),
3. mengumpulkan gagasan yang dengan cepat pada suatu keputusan segera terjadi,
4. menyediakan informasi penting mengenai perubahan,
5. konflik yang tersembunyi mengemuka, dan
6. mendamaikan pandangan yang berlawanan.

Pertemuan kemudian memecahkan isu, mengumpulkan informasi, melaporkan status, atau mendidik staff tentang tugas teknis, tetapi tidak memenuhi pekerjaan teknis yang spesifik diperlukan untuk melengkapi penyelesaian projek itu. Dengan pemikiran ini, sasaran yang harus dijaga hanya untuk pertemuan yang mereka perlukan untuk mengkoordinir aktivitas dan memelihara saluran komunikasi yang diperlukan untuk memenuhi tugas pengembangan itu.
Kapan pertemuan-pertemuan diperlukan untuk mengatur kegiatan teknis itu, adalah penting bahwa manager proyek memerlukan pemanggilan orang dalam pertemuan untuk melakukan hal-hal sebagai berikut:

• jadikanlah pertemuan mempunyai tujuan pasti dan terbatas bahwa peserta memahami tujuan itu.
• jadikanlah peserta mengetahui secara pasti apa yang diharapkan dari mereka.
• jadikanlah dengan pasti bahwa orang-orang yang hadir itu baik untuk memenuhi tujuan yang telah dinyatakan.
• jadikanlah dengan pasti untuk memelihara pertemuan sekecil mungkin untuk menyediakan komunikasi yang lebih efektif. Hanya penyokong, pembuat keputusan, dan dengan tugas menghadirinya itu menyelesaikan keputusan yang diperlukan.
• jadikanlah dengan pasti untuk membatasi pertemuan yang panjang itu. Jika isu masih belum terpecahkan, kemungkinan skeduling suatu kelanjutan pertemuan dengan suatu kelompok yang lebih kecil perlu diselidiki.
• jadikanlah dengan pasti untuk membawa pertemuan itu kepada suatu kesimpulan yang terbatas. Peserta perlu ikut memahami keputusan yang dibuat. Menuju tindakan yang direncanakan, dan siapa yang mempunyai tanggung jawab untuk tindakan yang berikutnya. Karena suatu pertemuan perlu menginformasikan kesimpulan dengan ringkasan titik kunci yang diperkenalkan sepanjang pertemuan.

Pertemuan yang sering dilakukan adalah satu-satunya cara efektif untuk mendapatkan orang kunci untuk memusatkan atas isu yang sangat teknis itu dapat dipecahkan untuk dipelihara dari pada menunda salah satu dari tugas pengembangan. Ini adalah produktif jika pertemuan yang direncanakan dengan baik dan sesuatu yang diijinkan untuk perbedaan ke dalam lain area. Suatu pertemuan adalah produktif tidak jika:

• pertemuan bisnis mungkin secara efisien telah lebih yang ditangani oleh nota percakapan telepon individu, atau lainnya yang lebih sedikit mengkonsumsi waktu yang berarti
  pertemuan menjadi suatu diskusi teknis yang terperinci antara beberapa partisipan.
• orang-orang yang diperlukan untuk memenuhi sasaran pertemuan tidak hadir.
• peserta datang tidak disiapkan.
• biaya pertemuan melebihi nilai keuntungan yang dimiliki mungkin untuk melakukan keputusan dipertemuan itu.

4.4.5 Manajemen Biaya
Manajemen biaya yang benar-benar dimulai dari sepanjang proses estimasi biaya seperti yang diuraikan pada bab 3. estimasi biaya, biaya persiapan proposal, persiapan penawaran akhir, dan negosiasi yang diarahkan; mendahului aktivitas manajemen biaya proyek riil. Penetapan biaya yang realistis dan negosiasi sehingga mendapatkan suatu proyek yang memulai melangkahkan kaki kanan. Bagaimanapun, tanpa melaporkan biaya dan pentingnya biaya pada pihak manager proyek, suatu proyek sukses menjadi kebalikannya dapat menjadi suatu malapetaka untuk perusahaan dan, barangkali, karier manager proyek itu.

Biaya yang paling utama yaitu mengendalikan pertimbangan di dalam menentukan atas proyek adalah untuk menetapkan mengatur pembelanjaan masing-masing tugas teknis atau paket pekerjaan. Dengan keuangan yang telah diberitakan /dikomentari perincian tugas yang sama sebagai manajemen teknik, kemajuan teknis dan laporan keuangan yang dapat siap dihubungkan. Dengan kemampuannya siap dibandingkan yang teknis dan informasi keuangan, status yang benar proyek dapat dengan mudah ditentukan tanpa suatu latihan konversi raksasa (masive).

Laporan Biaya
Laporan keuangan pada umumnya dihasilkan menjadi suatu fungsi akuntansi biaya perusahaan untuk manager proyek itu. Uraian biaya dan tingkatan Pekerjaan Uraian biaya-biaya adalah jalur yang sedikit banyaknya dipertimbangkan manager proyek itu. Pertimbangan yang menjadi penting dan penggunaannya visible. Manager proyek harus memutuskan tidak tentang apa pelaporan biaya tingkatan yang diperlukan untuk menyediakan informasi itu diperlukan untuk mengendalikan proyek itu. Terlalu banyak yang detil pada berbagai hal kacau balau dan dapat menyembunyikan apa yang sesungguhnya terjadi.
Bagaimanapun, data bagi suatu tingkatan yang terperinci diperlukan untuk menentukan di mana jika permasalahan biaya di dalam proyek itu terjadi.

Akuntansi biaya perusahaan akan secara normal menyediakan data anggaran dan pembelanjaan nyata sampai saat ini oleh perancang akuntansi biaya. Manager proyek perlu mempunyai data ini yang direncanakan untuk menyediakan suatu penyajian grafis, yang mana adalah lebih cepat untuk berasimilasi dan menandai adanya kecenderungan lebih siap terpenuhi dibanding meninjau ulang daftar angka-angka yang pada umumnya disajikan oleh sistem akuntansi biaya. Yang secara hati-hati merekam dan perkerjaan mengikuti jalannya biaya-biaya yang dapat juga mendukung nilai data sebagai bagian dari legasi proyek terhadap proposal proyek yang berikutnya. Suatu catatan yang baik dari biaya riil, dengan menggunakan anggaran proposal, itu menyediakan dasar untuk estimasi biaya ditingkatkan.

Alokasi Sumber Daya.
Tujuan nilai proyek sistem informasi yang mana, ketika dibandingkan anggaran, dapat digunakan untuk menentukan jika tindakan manajemen diperlukan. Anggaran menghadirkan suatu alokasi sumber daya yang direncanakan oleh petugas dan dengan periode waktu dalam keseluruhan proyek itu. Suatu masalah biaya di dalam satu area bisa memerlukan realokasi sumber daya dari yang lain atau dari suatu cadangan manajemen.
Area Cadangan Manajemen adalah suatu mekanisme perusahaan yang menggunakan banyak untuk menyediakan manager proyek itu dengan kemampuan untuk bereaksi terhadap biaya yang melebihi dari ketentuan semula, karena apapun juga alasannya, di dalam satu bagian dari proyek itu. Dengan pengaturan yang mengesampingkan pada awal start manager proyek itu mempunyai sumber daya yang tersedia untuk mendukung lingkup permasalahan. Jumlah cadangan manajemen pada umumnya suatu fungsi resiko proyek (resiko lebih tinggi, cadangan lebih besar), jenis kontrak , petunjuk perusahaan, dan, yang adakalanya, petunjuk pelanggan yang dirundingkan.

Pencatatan Komitmen
Terutama sekali untuk proyek lebih kecil, manager proyek dapat mendapatkan suatu kejutan riil ketika bukan biaya tenaga kerja yang akhirnya memasuki sistem akuntansi biaya itu. Suatu proyek yang nampak menjadi benar pada anggaran dapat dengan tiba-tiba berubah menjadi melebihi dari yang ditentukan semula. Jalan yang terbaik untuk menghindari situasi ini adalah untuk menjejaki itu bukan komitmen tenaga kerja sebagaimana adanya yang dibuat dengan suatu Pencatatan Komitmen. Catatan ini perlu mempunyai masukan untuk masing-masing komitmen, seperti perangkat keras atau pembelian peralatan komputer, jasa teknis dari lain organisasi perusahaan, atau biaya perjalanan. Seperti komitmen yang nampak pada laporan akuntansi biaya, mereka ditunda dari Pencatatan Komitmen. Catatan kemudian hanya berisi komitmen itu yang telah tidak tercakup di laporan keuangan dari sistem akuntansi biaya.
Variasi Proyek biaya dapat dengan tepat menyaingi bantuan Pencatatan Komitmen. Sistem Akuntansi biaya melaporkan lebih komitmen yang tidak ditunda di dalam Catatan Komitmen harga yang sama sebenarnya sampai saat ini. Pendekatan ini perlu menghindari kejutan yang berlebihan dalam kaitannya dengan keterlambatan dalam mengusahakan biaya-biaya yang bukan tenaga kerja ke dalam laporan keuangan itu.

4.4.6 Dukungan Pelayanan
Manager proyek mungkin telah mengkhususkan bantuan yang tersedia untuk mendukung proyek itu. Banyak perusahaan memelihara staff spesialis di dalam kontrak, hubungan industri, pemasaran, penetapan harga, merancang perencanaan dan pengendalian, dan konfigurasi manajemen untuk mendukung semua proyek. Manager proyek Piranti lunak perlu mencari-cari sumber pendukung ini dan menggunakannya kepada keuntungan proyek. Banyak perusahaan yang juga menyediakan spesialis penasehat yang sah tentang undang-undang, teknis penerbitan, hak paten, fasilas perencanaan, pembelian, keamanan, dan pengembangan karier. Ketika yang diperlukan oleh proyek, spesialis ini harus terdaftar oleh manager proyek itu. Area lain yang dapat berguna bagi suatu proyek adalah perusahaan riset dan pengembangan mandiri ( IR&D) aktivitas. Manager proyek harus terbiasa dengan IR&D aktivitas yang mungkin telah memproduksi hasil atau peralatan yang berguna bagi proyek. Ia perlu juga siaga ke peluang untuk menyelidiki teknologi atau mengembangkan peralatan yang berguna bagi proyek melalui IR&D membiayai studi atau aktivitas pengembangan.


4.5 LEGASI PROYEK.
Implementasi yang sukses perencanaan dan pendekatan perkiraan biaya diperkenalkan pada bab 3 dan konsep pendekatan manajemen proyek yang dibahas bab ini memerlukan pengembangan dari suatu dasar pengalaman dari proposal diselesaikan dan dirancang. Itu tidaklah wajib bahwa satuan individu yang menyiapkan perkiraan biaya itu dan Rencana Proyek untuk proyek yang sekarang secara pribadi sudah mengalami menyelesaikan proyek. Itu adalah, bagaimanapun, diperlukan personil itu di dalam dokumen proyek yang diselesaikan proyek dari sejumlah perspektif yang berbeda dalam urutan bagi proyek masa depan untuk bermanfaat. Perspektif ini diperlukan yang meliputi suatu evaluasi dari perspektif manager proyek, dari suatu perspektif teknis yang senior atau staf manajemen yang ahli dekat dengan proyek, dan dari suatu perspektif biaya/perencanaan jadual.
Produk dari ini memutar kembali yang memperhatikan masing-masing dan proposal utama proyek yang diperlukan meliputi :

• uraian proyek,
• evaluasi Perencanaan Proyek,
• evaluasi pada proyek karena ia diterapkan, dan
• rekommedasi untuk proyek masa depan.

Suatu garis besar suatu dokumen sejarah proyek yang meliput topik yang utama ini disiapkan dalam bentuk gambar 4.14. untuk kebanyakan perancangan piranti lunak, jadi dokumen ini akan tidak lagi dibandingkan suatu lima sampai enam nota halaman. Bagaimanapun, untuk dokumen tertentu yang lebih besar mungkin adalah yang diperlukan untuk mengevaluasi proyek itu dalam kaitannya dengan berbagai unsur piranti lunak utama, dengan suatu evaluasi capaian dan satu set rekomendasi pada setiap area, seperti halnya deposit merancang rekomendasi evaluasi, haruslah dicatat bahwa topik tertentu tercakup di diskusi ini berlaku bagi proposal utama, seperti halnya pada proyek yang telah diselesaikan. Itu adalah, sesi 1,5 dan 6 garis besar di dalam gambar 4.10 perlu juga diselesaikan untuk semua proposal utama, bahkan usaha yang gagal / kehilangan, untuk membantu meningkatkan mutu tentang usaha proposal masa depan.

Petunjuk untuk masing-masing bagian utama yang teridentifikasi pada gambar 4.10 yang diperkenalkan seperti pada paragrap yang berikut ini yaitu :

Bagian 1 Pengenalan Dan Ikhtisar
Pengenalan Dan Bagian Ikhtisar dokumen sejarah proyek perlu menyediakan pemakai dokumen dengan informasi latar belakang cukup untuk dengan teliti menilai mudah diterapkan dari proyek ini mengalami suatu usaha masa depan yang spesifik. Uraian dan latar belakang Material perlu mengidentifikasi atau sedikitnya menguraikan sebagai berikut:

1. Sebutan/judul Proyek.
2. Periode Capaian.
3. Pelanggan.
4. Usaha awal memasarkan (jika bisa diterapkan).
5. Lingkungan Proposal, jika yang bisa diterapkan (tampak sumber atau penawaran kompetitif).
6. Jenis Kontrak (harga pasti, kelebihan biaya ditetapkan, penghargaan atau pembayaran perangsang, atau lainnya).
7. Struktur Pembayaran Dan Faktor Evaluasi, sebagai kesesuaian.
8. Pendekatan memonitor Pelanggan (tinjauan ulang bulanan, perwakilan ditempat, tinjauan ulang formal, tim pendukung teknis pelanggan kecil atau besar, penggunaan pelanggan konsultan, dll).
9. Topik Negosiasi utama (area spesifik di mana jika perubahan telah dibuat, dasar pemikiran, dan yang berhubungan dengan biaya / dampak jadual).
10. Tindakan khusus mengambil untuk memperoleh kontrak itu dalam kaitannya dengan komitmen proposal awal perusahaan dan dana proposal, personil, sumber daya riset dan pengembangan, pengaturan tim, dan pemilihan subkontraktor.
11. Faktor Evaluasi Proposal spesifik dalam kaitannya dengan kekuatan dan kelemahan, dengan suatu indikasi faktor yang paling berpengaruh di dalam kemenangan atau kerugian kontrak yang diusulkan.

Sebagai tambahan di atas, suatu bagian penting untuk dimasukkan adalah apa yang diidentifikasi sumber dokumen itu. Bagian ini perlu mengidentifikasi personil yang berhubungan dengan proposal dan / atau perancang dari siapa informasi tambahan dapat diperoleh. Personil bagian ini didaftar yang diperlukan antara lain meliputi:

1. Lini manajer yang secara langsung dilibatkan dalam keputusannya untuk menawar atau proses dengan proyek itu.
2. Untuk proposal, manajer proposal dan anggota tim proposal senior yang bertanggung jawab untuk yang berifat teknis dan masukan yang berharga.
3. Lini manajer untuk siapa manager proyek melaporkan.
4. Manager proyek, teknis senior, dan keuangan proyek senior mengorganisir anggota.
5. Jika tim pendukung gugus tugas atau tim tinjauan ulang internal telah digunakan sepanjang proyek, pimpinan . itu seperti tim.

Untuk kelengkapan, jika sepanjang hidup perubahan manajemen proyek telah dibuat, periode perubahan keterlibatan telah dibuat, periode dari tiap keterlibatan dalam kaitannya dengan kalender waktu, tugas teknis, dan tinjauan ulang yang yang terpenuhi harus dimasukkan.

Bagian 2. Evaluasi Rencana Proyek
Bagian dua perlu menyediakan suatu evaluasi tugas yang mula-mula diusulkan, tenaga kerja dan perkiraan pendukung, jadual, dan informasi anggaran dengan membandingkannya dengan proyek yang nyata. Data Proposal harus disesuaikan untuk perubahan apapun harus dirundingkan dan kemudian membandingkan dengan akhir proyek riil. Informasi harga dari proposal dan data yang nyata harus dimasukan format serupa dan kemudian dibandingkan.
Suatu ringkasan seperti pada gambar 4.15 dapat digunakan untuk tujuan ini. Subbagian di dalam evaluasi proyek bagian ini perlu menyediakan informasi yang cukup tentang tugas, jenis permasalahan piranti lunak, atau permasalahan antarmuka yang tidak biasa untuk mengijinkan analisa biaya proposal masa depan untuk menginterpretasikan ringkasan data keuangan. Khususnya, biaya per instruksi informasi harus dievaluasi secara hati-hati, bersama-sama dengan faktor proyek seperti

• waktu riil vs. piranti lunak batch,
• HOL, vs bahasa asembler,
• ilmiah vs manajemen data,
• disain baru vs usaha konversi, atau
• piranti lunak pendukung vs sistem pengembangan yang matang.

Bagian ini harus menyediakan informasi cukup untuk mengijinkan pemakai dari dokumen ini untuk koreksi yang membandingkan perkiraan biaya dan tugas yang nyata untuk proyek ini dengan lain proyek yang diselesaikan dan menggunakan data itu untuk meningkatkan perkiraan proposal.

Bagian 3. Teknik Manajemen
Bagian ini perlu menguraikan teknik manajemen yang digunakan proyek, mengidentifikasi permasalahan yang ditemukan manajemen, menguraikan tindakan korektif mengambil, dan mengidentifikasi teknik yang bisa menjadi keuntungan proyek itu. Penggunaan sejarah untuk proyek sistem informasi masa depan yang potensial dari informasi ini harus dipertimbangkan ketika menyiapkan bagian ini. Manajemen spesifik Personil tidak terpuji atau harus dikritik. Sesungguhnya, nama dari para manajer individu adalah tak perlu. Teknik yang digunakan untuk mengkoordinasikan pelanggan, penjadualan, alokasi sumber daya (personil, perjalanan, perlengkapan, dan dukungan pelayanan). Tugas pengendalian dan kemajuan analisa harus diuraikan dan dievaluasi. Dalam beberapa hal, kepribadian akan masuk untuk merekomendasikan sejumlah atau seseorang dengan kelemahan tertentu untuk peranan tertentu di dalam proyek itu. Informasi jenis ini adalah berharga dan harus dimasukkan, tetapi yang dinyatakan adalah suatu cara yang konsisten dengan tujuan yang sebelumnya dinyatakan dan penggunaannya tentang dokumen ini.

Bagian 4 Teknik Pengembangan
Bagian ini menjadi terus meningkat pada periode yang lebih penting ketika perusahaan yang sedang mengadakan percobaan dengan pendekatan pengembangan baru. Teknik yang digunakan untuk proyek harus diuraikan, capaian mereka dievaluasi, dan membuat rekomendasi. Seperti dengan bagian pada teknik manajemen, penggunaan sejarah utuk masa depan proyek sistem informasi harus dikendalikan tingkatannya dari yang detil hingga lingkupnya.
Ini adalah untuk tidak menjadikan suatu penjualan yang dilemparkan untuk favorit manager proyek teknik pengembangan baru. Suatu usaha yang harus dibuat untuk secara obyektif mengevaluasi teknik yang digunakan proyek itu dan, dimana mungkin, untuk menyarankan teknik yang bisa menjadi lebih efektiv di dalam proyek atau yang tak memuaskan itu dibuktikan. Teknik Pengembangan Evaluasi perlu menunjuk metoda dulu pendekatan tugas teknis yang utama dalam kaitannya dengan personil yang ditugaskan, teknik audit dan tinjauan ulang teknis trainning khusus, dan penggunaan disain dan peralatan pendukung pengembangan.

Bagian 5. Mempelajari
Bagian ini perlu meringkas poin-poin yang penting dari permulaan empat bagian dalam kaitannya dengan pembelajaran. Itu perlu mengidentifikasi teknik atau pendekatan membuktikan yang memuaskan terjadi dan membuktikan menjadi lebih efective. Itu perlu mengidentifikasi permasalahan penaksiran sumber daya yang ditemukan pada proyek itu. Jika ada suatu biaya yang melebihi dari yang ditentukan semula atau biaya di bawah yang telah ditentukan semula, tentang suatu kelebihan jadual, itu perlu mengidentifikasi unsur-unsur yang utama, tugas, atau kebutuhan sumber daya yang salah diperkirakan di mulainya proyek itu. Jika[di sana para subkontraktor, mengevaluasi capaian mereka, teknik manajemen, dan disain teknik perlu juga ditujukan. Bentuk serupa yang digambarkan 4.15 dapat juga digunakan untuk data pemilihan subkontraktor dengan capaian subkontraktor akan juga bermanfaat.

Bagian 6 Rekomendasi
Bagian ini perlu menyediakan rekomendasi spesifik yang akan meningkatkan perkiraan itu untuk dan capaian pada proyek masa depan yang serupa. Bagian ini dan yang sebelumnya adalah dua bagian yang paling utama dokumen sejarah proyek. Sisa dari bagian yang menyediakan dukungan detil diperlukan untuk memahami dan menerapkan pelajaran itu yang mempelajari dan merekomendasi kan untuk proyek masa depan.



Referensi
Philip Bruce, Sam M. Pederson, 1982 The Software Development Project, John Wiley and Sons, New York.
Steve McConnell, 1996, Rapid Development Taming Wild Software Schedule, Microsoft Press, Washington.
Tumar, 2002, Information System Strategic, Universitas Bina Nusantara, Jakarta.Bob Hughes and Mike Cotterell, 2002, Software Project Management, McGraw Hill, London.