Kebijakan Pemeliharaan

11.2.2. Kebijakan Pemeliharaan

Komponen  utama  kebijakan  pemeliharaan  yang  mempengaruhi  keberhasilan  perawatan  perangkat lunak adalah versi pengembangan kebijakan dan perubahan yang akan diterapkan
selama siklus hidup perangkat lunak.

Kebijakan pengembangan versi

             Kebijakan  ini  berkaitan  terutama  untuk  pertanyaan  tentang  bagaimana  banyak  versi  perangkat  lunak harus operasi secara bersamaan. Meskipun jelas bahwa ini bukan masalah bagi software custom-made yang melayani satu organisasi, jumlah versi menjadi masalah besar untuk paket-paket perangkat lunak Cots  yang  direncanakan  untuk  melayani  berbagai  macam  pelanggan.  Pengembangan  kebijakan  versi terakhir   dapat   mengambil   "berurut"   atau   bentuk   "pohon".   Ketika   mengadopsi   kebijakan   versi berurutan, hanya satu versi yang tersedia untuk seluruh pelanggan. Versi ini mencakup profesi aplikasi yang menunjukkan redundansi yang tinggi, atribut yang memungkinkan perangkat lunak untuk melayani kebutuhan  semua  pelanggan.  Perangkat  lunak  ini  harus  direvisi  secara  berkala  tapi  sekali  versi  baru selesai, itu menggantikan versi yang saat ini digunakan oleh seluruh pengguna.

Ketika  mengadopsi  kebijakan  versi  pohon,  tim  perawatan  perangkat  lunak  mendukung  upaya pemasaran   dengan   mengembangkan   versi,   khusus   ditargetkan   untuk   kelompok   pelanggan   atau pelanggan utama setelah diminta. Sebuah versi baru dilantik dengan menambahkan aplikasi khusus atau menghilangkan   aplikasi,   tergantung   pada   apa   yang   relevan   dengan   kebutuhan   pelanggan.   Versi bervariasi dalam kompleksitas dan tingkat aplikasi - aplikasi industri berorientasi target dan sebagainya.

Jika  kebijakan  ini  diterapkan,  paket  perangkat  lunak  dapat  berkembang  menjadi  sebuah  paket  multi- versi setelah beberapa tahun kerja, berarti ia akan menyerupai pohon, dengan beberapa cabang utama

dan  cabang  sekunder  banyak,  masing-masing  cabang  mewakili  sebuah  versi  dengan  revisi  khusus. Berbeda dengan versi software sekuensial pemeliharaan, dan pengelolaan perangkat lunak versi pohon jauh lebih sulit dan memakan waktu. Mengingat kekurangan-kekurangan ini, perangkat lunak organisasi- organisasi  pembangunan  mencoba  menerapkan  kebijakan  pohon  versi  terbatas,  yang  memungkinkan

hanya sejumlah kecil dari versi perangkat lunak untuk dikembangkan.

Pengalaman  harian  tim  pemeliharaan  karena  itu  termasuk  mengatasi  kesulitan  yang  diciptakan  oleh struktur versi dari paket yang berkaitan dengan perangkat lunak itu sendiri:

ž   koreksi  kesalahan  yang  disebabkan  oleh  identifikasi  tidak  memadai  struktur  modul  dari  versi saat ini digunakan oleh pelanggan tertentu.

ž   koreksi  kesalahan  yang  disebabkan  oleh  salah  penggantian  modul  yang  rusak  dengan  modul versi lain yang kemudian terbukti tidak memadai untuk integrasi ke versi paket pelanggan.

ž   Upaya diinvestasikan untuk meyakinkan pelanggan untuk meng-update paket software mereka dengan menambahkan modul-modul yang baru dikembangkan atau mengganti modul versi saat

ini  dengan  versi  yang  baru.  Setelah  upaya  berhasil  membujuk  pelanggan  untuk  memperbarui paket   perangkat   lunak   mereka,   masalah   dan   kegagalan   terjadi   ketika   mencoba   untuk mengintegrasikan modul yang baru dikembangkan atau untuk mengganti  saat ini dengan versi lanjutan dari modul.

Kebijakan Perubahan (change Policy)

Kebijakan perubahan mengacu  pada  metode  pemeriksaan  setiap  permintaan  perubahan  dan  kriteria  yang digunakan untuk persetujuan. Jelas bahwa kebijakan permisif, baik dilaksanakan oleh CCB (the Change Control Board  ) atau badan lain yang berwenang untuk menyetujui perubahan, memberikan kontribusi untuk   peningkatan   sering   dibenarkan   dalam   perubahan   beban   tugas.   Kebijakan   seimbang,   yang memerlukan  pemeriksaan  menyeluruh  terhadap  permintaan  perubahan,  adalah  lebih  disukai  karena memungkinkan  staf  untuk  fokus  pada  perubahan  yang  paling  penting  dan  menguntungkan,  serta mereka bahwa mereka akan mampu melakukan dalam waktu yang wajar dan sesuai dengan standar   kualitas yang diperlukan.   Kebijakan   ini   akan   berujung   pada   persetujuan   dan   hanya   sebagian   kecil   dari permintaan perubahan.

11.3.   Komponen Kualitas Software Pre-Pemeliharaan

Seperti komponen SQA pra-proyek, kegiatan pra-perawatan SQA akan selesai sebelum memulai layanan perawatan yang diperlukan adalah sangat penting. Ini memerlukan:

ž   Ulasan (review) kontrak pemeliharaan

ž   Kontruksi rencana pemeliharaan.

11.3.1. Review Kontrak Pemeliharaan

Ketika mempertimbangkan kontrak pemeliharaan, perspektif yang luas harus diutamakan. Yang paling penting, kontrak pemeliharaan menghasilkan keputusan yang diperlukan tentang kategori jasa yang akan dikontrak. Keputusan ini tergantung pada jenis pelanggan yang dilayani: pelanggan khusus, pelanggan yang membeli paket perangkat lunak COTS, dan pelanggan internal

Jadi, sebelum memulai untuk menyediakan layanan pemeliharaan perangkat lunak untuk salah satu pelanggan, kontrak pemeliharaan yang memadai harus diselesaikan yang menetapkan bawah seluruh cakupan kewajiban pemeliharaan sesuai dengan kondisi yang relevan.

Tujuan kontrak pemeliharaan software :

ž   Persyaratan Klarifikasi Pelanggan

                Isu-isu berikut perlu mendapatkan perhatian khusus :

a.       Jenis layanan pemeliharaan korektif yang diperlukan  : daftar layanan remote dan layanan ditempat yang akan diberikan, jam pelayanan, waktu respon, dll.

b.      Ukuran populasi pengguna dan jenis aplikasi yang akan digunakan

c.       Lokasi dari pengguna, terutama lokasi jarak jauh dan jenis aplikasi yang terinstal di masing-masing

d.      Pemeliharaan adaptive dan perbaikan fungsi yang harus disediakan dan prosedur pengajuan permintaan pelayanan serta mengusulkan dan menyetujui kinerja layanan ini.

ž   Pendekatan Alternatif untuk penyediaan pemeliharaan

Pilihan berikut pantas mendapat pertimbangan khusus :

a.       Subkontrak untuk lokasi atau jenis layanan

b.      Kinerja beberapa layanan yang dilakukan oleh pelanggan sendiri dengan dukungan dari tim pemeliharaan supplier

ž   Review Estimasi Sumber Daya pemelliharaan yang dibutuhkan.

Pertama, perkiraan ini harus diperiksa berdasarkan layanan pemeliharaan yang diperlukan, diklarifikasi oleh tim usulan. Kemudian kapasitas perusahaan harus dianalisis untuk memenuhi komitmennya terhadap kompetensi professional serta ketersediaan tim pemeliharaan.

ž   Review Jasa Perbaikan dan pemeliharaan yang akan diberikan oleh sub-contractor dan pelanggan

Review ini mengacu pada definisi layanan yang diberikan oleh setiap peserta, pembayaran kepada subkontraktor, jaminan kualitas dan tindak lanjut prosedur yang harus diterapkan.

ž   Estimasi Biaya Pemeliharaan

11.3.2. Perencanaan Pemeliharaan

Pemeliharaan rencana harus disiapkan untuk semua pelanggan, eksternal dan internal. Rencana ini harus menyediakan kerangka di mana ketentuan pemeliharaan diatur. Oleh karena itu, seperti yang diharapkan, rencana pemeliharaan dan pembangunan (lihat Bab 6) didasarkan pada konsep serupa. Rencana tersebut meliputi:

Rencana pemeliharaan harus disiapkan untuk semua pelanggan , Rencana tersebut meliputi :

•     Daftar layanan pemeliharaan yang dikontrak

1.       Para pelanggan internal dan eksternal, jumlah pengguna, lokasi dari masing –masing pelanggan.

2.       Karakteristik layanan pemeliharaan korektif (terpencil dan di situs).

3.       Kewajiban untuk penyediaan layanan adaptif dan pemeliharaan peningkatkatan fungsional untuk setiap pelanggan

•     Penjelasan dari organisasi tim pemeliharaan

       Rencana Organisasi Tim pemeliharaan berfokus pada kebutuhan tenaga kerja, yang harus dipertimbangkan dengan cermat sesuai dengan kriteria ini:

1.       Jumlah anggota tim yang dibutuhkan. Jika layanan yang harus disediakan dari beberapa fasilitas, maka diperlukan tim untuk setiap fasilitas.

2.       Kualifikasi yang diperlukan untuk anggota tim sesuai dengan tugas-tugas pemeliharaan, termasuk pemahaman terhadap paket perangkat lunak yang akan dimaintenance.

3.       Struktur organisasi tim pemeliharaan, termasuk nama-nama pemimpin tim.

4.       Definisi tugas (tanggung jawab untuk pelanggan, jenis aplikasi, dll) untuk setiap tim.

5.       Kebutuhan akan pelatihan.

•     Daftar Fasilitas Perawatan

             Pemeliharaan Fasilitas adalah infrastruktur yang memungkinkan untuk memberikan layanan yang meliputi:

1.       Pusat Dukungan pemeliharaan (maintenance support center)  dengan hardware dan peralatan komunikasi yang sudah terinstal untuk memberikan dukungan terhadap user dan layanan koreksi terhadap perangkat lunak.

2.       Sebuah pusat dokumentasi yang berisi satu set lengkap dokumen (dalam format cetak atau elektronik):

-  Dokumentasi perangkat lunak, termasuk dokumentasi pengembangan

-  Kontrak layanan

-  Konfigurasi perangkat lunak untuk setiap pelanggan dan versi dari paket perangkat lunak yang diinstal di setiap tempat, disediakan oleh manajemen konfigurasi

-  Catatan-catatan sejarah perawatan untuk setiap pengguna dan pelanggan

•     Daftar resiko layanan pemeliharaan yang telah diidentifikasi

       Layanan risiko Pemeliharaan berkaitan dengan situasi di mana kegagalan untuk memberikan perawatan yang memadai dapat diantisipasi. Resiko-resiko ini termasuk:

1.       kekurangan Staf, apakah layanan pemeliharaan pada seluruh organisasi, di sebuah pusat dukungan perawatan tertentu atau pada suatu aplikasi tertentu.

2.       Kualifikasi atau tingkat pemahaman yang tidak memadai dengan sebagian dari paket perangkat lunak untuk melakukan dukungan layanan kepadan  pengguna dan / atau tugas pemeliharaan korektif.

3.       anggota tim kurang memenuhi syarat untuk melakukan perbaikan fungsional serta tugas-tugas adaptif.

•     Daftar prosedur pemeliharaan dan kegiatan kontrol software yang diperlukan

       Sebagian besar prosedur yang diperlukan mengacu pada proses yang dilaksanakan oleh tim pemeliharaan korektif dan oleh pusat dukungan pengguna. Prosedur ini biasanya berhubungan dengan:

1.       Penanganan aplikasi pelanggan

2.       Penanganan laporan kegagalan perangkat lunak

3.       pelaporan periodik dan tindak lanjut dari layanan dukungan untuk pengguna

4.       pelaporan periodik dan tindak lanjut layanan pemeliharaan korektif

5.       Pelatihan dan sertifikasi anggota tim pemeliharaan

•     Anggaran pemeliharaan perangkat lunak

Perkiraan anggaran yang digunakan dalam pemeliharaan korektif didasarkan pada rencana tenaga kerja suatu organisasi, fasilitas yang dibutuhkan dan investasi yang dibutuhkan untuk membangun fasilitas ini, kebutuhan tim pelatihan dan tugas-tugas lainnya. Hal-hal tersebut dapat disiapkan jika tenaga kerja, fasilitas dan prosedur telah ditetapkan. Perkiraan untuk pemeliharaan adaptif dan tugas-tugas perbaikan fungsi disiapkan disesuaikan dengan beban kerja yang disebabkan oleh perubahan dan perbaikan yang dilakukan

11.4.   Tools Jaminan Kualitas Software Pemeliharaan

Berbagai alat besar jaminan kualitas perangkat lunak yang digunakan selama masa theoperational dari siklus   hidup   perangkat   lunak.   Sifat   khusus   dari   setiap   komponen   perawatan   perangkat   lunak   - adaptivemaintenance perbaikan, pemeliharaan dan perbaikan pemeliharaan fungsi - menuntut berbeda set   alat   SQA   digunakan   untuk   masing-masing.   Selanjutnya,   operationalperiod   software   biasanya membuat penggunaan intensif alat SQA infrastruktur dan alat kontrol manajerial lebih mungkin.

Beberapa  indikasi  tingkat  sumber  daya  yang  diinvestasikan  dalam  SQA  selama  pemeliharaan telah  disiapkan  oleh  Perry  (1995).  Dalam  survei  yang  ia  dilakukan  inNovember  1994,  para  peserta melaporkan   bahwa   berdasarkan   pengalaman   mereka,   31%   dari   jadwal   pemeliharaan   mereka didedikasikan untuk jaminan kualitas (review dan tugas pengujian

11.4.1. Tool SQA untuk pemeliharaan perbaikan

Kegiatan pemeliharaan korektif memerlukan terutama (a) layanan dukungan pengguna dan) perangkat lunak koreksi b ((perbaikan bug).  Pengguna layanan dukungan menangani kasus-kasus kode perangkat lunak  dan  dokumentasi  kegagalan,  atau  samar  dokumentasi  lengkap,  mereka  juga  dapat  melibatkan instruksi  dari  pengguna  yang  memiliki  pengetahuan  cukup  tentang  perangkat  lunak  atau  gagal  untuk menggunakan  dokumentasi  yang  tersedia.   layanan  koreksi  Software  -  perbaikan  bug  dan  koreksi dokumentasi  -  yang  disebut  dalam  kasus  kegagalan  perangkat  lunak,  dan  biasanya  diberikan  selama periode awal operasi (meskipun upaya diinvestasikan dalam pengujian) dan terus diperlukan, meskipun dalam  frekuensi  yang  lebih  rendah.  Sebagai  dua  jenis  layanan  secara  inheren  berbeda,  khas  set  alat jaminan  mutu  digunakan  terlepas  dari  bersama  berfokus  pada  kualitas  layanan.  Meskipun  demikian, dalam banyak kasus tim yang sama melakukan kedua jenis pemeliharaan korektif.

Selain  pengendalian  manajemen  SQA  dan  alat-alat  infrastruktur  (dibahas  kemudian  dalam bagian  ini),  perbaikan  bug  tugas  yang  paling  membutuhkan  penggunaan  mini  siklus  hidup  alat  SQA, terutama mini-pengujian.  Mini-prosedur pengujian yang diperlukan untuk menangani patch perbaikan (skala kecil) tugas, ditandai oleh sejumlah kecil ofcoding perubahan line bersama dengan tekanan kuat

untuk  menyelesaikan  koreksi  dengan  cepat.  Implikasi  perbaikan  tertunda  adalah  sedemikian  bahwa

mini-singkat - bentuk pengujian sering digunakan. Namun, penggunaan alat-alat mini pengujian ini harus dipertahankan untuk menghindari situasi pengujian tidak ada kompromi. Untuk memastikan " mini-testing" kualitas, pedoman ini harus dipatuhi:

·         Pengujian   harus   dilakukan   oleh   tester   berkualitas,   bukan   oleh   programmer   yang melakukan perbaikan.

·         Sebuah prosedur dokumen pengujian (dalam banyak kasus 2-3 halaman panjang) harus disiapkan.  Termasuk  dalam  dokumen adalah deskripsi efek  diantisipasi dari perbaikan, lingkup  koreksi  dan  daftar  kasus  uji  yang  akan  diaktifkan.  Prosedur  pengujian  A-ulang dokumen,  mirip  dengan  dokumen  prosedur  pengujian,  harus  juga  disiapkan  untuk menangani pengujian perbaikan kesalahan terdeteksi dalam tes sebelumnya.

·         Sebuah laporan  uji mendokumentasikan sepenuhnya  kesalahan terdeteksi pada  setiap tahap pengujian dan pengujian ulang harus diselesaikan.

·         Kepala  tim  pengujian adalah  meninjau dokumentasi pengujian untuk  cakupan  koreksi, kecukupan  kasus   uji   dan   testingresults.   Tanggung   jawab   untuk   persetujuan   dari perangkat   lunak   diperbaiki   untuk   operasional   (kadang-kadang   disebut   "produksi") menggunakan terletak tim kepala.

·         Untuk  perbaikan  dianggap  "sederhana  dan  sepele",  terutama  bagi  mereka  tampil  di situs pelanggan, mini-pengujian dapat dihindari.

Subkontrak  (outsourcing)  jasa  pemeliharaan,  terutama  dukungan  layanan  pengguna,  telah  menjadi sangat umum setiap kali terlalu merepotkan atau tidak ekonomis untuk kontraktor pemeliharaan untuk langsung memberikan  layanan  ini.  Alat utama  untuk  menjamin  kualitas's  pemeliharaan  subkontraktor dan   membuka   jalan   bagi   hubungan   halus   adalah   kontrak   kontraktor-subkontraktor.   

Alat   SQA terintegrasi ke dalam kontrak, fokus pada :

ž   Prosedur untuk menangani berbagai spesifikasi panggilan pemeliharaan.

ž   Penuh dokumentasi prosedur pelayanan.

ž   Ketersediaan mendokumentasikan catatan sertifikasi profesional's pemeliharaan subkontraktor anggota tim, untuk meninjau kontraktor.

ž   Kuasa  untuk  kontraktor  untuk  melaksanakan  penelaahan  secara  periodik  terhadap  layanan pemeliharaan utama serta survei kepuasan pelanggan.

ž   Kualitas  yang  terkait  dengan  kondisi  yang  mengharuskan  pengenaan  denda  dan  pemutusan

kontrak subkontrak dalam kasus yang ekstrim.

11.4.2. Tool SQA untuk pemeliharaan fungsi perbaikan

Karena  kesamaan  tugas  pemeliharaan  fungsi perbaikan  untuk  proyek  tugas  pengembangan perangkat lunak, hidup alat siklus proyek (review dan pengujian) secara rutin digunakan untuk pemeliharaan fungsi perbaikan.  Alat-alat  yang  sama  juga  secara  rutin  diterapkan  untuk  skala  besar  tugas-tugas pemeliharaan adaptif, dimana, sekali lagi, karakteristik tugas mirip tugas perbaikan fungsi. Untuk diskusi umum rinci tentang review dan pengujian, lihat Bab 8, 9 dan 10. Tambahan SQA alat diimplementasikan untuk perbaikan pemeliharaan fungsi adalah sistem kontrol manajemen sarana dan prasarana, dibahas kemudian dalam bagian ini.

11.4.3. Komponen infrastruktur SQA untuk pemeliharaan software

Alat infrastruktur jaminan kualitas software, dibahas dalam Bagian IV dari buku ini (Bab 14-19), adalah komponen   penting   dalam   perawatan   perangkat   lunak.   Sebagian   besar   dari   array   dari   SQA   alat infrastruktur yang bersifat umum dan diimplementasikan di seluruh siklus hidup dari sistem perangkat lunak.  Selain  itu, kesamaan  peningkatan  fungsi  perangkat  lunak dan  pengembangan  proses perangkat lunak  memungkinkan  kedua  proses  untuk  berbagi  SQA  sama  alat-alat  infrastruktur  dengan  sedikit perubahan.   prasarana  alat  khusus  yang  diperlukan  untuk  kegiatan  pemeliharaan  korektif,  karena karakteristik khusus dari kegiatan ini. kegiatan pemeliharaan adaptif dilayani oleh SQA alat infrastruktur, sesuai dengan karakteristik mereka.  Sering digunakan alat SQA yang paling yang alat fungsi perbaikan, diikuti oleh alat SQA pemeliharaan korektif.

Sebenarnya,   kontribusi     alat   infrastruktur   SQA untuk   pemeliharaan   tidak   dimulai   dengan permulaan   proses   pemeliharaan.   Jelas,   aplikasi   yang   memadai   alat   infrastruktur   SQA   oleh   tim pengembangan  perangkat  lunak  yang  memberi  kontribusi  besar  terhadap  efisiensi  dan  efektivitas kegiatan tim pemeliharaan. Dengan kata lain, alat ini memberikan kontribusi terhadap kualitas jaminan pemeliharaan dalam dua cara: pertama, dengan mendukung tim pengembangan perangkat lunak ketika memproduksi   perangkat  lunak   berkualitas   tinggi,  dan  kedua,  dengan  mendukung   tim   perawatan bertanggung jawab atas pemeliharaan produk perangkat lunak yang sama.

   Tools khusus infrastruktur SQA yang diperlukan untuk proses perawatan perangkat lunak,  terutama perawatan korektif, mempunyai karakteristik khusus. Infrastruktur khusus alat SQA adalah:

ž   Pemeliharaan prosedur dan instruksi kerja

ž   Mendukung kualitas suatu perangkat / device

ž   Pelatihan dan sertifikasi team maintenance

ž   Pencegahan dan tindakan yang hati-hati

ž   Manajemen konfigurasi

ž   Dokumentasi dan mengontrol record kualitas

Prosedur Pemeliharaan dan instruksi kerja

Kebanyakan prosedur pemeliharaan yang paling khusus dan instruksi kerja diterapkan untuk pemeliharaan korektif dan kegiatan dukungan pengguna, misalnya:

ž   Remote penanganan permintaan untuk layanan dalam kasus-kasus kegagalan perangkat lunak

ž   Di tempat penanganan permintaan pelanggan untuk layanan dalam kasus-kasus kegagalan perangkat lunak

ž   Pengguna dukungan layanan

ž   Jaminan kualitas kontrol koreksi perangkat lunak dan mendukung aktivitas pengguna

ž   Survei kepuasan pelanggan

ž   Sertifikasi pemeliharaan korektif dan tim dukungan anggota pengguna.

 Pendukung kualitas perangkat

Departemen   pemeliharaan   diharapkan   dapat   mengembangkan   perangkat   khusus   untuk mendukung koreksi perangkat lunak dan mendukung aktivitas pengguna: template, daftar dan sejenisnya. perangkat tersebut dapat meliputi:

ž  Daftar  lokasi  penyebab  kegagalan  -  untuk  diterapkan  oleh  teknisi pemeliharaan.

ž  Template    untuk    melaporkan    bagaimana    kegagalan   perangkat    lunak    tersebut

diselesaikan, termasuk temuan dari proses koreksi.

ž  Daftar-pembanding untuk menyusun dokumen prosedur pengujian mini.

Pelatihan dan sertifikasi tim pemeliharaan

Pelatihan   tim   pemeliharaan   yang   berhubungan   dengan   peningkatan   tugas-tugas   fungsional   tidak berbeda  secara  substansial  dari  pelatihan  dari  tim  pengembangan  perangkat  lunak  lain.   Namun, pelatihan khusus dan sertifikasi sangat penting untuk tim pemeliharaan korektif.

Pelatihan  profesional  pemeliharaan  korektif  dimotivasi  oleh  kebutuhan  untuk  menyediakan layanan yang ditentukan dalam kontrak pemeliharaan (atau perjanjian, dalam kasus pelanggan internal) secara   berkesinambungan.   Dengan   demikian,   rencana   pelatihan   harus   memberikan   solusi   untuk kebutuhan staf selama periode beban puncak dan organisasi kebutuhan untuk mengganti, dalam waktu singkat,  pensiun,  mengundurkan  diri  atau  habis  personil.  Dalam  banyak  kasus,  pelatihan  umum  dari cadangan    "pemeliharaan    personil"    tidak    cukup,    dan    pelatihan    dalam    sistem    tertentu    harus ditambahkan. Dengan kata lain, program latihan keras yang diperlukan untuk memungkinkan organisasi untuk mengatasi dengan tingkat pelayanan tertentu dikontrak untuk periode beban puncak dan dalam situasi pergantian personil perawatan, karena alasan apapun.