BAB X

Mengelola Kualitas
Pekerjaan yang nagus lebih baik Perkataan yang baik .
( Benjamin Franklin )

Kualitas didefinisikan oleh PMI sebagai kesesuaian dari persyaratan , spesifikasi , standar dan
kesesuaian untuk digunakan ( PMI , 2000). Bagian dari definisi ini adalah sebagian besar
kuantitatif , yaitu persyaratan , spesifikasi , dan standar (dengan asumsi bahwa tiga hal ini dengan
hati-hati dan benar terperinci ) , tetapi " kebugaran untuk penggunaan " sebagian besar kualitatif.

Karena bagian ini kualitatif dari definisi , kualitas produk yang merupakan subyek dari proyek
mungkin menjadi daerah konflik potensial antara melakukan organisasi dan manfaat organisasi .
Bahkan , sebagai hasil proyek , kualitas adalah daerah yang paling sulit untuk terus melacak ,
bukan karena kompleksitasnya , tetapi karena tim proyek dapat membahayakan ketika krisis
timbul ( Hallows , 1998) .

Manajemen kualitas
Kualitas lebih dari sekedar kesesuaian dari persyaratan. Satu set yang baik dari persyaratan
seringkali sulit dirancang untuk sistem IT . Jika ada cacat dalam persyaratan (yang ada biasanya),
salah satunya bisa dibayangkan bila memiliki sistem berkualitas tinggi yang tidak berguna . Selain
itu, hanya memenuhi persyaratan tidak akan menjamin bahwa pelanggan atau pengguna akhir
puas dengan produk. Kualitas juga harus dibedakan dari kelas. Sebuah produk kelas rendah
mungkin sama banyak kualitas sebagai produk bermutu tinggi. Nilai yang berbeda dari produk
umumnya dibuat untuk kelas pelayanan yang berbeda, dan mereka umumnya memiliki harga
satuan yang berbeda .

Kebanyakan orang berpikir bug ketika mereka berpikir tentang kualitas dalam konteks sistem TI.
Bug Istilah ini awalnya diciptakan oleh Dr Grace Hopper, orang yang mengembangkan bahasa
COBOL. Dia telah menemukan bahwa komputer dapat crash karena bug yang bersarang di dalam
perangkat keras. Untuk sistem IT besar 1.000 fungsi poin atau lebih, jumlah cacat rata-rata adalah
lima bug per titik fungsi (Jones, 1994). Bahkan dengan pengembangan perangkat lunak
berkualitas tinggi, untuk setiap 500 atau lebih baris seperti kode prosedural-C pasti ada satu bug
didalamnys (Linger, 1994 ). Pisau cukur listrik Anda memiliki puluhan bug, TV Anda mungkin
memiliki ratusan bug dan mobil Anda mungkin memiliki ribuan bug. Sebagian besar bug ini
ditemui hanya ketika satu set keadaan tertentu yang tampak. Software bug berbiaya sebesar $60
miliar per tahun, seperti yang diperkirakan oleh Institut Nasional Standar dan Teknologi. Dari
sumber melaporkan bahwa Microsoft Windows 2000 dirilis dengan 63.000 potensial cacat
(Foley, 2000; ZDNet , 2000). Software bug meningkat jumlahnya di dunia modern kita sebagai
ketergantungan kita dalam memperdalam IT dan ketergantungan kita pada otomatisasi dan
perangkat lunak semakin berkembang.

Selain bug, bagaimanapun, definisi dasar dari kualitas yang perlu diperpanjang ketika kita
mempertimbangkan kriteria penyelesaian dan kriteria kepuasan. Definisi yang lebih lengkap dari
kualitas untuk proyek-proyek IT mencakup :
• Sesuai dengan persyaratan dan spesifikasi
• Memenuhi " harapan pelanggan "
• Apakah bebas cacat
• Apakah sangat digunakan
• Apakah sesuai dengan standar yang diadopsi
• Apakah reliabilitas (apakah itu dilakukan dengan benar sepanjang waktu)
• Apakah kuat (dapat menangani kesalahan/data yang tidak biasa dan digunakan)
• Apakah diuji
• Apakah bisa di audit
• Apakah bisa dirawat dan bisa dibaca
• Apakah aman
• Apakah dapat di dipulihkan
• Apakah tepat didokumentasikan ( eksternal dan internal)
• Apakah efisien ( sehubungan dengan kecepatan , penyimpanan , klik, keystrokes , dan sumber
daya lainnya )
• Apakah platform independen ( portabilitas )
• Apakah fleksibel dan mudah beradaptasi

Daftar yang kurang spesifik tetapi atribut resmi kualitas ditemukan dalam IEEE 83 : portabilitas,
keandalan, efisiensi, akurasi, kesalahan, ketahanan, kebenaran. Daftar lain atribut resmi kualitas
ditemukan dalam ISO 9126 : fungsionalitas, keandalan, kegunaan, efisiensi, pemeliharaan, dan
kinerja .

Kualitas buruk dapat mengakibatkan sejumlah kejadian yang tidak diinginkan dan sebagainya,
termasuk peningkatan biaya, moral yang rendah baik dalam pertunjukan dan organisasi
menguntungkan, kepuasan pemangku kepentingan yang lebih rendah, peningkatan risiko,
kehilangan bisnis, dan keuntungan bisnis proyek yang lebih rendah, sedangkan memenuhi
standar kualitas umumnya hasil peningkatan moral, risiko lebih rendah, kepuasan pemangku
kepentingan yang lebih tinggi, dan harapan manfaat proyek pertemuan. Kualitas dalam proyek TI
memiliki efek jangka panjang. Kadang-kadang efek kualitas yang buruk tidak dapat melihat baik
sampai dengan produk IT dibangun dan disebarkan. Seringkali, produk IT dilakukan dengan cara
yang memuaskan tetapi mungkin tidak terkelola secara ekonomi atau teradaptasi. Untuk proyek
IT yang sukses (dan perlu diingat bahwa sebagian besar proyek TI bisa tidak berhasil), sebagian
besar biaya jangka panjang akan berada dalam fase pemeliharaan ( sekitar dua - pertiga dari biaya
siklus hidup ) .

Sebuah PM perlu memahami apa yang terlihat dan terasa seperti kualitas untuk nya proyek . Hal
ini dapat menjadi bencana jika PM dari proyek TI tidak mengerti bagaimana kualitas
memanifestasikan dirinya di daerah aplikasi untuk proyek! Anggota tim perlu pemahaman yang
sama dan penghargaan dan jika kurang pelatihan yang sesuai harus disediakan . Manajemen mutu
adalah keseluruhan proses yang diperlukan untuk memastikan bahwa metrik kualitas IT di atas
tercapai; Proses keseluruhan ini meliputi tiga subproses berikut : perencanaan mutu, jaminan
kualitas dan kontrol kualitas. Gambar 10.1 mendefinisikan tiga proses (PMI, 2000).

Perencanaan kualitas
Fokus utama pada kualitas yang digunakan untuk inspeksi produk yang terlibat (memeriksa
barang setelah pembangunan) . Deming (1982 ) dan lain-lain menunjukkan bahwa kualitas dapat
lebih ditingkatkan dengan langkah-langkah pencegahan seperti meningkatkan proses produksi
dan bukan oleh pascaproduksi inspeksi. Dengan munculnya filsafat modern kualitas, perusahaan
telah mulai menghabiskan lebih banyak pada perencanaan dan pencegahan. Ditemukan bahwa
biaya yang digunakan untuk pencegahan kurang dari biaya kualitas yang tidaksesuai. Sebuah
aturan praktis menyatakan bahwa untuk setiap dolar yang dihabiskan untuk pencegahan , biaya
perbaikan dikurangi dengan $3 sampai $10 (Jones, 1994). Seringkali , manajemen kurang peduli
dengan pencegahan, karena pemecahan masalah adalah upaya visibilitas tinggi dengan hadiah
langsung, sedangkan pencegahan masalah memiliki visibilitas rendah. Kedua kesesuaian dan
tidaksesuai biaya yang dikenakan; masalah biaya yang berbeda dari masing-masing ditunjukkan
pada Gambar 10.2 . Dengan demikian, total biaya yang terlibat dengan kualitas dapat dinyatakan
sebagai (Campenella, 1999; Crosby, 1979) :
Figure 10.1. Quality processes

Perencanaan kualitas lengkap terdiri dari desain dan rencana untuk tindakan pencegahan (built-
in kualitas) dan pengujian produk .

Biaya ketidaksesuaian diklasifikasikan sebagai internal atau eksternal. Biaya internal yang timbul
ketika organisasi menemukan cacat dan biaya eksternal yang timbul ketika organisasi yamg
melaksanakan menemukan cacat. Biaya eksternal biasanya lebih besar dari intern. Biaya
memperbaiki kerusakan dalam sistem IT adalah fungsi ketika cacat diperlihatkan dan ketika
cacat ditemukan. Cacat diperlihatkan di awal dan di akhir ditemukan dalam proses pembangunan
yang paling mahal untuk diperbaiki. Pertimbangkan metodologi contoh pada Gambar 10.3 untuk
mengembangkan aplikasi Web. Cacat diperkenalkan dalam tahap persyaratan, namun tidak
ditemukan sampai penyebaran mungkin berarti bahwa semua langkah intervensi harus diulang
dalam beberapa derajat. Cacat diperkenalkan selama pengembangan program (bug
pemrograman) dan ditemukan selama pengujian integrasi akan membutuhkan pengulangan
langkah-langkah yang jauh lebih sedikit .

Figure 10.2. Cost of conformance and nonconformance

Figure 10.3. Web application development methodology

Cacat pada umumnya dapat ditelusuri dari lima asal (Jones, 1994) : persyaratan , desain , coding,
dokumentasi dan buruknya perbaikan. Hal ini dapat dikenakan biaya 40 sampai 1.000 kali lebih
untuk memperbaiki cacat yang ditemukan akhir dalam siklus pengembangan (Gause & Weinberg,
1989). Hingga delapan puluh persen waktu pengembangan produk perangkat lunak khas
mungkin dihabiskan mengoreksi kesalahan tidak ditemukan di awal proyek (McConnell, 1997).
Di Department Pertahanan US ( DoD ) Studi yang dilakukan oleh Hughes, ditemukan bahwa biaya
100 kali lebih untuk memperbaiki masalah yang tidak diakui sampai aplikasi dirilis. Sejumlah
besar kesalahan yang tidak ditemukan sampai produk dirilis dan dimasukkan ke dalam
penggunaan umum (sekitar 22 %) dan sebagian besar kesalahan yang diperlihatkan dalam
definisi / tahap persyaratan (sekitar 55 %). Ketika cacat akhirnya diperbaiki, ada perubahan 40%
bahwa kesalahan lainnya diperlihatkan secara tidak sengaja (untuk perangkat lunak yang bukan-
objekorientasi). Dengan demikian, fokus awal untuk kualitas proyek TI harus pada pencegahan
atau kualitas built-in / bawaan. Membangun kualitas melibatkan penetapan prosedur ketat yang
ditetapkan untuk bagaimana sesuatu dibangun atau dirakit. Disiplin rekayasa perangkat lunak
sebagian besar berkaitan dengan topik ini dan ini dibahas dalam sebuah bab buku sebelumnya.
Untuk sistem IT, dimensi ini kualitas memanifestasikan dirinya terutama melalui : standar IT ,
persyaratan teknik, teknik desain, teknik pelaksanaan dan pemeliharaan, kemampuan
beradaptasi dan metode penggunaan kembali. Jones mengumpulkan daftar software teknik
pencegahan cacat primer seperti ( Jones , 1994) :
• rencana mutu Formal
• Penggunaan pengembangan aplikasi bersama ( JAD )
• Penggunaan prototyping
• analisis terstruktur dan desain teknik
• Kode Reusable dan desain
• tim jaminan kualitas Software
• manajemen mutu total ( TQM ) metode
• Kualitas fungsi penyebaran ( QFD ) metode
• " Kamar yang bersih" metode pengembangan
• Program Pengukuran Kualitas
• Ulasan dan inspeksi
• Penggunaan estimasi cacat dan alat pengukuran

Verifikasi dan validasi Istilah ( V & V ) telah muncul dalam beberapa tahun terakhir dan telah
diterapkan untuk proyek-proyek pengembangan perangkat lunak ; IEEE 1012-1998 adalah
standar baru untuk V & V. Definisi dari perspektif TI berbeda antara penulis mengenai kegiatan
proyek adalah kegiatan verifikasi dan yang mana kegiatan validasi; dan beberapa jenis kegiatan
memiliki keduanya. Secara formal, verifikasi adalah bukti kepatuhan dengan
persyaratan , spesifikasi dan standar. Verifikasi terutama berkaitan dengan built -in kualitas dan
proses-relasi yang mengajukan pertanyaan, " Apakah kita membangun produk dengan cara yang
benar ?" untuk menjawab pertanyaan dibutuhkan baik itu pengujian internal produk dan inspeksi
proses. Untuk proyek TI, pemeriksaan melibatkan terutama desain penelusuran, penelusuran
kode dan metode dan alat yang produk yang benar yang sedang dibangun. Prosedur ini
melibatkan organisasi pendapatan manfaat dan pemangku kepentingan lain yang lebih erat
terlibat dalam review manifestasi produk awal ; metodologi ini dibahas secara rinci nanti dalam
bab ini.

Sebuah bagian dari upaya untuk membangun kualitas untuk sistem TI adalah untuk
mengidentifikasi area masalah kualitas utama dan kemudian menemukan akar penyebab
masalah ini. Pareto chart adalah diagram rekayasa kualitas klasik yang membantu perhatian
fokus pada masalah yang paling penting dari sebuah proyek dengan menyajikan informasi dalam
urutan prioritas ; ini diilustrasikan pada Gambar 10.4 . Filosofi ini didasarkan pada 80 /20 ( 80 %
masalah datang dari 20% kegiatan). Untuk seorang PM, daripada memecahkan setiap masalah
secepat itu terjadi, diagram Pareto membantu menempatkan masalah dalam perspektif sehingga
waktu seorang PM dapat difokuskan pertama pada isu-isu kunci .
Figure 10.4. Pareto chart

Jaminan Kualitas
Jaminan kualitas dilakukan terutama selama pelaksanaan proyek. Sistem pengukuran yang
direcanakan adalah analisis untuk melihat apakah semua pengukuran yang diperlukan atau jika
pengukuran yang lebih perlu dibentuk. Kinerja proyek keseluruhan secara teratur dianalisis
untuk memastikan proyek ini akan memenuhi standar kualitas yang diperlukan. Untuk proyek-
proyek TI, metrik kualitas harus didefinisikan dalam tiga bidang : proses , produk, dan persepsi ;
tiga bidang ini harus mencakup faktor penentu keberhasilan diidentifikasi sebelumnya dalam
buku ini. Untuk IT maturity model seperti model SEI CMM, tingkat kematangan melibatkan
peningkatan baik produk dan proses membangun produk . Pengendalian proyek ditutupi dalam
Bab IX, dan beberapa metrik kontrol diidentifikasi dan dibahas dalam bab itu yang juga terkait
kualitas dan ditampilkan dan diklasifikasikan dalam Gambar 10.5 . Serta produk dan kualitas
proses metrik , beberapa metrik melibatkan faktor lingkungan di mana produk tersebut akan
dikerahkan.

Figure 10.5. IT quality metrics

Produk yang merupakan subjek dari proyek TI juga mungkin perlu untuk memenuhi perjanjian
tingkat layanan tertentu ( SLA ), yang bahkan bisa menjadi bagian dari kontrak proyek. Sebuah
SLA khusus mendefinisikan " kualitas " dari layanan yang akan diberikan oleh produk dalam
lingkungan penyebaran tertentu. Item yanga biasa ditemukan di SLA adalah :
• Response time batas atas
• Persentase log - in atau panggilan tidak terjawab pertama kalinya
• persentase maksimum Downtime (yaitu , " 99 % uptime " )
• Interval downtime maksimum

Rekayasa Perangkat Lunak Institute ( SEI , www.sei.cmu.edu / cmm ) CMM mendefinisikan

Tingkat memerlukan 2 praktik untuk jaminan kualitas perangkat lunak :
• Apakah aktivitas jaminan kualitas yang direncanakan ?
• Apakah kegiatan ini memberikan verifikasi obyektif bahwa produk perangkat lunak dan
kegiatan mematuhi standar dan kebutuhan ?
• Apakah hasil tinjauan kualitas dan audit diberikan kepada pihak yang terkena dampak ?
• Apakah masalah ketidakpatuhan yang tidak diselesaikan dalam alamat proyek oleh manajemen
atas ?
• Apakah proyek mengikuti kebijakan tertulis untuk pelaksanaan penjaminan mutu ?
• Apakah sumber daya yang memadai disediakan untuk melakukan kegiatan jaminan kualitas ?
• Apakah pengukuran yang digunakan untuk menentukan biaya dan jadwal status kegiatan
jaminan kualitas ?
• Apakah kegiatan terakhir ini secara teratur dengan manajemen atas ?

Kontrol Kualitas
Kontrol kualitas melibatkan analisis pengukuran, perbandingan dengan rencana dan pengambil
tindakan korektif jika diperlukan, seperti menghilangkan penyebab kinerja yang tidak
memuaskan. Analisis pengukuran biasanya melibatkan alat kontrol kualitas, seperti metode
statistik, diagram kontrol, analisis trend dan metode flowcharting lainnya .

Analisis Trend juga mungkin melibatkan penggunaan teknik matematika untuk peramalan hasil
di masa depan berdasarkan nilai-nilai sejarah. Analisis Trend sering digunakan dalam proyek-
proyek TI untuk memantau metrik kinerja teknis, seperti bagaimana mungkin cacat telah
diperkenalkan dan terdeteksi dan di mana tahapan proyek . Menemukan banyak cacat pada tahap
selanjutnya seperti tes integrasi atau pengujian penerimaan pengguna merupakan indikasi dari
masalah kualitas awal dalam analisis atau desain. Hal ini diilustrasikan pada Gambar 10.6 .
Gambar 10.7 menunjukkan jenis lain yang berguna dari grafik tren yang kumulatif terjadinya
cacat dan koreksi. Untuk jenis analisis, satu harapan untuk melihat kesenjangan antara kumulatif

Figure 10.6. Defects introduced and found

Figure 10.7. Cumulative defects

cacat yang ditemukan dan akhir perbaikan cacat dikumulatif sebagai hasil proyek. Jika
kesenjangan (antara dua kurva) menjadi lebih luas, maka ada masalah dalam ketepatan
perbaikan waktu untuk cacat. Sebuah teknik yang sangat berguna untuk menemukan
akar penyebab dari proyek adalah Ishikawa atau diagram Fishbone (juga disebut
diagram sebab-akibat). Diagram ini menunjukkan bagaimana berbagai penyebab atau
potensial penyebab (dan subcauses mereka) berhubungan dengan menyebabkan
masalah secara keseluruhan. Diagram ini juga membantu merangsang pemikiran tim
proyek. Gambar 10.8 menunjukkan jenis diagram untuk masalah yang terlibat dengan
analisis kebutuhan.
Figure 10.8. Requirements cause and effect diagram

Gambar 10.9 menunjukkan diagram lain dari jenis ini untuk menganalisis masalah cacat
perangkat lunak. Jones (1994) daftar delapan akar penyebab masalah kualitas sebagai:
• Kurangnya pemahaman tentang kualitas apa yang berarti untuk perangkat lunak
• pencegahan cacat yang tidak memadai
• Penggunaan yang tidak memadai ulasan dan inspeksi
• Kurangnya pengujian atau ceroboh
• Kurangnya pengukuran kualitas
• Kurangnya pemahaman oleh manajemen proyek yang berkualitas sangat penting untuk metrik
penyelesaian dan kepuasan pengguna
• tekanan jadwal yang berlebihan yang mengarah kepada upaya yang mengurangi kualitas
• kebutuhan pengguna yang tidak stabil dan ambigu

Seringkali, audit kualitas rinci dan terstruktur dilakukan setelah selesai proyek untuk
mengevaluasi rekayasa perangkat lunak dan proses manajemen proyek dalam kaitannya dengan
aspek kualitas, dan ini menjadi bagian dari proyek pelajaran-belajar dokumentasi.
Figure 10.9. Defects cause and effect diagram

Pengujian Perangkat Lunak

Teknik untuk membangun kualitas ke dalam sistem perangkat lunak telah cukup berhasil selama
beberapa dekade terakhir. Rata-rata software cacat menurun dari sekitar 8 per KLOC ( seribu
baris kode ) pada tahun 1970 untuk 5 per KLOC pada tahun 1990 ( “ Kualitas Imperatif " 1991) .
Namun, ketika perangkat lunak dibuat dengan menggunakan metodologi paling ketat dan
standar kualitas ( dapat memproduksi 1 atau 2 cacat per KLOC ), masih akan ada sejumlah besar
cacat pada produk sebelum pengujian. Software pengujian dan koreksi cacat biasanya
membutuhkan waktu antara 30 % sampai 60 % dari waktu pengembangan proyek dan anggaran.
Perkembangan aplikasi yang kompleks dapat menghabiskan lebih dari setengah dari total usaha
program mereka pada pengujian . Ketika krisis waktu muncul dalam suatu proyek , seringkali
pengujian penuh produk dikompromikan. Aturan yang berlaku umum adalah bahwa biaya
pengujian akan 25 % dari total biaya pengembangan ( Brown , 1998) .

Mungkin ada kalanya pengujian tidak diperlukan ; Software Manajer Program Jaringan telah
mengidentifikasi keadaan ini ( Brown , 1998) :
• Ketika tanggung jawab atas kegagalan bisa digeser ke orang lain
• Ketika dampak atau makna dari masalah tidak signifikan
• Ketika perangkat lunak tidak harus bekerja
• Bila tidak ada yang sedang atau akan menggunakan sistem
• Ketika proyek telah gagal
Figure 10.10. IEEE standard for software unit testing

Pengujian harus menjadi proses yang bertingkat dengan berbagai jenis pengujian dalam berbagai
tahap proyek. Pengujian single stage memiliki keefektifan sekitar 30 %, tetapi pengujian
bertingkat dapat mencapai efisiensi jauh lebih tinggi ( Jones , 1994). Pengujian juga harus
dimasukkan kedalam komponen software yang akan dibeli atau diperoleh .

Unit pengujian biasanya dilakukan oleh para pengembang dan merupakan proses untuk
memastikan bahwa setiap modul software melakukan dengan independen relatif baik dari modul
lainnya. Operasi input , output, dan antarmuka biasanya disimulasikan. Unit pengujian biasanya
sebagian besar menggunakan white-box ( " struktural " ) pengujian pengetahuan tentang modul
internal digunakan untuk memastikan bahwa setiap pernyataan kode sumber dan path melalui
kode tersebut dilakukan, mungkin sebagai fungsi dari kondisi eksternal dan database yang
berbeda. Seringkali, pemanfaatan tes yang diciptakan untuk setiap modul, merupakan
serangkaian tes khusus untuk modul tersebut. Pemanfaatan ini diperiksa ke dalam sistem kontrol
versi Kode sumber dan mereka biasanya secara otomatis diulang untuk setiap perubahan ke
modul tersebut. Untuk rekayasa perangkat lunak Cleanroom dibahas
sebelumnya dalam buku ini , unit testing tidak dilakukan oleh coders tetapi oleh penguji terpisah;
coders mereview kode orang lain dan berjalan melalui jalur eksekusi. Manfaat ekonomi dari
pendekatan ini ruang bersih untuk unit testing bisa diperdebatkan. Pengujian unit modul
biasanya termasuk dalam struktur rincian kerja ( WBS ) tugas untuk membangun modul itu.

Pengujian integrasi melibatkan pengujian seluruh sistem bekerja sama ; ini sering disebut " end-
to -end " atau tes sistem . Jenis pengujian tidak harus dilakukan oleh pengembang , tetapi oleh
kelompok pengujian independen . Proyek WBS harus memiliki kode WBS terpisah ( s ) untuk
pengujian integrasi . Proses pengujian ini biasanya terdiri dari tiga tahap : perencanaan , uji set
konstruksi , dan pelaksanaan tes . Gambar 10.10 dari IEEE Standard for Software Unit Testing (
IEEE / ANSI STD 1008, 2002) menggambarkan tiga tahap pengujian ini .

Kegiatan dalam setiap tahap meliputi ( IEEE / ANSI STD 1008, 2002) :
• Perencanaan Tes
Rencanakan pendekatan umum
Sumber daya rencana dan jadwal
Tentukan lingkungan pengujian ( s )
Tentukan fitur yang akan diuji
Memperbaiki rencana umum
• Uji set konstruksi
Desain set tes dan prosedur terkait
Menerapkan desain itu ( membangun script test)
• Pengujian
Jalankan set uji
Periksa perilaku yang benar dan hasil
Mengevaluasi hasil tes , usaha, dan metrik lainnya yang relevan
hasil dokumen

Sebuah dokumen rencana uji biasanya dihasilkan tidak hanya untuk kelompok pengujian , tetapi
juga untuk dibaca oleh pemangku kepentingan lainnya . Ini akan mencakup item seperti :
• Identifikasi produk IT dan versi
• Latar belakang dari produk / versi termasuk tujuan
• Sebelum versi termasuk riwayat revisi
• Tujuan dan sasaran pengujian ini
• Referensi ke dokumen lain produk ( misalnya , persyaratan , desain, dll )• Standar yang relevan
• Tim proyek dan pemangku kepentingan identifikasi dan info kontak
• Info Uji kontak organisasi
• sumber daya Test ( orang , pelatihan , akses ke orang lain , hardware , ruang, dll )
• Uji lingkungan ( s ) , platform , lokasi , dan kondisi
• Asumsi dan dependensi
• Tes lingkup dan fokus
• Hubungan dengan kegiatan validasi lainnya
• garis Pengujian
Data pengujian dan setup lainnya
uji metrik
alat pengujian
skrip uji
• prosedur pengujian Detil
• Uji pelaporan , dokumentasi , kiriman

Bagian penting dari proses pengujian ini adalah pembangunan set tes , kadang-kadang disebut
skrip uji. Script pengujian harus didasarkan pada persyaratan produk baik secara langsung atau
melalui skenario kasus penggunaan dan storyboard ( desain layar atau " prototipe kertas " ) ; ini
diilustrasikan pada Gambar 10.11 . Jika script tes diambil dari skenario use case , maka
kemungkinan jauh lebih besar bahwa pengujian akan melibatkan fitur dan jalur kode yang lebih
penting untuk pelanggan . Pengujian itu mahal, jadi kita tidak ingin membuang waktu fitur
pengujian bahwa tidak ada yang akan menggunakan atau peduli sedikit tentang . Namun, jika
script tes tidak diambil langsung dari persyaratan , masih perlu cek bahwa setiap persyaratan
termasuk di suatu tempat di skrip uji ( persyaratan traceability
telah dibahas sebelumnya dalam buku ini ) .

Script tes ini menunjukkan secara khusus bagaimana produk tersebut akan diuji dan apa hasil
yang diharapkan berada pada setiap titik dalam ujian . Sebagai contoh, dalam pengujian formulir
untuk menambahkan sebuah entitas baru ke database , script akan menunjukkan dengan tepat
apa yang harus diketik ke masing-masing bidang pada formulir , termasuk mengetik entri yang
tidak valid (untuk mana produk harus memberikan pesan kesalahan yang berarti ) . Dalam
hubungannya dengan generasi skrip tes , mungkin ada kebutuhan untuk menghasilkan data uji .
Situasi yang ideal adalah memiliki data uji dibuat sebagai bagian dari menjalankan skrip tes
sebelumnya . Namun, untuk memungkinkan lebih banyak pengujian secara paralel , data tes
mungkin perlu dibuat sebelum menjalankan skrip uji; juga , untuk pengujian volume, sejumlah
besar data mungkin perlu dihasilkan . Lingkungan pengujian juga harus ditentukan dan diatur,
dan lingkungan ini mungkin melibatkan satu atau lebih platform pada server dan sisi client .
Sebagai contoh, dalam membangun aplikasi Web modern, seseorang mungkin perlu untuk
menguji
Figure 10.11. Requirements-based testing

menggunakan kedua Microsoft dan Unix / Linux jenis server , mungkin dari vendor yang berbeda
dan versi ; dan satu mungkin perlu untuk menguji menggunakan beberapa konfigurasi client (
jenis peramban , versi browser , ukuran layar / resolusi , dan PC / MAC ) . Menjalankan skrip uji
sering dapat otomatis oleh program langsung atau dengan menggunakan produk software -
pengujian ; ini dibahas kemudian dalam bab ini . Ketika menjalankan skrip uji , setiap kegagalan ,
cacat , standar deviasi , kekhawatiran , atau saran untuk perbaikan harus dicatat dalam
dokumentasi pengujian . Kegagalan mungkin timbul dari sejumlah penyebab , dan rencana uji
harus menunjukkan prosedur untuk menangani masing-masing penyebab ini :
• Sebuah kesalahan dalam script tes
• Sebuah kesalahan dalam data pengujian ( termasuk meta data [ table / view definisi , kendala ,
dll ] )
• kesalahan A di lingkungan pengujian
• Sebuah kesalahan dalam pelaksanaannya (yaitu , coding bug )
• Sebuah kesalahan dalam algoritma
• Sebuah kesalahan dalam desain
• Sebuah kesalahpahaman dari kebutuhan

The ANSI / IEEE STD 829-1983 IEEE Standard for Software Test Dokumentasi adalah standar
untuk dokumentasi yang dihasilkan dalam tahap pengujian . Untuk setiap kegagalan,
dokumentasi rinci harus diproduksi yang akan mencakup item seperti :
• Nama produk dan versi
• Lokasi cacat dalam produk
• Lingkungan dan info Platform
• Info pengolahan terkait ( kondisi database, dll )
• Ditugaskan / nomor ID cacat yang dihasilkan
• Tanggal / waktu
• Status ( baru , sebelumnya , dll )
• Informasi lengkap tentang kegagalan ( termasuk screen shot , dll )
• Bagaimana untuk mereproduksi masalah ( jika direproduksi sebagai lawan dari " random " )
• Perkiraan keparahan masalah
• Penyebab cacat ( jika diketahui atau dicurigai )
• Info Tester ( nama , kontak, organisasi , dll )
Ketika cacat dianggap tetap dan / atau menetap, informasi yang akan ditambahkan ke catatan
tersebut (tes ulang info, status, dll) . Ketika pengembang menunjukkan bahwa cacat telah
diperbaiki , ada kebutuhan untuk menguji ulang . Koreksi Cacat ( dan mungkin perubahan lain
yang diminta ) umumnya " batched " bersama-sama untuk menghasilkan versi baru dari produk
perangkat lunak . Pengujian integrasi / system kemudian diulang untuk versi baru . Proses
pengujian ulang ini disebut " pengujian regresi , " dan isu kunci adalah berapa banyak dari script
pengujian awal harus diulang . Satu hanya dapat mengulangi hanya tes untuk fitur baru dan
orang-orang yang menghasilkan cacat pada versi sebelumnya , atau sebaliknya, menjalankan
semua tes lagi . Setiap memperbaiki yang tidak dapat memperbaiki cacat (atau sebagian benar) ,
tetapi juga dapat memperkenalkan cacat lainnya . Pilihan paling aman karena itu akan
menjalankan semua tes lagi ; ini sering bukan pilihan yang layak dalam hal waktu dan biaya ,
kecuali pengujian telah jauh otomatis .

Setelah pengujian integrasi , yang berfokus pada fitur , mungkin ada pengujian terpisah untuk
beban , skalabilitas , dan waktu . Timing mungkin merupakan fungsi dari beban untuk langkah-
langkah " jam dinding " penyelesaian atau waktu respon , atau dapat diukur dalam jumlah " klik "
atau " keystrokes " diperlukan untuk menyelesaikan tugas . Jenis tes mungkin diperlukan untuk
memastikan kepatuhan dengan SLA selama operasi produksi . Pengujian destruktif juga dapat
dilakukan secara terpisah atau dalam hubungannya dengan pengujian integrasi . Sebuah jumlah
tertentu dari pengujian destruktif harus dimasukkan di kedua pengujian unit dan pengujian
integrasi seperti efek dari masukan pengguna tidak benar atau hilang . Dalam pengujian
destruktif , seseorang mencoba untuk menghancurkan atau kompromi integritas sistem melalui
kesalahan input, kesalahan penggunaan , melaksanakan fitur dari urutan , melanggar langkah-
langkah keamanan , dan sengaja menipu sistem. Kebanyakan pengujian integrasi menggunakan
black-box ( perilaku ) pengujian , di mana hanya spesifikasi eksternal dari produk yang digunakan
. Namun, pengujian destruktif mungkin melibatkan jenis " white-box " pengujian , di mana
pengetahuan tentang internal modul digunakan .

Tes auditability terpisah juga dapat dijalankan terutama untuk aplikasi bisnis di mana kedua
maju dan mundur traceability diuji . Teruskan tracing mengikuti masuknya transaksi melalui
sistem untuk mana ia diposting ke account / total entitas . Reverse tracing mengambil total
account dan bekerja mundur untuk menampilkan transaksi yang membentuk total rekening .

Pengujian penerimaan , yang melibatkan organisasi menguntungkan (yaitu , pelanggan ) , sering

dilakukan setelah pengujian integrasi . Kontrak proyek mungkin akan meminta pengujian
penerimaan dilakukan ; Pengujian ini kadang-kadang dilakukan secara eksklusif oleh organisasi
menguntungkan . Biasanya , pengujian penerimaan diimplementasikan pada skala yang lebih
kecil dari pengujian integrasi , dan itu merupakan contoh dari fitur dan kondisi . Setelah ( atau
bukan ) pengujian penerimaan , produk mungkin dihasilkan untuk pengujian alpha untuk
digunakan dengan seperangkat terbatas ramah pengguna . Jika pengujian alpha berhasil ,

Pengujian beta diimplementasikan , yang melibatkan kelompok yang lebih besar dan tidak selalu
ramah . Beta testing , yang melibatkan banyak pengguna (yaitu , 1.000 atau lebih ) , dapat
mencapai efisiensi pengujian sekitar 75 % ( Jones , 1994) .

Perangkat Lunak Manajer Program Jaringan mendefinisikan delapan tingkat pengujian perangkat
lunak dari kotak putih- unit testing melalui situs akhir black-box testing produksi ( Brown , 1998).
Setiap tingkat memiliki fokus , tanggung jawab organisasi , dasar dokumentasi , jenis tes , dan
kegiatan uji. 10 perintah pengujian adalah sebagai berikut :
1 . Tes Black- box yang memvalidasi persyaratan harus melacak dengan spesifikasi yang disetujui
dan dilaksanakan oleh organisasi + + independen
2 . Uji tingkat harus diintegrasikan ke dalam struktur yang konsisten.
3. Jangan melewatkan tingkat untuk menghemat waktu atau sumber daya ; menguji kurang di
setiap tingkat 4 . Semua produk tes, konfigurasi , alat , data, dan sebagainya , perlu konfigurasi
(versi ) Kontrol

5 . Uji Selalu prosedur

6 . Perubahan harus dikelola
7 . Pengujian harus dijadwalkan , dipantau , dan dikendalikan
8 . Semua kasus uji harus melacak sesuatu yang berada di bawah konfigurasi (versi ) Kontrol
9 . Anda tidak akan kehabisan sumber daya
10 . Selalu tentukan dan menguji kriteria

Ekstrim pemrograman ( XP ) telah dibahas sebelumnya dalam buku ini , dan pengujian ekstrem
adalah bagian penting dari itu metodologi XP . Pengembang diharapkan dapat menulis skrip tes
unit pertama sebelum aplikasi dibangun . Script tes berada di bawah kontrol sumber ( kontrol
versi ) bersama dengan kode sumber . Para pelanggan diharapkan untuk menjadi bagian dari tim
proyek dan untuk membantu mengembangkan skenario untuk script pengujian , setidaknya
penerimaan script , jika tidak semua skrip pengujian . QA dan pengujian personil juga diharapkan
untuk menjadi bagian dari tim proyek

Kebanyakan pengujian sistem TI masih dilakukan secara manual . Namun, pengujian otomatis
sering dapat menghasilkan hasil yang lebih baik dengan harga lebih murah . Baru , alat otomatis
mencakup semua tahapan proses pengujian , termasuk perencanaan . The Quality Assurance
Institute melakukan benchmark membandingkan metode pengujian manual dan otomatis dan
menemukan pengurangan secara keseluruhan dalam waktu orang dari 75 % ( QA Quest , 1995) .
Pengurangan berjalan pengujian yang sebenarnya adalah 95 % , dengan sedikit tabungan dalam
tahap perencanaan pengujian . Otomatis pengujian , bersama dengan menghemat waktu dan
biaya ( setelah kurva pembelajaran awal dalam waktu dan dolar ) , memiliki ini keuntungan lebih
lanjut ( Brown , 1998) :
• Uji pengulangan dan konsistensi
• reuse uji diperluas dan praktis
• dasar suite Praktis

Alat pengujian otomatis benar-benar berguna ketika kita harus mengulang tes yang sama untuk
sejumlah klien yang berbeda dan / atau lingkungan platform server , seperti halnya dengan Web
dan e -commerce aplikasi modern. Pengujian otomatis juga sangat berguna ketika pengujian
beban diperlukan dengan volume tinggi pengguna , transaksi , dan / atau data.

Namun, ada situasi di mana pengujian otomatis kurang berguna , seperti situasi di mana penilaian
manusia diperlukan , dan sulit untuk menentukan kriteria secara kuantitatif . Pengujian kegunaan
adalah salah satu daerah tersebut ( kegunaan dokumentasi serta produk ) , dan daerah lain adalah
" lokalisasi " khususnya dari aplikasi e -commerce global.

Ada sejumlah produk pengujian perangkat lunak yang tersedia untuk mengotomatisasi semua
atau bagian dari proses pengujian : QAWizard ( www.seapine.com ) , TestQuest (
www.testquest.com ) , e -Test ( www.empirix.com ) , tertinggi dimiliki ( www.vtsoft . com ) ,
ApTest ( www.aptest.com ) , QES ( www.qestest.com ) , TestComplete ( www.automatedqa.com )
, QACenter ( www.compuware.com/ ) , dan TestWorks ( www.soft .com / TestWorks / ) .

Beberapa produk pengujian adalah untuk lingkungan tertentu ( misalnya , aplikasi web , aplikasi
windows, aplikasi Java , dll ) , ada pula yang untuk produk tertentu ( misalnya , SAP , PeopleSoft ,
dan lain-lain ) , ada pula yang untuk masalah tertentu ( misalnya , " kebocoran memori , " batas
catur , variabel yang tidak diinisiasi , tipe tidak cocok , ketidaksesuaian dengan standar coding ) ,
dan beberapa tujuan umum .
Untuk daftar alat pengujian open source saat melihat OpenSourceTesting (
www.opensourcetesting.org/ ) . Ada juga sejumlah program tujuan khusus tersedia untuk cacat
pelacakan sebagai : Bug -Track ( www.bug - track.com ) , ElementTool ( www.elementtool.com )
, dan TrackStudio ( www.trackstudio.com ) .

Mengevaluasi, memilih , pengadaan , dan belajar alat tes dapat menjadi beban signifikan dan
mungkin menjadi proyek sendiri untuk sebuah organisasi TI . Kegiatan yang merupakan bagian
dari upaya ini mencakup analisis kebutuhan , pembenaran bisnis untuk biaya pengadaan dan
implementasi , studi alat yang tepat tersedia , pelaksanaan alat , dan pelatihan personil pada alat.

Alat ini sulit untuk mengevaluasi dan adalah mungkin bahwa hal itu akan memakan waktu 6
bulan untuk menemukan bahwa alat ini tidak akan sesuai dengan aplikasi ( Hendrickson , 1999).
" Coba sebelum membeli " adalah filsafat terbaik di sini . Misalnya, dengan aplikasi GUI modern,
alat pemutaran sederhana tidak memadai , karena jika sebuah widget GUI tunggal berubah pada
layar , maka seluruh naskah mungkin harus diubah . Untuk GUI , alat yang lebih kompleks yang
diperlukan yang memungkinkan seseorang untuk mengasosiasikan widget GUI tertentu dengan
seri tertentu yang valid / tidak valid entri skrip . Organisasi tidak boleh meremehkan waktu dan
biaya yang diperlukan untuk belajar menggunakan alat khusus , atau usaha dalam menyiapkan
alat untuk aplikasi di tangan (yang biasanya melibatkan pemrograman uji script) . Dustin ( 1999)
terdaftar beberapa pelajaran dalam otomasi pengujian , termasuk :
• Berbagai alat yang digunakan di seluruh siklus hidup tidak mengintegrasikan dengan mudah
• Informasi Gandakan harus disimpan
• Alat uji melaju usaha
• Staf adalah belajar yang sangat sibuk untuk menulis script
• skrip uji rumit dikembangkan , duplikasi upaya pengembangan
• Script penciptaan adalah rumit
• Tes alat ( s ) diperkenalkan terlambat
• Pelatihan dalam alat sudah terlambat
• Beberapa penguji menolak alat
• Ekspektasi pengembalian awal tidak realistis
• Tool ( s ) punya masalah mengenali kontrol GUI pihak ketiga
• Kurangnya pedoman pengembangan tes
• Tool ( s ) adalah mengganggu , dan diperlukan " sisipan " ke dalam kode
• Laporan berkembang biak dengan alat ( s ) adalah sia-sia
• Peralatan yang dipilih sebelum arsitektur sistem secara keseluruhan ditentukan
• Upgrade ke alat-alat baru memiliki masalah kompatibilitas
• Tool ( s ) database tidak scalable

Ada juga perusahaan yang menawarkan jasa pengujian dan Q / A , seperti Systemware
(www.sysemware.com ) . Beberapa situs web yang tersedia yang menyediakan link ke berbagai
sumber daya pengujian ( alat, buku , artikel , dll ) , seperti Software Q / A Uji Resource Center (
www.softwareqatest.com ) , Pengujian Perangkat Lunak dan Kualitas Jaringan Rekayasa ( www .
stqe.net ) , dan Pengujian dan Kualitas Rekayasa Magazine ( www.stqemagazine.com ) .

Kualitas Tahap Gates

Pengguna penerimaan pengujian adalah kegiatan validasi yang datang terlambat dalam proses
pembangunan tetapi belum tentu di akhir. Ada kegiatan yang dapat dilakukan lebih awal dalam
proses keseluruhan untuk membantu menjamin bahwa produk yang benar sedang dibangun .
Kegiatan ini melibatkan mendapatkan manfaat organisasi dan pemangku kepentingan lain yang
lebih erat terlibat dalam review manifestasi produk awal . Kadang-kadang jenis kegiatan yang
disebut " pengujian statis " karena mereka tidak benar-benar melibatkan menjalankan sistem (
produk akhir ) . Tinjauan koperasi ini manifestasi produk awal disebut gerbang tahap kualitas .
Gerbang tahap manajemen yang dibahas sebelumnya dalam buku ini , dan menerapkan
manajemen gerbang tahap metodologi air terjun klasik ( dan variasinya ) juga digambarkan .
Gambar 2.6 dalam Bab II diilustrasikan gagasan saya gerbang ganda .

Beberapa gerbang tahap kualitas bisa jatuh dalam satu manajemen tahap gerbang atau
sebaliknya . Di gerbang tahap manajemen , kriteria penyelesaian yang terakhir (baik secara
mendalam atau dengan pengecualian ) , dan pergi / kill / keputusan hold tercapai . Gerbang tahap
manajemen dapat diatur pada interval waktu yang tetap atau setelah selesainya fase proyek
besar.

Untuk metodologi di mana fase tumpang tindih , atau saat menggunakan pendekatan inkremental
atau berulang , gerbang tahap manajemen dapat diatur antara kenaikan atau iterasi atau pada
penambahan waktu tetap, seperti 1 bulan . Untuk meminimalkan waktu dan biaya yang terkait
dengan tinjauan manajemen formal, dianjurkan bahwa gerbang tahap manajemen terjadi pada
interval waktu yang teratur tetapi mereka terjadi hanya atas dasar pengecualian ketika metrik
kunci ( seperti indeks EVA ) menunjukkan masalah .

Untuk setiap tahap gerbang kualitas , faktor kepuasan biasanya ditelaah dengan berfokus pada
produk tertentu awal manifestasi oleh para pemangku kepentingan yang relevan untuk gerbang
itu ; review tidak membuat pergi / kill / hold keputusan melainkan jenis keputusan go- maju atau
recycle . Gambar 10.12 mengilustrasikan perbedaan ini .

Sedangkan faktor gerbang tahap manajemen tinjauan penyelesaian (yaitu , biaya yang
sebenarnya sampai saat ini , nilai yang diperoleh , estimasi biaya pada penyelesaian , status
penyelesaian kegiatan , perkiraan waktu untuk menyelesaikan , analisis risiko diperbarui , dan
perlu untuk lebih atau kurang cadangan ) , tahap kualitas gerbang fokus pada faktor-faktor
kepuasan sebagai utilitas , operasi , pemeliharaan , auditability , dan pembenaran bisnis direvisi
(yaitu , analisis biaya-manfaat direvisi berdasarkan perkiraan biaya terbaru dan nomor manfaat
direvisi ) . Pemangku kepentingan yang berbeda dapat hadir pada dua jenis ulasan gerbang
panggung, untuk meminimalkan biaya dan waktu individu kunci. Manifestasi produk awal yang
harus dikaji oleh pemangku kepentingan akan mencakup dokumen persyaratan , skenario use
case , awal
Figure 10.12. Dual stage gates
user manual , storyboard ( " prototipe kertas" ) , desain layar / laporan , dan prototipe bekerja .
Wiegers ( 1999) melaporkan laba atas investasi hingga 800 % untuk kebutuhan ulasan . Gambar
10.13 menunjukkan contoh bagaimana gerbang kualitas mungkin diatur untuk metodologi
waterfall klasik .

Gambar 10.14 adalah contoh dari bentuk gerbang panggung ulasan. Pada formulir ini , metrik
dari analisis nilai yang diperoleh dari gerbang manajemen terakhir ( biasanya pada interval
waktu tertentu) dicatat , yang menunjukkan bagaimana proyek akan dari kemajuan dan
perspektif biaya . Bagian berikutnya dari bentuk menyangkut faktor kepuasan , yang kualitatif
dievaluasi oleh kedua organisasi manfaat ( pelanggan) dan organisasi melakukan ( tim proyek ) .
Dasar dari skor kepuasan juga ditentukan , yang akan menjadi kualitas gerbang terakhir di mana
artefak produk yang tersedia , seperti prototipe . Risiko yang diidentifikasi dan diukur pada awal
proyek kemudian dievaluasi kembali . Informasi pada formulir ini kemudian biasanya ditinjau
oleh manajemen lini dari kedua organisasi (baik secara berkala atau dengan pengecualian ) untuk
menentukan apakah proyek harus terus .
Figure 10.13. Event driven quality stage gates

Figure 10.14. Stage gate review form

Program kualitas
Ada sejumlah program mutu modern yang disponsori oleh organisasi nasional dan internasional.
Organisasi-organisasi ini kualitas asuh dengan mendefinisikan pendekatan umum atau spesifik
tertentu untuk mencapai kualitas dan / atau dengan menetapkan standar untuk kualitas.
Sebelumnya dalam buku ini, Software Engineering Institute Capability Maturity Model (CMM SEI)
dan Manajemen Institut Proyek Badan Knowledge ( PMBOK PMI ) telah dibahas.

Metode penilaian kualitas untuk IT ( khususnya pengembangan perangkat lunak ) juga dibahas ,
termasuk SPICE ( ISO / IEC 15504 ) , TickIT , COBIT , ITIL dan pendekatan . Organisasi-organisasi
ini kualitas asuh dengan mendefinisikan lebih khusus praktik terbaik untuk masing-masing
disiplin ilmu yang tumpang tindih . Praktek-praktek terbaik adalah hal-hal organisasi perlu
dilakukan dalam rangka untuk menghasilkan produk berkualitas melalui proyek-proyek dikelola
dengan baik . Meskipun hal-hal yang perlu dilakukan adalah diperinci , persis bagaimana
melakukannya diserahkan kepada kebijaksanaan organisasi individu dan / atau PM . Pada bagian
ini kita melihat banyak program kualitas umum .

Manajemen kualitas total ( TQM ) adalah filosofi bisnis yang mendorong organisasi dan karyawan
mereka untuk fokus pada kualitas dan menemukan cara untuk melakukan perbaikan terus
menerus untuk organisasi produk / jasa dan praktek . TQM mendapatkan popularitas di Amerika
Serikat pada 1990-an setelah sukses dilaksanakan oleh Ford , Boeing , dan perusahaan besar
lainnya . TQM didasarkan pada karya sebelumnya dari seluruh dunia ( terutama di Jepang setelah
Perang Dunia II ) oleh Shewart , Demming , dan Ishikawa . Enam prinsip TQM adalah :
• Fokus pada pelanggan
• Fokus pada proses serta hasil
• Pencegahan terhadap pemeriksaan
• Memobilisasi keahlian tenaga kerja
• pengambilan keputusan berbasis Fakta
• Feedback

Landasan , bagaimanapun , TQM adalah perbaikan terus-menerus , pemberdayaan karyawan dan

fokus pelanggan. Perbaikan terus-menerus ( atau kaizen ) merupakan proses yang
berkesinambungan melakukan perbaikan , biasanya dengan langkah-langkah kecil . Dalam
bahasa Jepang , kai berarti untuk mengubah dan zen berarti untuk membuat lebih baik .
Pemberdayaan karyawan berarti untuk memungkinkan karyawan untuk membuat saran tentang
bagaimana meningkatkan proses , karena mereka adalah orang yang paling intim dengan proses
, tidak supervisor mereka . TQM didasarkan pada prinsip bahwa sebagian besar karyawan ingin
terlibat dalam perbaikan dan untuk melakukan pekerjaan mereka dengan baik . TQM mendorong
kerja sama tim di antara karyawan untuk mengidentifikasi masalah kualitas dan koreksi . Sebuah
aplikasi untuk Malcolm Baldrige Award1 dapat dilakukan oleh perusahaan yang telah
sepenuhnya dilaksanakan TQM dan dihitung manfaat daripadanya .

Kualitas fungsi penyebaran ( QFD ) didirikan di Jepang pada akhir 1960-an oleh Profesor Shigeru
Mizuno dan Yoji Akao . Kontrol kualitas statistik telah menjadi lazim di industri manufaktur
Jepang , dan kegiatan kualitas ini sedang terintegrasi dengan ajaran Ishikawa dan Feigenbaum ,
yang kemudian dikenal sebagai TQM . Mizuno dan Akao berusaha untuk mengembangkan metode
jaminan kualitas yang akan merancang kepuasan pelanggan menjadi produk sebelum produk
yang dihasilkan . Aplikasi besar pertama adalah di Bridgestone Tire , di Jepang , yang
menggunakan Ishikawa ( " diagram tulang ikan " ) untuk mengidentifikasi setiap kebutuhan
pelanggan (efek ) dan untuk mengidentifikasi faktor-faktor desain proses ( penyebab ) yang
diperlukan untuk mengontrol dan mengukur itu . Dengan kesuksesan , ini diagram fishbone
kebutuhan pelanggan dan harapan yang refashioned ke dalam spreadsheet atau matriks Format
, dengan baris menjadi efek yang diinginkan kepuasan pelanggan dan kolom menjadi penyebab
pengendalian dan terukur . Pada waktu yang sama , Ishihara memperkenalkan prinsip-prinsip
rekayasa nilai yang menggambarkan fungsi bisnis yang diperlukan untuk menjamin kualitas
proses desain itu sendiri . QFD muncul sebagai kombinasi dari dua metode ini untuk memastikan
sistem kualitas desain yang komprehensif untuk kedua produk dan proses bisnis ( Akao , 1990) .
QFD mencapai Amerika Serikat dan Eropa pada tahun 1980 ketika American Society for Quality
Control menerbitkan karya Akao dan mengundang Akao untuk memberikan seminar QFD di
Amerika . Hari ini , QFD digunakan secara luas di Amerika Serikat , Jepang , Swedia , Jerman ,
Australia , Brasil , dan Turki . QFD agak berbeda dari prinsip-prinsip kualitas lain dalam hal ini
berfokus pada kedua kebutuhan pelanggan - lain dan tak tertulis . Ini berusaha untuk
memaksimalkan aspek kualitas positif , seperti kemudahan penggunaan , menyenangkan untuk
digunakan , menarik , dll QFD prinsip-prinsip kunci ( Mizuno & Akao , 1994)
• Memahami kebutuhan pelanggan
• Kualitas sistem pemikiran + psikologi + pengetahuan / epistemologi
• Memaksimalkan kualitas positif untuk menambah nilai
• kualitas sistem komprehensif untuk kepuasan pelanggan
• Strategi untuk " tetap di depan permainan "

Organisasi Internasional untuk Standardisasi ( ISO ) juga mendefinisikan seperangkat prinsip

manajemen mutu yang disebut ISO 9000 , yang meliputi banyak TQM . Dalam DoD AS , 2167A
merupakan satu set sama prinsip dan persyaratan . Versi terbaru dari ISO 9000 ( ISO 9000:2000)
terdiri dari prinsip-prinsip manajemen ini :
• Pelanggan Fokus : Jauhkan kebutuhan pelanggan di garis depan
• Kualitas Fokus melalui Kepemimpinan : Pemimpin harus selalu peduli dengan kualitas dan
menumbuhkan sikap yang sama dalam __ pengikutnya
• Orang Fokus : Manajemen harus menyimpan semua pihak yang terlibat dan mendorong
komunikasi terbuka dan jujur
• Proses Fokus : Kegiatan produksi dan proyek harus dipandang sebagai suatu proses sehingga
teknik optimasi proses dapat diterapkan
• Pendekatan Sistem : saling tergantung dan proses harus dilihat sebagai suatu sistem sehingga
prinsip optimasi sistem dapat diterapkan di semua proses tersebut
• Peningkatan Berkepanjangan : Organisasi harus berusaha untuk terus meningkatkan sistem dan
proses melalui metrik dan tujuan
• Pengambilan Keputusan Kuantitatif : Keputusan harus didasarkan pada informasi dan metode
untuk secara resmi menganalisa informasi yang
• Hubungan Simbiotik dengan Pemasok : Hubungan dengan vendor harus menciptakan nilai bagi
kedua organisasi untuk keberhasilan jangka panjang dan kualitas dari kedua organisasi

Organisasi dapat mencari sertifikasi ISO 9000 untuk membuktikan bahwa mereka telah
menerapkan prinsip-prinsip manajemen kualitas dan proses bisnis untuk mendukung sama.
Sertifikasi ISO 9000 dapat dicari di bawah salah satu dari tiga program : . ISO 9001 , ISO 9002 ,
ISO 9003 atau ISO 9001 adalah sertifikasi yang biasanya berlaku untuk organisasi TI karena itu
untuk organisasi yang memiliki desain dan pengembangan proses serta produksi dan dukungan.
Jika sebuah organisasi IT tidak melakukan desain dan pengembangan ( seperti mungkin kasus di
mana semua proyek melibatkan integrasi off- the- rak produk ) , maka ISO 9002 mungkin berlaku.

Standar proses untuk sertifikasi ISO pada dasarnya memastikan bahwa organisasi memiliki dan
mengikuti prosedur kualitas mereka sendiri ; mereka tidak menentukan prosedur mutu.
Perusahaan menginginkan sertifikasi tersebut biasanya melakukan self assessment rinci
pertama, kemudian meminta persetujuan resmi oleh pihak ketiga yang terdaftar untuk
melakukan audit tersebut . Ia telah mengemukakan bahwa melompat melalui lingkaran ISO dapat
menjadi proses yang mahal dan menyedihkan bagi organisasi yang bertentangan dengan aplikasi
untuk penghargaan TQM Baldrige , yang lebih menggembirakan ( Jones , 1994) .

Program kualitas Sedikit lebih kuantitatif dan spesifik adalah Six Sigma . Program ini dimulai oleh
Motorola pada tahun 1980 dan menerima banyak perhatian setelah implementasi yang sangat
sukses dengan General Electric ( GE ) pada 1990-an . Sigma (  ) adalah bahasa Yunani dan
merupakan standar deviasi dalam distribusi normal. Distribusi statistik ini adalah yang paling
umum , dan digunakan dalam analisis kualitas , seperti variasi pengukuran; itu diilustrasikan
pada Gambar 10.15 . Standar deviasi ( sigma ) adalah ukuran seberapa jauh sebuah titik dari rata-
rata ( setengah dari distribusi adalah pada setiap sisi dari mean ) . Rentang Sigma adalah
Figure 10.15. Normal distribution

didefinisikan apa yang paling penting bagi mereka , seperti kecepatan dalam menyelesaikan
proses pemesanan on-line , organisasi menentukan kegiatan yang paling mempengaruhi
kemampuannya untuk mempercepat proses tersebut. Kegiatan-kegiatan yang dipilih menjadi
kritis - to-quality ( CTQ ) kegiatan ( Shand , 2001) . Program Six Sigma ini terdiri dari 12 langkah
( Harry & Schroeder , 2000) :
Ukuran
1 . Pilih ( CTQ ) kegiatan kritis - to-quality
2 . Tentukan standar kinerja
3 . Validasi sistem pengukuran
Menganalisa
4 . Membangun kemampuan produk
5 . Tentukan tujuan kinerja
6 . Mengidentifikasi sumber variasi ( akar penyebab )
Memperbaiki
7 . Layar penyebab potensial
8 . Temukan hubungan variabel
9 . Menetapkan toleransi operasi
Kontrol
10 Sistem pengukuran Validasi
11 . Menentukan kemampuan proses
12 . Melaksanakan proses kontrol

Dasar proses Six Sigma mengidentifikasi kegiatan CTQ , menemukan akar penyebab masalah
potensial dengan proses tersebut , menemukan hubungan kuantitatif antara sebab dan akibat, set
up metrik untuk mengukur penyebab , dan mengontrol penyebab potensi masalah sehingga efek
tetap dalam enam - sigma level. Untuk menerapkan Six Sigma memerlukan investasi yang
signifikan dalam program pelatihan yang sangat spesifik .

Baru-baru ini , Computerworld telah mendefinisikan banyak program kualitas dan diringkas
derajat mereka abstraksi dan relevansi khusus IT , seperti yang diilustrasikan jika Gambar 10.16
( Athena 2004 ) .

Standar Pengembangan Software

Program kualitas dan praktik terbaik berfokus terutama pada proses , dan sebagian besar cukup
umum daripada spesifik . Program-program berkualitas tidak selalu menangani efek jangka
panjang dari masalah kualitas , terutama dalam proyek TI . Masalah seperti rawatan , kemampuan
beradaptasi , dan penggunaan kembali tidak sepenuhnya dibahas dalam program-program
berkualitas , terutama dalam program-program yang berfokus pada pelanggan ( karena aspek ini
tidak bisa dilihat oleh pelanggan ) . Standar berfokus terutama pada kriteria produk, dan standar
juga dapat dibentuk untuk menangani efek jangka panjang yang berkualitas . Salah satu cara
terbaik untuk memastikan kualitas dalam proses IT , produk ,
Figure 10.16. Quality programs

dan proyek adalah dengan menetapkan standar dalam organisasi TI sesuai tingkatannya tertinggi
. Standar adalah spesifikasi formal untuk mendokumentasikan bagaimana proses harus
dijalankan secara khusus , bagaimana produk yang akan dibangun , dan / atau bagaimana produk
yang melakukan .

Ada banyak bidang standar teknis . Beberapa perkembangan yang paling umum dan penting bagi
IT melibatkan persyaratan , desain , coding , database, pengujian , dokumentasi internal dan
eksternal , antarmuka pengguna , dan antarmuka eksternal lainnya . IEEE memiliki banyak
standar rekayasa perangkat lunak penting , dan yang paling relevan di daerah kualitas adalah :
• Standar IEEE untuk Kualitas Software Rencana Jaminan
• 829730-2002 -1998 IEEE Standard for Software Test Dokumentasi
• 982,1-1988 IEEE Standard Kamus Langkah-langkah untuk Menghasilkan Reliable Software
• 1008-1987 IEEE Standard for Software Pengujian Unit
• 1012-1998 IEEE standar untuk Perangkat Lunak Verifikasi dan Validasi
• 1012a - 1998 IEEE Standard for Software Verifikasi dan Validasi - Tambahan 1012-1998
• 1061-1998 ( R2004 ) IEEE Standar Kualitas Software Metrik Metodologi
• 1228-1994 ( 2002 ) IEEE Standard for Rencana Keselamatan Software
• 1465-1998 [ Adopsi ISO / IEC 12119 : 1994 ( E ) ] , IEEE Standard Adopsi Standar Internasional
ISO / IEC 12119 : 1994 ( E ) Informasi Teknologi paket - Software : Syarat mutu dan pengujian

Rincian standar ini tersedia di situs Web IEEE ( www.standards.ieee.org ) . Standar IT lain yang
relevan juga tersedia dari American National Standards Institute ( ANSI ) dan International
Organization for Standardization ( ISO ) ; IEEE , ANSI , ISO dan standar tumpang tindih di banyak
daerah dan sering berhubungan langsung satu sama lain .

Ini semua adalah standar yang cukup umum yang harus dibuat spesifik untuk setiap organisasi ,
dan mungkin untuk setiap platform dan bahasa pemrograman . Perhatikan , misalnya , standar
pengkodean organisasi , yang dapat mencakup item seperti :
• Konvensi penamaan untuk variabel ( statis dan contoh ) , konstanta , kelas , fungsi / metode ,
dan sebagainya .
• Penggunaan dan penempatan konstanta (yaitu , di satu tempat seperti file sumber daya , C + +
/ PHP kelas abstrak , atau antarmuka Java )
• Gunakan orientasi obyek ( warisan , komposisi , polimorfisme , interface )
• Penggunaan komentar dan dokumentasi internal
• Penggunaan lekukan dan " ruang putih "
• Penggunaan kurung untuk pesanan evaluasi ekspresi
• Bersyarat terhadap ekspresi logis
• Kedekatan keputusan dan tindakan
• Iterasi dibandingkan rekursi
• kepadatan Code ( yaitu , satu baris kode per statement ) dan mudah dibaca
• ukuran Fungsi / metode (yaitu , hanya satu fungsi logis dan di bawah 100 baris kode )
• Jenis-jenis kelas ( delegasi , adaptor , batin , anonim , dll )
• Perlindungan Access ( publik, swasta , paket , dilindungi , dll )
• Meminimalkan kopling ( teman , argumen object , dll )
• Kesalahan penanganan (input pemeriksaan , pengecualian , dll )
• Overloading ( fungsi , operator , dll )

Untuk berkomunikasi dan menegakkan standar , banyak perusahaan mungkin masih bergantung
pada beberapa jenis dicetak manual standar . Untuk beberapa perusahaan , ini adalah satu set
multivolume besar dokumen terikat . Organisasi-organisasi lain , yang mungkin atau mungkin
tidak memiliki manual standar seperti luas , melakukan periodik " walkthrough kode , " yang
memiliki rekan-rekan dan / atau manajer memeriksa sampel kode masing-masing programmer
untuk memastikan mereka mengikuti standar perusahaan . Beberapa metodologi rekayasa
perangkat lunak memiliki tingkat kode walkthrough dibangun ke metodologi , seperti dalam
pasangan pemrograman , di XP .

Proses pengujian adalah cara lain untuk memastikan program-program tersebut yang diinginkan
"tampilan dan nuansa . " Di sini , hasilnya mudah dilihat tetapi tidak metode yang mendasarinya.
Weinschenk ( 1997) menyatakan bahwa " agar pedoman Anda untuk menjadi sukses , orang
harus tahu bahwa mereka ada dan didorong untuk menggunakannya . " Dia menguraikan daftar
beberapa tindakan manajemen yang mendorong penerapan standar yang efektif .

Satu-satunya cara untuk benar-benar memastikan bahwa standar sedang diikuti dari kedua
perspektif eksternal dan internal , bagaimanapun, adalah untuk meminta pengembang untuk
memanfaatkan komponen di mana standar yang relevan telah dibenamkan ( Brandon , 2000).
Metode pemanfaatan komponen bervariasi dengan bahasa pemrograman dan gaya
pemrograman dari yang sederhana " termasuk" teknik ( seperti buku salinan COBOL , SHTML
server-side termasuk , atau PHP membutuhkan) dengan teknik berorientasi objek warisan dan
komposisi yang dibahas sebelumnya dalam buku ini .
Sebagai contoh , mempertimbangkan user interface , yang sering bagian penting dari aplikasi TI
modern. Telah ada banyak perhatian pada pendekatan user interface dan standar sejak Apple
Computer berhasil dengan antarmuka pengguna grafis komersial pertama ( GUI , Collins , 1995).
Banyak buku dan beberapa film telah dibuat tentang teknis, bisnis , dan isu-isu sosial dari saga
GUI . Untuk sistem komputer memiliki nilai abadi , itu harus ada mensinergikan dengan pengguna
dan sistem lain di dunia yang selalu berubah IT . Bahkan jika sistem dengan sendirinya sangat
baik , fakta bahwa mereka mungkin memiliki tampilan yang berbeda dan merasa untuk sistem
lain yang digunakan pada akhirnya akan mantra azab nya.

Perusahaan membangun sistem perangkat lunak , baik untuk keperluan internal mereka atau
untuk dijual kembali , produk mustbuild yang kompatibel dengan sistem lain . Sebagaimana
dinyatakan oleh Weinschenk dan Yeo ( 1995 ) , " desainer antarmuka , manajer proyek ,
pengembang , dan unit bisnis perlu seperangkat pedoman tampilan dan nuansa untuk merancang
dan mengembangkan oleh . Datang dengan pedoman ini bisa menjadi proses yang panjang dan
sulit . Aplikasi GUI baru tidak dapat diadakan untuk delapan bulan sementara satuan tugas
berpendapat tentang pedoman " Ada banyak buku yang ditulis tentang masalah desain
antarmuka pengguna yang tepat pada umumnya . ( Fowler , 1998; Galitz , 1997; Wood , 1998 ) ,
dan ada juga buku yang khusus ditujukan untuk platform tertentu, seperti Microsoft Windows (
Cooper , 1995; Microsoft , 1995 ) . Lampiran A ( 1997) buku Weinschenk juga menyajikan daftar
standar antarmuka pengguna ; ada lebih dari 300 item yang terdaftar di sana.

Untuk menegakkan standar dan untuk memberikan dasar pemrograman yang fleksibel dan
mudah beradaptasi , organisasi TI harus mengadopsi atau mengembangkan dasar untuk
penerapan standar . Gambar 10.17 menggambarkan konsep salah satu yayasan standar tersebut
dengan bahasa pemodelan terpadu ( UML ) diagram ( Brandon , 2000).

Dalam contoh ini , sebuah aplikasi terdiri dari sejumlah aplikasi Windows. Setiap Aplikasi
Window (yaitu , program PHP , Java Server Page, Java Applet ) berasal ( diturunkan ) dari
Standard Jendela Perusahaan . Aplikasi Jendela mengimplementasikan GUI Standar Interface (
atau jendela yang Permohonan berasal telah mengimplementasikan interface ini ) . Dengan
antarmuka , hal ini dimaksudkan antarmuka Java atau kelas abstrak C + + atau PHP . Aplikasi
Jendela terdiri dari Standar Perusahaan Komponen GUI . Komponen-komponen standar
menggunakan GUI Standar Perusahaan dan komponen ini mungkin berasal dari HTML / XML
objek GUI , MFC , Java AWT , Java Swing , atau perpustakaan kelas pihak ketiga asalkan sumber
perpustakaan kelas ini telah diperpanjang ( disesuaikan ) untuk menggunakan data di GUI
Standar Perusahaan .

Serta melaksanakan semua standar perusahaan yang diinginkan , kelas standar dasar juga dapat
dibangun untuk merangkum mekanisme keamanan . Jika semua masukan aplikasi dipaksa untuk
mengambil tempat melalui kelas dasar standar , maka programmer nakal atau kontraktor akan
cenderung mampu membangun -in " pintu belakang , " " kuda Trojan , " " waktu - bom , " dan
mekanisme terlarang lainnya ke dalam sistem yang dikembangkan . Kelas dasar standar akan
dibangun dan diperiksa oleh sumber terpercaya , dan kelas-kelas yang akan diimpor oleh coders
lain akan dibuat akhir .
Figure 10.17. Standards foundation

Figure 10.18. Standards implementation via window inheritance

Sebelumnya dalam buku ini, banyak tantangan TI manajemen proyek diidentifikasi.

Tantangan-tantangan ini dapat dipenuhi dengan integrasi cermat prinsip dan praktek
rekayasa manajemen proyek modern dan perangkat lunak. Hal ini diilustrasikan pada
Gambar 1.4 di Bab I; bab ini membahas aspek kualitas manajemen proyek. kritis
Faktor keberhasilan proyek TI digunakan sebagai dasar untuk metrik kualitas kunci.
Sebuah rencana manajemen mutu untuk proyek-proyek TI harus mencakup verifikasi
dan validasi, dan kedua proses ini harus pada pergi sepanjang proyek dan dikontrol
melalui teknik seperti kualitas proses tahap gerbang yang dijelaskan di sini. Topik
kualitas kunci lainnya juga dibahas dalam bab ini, termasuk banyak jenis dan metode
pengujian perangkat lunak, standar pengembangan perangkat lunak, dan organisasi dan
program yang berkualitas.

Referensi
Akao, Y. (1990). Quality function deployment: Integrating customer requirements into product design (G. Mazur,
Trans.). New York: Productivity Press.
Athens, G. (2004, March). Model mania. Computerworld.
Brandon, D. (2000). An object oriented approach to user interface standards. Challenges of information
technology management in the 21st century (pp. 753-756). Hershey, PA: Idea Group Publishing.
Brown, N. (1998). Little book of testing: Vols. I & II. Chesapeake, VA: Software Program Managers Network.
Collins, D. (1995). Designing object oriented user interfaces. Boston: Benjamin/Cummings.
Cooper, A. (1995). About face. Boston: IDG Books.
Crosby, P. (1979). Quality is free. Princeton, NJ: McGraw-Hill.
Deming, W. (1982). Out of the crisis. MIT Press.
Dustin, E. (1999, September/October). Lessons in test automation. Testing & Quality, 1(5).
Foley, M. (2000, February 11). Can Microsoft squash 63000 bugs in Windows 2000. Smart Reseller.
Fowler, S. (1998). GUI design handbook. McGraw-Hill.
Galitz, W. (1997). The essential guide to user interface design. New York: Wiley.
Gause, D. & Weinberg, G. (1989). Exploring requirements: Quality before design. New York: Dorset House.
Hallows, J. (1998). Information systems project management. New York: American Management Association.
Harry, M. & Schroeder, R. (2000). Six Sigma: The breakthrough management strategy revolutionizing the world’s
top corporations. New York: Doubleday.
Hendrickson, E. (1999, May-June). Making the right choice. Software Testing and Quality Engineering.
IEEE/ANSI STD 1008. (2002). IEEE standard for software unit testing. Piscataway, NJ:
IEEE Computer Society.
Jones, C. (1994). Assessment and control of software risks. Englewood Cliffs, NJ: Yourdon Press Computing
Series.
Linger, R. (1994). Cleanroom process model. IEEE Software, 11(2)
McConnell, S. (1997). Software project survival guide. Seattle, WA: Microsoft Press.
Microsoft. (1995). The Windows interface guidelines for software design. Microsoft Press.
Mizuno, S. & Akao, Y. (1994). QFD: The customer-driven approach to quality planning and deployment (G.
Mazur, Trans.). Newton Square, PA: Quality Resources.
PMI. (2000). The project management body of knowledge (PMBOK). ISBN 1-880410-22-2.
QA Quest. (1995, November). The newsletter of the Quality Assurance Institute.
Orlando, FL.
The Quality Imperative. (1991, Bonus Issue, Fall). Business Week.
Shand, D. (2001, March 5). Six Sigma.Computerworld, p. 38.
Weinschenk, S. & Yeo, S. (1995). Guidelines for enterprise wide GUI design. New York: Wiley.
Weinschenk, S., Pamela J., & Sarah Y. (1997). GUI design essentials. Wiley.
Wiegers, K. (1999). Software requirements. Seattle, WA: Microsoft Press.
Wood, L. (1998). User interface design. Boca Raton, FL: CRC Press.
ZDNet. (2000, February). Retrieved from www.zdnet.com

Catatan Akhir
The Malcolm Baldrige National Quality Award (disajikan oleh NIST - Institut Nasional
Standar dan Teknologi). Diciptakan oleh Hukum Publik 100-107, yang ditandatangani menjadi
undang-undang pada 20 Agustus 1987 dukungan Kepala Sekolah untuk program berasal dari
Yayasan Nasional Malcolm Baldrige Quality Award, didirikan pada tahun 1988.

Penghargaan ini dinamai Malcolm Baldrige, yang menjabat sebagai Menteri Perdagangan dari
tahun 1981 sampai kematiannya yang tragis dalam kecelakaan rodeo pada tahun 1987.
 BAB XI

Manajemen
Perubahan dan Close-Out
Anda harus menyambut perubahan sebagai aturan , tapi bukan sebagai penguasa Anda .
( Denis Waitley )

Perubahan adalah kenyataan hidup bagi sebagian besar proyek , terutama proyek TI . Penyebab
tunggal terbesar dari overruns proyek adalah perubahan dalam lingkup ( Hallows , 1998) .
Perubahan bisa untuk baik atau buruk , tetapi perubahan yang diharapkan , dan perubahan harus
dikelola . Bab ini berkaitan dengan proses manajemen .

proyek Perubahan
Resistensi terhadap perubahan biasanya berakar pada ketakutan yang tidak diketahui sebagai
PMS dan orang-orang pada umumnya lebih memilih stabilitas dan prediktabilitas . Namun, dalam
rangka untuk proyek untuk bertahan hidup , PMS harus menghadapi perubahan secara efektif .
Banyak proyek gagal tidak dalam tujuan dan arah mereka , tetapi dalam rencana mereka ( atau
kurangnya rencana ) untuk menghadapi perubahan . Tidak memiliki sistem kontrol perubahan
resmi " menjamin proyek akan terganggu oleh kekacauan , kesalahan , kerusakan permanen ,
produktivitas yang rendah , dan evolusi perangkat lunak tidak terkendali " ( Brown , 1998) .
Pengendalian perubahan formal sangat penting dalam proyek-proyek yang melibatkan
pertunjukan eksternal atau menguntungkan organisasi sehingga satu organisasi dapat tepat
kompensasi untuk upaya tambahan .

Perubahan bisa terjadi karena berbagai alasan ; dalam proyek-proyek TI , sumber utama atau
indikator perubahan adalah :
• Pelanggan ( menguntungkan organisasi ) tidak yakin kebutuhan mereka
• Pelanggan tidak yakin bagaimana kebutuhan harus disampaikan
• Organisasi melakukan jelas dengan rincian kebutuhan pelanggan
• Organisasi melakukan tidak yakin bagaimana untuk melakukan pekerjaan
• Lingkungan deployment telah berubah
• metode Direncanakan atau algoritma membuktikan tidak cocok
• Metode yang lebih baik membangun atau penggelaran sistem telah datang ke depan
• Kasus bisnis untuk proyek telah berubah
• Pasar pergeseran demografis dan / atau geografis
• Lingkungan sosial politik untuk proyek tersebut telah berubah
• Lingkungan perusahaan telah berubah ( reorganisasi , merger , akuisisi )

Perubahan dalam suatu proyek bisa datang dalam setiap bagian dari proyek dari perencanaan
awal melalui proyek obral ; dalam proyek-proyek TI , sebagian besar perubahan datang kemudian
dalam proyek seperti selama implementasi , pengujian dan penyebaran . Perubahan datang
kemudian dalam sebuah proyek biasanya jauh lebih mahal daripada jika itu kebutuhan untuk
perubahan diidentifikasi sebelumnya .

Perubahan di salah satu bagian dari deliverable proyek dapat menyebabkan perubahan di banyak
bagian lain dari proyek juga. Jadi , seperti yang dibahas sebelumnya dalam buku ini , sangat
penting untuk mengambil langkah-langkah awal untuk flush kebutuhan pengguna dan perubahan
potensial . Validasi manifestasi produk awal dengan gerbang tahap kualitas menggunakan
metode sebagai prototipe , use case penelusuran dengan pelanggan , dan review desain dengan
pemangku kepentingan yang tepat akan meminimalkan perubahan kemudian dalam proyek .
Manajemen perubahan proyek biasanya menyangkut perubahan ruang lingkup , tetapi
perubahan lain juga perlu dikelola . Biasanya , sistem kontrol perubahan ditetapkan untuk
berurusan dengan hanya lingkup dan perubahan penyampaian ; perubahan proyek lainnya
biasanya ditangani melalui manajemen risiko , seperti yang dibahas sebelumnya dalam buku ini.

Lingkup manajemen secara umum mencakup proses-proses yang diperlukan untuk memastikan
bahwa semua pekerjaan proyek ditujukan dan bahwa pekerjaan ekstra tidak dilakukan .
Pengendalian perubahan lingkup harus direncanakan dan prosedur yang ditetapkan di awal
proyek ( charter , SOW , kontrak , rencana proyek keseluruhan ) . Ubah control berkaitan dengan
berikut ( PMI , 2000) :
• Mempengaruhi faktor-faktor yang menyebabkan perubahan kontrol untuk memastikan bahwa
perubahan yang bermanfaat
• Menentukan bahwa perubahan lingkup telah terjadi
• Mengelola perubahan yang sebenarnya ketika dan jika mereka terjadi Dalam lingkungan TI ,

kontrol perubahan jangka dapat membingungkan karena kata-kata itu sering diterapkan untuk
kontrol perubahan pada kode dan / atau perubahan ke platform deployment target hardware /
software sumber program . Dalam buku ini , kontrol kode sumber dan artefak terkait akan disebut
kontrol versi , dan kontrol hardware dan komponen software tergantung pada platform
penyebaran akan disebut kontrol konfigurasi ; kedua topik ini akan dibahas kemudian dalam bab
ini . Dalam buku ini , kontrol perubahan merujuk hanya untuk mengubah kontrol pada tingkat
proyek ; Namun , perubahan persyaratan proyek atau penyampaian dapat memicu versi atau
konfigurasi sesuai perubahan .

Membangun Sistem Change Control

Sebuah sistem pengendalian perubahan lingkup proyek mendefinisikan prosedur dimana
lingkup proyek dapat diubah dan biasanya meliputi bentuk , sistem pelacakan , dan tingkat
persetujuan . Sebuah ilustrasi bentuk seperti ditunjukkan pada Gambar 11.1 . Ini harus
diintegrasikan dengan sistem yang log dan mendokumentasikan semua perubahan proyek .

Sebuah kode atau nomor harus diserahkan kepada setiap perubahan yang diusulkan apakah
perubahan diusulkan secara internal (yaitu , anggota tim proyek ) atau eksternal (yaitu ,
pelanggan ) . Gelar ini formalitas biasanya dikenakan setelah segmen metodologi awalnya selesai.

Sebagai contoh, pengendalian perubahan formal pekerjaan desain biasanya dilaksanakan setelah
desain awal selesai . Pro dan kontra perubahan harus dianalisis dan dibahas dari segi semua
parameter proyek termasuk biaya dan waktu konsekuensi , dan apa perubahan lain mungkin
diperlukan ( atau diinginkan ) akibat perubahan ini . Mengusulkan perubahan mungkin atau
mungkin tidak dalam anggaran proyek , atau mungkin atau mungkin tidak menjadi bagian dari
anggaran yang tidak dibagikan.

Pembahasan perubahan yang disarankan biasanya terjadi pada pertemuan yang dijadwalkan
secara rutin dari panel kontrol perubahan , yang memiliki anggota dari kedua pertunjukan
tersebut
Figure 11.1. Change order form

organisasi dan organisasi menguntungkan . Hal ini juga dianjurkan untuk menyertakan wakil-
wakil dari kelompok-kelompok stakeholder utama lainnya . Perwakilan harus dididik ke dalam
proses yang mereka akan menjadi bagian dari . Untuk memaksimalkan manfaat dari pertemuan
ini dan meminimalkan waktu pertemuan hilang oleh peserta , pertemuan tidak boleh terlalu
sering , paket pengarahan harus dikirim ke perwakilan sebelum pertemuan, dan perubahan harus
disortir dan dibundel ke dalam bidang fungsional produk . Seringkali , banyak perubahan kecil
dapat dianalisis dan dibahas sebagai satu perubahan set atau pelepasan . Cacat dan
ketidakpatuhan terhadap persyaratan dan / atau standar biasanya tidak pergi melalui
pengendalian perubahan formal, namun dalam beberapa organisasi papan kontrol perubahan
mungkin disarankan dari isu-isu tersebut selama proyek . Kadang-kadang ada garis tipis antara
perubahan ruang lingkup dan ketidakpatuhan terhadap persyaratan asli ; dan tentu saja ini dapat
menyebabkan konflik antara organisasi yang terlibat . Cara terbaik adalah untuk
mendokumentasikan semua masalah tersebut dan resolusi mereka bahkan jika informasi
tersebut tidak akan diserahkan ke papan kontrol perubahan .

Jika perubahan disetujui oleh dewan , maka mungkin ada tingkat tambahan tertentu diperlukan
persetujuan yang diperlukan dalam pengelolaan garis organisasi melakukan dan manfaat .
Seringkali jika perubahan adalah dalam anggaran yang tidak dibagikan , maka persetujuan yang
lebih tinggi tidak diperlukan . Setelah disetujui , struktur rincian kerja baru ( WBS ) bekerja packet
dibuat ( atau paket yang ada dimodifikasi ) untuk mencerminkan perubahan dan rencana biaya
proyek dasar baru dan jadwal dibuat ; untuk pekerjaan eksternal dikontrak , perubahan kontrak
juga mungkin diperlukan , yang disebut "order perubahan. " Gambar 11.2 menunjukkan contoh
informasi perubahan kontrol ( nomor kontrol perubahan ) terkait dengan WBS paket pekerjaan .

Biasanya lebih baik untuk membuat WBS paket pekerjaan baru yang akan menjadi pengganti (
atau di samping ) paket lain ; untuk penggantian , paket lama telah biaya yang direncanakan
diatur ke nol ( atau jumlah yang sudah dihabiskan untuk itu jika bekerja di dalamnya sudah
dimulai ) . Gambar 11.3 mengilustrasikan prosedur keseluruhan khas untuk menangani
perubahan proyek . Setelah permintaan perubahan dimulai , keputusan dibuat apakah perubahan
yang diminta sebenarnya adalah bagian dari asli ( baseline) lingkup atau tidak . Keputusan ini
dapat dilakukan oleh dewan CC atau hulu dari papan dengan manajemen proyek . Mereka
permintaan perubahan yang dicakup oleh lingkup dasar yang dikirim untuk bekerja kontrol
untuk dimasukkan
Figure 11.2. Form to add WBS Code (showing change info)

Figure 11.3. Change control process

ke dalam WBS. Mereka permintaan perubahan yang untuk pekerjaan tambahan akan dikirim ke
papan CC untuk studi. Dewan mempelajari permintaan dalam terang manfaat terhadap dampak
proyek dan membuat keputusan untuk menerapkan perubahan atau tidak. Jika keputusan adalah
untuk menerapkan, maka administrasi kontrak mungkin perlu harga pekerjaan baru dan
mengeluarkan perintah perubahan kontrak. Jika urutan perubahan kontrak disetujui (dengan
memanfaatkan dan melakukan organisasi), maka perubahan pergi bekerja kontrol. Perubahan
lingkup dan perubahan korektif biasanya batched ke versi produk yang melalui kontrol versi
(dibahas nanti) dan Q / A.

Gambar 11.4 menunjukkan jenis berguna grafik tren untuk perintah perubahan kumulatif
terbuka dan perintah perubahan kumulatif ditutup (disetujui untuk implementasi atau ditolak).
Untuk jenis

Figure 11.4. Cumulative change orders

analisis , satu harapan untuk melihat kesenjangan antara perintah perubahan terbuka dan
tertutup perintah menutup sebagai hasil proyek . Jika gap ( antara dua kurva ) menjadi lebih luas
, maka ada masalah dalam definisi lingkup proyek . Untuk proyek-proyek IT yang sukses , 70 %
dari biaya produk berada dalam tahap pemeliharaan ; dengan demikian , pemeliharaan sangat
penting . Sebuah ukuran rawatan produk IT adalah baris kode yang terkena dampak perubahan
per pesanan . Sebuah metrik yang komprehensif di daerah ini mencakup baik baris kode yang
terkena dampak dan baris kode diperiksa per pesanan perubahan, karena dalam melaksanakan
perubahan , programer menghabiskan sekitar setengah dari waktu mereka hanya memeriksa
kode yang sudah ada . Kedua metrik ini termasuk dalam bentuk mengubah urutan sampel
Gambar 11.1 .

Kontrol versi
Versi kontrol terutama suatu proses untuk memastikan bahwa beberapa pengembang tidak
mengesampingkan setiap perubahan lain untuk modul kode sumber . Ini biasanya melibatkan
prosedur check-in/check-out manual atau otomatis untuk modul tersebut . Versi kontrol
mungkin berlaku untuk IT artefak atau kiriman lain dari sekedar kode sumber termasuk berbagai
bentuk dokumentasi ( termasuk dokumen desain ) atau konten sistem proyek . Dalam proses
rekayasa perangkat lunak modern, di mana persyaratan dan desain serta pelaksanaan ditangkap
dalam notasi ketat di awal siklus hidup , kontrol versi resmi diterapkan untuk semua artefak ini
( Royce , 1998) . Sistem kontrol versi biasanya mendokumentasikan perubahan dalam hal siapa,
apa , mengapa , dan ketika perubahan yang dilakukan , serta menjaga pengembang dari
menginjak kaki satu sama lain . Sistem kontrol versi juga memelihara informasi yang bisa
membuat dan / atau menyetujui apa jenis perubahan dan mempertahankan salinan arsip dari
semua versi artefak , menangani penamaan dan penomoran aturan , sehingga memberikan
ketertelusuran perangkat lunak dan artefak terkait sepanjang siklus hidup produk. Sistem
kontrol versi biasanya mengelola perubahan ke kode sumber dan artefak terkait baik karena
proyek perubahan tingkat ( perubahan persyaratan dan penambahan ) dan karena perubahan
internal seperti bug atau dibutuhkan pendesainan ulang . Produk kontrol versi modern juga
mengkoordinasikan perubahan sehingga membangun dari versi tertentu menggunakan modul
yang sesuai dan arus .

Secara tradisional proses pembangunan untuk sebuah produk software yang terlibat kompilasi
dan menghubungkan operasi ; Namun , hari ini , dengan sistem berbasis web modern, ada
mungkin tidak ada menghubungkan atau kompilasi apapun. Namun, masih ada proses ( produksi
Java bytecode , enkripsi [ HTML , JavaScript , PHP ] , mengaburkan , dll ) yang perlu dilakukan
dalam membuat transisi dari kode sumber pengembang gunakan untuk kode yang diletakkan
pada produksi server (s) .

Komponen utama dari sistem manajemen kontrol versi adalah ( Brown , 1998)
Item Identifikasi
Pengidentifikasi produk ( nama dan nomor )
Pengidentifikasi artefak Produk
Identifikasi kriteria penerimaan produk
Identifikasi perubahan
Identifikasi rilis
mengubah Kontrol
Ubah kriteria
Revisi
Prosedur
ulasan organisasi
Status / Akuntansi
Catatan deskripsi produk
Catatan Ubah status
catatan verifikasi
Otorisasi dan persetujuan
Audit
Formal Ulasan Kualifikasi
Audit fisik
Audit fungsional

Ada beberapa produk komersial yang tersedia untuk kontrol versi beberapa di antaranya
berbasis server dan beberapa peer- to-peer berbasis , ini termasuk QVCS ( www.qumasoft.com )
, CS - RCS ( www.componentsoftware.com/ ) , Kode Co- op ( www.relisoft.com/ ) , Surround SCM
( www.seapine.com / surroundscm.html ) , dan CodeMatrix ( www.codematrix.com/ ) . Ada juga
sejumlah gratis , shareware , atau open source produk yang tersedia ( www.thefreecountry.com
/ pemrograman / versioncontrol.shtml ) .

Kontrol konfigurasi
Pengendalian modul software saling bergantung dan komponen perangkat keras pada klien dan
server platform biasanya disebut kontrol konfigurasi . Namun, terkadang kontrol konfigurasi
jangka diterapkan untuk kedua kontrol versi ( seperti yang dibahas sebelumnya ) dan konfigurasi
platform penyebaran . Untuk aplikasi client server , mungkin ada banyak modul software saling
bergantung masing-masing memerlukan versi tertentu dari modul lain untuk beroperasi .

Ini mungkin termasuk sistem operasi , sistem manajemen database , driver perangkat , protokol
komunikasi , dan banyak komponen perangkat lunak middleware . Ini lebih rumit karena
mungkin ada banyak versi dari modul software saling bergantung waktu tertentu dan / atau fitur.
Sebagai contoh, sebuah produk perangkat lunak mungkin dalam versi kelima , dengan delapan
kustomisasi yang berbeda diinstal pada ribuan komputer pelanggan , di mana setiap pelanggan
mungkin memiliki versi yang berbeda dan kustomisasi.

Dengan munculnya aplikasi Internet , protokol jaringan tunggal ( TCP / IP ) , dan thin client ,
organisasi yang dapat menghilangkan semua masalah kontrol konfigurasi mereka di sisi client (
karena satu-satunya perangkat lunak tingkat aplikasi client yang dibutuhkan adalah browser ) .

Selain itu, banyak isu kontrol konfigurasi pada sisi server juga dihilangkan karena setelah versi
baru dari aplikasi ditempatkan di server itu didownload ke klien ketika mereka pertama kali
diakses sistem ( download HTML , JavaScript , CSS , dan gambar atau lainnya file multimedia ) .
Namun, dengan kebutuhan ( atau kesempatan ) untuk menjual barang atau jasa secara global
sekarang , masalah kontrol konfigurasi telah muncul kembali dalam bentuk yang berbeda karena
konten web mungkin harus " lokal " untuk bahasa yang berbeda , negara , dan demografi .

lingkup Creep
Lingkup creep sangat umum dalam proyek IT . Pelanggan harus mendapatkan apa yang mereka
minta dan harapkan, tidak lebih dan tidak kurang . Memberikan pelanggan bekerja ekstra disebut
penyepuhan emas . Namun, karena sebagian besar proyek TI tidak berhasil , Anda tidak harus
melakukan pekerjaan tambahan bagi pelanggan karena Anda mungkin tidak mendapatkan
kompensasi untuk itu , dan Anda tahu pasti bahwa pelanggan benar-benar ingin pekerjaan yang
dilakukan . Lingkup creep begitu umum karena bersifat alami bagi anggota tim proyek untuk
ingin menyenangkan pelanggan mereka , dan sebagian besar komunikasi antara anggota tim
proyek dan personil pelanggan berlangsung tanpa keterlibatan PM . Hal ini juga tidak biasa bagi
anggota proyek ( khususnya di IT dan dalam pekerjaan teknis lainnya ) untuk ingin menjelajahi
rincian teknis melampaui batas-batas tugas . PM harus memastikan bahwa semua pemangku
kepentingan tahu apa yang tercakup dalam ruang lingkup dan juga apa yang bukan bagian dari
ruang lingkup proyek ; perbedaan ini paling baik dilakukan di awal proyek . Para anggota tim
proyek ( dan PMS ) harus dididik ( dan mengingatkan ) tentang perlunya untuk mencegah scope
creep dan untuk pengendalian perubahan formal.

Perangkat Lunak Manajer Program Jaringan ( Brown , 1998) berisi praktek-praktek terbaik untuk
perubahan dan kontrol versi :
• pekerjaan manajemen perubahan Membuat semua orang
• Menciptakan lingkungan dan proses yang memungkinkan manajemen perubahan
• Menetapkan dan mendokumentasikan proses, kemudian pilih alat ditetapkan untuk
mendukungnya
• Staf pengendalian perubahan harus terdiri dari individu-individu dengan keahlian teknis untuk
mendukung pengembangan dan pemeliharaan produk
• Rencana dan prosedur perubahan perlu dikembangkan dan didokumentasikan dengan cara
yang sama bahwa rencana pembangunan yang dibuat pada awal proyek Mereka juga menetapkan
aturan berikut untuk manajemen perubahan yang berhasil ( Brown , 1998) :
• Sistem manajemen perubahan harus " memiliki " informasi produk
• identifikasi dan kontrol produk dan artefak dini sangat penting
• Proses manajemen perubahan dan prosedur harus sederhana dan didukung oleh metode dan
peralatan yang digunakan dalam pengembangan produk
• Tindakan dewan pengendalian perubahan harus didokumentasikan
• Ubah kontrol harus menjadi fokus utama dan diintegrasikan ke dalam budaya organisasi
• Semua informasi yang ditempatkan di bawah pengendalian perubahan harus " dipromosikan
"melalui kualitas ( stage ) " gerbang "
• Semua perubahan yang diusulkan harus benar diklasifikasikan ( untuk jenis perubahan )
• Semua rilis kode dan artefak dari perpustakaan ( check- out dan check- in ) harus dicatat
• Sangat penting bahwa sistem pengendalian perubahan harus terus-menerus menyadari status
produk / artefak bawah kontrol dan hubungan dari satu produk / artefak lain
• Cara terburuk untuk membangun kontrol perubahan adalah untuk membeli alat set dan
kemudian untuk menyesuaikan proses Anda untuk alat

Rekayasa Perangkat Lunak Institute ( SEI , www.sei.cmu.edu / cmm ) CMM mendefinisikan

diperlukan Level 2 praktik untuk manajemen konfigurasi perangkat lunak ( pengendalian
perubahan ) :
• Apakah kegiatan pengendalian perubahan direncanakan untuk proyek tersebut ?
• Apakah proyek diidentifikasi , dikendalikan , dan tersedia produk-produk perangkat lunak
melalui penggunaan manajemen konfigurasi ?
• Apakah proyek mengikuti prosedur terdokumentasi untuk mengendalikan perubahan dan
konfigurasi ?
• Apakah laporan standar pada dasar perangkat lunak yang didistribusikan kepada pihak yang
terkena dampak ?
• Apakah proyek mengikuti kebijakan tertulis untuk melaksanakan kegiatan pengendalian
perubahan ?
• Apakah personil proyek dilatih untuk melakukan kegiatan-kegiatan pengendalian perubahan ?
• Apakah pengukuran yang digunakan untuk menentukan status kegiatan pengendalian
perubahan ?
• Apakah audit secara periodik yang dilakukan untuk memverifikasi bahwa perangkat lunak
baseline sesuai dengan dokumentasi di mana mereka didefinisikan ?

Ada juga standar industri (IEEE 828) dan standar militer ( MIL - STD 973 , 2549 ) yang dapat
digunakan sebagai pedoman lebih lanjut dalam menyiapkan perubahan , versi , dan sistem
kontrol konfigurasi . Sistem perangkat lunak yang tersedia untuk membantu dalam pengendalian
manajemen perubahan proyek . Serta fitur yang dibangun ke dalam sistem perangkat lunak
manajemen proyek umum seperti FiveAndDime , ada software yang didedikasikan untuk proyek
manajemen perubahan seperti TrackWise ( www.sparta - systems.com ) , SeaPine (
www.seapine.com / cmsuite.html ) , Software Planner ( www.softwareplanner.com ) , dan
ChangeManagementExpert ( www.change-management-expert.com/ ) .

proyek obral
Manajemen harus , di beberapa titik , berhenti mengambil perintah perubahan , dan proyek resmi
harus diakhiri . Permintaan tambahan untuk perubahan dapat ditangguhkan ke versi berturut-
turut produk atau ditangguhkan sampai produk secara resmi dipindahkan ke tahap operasi dan
pemeliharaan . Pengaturan kontrak asli ( tertulis atau tersirat ) akan sering menentukan ( atau
menyarankan ) waktu proyek harus berakhir . Hal ini biasanya setelah semua lingkup asli selesai
ditambah perintah perubahan penting yang harus dilakukan sebelum produk ditempatkan dalam
pelayanan . Dalam banyak proyek TI , datang ke penutupan mungkin sulit :
• Kadang-kadang proyek akan melanjutkan bila dana yang tersedia , bahkan ketika anggaran dan
jadwal yang jauh melebihi ; ini sering disebabkan kesalahpahaman manajemen dari " biaya
hangus " dan / atau kurangnya jelas pembenaran bisnis asli .
• Kadang-kadang sulit untuk memanggil mengakhiri proyek ketika stills organisasi manfaat
menginginkan lebih banyak perubahan ( dan bersedia membayar untuk mereka ) dan organisasi
melakukan ingin melakukan pekerjaan .
• Kadang-kadang pembeli ( yang sering organisasi menguntungkan ) tidak akan menandatangani
penerimaan resmi sampai beberapa masalah ( s ) teratasi .
• Kadang-kadang tim proyek ingin melanjutkan karena beberapa dari mereka mungkin khawatir
tentang : tugas masa depan , ruang lingkup yang signifikan belum selesai belum , kiriman
dokumentasi belum selesai , dan bug atau masalah masih ada ( meskipun mereka mungkin belum
memiliki muncul dalam pengujian ) .

Obral proyek dapat menjadi sangat sibuk dan waktu juga dapat menjadi waktu kesesakan atau
kegembiraan bagi para pemangku kepentingan yang berbeda . PM harus berhati-hati bahwa
semua tugas dan masalah sepenuhnya dan benar selesai . Anggota tim mungkin khawatir tentang
pekerjaan masa depan setelah proyek selesai atau mereka mungkin terlalu bersemangat untuk
melanjutkan proyek berikutnya . Tapi kecuali yang diproyeksikan akan berakhir , dan yang baru
dimulai jika perlu , pekerjaan yang dilakukan tidak akan lagi sesuai dengan tujuan awal dan
justifikasi bisnis .

Proyek mungkin akan berhasil menyelesaikan dan mengakhiri normal atau mereka dapat
dihentikan normal . Sebuah proyek mungkin berakhir normal (mungkin dalam waktu dan
anggaran kendala ) meskipun manajemen mungkin memutuskan untuk tidak menggunakan
produk ( memasukkannya ke dalam operasi ) . Keputusan ini mungkin untuk sejumlah alasan ,
termasuk :
• Produk ini tidak lagi diperlukan atau diinginkan oleh pengguna akhir .
• Kondisi ekonomi memiliki perubahan , dan nilai bisnis tidak bisa lagi diwujudkan .
• Produk tidak dapat dioperasikan secara ekonomis .
• Resources telah habis.
• Produk ini tidak cukup aman .
• Produk tidak dapat dipertahankan secara ekonomis .
• Produk ini tidak cukup " dapat digunakan . "
• Produk ini memiliki cacat desain utama .
• Produk ini penuh dengan bug .
• Produk tidak sesuai dengan standar atau peraturan yang berlaku .
• Proyek sponsor ( " juara " ) tidak lagi mendukung usaha.
• produk alternatif lain telah terbukti lebih efektif .

Kondisi ini bisa juga terjadi pada review gerbang panggung, dan proyek bisa saja prematur
dibatalkan atau ditunda . Kriteria ini merupakan bagian dari tinjauan kualitas tahap gerbang
sebagaimana didefinisikan dalam buku ini , dan organisasi dapat menghemat sejumlah besar
uang dan usaha dengan menemukan salah satu masalah sebelum proyek sepenuhnya selesai .

Setiap kali sebuah proyek dibatalkan atau ditunda , PM harus berkonsultasi dengan para
pemangku kepentingan utama dan kantor administrasi ( misalnya , hukum , SDM , dan kantor
pengadaan / kontrak ) untuk menentukan dampak dari pembatalan dan tindakan mitigasi yang
mungkin diperlukan . Untuk meminimalkan dampak organisasi pada kedua pertunjukan dan
organisasi menguntungkan , rencana pembatalan resmi mungkin diperlukan , dan semua
pemangku kepentingan harus diberitahu tentang pembatalan pada waktu yang tepat dan dengan
cara yang tepat . Rencana pembatalan juga harus mencakup langkah-langkah untuk
menyelamatkan komponen yang masih bisa di gunakan.

Bila proyek ini selesai , baik normal atau tidak normal ( terus atau membatalkan ) , beberapa
kegiatan penting yang harus dilakukan antara lain:
• audit Pengadaan dan kontrak ( s ) obral
• validasi dan verifikasi produk , termasuk perintah perubahan
• Konfirmasi kiriman
• inspeksi Formal dan verifikasi kepatuhan oleh regulator
• penerimaan Formal dan sign off " oleh pembeli atau menguntungkan organisasi
• Pemberitahuan penyelesaian kepada seluruh pemangku kepentingan
• Formal " turnover " untuk operasi / pelanggan
• review dan pelajaran Postproject belajar dokumentasi
• perincian dari perintah perubahan yang tidak dilakukan ( ditangguhkan atau ditolak )
• Memperbarui dan penutupan waktu proyek , biaya , dan catatan lain
• Benar arsip dari semua catatan dan artefak
• Turnover informasi yang relevan dengan PM dari fase berikutnya / versi produk
• Pengakuan dukungan dari stakeholder kunci
• Pengakuan kontribusi yang luar biasa
• Melepaskan sumber daya proyek , termasuk rekening keuangan dan barang-barang keamanan
• Tim formal melepaskan

Bentuk obral proyek atau checklist sering digunakan . Gambar 11.5 adalah contoh bentuk proyek
obral sederhana . Dalam beberapa organisasi , proyek obral dibagi menjadi tiga bagian : obral
administrasi , kontrak obral , dan personil obral .

Obral Administrasi dilakukan oleh PM dan tim proyek dalam hubungannya dengan manajemen
lini organisasi melakukan dan memastikan bahwa semua hal proyek , termasuk semua
penagihan, telah selesai . Kontrak obral dilakukan oleh kantor pengadaan dan memastikan bahwa
semua kontrak selesai dengan baik , semua vendor dibayar , dan semua masalah persediaan
diselesaikan. Personil obral dilakukan oleh kantor HR , yang menangani evaluasi akhir personil
(biasanya dilakukan oleh PM ) , kembalinya check -out peralatan dan barang-barang lainnya , dan
masalah keamanan akhir . Anggota tim proyek ( kelompok atau individu ) harus benar dilepaskan
ketika peran mereka pada proyek berakhir . Jika mereka dilepaskan dengan cara yang tepat dan
tepat waktu , biaya akan berkurang dengan tidak harus membuat pekerjaan mereka sampai
mereka dipindahkan ke proyek lainnya . Hal ini juga meningkatkan semangat kerja dengan
mengurangi ketidakpastian tentang tugas proyek masa depan atau kesempatan kerja . Pertemuan
tim akhir harus diadakan agar semua kegiatan penutupan dapat dikoordinasikan dan mortem
posting dilakukan yang menjawab pertanyaan-pertanyaan berikut :
• Apakah pembenaran bisnis menyadari ( atau tidak muncul bahwa hal itu akan terwujud ) ? Jika
tidak, mengapa tidak ?
• Proses apa , metode, alat , teknik , dan sumber daya bekerja dengan baik ?
• Proses apa , metode, alat , teknik , dan sumber daya tidak bekerja dengan baik ?

Figure 11.5. Project closeout form

• Apa risiko peristiwa yang terjadi dan bagaimana mereka ditangani ?
• Apa risiko kejadian yang tidak terjadi ? Mengapa tidak ?
• artefak dan komponen apa yang bisa digunakan kembali ?
• Apa yang secara umum harus dilakukan secara berbeda pada proyek tersebut
selanjutnya?

Semua pertanyaan ini harus dijawab dan didokumentasikan . Selain itu, dokumentasi ini
harus dirumuskan sedemikian rupa sehingga benar-benar akan digunakan . Jawaban atas
posting ini mortem dapat dimasukkan ke dalam sistem software pelajaran - belajar.
Proses ini , serta manajemen pengetahuan pada umumnya , dibahas lebih lanjut dalam
Bab XVI .

Sebuah tinjauan gerbang tahap akhir akan diperlukan jika proses gating panggung
digunakan . Sebuah contoh dari bentuk gerbang tahap tinjauan diilustrasikan pada
Gambar 11.6 . Ini meninjau kualitas tahap gerbang akhir memberikan pandangan akhir
dari faktor penentu keberhasilan proyek : penyelesaian dan kepuasan . Apakah atau tidak
laporan gerbang tahap akhir digunakan , itu adalah umum untuk laporan proyek obral
akhir yang akan dibuat . Bahwa laporan akhir termasuk informasi yang ditampilkan pada
Gambar 11.5 dan 11.6 , termasuk kemajuan akhir , waktu , dan biaya . Seringkali
pertemuan obral terpisah diadakan dengan organisasi menguntungkan dan mungkin
dengan pengguna akhir . Dalam pertemuan obral ini , pengguna akhir diperkenalkan
dengan operasi dan dukungan orang-orang dengan siapa mereka dapat bekerja di masa
depan . Seringkali organisasi melakukan menggunakan pertemuan ini
sebagai kesempatan untuk memperkenalkan atau mendiskusikan kemungkinan untuk
ekstensi produk atau perangkat tambahan . Untuk proyek yang sukses , banyak organisasi
juga memiliki pesta perayaan untuk tim proyek dan stakeholder kunci lainnya . Untuk
proyek yang gagal , banyak organisasi memiliki luar tinjauan auditor independen cara
proyek ini berhasil.
Figure 11.6. Final stage gate review form
Bab Summary
Dalam bab ini, proyek manajemen perubahan umum telah tertutup, terutama untuk proyek-
proyek TI kontrol versi dan kontrol konfigurasi. Sebuah masalah serius bagi proyek TI adalah
selalu "scope creep," dan topik ini juga dibahas. Obral proyek dan topik terkait juga disertakan
dan diilustrasikan.

Referensi
Brown, N. (1998, November). Little book of configuration management. Software Program Managers Network.
Hallows, J. (1998). Information systems project management. American Management Association.
PMI. (2000). The Project Management Body of Knowledge (PMBOK). Project Management Institute. ISBN 1-
880410-22-2.
Royce, W. (1998). Software project management. Addison-Wesley.