Estimasi sebagai bagian Measurement & Metric

ESTIMATIONS

I Putu Surya Ari Taram (22 06 4054)

Rekayasa Perangkat Lunak II

ESTIMATIONS

Akan semakin sulit untuk meramalkan sumber daya, biaya-biaya, dan jangka waktu untuk pengintegrasian perangkat lunak dan sistem. Banyak model biaya menggunakan konsep ukuran produk sebagai pemegang utama untuk penilaian biaya. Tetapi pengalaman sudah menunjukkan bahwa mutu komponen-komponen dan mutu sistem terintegrasi akan menjadi faktor-faktor dominan yang mempengaruhi timbangan biaya-biaya dan waktu dari banyak proyek-proyek saat ini.

Perangkat lunak mahal untuk dikembangkan dan biaya merupakan suatu faktor yang utama di dalam anggaran-anggaran sistem informasi. Dengan bermacam-macam karakteristik perangkat lunak dan kemunculan teknologi baru akan mempersulit dalam mengestimasi biaya-biaya pengembangan software dengan tepat. Bagaimanapun, perangkat lunak itu ditargetkan untuk pelanggan dan biaya pengembangan mempengaruhi harga. Sebagai pelanggan atau pengembang, untuk mampu mendasari keputusan pembelian atau penjualan harus bisa mengestimasi biaya pengembangan secara konsisten dan benar. Penilaian melibatkan identifikasi dan hitungan faktor-faktor di dalam pengembangan suatu produk perangkat lunak. Termasuk di dalamnya proses-proses dengan siapa perangkat lunak itu dikembangkan, sumber daya personil dan dukungan yang digunakan di dalam pengembangan dan sifat alami produk diri sendiri.

Meramalkan biaya dan jangka waktu suatu proyek masih menjadi suatu masalah. Jack dan Mannion (1995) menyimpulkan dari survei organisasi-organisasi bahwa hanya 25% dari proyek-proyek tepat dengan prediksi biaya dan jadwal mereka mula-mula, 66% dari perusahaan itu meremehkan waktu dan biaya, lalu biaya untuk proyek-proyek yang serupa dapat bertambah sampai 200%. Ada beberapa teknik-teknik penilaian yang berbeda yang sekarang ini digunakan di dalam industri dan ini dapat diatur ke dalam 3 kategori utama:

model-model Algorithmic yang meramalkan usaha dan jangka waktu sebagai suatu fungsi sejumlah variabel. Algorithmic yang paling umum digunakan adalah COCOMO (COnstructive COst MOdel) (Boehm 1981) dan Function Point Analysis ( Albrecht &Gaffney 1983).

Ahli pakar menyertai ramalan-ramalan yang didasarkan pada keterampilan dan pengalaman dari satu atau lebih ahli-ahli.

Penilaian oleh Analogy yang menyertai perbandingan dari satu atau lebih proyek dengan suatu proyek baru yang serupa untuk meramalkan biaya dan jadwal.

1. Cellular Manufacturing Process Model (CMPM)

Secara tradisional, ICL (sebuah Company) sudah menggunakan V-diagram waterfall life cycle model untuk merencanakan dan mengendalikan pengembangan dari pengelola perangkat lunak dan sistem. Perkiraan-perkiraan kegiatan dan pertimbangan waktu yang didasarkan pada satu pemahaman arsitektur solusi, dan pendapat ahli atas derajat kesulitan serta masalah potensial akan ditemui selama aktivitas pengintegrasian. ketersediaan sumber daya dan ukuran tim juga diambil ketika membuat estimasi. Sejumlah alternatif life cycle models dan metoda-metoda pengembangan, saat ini tak satupun menunjukan hasil spesifik untuk mengatur pengintegrasian yang kompleks dari komponen-komponen yang disediakan.

CMPM adalah life cycle model yang baru dikembangkan bersama-sama oleh ICL dan Southampton University. Model ini memungkinkan pemahaman lebih dini dan lebih menyeluruh atas persyaratan pengintegrasian. Pemahaman ini memastikan verifikasi lebih baik dan pengesahan perangkat lunak dan sistem yang terintegrasi dan membantu melawan resiko potensial.

CMPM adalah satu set "Manufacturing Cells" berisi hubungan antara sel-sel yang digambarkan sebagai suatu set dari metrics. Model didasarkan pada model jaringan dari pengembangan software, dan pada "value chain" model. Model ini menunjukkan suatu pandangan ingintegrasi produk dari suatu campuran dari yang dibeli dan komponen-komponen diri yang dibangun sendiri. Di dalam konteks ini, integrasi sistem diartikan aktivitas yang mengidentifikasi (dan menetapkan) komponen-komponen dan mengembangkan "glue" untuk mengikat mereka (gambar 1.0).

Masing-masing aktivitas pengintegrasian digambarkan sebagai suatu sel di dalam CMPM. Model ini hirarki. Masing-masing sel bisa merupakan suatu komponen di suatu aktivitas pengintegrasian tingkat yang lebih tinggi.

Produk-produk dengan struktur hierarkis membiarkan diri mereka diberkembangkan dan dibuat di suatu jaringan dari manufacturing cells. Masing-masing sel bertanggung jawab atas satu tingkatan integrasi. Sel menerima komponen-komponen dari para supplier, membuat beberapa komponen di tempat itu, menempelkan komponen-komponen ke dalam satu produk yang terintegrasi (yang diuji untuk standar output) dan mengirim produk yang terintegrasi kepada pelanggan atau kepada sel yang melaksanakan tingkat integrasi berikutnya. Proses pengembangan software yang tradisional dapat digambarkan sebagai satu sel pengintegrasian di dalam dari CMPM. Itu membuat semua komponen (baris kode) inhouse dan merekatkan (compiles and builds) mereka ke dalam modul perangkat lunak atau produk perangkat lunak.

a. Metrics dalam CMPM

Enam metrics didefinisikan untuk setiap sel dalam jaringan CMPM (gambar 2). Q, P, and S harga penegendali dan digunakan untuk menentukan upaya yang dibutuhkan untuk menyelesaikan proyek. T ditentukan dari W dengan mengambil sumber yang ada, N, menjadi account.

W, T, dan N digambarkan di dalam COCOMO. definisi-definisi pengendali biaya adalah:

Q: bagian persyaratan-persyaratan pada komponen-komponen input tanpa biaya yang terjadi di dalam sel pengintegrasian.

P: bagian persyaratan-persyaratan pelanggan pada produk terintegrasi yang dijumpai dengan produk yang dikirimkan.

S: Ukuran dari komponen-komponen yang dikirimkan dan dikonsumsi di dalam “Unit-unit Pengintegrasian Standar” (SIU'S).

Kualitas metrics secara langsung berhubungan dengan resiko proyek. Lebih miskin kualitas input, semakin besar resiko menemukan masalah tak terduga selama pengintegrasian. Sama dengan, lebih miskin mutu yang dikirimkan, lebih besar resiko pelanggan-pelanggan menemukan masalah yang tak terduga.

Baseline data (tabel 1) dikumpulkan dari proyek-proyek yang diselesaikan sebelum eksperimen. Satu-satunya data yang tersedia adalah usaha total yang dihabiskan dan jangka waktu aktivitas pengembangan.

Pengukuran di atas dapat dibandingkan dengan yang estimasi asli pada masing-masing release. Data menunjukkan usaha nyata bervariasi 76% (24% under-spend) sampai 183% (83% overspend) dari prediksi, sedangkan jangka waktu bervariasi dari 152% (52% overrun) sampai 248% (148% overrun). Bahkan ketika proyek under-spend berbanding terbalik dengan estimasi usaha asli, waktu yang dilewatkan lebih dari dua kali perkiraan. Bukti dari proyek-proyek di dalam organisasi lainnya mengkonfirmasikan generalisasi bahwa hampir semua proyek-proyek overrun dari 50% -100%.

Langkah pertama adalah menggambarkan proyek sebagai suatu set dari sel-sel peroduksi yang terkait dengan menggunakan CMPM, masing-masing sel menunjukan integrasi beberapa komponen yang menghasilkan satu bagian sistim yang lain. Masing-masing sel, mengestimasi untuk biaya Q, P, dan S, menggunakan data checklist dan historis di dalam experience database. Pengendalian biaya digunakan untuk meramalkan usaha (W) dan waktu (T), pengambilan ketersediaan sumber daya pelanggan.

Gambar 3: Estimasi biaya dan proses project tracking

Table.2: Checklist generic work products untuk mengestimasi ukuran

2. Estimasi Proyek Menggunakan CBR

Case-based reasoning (CBR) berfungsi sebagai suatu memori terstruktur di mana pengalaman disimpan sebagai kasus-kasus dan bisa digambarkan lagi ketika permasalahan yang baru muncul dalam proyek baru. Sehingga kita dapat mengestimasi proyek baru berdasarkan pengalaman proyek sebelumnya yang serupa. Efektivitas CBR pada satu tingkat operasional sudah terbukti dengan banyak aplikasi. Sungguh ada banyak riset memakai CBR pada tingkat operasional dalam perkiraan biaya proyek perangkat lunak yang kita minati.

Estimasi biaya proyek perangkat lunak adalah masalah karena sulit untuk memperoleh gambaran ukuran dan biaya yang akurat yang bisa diketahui di awal proses pengembangan. Ini adalah karakteristik dari weak theory domains di mana CBR dapat menjadi solusinya. Pendekatan CBR menggunakan teknik estimasi konvensional seperti COCOMO atau Function Point Analysis untuk membangun suatu struktur kasus.

a. Estimasi Awal

Ketelitian estimasi perangkat lunak mempunyai suatu dampak langsung pada mutu keputusan investasi organisasi perangkat lunak. Penilaian yang akurat sejak awal sebisa mungkin dilakukan dalam development life cycle. Ini penting sebagai perkiraan awal sebelum dimasukan ke analisa biaya/untung dan keputusan dengan strategi yang lain.

Untuk mengestimasi kegiatan pengembangan pada tahap awal development life cycle perlu dilakukan identifikasi atribut-atribut dari proyek. Kebanyakan dari model-model algorithmic menggunakan ukuran dari ukuran sistim seperti kunci input untuk prosedur estimasi. COCOMO menggunakan bentuk kode sebagai ukuran dari ukuran perangkat lunak. Function Point Analysis menggunakan suatu ukuran dari ukuran sistim disebut Function Point yang berasal dari fitur desain seperti banyaknya input, output dan entitas dalam sistim perangkat lunak. Aplikasi CBR di atas juga menggunakan fitur disain dan metrics yang tidak bisa diketahui setiap kepastiannya yang layak di awal dalam life cycle pada saat estimasi biaya awal.

b. CBR pada Estimasi Awal

Satu cara yang sederhana menghitung usaha (effort) yang dilibatkan dalam pengembangan sistim perangkat lunak memerlukan ukuran sistim (contoh poin-poin kode atau fungsi) dikalikan dengan produktivitas yang diharapkan tim proyek (seperti banyaknya bentuk dari kode atau titik fungsi per hari).

Effort  Size * Productivity

Salah satu persoalan paling sulit berhubungan dengan usaha estimasi di awal penilaian adalah menyediakan ukuran dari ukuran sistim. Shepperd et al. (1996) menjelaskan dengan analogi untuk estimasi usaha dan menyatakan bahwa sangat penting untuk memilih sedikitnya nya variabel atau fitur untuk bertindak sebagai pengendali ukuran (size driver). Pada tahap siklus pengembangan pengendali ukuran digunakan untuk menghasilkan estimasi. Tanpa beberapa kerja desain mustahil untuk mengestimasi banyaknya input, layar-layar atau kelas-kelas dengan teliti. Untuk alasan ini tidak baik untuk mengharapkan estimasi yang akurat (contoh dalam bulan kerja). Lebih sesuai menggunakan prediksi fitur yang tersedia dengan suatu penimbang yang akan menandai adanya pengaruh dimana fitur kasus akan memiliki produktivitas proyek yang diharapkan.

Gambar 4 menampilkan usulan representasi kasus. Beberapa fitur di dalam representasi kasus mengacu pada pengaruh dan pengalaman dari manajemen proyek pengembangan software. “Manajemen bisa mempunyai lebih banyak pengaruh pada produktivitas dari staf programming daripada teknologi yang digunakan sekarang” ( Kendall & Lamb 1977). Variabel itu dikenali sebagai variabel-variabel resiko atau variabel-variabel yang menambah

overrun proyek atau menyebabkan estimasi yang tidak akurat dalam berbagai studi-studi (Barki et al. 1993; Subramanian &Breslawski 1994; Subramanian &Breslawski 1995;

Heemstra 1992). Subramanian & Breslawski (1995) juga menemukan bahwa menggunakan suatu pengalaman manajer proyek untuk menyesuaikan estimasi yang diperoleh dari model-model algorithmic untuk meningkatkan akuransi estimasi usaha.

komposisi dan pengalaman dari tim proyek juga menjadi kunci usaha dalam mempengaruhi estimasi pengembangan (Heemstra 1992; Barki et al. 1993; Boehm &Papaccio 1990; Jeffery 1987). Heemstra (1992) menyimpulkan bahwa “aspek manusia” adalah sangat penting dalam estimasi biaya perangkat lunak. Fitur seperti mutu, pengalaman dan komposisi tim proyek, tingkat derajat manager proyek dapat memotivasi dan mendorong timnya .

Gambar 4

Riset-riset juga telah mebuktikan pentingnya keikutsertaan pengguna dan pengalamannya di dalam proyek-proyek sukses (Barki et al 1993; Lederer &Prasad 1992; Subramanian &Breslawski 1995).

Beberapa cost driver yang digunakan dalam teknik-teknik estimasi Aplikasi sendiri adalah variabel-variabel yang bersifat tergantung pada jumlah tertentu dari desain yang sudah diselesaikan, seperti kompleksitas perangkat lunak atau ukuran database.

Pertimbangan akhir metode pengembangan, studi-studi sudah menunjukkan bahwa penggunaan dari alat-alat produktivitas, teknologi tertentu dan teknik-teknik desain standar dapat mempengaruhi estimasi ( Lederer &Prasad 1992; Subramanian &Breslawski 1994; Heemstra 1992). Lederer & Prasad (1992) juga menyimpulkan bahwa ketelitian dari estimasi meningkat dengan pemakaian fakta-fakta dan standarisasi yang didokumentasikan.

KESIMPULAN

Eksperimen-eksperimen sudah menunjukkan bahwa CMPM menyediakan suatu makna yang lebih efektif untuk perencanaan dan pengerjaan perangkat lunak dan proyek-proyek pengintegrasian sistem yang tergantung atas komponen-komponen yang disediakan oleh pihak ketiga. Metode ini cukup fleksibel untuk dikembangkan oleh organisasi yang integrasi sistem komponen-komponennya disediakan oleh pihak ketiga, seperti COTS atau pengembangan kolaboratif. Ini dapat digunakan untuk proyek-proyek ukuran kecil sampai menengah.

Mengestimasi proyek baru berdasarkan pengalaman proyek (CBR) yang serupa cukup baik untuk diterapkan. Kemungkinan untuk mengalami kesalahan yang sama dapat ditanggulangi dengan estimasi yang benar. Faktor manusia juga sangat penting bagi kesuksuksesan dari suatu proyek pengembangan software walaupun estimasi yang dibuat sudah sangat bagus. Tanpa kualitas developer dan pelaku manajemen proyek yang berkualitas sebuah proyek tidak akan berhasil dengan baik.

REFERENSI

An Experiment to Improve Cost Estimation and Project Tracking for Software and Systems Integration Projects

Brian Chatters, ICL, Wenlock Way, West Gorton, Manchester, M12 5DR, UK

Peter Henderson, University of Southampton, UK

Chris Rostron, ICL, Manchester, UK

The Limits of CBR in Software Project Estimation

Sarah Jane Delany1, Pádraig Cunningham2 and Wolfgang Wilke3

1Dublin Institute of Technology, Ireland

2Trinity College Dublin, Ireland

3University of Kaiserslautern, Germany.

CASE STUDY QUALITY MANAGEMEN

Penerapan Quality Management Suatu Evaluasi Melalui Karakteristik Kerja

Pengantar

Managemen mengalami transformasi yang cukup radikal, yaitu perubahan dari modeltradisional bergeser kepada Quality Management (QM) yang menuntut keunggulan organisasi seperti kecepatan, daya tanggap, kelincahan, pembelajaran, dan kompetensi karyawan.Penilitian ini merupakan suatu evaluasi penerapan program QM yang dijalankan oleh Pabrik Gula (PG) Candi Baru Sidoarjo melalui Gugus Kendali Mutu (GKM), yang merupa-kan suatu pendekatan dalam mewujudkan pemberdayaan karyawan, yang pada tingkat berbeda memiliki persepsi tentang mutu berbeda.Penelitian mengacu pada pengukuran kepuasan kerja karyawan yang difokuskan pada karakteristik kerja, meliputi variasi ketrampilan, identifikasi tugas, signifikansi tugas,otonomi dan umpan balik. Hasil penelitian menyimpulkan bahwa berdasarkan ukurankepuasan terhadap indikator-indikator; menyadari sumberdaya yang dimiliki dan yangdigunakan, perlengkapan dan peralatan serta materi yang tersedia, batas waktu yang diberikan, maka terdapat hubungan positip antara kepuasan kerja dengan variasi ketrampilan. Untuk indikator-indikator; cara dan hasil kerja yang dinilai diri sendiri maupun penilaian rekan kerja, maka terdapat hubungan positip antara kepuasan kerja dengan identifikasi tugas. Untuk indikator-indikator; kerjasama karyawan dalam maupun antar bagian, antara karyawan bawahan dan atasan, maka terdapat hubungan positip antara kepuasan kerja dengan signifikasi tugas. Secara umum penerapan GKM dalam memberdayakan karyawan mempunyai dampak positip terhadap kepuasan karyawan PG Candi Baru

PENDAHULUAN

Perubahan lingkungan dari lingkup lokal menjadi global menyebabkan terjadinya perubahan di hampir semua sektor kehidupan. Adanya keharusan untuk penyesuaian situasi secara global, membuat manajer tidak hanya mengacu pada situasi lokal, nasional ataupun regional, namun harus mampu bersaing secara internasional. Sikap perusahaan untuk menghadapi hal ini hanya ada satu, yaitu ikut mengalami perubahan baik secara struktural maupun sumber daya yang dimiliki. Salah satu cara yang bisa ditempuh oleh perusahaan adalah dengan membenahi sumber daya manusia yang dimilikinya agar bisa bertahan dalam persaingan jangka panjang. Penerapan Quality Management (QM) dalam perusahaan dapat membantu perusahaan dalam menghadapi persaingan yang makin ketat. QM mengacu pada perubahan organisasi, mulai dari perubahan struktur, tujuan, peran manajer, dan peran karyawan.Penerapan QM dalam organisasi perusahaan ternyata mempunyai dampak positif terhadap karakteristik kerja (Rahayu, 2000).
Banyak peneliti yang menyimpulkan bahwa pekerjaan (job) dan khususnya karir saat ini
berbeda dengan beberapa dekade yang lalu (Cappeli, 1999). Pendekatan lama atau tradisional,yang disebut career jobs, didefinisikan sebagai pekerjaan yang full-time dengan masa kerja yang lama, pembayaran gaji yang layak, menawarkan manfaat, dan mencerminkan perhatian kebijakan umum tentang apakah pekerjaan memberikan solusi untuk menghindari kesulitan ekonomi (Jacoby, 1999), namun pengertian ini sedikit demi sedikit terkikis dengan pergeseran kebutuhan pasar dan perubahan dunia bisnis.
Dan saat ini banyak pemikir manajemen berpendapat bahwa pengganti pendekatan
tradisional yang berfokus pada karyawan sebaiknya berfokus pada kemampuan bekerja
karyawan, atau dengan kata lain kita harus melupakan ketergantungan pada satu pekerjaan, satu perusahaan, atau satu jalur karir sehingga berkembang bentuk baru dari karir tradisional menjadi Protean Career. Oleh Hall & Moss (1998) Protean Career didiskripsikan sebagai suatu proses dimana seseorang, bukan organisasi, yang mengatur dimana orang yang protean tersebut memiliki pilihan karirnya sendiri dan mencari untuk memenuhi dirinya yang merupakan elemen yang terintegrasi dalam hidupnya, dan kesuksesan yang dicapai adalah kesuksesan internal atau psikologis, dan bukan eksternal. Dengan nada yang sama, Waterman dkk. (1994) mengemukakan career-resilient workforce yang diartikan sebagai sebuah kelompok karyawan yang tidak hanya berdedikasi pada ide dari pembelajaran yang berkelanjutan (continuous learning) tetapi juga menyiapkan diri untuk menghadapi perubahan, bertanggung jawab pada pengaturan karir mereka sendiri, dan yang terakhir adalah mempunyai komitmen terhadap kesuksesan perusahaan. Dalam artikel ini akan dibahas tentang perubahan faktor internal dan eksternal perusahaan, paradigma lama menjadi paradigma baru dan dampak serta implikasinya bagi individu dan perusahaan dalam memanajemeni karirnya

PENGERTIAN MANAJEMEN SUMBER DAYA MANUSIA

Manajemen Sumber Daya Manusia mencakup masalah-masalah yang berkaitan dengan
pembinaan, penggunaan sumber daya manusia baik yang berada dalam hubungan kerja maupun yang berusaha sendiri (Basir Barthos, 1993). Menurut Stephen P. Robbinson “activities necessary for staffing the organization and sustaining high employee performance”, artinya eraktifitas diperlukan untuk menilai performance seseorang dalam organisasi. Menurut Luis R. Gomez-Mejia, Cs.: “Human resources people who work in an organization. Also called personnel” .

PENGERTIAN QM

Quality Management (pengertian dalam kasus ini ) didefinisikan sebagai konsep perbaikan yang dilakukan secara terus menerus, yang melibatkan semua karyawan di setiap level organisasi, untuk mencapai kualitas yang ‘exellent’ dalam semua aspek organisasi melalui proses manajemen

1. Pengertian Kualitas
Bukan berarti sekedar produk bebas cacat, tetapi QM lebih menekankan pelayanan kualitas.Kualitas didefinisikan oleh pelanggan, bukan organisasi atau manajer departemen pengendalian kualitas. Kenyataan bahwa ekspektasi pelanggan bersifat individual,
tergantung pada latar belakang sosial ekonomis dan karakteristik demografis, mempunyai implikasi penting : kualitas bagi seorang pelanggan mungkin tidak sama bagi pelanggan lain.

2. Pengertian managemen
Mengandung arti bahwa QM merupakan pendekatan managemen, bukan pendekatan teknis pengendalian kualitas yang sempit. Pendekatan QM sangat berorientasi pada managemen orang. Implementasi QM mensyaratkan berbagai perubahan organisasional dan manajerial total dan fundamental, yang mencakup misi, visi, orientasi strategic, dan berbagai praktek managemen vital lainnya.
Program QM memiliki dua sisi kualitas (Wilkinson, 1992) yaitu hard side of quality dan
soft side of quality. Sisi hard side of quality meliputi semua upaya perbaikan proses produksi mulai dari desain produk sampai dengan penggunaan alat-alat pengendalian seperti Quality Function Development, Just In Time dan Statistical Prosses Control), dan perubahan organisasional lainnya (seperti struktur organisasi, budaya organisasi, dan sebagainya), dengan upaya demikian diharapkan akan dapat meningkatkan kualitas produk yang pada gilirannya nanti dapat memuaskan kebutuhan konsumen.
Penekanan “soft side of quality” lebih terfokus pada upaya menciptakan kesadaran karyawan akan pentingnya arti kepuasan konsumen dan menumbuhkan komitmen karyawan untuk selalu memperbaiki kualitas. Upaya tersebut dapat dilakukan melalui pendidikan dan pelatihan yang mendukung, pendekatan sistem pengupahan yang mendukung, struktur kerja. Semua upaya ini termasuk dalam kegiatan managemen sumber daya manusia dan dengan menerapkan QM akan berakibat pada perubahan struktur organisasional, peran manajer, karyawan, tujuan organisasi dan sebagainya, yang pada gilirannya akan mengubah karakteristik kerja.

PENGERTIAN TEORI KARAKTERISTIK KERJA

Desain kerja merupakan salah satu faktor sistem yang dapat mempengaruhi motivasi maupun kepuasan kerja dan hal ini dapat dihubungkan dengan konsep QM (Waldman, 1994). Desain kerja didefinisikan sebagai proses untuk memutuskan tugas-tugas khusus apa yang seharusnya dilakukan oleh setiap pemegang kerja dalam konteks seluruh kerja yang akan dicapai oleh organisasi (Wagner III, 1995). Pendekatan klasik tentang desain kerja yang diajukan oleh Hackman dan Oldham (1980) dikenal dengan istilah teori karakteristik pekerjaan (job characteristics theory).

Beberapa prinsip dari model yang diajukan oleh Hackman dan Oldham (dalam Rahayu,
2000) mempunyai kesesuaian dengan prinsip QM. Prinsip adanya hubungan langsung dengan langganan membuat karyawan dapat berkomunikasi dan bertanggungjawab untuk mengelola hubungan ini, baik dengan konsumen eksternal maupun konsumen internal. Di samping itu Hackman dan Oldham juga memasukkan tugas untuk memutuskan kapan dan bagaimana mengontrol kualitas dalam desain kerjanya. Dengan mengijinkan karyawan untuk mengontrol sendiri kualitas mereka secara otomatis akan meningkatkan umpan balik langsung dari pekerjaan itu sendiri. Hal ini tidak pernah terpikirkan dalam desain kerja secara tradisional,dimana pengontrolan kualitas dilakukan oleh orang lain.

METODE PENELITIAN

Penelitian ini dilakukan di PG Candi Baru, jalan Raya Candi no. 10, Sidoarjo, sebagai salah satu perusahaan yang telah menerapkan konsep QM. Objek penelitian adalah seluruh karyawan tetap sejumlah 266 karyawan. Sumber informasi diperoleh melalui kuisioner dan wawancara serta data-data sekunder yang sudah ada di perusahaan dan relevan dengan penelitian pengukuran karakteristik kerja.

Variabel-variabel yang diamati adalah menyangkut 5 karekteristik kerja, yaitu; variasi
ketrampilan, identifikasi tugas, otonomi, umpan balik, dengan menggunakan skala pengukuran skala Likert. Analisis yang digunakan adalah analisis deskriptif mengenai persepsi karyawan terhadap karateristik kerja pada perusahaan ini setelah dilakukan penerapan QM yang dalam perusahaan ini dinamakan GKM.

UJI RELIABILITAS DAN VALIDITAS

Pertanyaan-pertanyaan dalam kuisioner disusun dengan mengacu pada pertanyaan-
pertanyaan dalam mengevaluasi penerapan QM pada buku The Human Dimension of Quality (Thomas,B, 1995), tetapi pertanyaan-pertanyaan yang terdapat dalam buku tersebut tidak semuanya diambil untuk kuisioner penelitian, oleh karena perlu diadakan uji reliabilitas. Sedangkan, untuk skala tetap sama dengan yang digunakan dalam sumber, yaitu skala Likert 1-5, karena itu tidak perlu mengadakan pengujian validitas lagi (uji validitas dilakukan dengan tujuan untuk mengetahui apakah skala yang digunakan mampu menghasilkan data yang akurat sesuai dengan tujuan ukurnya).
Tujuan uji reliabilitas adalah untuk mengetahui apakah cara pengukuran yang dilakukan, dalam hal ini untuk mengetahui tingkat kepuasan karyawan terhadap karakteristik kerja, benar-benar dapat mengukur, atau dengan kata lain apakah hasil dari pengukuran konsisten dan dapat dipercaya. Pengukuran yang tidak reliabel akan menghasilkan skor yang tidak dapat dipercaya karena perbedaan skor yang terjadi diantara individu lebih ditentukan oleh faktor eror daripada faktor perbedaan yang sesungguhnya. Pengukuran yang tidak reliabel tentu tidak akan konsisten pula dari waktu ke waktu. Reliabilitas, dalam aplikasinya, dinyatakan oleh koefisien reliabilitas (r
xx) yang angkanya berada dalam rentang 0 sampai dengan 1.00. Semakin tinggi koefisien reliabilitas mendekati 1.00, berarti semakin tinggi reliabilitas, dan sebaliknya.
Prosedur pengujian reliabilitas yang digunakan dalam penelitian ini adalah Koefisien
Reliabilitas Alpha. Data untuk menghitung koefisien reliabilitas alpha diperoleh lewat penyajian satu bentuk skala yang dikenakan hanya sekali saja pada sekelompok responden. Skala yang diestimasi reliabilitasnya dibelah menjadi dua atau tiga bagian, sehingga tiap belahan berisi item-item dalam jumlah yang sama banyak. 

ANALISA PENERAPAN Quality Managemen

Program QM yang diterapkan oleh pabrik gula Candi Baru Sidoarjo, yaitu program QM yang mengacu pada sisi soft side of quality. Konsep yang diterapkannya adalah Konsep Gugus Kendali Mutu, yang mengacu pada pemberdayaan karyawan. Gugus Kendali Mutu adalah kelompok yang terdiri dari 6 sampai 12 karyawan, mereka secara sukarela mengadakan pertemuan untuk memecahkan masalah-masalah yang berkaitan dengan pekerjaan. Kelompok Gugus Kendali Mutu yang terbentuk di PG Candi Baru dapat dilihat pada Tabel1. Berdasarkan program QM yang dijalankan di PG Candi Sidoarjo dengan nama Gugus Kendali Mutu, dapat dikatakan bahwa perusahaan tersebut telah menerapkan program QM pada sisi “soft of quality”. Hasil uji reliabilitas yang dilakukan, menghasilkan koefisien reliabilitas alpha (α) sebesar 0.900871

KESIMPULAN

Dari beberapa statistik Penerapan QM pada soft side di pabrik gula Candi Baru Sidoarjo, telah menerapkan pendidikan, ketrampilan yang dimiliki karyawan dalam pekerjaan, namun ada hal yang tidak dapat diubah oleh beberapa karyawan atau malah sebagian besar karyawan. Karyawan belum merasa puas dengan adanya otonomi yang diberikan padahal hal utama yang diharapkan timbul dari adanya penerapan QM adalah otonomi karyawan. Karyawan dengan masa kerja lebih dari 10 tahun telah terbiasa dengan pola kepemimpinan lama sehingga mereka merasa tidak nyaman dengan kebebasan yang diberikan dalam bekerja. Melihat hal tersebut maka perusahaan hendaknya lebih mempersiapkan karyawannya untuk menghadapi perubahan yang terjadi dalam lingkungan kerja sebagai akibat adanya penerapan QM. Misalnya, dengan mulai melatih karyawan untuk memutuskan sesuatu yang harus diselesaikannya tanpa menanyakannya kepada supervisornya, selanjutnya apabila karyawan telah terbiasa, akan lebih mudah untuk membiasakan karyawan merubah cara pandangnya terhadap peran manajer

Nama : Hubertus Bith

N I M : 22 04 3641

Group : B

Source : Jurnal managemen & Kewirausahaan Vol. 5, No. 1, Maret 2003: 72 - 84

MEASUREMENT & METRIC

by
Name : Hardi Sudanta Budiaryana
Number of Student : 22064114
Group : B (RPL2)

MEASUREMENT & METRIC

Pengukuran perangkat lunak merupakan salah satu bagian penting yang perlu diperhatikan dalam pengembangan perangkat lunak. Pengukuran terhadap perangkat lunak dapat dilakukan terhadap kompleksitas, jumlah LOC (Line of Code) pada perangkat lunak, maupun tingkat kesalahan yang ada pada perangkat lunak tersebut. Alasan dilakukannya pengukuran adalah sebagai berikut :

1. Kualitas suatu software akan terlalu abstrak tanpa dilakukannya pengukuran terhadap perangkat lunak itu sendiri.
2. Eksplorasi terhadap Performance, Understandability, Testability, Maintainability, dan Security dari perangkat lunak.
3. Menghindar dari kemungkinan kegagalan dalam proyek pembuatan perangkat lunak, dimana dengan estimasi yang dilakukan maka dapat diperkirakan waktu yang dibutuhkan dalam pembuatan perangkat lunak serta budget yang dibutuhkan.
4. Sebagai bentuk evaluasi terhadap pengembangan perangkat lunak

Banyak keuntungan yang didapatkan dari pengukuran perangkat lunak :

1. Lebih tepat dalam estimasi serta perencanaan pembuatan perangkat lunak.
2. Dapat melakukan identifikasi resiko lebih awal sehingga dapat menghindari kegagalan dalam perancangan dan pengembangan perangkat lunak
3. Pengukuran yang dilakukan dapat dijadikan sebagai referensi untuk langkah awal dalam pengembangan perangkat lunak di masa yang akan datang.

Dalam pengukuran metrik sutau perangkat lunak dapat dilakukan walau tanpa perangkat lunak, seperti metode Cyclometic Complecity , meliputi region, predicate node, dan Mc Cabe. Dalam pembahasan ini, akan dipakai pemecahan kasus dengan metode Mc Cabe dalam melakukan pengukuran perangkat lunak.

Adapun flowchat yangt diperoleh dari source code program adalah sebagai berikut :

N : 12 (jumlah node)

E : 14 (jumlah Edge)

Perhitungan dengan metode Mc Cabe :

= E – N + 2

= 14 – 12 + 2

= 4

Dengan memperoleh nilai itu, maka lakukan pengecekan terhadap tabel kompleksitas perangkat lunak :

Cyclomatic	Complexity Risk Evaluation
1-10	a simple program, without much risk
11-20	more complex, moderate risk
21-50	complex, high risk program
>50	untestable program (very high risk)

Dengan melihat tabel tersebut diatas, maka dapat ditentukan bahwa program yang ditunjukkan oleh flowchart diatas dikategorikan sebagai program yang simpel.

Selain melakukan penghitungan seperti diatas, untuk mengetahui kompleksitas suatau perangkat lunak dapat digunakan software-software pengukur kompleksitas seperti : crystal flow, Resource Standard Metrics ver.7.0, OXY PROJECT METRICS 1.8.1, SLOC Metric 3.0, Jmetric, Resource Standard Metric, Loc METRICS, dan masih banyak perangkat lunak lainnya.

Secara umum perangkal lunak pengukur kompleksitas itu seudah di tentukan pemakaiannya terhadap bahasa pemrograman tertentu. Seperi Crystal Flow yang terdiri dari dua jenis yaitu crystal flow for C yang khusus untuk mengukur perangkat lunak yang dibangun dengan bahasa pemrograman C dan Crystal flow for C++ yang perangkat lunaknya dibanguan dengan bahasa C++.

Referensi

SOFTWARE MEASUREMENT ,SANDRO MORASCA

Università dell'Insubria, Dipartimento di Scienze Chimiche, Fisiche e Matematiche Sede di Como

Email: morasca@uninsubria.it

Measurement, Adi Mulyanto

Departemen Teknik Informatika Institut Teknologi Bandung

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.