Nama: Agus Indrawan

Nim: 1955201109
Kelas: B2

Bagian II Komponen kualitas perangkat lunak pra-proyek Bab 5 Peninjauan kontrak

5.1 Pendahuluan:

perayaan penyelesaian Proyek CFV Pertemuan yang menyenangkan dari tim proyek CFV di
sebuah restoran populer di pusat kota diadakan untuk merayakan keberhasilan penyelesaian
proyek 10 bulan untuk Buah dan Sayuran Carnegie, grosir produk. Sistem informasi baru
mencatat penerimaan produk dari petani, memproses pesanan klien dan menghasilkan
pengiriman ke klien (pedagang sayur dan supermarket), tagihan klien, dan menghitung
pembayaran yang dilakukan kepada petani. Anggota tim dengan bangga menekankan bahwa
proyek telah dilaksanakan secara penuh sesuai jadwal semula. Tim sangat gembira seperti
sebelumnya pagi setiap anggota telah menerima bonus bagus untuk menyelesaikan tepat
waktu. Pembicara ketiga, Wakil Presiden Keuangan perusahaan perangkat lunak, mengubah
suasana yang menyenangkan dengan menyebutkan bahwa proyek yang sangat sukses ini
telah benar-benar kehilangan sekitar $90000. Dalam sambutannya, dia memuji para
perencana untuk perkiraan yang baik dari sumber daya yang dibutuhkan untuk analisis dan
desain fase, dan untuk rencana penggunaan kembali perangkat lunak secara luas dari sistem
lain yang itu, kali ini, benar-benar disadari. “Satu-satunya fase di mana perkiraan kami gagal
adalah salah satu fase akhir proyek, instruksi klien, di mana staf klien diinstruksikan tentang
cara menggunakan sistem informasi baru. Dia sekarang tampaknya tidak ada yang membaca
bagian RFP (persyaratan untuk proposal) yang relevan dengan cukup hati-hati. Bagian ini
dinyatakan dengan agak tidak berbahaya dengan cara bahwa personel di semua cabang CFV
tempat perangkat lunak itu berada yang akan diinstal akan diinstruksikan penggunaannya
oleh pemasok perangkat lunak.” Setelah jeda singkat dia melanjutkan sebagai berikut: “Tidak
ada yang mencoba mencari tahu berapa banyak cabang klien kami beroperasi. Tidak ada yang
menyebutkan bahwa CFV beroperasi 19 cabang – enam di antaranya di luar negeri – sebelum
menandatangani kontrak!” Dia melanjutkan: “Kami mencoba menegosiasikan ulang item
anggaran instalasi dan instruksi dengan klien, tetapi klien bersikeras untuk tetap berpegang
pada kontrak asli.” Meskipun tidak ada nama yang disebutkan, jelas bahwa dia menyalahkan
penjualan tim perunding atas kerugian tersebut.
5.2 Proses peninjauan kontrak dan tahapannya

Beberapa situasi dapat menyebabkan perusahaan perangkat lunak (“pemasok”) untuk

menandatangani a kontrak dengan pelanggan. Yang paling umum adalah:

(1) Keikutsertaan dalam tender.

(2) Pengajuan proposal sesuai dengan RFP pelanggan.

(3) Penerimaan pesanan dari pelanggan perusahaan.

(4) Penerimaan permintaan atau pesanan internal dari departemen lain di organisasi. Tinjauan
kontrak adalah komponen SQA yang dirancang untuk memandu draf tinjauan proposal dan
dokumen kontrak. Jika berlaku, tinjauan kontrak juga memberikan pengawasan terhadap
kontak yang dilakukan dengan calon mitra proyek dan subkontraktor. Proses review sendiri
dilakukan dalam dua tahap: Tahap Satu – Review draft proposal sebelum diajukan ke calon
pelanggan (“peninjauan draf proposal”). Tahap ini meninjau final draft proposal dan dasar
proposal: kebutuhan pelanggan dokumen, detail tambahan pelanggan, dan penjelasan tentang
persyaratan, perkiraan biaya dan sumber daya, kontrak atau kontrak yang ada draft pemasok
dengan mitra dan subkontraktor. Tahap Dua – Review draft kontrak sebelum
penandatanganan (“contract draft tinjauan"). Tahap ini meninjau draft kontrak berdasarkan
usulan dan kesepahaman (termasuk perubahan) yang dicapai selama sesi negosiasi kontrak.

5.3 Tujuan peninjauan kontrak Seperti yang diharapkan, kedua tahap tinjauan kontrak
memiliki tujuan yang berbeda, yang kami rinci berikut ini.

5.3.1 Tujuan peninjauan draf proposal Tujuan dari tinjauan draf proposal adalah untuk
memastikan bahwa: kegiatan telah dilaksanakan dengan baik.

(1) Persyaratan pelanggan telah diklarifikasi dan didokumentasikan. Dokumen RFP dan
dokumen teknis serupa bisa jadi terlalu umum dan tidak tepat untuk tujuan proyek.
Akibatnya, detail tambahan harus diperoleh dari pelanggan. Klarifikasi persyaratan yang
tidak jelas dan pembaruannya harus dicatat dalam dokumen terpisah yang disetujui oleh
pelanggan dan perusahaan perangkat lunak.

(2) Pendekatan alternatif untuk melaksanakan proyek telah diperiksa. Seringkali, alternatif
yang menjanjikan dan cocok untuk mempresentasikan proposal belum ditinjau secara
memadai (jika ada) oleh tim proposal. Ini ketentuan mengacu terutama pada alternatif yang
mencakup penggunaan kembali perangkat lunak, dan kemitraan atau subkontrak dengan
perusahaan yang memiliki spesialisasi pengetahuan atau staf yang dapat memenuhi syarat
untuk memenuhi persyaratan proposal.

(3) Aspek formal dari hubungan antara pelanggan dan perusahaan perangkat lunak telah
ditentukan. Proposal harus mendefinisikan formalitas yang meliputi: Komunikasi pelanggan
dan saluran antarmuka Hasil proyek dan kriteria penerimaan Proses persetujuan fase formal
Desain pelanggan dan metode pengujian tindak lanjut Prosedur permintaan perubahan
pelanggan.

(4) Identifikasi risiko pembangunan. Risiko pengembangan, seperti pengetahuan profesional

yang tidak memadai mengenai bidang profesional proyek atau penggunaan pengembangan
yang diperlukan alat, perlu diidentifikasi dan diselesaikan. Untuk deskripsi komprehensif
tentang identifikasi item risiko perangkat lunak dan metode untuk risiko tindakan
pengelolaan, lihat Lampiran 6A. 5.3.2 Tujuan peninjauan draf kontrak

Tujuan dari tinjauan draf kontrak adalah untuk memastikan bahwa kegiatan berikut telah
dilakukan dengan memuaskan:

(1) Tidak ada masalah yang belum diklarifikasi yang tersisa dalam draft kontrak.

(2) Semua pemahaman yang dicapai antara pelanggan dan perusahaan harus
didokumentasikan secara lengkap dan benar dalam kontrak dan lampirannya. Ini pemahaman
dimaksudkan untuk menyelesaikan semua masalah dan perbedaan yang belum diklarifikasi
antara pelanggan dan perusahaan yang telah terungkap selama ini.

(3) Tidak ada perubahan, penambahan, atau penghilangan yang belum dibahas dan disepakati
harus dimasukkan ke dalam draft kontrak. Setiap perubahan, disengaja atau tidak, dapat
mengakibatkan tambahan yang substansial dan komitmen tak terduga dari pihak pemasok.

5.4 Pelaksanaan tinjauan kontrak Tinjauan kontrak bervariasi dalam besarnya, tergantung
pada karakteristiknya dari proyek yang diusulkan. Kompleksitas ini dapat berupa teknis atau
organisasi. Oleh karena itu, tingkat upaya profesional yang berbeda dibenarkan untuk
berbagai tinjauan kontrak. Upaya profesional khusus diperlukan untuk proposal utama. Jalan
yang direkomendasikan untuk menerapkan tinjauan kontrak utama Perencanaan yang cermat
dari tinjauan kontrak diperlukan untuk penyelesaian yang sukses. Seperti yang seharusnya
sudah jelas sekarang, ini berlaku dua kali lipat untuk kontrak besar ulasan. Direkomendasikan
bahwa langkah-langkah berikut diambil untuk memfasilitasi: proses peninjauan. Tinjauan
kontrak harus dijadwalkan. Kegiatan peninjauan kontrak harus dimasukkan dalam jadwal
persiapan proposal, menyisakan waktu yang cukup untuk peninjauan dan koreksi berikutnya
yang harus dilakukan. Sebuah tim harus melakukan tinjauan kontrak. Kerja tim
memungkinkan untuk mendistribusikan beban kerja di antara anggota tim sehingga masing-
masing anggota tim peninjau kontrak dapat menemukan waktu yang cukup untuk melakukan
tugasnya bagiannya (yang mungkin termasuk menyiapkan laporan tertulis yang merangkum
temuan dan rekomendasinya). Seorang pemimpin tim peninjau kontrak harus ditunjuk.
Penting bahwa tanggung jawab untuk mengatur, mengelola, dan mengendalikan kontrak
kegiatan tinjauan didefinisikan, lebih disukai dengan menunjuk seorang pemimpin tim. Itu
kegiatan ketua tim meliputi: – Perekrutan anggota tim – Distribusi tugas peninjauan di antara
anggota tim – Koordinasi antar anggota tim peninjau – Koordinasi antara tim review dan tim
proposal – Tindak lanjut kegiatan, terutama kesesuaian dengan jadwal – Rangkuman temuan
dan penyampaiannya kepada tim proposal.

5.5 Subyek tinjauan kontrak Tinjauan kontrak

memeriksa banyak mata pelajaran, berdasarkan tinjauan kontrak tujuan. Daftar periksa adalah
perangkat yang berguna untuk membantu tim peninjau untuk mengatur pekerjaan mereka dan
mencapai cakupan yang tinggi dari mata pelajaran yang relevan. Jelas bahwa banyak subjek
dalam daftar ini tidak relevan untuk proyek tertentu. Pada pada saat yang sama, bahkan daftar
periksa yang komprehensif dapat mengecualikan beberapa yang penting mata pelajaran yang
relevan dengan proposal proyek yang diberikan. Ini adalah tugas kontrak tim peninjau, tetapi
terutama pemimpinnya, untuk menentukan daftar subjek yang sesuai untuk proposal proyek
tertentu. Daftar subjek tinjauan kontrak, diklasifikasikan menurut tinjauan kontrak tujuan,
disajikan dalam lampiran bab ini: Lampiran 5A: Tinjauan draf proposal – daftar periksa mata
pelajaran Lampiran

5B: Tinjauan draf kontrak – daftar periksa mata pelajaran.

5.6 Tinjauan kontrak untuk proyek internal Sejumlah besar, jika bukan mayoritas, proyek
perangkat lunak bersifat internal proyek — proyek “in-house” – dilakukan oleh satu unit
organisasi untuk unit lain dari organisasi yang sama. Dalam kasus seperti itu, unit
pengembangan perangkat lunak adalah pemasok, sedangkan unit lainnya dapat dianggap
sebagai pelanggan. Proyek internal yang khas dan pelanggan internal mereka terdaftar di
Tabel 5.1. Seringkali, proyek pengembangan perangkat lunak internal tidak didasarkan pada:
apa yang akan dianggap sebagai hubungan pelanggan-pemasok yang lengkap. Di banyak
kasus, proyek ini didasarkan pada kesepakatan umum, dengan niat baik memainkan peran
penting dalam hubungan antara dua unit. Ini mengikuti bahwa unit yang sedang berkembang
hanya akan melakukan kontrak pendek dan "ringan" review, atau tidak sama sekali.
Ringkasan (1) Jelaskan dua tahap tinjauan kontrak. Peninjauan draf proposal. Tahap ini
meninjau draf proposal akhir dan dokumen yang menjadi dasarnya: dokumen pelanggan dan
detail pelanggan penjelasan tentang persyaratan, sumber daya dan perkiraan keuangan, yang
ada kontrak dengan mitra dan subkontraktor, dll. Tinjauan draf kontrak. Tahap ini meninjau
draft kontrak berdasarkan proposal dan kesepahaman yang dicapai selama negosiasi
berikutnya. (2) Buat daftar tujuan tinjauan kontrak. Tujuan dari tinjauan draf proposal adalah
untuk memastikan bahwa kegiatan berikut telah diselesaikan dengan memuaskan:
Persyaratan pelanggan telah diklarifikasi dan didokumentasikan. Alternatif untuk
melaksanakan proyek telah diperiksa. Hubungan formal dengan pelanggan telah ditentukan.
Risiko pengembangan telah diidentifikasi. Sumber daya dan jadwal untuk proyek telah
diperkirakan secara memadai. Kapasitas perusahaan untuk melaksanakan proyek telah
diperiksa. Kapasitas pelanggan untuk memenuhi komitmennya telah diperiksa. Partisipasi
mitra dan subkontraktor telah ditentukan. Hak kepemilikan telah ditetapkan dan dilindungi.

Bibliografi yang dipilih

1. ISO (1997) ISO 9000-3:1997(E), Manajemen Mutu dan Jaminan Mutu Standar – Bagian 3:
Pedoman Penerapan ISO 9001:1994 untuk Pengembangan, Pengadaan, Instalasi dan
Pemeliharaan Perangkat Lunak Komputer, 2nd edn, Organisasi Internasional untuk
Standardisasi, Jenewa.

2. ISO/IEC (2001) “ISO 9000-3:2001 Rekayasa Perangkat Lunak dan Sistem – Pedoman
Penerapan ISO 9001:2000 pada Perangkat Lunak, Final draft”, Organisasi Internasional
untuk Standardisasi (ISO), Jenewa, tidak diterbitkan draf, Desember 2001.

3. Oskarsson, O. and Glass, R. L. (1996) Pendekatan ISO 9000 untuk Bangunan Perangkat
Lunak Berkualitas, Ch. 3, Prentice Hall, Upper Saddle River, NJ.

Tinjau pertanyaan 5.1

Kasus CFV dijelaskan di awal bab ini. Dari Wakil Pidato singkat Presiden, dapat dipahami
bahwa penyusunan proposal adalah dilakukan sebagai berikut: (a) tim perunding ditunjuk
oleh manajemen, (b) proposal disiapkan oleh tim perunding, (c) disetujui manajemen
proposal sebelum disajikan kepada pelanggan, (d) manajemen ditandatangani kontrak.
(1) Dapatkah Anda menyarankan langkah-langkah yang akan mengurangi kemungkinan
kerugian yang disebabkan oleh a kontrak yang salah?

(2) Apa subjek tinjauan kontrak yang relevan, yang tercantum dalam Lampiran 5A dan 5B,
yang dapat telah mengungkapkan kesalahan kontrak yang dijelaskan dalam kasus CFV? 5.2

Daftar berbagai aspek yang terlibat dengan pemeriksaan kemampuan pelanggan. 5.3 Salah
satu tujuan dari tinjauan kontrak adalah untuk memeriksa risiko pengembangan.

(1) Buat daftar jenis risiko pembangunan yang paling umum.

(2) Kegiatan tim proposal apa yang diperlukan mengenai masing-masing pengungkapan?
risiko pembangunan?

5.4 Luasnya tinjauan kontrak tergantung pada karakteristik proyek.

(1) Mendeskripsikan proyek imajiner yang membutuhkan proses intensif dan komprehensif
tinjauan kontrak. (

2) Jelaskan proyek imajiner di mana tinjauan kontrak skala kecil akan memadai.

5.5 Melakukan review kontrak menimbulkan banyak kesulitan.

(1) Buat daftar kesulitan “terpasang” untuk melakukan tinjauan kontrak skala besar.

(2) Buat daftar langkah-langkah yang harus diambil untuk membuat tinjauan kontrak skala
besar menjadi layak. Topik untuk diskusi 5.1 MJS, Mount Jackson Systems, menandatangani
kontrak untuk mengembangkan CRM yang komprehensif (Manajemen Hubungan Pelanggan)
sistem untuk perusahaan persiapan makanan besar. Untuk memenuhi persyaratan proyek,
MJS mempekerjakan tiga orang: subkontraktor. Pengalaman MJS dengan subkontraktor
ternyata merepotkan, terutama dalam hal tidak menjaga jadwal, tingkat perangkat lunak yang
tinggi semua jenis kesalahan, dan banyak kesalahan antarmuka dengan bagian sistem yang
dikembangkan oleh pihak lain peserta dalam proyek. Kepala unit jaminan kualitas perangkat
lunak menyatakan bahwa jika unitnya telah melakukan prosedur tinjauan kontrak, sebagian
besar dijelaskan masalah akan dapat dihindari. (1) Subjek tinjauan kontrak apa yang relevan
dengan kasus ini? (2) Proses apa yang akan Anda rekomendasikan ketika menerapkan
tinjauan kontrak di kasus ini?

5.2 Seorang profesional SQA mengklaim:

“Saya menemukan semua alasan yang diberikan untuk tinjauan draf proposal untuk
dibenarkan. Saya juga percaya bahwa tinjauan berkontribusi pada kualitas proposal, terutama
dalam mengklarifikasi dan mendefinisikan persyaratan secara tepat, dan dalam
mempersiapkan perkiraan yang lebih realistis, di antara isu-isu lainnya. Namun, begitu
proposal telah disampaikan kepada pelanggan, tidak perlu ada draft kontrak tinjauan. Tugas
meninjau hasil negosiasi akhir dan versi final kontrak harus diserahkan kepada departemen
hukum dan manajemen.”

(1) Apakah Anda setuju dengan pernyataan di atas? Daftar argumen Anda.

(2) Dalam situasi apa tinjauan draf kontrak tidak diperlukan?

(3 Dalam situasi apa tinjauan draf kontrak mutlak diperlukan?

Lampiran 5A Kajian draf proposal – daftar

periksa mata pelajaran

1.Persyaratan pelanggan memiliki

1.1 Persyaratan fungsional. telah diklarifikasi dan didokumentasikan

1.2 Lingkungan operasi pelanggan (perangkat keras, sistem komunikasi data, sistem operasi,
dll).

1.3 Antarmuka yang diperlukan dengan paket perangkat lunak lain dan firmware instrumen,
dll.

1.4 Persyaratan kinerja, termasuk beban kerja seperti yang ditentukan oleh jumlah pengguna
dan karakteristik penggunaan.

1.5 Keandalan sistem.

1.6 Kegunaan sistem, sebagaimana diwujudkan dalam kebutuhan waktu pelatihan bagi
operator untuk mencapai yang dibutuhkan produktifitas. Total pelatihan dan instruksi upaya
yang harus dilakukan oleh pemasok, antara lain: jumlah peserta pelatihan dan hal-hal yang
diinstruksikan, lokasi dan durasi.

1.7 Jumlah instalasi perangkat lunak yang akan dilakukan oleh pemasok, termasuk lokasi.

1.8 Masa garansi, tingkat tanggung jawab pemasok, dan metode pemberian dukungan.

1.9 Proposal untuk penyediaan layanan pemeliharaan melampaui masa garansi, dan kondisi.
1.10 Penyelesaian semua persyaratan tender, termasuk: informasi tentang tim proyek,
sertifikasi dan dokumen lain, dll.

2. Pendekatan alternatif untuk

2.1 Mengintegrasikan perangkat lunak yang digunakan kembali dan dibeli. melaksanakan
proyek memiliki 2.2 Mitra. telah diperiksa

2.3 Komitmen pelanggan untuk melakukan in-house pengembangan beberapa tugas proyek.

2.4 Subkontraktor.

2.5 Perbandingan alternatif yang memadai.

Lampiran 5B Tinjauan draf kontrak – daftar periksa mata pelajaran 1. Tidak ada masalah
yang belum diklarifikasi yang tersisa

1.1 Kewajiban Pemasok sebagaimana didefinisikan dalam kontrak dalam draft draft kontrak
dan lampirannya.

1.2 Kewajiban Pelanggan sebagaimana didefinisikan dalam kontrak draft dan lampirannya.

2. Semua pemahaman tercapai

2.1 Pemahaman tentang fungsi proyek mengikuti persyaratan proposal. didokumentasikan

dengan benar

2.2 Pemahaman tentang masalah keuangan, termasuk: jadwal pembayaran, bonus, penalti, dll.

2.3 Pemahaman tentang kewajiban pelanggan.

2.4 Pemahaman tentang mitra dan subkontraktor kewajiban, termasuk perjanjian pemasok
dengan pihak eksternal.

3. Tidak ada perubahan “baru”, penambahan,

3.1 Rancangan kontrak selesai; tidak ada bagian kontrak atau atau kelalaian telah memasuki
lampiran yang hilang. draft kontrak

3.2 Tidak ada perubahan, kelalaian dan penambahan telah dimasukkan ke dalam dokumen
yang disepakati, mengenai masalah keuangan, jadwal proyek, atau kewajiban pelanggan dan
mitra

Bab 6 Rencana pengembangan dan kualitas

6.1 Rencana pengembangan dan tujuan rencana mutu Perencanaan,

sebagai suatu proses, memiliki beberapa tujuan, yang masing-masing dimaksudkan untuk
mempersiapkan landasan yang memadai untuk hal-hal berikut: (1) Menjadwalkan kegiatan
pengembangan yang akan mengarah pada keberhasilan dan penyelesaian proyek tepat waktu,
dan memperkirakan sumber daya dan anggaran tenaga kerja yang dibutuhkan. (2) Merekrut
anggota tim dan mengalokasikan sumber daya pengembangan (sesuai dengan jadwal kegiatan
dan perkiraan kebutuhan sumber daya tenaga kerja). (3) Menyelesaikan risiko pembangunan.
(4) Melaksanakan kegiatan SQA yang diperlukan. (5) Menyediakan manajemen dengan data
yang dibutuhkan untuk pengendalian proyek.

6.2 Elemen rencana pembangunan

Berdasarkan bahan proposal, rencana pengembangan proyek disiapkan untuk memenuhi

tujuan di atas. Unsur-unsur berikut, masing-masing berlaku untuk komponen proyek yang
berbeda, terdiri dari rencana pengembangan proyek. (1) Produk proyek Rencana
pengembangan mencakup produk-produk berikut: Dokumen desain yang menentukan tanggal
penyelesaian, yang menunjukkan itu barang yang akan dikirimkan ke pelanggan ("barang
yang dikirim") Produk perangkat lunak (menentukan tanggal penyelesaian dan lokasi
pemasangan) Tugas pelatihan (menentukan tanggal, peserta, dan lokasi). (2) Antarmuka
proyek Antarmuka proyek meliputi: Antarmuka dengan paket perangkat lunak yang ada
(antarmuka perangkat lunak) Antarmuka dengan tim pengembangan perangkat lunak
dan/atau perangkat keras lainnya yang bekerja pada sistem atau proyek yang sama (yaitu,
kerja sama dan link koordinasi) Antarmuka dengan perangkat keras yang ada (antarmuka
perangkat keras).

6.3 Elemen rencana mutu Semua atau beberapa item berikut,

tergantung pada proyek, terdiri dari: elemen dari rencana kualitas proyek: (1) Sasaran kualitas
Istilah "tujuan kualitas" mengacu pada persyaratan kualitas substantif sistem perangkat lunak
yang dikembangkan. Ukuran kuantitatif biasanya lebih disukai daripada ukuran kualitatif
ketika memilih sasaran kualitas karena mereka memberi pengembang penilaian perangkat
lunak yang lebih objektif kinerja selama proses pengembangan dan pengujian sistem. Namun,
satu jenis tujuan tidak sepenuhnya setara dengan yang lain. Kemungkinan penggantian
kualitatif dengan ukuran kuantitatif diilustrasikan dalam contoh berikut. Contoh Sebuah
sistem perangkat lunak untuk melayani operasi meja bantuan dari produsen peralatan listrik
akan dikembangkan. Sistem help desk (HDS) adalah dimaksudkan untuk beroperasi selama
100 jam per minggu. Tim penjaminan kualitas perangkat lunak diminta untuk menyiapkan
daftar sasaran kualitas kuantitatif sesuai dengan persyaratan kualitatif tertentu, seperti yang
ditunjukkan pada Tabel 6.1. 2) Kegiatan peninjauan yang direncanakan Rencana mutu harus
memberikan daftar lengkap dari semua tinjauan yang direncanakan kegiatan: tinjauan desain
(DR), inspeksi desain, inspeksi kode, dan seterusnya, dengan hal-hal berikut ditentukan untuk
setiap aktivitas: Lingkup kegiatan review Jenis kegiatan ulasan Jadwal kegiatan peninjauan
(sebagaimana ditentukan oleh prioritasnya dan kegiatan yang berhasil dari proses proyek)
Prosedur khusus yang akan diterapkan Siapa yang bertanggung jawab untuk melaksanakan
kegiatan review?

6.4 Rencana pengembangan dan kualitas

untuk proyek-proyek kecil dan untuk proyek internal Sangat wajar bagi para pemimpin
proyek untuk mencoba menghindari "kerepotan" dalam menyiapkan rencana pengembangan
dan rencana kualitas (dan hiruk pikuk di sekitar tinjauan dan persetujuan rencana). Perilaku
ini mencerminkan kecenderungan untuk menghindari "pekerjaan birokrasi" dan kontrol
menyeluruh yang mungkin dicoba oleh pelanggan Harus jelas bahwa prosedur
pengembangan dan rencana mutu yang berlaku untuk proyek-proyek besar tidak dapat secara
otomatis diterapkan pada proyek-proyek kecil. Diperlukan prosedur khusus. Prosedur-
prosedur ini menentukan cara merawat proyek yang bersangkutan sehubungan dengan
rencana: (1) Kasus/situasi di mana tidak ada pengembangan maupun rencana mutu
diperlukan, mis. proyek yang membutuhkan 15 hari kerja. (2) Kasus/situasi di mana
keputusan untuk menyiapkan rencana diserahkan kepada kebijaksanaan pemimpin proyek.
Salah satu contohnya adalah proyek yang membutuhkan lebih sedikit dari 50 hari kerja di
mana tidak ada item risiko perangkat lunak yang signifikan telah diidentifikasi – dalam hal
ini dapat diputuskan bahwa tidak ada rencana yang akan disiapkan. Contoh lain bisa berupa
proyek kecil tapi rumit yang harus diselesaikan dalam waktu 30 hari, di mana ada hukuman
berat jika tidak selesai tepat waktu. Dalam hal ini diperlukan perencanaan untuk
menanggulanginya kesulitan proyek. Ringkasan (1) Menjelaskan tujuan pengembangan dan
rencana mutu. Tujuan rencana adalah untuk memberikan dasar bagi: Penjadwalan kegiatan
pengembangan Merekrut anggota tim dan mengalokasikan fasilitas pengembangan
Menyelesaikan risiko pengembangan Menerapkan kegiatan SQA yang diperlukan
Menyediakan manajemen dengan data yang dibutuhkan untuk pengendalian proyek

Bibliografi yang dipilih

1 Barki, H., Rivard, S. dan Talbot, J. (1993). “Menuju penilaian perangkat lunak risiko
pengembangan”, Jurnal Sistem Informasi Manajemen, 10(2), 203–225.

2 Boehm, B.W. (1988). “Sebuah model spiral pengembangan dan peningkatan perangkat
lunak”, Computer, 21(5), 61–72.

3 Boehm, B.W. (1991). “Manajemen risiko perangkat lunak: prinsip dan praktik”, Perangkat
Lunak IEEE, Januari, 32–41.

4 Boehm, B.W. (1998). “Menggunakan model spiral Menang-Menang: studi kasus”,

Komputer, 31(7), 33–44.

5 Boehm, B. W. dan Ross, R. (1989). “Manajemen proyek Teori-W: prinsip dan contoh”,
IEEE Transactions on Software Engineering, 15, 902–916.

6 Institut Rekayasa Perangkat Lunak Universitas Carnegie-Mellon (1994) The Model

Kematangan Kemampuan: Pedoman untuk Meningkatkan Proses Perangkat Lunak, Addison-
Wesley, Membaca, MA.

7 Felschow, A. (1999). “Memahami Model Kematangan Kemampuan (CMM) dan peran

SQA dalam Kematangan Pengembangan Perangkat Lunak”, dalam G. G. Schulmeyer dan J.
I. McManus (eds), Handbook of Software Quality Assurance, 3rd edn, Prentice Hall, Upper
Saddle River, NJ, hlm. 329–350.

8 Hall, E. M. (1998) Mengelola Risiko – Metode untuk Sistem Perangkat Lunak

Pengembangan, Addison-Wesley, Membaca, MA.

9 Humphrey, W. S. (1989) Mengelola Proses Perangkat Lunak, Addison-Wesley, Membaca,

MA.

10 IEEE (1998) “IEEE Std 730-1998 – Standar IEEE untuk Kualitas Perangkat Lunak
Assurance Plans”, dalam Koleksi Standar Rekayasa Perangkat Lunak IEEE, The Institut
Insinyur Listrik dan Elektronik, New York,

11 IEEE (2001) “IEEE Std 1540-2001 – Standar IEEE untuk Siklus Hidup Perangkat Lunak
Proses - Manajemen Risiko”, dalam Standar Rekayasa Perangkat Lunak IEEE Koleksi,
Institut Insinyur Listrik dan Elektronik, New York.

12 ISO (1997) ISO 9000-3:1997(E), Manajemen Mutu dan Jaminan Mutu Standar –

Bagian 3: Pedoman Penerapan ISO 9001:1994

untuk Pengembangan, Pengadaan, Instalasi dan Pemeliharaan Perangkat Lunak Komputer,
2nd edn. Organisasi Internasional untuk Standardisasi (ISO), Jenewa.

Tinjau pertanyaan

6.1 Ada kesamaan yang signifikan antara tinjauan draf proposal dan rencana pengembangan.
(1) Bandingkan dokumen-dokumen ini dengan referensi mata pelajaran yang ditinjau. (2)
Bandingkan dokumen-dokumen ini dengan mengacu pada tujuan penyusunan dokumen
individu.

6.2 Rencana pengembangan dan kualitas memiliki lima tujuan. (1) Dapatkah Anda membuat
daftar tujuan? (2) Sarankan cara-cara di mana setiap tujuan berkontribusi pada penyelesaian
proyek yang berhasil dan tepat waktu.

6.3 Beberapa elemen pengembangan disertakan dalam dokumen persyaratan, namun masih
tidak disusun oleh perencana pembangunan. (1) Elemen mana dari rencana pembangunan
yang termasuk dalam kategori ini? (2) Jelaskan pentingnya mengumpulkan informasi ini dari
pelanggan dokumen. Topik

untuk diskusi

6.1 “Selama proposal disiapkan dan disetujui dengan benar, mengikuti tinjauan kontrak yang
memadai, tidak ada pembenaran untuk mengulang semua pekerjaan ini. Sumber dayanya
perkiraan dan jadwal dapat berfungsi sebagai rencana proyek. . . .” Anda sering mendengar
klaim Seperti yang ini. (1) Apakah Anda setuju dengan klaim ini? Jika tidak, sebutkan
argumen Anda yang menentangnya. (2) Menyarankan situasi di mana jelas bahwa proposal
dan materinya dapat berfungsi sebagai rencana pengembangan dan kualitas. (3) Menyarankan
situasi di mana jelas bahwa proposal dan materinya tidak dapat berfungsi sebagai rencana
pengembangan dan kualitas.

6.2 Martin Adams, seorang pemimpin proyek yang berpengalaman di David's Software Ltd,
sebuah rumah perangkat lunak berukuran sedang, telah ditunjuk sebagai pemimpin proyek
untuk pengembangan sebuah sistem perangkat lunak meja bantuan canggih untuk perawatan
peralatan rumah tangga terkemuka melayani. Ini adalah sistem help desk ke-12 yang
dikembangkan oleh departemennya pada tahun lalu tiga tahun. Lampiran 6A Risiko
pengembangan perangkat lunak dan risiko perangkat lunak pengelolaan 6A.1 Risiko
pengembangan perangkat lunak Beberapa daftar potensi risiko pengembangan perangkat
lunak ("item risiko perangkat lunak" atau SRI) disebutkan dalam literatur. Ropponen dan
Lyytinen (2000) memiliki mengklasifikasikan item risiko perangkat lunak ke dalam enam
kelas berikut: (1) Risiko penjadwalan dan waktu (2) Risiko fungsionalitas sistem (3) Risiko
subkontrak (4) Risiko manajemen persyaratan (5) Penggunaan sumber daya dan risiko kinerja
(6) Risiko manajemen personalia. Boehm dan Ross (1989) menyarankan daftar 10 item risiko
perangkat lunak utama. Tabel 6A.1 menunjukkan bagaimana daftar ini dapat diintegrasikan
dengan enam kelas risiko yang diajukan oleh Ropponen dan Lyytinen (2000). Metodologi
untuk identifikasi item risiko perangkat lunak telah ditawarkan oleh Boehm (1991), Keil et
al., (1998), Ropponen dan Lyytinen (2000), Barki et al., (1993) dan IEEE (2001). Salah satu
alat paling efektif untuk mengidentifikasi dan mengevaluasi item risiko perangkat lunak
adalah daftar periksa khusus, juga disebutkan oleh beberapa penulis 6A.2 Kegiatan dan
tindakan manajemen risiko Berbagai kegiatan dan tindakan (biasanya disebut "tindakan
manajemen risiko" atau) RMA) dapat diambil. Tujuan RMA adalah untuk mencegah risiko
perangkat lunak, untuk: mencapai identifikasi awal item risiko perangkat lunak, dan untuk
mengatasinya. Boehm dan Ross (1989), Boehm (1991), Ropponen dan Lyytinen (2000), dan
Karolak (1996), antara lain, telah menyarankan berbagai tindakan manajemen risiko (lihat
Tabel 6A.2). Tindakan manajemen risiko internal, diterapkan dalam pengembangan
perangkat lunak organisasi. Subkontrak tindakan manajemen risiko, berurusan dengan
hubungan antara pengembang perangkat lunak dan subkontraktor dan pemasoknya. Tindakan
manajemen risiko pelanggan, berurusan dengan hubungan antara pengembang perangkat
lunak dan pelanggan.