SOFTWARE MAINTENANCE MATURITY MODEL
Pemeliharaan perangkat lunak masih tidak menerima bagian terlihat dari perhatian manajemen dan menderita dari kurangnya perencanaan, seperti yang sering digambarkan oleh manajemen krisis gaya. Sebagian dari masalah adalah bahwa pemeliharaan biasanya dianggap sebagai mahal dan tidak efektif. Selain itu, beberapa proposal dari praktik terbaik telah dimasukkan maju yang mudah dapat diterapkan dalam industri. Secara umum, rekayasa perangkat lunak masyarakat mengharapkan bahwa kualitas produk akan ditingkatkan jika pemeliharaan proses ditingkatkan. Namun, para peneliti cenderung mengembangkan terisolasi dan sangat teknis solusi yang cukup menantang untuk diterapkan dalam industri, lebih-lebih di kelompok pemeliharaan kecil yang memiliki anggaran yang sangat kecil dan waktu yang terbatas untuk meningkatkan kegiatan pemeliharaan mereka. Pada saat yang sama, sejumlah perangkat lunak pemeliharaan praktik terbaik telah dilaksanakan di beberapa yang terbaik perawatan jangka organisasi, meskipun praktik ini belum diakui dan kebutuhan akan lebih baik dijelaskan untuk mempersiapkan mereka untuk transfer teknologi untuk industri pada umumnya.
Untuk fungsi pengembangan perangkat lunak, banyak model jatuh tempo sudah ada untukmengevaluasi proses pembangunan dan untuk mengusulkan perbaikan. Untuk fungsi perawatan perangkat lunak, model penilaian yang tersedia jauh lebih luas. Tulisan ini didasarkan pada model komprehensif pertama untuk memperhitungkan karakteristik khusus untuk proses pemeliharaan, Software Maintenance Maturity Model - S3M.
A. Software Maintenance
Hal ini penting untuk memahami ruang lingkup kegiatan pemeliharaan dan konteksnya di mana kerja perangkat lunak pengelola setiap hari. Memang ada beberapa interface dalam konteks organisasi pemeliharaan perangkat lunak:• Pelanggan dan pengguna dari perawatan perangkat lunak• Infrastruktur dan departemen operasi• Pengembang• Pemasok• PemeliharaanDengan mempertimbangkan bahwa antarmuka ini memerlukan layanan harian , pemeliharaanmanajer harus menjaga aplikasi berjalan lancar , bereaksi dengan cepat untuk memulihkan layanan ketika ada masalah produksi, memenuhi atau melebihi tingkat yang disepakati pelayanan, menjaga kepercayaan dari masyarakat pengguna bahwa mereka memiliki dedikasi dan tim dukungan kompeten di pembuangan mereka yang bertindak dalam persetujuan anggaran.
B. Aspek Kegiatan Maintenance
Sebuah proses yang digunakan, jika diperlukan, oleh proses operasional dikatakan menjadi 'proses dukungan' operasional. Di kebanyakan organisasi, proses ini bersama oleh kedua pengembang dan pengelola. klasifikasi ini meliputi:a) proses dokumentasi.b) perangkat lunak fungsi manajemen konfigurasi dan alat-alat, yang sering bersama dengan pengembang.c) proses dan kualitas produk jaminan.d) proses verifikasi dan validasi.e) review dan audit.f) proses penyelesaian masalah, yang sering berbagi dengan infrastruktur dan operasi departemen.Ini semua adalah proses kunci yang diperlukan untuk mendukung kegiatan proses perawatan perangkat lunak operasional dalam kegiatan maintenance. 'Proses Organisasi' yang biasanya ditawarkan oleh organisasi IS dan oleh departemen lain dalam organisasi (misalnya banyak perspektif perencanaan pemeliharaan, kegiatan yang berhubungan dengan proses, pengukuran, inovasi, pelatihan, dan manusia sumber). Meskipun penting untuk mengukur dan menilai proses-proses ini, lebih penting bagi pengelola untuk menentukan dan mengoptimalkan proses operasional pertama.
C. Aktivitas Maintenance
Sebuah proses didefinisikan sebagai urutan langkah-langkah yang dilakukan untuk tujuan tertentu. Ini diamati bahwa kualitas perangkat lunak sangat ditentukan oleh kualitas proses pembangunan digunakan untuk merancang itu dan untuk mempertahankannya. Pemeliharaan Tujuan manajer, kemudian, adalah untuk membantu membawa proses seperti di bawah kontrol, dan pengukuranmemiliki peran penting untuk bermain dalam membantu dia mencapai tujuan tersebut. Karenamanajer pemeliharaan memiliki sedikit kontrol atas pengembangan perangkat lunak, dan harus mengidentifikasi titik awal di mana dapat mempengaruhi karakteristik rawatan dari perangkat lunak baru yang sedang dibangun. Memulai pengukuran selama pra-pengiriman dan transisi merupakan strategi kunci dalam menilai kualitas produk sedang dikembangkan dan kesiapannya untuk dapat diterima dalam pemeliharaan. Untuk mencapai hal ini obyektif, keputusan dapat dibuat untuk melaksanakan program pengukuran pemeliharaan dan link ke pengukuran proyek pengembangan perangkat lunak. Sebagai contoh, jika pengelola dapat mengatur beberapa target rawatan awal dalam pengembangan software baru, kualitas dapat diukur baik selama dan setelah pembangunan.
D. Teknik-teknik Maintenance
Tergantung pada sumber permintaan pemeliharaan , kegiatan pemeliharaan ditangani melaluiproses yang berbeda. Untuk setiap sumber permintaan , pemeliharaan kunci layanan / proses , bersama-sama dengan pendaftaran kategori pemeliharaan terkait pekerjaan , dimulai. Untukmisalnya, jika pengguna adalah sumber dari permintaan, maka permintaan perubahan terkait dengan penggunaan operasional perangkat lunak dan pekerjaan yang harus dilakukan dapat diklasifikasikan dalam satu dari tiga layanan pemeliharaan: koreksi , evolusi (yang regroups adaptif , perfektif dan pemeliharaan preventif) , atau dukungan operasional . Dalam beberapa kasus, proses pendukung , seperti service level agreement (SLA) informasi , juga akan dibutuhkan sebagai bagian penting dari kegiatan dukungan operasional. Daftar proses teknik perangkat lunak yang unik dapat ditemukan dalam versi terbaru dari Rekayasa Perangkat Lunak Body of Knowledge. Ini mengidentifikasi sejumlah proses , kegiatan , dan praktek-praktek yang unik untuk pengelola , misalnya:- Transisi: urutan terkontrol dan terkoordinasi kegiatan selama sistem ditransfer progresif dari pengembang ke pengelola.- SLA dan khusus (domain - spesifik) kontrak pemeliharaan dinegosiasikan oleh pengelola.- Modifikasi Permintaan dan Laporan Masalah Help Desk : proses masalah penanganan digunakan oleh pengelola memprioritaskan , dokumen , dan rute permintaan mereka terima.- Modifikasi Permintaan kerja selama tertentu ukuran / usaha / kompleksitas mungkin ditolak oleh pengelola dan dialihkan ke pengembang.
Sumber:http://selab.netlab.uky.edu/homepage/publications/April%20Huffman%20Abran%20Dumke%20Journal%202005.pdf
Tidak ada komentar:
Posting Komentar