Software Konfigurasi Management oleh USMAN P31. 2015 Software Konfigurasi Management oleh USMAN P31.2015.01801 MK : Software Enginering

PENDAHULUAN Perubahan : Pada dasarnya tidak ada software yang tidak berubah, semua software pasti berubah, yang mendasari software itu berubah menurut Roger Pressman(2005): Reorganisasi atau pertumbuhan bisnis menyebabkan pertumbuhan perubahan dalam project. Ini di karenakan kenginan-keinginan customer, seperti penambahan laporan atau data-data yang di perlukan oleh perusahaan tersebut, sehingga software tersebut harus dilakukan perubahan. Maka Software configuration management adalah serangkaian kegiatan tracking & control yang dimulai ketika suatu proyek perangkat lunak dimulai dan berakhir ketika perangkat lunak sudah tidak beroperasi lagi

TUJUAN SCM Karena perubahan dapat terjadi kapan saja, maka kegiatan SCM dibuat untuk: 1) mengidentifikasi perubahan, 2) mengontrol perubahan, 3) mengimplementasikan perubahan dengan benar, 4) dan melaporkan perubahan kepada pihak-pihak yang mempunyai kepentingan

Software Configuration Management Terdapat 4 sumber dasar perubahan. Bisnis baru atau kondisi pasar yang mendiktekan perubahan2 dalam produk atau aturan bisnis. Keinginan pelanggan baru yang meminta modifikasi data yang dihasilkan oleh sistem informasi; fungsionalitas yang diberikan oleh produk, atau layanan yang diberikan oleh suatu sistem berbasis komputer. Reorganisasi atau perampingan bisnis yang menyebabkan perubahan prioritas proyek atau struktur tim rekayasa perangkat lunak. Kendala-kendala anggaran atau jadwal yang menyebabkan redefinisi sistem atau produk

SCM adalah sekumpulan kegiatan yang telah dikembangkan untuk menangani perubahan selama siklus hidup dari perangkat lunak komputer. SCM dapat dipandang sebagai kegiatan SQA (Software Quality Assurance) yang dipakai selama proses perangkat lunak Baseline

Baseline Baseline adalah sebuah konsep manajemen konfigurasi perangkat lunak yang membantu kita mengontrol perubahan tanpa harus secara serius menggangu perubahan. yang dapat dibenarkan, mendefinisikan baseline sebagai : “suata spesifikasi atau produk yang telah dikaji secara formal dan disetujui, yang kemudian berfungsi sebagai dasar bagi pengembangan lebih jauh, serta dapat di ubah melalui prosedur control perubahan formal”.

SCI Baseline dan Database proyek

Berdasarkan gambar di atas yang dapat di artikan bahwa Software enginering melakukan tugas mendapatkan informasi SCI kemudian informasi tersebut diteruskan ke formal teknikal reviews, apabila disetujui maka di teruskan ke penyimpanan project database kemudian diekstrak ke SCM control setelah itu kembali lagi ke tugas software enginering, apa bila akan diadakan modifikasi lagi maka di lanjutkan langsung ke Formal teknikal reviews.

Software Configuration Item(SCI) Item konfigurasi perangkat lunak adalah informasi yang dibuat sebagai bagian dari proses software engineering. SCI adalah dokumen yang berisi sekumpulan test case atau komponen program yang diberi nama. SCI berikut menjadi target bagi teknik-teknik CM dan membentuk sekumpulan Baseline. Yang terdiri dari:

SCI Lanjutan System specification di tujukan untuk menetapkan layanan apa yang dituntut dari sistem dan batasan pada operasi sistem. Software Project plan Manajemen perangkat lunak yang dimulai dengan serangkaian aktifitas yang secara kolektif, dan aktifitas pertamanya yaitu estimation(perkiraan). Karena estimasi menjadi dasar bagi semua aktivitas perencanaan proyek yang lain dan perencanaan proyek memberikan sebuah peta jalan bagi suksesnya rekayasa perangkat lunak, maka tanpa estimasi kita tidak dapat berjalan dengan baik.

SCI Lanjutan Software Requirement Specification Graphical analysis model Model analisis yang di gunakan Process specifications proses dimana sistem apa yang harus dikembangkan dan kendala pengembangannya. Prototype Pendekatan model prototyping dipilih jika kebutuhan belum dapatdidefinisikan secara jelas dan tegas. Pemakai hanya memberikan gambaranumum dari spesifikasi dan kegunaan perangkat lunak tanpa merinci seperti apamasukan, poses, dan keluarannya

SCI Lanjutan Preliminary User Manual Design Specification Data design description Mentransformasi model domain informasi yang dibuat selama analisis ke dalam struktur data yang akan diperlukan untuk mengimplementasikan perangkat lunak. Architectural design description Menentukan hubungan diantara elemen-elemen struktur utama dari program

SCI Lanjutan Source Code Listing Interface design descriptions Menggambarkan bagaimana perangkat lunak berkomunikasi dalam dirinya sendiri dengan sistemy yang berinteroperasi dengannya dan dengan manusiayang menggunakannya. Objek deskription Source Code Listing kode-kode program dalam pengembangan perangkat lunak

SCI Lanjutan Test Specification Test plan & procedure Dokumen Test Plan ini menjelaskan tentang bagaimana software yang di buat dapat berjalan sesuai dengan rencana yang telah di tetapkan sebelumnya. Uji coba tidak hanya dilakukan pada source code, namun pengujian juga di lakukan pada database, komponen, interface, keamanan, model bisnis, dan performa dari software yang dibangun.

SCI Lanjutan Operation & Installation Manuals Executable Program a.Module executable code b.Linked modules Database Description a.Schema & file structure b.Initial content As-built User Manual Maintenance Documents a. Software problem reports b.Maintenance requests c. Engineering change orders Standard & Procedure for Softw are Engineering

SCM Proses Tanggung jawab SCM mengontrol perubahan Indentifikasi skema identifikasi mencerminkan struktur produk, mengidentifikasi komponen dan jenis , membuat menjadi unik dan dapat diakses dalam beberapa bentuk. Audit memvalidasi kelengkapan dari konsistensi produk dan memelihara antara komponen-komponen dengan memastikan bahwa produk tersebut adalah koleksi yang didefinisikan dengan komponen. Laporan Membuat laporan hasil perubahan yang telah dilakukan.

Tugas SCM Efinisi 5 tugas (task) SCM: identifikasi kontrol versi kontrol perubahan auditing konfigurasi, dan pelaporan.

Identifikasi Objek dalam SC Untuk mengontrol & menangani SCI masing-masing item harus diberi nama berbeda dan kemudian diorganisir dengan menggunakan metode berorientasi objek. Dua tipe objek dapat diidentifikasi: basic objects (obyek dasar) & aggregate objects(kumpulan obyek). Sebuah basic object adalah sebuah “unitof text” yang telah diciptakan oleh seorang software engineer pada saat (selama) analisis, design, coding,a tau testing. Sebuah aggregate object adalah sekumpulan basic object dan aggregate objects lainnya

Keunikan Objek Setiap object mempunyai sekumpulan fitur yang berbeda yang meng identifikasikannya secara unik; sebuah nama (objectname), suatudeskripsi (object description), suatudaftar sumber daya (resources list) dan suaturealisasi (realization)

Keunikan Objek Lanjutan Object name adalah sebuah string karakter yang mengidentifikasi object secara tidak samar. Object description adalah sebuah list item2 data yang mengidentifikasi: tipe SCI (misal dokumen,program, data) yang direpresentasikan oleh object; suatuproject identifier; dan informasi perubahan dan/atauversi. Resources adalah entitas yang disediakan, diproses, diacu atau sebaliknya diperlukan oleh object. Realisasi adalah sebuah pointer pada “unit oftext”untuk suatu basic object dan null untuk suatu aggregate object

Hubungan Antar-Objek Configuration object identification juga harus mempertimbangkan hubungan yang ada antara “named objects” Sebuah object dapat diidentifikasi sebagai <part-of> suatu aggregate object. Hubungan <part-of> menentukan sebuah hirarki object. Hubungan di antara object dalam suatu hirarki objek tidak hanya sepanjang direct path dari hirarchical tree, tetapi dalam beberapa hal,object2 diinterrelasikan melewati cabang2 dari object hirarchy. Interrelationships antara configuration objects dapat direpresentasikan dengan sebuah module interconection language(MIL)

Gambaran Configuration Objects

TERIMAKASIH