Konfigurasi pengelolaan

Tujuan
Tujuan bab ini adalah mengenalkan Anda pada konfigurasi
proses dan alat manajemen. Bila Anda telah membaca bab ini,
kamu akan:
 memahami proses dan prosedur yang terlibat dalam perubahan perangkat
lunak pengelolaan;
 mengetahui fungsi penting yang harus disediakan oleh sebuah versi sistem manajemen,
dan hubungan antar versi pengelolaan dan pembangunan sistem;
 memahami perbedaan antara versi sistem dan sistem lepaskan, dan ketahuilah tahapan
dalam proses pelepasan manajemen.

Isi
25.1 Manajemen perubahan
25.2 Manajemen versi
25.3 Pembangunan sistem
25.4 Pelepasan manajemen

Sistem perangkat lunak selalu berubah selama pengembangan dan penggunaan. Bug
ditemukan dan harus diperbaiki. Persyaratan sistem berubah, dan Anda harus menerapkan
perubahan ini dalam versi sistem yang baru. Versi baru perangkat keras dan platform
sistem tersedia dan Anda harus menyesuaikan sistem Anda untuk bekerja dengannya. Pesaing
mengenalkan fitur baru di batang sy mereka yang harus Anda serasi. Seiring perubahan pada
perangkat lunak, versi baru dari ystem dibuat. Oleh karena itu, sebagian besar sistem dapat
dianggap sebagai serangkaian versi, yang harus dipelihara dan dikelola.
Manajemen konfigurasi (CM) berkaitan dengan kebijakan, proses, dan alat untuk
mengelola perubahan sistem perangkat lunak. Anda perlu mengelola sistem yang
berkembang karena mudah kehilangan jejak versi chan ges dan komponen apa yang
telah digabungkan ke dalam setiap versi sistem. V ersions menerapkan proposal
untuk perubahan, koreksi kesalahan, dan adaptasi untuk perangkat keras dan sistem operasi
yang berbeda. Mungkin ada beberapa versi di bawah pengembangan dev dan digunakan pada
saat bersamaan . Jika Anda tidak memiliki prosedur pengaturan gement mana yang
efektif , mungkin Anda bisa membuang sedikit modifikasi versi sy yang salah, memberikan
versi sistem yang salah kepada pelanggan, atau lupa di mana kode
sumber softwa untuk versi tertentu dari sistematau komponen disimpan.
Manajemen konfigurasi berguna untuk proyek individu karena mudah untuk satu
proyek orang lupa perubahan apa yang telah dilakukan Ini penting bagi proyek tim
dimana beberapa pengembang bekerja bersamaan pada sistem perangkat lunak. Terkadang para
pengembang ini bekerja di tempat yang sama namun, semakin, tim pengembang didistribusikan
dengan anggota di berbagai lokasi di seluruh dunia. Penggunaan sistem manajemen konfigurasi
memastikan bahwa t eams memiliki akses ke informasi tentang sistem yang sedang
dikembangkan dan tidak mengganggu pekerjaan masing-masing.
Manajemen konfigurasi produk sistem perangkat lunak melibatkan empat kegiatan yang
terkait erat (Gambar 25.1):
1. Manajemen perubahan Ini melibatkan pelacakan permintaan perubahan perangkat lunak
dari pelanggan dan pengembang, mengerjakan biaya dan dampaknya membuat perubahan ini,
dan memutuskan apakah dan kapan harus berubah diimplementasikan
2. Manajemen versi Ini mencakup pembuatan beberapa versi komponen sistem dan
memastikan perubahan yang dibuat pada komponen secara berbeda pengembang tidak saling
mengganggu.
3. Sistem bangunan Ini adalah proses perakitan komponen program, data, dan perpustakaan,
dan kemudian kompilasi dan menghubungkannya untuk menciptakan sistem eksekusi.
4. Melepaskan manajemen Ini melibatkan persiapan perangkat lunak untuk pelepasan
eksternal dan mencatat versi sistem yang telah dirilis untuk penggunaan pelanggan.

Manajemen konfigurasi melibatkan sejumlah besar informasi dan banyak alat manajemen
konfigurasi telah dikembangkan untuk mendukung CM
Manajemen rilis
Ubah Proposal
Manajemen Perubahan
Sistem Pers
Komponen Versi
Versi sistem
Manajemen Versi
Bangunan sistem

Gambar 25.1
Aktivitas pengelolaan konfigurasi

proses. Ini berkisar dari alat sederhana yang mendukung satu tugas pengelolaan konfigurasi
tunggal , seperti pelacakan bug, hingga kompleksitas perangkat terintegrasi yang canggih yang
mendukung semuaaktivitas pengelolaan confi guration.
Kebijakan dan proses pengelolaan konfigurasi menentukan bagaimana cara merekam
dan proses perubahan sistem yang diusulkan, bagaimana cara membedakan komponen sistem
apa yang akanberubah, bagaimana mengelola berbagai versi sistem dan komponennya,
dan bagaimana mengubah perubahan pada pelanggan. Alat pengelolaan konfigurasi
adalah digunakan untuk melacak proposal perubahan, menyimpan versi komponen
sistem, membangun sistem dari komponen ini, dan melacak pelepasan versi sistem kepada
pelanggan.
Manajemen konfigurasi terkadang dianggap sebagai bagian dari perangkat
lunak manajemen mutu (dibahas dalam Bab 24 ), dengan manajer yang sama memiliki tanggung
jawab manajemen dan konfigurasi manajemen yang baik. Bila versi baru perangkat lunak telah
diterapkan , ini diserahkan oleh tim pengembang ke tim penjaminan mutu (QA ). Tim QA
memeriksa bahwa kualitas sistem dapat diterima. Jika demikian, maka jadilah sistem yang
terkendali,
yang berarti bahwa semua perubahan pada sistem harus disepakati dan dicatat sebelum
diterapkan.
Definisi dan penggunaan standar manajemen konfigurasi sangat penting sertifikasi mutu
baik standar ISO 9000 dan CMM dan CMMI (Ahern et al ., 2001; Bamford dan Deibler, 2003;
Pa ulk et al., 1995; Peach, 1996). Standar CM ini dapat didasarkan pada standar sta CM
generik yang telah dikembangkan oleh badan seperti IEEE. Misalnya standar IEEE 828-1998
adalah standar untuk rencana manajemen konfigurasi. Standar ini berfokus pada proses CM dan
dokumen yang dihasilkan selama proses CM . Dengan menggunakan standar eksternal sebagai
titik awal, perusahaan kemudian mengembangkan standar spesifik perusahaan yang lebih rinci
yang diberikan pada kebutuhan spesifik mereka.
Salah satu masalah dalam manajemen konfigurasi adalah bahwa perusahaan yang
berbeda membicarakan konsep yang sama dengan menggunakan istilah yang berbeda. Ada yang
bersejarah
Penjelasan Term
Konfigurasi item atau konfigurasi perangkat lunak
item (SCI)

Apa pun yang terkait dengan proyek perangkat lunak (des ign, code, test data, document, etc.)
yang telah ditempatkan di bawah konfigurasi con trol. Sering ada versi yang berbeda dari item
konfigurasi. Itemkonfigurasi memiliki nama yang unik.

Kontrol konfigurasi

Proses untuk memastikan bahwa versi sistem dan komponen dicatat dan dipertahankan sehingga
perubahan dikelola dan semua versi komponen diidentifikasi dan disimpan untuk masa pakai
sistem. Versi Sebuah instance dari item konfigurasi yang berbeda, dalam beberapa hal, dari
contoh lain dari item itu. Versi selalu memiliki unique ident ier, yang sering terdiri dari nama
item konfigurasi ditambah nomor versi.

Baseline

Sebuah baseline adalah kumpulan versi komponen yang membentuk sebuah sistem. Dasar-
dasar dikendalikan, yang berarti bahwa versi komponen yang membentuk sistem tidak dapat
diubah. Ini berarti bahwa sebaiknya selalu menciptakan kembali garis dasar dari komponen
penyusunnya.

Codeline
Sebuah codeline adalah seperangkat versi perangkat lunak mponent dan item konfigurasi lainnya
yang menjadi komponennya.

Garis utama
Urutan garis dasar yang mewakili berbagai versi sistem.
Melepaskan
Versi sistem yang telah dilepaskan ke pelanggan (atau pengguna lain di
organisasi) untuk digunakan.

Ruang kerja
Area kerja pribadi di mana perangkat lunak dapat dimusnahkan tanpa
mempengaruhi pengembang lain yang mungkin menggunakan atau memodifikasi perangkat
lunak itu.

Percabangan
Pembuatan codeline baru dari versi n codeline yang ada. Codeline baru dan codeline yang ada
kemudian dapat dikembangkan secara independen.

Penggabungan
Pembuatan versi baru komponen softwar e dengan menggabungkan versi terpisah dengan kode
kode yang berbeda. Ines codel ini mungkin telah dibuat oleh cabang sebelumnya dari salah satu
kode kode yang terlibat.

Sistem bangunan
Pembuatan versi sistem yang dapat dijalankan dengan mengkompilasi dan menghubungkan versi
komponen dan perpustakaan yang sesuai dengan sistem.

Gambar 25.2 CM
terminologi

alasan untuk ini Sistem perangkat lunak militer wer e mungkin sistem pertama di mana
manajemen konfigurasi digunakan dan terminologi untuk syst ini ems mencerminkan proses dan
prosedur yang sudah di p renda
untuk manajemen konfigurasi hardware. Pengembang syste ms komersial tidak terbiasa dengan
prosedur militer atau terminologi dan sering menemukan istilah mereka sendiri . Metode tangkas
juga telah menemukan teologi baru, kadang-kadang diperkenalkan dengan sengaja untuk
membedakan pendekatan tangkas dari metode CM tradisional. Gambar 25.2
mendefinisikan terminologi konfigurasinagement yang saya gunakan dalam bab ini.
Penjelasan Term
25. Manajemen perubahan
Perubahan adalah fakta hidup untuk sistem perangkat lunak besar. Kebutuhan dan persyaratan
kebutuhan Organi berubah selama masa sistem, bug tidak dapat diperbaiki, dan sistem
harus menyesuaikan diri dengan perubahan di lingkungan mereka. Untuk memastikan
bahwa perubahan tersebut diterapkan pada sistem dengan cara yang terkendali, Anda
memerlukan seperangkat proses manajemen perubahan yang didukung, diubah . Manajemen
perubahan dimaksudkan untuk memastikan bahwa evolusi sistem tersebut merupakan proses
yang terkelola dan prioritas tersebut diberikan pada perubahan yang paling mendesak dan hemat
biaya.

Proses manajemen perubahan berkaitan dengan analisis biaya dan manfaat dari
perubahan yang diusulkan, menyetujui perubahan tersebut pada manfaatnya, dan
melacak komponen mana dalam sistem yang telah diubah . Gambar 25.3 adalah model proses
manajemen perubahan yang menunjukkan bahwa prinsipal mengubah aktivitas manajemen. Ada
banyak varian dari proses ini yang digunakan namun,agar efektif, proses manajemen
perubahan harus selalu memiliki cara untuk mengurangi, mengorbankan, dan
menyetujui perubahan. Proses ini harus mulai berlaku saat perangkat lunak diserahkan
untukdilepaskan ke pelanggan atau untuk kepentingan deplesi dalam sebuah organisasi.
Proses manajemen perubahan dimulai saat 'pelanggan' selesai dan mengajukan
permintaan perubahan yang menjelaskan perubahan yang diperlukan pada sistem. Ini bisa
Dukungan Pelanggan
Pengembangan
Menyerahkan
CR
Pelanggan
Pengembangan Produk / CCB
Perubahan
Permintaan
Pilih CRs
Tutup CRs
Menilai CRs
Valid tidak sah
Tutup CR Register CR
Periksa CR
Lulus
Gagal
Tutup CR
Pelaksanaan
Analisis
Dampak biaya
Analisis
Memodifikasi
Perangkat lunak
Uji Perangkat Lunak
686 Bab 25 _ manajemen konfigurasi
Gambar 25.4 Sebagian
selesai ganti
form Permintaan

jadilah laporan bug, di mana gejala bug dijelaskan, atau permintaan fungsionalitas tambahan
untuk ditambahkan ke batang sy . Beberapa perusahaan menangani laporan bug dan persyaratan
baru secara terpisah namun, secara umum , keduanya hanya mengubah permintaan. Permintaan
perubahan dapat diajukan dengan menggunakan formulir permintaan perubahan ( change request
form / CRF). Saya menggunakan istilah 'pelanggan' di sini untuk menyertakan pemangku
kepentingan yang bukan bagian dari tim pengembang, jadi perubahan mungkin disarankan ,
misalnya oleh departemen pemasaran di perusahaan.
Permintaan perubahan elektronik mencatat informasi yang dibagi antara semua kelompok
yang terlibat dalam manajemen perubahan. Saat pencarian perubahan kembali diproses,
informasiditambahkan ke CRF untuk mencatat keputusan yang dibuat setiap tahapan
prosesnya. Setiap saat, oleh karena itu merupakan gambaran dari keadaan permintaan
perubahan. Serta mencatat perubahan yang diperlukan, CRF mencatat rekomendasi
mengenai perubahan tersebut; perkiraan biaya perubahan; suatu tanggal ketika perubahan
itu diminta, disetujui, diimplementasikan, dan divalidasi. CRF mungkin juga termasuk bagian
di mana pengembang menguraikan bagaimana perubahan dapat diimplementasikan.
Contoh formulir permintaan perubahan yang sebagian telah selesai ditunjukkan pada
Gambar 25.4. Ini adalah contoh jenis CRF yang mungkin digunakan dalam proyek
rekayasa sistem kompleks yang besar . Untuk proyek yang lebih kecil, saya recomm akhir
bahwa permintaan perubahan harus dicatat secara formal dan CRF harus berfokus
pada penggambaran perubahan yang diperlukan, dengan penekanan lebih sedikit pada masalah
implementasi. Sebagai pengembang ystem, Anda memutuskan bagaimana menerapkan
perubahan itu dan memperkirakan waktu yang dibutuhkan untuk ini.

Ubah Formulir Permintaan

Proyek: SICSA / AppProcessing Number: 23/02
Ubah pemohon: I. Sommerville Tanggal: 20/01/09
Perubahan yang diminta: Status pemohon (ditolak, diterima, dll.) Harus ditunjukkan
secara visual dalam daftar pemohon yang ditampilkan.
Change analyzer: R. Looek Tanggal analisis: 25/01/09
Komponen yang terpengaruh: PemohonListDisplay, StatusUpdater
Komponen terkait: StudentDatabase
Ubah penilaian: Relatif mudah diterapkan dengan mengubah warna tampilan
sesuai status Meja harus ditambahkan untuk menghubungkan status dengan warna. Tidak ada
perubahan
komponen terkait diperlukan
Ubah prioritas: Sedang
Mengubah implementasi:
Diperkirakan usaha: 2 jam
Tanggal ke aplikasi SGA. tim: 28/01/09 Tanggal keputusan CCB: 30/01/09
Keputusan: Terima perubahan. Perubahan yang akan diimplementasikan di Release 1.2
Ganti pelaksana: Tanggal perubahan:
Tanggal diserahkan ke QA: Keputusan QA:
Tanggal diserahkan ke CM:
Komentar:

Setelah permintaan perubahan diajukan, dicek untuk memastikan validasinya. Pemeriksa

dapat berasal dari tim dukungan pelanggan atau aplikator atau, untuk permintaan internal ,
mungkin merupakan anggota tim pengembang . Pemeriksaan diperlukan karena tidak semua
permintaan perubahan memerlukan tindakan. Jika perubahan r equest adalah laporan bug,
bug mungkin telah dilaporkan.Terkadang, yang paling penting adalah
masalah sebenarnya adalah kesalahpahaman tentang apa yang harus diselesaikan oleh
sistem . Terkadang, orang meminta fitur yang sudah ada implikasi tapi yang tidak mereka
ketahui . Jika salah satu dari ini benar, permintaan perubahan ditutup dan formulir
diperbarui dengan alasan penutupan. Jika itu adalah permintaan perubahan yang valid, maka
saya kemudian masuk sebagai permintaan yang luar biasa untuk analisis selanjutnya.
Untuk permintaan perubahan yang valid, tahap selanjutnya dari proses ini adalah
penilaian perubahan dan biaya. Ini biasanya merupakan tanggung jawab tim pengembang atau
pemeliharaan karenamereka dapat mengetahui apa yang terlibat dalam penerapan
chan ge. Dampak dari perubahan pada sisa sistem harus diperiksa. Untuk melakukan ini, Anda
harus mengidentifikasi semua komponen yang terpengaruh oleh perubahan
tersebut. Jika membuat perubahan berarti bahwa perubahan lebih lanjut di tempat lain dalam
sistem sangat dibutuhkan, ini jelas akan mengurangi biaya implementasi
perubahan.Selanjutnya, angsa ch yang dibutuhkan untuk modul sistem dinilai. Akhirnya, biaya
pembuatan perubahan diperkirakan, dengan mempertimbangkan
biaya untuk mengubah komponen terkait.
Setelah analisis ini, kelompok yang terpisah kemudian harus memutuskan apakah itu
efektif biaya dari perspektif bisnis untuk melakukan perubahan pada perangkat
lunak. Untuk sistem militer dan pemerintahan, kelompok ini sering disebut papan kontrol
perubahan (CCB). Di industri, bisa disebut sesuatu seperti ' kelompok pengembangan produk ',
siapa yang bertanggung jawab untuk membuat keputusan mengenai bagaimana sistem perangkat
lunak harus berkembang. Grup ini harus meninjau dan menerapkan semua permintaan
perubahan, kecuali jika perubahan hanya melibatkan koreksi kesalahan kecil pada tampilan
layar, halaman web, atau dokumen. Permintaan kecil ini harus diteruskan ke tim
pengembang tanpa analisis terperinci, karena analisis tersebut memerlukan biaya lebih besar
daripada menerapkan perubahan tersebut.
Grup pengembangan CCB atau produk mempertimbangkan dampak perubahan
dari strategis dan organisasional daripada sudut pandang teknis. Ini menentukan apakah
perubahan tersebut diperhitungkan secara ekonomis dan memprioritaskan perubahan
yang diterima untuk implementasi. Perubahan yang diterima dilewatkan kembali
ke kelompok pengembangan ; Permintaan ganti ditolak ditutup dan tidak ada tindakan er yang
diambil. Faktor penting yang harus dipertimbangkan dalam menentukan apakah perubahan
seharusnya terjadi atau tidak disetujui adalah:
1. Konsekuensi tidak membuat perubahan Saat menilai permintaan perubahan, Anda
harus mempertimbangkan apa yang akan terjadi jika perubahan tersebut tidak
dilaksanakan. Jika Perubahan dikaitkan dengan kegagalan sistem yang dilaporkan,
keseriusan kegagalan itu harus diperhitungkan. Jika kegagalan sistem menyebabkan sistem
mogok, Hal ini sangat serius dan kegagalan membuat perubahan bisa mengganggu
operasional penggunaan sistem Di sisi lain jika kegagalan memiliki efek minor,
seperti Warna salah pada layar, maka tidak penting untuk memperbaiki masalah dengan
cepat, jadi perubahan harus memiliki prioritas rendah.
 2. Manfaat dari perubahan adalah perubahan sesuatu yang akan menguntungkan
banyak pengguna dari sistem atau hanya sebuah proposal yang terutama akan bermanfaat
bagi ganti proposer
3. Jumlah pengguna yang terpengaruh oleh perubahan Jika hanya sedikit pengguna
yang terpengaruh, maka perubahan tersebut mungkin diberikan prioritas
rendah. Sebenarnya, membuat perubahan mungkin terjadi tidak disarankan jika bisa
berdampak buruk pada mayoritas pengguna sistem.
4. Biaya pembuatan perubahan Jika membuat perubahan mempengaruhi banyak
komponen sistem (sehingga meningkatkan kemungkinan mengenalkan bug baru) dan /
atau mengambil a Banyak waktu untuk diimplementasikan, maka perubahannya bisa
ditolak, mengingat kenaikan biaya yang terlibat
5. Siklus pelepasan produk Jika versi baru perangkat lunak baru saja
diluncurkan Bagi pelanggan, masuk akal jika menunda pelaksanaan perubahan
sampai rilis rencana berikutnya (lihat Bagian 25.3).

Mengubah manajemen untuk produk perangkat lunak (misalnya, produk sistem

CAD) daripada sistem yang dikembangkan khusus untuk pelanggan tertentu, harus
ditangani dengan cara yang sedikit berbeda. Dalam produk perangkat lunak, stomer cu tidak
terlibat langsung dalam keputusan tentang evolusi sistem, jadi relevansinya dengan perubahan
pada bisnis pelanggan bukanlah masalah. Perubahan permintaan untuk produk ini berasal
dari tim dukungan pelanggan , tim pemasaran perusahaan dan pengembangnya
sendiri. Permintaan ini mungkin mencerminkan saran dan umpan balik dari pelanggan
atauanalisis tentang apa yang ditawarkan oleh produk pesaing.
Tim dukungan pelanggan dapat mengirimkan perubahan yang terkait dengan bug yang telah
ditemukan dan dilaporkan oleh perangkat lunak setelah perangkat lunak
telah dilepaskan. Pelanggan dapat menggunakan halaman web atau e-mail untuk melaporkan
bug. Tim manajemen bug kemudian memeriksa bahwa laporan bug tersebut valid dan
menerjemahkannya ke dalam permintaan perubahan sistem secara formal . Staf pemasaran
bertemu dengan para kustomer dan menyelidiki produk kompetitif . Mereka mungkin
menyarankan perubahan yang harus disertakan d agar lebih mudah menjual sistem versi baru
ke pelanggan baru dan yang sudah ada. Pengembang sistem itu sendiri mungkin memiliki
beberapa gagasan bagus tentang fitur baru yang dapat ditambahkan ke sistem.
Proses permintaan perubahan yang ditunjukkan pada Gambar 25.3 digunakan setelah
sistem dilakukan dilepaskan ke pelanggan. Selama pengembangan, ketika versi baru
sistem dibuat melalui sistemd aily (atau lebih sering), manajemen perubahan yang lebih
sederhana proses biasanya digunakan Masalah dan perubahan harus tetap dicatat, tapi Perubahan
yang hanya mempengaruhi komponen dan modul individual tidak harus mandiri dinilai. Mereka
dilewatkan langsung ke pengembang sistem. Pengembang sistem baik menerima mereka atau
membuat kasus mengapa mereka tidak diperlukan. Namun, aOtoritas independen, seperti arsitek
sistem, harus menilai dan memprioritaskan Perubahan itu mempengaruhi modul sistem yang
telah dihasilkan berbeda tim pengembangan
Dalam beberapa metode tangkas, seperti pemrograman ekstrem, pelanggan secara
langsung terlibat dalam menentukan apakah suatu perubahan harus dilaksanakan. Saat mereka
mengajukan aMengubah persyaratan sistem, mereka bekerja dengan tim untuk menilai
dampaknya yang berubah dan kemudian memutuskan apakah perubahan harus diprioritaskan
pada fitur direncanakan untuk kenaikan berikutnya dari sistem. Namun, perubahan itu
melibatkan perbaikan perangkat lunak diserahkan kepada kebijaksanaan programmer yang
bekerja di sistem. Refactoring, dimana perangkat lunak terus ditingkatkan, tidak dilihat
sebagai overhead melainkan sebagai bagian penting dari proses pembangunan.
Seiring tim pengembang mengubah perangkat lunak , mereka harus mencatat perubahan
yang dilakukan pada masing-masing komponen. Ini kadang disebut derivasi sejarah
komponen. Cara yang baik untuk menjaga sejarah derivasi dalam standar komentar di awal kode
sumber komponen (Gambar 25.5). Komentar ini harus merujuk pada permintaan perubahan yang
memicu perangkat lunak perubahan.Anda kemudian dapat menulis skrip sederhana yang
memindai semua komponen dan memprosesnya derivasi untuk menghasilkan laporan perubahan
komponen. Untuk dokumen, catatan Perubahan yang tergabung dalam setiap versi biasanya
dipelihara di halaman terpisah di depan dokumen Saya membahas hal ini di bab web tentang
dokumentasi.
Manajemen perubahan biasanya didukung oleh perangkat lunak khusus. Ini Mungkin alat
berbasis web yang relatif sederhana seperti Bugzilla, yang biasa dilaporkan masalah dengan
banyak sistem open source. Sebagai alternatif, alat yang lebih kompleks mungkin ada digunakan
untuk mengotomatisasi seluruh proses penanganan permintaan perubahan dari pelanggan
awal proposal untuk mengubah persetujuan

Gambar 25.5
Sejarah Derivatif
// Proyek SICSA (XEP 6087)
//
// APP-SYSTEM / AUTH / RBAC / USER_ROLE
//
// Obyek: currentRole
// Pengarang: R. Looek
// Tanggal pembuatan: 13/11/2009
//
// © St Andrews University 2009
//
// Riwayat modifikasi
// Versi Modifier Date Change Reason
// 1.0 J. Jones 11/11/2009 Tambahkan tajuk Submitted to CM
// 1.1 R. Looek 13/11/2009 Bidang baru Ubah req. R07 / 02

Baseline - V1
A B1.2 C1.1
L1 L2 Ex1

Baseline - V2
A1.3 B1.2 C1.2
L1 L2 Ex2
Garis utama

Codeline (A) A1.1 A1.2 A1.3

Codeline (B) B B1.1 B1.2 B1.3
Codeline (C) C C1.1 C1.2 C1.3
Perpustakaan dan Komponen Eksternal
L1 L2 Ex1 Ex2

Gambar 25.6 Codelin

dan garis dasar

25.2 Manajemen versi

Manajemen versi (VM) adalah proses melacak diskusi-ver berbeda dari komponen perangkat
lunak atau item konfigurasi dan sy batang di mana komponen ini digunakan. Ini juga melibatkan
memastikan bahwa perubahan yang dilakukan oleh pengembang yang berbeda terhadap versi ini
tidak saling mengganggu. Anda bisa, karena itu, memikirkan manajemen sion ver sebagai proses
pengelolaan codelines dan baseline.
Gambar 25.6 mengilustrasikan perbedaan antara codelines dan baseline. Intinya, codeline
adalah urutan versi kode sou rce dengan versi yang lebih baru dalam urutan yang berasal dari
versi sebelumnya. Codelin es biasanya berlaku untuk komponen sistem sehingga ada beberapa
versi berbeda dari masing - masing komponen. Garis dasar adalah definisi sistem tertentu. Oleh
karena itu, baselinememalsukan versi komponen yang disertakan dalam sistem ditambah
spesifikasi perpustakaan yang digunakan, file konfigurasi , dan lain-lain. Pada Gambar 25.6,
Anda dapat melihat bahwa baseline yang berbeda menggunakan versi komponen yang berbeda
dari setiap codeline. Dalam diagram, saya telah menaungi kotak yang mewakili komponen
dalam definisi dasar untuk menunjukkan bahwa ini benar -benar mengacu pada komponen dalam
kodeks. M ainline adalah urutan versi sistem yang dikembangkan dari garis dasar asli.
Dasar-dasar dapat ditentukan menggunakan bahasa konfigurasi, yang memungkinkan
Anda melakukannya tentukan komponen apa saja yang termasuk dalam versi sistem
rhythular pa . Hal ini dimungkinkan untuk secara eksplisit menentukan versi komponen tertentu
( X.1, katakanlah) atau hanya untuk menentukan komponen identifier (X). Jika Anda
menggunakan identi fier, ini berarti versi terbaru komponen harus digunakan di baseline.
Dasar penting karena Anda sering harus membuat ulang versi tertentu sebuah sistem
yang lengkap Sebagai contoh, lini produk dapat dipakai sehingga ther e versi sistem individual
untuk pelanggan yang berbeda. Anda mungkin harus membuat ulang versi yang dikirimkan ke
pelanggan tertentu jika, misalnya , pelanggan melaporkan bug di sistem mereka yang harus
diperbaiki.
Untuk mendukung manajemen versi, Anda harus selalu menggunakan manajemen
versi alat (kadang disebut sistem kontrol versi atau sistem kontrol kode sumber).
Alat ini mengidentifikasi, menyimpan, dan mengendalikan akses ke komponen versi yang lebih
beragam. Ada banyak sistem manajemen versi yang berbeda yang tersedia, termasuk sistem
open source yang banyak digunakan seperti CVS dan S ubversion (Pilato et al.,
2004; Vesperman, 2003).
Sistem manajemen versi biasanya menyediakan berbagai fitur:
1. Identifikasi versi dan rilis Versi terkelola diberi pengenal saat mereka diserahkan ke
sistem. Pengenal ini biasanya didasarkan pada nama item konfigurasi (misalnya,
ButtonManager), diikuti oleh satu ataulebih banyak angka Jadi ButtonManager 1.3 berarti
versi ketiga dalam codeline 1 dari komponen ButtonManager Beberapa sistem CM juga
memungkinkan asosiasi atribut dengan versi (misalnya mobile, smallscreen), yang juga bisa
digunakan untuk identifikasi versi Sistem ntifikasi ide yang konsisten penting karena
menyederhanakan masalah dalam menentukan konfigurasi. Itu membuatnya lebih
sederhana untuk menggunakan referensi singkat (misalnya, * .V2 yang berarti versi 2 dari
semua komponen).
2. Manajemen penyimpanan Untuk mengurangi ruang penyimpanan yang dibutuhkan oleh
beberapa versi dari komponen yang sedikit berbeda, sistem manajemen versi
biasanya menyediakan fasilitas manajemen penyimpanan. Alih-alih menyimpan salinan
lengkap dari Setiap versi, sistem menyimpan daftar perbedaan (delta) antara satu versi dan
yang lainnya. Dengan menerapkan ini ke versi sumber (biasanya versi terbaru), versi target
bisa dibuat ulang. Hal ini diilustrasikan pada Gambar 25.7.
3. Mengubah rekaman sejarah Semua perubahan dibuat pada kode sistem atau komponen
dicatat dan terdaftar. Di beberapa sistem, perubahan ini bisa digunakan untuk memilih versi
sistem tertentu. Ini melibatkan komponen penandaan dengan kata kunci yang menjelaskan
perubahan yang terjadi. Anda kemudian menggunakan tag ini untuk memilih komponen untuk
dimasukkan dalam baseline.
4. Pengembangan independen Pengembang yang berbeda mungkin bekerja pada hal yang
sama komponen pada saat bersamaan. Sistem manajemen versi mencatat komponen yang
telah diperiksa untuk diedit dan memastikan perubahannya dibuat untuk komponen oleh
pengembang yang berbeda tidak mengganggu.
5. Dukungan proyek Sistem manajemen versi dapat mendukung pengembangan beberapa
proyek, yang berbagi komponen. Dalam sistem pendukung proyek, seperti

Tanggal Pembuatan
Urutan versi
Terakhir
Struktur Penyimpanan
Versi
1.0
Versi
1.1
Versi
1.2
Versi
1.3
D1 D2 D3
V1.3 Sumber
Kode
Gambar 25.7 Penyimpanan
manajemen menggunakan
delta

CVS (Vesperman, 2003), adalah mungkin untuk memeriksa dan memeriksa semua file terkait
dengan sebuah proyek daripada harus bekerja dengan satu file atau direktori pada satu waktu.

Ketika sistem manajemen versi pertama kali dikembangkan, manajemen

penyimpanan adalah salah satu fungsi terpenting mereka. Fitur penyimpanan anajemen
dalam sistem kontrol versi mengurangi ruang disk yang diperlukan untuk menjaga semua versi
sistem. Ketika versi baru dibuat, sistem ini hanya menyimpan delta (daftar perbedaan) antara
versi baru dan versi lama yang digunakan untuk membuat versi baru (ditunjukkan di bagian
bawah Gambar 25.7). Pada Gambar 25.7, kotak yang diarsir tersebut mewakili sebelumnya versi
komponen yang dibuat ulang secara otomatis dari versi komponen terbaru .Deltas biasanya
disimpan sebagai daftar garis yang berubah dan, dengan menerapkannya secara otomatis, satu
versi komponen dapat dibuat dari yang lain. Karena kemungkinan besar versi terbaru dari
komponen akan digunakan, sebagian besar sistem menyimpan versi itu secara
penuh. Delt seperti yang kemudian menentukan bagaimana membuat ulang versi sistem
sebelumnya.
Sebagian besar pengembangan perangkat lunak adalah aktivitas tim, sehingga situasi
sering muncul dimana berbeda Anggota tim mengerjakan komponen yang sama pada saat
bersamaan. Sebagai contoh, katakanlah Alice membuat beberapa perubahan pada sistem, whi ch
melibatkan perubahan komponen A, B, dan C. Pada saat yang sama, Bob bekerja untuk
perubahan dan ini memerlukan perubahan pada komponen X, Y, dan C. B. Alice dan
Bob berubah C. Penting untuk menghindari perubahan-perubahan ini dalam saling terfermentasi-
perubahan Bob terhadap C menimpa Alice's atau sebaliknya.
Untuk mendukung pengembangan mandiri tanpa gangguan, manajemen versi Sistem
menggunakan konsep repositori publik dan ruang kerja pribadi. Pengembang memeriksa
komponen dari gudang umum saya ke ruang kerja pribadi mereka dan mungkin mengubahnya
sesuai keinginan mereka dalam ruang wo pribadi mereka . Ketika perubahan mereka selesai,
mereka memeriksa komponen ke bagianutama. Hal ini diilustrasikan pada Gambar 25.8. Jika dua
atau lebih orang bekerja dengan baik pada saat bersamaan, masing-masing harus memeriksa
komponen dari sitori repo . Jika komponen telahdiperiksa, sistem manajemen versi biasanya
akan memperingatkan pengguna lain yang menginginkannya

Sistem Manajemen Versi

Alice Bob
Workspace (U2)
check_in check_out check_out check_out
C
AB
C
XY
ABCZXR
A1.1 B1.1 C1.1 YPQ
Ruang kerja (U1)
Gambar 25.8 Check-in
dan check out dari a
repositori versi
25.3 _ Pembangunan sistem 693
Codeline 1
Codeline 2
<branch>
<branch>
<gabung>
Codeline 2.1
V1.0 V1.1 V1.2
V2.2 V2.3
V2.1.1 V2.1.2
V2.0 V2.1 V2.4
Gambar 25.9 Cabang
dan penggabungan
untuk memeriksa komponen yang telah diperiksa oleh orang lain. Sistem juga akan memastikan
bahwa ketika komponen yang dimodifikasi diperiksa, versi yang berbeda diberi pengenal versi
berbeda dan disimpan secara terpisah.
Konsekuensi pengembangan independen dari komponen yang sama adalah itu kode kode
mungkin cabang Alih-alih urutan linear v ersions yang mencerminkan perubahan pada
komponen dari waktu ke waktu, mungkin ada beberapa urutan independen, seperti yang
ditunjukkan pada Gambar 25.9. Ini normal dalam pengembangan sistem, di mana pengembang
yang berbeda bekerja secara independen pada berbagai versi kode sumber dan mengubahnya
dengan cara yang berbeda.
Pada tahap tertentu, mungkin perlu menggabungkan cabang codeline untuk membuat
yang baru versi komponen yang mencakup semua perubahan yang telah dilakukan. Hal ini
juga ditunjukkan pada Gambar 25.9 dimana versi 2.1.2 dan 2.3 komponen digabungkan
untuk membuat versi 2.4. Jika perubahan yang dilakukan melibatkan sebagian komponen kode,
bagian komponen dapat digabungkan secaraotomatis oleh sistem manajemen versi dengan
menggabungkan delta yang sesuai dengan kode. Lebih sering, ada tumpang tindih antara
perubahan yang dilakukan dan saling terkait satu sama lain. Seorang pengembang harus
memeriksa bentrokan dan memodifikasi perubahan sehingga kompatibel.
25.3
Sistem bangunan
Pembuatan sistem adalah proses pembuatan sistem yang lengkap dan dapat dieksekusi dengan
mengkompilasi dan menghubungkan komponen sistem, rujukan libra eksternal , file konfigurasi,
dll. Peralatan pengembangan sistem dan perangkat manajemen versi harus berkomunikasi
karena proses pembuatannya melibatkan pengecekan komponen versi dari repositori dikelola
oleh sistem manajemen versi.Deskripsi konfigurasi yang digunakan untuk
mengidentifikasi baseline juga digunakan oleh alat pembangun sistem.
 Bangunan adalah proses yang kompleks, yang berpotensi rawan kesalahan, karena
mungkin ada tiga platform sistem yang berbeda yang terlibat (Gambar 25.10):
1. Sistem pengembangan, yang meliputi alat pengembangan seperti kompiler, editor
kode sumber, dll. Pengembang memeriksa kode dari manajemen versi sistem ke ruang
kerja pribadi sebelum melakukan perubahan pada sistem.
Mereka mungkin ingin membangun versi sistem untuk pengujian dalam pengembangan
mereka lingkungan sebelum melakukan perubahan yang telah mereka lakukan pada
versinya sistem manajemen. Ini melibatkan penggunaan alat build lokal yang
menggunakan check-out versi komponen di ruang kerja pribadi.
2. Membangun server, yang digunakan untuk membangun definitif, versi executable
dari sistem. Ini berinteraksi erat dengan sistem manajemen versi. Pengembang memeriksa
kode ke sistem manajemen versi sebelum dibangun. Pembuatan sistem mungkin
bergantung pada perpustakaan eksternal yang tidak termasuk dalam versi sistem
manajemen
3. Lingkungan sasaran, yang merupakan platform di mana sistem dijalankan. Ini
mungkin jenis komputer yang sama yang digunakan untuk pengembangan
dan membangun sistem Namun, untuk sistem real-time dan embedded, lingkungan
target seringkali lebih kecil dan lebih sederhana daripada lingkungan pengembangan
(misalnya ponsel). Untuk sistem yang besar, lingkungan target mungkin mencakup
database dan sistem COTS lainnya yang tidak dapat diinstal pada mesin
pengembangan. Di Kedua kasus ini, tidak mungkin membangun dan menguji sistem
pada komputer pengembangan atau pada server build.

Sistem pengembangan dan server build keduanya dapat berinteraksi dengan versi sistem
manajemen. Sistem VM mungkin ada di server build atau dedicated server. Untuk sistem
embedded, lingkungan simulasi dapat dipasang di lingkungan pengembangan untuk
pengujian, daripada menggunakan platform sistem tertanam yang sebenarnya . Simulator ini
dapat memberikan dukungan debugging lebih baik daripada yang tersedia pada sistem yang
disematkan. Namun, sangat sulit untuk mensimulasikan perilaku sistem yang disematkan dalam
segala hal. Anda harus menjalankan tes sistem pada platform yang sebenarnya dimana sistem
akan dijalankan, serta simulator sistem.
Sistem bangunan melibatkan perakitan sejumlah besar informasi tentang perangkat lunak
dan lingkungan operasinya. Untuk itu , untuk sesuatu yang terpisah dari sistem yang sangat kecil,
selalu masuk akal untuk menggunakan alat pengembangan otomatis untuk menciptakan
sistem (Gambar 25.11). Perhatikan bahwa Anda tidak hanya memerlukan file kode sumber
yang terlibat dalam pembuatan. Anda mungkin harus menghubungkannya dengan yang
disediakan secara eksternal

Sistem Pengembangan
bersama
Versi Manajemen dan Build Server
Sistem Sasaran
Sistem yang Dapat Dijalankan
Platform Sasaran
Periksa
(bersama)
Mendaftar
Pengembangan
Alat
Ruang kerja pribadi
Versi
Pengelolaan
Sistem
Membangun Server
Gambar 25.10
Pembangunan, pembangunan,
dan target platform

Sumber
File kode
File data
Perpustakaan
Executable
Pengujian
Executable
Sistem Sasaran
Hasil tes
Konfigurasi
File
Otomatis
Membangun Sistem
Kompiler
Gambar 25.11 Sistem dan Peralatan
bangunan

perpustakaan, file data (seperti file pesan kesalahan ), dan file konfigurasi yang menentukan
target instalasi. Anda mungkin harus mengetahui versi compiler dan perangkat lunak lain yang
akan digunakan dalam pembuatannya. Idealnya, Anda harus ab le untuk membangun sebuah
sistem yang lengkap dengan perintah tunggal atau klik mouse.
Ada banyak alat pembuatan yang tersedia dan sistem pembuatan mungkin menyediakan
beberapa atau semua fitur berikut:
1. Membangun skrip generasi Jika perlu, sistem build harus menganalisa program yang
sedang dibangun, mengidentifikasi komponen dependen, dan secara otomatis
menghasilkan script build (terkadang disebut file konfigurasi). Sistem juga harus mendukung
pembuatan dan pengeditan manual pembuatan skrip.
2. Integrasi sistem manajemen versi Sistem build harus memeriksa versi komponen yang
dibutuhkan dari sistem manajemen versi.
3. Kompilasi ulang minimal Sistem build harus mencari tahu kode sumber apa yang harus
dikompilasi ulang dan menyiapkan kompilasi jika diperlukan.
 4. Pembuatan sistem executable Sistem build harus menghubungkan file kode objek yang
dikompilasi satu sama lain dan dengan file lain yang dibutuhkan, seperti perpustakaan dan file
konfigurasi, untuk membuat sistem eksekusi.
5. Uji otomasi Beberapa sistem build dapat secara otomatis menjalankan tes
otomatis menggunakan alat uji otomasi seperti JUnit. Ini memastikan bahwa bangunan
belum 'rusak' oleh perubahan.
6. Pelaporan Sistem pembuatan harus memberikan laporan tentang keberhasilan atau
kegagalan membangun dan tes yang telah dijalankan.
7. Generasi Dokumentasi Sistem build mungkin dapat menghasilkan catatan rilis tentang
halaman bantuan build and system.

Script build adalah definisi sistem yang akan dibangun. Ini mencakup informasi tentang
komponen dan dependensinya, dan perangkat yang digunakan untuk mengkompilasi dan
menghubungkan sistem. Skrip build mencakup spesifikasi con figuration sehingga bahasa
scripting yang digunakan seringkali sama dengan bahasa deskripsi konfigurasi.

Bahasa konfigurasi mencakup konstruksi untuk menggambarkan komponen sistem yang akan
disertakan dalam membangun dan ketergantungannya.
Sebagai kompilasi adalah proses komputasi yang intensif, alat untuk
mendukung pembangunan sistem biasanya dirancang untuk meminimalkan jumlah kompilasi
yang diperlukan. Mereka melakukan ini dengan memeriksa apakah versi kompilasi dari
compo nent tersedia. Jika demikian, tidak perlu mengkompilasi ulang komponen itu. Oleh karena
itu, ada cara untuk secara jelas menghubungkan kode sumber komponen dengan kode objek
ekuivalennya.
Cara yang dilakukan ini adalah mengaitkan tanda tangan unik dengan setiap file
dimana komponen kode sumber disimpan. Kode objek yang sesuai , yang telah dikompilasi dari
kode sumber, memiliki tanda tangan terkait. Tanda tangan mengidentifikasi setiap versi kode
sumber dan diubah bila kode asam terbit diedit. Dengan membandingkan tanda tangan pada file
sumber dan kode objek, adalah mungkin untuk memutuskan apakah komponen
kode sumber digunakan untuk menghasilkan komponen kode objek.
Ada dua jenis tanda tangan yang bisa digunakan:
1. Tanda tangan modifikasi Tanda tangan pada file kode sumber adalah waktu
dan tanggal saat file tersebut dimodifikasi. Jika file kode sumber komponen
telah dimodifikasi setelah file kode objek terkait, maka sistem mengasumsikan
bahwa kompilasi ulang untuk membuat file kode objek baru diperlukan.

Misalnya, komponen Comp.java dan Comp.class memiliki tanda tangan modifikasi 17:
03: 05: 02: 14: 2009 dan 16: 34: 25: 02: 12: 2009. Ini berarti kode Java dimodifikasi pada
3 menit dan 5 detik 5 pada tanggal 14 Februari 2009 dan versi yang dikompilasi
dimodifikasi pada 34 menit dan 25 detik 4 pada tanggal 12 Februari 2009. Dalam kasus
ini, sistem akan otomatis kompilasi ulang Comp.java karena versi yang dikompilasi
tidak termasuk perubahan yang dibuat pada kode sumber sejak 12 Februari.
2. Source code checksum Tanda tangan pada file kode sumber adalah checksum
yang dihitung dari data dalam file. Fungsi checksum menghitung bilangan unik dengan
menggunakan teks sumber sebagai masukan. Jika Anda mengubah kode sumber (bahkan
dengan satu karakter), ini akan menghasilkan checksum yang berbeda. Oleh karena itu
 Anda dapat yakin bahwa file kode sumber dengan checksum berbeda sebenarnya
berbeda. Checksum ditugaskan ke kode sumber sebelum kompilasi dan secara unik
mengidentifikasi file sumber. Itu membangun sistem kemudian tag file kode objek yang
dihasilkan dengan tanda tangan checksum. Jika tidak ada file kode objek dengan tanda
tangan yang sama seperti file kode sumber yang akan disertakan dalam sistem, maka
kompilasi ulang kode sumber diperlukan.

Sebagai file kode objek biasanya tidak diversi, pendekatan pertama berarti hanya file kode
objek yang dikompilasi baru-baru ini yang tersimpan dalam sistem. Hal ini biasanya terkait
dengan file kode sumber dengan nama (i e, memiliki nama yang sama dengan file kode sumber
namun dengan akhiran yang berbeda). Karena itu , file sumber Comp.Java bisa menghasilkan file
objek Comp.class. Karena sou rce dan file objek dihubungkan oleh nama dan bukan tanda tangan
sumber berkas yang eksplisit , biasanya tidak mungkin untuk membuat versi komponen
komponen kode yang berbeda ke dalam direktori yang sama pada saat bersamaan, karena ini
akan menghasilkan file objek dengan sama nama.

Pengujian Gagal
Pengujian OK
baik
Tes Check-out Gagal
Garis utama
Membangun dan
Sistem Uji
Membangun dan
Sistem Uji
Membuat
Perubahan
Check-in ke
Membangun Server
Membangun dan
Sistem Uji
Melakukan
Perubahan pada VM
Versi
Pengelolaan
Sistem
Membangun Server
Pribadi
Ruang kerja
Versi
Pengelolaan
Sistem
Gambar 25.12
Integrasi terus menerus
 Pendekatan checksum memiliki keuntungan untuk memungkinkan berbagai versi kode
objek komponen dipertahankan pada waktu bersamaan. Tanda tangan dan bukan nama file
adalah link antara sumber kode objek nd. Kode sumber dan kode objek memiliki tanda tangan
yang sama. Oleh karena itu, ketika Anda mengkompilasi ulang komponen, kode tersebut tidak
menimpa kode objek , seperti biasanya ketika stempel waktu digunakan. Sebaliknya, ia
menghasilkan file kode objek baru dan menandainya dengan tanda kode sumber. Kompilasi
paralel adalah mungkin dan versi komponen yang berbeda dapat disusun pada saat yang
bersamaan.
Metode tangkas menyarankan agar sistem yang sangat sering dibangun harus
dilakukan dengan pengujian otomatis (kadang-kadang disebut tes asap) untuk menemukan
masalah perangkat lunak. Sering membangun mungkin merupakan bagian dari
proses integrasi berkesinambungan , seperti yang ditunjukkan pada Gambar 25.12. Sesuai
dengan gagasan tangkas untuk membuat banyak perubahan kecil , integrasi terus menerus
melibatkan pembangunan kembali jalur utama sesering mungkin, setelah perubahan kode sumber
kecil telah dilakukan. Langkah-langkah dalam integrasi berkesinambungan adalah:
1. Simak sistem jalur utama dari sistem manajemen versi ke dalam ruang kerja
pribadi pengembang.
2. Bangun sistem dan jalankan tes otomatis untuk memastikan sistem yang dibangun
melewati semua tes. Jika tidak, bangunan rusak dan Anda harus memberitahu siapa pun
yang memeriksa sistem dasar terakhir. Mereka bertanggung jawab untuk memperbaiki
masalah.
3. Buat perubahan pada komponen sistem.
4. Bangun sistem di ruang kerja pribadi dan jalankan kembali tes sistem. Jika tes
gagal, lanjutkan pengeditan.
5. Begitu sistem telah lulus tesnya, periksa ke sistem build tapi jangan lakukan itu
sebagai dasar sistem yang baru.
6. Bangun sistem pada build server dan jalankan tesnya. Anda perlu melakukan ini
jika orang lain telah memodifikasi komponen sejak Anda memeriksa
sistem. Jika demikian, periksa komponen yang telah gagal dan edit sehingga tes ini lulus
pada ruang kerja pribadi Anda.
7. Jika sistem melewati tes pada sistem build, maka lakukan perubahan
yang telah Anda buat sebagai baseline baru di sistem mainline.

Argumen untuk integrasi berkesinambungan adalah bahwa hal itu memungkinkan masalah
yang disebabkan oleh interaksi antara pengembang yang berbeda dapat ditemukan dan
diperbaiki sesegera mungkin. Sistem yang paling baru di mainline adalah sistem kerja definitif.
Namun, meskipun integrasi kontinu adalah ide yang baik , tidak selalu mungkin menerapkan
pendekatan ini terhadap pembangunan sistem. Alasan untuk ini adalah:
1. Jika sistemnya sangat besar, mungkin butuh waktu lama untuk membangun dan
menguji. Oleh karena itu tidak praktis untuk membangun sistem itu beberapa kali per hari.
2. Jika platform pengembangan berbeda dari platform target, mungkin
tidak mungkin menjalankan tes sistem di ruang kerja pribadi pengembang. Disana
mungkin menjadi perbedaan dalam perangkat keras, sistem operasi, atau perangkat lunak
yang diinstal. Karena itu lebih banyak waktu yang dibutuhkan untuk menguji sistem.
 Untuk sistem besar atau untuk sistem dimana platform eksekusi tidak sama dengan
platform pengembangan, integrasi berkelanjutan mungkin impra ctical. Dalam keadaan seperti
itu, sistem build harian bisa digunakan. Fitur dari hal ini adalah sebagai berikut:
1. Organisasi pengembang menetapkan waktu pengiriman (katakanlah 2 PM) untuk
komponen sistem. Jika pengembang memiliki versi baru dari komponen yang mereka
tulis, mereka harus mengirimkannya pada saat itu. Komponen mungkin tidak lengkap
namun harus menyediakan beberapa fungsi dasar yang bisa diuji.
2. Versi baru dari sistem ini dibangun dari komponen ini dengan mengkompilasi
dan menghubungkannya untuk membentuk sistem yang lengkap.
3. Sistem ini kemudian dikirim ke tim pengujian, yang melakukan serangkaian tes
sistem yang telah ditentukan. Pada saat yang sama, para pengembang masih
mengerjakan komponen mereka, menambah fungsionalitas dan memperbaiki kesalahan
yang ditemukan pada tes sebelumnya.
4. Kesalahan yang ditemukan selama pengujian sistem didokumentasikan dan
dikembalikan ke pengembang sistem. Mereka memperbaiki kesalahan ini dalam versi
berikutnya dari komponen.

Keuntungan menggunakan perangkat lunak yang sering digunakan adalah kemungkinan

menemukan masalah yang timbul dari komponen interaksi di awal proses meningkat. Bangunan
yang sering mendorong unit testing komponen. Secara psikologis, pengembang berada di bawah
tekanan untuk tidak 'memecahkan pembangunan'; Artinya, mereka mencoba untuk tidak
memeriksa versi komponen yang menyebabkan keseluruhan sistem gagal. Oleh karena itu
mereka enggan memberikan versi omponent c baru yang belum diuji dengan benar. Akibatnya,
semakin sedikit waktu yang dihabiskan untuk menguji sistem cincin du menemukan dan
mengatasi kesalahan perangkat lunak yang bisa ditemukan oleh pengembang.

25.4 Pelepasan manajemen

Pelepasan sistem adalah versi sistem perangkat lunak yang didistribusikan kepada
pelanggan. Untuk perangkat lunak pasar massal, biasanya mungkin kita mengidentifikasi dua
jenis pelepasan yaitu rilis utama, yang memberikan fungsi baru yang signifikan , dan rilis kecil ,
yang memperbaiki bug dan memperbaiki kesalahan proble pelanggan yang telah dilaporkan.
Untuk contoh, buku ini sedang ditulis di Apple M komputer ac dimana operasi sistem OS 10.5.8.
Ini berarti pelepasan kecil 8 dari rilis utama 5 dari OS 10. Pelepasan utama sangat penting secara
ekonomi bagi vendor yang sangat penting karena pelanggan harus membayarnya. Pelepasan
minor biasanya dibagi secara cuma-cuma.
Untuk perangkat lunak kustom atau lini produk perangkat lunak , mengelola rilis sistem
adalah proses yang kompleks. Pelepasan sistem khusus mungkin harus diproduksi untuk
setiap pelanggan dan pelanggan individual dapat menjalankan rilis sistem yang berbeda secara
berbeda pada saat bersamaan. Ini berarti bahwa perusahaan softwar yang menjual produk
perangkat lunak khusus mungkin harus mengelola puluhan atau bahkan ratusan
pelepasan produk yang berbeda. Sistem manajemen konfigurasi dan proc esses mereka
harus dirancang untuk memberikan informasi tentang custo mers mana yang melepaskan sistem
dan hubungan antara versi rilis dan versi sys tem. Dalam hal a Masalahnya, mungkin perlu
mereproduksi persis perangkat lunak yang telah dikirimkan
untuk pelanggan tertentu
 Oleh karena itu ketika sebuah rilis sistem diproduksi, maka harus didokumentasikan
untuk memastikan bahwa hal itu dapat diciptakan kembali tepat di masa depan. Hal ini
sangat penting untuk sistem embedded embedded seumur hidup, seperti komputer yang
mengendalikan mesin kompleks . Pelanggan mungkin menggunakan sistem pelepasan
tunggal selama bertahun-tahun dan mungkin memerlukan perubahan spesifik
pada sistem perangkat lunak tertentu lama setelah tanggal rilis aslinya.
Untuk mendokumentasikan rilis, Anda harus mencatat versi komponen kode sumber
khusus yang digunakan untuk membuat kode eksekusi . Anda harus menyimpan salinan file kode
sumber, file executable, dan al l yang sesuai dan file konfigurasi. Anda juga harus mencatat versi
dari sistem operasi , perpustakaan, kompiler, dan alat lain yang digunakan untuk membangun
perangkat lunak. Ini mungkin diperlukan untuk membangun sistem yang sama persis di
kemudian hari. Ini mungkin berarti Anda harus menyimpan salinan perangkat lunak platform dan
alat yang digunakan untuk membuat sistem dalam sistem manajemen versi beserta kode sumber
sistem target.
Menyiapkan dan mendistribusikan pelepasan sistem merupakan proses yang mahal,
terutama untuk produk perangkat lunak pasar massal. Serta pekerjaan nis teknis yang terlibat
dalam menciptakan distribusi, periklanan dan publisitas rilis harus disiapkan dan strategi
pemasaran diterapkan untuk meyakinkan pelanggan agar membeli rilis baru dari

Kualitas teknis sistem

Jika kesalahan sistem yang serius dilaporkan yang mempengaruhi cara
orang menggunakan sistem, mungkin perlu dikeluarkan perbaikan kesalahan . Kesalahan sistem
minor dapat diperbaiki dengan mengeluarkan tambalan (biasanya didistribusikan melalui
I nternet) yang dapat diterapkan pada sistem saat ini.

Perubahan platform
Anda mungkin harus membuat rilis baru dari aplikasi perangkat lunak saat versi baru
dari platform sistem operasi dilepaskan.

Hukum kelima Lehman (lihat Bab 9)

'Hukum' ini menyarankan bahwa jika Anda menambahkan banyak fungsi baru ke sistem; Anda
juga akan mengenalkan bug yang akan membatasi jumlah fungsi yang mungkin disertakan
dalam rilis berikutnya . Oleh karena itu, pelepasan sistem dengan fungsi penting yang
signifikan mungkin harus diikuti oleh rilis yang berfokus pada memperbaiki masalah dan
meningkatkan kinerja.

Persaingan : Untuk perangkat lunak pasar massal, peluncuran sistem baru mungkin diperlukan
karena produk pesaing telah memperkenalkan fitur baru dan pasar mungkin akan hilang jika
tidak disediakan bagi pelanggan lama.

Persyaratan pemasaran
Bagian pemasaran sebuah organisasi mungkin telah membuat komitmen agar rilis tersedia pada
tanggal tertentu.

Perubahan pelanggan proposal

Untuk sistem kustom, pelanggan mungkin telah membuat dan memberi contoh proposal
perubahan sistem tertentu , dan mereka mengharapkan peluncuran sistem segera setelah
ini diterapkan.
Gambar 25.13 Faktor-faktor yang mempengaruhi perencanaan pelepasan sistem

sistem. Pemikiran hati-hati harus diberikan untuk melepaskan timin g. Jika rilis terlalu
sering atau memerlukan upgrade perangkat keras, pelanggan mungkin tidak akan beralih ke rilis
baru, terutama jika mereka harus membayarnya. Jika sistem rilis terlalu jarang terjadi, pangsa
pasar mungkin akan hilang saat pelanggan beralih ke sistem alternatif.
Berbagai faktor teknis dan organisasi yang harus Anda perhitungkan saat menentukan
kapan harus merilis versi baru dari sebuah sistem ditunjukkan pada Gambar 25.13.
Pelepasan sistem bukan hanya kode yang dapat dieksekusi dari sistem. Pelepasan ini
mungkin juga mencakup:
• file konfigurasi yang menentukan bagaimana pelepasannya harus dikonfigurasi
untuk instalasi tertentu ;
• file data, seperti file pesan kesalahan, yang dibutuhkan untuk operasi sistem yang berhasil ;
• sebuah program instalasi yang digunakan untuk membantu menginstal sistem pada
perangkat keras target;
• dokumentasi elektronik dan kertas yang menjelaskan sistem;
• kemasan dan publikasi terkait yang telah dirancang untuk rilis tersebut.

Penciptaan rilis adalah proses pembuatan kumpulan file dan dokumentasi yang mencakup
semua komponen pelepasan sistem . Kode program yang dapat dieksekusi dan semua file data
terkait harus diidentifikasi dalam sistem manajemen versi dan ditandai dengan identifier
rilis. Deskripsi konfigurasi mungkin harus ditulis untuk perangkat keras dan operasi sy stem dan
instruksi yang dipersiapkan untuk pelanggan yang perlu mengkonfigurasi sistem onn mereka .
Jika manual yang dapat dibaca mesin didistribusikan, salinan elektronik harus disertakan dengan
perangkat lunak. Skrip untuk program instalasi mungkin harus ditulis. F inally, kapan semua
informasi itu Tersedia, gambar master executable dari softw harus dipersiapkan dan
diserahkan untuk didistribusikan ke pelanggan atau outlet penjualan.
Saat merencanakan pemasangan sistem baru, Anda tidak dapat mengasumsikan
bahwa pelanggan akan selalu menginstal kemudahan sistem baru . Beberapa pengguna sistem
mungkin senang dengan sistem yang ada. Mereka mungkin mempertimbangkan bahwa tidak
perlu biaya untuk beralih ke rilis baru. Rilis baru dari sistem tidak bisa, karena itu,
mengandalkan pada instalasi rilis sebelumnya. Untuk menggambarkan masalah ini ,
pertimbangkan skenario berikut ini :
1. Release 1 dari sebuah sistem didistribusikan dan mulai digunakan.
2. Release 2 membutuhkan pemasangan file data baru, namun beberapa pelanggan
tidak memerlukan fasilitas pelepasan 2 sehingga tetap dengan release 1.
3. Release 3 memerlukan file data yang terinstal di release 2 dan tidak memiliki file
data baru sendiri.

Distributor perangkat lunak tidak dapat mengasumsikan bahwa file yang diperlukan
untuk rilis 3 sudah terpasang di semua situs. Beberapa situs masuk langsung dari rilis 1
untuk melepaskan 3, melewatkan rilis 2. Beberapa situs mungkin memiliki mod ified file data
yang terkait dengan rilis 2 untuk mencerminkan keadaan setempat. Oleh karena itu, file data
harus didistribusikan dan diinstal dengan release 3 dari sistem.
Biaya pemasaran dan kemasan yang terkait dengan rilis baru produk perangkat
lunak tinggi sehingga vendor produk biasanya hanya membuat rilis baru untuk platform
baru atau menambahkan fungsionalitas baru yang signifikan. Mereka kemudian membebankan
pengguna untuk perangkat lunak baru ini . Ketika masalah ditemukan dalam rilis yang ada,
vendor perangkat lunak membuat tambalan untuk memperbaiki perangkat lunak yang ada di situs
web yang akan diunduh oleh pelanggan.
Masalah dengan menggunakan tambalan yang dapat diunduh adalah banyak pelanggan
mungkin tidak pernah menemukan adanya perbaikan masalah ini dan mungkin tidak
mengerti mengapa harus dipasang. Mereka mungkin malah terus menggunakan sistem mereka
yang sudah ada dan salah dengan konsekuensi risiko bisnis mereka. Dalam beberapa situasi,
di mana tambalan ini dirancang untuk memperbaiki fon pembersihan, risiko
kegagalan memasang patch dapat berarti bahwa bisnis rentan terhadap serangan eksternal.
Untuk menghindari masalah ini, perangkat lunak pasar massal, seperti Adobe, Apple,
dan Microsoft, biasanya menerapkan solusi otomatis di mana sistem diperbarui. kapanpun rilis
minor baru tersedia Namun, ini biasanya tidak bekerja untuk sistem kustom karena sistem
ini tidak ada dalam versi standar untuk semua pelanggan.

POIN KUNCI
• Manajemen konfigurasi adalah pengelolaan sistem perangkat lunak yang
berkembang. Kapan memelihara sebuah sistem, sebuah tim CM disiapkan untuk memastikan
bahwa perubahan dimasukkan ke dalam sistem dengan cara yang terkendali dan catatan
tersebut dipelihara dengan rincian perubahan yang telah diimplementasikan.
• Proses manajemen konfigurasi utama berkaitan dengan manajemen perubahan, manajemen
versi, pengembangan sistem, dan manajemen rilis. Perangkat perangkat lunak tersedia
untuk mendukung semua proses ini.
• Manajemen perubahan melibatkan penilaian proposal untuk perubahan dari pelanggan
sistem dan pemangku kepentingan lainnya dan memutuskan apakah biaya-efektif untuk
menerapkannya dalam versi baru dari sistem.
• Manajemen versi mencakup pembuatan berbagai versi komponen perangkat lunak yang
dibuat karena perubahan dibuat untuk mereka.
• System building adalah proses perakitan komponen sistem menjadi program yang
dapat dijalankan untuk dijalankan pada sistem komputer target.
• Perangkat lunak harus sering dibangun kembali dan diuji segera setelah versi yang
baru dibangun di. Hal ini memudahkan untuk mendeteksi bug dan masalah yang telah
diperkenalkan sejak build terakhir .
• Rilis sistem mencakup kode yang dapat dieksekusi, file data, file konfigurasi, dan
dokumentasi. Manajemen rilis melibatkan pengambilan keputusan pada tanggal rilis sistem,
menyiapkan semua informasi untuk distribusi, dan mendokumentasikan setiap rilis sistem.

BACAAN LEBIH LANJUT

Prinsip dan Praktik Manajemen Konfigurasi . Buku rehensif yang sangat komprehensif ini
mencakup standar dan pendekatan tradisional terhadap CM dan juga pendekatan CM yang lebih
sesuai dengan proses modern , seperti pengembangan perangkat lunak yang tangkas. (Anne
Mette Jonassen Hass, Addison-Wesley, 2002.)

Pola Pengelolaan Konfigurasi Perangkat Lunak: Kerja Tim yang Efektif, Integrasi
Praktis. Buku yang relatif singkat dan mudah dibaca yang memberikan saran praktis yang baik
tentang praktik manajemen konstruksinya, terutama untuk metode pengembangan yang
tangkas. (SP Berczuk dengan B. Appleton, Addison-Wesley, 2003.)

'Praktik Terbaik tingkat tinggi dalam Manajemen Konfigurasi Perangkat Lunak'. Artikel
web Thi , yang ditulis oleh staf di pemasok alat CM, merupakan perkenalan yang sangat baik
untuk praktik yang baik dalam konfigurasi perangkat lunak
manajemen (L. Wingerd dan C. Seiwald,
2006.) http://www.perforce.com/perforce/papers/ bestpractices.html.

'Pengelolaan Konfigurasi Agile untuk Organisasi Besar'. Artikel web ini menjelaskan praktik
pengelolaan konfigurasi yang dapat digunakan dalam proses pengembangan tangkas , dengan
penekanan khusus pada bagaimana hal ini dapat mengarah pada proyek dan perusahaan
besar. (P. Sc huh, 2007.) http://www.ibm.com/ developerworks / rational / library / mar07 /
schuh / index.html.

E XERCISES
25.1. Sarankan lima masalah yang mungkin timbul jika perusahaan tidak
mengembangkan kebijakan dan proses manajemen konfigurasi yang efektif .
25.2. Apa manfaat menggunakan formulir permintaan perubahan sebagai dokumen utama dalam
perubahan tersebut
proses manajemen?
25.3. Jelaskan enam fitur penting yang harus disertakan dalam alat untuk mendukung perubahan
proses manajemen
25.4. Jelaskan mengapa penting bahwa setiap versi komponen harus dikenali secara unik.
Mengomentari masalah menggunakan skema identifikasi versi yang hanya berdasarkan
nomor versi
25.5. Bayangkan sebuah situasi dimana dua pengembang sekaligus memodifikasi tiga berbeda
komponen perangkat lunak. Kesulitan apa yang mungkin timbul saat mereka mencoba
menggabungkan perubahan itu
mereka telah membuat?
25.6. Perangkat lunak semakin dikembangkan oleh tim tempat anggota tim bekerja
lokasi yang berbeda Sarankan fitur dalam sistem manajemen versi yang mungkin diperlukan
dukung pengembangan perangkat lunak terdistribusi ini.
25.7. Jelaskan kesulitan yang mungkin timbul saat membangun sistem dari komponennya. Apa
Masalah tertentu mungkin terjadi saat sistem dibangun di komputer host untuk beberapa target
mesin?
25.8. Dengan mengacu pada sistem bangunan, jelaskan mengapa terkadang Anda harus
mempertahankan usang
komputer di mana sistem perangkat lunak besar dikembangkan.
25.9. Masalah umum dengan sistem bangunan terjadi ketika nama file fisik digabungkan
dalam kode sistem dan struktur berkas yang tersirat dalam nama-nama ini berbeda dari target
mesin. Tuliskan satu set panduan programmer yang membantu menghindari hal ini dan
systembuilding lainnya
masalah yang bisa anda pikirkan
25.10. Jelaskan lima faktor yang harus dipertimbangkan oleh para insinyur selama proses
membangun sebuah rilis dari sebuah sistem perangkat lunak yang besar.

REFERENSI
Ahern, DM, Clouse, A. dan Turner, R. (2001). CMMI suling . Membaca, misa: Addison-Wesley.
Bamford, R. dan Deibler, WJ (2003). 'ISO 9001: 2000 untuk Sof twair dan Penyedia
Sistem: Pendekatan Teknik'. Boca Raton, FL: CRC Tekan.
Paulk, MC, Weber, CV, Curtis, B. dan Chrissis, MB (1995). Model Kemampuan
Maturitas: Panduan untuk Meningkatkan Proses Perangkat Lunak . Membaca, misa: Addison-
Wesley.

Peach, RW (1996). Buku Pegangan ISO 9000, edisi ke-3 . New York: Irwin Professional Pub.
Pilato, CM, Collins-Sussman, B. dan Fitzpatrick, BW (2004). Kontrol Versi dengan
Subversion . Sebastopol, California: O'Reilly Media Inc.

Vesperman, J. (2003). CVS penting . Sebastopol, California: O'Reilly and Associates.