MANAJEMEN PERANCANGAN PERANGKAT LUNAK

PENGENALAN MANAJEMEN KONFIGURASI PERANGKAT

LUNAK

Oleh
Kelompok 6
Hastie Audytra ( 09071002012 )
Putri Dian Zara ( 09071002014 )
Hidayat ( 09071002032 )
Desty Rodiah ( 09071002034 )

IF-7B

PROGRAM STUDY TEKNIK INFORMATIKA

FAKULTAS ILMU KOMPUTER
UNIVERSITAS SRIWIJAYA
2010
 PENGENALAN MANAJEMEN KONFIGURASI

PERANGKAT LUNAK

1. Pengertian Manajemen Konfigurasi Perangkat Lunak

Pengertian manajemen menurut Encylopedia of the Social Science adalah

suatu proses dimana pelaksanaan suatu tujuan tertentu dilaksanakan dan diawasi.

Pengertian manajemen meurut Haiman yaitu fungsi untuk mencapai suatu tujuan

melalui kegiatan orang lain, mengawasi usaha-usaha yang dilakukan individu

untuk mencapai tujuan.

Konfigurasi merupakan bentuk, susunan,setting, informasi keadaan dari suatu

sistem terutama untuk menjalankan proses.

Manajemen konfigurasi adalah seni pengidentifikasiaan ,pengorganisasian dan

pengontrolan modifikasi terhadap perangkat lunak yang sedang dibangun oleh

sebuah tim pemrograman (Babich,1989).

Konfigurasi perangkat lunak merupakan

• Serangkaian penelusuran dan aktifitas control yang berawal saat proyek

dimulai dan berhenti pada saat perangkat lunak sudah tidak dioperasikan.

• Sekumpulan item-item yang terdiri dari semua informasi yang dihasilkan

sebagai bagian dari proses perangkat lunak (Software Configuration

Items / SCI)

• Serangkaian aktivitas jaminan kualitas yang dikembangkan untuk

mengatur perubahan pada seluruh siklus hidup perangkat lunak.

Manajemen konfigurasi perangkat lunak merupakan aktivitas pelindung yang

diterapkan pada keseluruhan proses perangkat lunak. Manajemen Konfigurasi

Perangkat Lunak (SCM) merupakan tools manajemen konfigurasi yang dipakai

untuk menyimpan versi komponen sistem, membangun sistem dari komponen,

dan memantau rilis versi sistem ke pelanggan beserta hasil laporannya.

Perbedaan antara pemeliharaan perangkat lunak dan manajemen konfigurasi

perangkat lunak yaitu pemeliharaan adalah serangkaian aktivitas rekayasa

perangkat lunak yang terjadi setelah perangkat lunak di sampaikan kepada

pelanggan dan sudah dioperasikan. Sedangkan manajemen konfigurasi perangkat

lunak merupakan serangkaian penelusuran dan aktivitas kontrol yang dimulai

pada saat suatu proyek perangkat lunak dimulai dan berhenti hanya bila perangkat

lunak tidak dioperasikan.

Gambar 1. Susunan aktifitas pembangunan Perangkat Lunak

2. Output Proses Perangkat Lunak

Output dari proses perangkat lunak adalah informasi yang dapat dibagi

menjadi 3 kategori :

a. Program Komputer (baik tingkat sumber maupun bentuk yang dapat

dieksekusi)

b. Dokumen yang dapat menggambarkan program komputer (ditargetkan

untuk praktisi teknis dan pemakai)

c. Data (yang diisikan dalam program atau dikeluarkan dari program)

3. Tujuan Manajemen Konfigurasi Perangkat Lunak

Tujuan dari manajemen konfigurasi adalah

• Untuk menetapkan dan memelihara integritas produk (komponen, data,

dokumentasi) tentang perangkat lunak (software) atau sistem diluar proyek

dan daur hidup produk (product life cycle).

• Untuk memonitor informasi konfigurasi jaringan dan sistem, sehingga semua

versi perangkat keras, lunak, dan konfigurasi dapat dilacak dan semua potensi

masalah bisa dihilangkan (atau diantisipasi).

• Memaksimalkan produktivitas dengan meminimalisasi kesalahan

Manajemen konfigurasi merupakan tools yang digunakan untuk mengatur

sekumpulan aktifitas yang dirancang untuk mengontrol perubahan, sbb

• Mengidentifikasi jenis produk yang akan diubah

• Audit dan report perubahan yang dibuat

 • Mengontrol perubahan

• Menentukan mekanisme untuk memanage versi yang berbeda dari jenis

produk

• Mengelompokkan produk

4. Tanggung Jawab Manajemen Konfigurasi

SCM juga bertanggung jawab untuk mengidentifikasi SCI dan beberapa versi

dari software, auditing konfigurasi software untuk memastikan bahwa sofware

telah di develop dengan baik dan membuat laporan mengenai semua perubahan

yang diaplikasikan pada konfigurasi

Pada saat proses perangkat lunak berlangsung , jumlah item konfigurasi

perangakat lunak (SCI) berkembang dengan pesat. Spesifikasi sistem

menghasilkan rencana proyek perangkat lunak dan spesifikasi syarat perangkat

lunak dan spesifikasi syarat perangkat lunak (dan juga perangkat lunak yang

berhubungan dengan dokumen). Hal ini secara berurutan menghasilkan dokumen

untuk menciptakan hirarki informasi. Bila masing masing SCI secara sederhana

menghasilkan SCI-SCI yang lain, maka akan muncul sedikit keraguan. Sayangnya

variabel lain , yaitu perubahan , masuk kedalam proses. Perubahan dapat terjadi

setiap saat , dengan alasan berbagai alasan.

Faktor terjadinya perubahan :

• Bisnis baru atau kondisi pasar yang menjadikan perubahan pada kebutuhan

produk atau aturan bisnis

 • Kebutuhan customer baru yang menyebabkan perubahan permintaan data oleh

sistem informasi, fungsi yang ada pada produk, atau service yang diberikan

oleh sistem berbasis komputer

• Re-organisasi dan/atau perubahan bisnis yang menyebabkan perubahan dalam

prioritas proyek atau struktur tim software engineering

• Batasan anggaran dan jadwal yang menyebabkan redefinisi sistem atau

produk

Gambar 2. Faktor perubahan proyek PL

5. Item Konfigurasi Perangkat Lunak (SCI)

Item konfigurasi perangkat lunak adalah informasi yang dibuat sebagai bagian

dari proses software engineering. SCI dapat merupakan bagian tunggal dari

spesifikasi yang besar atau satu test case dalam sebuah kumpulan test. SCI adalah

dokumen yang berisi sekumpulan test case atau komponen program yang diberi

nama.

SCI (Software Configuration Items) terdiri dari :

1. Spesifikasi Sistem

2. Rencana Proyek Perangkat lunak

3. Spesifikasi Persyaratan Perangkat Lunak

a. Model analisis grafis

b. Spesifikasi Proses

c. Prototipe

d. Spsesifikasi matematis

4. Manual pemakai Pertama

5. Spesifikasi Desain

a. Deskripsi desain data

b. Deskripsi desain arsitektur

c. Deskripsi desain modul

d. Deskripsi desain interface

e. Deskripsi objek (jika teknik object oriented digunakan)

6. Listing Kode Sumber

7. Spesifikasi Pengujian

a. Rencanan dan prosedur pengujian

b. Test cases dan hasil catatan

8. Manual operasi dan instalasi

9. Program dapat dieksekusi

a. Kode dapat mengeksekusi modul

b. Modul – modul terhubung

10. Deskripsi database

a. Skema dan struktur file

b. Isi awal

11. Manual Pemakai Saat Dibuat

12. Dokumen Pemeliharaan

 a. Laporan masalah perangkat lunak

b. Persayaratan pemeliharaan

c. Permintaan perubahan rekayasa

13. Standar dan prosedur untuk rekayasa perangkat lunak

6. Proses Manajemen Konfigurasi Perangkat Lunak

Manajemen konfigurasi perangkat lunak merupakan elemen yang pentig dari

jaminan kualitas perangkat lunak. Tanggung jawab utamanya adalah mengontorol

perubahan.

Ada 5 tugas SCM yaitu :

• Identifikasi

• Kontrol versi

• Kontrol perubahan

• Audit konfigurasi

• Pelaporan

6.1 Identifikasi

Untuk mengontrol dan mengatur item konfigurasi perangkat lunak, maka

masing masing item harus diberi nama secara terpisah dan diorganisasikan

dengan mengunakan suatu pendekatan berorientasi objek.

Ada 2 object yang dapat diidentifikasi :

- Basic object (objek dasar)

Objek dasar adalah suatu “unit teks” yang dibuat oleh software engineer

selama analisis, desain, coding atau testing.

 Contoh : basic object dpt berupa bagian dari spesifikasi persyaratan, daftar

sumber untuk modul, atau sejumlah test case yang digunakan untuk

menguji kode.

- Aggregate Object

Objek agregat adalah kumpulan dari basic object dan aggregate object

lainnya.

Contoh : Spesifikasi desain (pada gambar 3) merupakan sebuah objek

agregat. Secara konseptual , spesifikasi design dapat dilihat sebagai daftar

pointer yang diberi nama (diidentifikasi) yang menentapkan objek – objek

dasar seperti model data dan N-modul.

Masing – masing objek memiliki serangkaian fitur yang berbeda yang

menandainya secara unik : nama , deskripsi , daftar sumber daya dan

“realisasi”. Nama objek berupa string karakter yang mengidentifikasi objek

tanpa ambiguitas. Deskripsi objek adalah daftar item data yang

mengidentifikasi :

• Tipe SCI (misalnya dokumen,program, data) yang disajikan oleh objek;

• Suatu pengidentifikasi objek dan perubahan dan atau informasi versi.

 Model data

Spesifikasi design

Design data
Arsitektural design
Desain modul
Desain interface
N modul

Deskripsi interface
Deskripsi algoritma
PDL

Spesifikasi pengujian

Rencana pengujian
Prosedur pengujian
Test case Kode sumber

Gambar 3. Objek objek konfigurasi

6.2 Kontrol versi

Version control mengkombinasikan prosedur dan tool untuk mengatur

versi yang berbeda dari konfigurasi object yg dibuat selama proses rekayasa

software. Clemm (1989) menggambarkan kontrol versi dalam konteks SCM

sebagai berikut : manajemen konfigurasi mengizinkan seorang pemakai untuk

mengkhususkan konfigurasi alternatif dari sistem perangkat lunak melalui

pemilihan versi perangkat lunak dan kemudian mengijinkan suatu konfigurasi

untuk ditentukan [dan dikontruksi] dengan mendeskripsikan serangkaian

atribut yang diinginkan.

Atribut atribut tersebut dapat sesederhana nomer versi tertentu yang

dilampirkan bagi setiap objek atau dapat sekompleks string variabel boolean

(skalar) yang menunjukkan tipe perubahan fungsional tertentu yang telah

diaplikasikan pada sistem.

Cara untuk mengkonseptualisasi hubungan antara komponen,varian dan

versi(revisi) adalah dengan merepresentasikannya sebagai objek pool. Seperti

 pada gambar 4, hubungan antara objek konfigurasi dan komponen varian dan

versi dapat dihadirkan sebagai ruang tiga dimensi. Komponen terdiri dari

kumpulan objek pada tingkat revisi yang sama. Varian adalah sekumpulan

objek yang berbeda pada tingkat revisi yang sama, dan karena itu berada

berdampingan secara paralel dengan varian yang lain. Versi baru ditentukan

pada saat perubahan mayor dilakukan pada suatu objek atau lebih.

Gambar 4. Object pool merepresentasikan komponen , varian dan versi

6.3 Kontrol perubahan

Untuk proyek pengembangan perangkat lunak yg besar, perubahan yang

cepat dan tidak terkontrol akan membawa kekacauan. Kontrol perubahan

adalah kombinasi prosedur manusia dan piranti yang otomatis menyediakan

mekanisme untuk mengontrol perubahan. Proses kontrol perubahan

digambarkan secara sistematis pada gambar 5. Permintaan perubahan dibuat

dan dievaluasi untuk menghitung manfaat teknis, efek samping potensial,

perngaruh keseluruhan pada objek konfigurasi dan fungsi sistem yang lain dan

biaya perubahan yang diproyeksikan. Hasil dari evaluasi dipresentasikan

sebagai laporan perubahan yang digunakan oleh otoritas kontrol perubah

Change Control Authority (CCA) yakni orang atau grup yang membuat

keputusan akhir mengenai status dan prioritas perubahan.

Kebutuhan akan perubahan diketahui

Permintaan perubahan dari pemakai

Pengembang mengevaluasi

Laporan perubahan dihasilkan

Otoritas kontrol perubahan membuat keputusan

Permintaan ditindaklanjuti , ECO dibuat

Permintaan perubahan ditolak

Menunjuk orang untuk objek konfigurasi

Pemakai diberi informasi baru
Mengeluarkan objek (item) konfigurasi

Membuat perubahan

Kajian (audit) perubahan

Check mencatat item konfigurasi yang telah diubah

Membuat baseline untuk pengujian

Mengadakan jaminan kualitas dan tindakan pengujian

“mempromosikan” perubahan untuk masuk dalam peluncuran (revisi) berikutnya

Membangun kembali versi perangkat lunak yang tepat

Kajian (audit) perubahan pada semua item konfigurasi

Memasukkan perubahan – perubahan pada versi baru

Gambar 5 Proses
Distribusi versi baru control perubahan
6.4 Audit konfigurasi

Menilai suatu objek konfigurasi berdasarkan karakteristik umum yang

tidak tercakup dalam proses kajian,dan dilakukan secara terpisah dengan

kelompok jaminan kualitas. Identifikasi, kontrol versi , dan kontrol perubahan

membantu pengembang perangkat lunak untuk me-maintain permintaan pada

saat terjadi kondisi yang tidak diinginkan. Tetapi bahkan mekanisme kontrol

yang paling sukses sekalipun hanya dapat menelusuri perubahan sampai ECO

dimunculkan. Bagaimana bisa memastikan bahwa perubahan

diimplementasikan dengan baik ? Jawabannya tergantung dua hal, yakni :

Kajian teknis formal dan audit konfigurasi perangkat lunak.

Kajian teknis formal memfokuskan pada kebenaran tenkis dari objek

konfigurasi yang telah dimodifikasi. Pengkajian menilai SCI untuk

menentukan konsistensi dengan SCI yang lain, penhilangan, dan efek samping

potensial. Kajian teknis formal harus dilakukan untuk semua perubahan yang

paling sepele.

Audit konfigurasi perangkat lunak melengkapi kajian teknis formal

dengan menilai suatu objek konfigurasi untuk karakteristik yang secara umum

tidak dipertimbamgkan selama kajian.

6.5 Pelaporan

Merupakan tugas SCM dengan melaporkan suatu konfigurasi / aliran

informasi proyek. Pelaporan status konfigurasi atau biasa disebut status

accounting adalah tugas SCM yang menjawab pertanyaan seperti berikut :

• Apa yang terjadi ?

 • Siapa yang melakukannya?

• Kapan terjadi ?

• Apa yang menjadi dampaknya?

Aliran informasi untuk melaporkan Configuration Status Reporting (CSR)

ditunjukkan pada gambar 5 setiap kali suatu SCI ditandai dengan identifikasi

baru atau diperbaharui, hal itu berabrti suatu entry CSR dibuat. Setiap kali

suatu perbuahan disetujui oleh CCA (yaitu sebuah ECO dikeluarkan), berarti

entry SCR dibuat. Setiap kali audit konfigurasi dilakukan, hasilnya dilaporkan

sebagai bagian dari tugas CSR. Dua developer akan melakukan modifikasi

SCI yg sama dengan cara yg berbeda. Tim Software Engineering akan

menghabiskan waktu yang lama untuk mengembangkan software pada

spesifikasi hardware yang lama.

Orang Orang yang menyadari efek samping serius untuk perubahan yang

diajukan tidak menyadari perubahan yang sedang dibuat. SCR membantu

mengeliminasi masalah ini dengan meningkatkan komunikasi semua orang

yang terlibat didalamnya.

7. Konsep Manajemen Konfigurasi Perangkat Lunak

• Baseline

Baseline adalah sebuah konsep manajemen kofigurasi perangkat lunak

yang membantu pengontrolan perubahan tanpa menganggu proses perubahan

yang lain. IEEE (IEEE Std.610.12-1990) mendefinisikan baseline sebagai suatu

spesifikasi atau produk yang telah dikaji secara formal dan disetujui, yasng

kemudian berfungsi sebagai dasar bagi pengembangan lebih jauh, serta dapat

diubah hanya melalui prosedur kontrol perubahan formal.

 Dalam konteks rekayasa perangkat lunak , baseline merupakan suatu

kejadian penting dalam pengembangan perangkat lunak yang ditandai dengan

penyampaian satu atau lebih item konfigurasi perangkat lunak dan izin dari

SCI yang didapatkan melalui suatu kajian teknis formal. Sebagai contoh

elemen-elemen spesifikasi design telah didokumentasikan dan dikaji.

Kesalahan – kesalahan telah ditemukan dan dikoreksi. Sekali semua bagian

spesifikasi dikaji, dibetulkan dan disetujui, berarti spesifikasi design menjadi

sebuah baseline. Perubahan lebih jauh terhadap arsitektur program (diisikan ke

dalam spesifikasi design) hanya dapat dilakukan setelah masing masingnya

dievaluasi dan disetujui. Baseline dapat di definisikan pada berbagai tingkat

detail.

8. Kesimpulan

• Manajemen konfigurasi perangkat lunak merupakan aktivitas pelindung

yang diterapkan pada keseluruhan proses perangkat lunak.

• SCM mengidentifikasi kontrol,audit dan memodifikasi laporan,yang selalu

terjadi pada saat perangkat lunak sedang di kembangkan dan setelah di

lepaskan ke pelanggan

• Tugas SCM yaitu identifikasi,kontrol versi, kontrol perubahan, audit

konfigurasi dan pelaporan

 Daftar Pustaka

Babich,W.A., Software Configuration Management, Addison-Wesley, 1989

Clemm, G.M., “Replacing Version Control with Job Control,” Proc. 2 nd Intl.

Workshop on Software Configuration Management, ACM, Princeton,NJ, Oktober

1989,h.162-169.

Pressman, Roger. 2002. Rekayasa Perangkat Lunak. Yogyakarta : Andi.

http://athay.wordpress.com/2009/10/15/scm-software-configuration-management/