Configuration Management Untuk Rekayasa Web, dibuat oleh Fika Juwita Avriani (22033301)

Configuration management adalah aktivitas yang diaplikasikan untuk keseluruhan proses pengembangan suatu software, yaitu dimulai dari mengidentifikasi, mengontrol, mengaudit, hingga melaporkan perubahan yang terjadi saat software sedang dikembangkan dan setelah software tersebut dirilis ke konsumen. Disini akan dijelaskan tentang penerapan configuration management pada rekayasa web, khususnya untuk pengembangan aplikasi-aplikasi pada web.
Aplikasi-aplikasi pada web (WebApps/WebApplications) menjadi semakin bertambah penting di dalam pertumbuhan dan ketahanan suatu bisnis. Configuration Management (CM) dibutuhkan untuk mengembangkan WebApps. Hal ini dikarenakan configuration management berperan penting, diantaranya untuk mengontrol perubahan yang efektif pada WebApps, untuk mengontrol error atau mengurangi fungsi-fungsi yang dapat membuat kecewa pengunjung website, kelemahan-kelemahan pengamanan yang dapat membahayakan sistem-sistem di dalam perusahaan, dan hal-hal yang secara ekonomis tidak menguntungkan atau hal-hal yang dapat mengakibatkan kerusakan.
Secara umum strategi-strategi Software Configuration Management (SCM) dapat diaplikasikan, tetapi taktik dan piranti-pirantinya harus disesuaikan dengan keunikan sifat dasar WebApps. Ada 4 hal yang terkandung saat mengembangkan taktik untuk configuration management pada WebApps, yaitu :
• Content
Ciri khas dari WebApps adalah pada content WebApps terdapat sangat banyak array, antara lain : teks, grafik, applets, scripts, file-file audio/video, forms, active page elements, table-tabel, streaming data, dan lain-lain. Tantangannya adalah bagaimana cara mengatur content-content yang banyak tersebut ke dalam sekelompok configuration objects yang rasional, dan kemudian membangun mekanisme configuration control untuk objek-objek ini.
• People
Banyak orang yang terlibat di dalam WebApps dapat (dan sering) membuat content. Akan tetapi banyak dari pembuat content pada WebApps tidak mempunyai latar belakang software engineering dan sama sekali tidak mengetahui kegunaan control management. Akibatnya, aplikasi berkembang dan berubah di dalam sebuah pola yang tidak terkontrol.
• Scalability
Teknik dan kontrol yang diberlakukan pada sebuah WebApps yang kecil tidak menaikkan skala dengan baik. Hal ini tidak umum bagi sebuah aplikasi web sederhana untuk bertumbuh secara cepat sebagai interconnection dengan sistem informasi yang ada, dimana databases, data warehouses, dan portal gateways diimplementasikan. Dengan pertambahan ukuran dan kompleksitas, perubahan-perubahan kecil dapat dicapai dan tidak diperuntukkan penggunaan yang bermasalah. Oleh karena itu, kekakuan dalam mekanisme configuration control akan dibandingkan secara langsung dengan skala aplikasi.
• Politics
Siapa yang “memiliki” WebApps? Pertanyaan ini diperdebatkan di perusahaan-perusahaan besar dan kecil, dan jawabannya mempunyai pengaruh yang signifikan pada aktivitas-aktivitas kontrol dan manajemen yang dihubungkan dengan rekayasa web. DART mengusulkan pertanyaan-pertanyaan berikut untuk membantu memahami politics yang berhubungan dengan rekayasa web :
1. Siapa yang bertanggung jawab terhadap keakuratan informasi yang terdapat pada website?
2. Siapa yang menjamin bahwa proses pengontrol kualitas telah sesuai sebelum informasi dipublikasikan ke dalam site?
3. Siapa yang bertanggung jawab terhadap pembuatan perubahan?
4. Siapa yang menanggung biaya perubahan?

WEBAPP CONFIGURATION OBJECTS
WebApp mencakup banyak sekali macam-macam configuration objects, yaitu content objects (seperti teks, grafik, gambar, audio, video), komponen-komponen fungsional (seperti scripts, applets), dan interface objects (seperti COM atau COBRA). Objek-objek WebApp dapat diidentifikasi dengan banyak cara yang sesuai dengan organisasi. Ada beberapa ketentuan yang disarankan untuk menjamin cross-platform compability tetap terpelihara, diantaranya adalah panjang nama file dibatasi sebanyak 32 karakter, nama file yang terdiri dari pencampuran huruf besar dan huruf kecil atau semuanya huruf besar harus dihindari, dan penggunaan underscore tidak diperbolehkan. Link-link pada URL di dalam configuration objects harus selalu menggunakan garis pemisah (contoh : …/products/alarmsensors.html).
Seluruh content pada WebApp mempunyai format dan struktur. Internal file formats ditentukan oleh computing environment dimana content disimpan. Meskipun demikian, perubahan format (biasa disebut display format) ditegaskan oleh corak estetis dan pola aturan-aturan yang dibangun untuk WebApp. Struktur content mendefinisikan sebuah arsitektur content yang berarti bahwa struktur content mendefinisikan suatu cara dimana objek-objek content dikelompokkan untuk memberikan informasi yang bermanfaat kepada end-user.

CONTENT MANAGEMENT
Content management berkaitan dengan configuration management dalam pengertian bahwa sebuah Content Management System (CMS) membangun sebuah proses (didukung oleh piranti yang tepat), sehingga menghasilkan content yang ada (dari sebuah array yang besar pada configuration objects WebApps), menyusunnya dalam sebuah cara yang memungkinkannya untuk diperkenalkan ke end-user, dan kemudian memberikannya ke lingkungan bagian client untuk ditampilkan.
Pada umumnya kebanyakan penggunaan content management system terjadi saat sebuah WebApp dibangun. WebApps yang dinamis membuat halaman-halaman web “on the fly”. Maksudnya adalah user biasanya melakukan perintah query untuk meminta informasi yang spesifik dari WebApp. WebApp melakukan query ke database, kemudian menyesuaikan format informasi yang diminta user dengan format informasi yang ada di dalam database, dan memberikannya ke user. Contohnya pada perusahaan musik, perusahaan musik menyediakan informasi tentang CD-CD yang mereka jual. Saat seorang user memesan sebuah CD atau e-music, perintah query dijalankan ke sebuah database. Di dalam database terdapat berbagai informasi tentang artis, CD (gambar sampul atau grafisnya), musical content, dan contoh audio semua CD atau e-music yang dapat di-download. Informasi-informasi tersebut disusun ke dalam sebuah standard content template. Pada bagian server dibangun halaman web dan diteruskan ke browser bagian client agar dapat dilihat oleh end-user. Secara umum representasinya ditunjukkan pada gambar di bawah ini :

Gambar 1 : Content Management System (CMS)

Dalam pengertian yang paling umum, CMS menyusun content untuk end-user dengan cara meminta 3 subsistem yang terintegrasi, yaitu : collection subsystem, management subsystem, dan publishing subsystem.
• Collection Subsystem
Content didapatkan dari data dan informasi yang harus dibuat atau dipelajari oleh seorang content developer. Collection subsystem meliputi semua tindakan yang diperlukan untuk menciptakan dan/atau mendapatkan content, dan fungsi-fungsi teknis yang diperlukan untuk :
1. Mengubah content ke dalam sebuah bentuk yang dapat direpresentasikan oleh bahasa mark-up (HTML/XML).
2. Mengatur content ke dalam paket-paket yang dapat ditampilkan secara efektif pada bagian client.
• Management Subsystem
Setelah content dibuat, content harus disimpan ke dalam tempat penyimpanan, lalu dibuat daftar content-nya untuk penambahan dan penggunaan content yang akan datang, dan diberi label untuk mendefinisikan :
1. Status sekarang (apakah content objects sudah lengkap atau masih dalam pengembangan).
2. Versi yang tepat dari content objects
3. Objek-objek content yang berelasi.
Oleh karena itu, management subsystem mengimplementasikan tempat penyimpanan yang meliputi elemen-elemen berikut ini :
- Content database : Struktur informasi yang telah dibangun untuk menyimpan semua content objects.
- Database capabilities : Fungsi yang memungkinkan CMS untuk mencari content objects yang spesifik (atau kategori objek-objek), menyimpan dan mengembalikan objek-objek, dan mengatur struktur file yang telah dibangun untuk content tersebut.
- Configuration management function : Elemen fungsional dan workflow yang berhubungan mendukung pengenalan content object, version control, perubahan manajemen, perubahan auditing, dan pemberitaan/pelaporan.
Sebagai tambahan untuk elemen-elemen tersebut, management subsystem menggunakan fungsi administrasi yang meliputi metadata dan aturan-aturan untuk mengontrol keseluruhan struktur dari content, dan hal-hal lain yang didukung olehnya.
• Publishing Subsystem
Content harus diekstraksi dari tempat penyimpanan, diubah ke dalam suatu bentuk yang disetujui untuk dipublikasikan dan dibentuk agar dapat dikirimkan ke browser pada bagian client. Publishing subsystem mengerjakan tugas-tugas ini dengan mengunakan serangkaian template-template. Masing-masing template merupakan sebuah fungsi yang membangun publikasi dengan menggunakan salah satu dari tiga komponen yang berbeda :
1. Static elements : Teks, grafik, media dan scripts yang tidak memerlukan proses lebih lanjut ditransmisikan secara langsung ke bagian client.
2. Publication services : Fungsi yang menggunakan layanan retrieval khusus dan formatting untuk personalize content (menggunakan aturan yang telah didefinisikan), melakukan konversi data, dan membangun link-link navigasi yang sesuai.
3. External Services : Menyediakan akses untuk informasi infrastruktur luar seperti data enterprise atau aplikasi “back-room”.
CMS yang mencakup masing-masing dari subsistem-subsistem ini dapat diaplikasikan untuk project rekayasa web yang besar. Bagaimanapun juga filosofi dan fungsi dasarnya yang terhubung dengan CMS bisa digunakan untuk semua web yang dinamis.

CHANGE MANAGEMENT
Workflow yang terhubung dengan kontrol perubahan pada software konvensional, biasanya terlalu berat dan lambat untuk rekayasa web. Agar dapat mengimplementasikan perubahan manajemen yang efektif dalam filosofi “code and go”, maka proses perubahan kontrol yang konvensional harus diubah. Setiap perubahan harus digolongkan ke dalam salah satu dari 4 kelas di bawah ini :
• Kelas 1
Perubahan content atau fungsi yang mengkoreksi error atau meningkatkan fungsi atau local content.
• Kelas 2
Perubahan content atau fungsi yang memiliki pengaruh pada content object atau komponen fungsional yang lain.
• Kelas 3
Perubahan content atau fungsi yang memiliki pengaruh luas terhadap WebApp (Esensi utama dari fungsi, penaikkan atau penurunan signifikan pada content, perubahan utama yang diperlukan pada navigasi).
• Kelas 4
Perubahan desain utama (Perubahan pada desain antarmuka atau pendekatan navigasi) yang akan dengan cepat dikenali oleh satu atau lebih golongan dari user.

Perubahan permintaan dapat diproses sesuai dengan algoritma seperti pada gambar di bawah ini setelah perubahan permintaan dikelompokkan :

Gambar 2 : Mengelola Perubahan-Perubahan Pada WebApps

Perubahan pada kelas 1 dan kelas 2 ditangani secara informal dan cepat. Untuk perubahan pada kelas 1, web engineer mengevaluasi pengaruh dari perubahan, tetapi tidak ada laporan atau dokumentasi eksternal yang diperlukan. Saat perubahan dibuat, prosedur-prosedur check-in dan check-out standar dijalankan oleh alat-alat configuration repository. Pada perubahan di kelas 2, web engineer bertanggung jawab untuk melakukan review terhadap pengaruh perubahan pada objek-objek yang berhubungan (atau meminta developer yang bertanggung jawab terhadap objek-objek tersebut untuk melakukannya). Jika perubahan dapat dibuat tanpa memerlukan perubahan-perubahan yang signifikan terhadap objek-objek lain, maka modifikasi dapat dilakukan tanpa dokumentasi atau review tambahan. Jika perubahan yang sesungguhnya diperlukan, maka selanjutnya evaluasi dan perencanaan yang lebih rinci diperlukan.
Perubahan pada kelas 3 dan kelas 4 juga dilakukan dengan cara yang cepat, tetapi beberapa dokumentasi deskriptif dan prosedur-prosedur formal review diperlukan. Change description menggambarkan perubahan dan menyediakan perkiraan yang jelas dari dampak perubahan, yang dikembangkan untuk perubahan-perubahan di kelas 3. Deskripsi tersebut didistribusikan untuk semua anggota dari tim rekayasa web yang mempelajari tentang change description untuk memperkirakan dampak yang lebih baik lagi. Change description juga dikembangkan pada perubahan di kelas 4, tetapi dalam kasus ini tinjauan dilakukan oleh stakeholder.

VERSION CONTROL
Selama pengembangan WebApp, terdapat beberapa versi WebApp yang berbeda-beda pada waktu yang sama. Satu versi (cara kerja WebApp saat ini) tersedia melalui internet untuk end-user. Versi kedua (pengembangan WebApp selanjutnya) mungkin berada pada tahap akhir dari pengujian sebelumnya. Versi ketiga masih dalam pengembangan dan mempersembahkan pembaharuan yang besar pada content, nilai estetika antarmuka, dan fungsionalitas. Configuration objects harus didefinisikan secara jelas agar dapat dihubungkan dengan versi yang sesuai. Di samping itu mekanisme kontrol harus dibangun. Dreilinger mengemukakan betapa pentingnya version (dan perubahan) control ketika dia menulis :
“Pada situs yang tidak terkontrol dimana banyak penulis memiliki akses untuk mengedit dan menambah content, kemungkinan besar akan muncul konflik dan masalah. Konflik dan masalah akan muncul ketika para penulis ini bekerja dari kantor yang berbeda pada saat yang berbeda pula. Seseorang developer mungkin akan menghabiskan waktu untuk memperbaiki file index.html untuk customer. Pada saat yang sama, developer lain yang bekerja di rumah setelah jam kerja, atau yang berada di kantor yang lain meng-upload hasil revisi versi yang baru dari file index.html milik mereka sendiri. Hal ini dapat menyebabkan pekerjaan developer kedua akan menimpa hasil pekerjaan developer pertama dan tidak ada cara untuk mendapatkan kembali pekerjaaan developer pertama.”
Situasi seperti ini seharusnya terdengar akrab untuk semua software engineer, demikian juga web engineer. Untuk menghindari kejadian di atas, maka akan dibangun sebuah version control process sebagai berikut :
1. Pada proyek WebApp akan dibangun sebuah tempat penyimpanan utama. Tempat penyimpanan ini akan menyimpan versi-versi yang sekarang dari semua configuration objects (content, komponen-komponen fungsional, dan lain-lain).
2. Setiap web engineer membuat folder kerjanya masing-masing. Folder tersebut berisi objek-objek yang telah dibuat atau yang diubah pada waktu tertentu.
3. Jam-jam pada semua tempat kerja developer harus dicocokkan. Hal ini dilakukan untuk menghindari masalah penimpaan pada saat dua developer membuat perubahan dalam waktu yang sangat dekat.
4. Saat configuration objects yang baru dikembangkan atau objek-objek yang sudah ada diubah, objek-objek ini dikirim ke tempat penyimpanan utama. Version control tool akan mengatur semua fungsi yang keluar dan masuk dari masing-masing folder kerja web engineer.
5. Saat objek-objek diambil dari atau dikirim ke tempat penyimpanan, secara otomatis time stamped log message dibuat. Time stamped log message menyediakan informasi yang berguna untuk memeriksa dan dapat menjadi bagian dari sebuah skema pemberitaan yang efektif.

AUDITING AND REPORTING
Fungsi auditing dan reporting kurang ditekankan di dalam pekerjaan rekayasa web, tetapi masih digunakan. Semua objek yang masuk atau keluar dari tempat penyimpanan direkam pada sebuah log yang dapat dilihat setiap saat. Laporan log yang lengkap dapat dibuat, sehingga semua anggota tim rekayasa web mempunyai kronologi perubahan yang terjadi pada suatu periode waktu tertentu. Notifikasi e-mail otomatis (yang ditujukan untuk semua developers dan stakeholders) tentang objek-objek yang masuk atau keluar dari tempat penyimpanan dapat dikirim setiap saat.

Referensi : Pressman, Roger S. (2005). Software Engineering A Practitioners Approach Sixth Edition. New York : McGraw-Hill.