Bulan: Maret 2020

Training : melatih para pemangku kepentingan tentang implementasi sistem.

Consultative : Biaya dan lamanya waktu diperkirakan untuk pekerjaan pemeliharaan, personel menjalankan help desk, pelanggan dibantu untuk mempersiapkan permintaan pekerjaan pemeliharaan, dan personel membuat pengetahuan ahli tentang sumber daya yang tersedia dan sistem kepada orang lain dalam organisasi untuk meningkatkan efisiensi .

Evaluative : kegiatan umum termasuk meninjau kode program dan dokumentasi, memeriksa efek riak dari perubahan yang diusulkan, merancang dan melaksanakan tes, memeriksa dukungan pemrograman yang disediakan oleh sistem operasi, dan menemukan data yang diperlukan dan debugging.

Reformative :meningkatkan keterbacaan dokumentasi, membuat dokumentasi konsisten dengan perubahan lain dalam sistem, menyiapkan bahan pelatihan, dan menambahkan entri ke kamus data.

Updative : menggantikan dokumentasi yang sudah ketinggalan zaman dengan dokumentasi yang mutakhir, membuat semi formal, misalnya, di UML untuk mendokumentasikan kode program saat ini, dan memperbarui dokumentasi dengan rencana pengujian.

Groomative: mengganti komponen dan algoritma dengan yang lebih efisien dan sederhana, memodifikasi konvensi untuk penamaan data, mengubah otorisasi akses, menyusun kode sumber, dan melakukan backup.

Preventive :melakukan perubahan untuk meningkatkan rawatan dan membangun dasar untuk melakukan transisi di masa depan ke teknologi yang muncul.

Performance : meningkatkan waktu sistem dan mengganti komponen dan algoritma dengan yang lebih cepat. 

Adaptive : Aktivitas biasa dalam jenis ini mem-porting perangkat lunak ke platform eksekusi yang berbeda dan meningkatkan pemanfaatan komponen COTS. 

Reductive : mengurangi jumlah input data ke sistem dan mengurangi jumlah data yang dihasilkan oleh sistem. 

Corrective :  Kegiatan biasa dalam jenis ini adalah mengoreksi bug yang diidentifikasi, menambahkan strategi pemrograman defensif dan memodifikasi cara-cara pengecualian ditangani.

Enhancive : Menambah dan memodifikasi aturan bisnis untuk meningkatkan fungsionalitas sistem yang tersedia bagi pelanggan dan menambahkan aliran data baru ke dalam atau keluar dari perangkat lunak.

 

 

Perawatan korektif : Tujuan pemeliharaan korektif adalah untuk memperbaiki kegagalan: kegagalan pemrosesan dan kegagalan kinerja.

• Isolasi dan koreksi elemen yang rusak dalam perangkat lunak. 
• Produk perangkat lunak diperbaiki untuk memenuhi persyaratan. 
• Mengoreksi program yang membatalkan atau menghasilkan hasil yang salah. 
• Proses reaktif, yang berarti pemeliharaan korektif dilakukan setelah mendeteksi cacat pada sistem.

Pemeliharaan adaptif. Tujuan pemeliharaan adaptif adalah untuk memungkinkan sistem beradaptasi dengan perubahan dalam lingkungan datanya atau lingkungan pemrosesan.

• Memodifikasi perangkat lunak untuk berinteraksi dengan benar dengan lingkungan yang berubah
• Pemeliharaan adaptif meliputi perubahan sistem, penambahan, penghapusan, modifikasi, ekstensi, dan peningkatan untuk memenuhi kebutuhan lingkungan di mana sistem harus beroperasi.

Perawatan yang penyempurnaan. Tujuan dari pemeliharaan yang sempurna adalah untuk membuat berbagai perbaikan, yaitu, pengalaman pengguna, efisiensi pemrosesan, dan pemeliharaan

• Program dapat dibuat lebih mudah dibaca untuk pengalaman pengguna yang lebih baik; 
• program dapat dimodifikasi untuk membuatnya lebih cepat, sehingga meningkatkan efisiensi pemrosesan; 
• program dapat direstrukturisasi untuk meningkatkan keterbacaannya, sehingga meningkatkan kemampuan pemeliharaannya. 
• restrukturisasi kode, membuat dan memperbarui dokumentasi, dan mengatur sistem untuk meningkatkan kinerja. Kadang juga disebut “pemeliharaan demi pemeliharaan” atau “rekayasa ulang”

Pemeliharaan preventif. Tujuan pemeliharaan preventif adalah untuk mencegah terjadinya masalah dengan memodifikasi produk perangkat lunak

• Mengidentifikasi risiko di masa depan dan masalah yang tidak diketahui, dan mengambil tindakan agar masalah tersebut tidak terjadi. 
• Sebagai contoh : gaya pemrograman yang baik dapat mengurangi dampak perubahan, sehingga mengurangi jumlah kegagalan. Oleh karena itu, program dapat direstrukturisasi untuk mencapai gaya yang baik untuk mempermudah pemahaman program nantinya. 
• Pemeliharaan preventif sangat sering dilakukan pada sistem perangkat lunak yang kritis dan aman 

 

Permintaan perubahan (CR: Change Request) mengaktifkan proses organisasi untuk memodifikasi sistem perangkat lunak untuk melakukan pemeliharaan.  Proses pemeliharaan dimulai dengan melakukan analisis dampak. Analisis dampak pada dasarnya berarti mengidentifikasi komponen-komponen yang terkena dampak oleh CR . Analisis dampak memungkinkan pemahaman dan penerapan perubahan dalam sistem dan digunakan untuk memperkirakan biaya dan merencanakan jadwal.

Alasan melakukan analisa dampak:

• Untuk memperkirakan biaya mengeksekusi permintaan perubahan.  
• Untuk menentukan apakah beberapa bagian penting dari sistem akan terkena dampak karena perubahan yang diminta. 
• Untuk mencatat riwayat informasi terkait perubahan untuk evaluasi perubahan di masa mendatang. 
• Untuk memahami bagaimana item perubahan terkait dengan struktur perangkat lunak. 
• Untuk menentukan bagian-bagian dari perangkat lunak yang perlu dikenakan pengujian regresi setelah perubahan dilakukan.

Cara melihat analisa dampak:

• Richard Turver dan Malcolm Munro  mendefinisikan analisis analisis dampak penilaian terhadap perubahan kode sumber modul pada modul lain dari sistem. Hal ini menentukan ruang lingkup perubahan dan memberikan ukuran kompleksitasnya.
• Queille mendefinisikan analisis dampak sebagai tugas menilai dampak dari melakukan serangkaian perubahan pada sistem perangkat lunak.
• Bohner dan Arnold  mendefinisikan analisis dampak sebagai mengidentifikasi konsekuensi potensial dari suatu modifikasi atau menemukan entitas yang akan dimodifikasi untuk mencapai perubahan.

Implementasi permintaan perubahan berdampak pada semua jenis artefak, termasuk kode sumber, persyaratan, dokumentasi desain, dan skenario pengujian. Oleh karena itu, informasi keterlacakan analisis dampak dapat digunakan dalam melakukan analisis dampak.

Gotel dan Finkkelstein mendefinisikan keterlacakan sebagai kemampuan untuk menggambarkan dan mengikuti kehidupan artefak di kedua arah maju dan mundur. Bohner dan Arnold mendefinisikan keterlacakan sebagai kemampuan untuk melacak antara artefak perangkat lunak yang dihasilkan dan dimodifikasi selama siklus hidup produk perangkat lunak. Dengan demikian, keterlacakan membantu pengembang perangkat lunak memahami hubungan di antara semua artefak perangkat lunak dalam suatu proyek. Setelah mengidentifikasi dokumen tingkat tinggi tentang fitur yang akan dimodifikasi, dengan menggunakan konsep keterlacakan, pengelola menempatkan entitas yang perlu diubah. Contoh entitas tersebut adalah desain dan kode sumber.

Topik yang terkait dengan analisis dampak adalah analisis efek riak. Efek riak berarti bahwa modifikasi pada variabel tunggal mungkin memerlukan beberapa bagian dari sistem perangkat lunak untuk dimodifikasi. Konsep efek riak memiliki relevansi dalam evolusi perangkat lunak karena menyangkut perubahan dan efeknya. Analisis efek riak mengungkapkan apa dan di mana perubahan terjadi. Pengukuran efek riak dapat memberikan informasi berikut tentang sistem perangkat lunak yang berkembang:

(i) antara versi berturut-turut dari sistem yang sama, pengukuran efek riak akan memberi tahu kami bagaimana kompleksitas perangkat lunak telah berubah;

(ii) ketika modul baru ditambahkan ke sistem, pengukuran efek riak pada sistem akan memberi tahu kami bagaimana kompleksitas perangkat lunak telah berubah karena penambahan modul baru.