Pemeliharaan sistem perangkat lunak sulit karena mereka sudah operasional.

Oleh
karena itu, diperlukan untuk menjaga keseimbangan yang tepat antara kebutuhan
untuk perubahan dan menjaga sistem diakses oleh pengguna. Banyak masalah
teknis dan manajerial hasil ketika mengubah perangkat lunak dengan cepat dan
murah
Dalam menjalankan Software maintenance perlu berbagai pertimbangan dan disini
dibagi menjadi 3 hal:
1. Kebutuhan dari Pengguna
2. Biaya pemeliharaan
3. Dan masalah teknis
Software pemeliharaan dapat dilihat dalam dua cara yang berbeda: (a)
mencerminkan Tampilan eksternal perangkat lunak, (b) mencerminkan pandangan
internal perangkat lunak. itu Alasan untuk cara pertama adalah bahwa
pemeliharaan tergantung pada produk itu sendiri, juga seperti pada individu yang
terlibat dalam pemeliharaan, diusulkan penggunaan perangkat lunak, dan
mendukung dokumentasi dan alat. 22 Singkatnya, tidak mungkin untuk mengukur
rawatan tanpa pemantauan perilaku perangkat lunak dalam lingkungan tertentu.
Pengukuran rawatan sebelum benar-benar memberikan software dianggap penting
karena berbagai faktor, termasuk mendapatkan rasa sumber daya
EKSTERNAL
VIEW
Tampilan eksternal perangkat lunak pemeliharaan meliputi langkah-langkah seperti:
Rata-rata waktu untuk memperbaiki
Jumlah masalah yang belum terselesaikan
Jumlah total waktu yang dihabiskan untuk masalah diselesaikan
Jumlah komponen dimodifikasi untuk menerapkan perubahan
Rasio total waktu pelaksanaan perubahan jumlah perubahan
diimplementasikan
Persentase modifikasi yang diperkenalkan kesalahan baru dalam sistem perangkat
lunak
Mungkin ukuran rawatan paling efektif adalah rata-rata waktu untuk memperbaiki.
untuk yang
perhitungan, catatan hati-hati informasi seperti yang tercantum di bawah ini
diperlukan.
22
Waktu Masalah pelaporan
Waktu yang dibutuhkan untuk melakukan analisis masalah
Total waktu yang hilang karena keterlambatan administrasi
Jumlah total waktu yang dibutuhkan untuk menentukan modifikasi yang dibuat
Jumlah total waktu yang dibutuhkan untuk membuat perubahan
Jumlah total waktu yang dibutuhkan untuk mendokumentasikan perubahan
Jumlah total waktu yang dibutuhkan untuk menguji perubahan
INTERNAL VIEW Ada berbagai langkah untuk atribut internal perangkat lunak yang
berkaitan dengan pemeliharaan diusulkan oleh banyak peneliti. Sebagai contoh,
tindakan kompleksitas sering berkorelasi dengan upaya pemeliharaan, yaitu,

semakin kompleks kode, semakin besar usaha yang diperlukan untuk pemeliharaan.
Meskipun korelasi dan pengukuran tidak sama, ada hubungan antara produk buruk
terstruktur dan tidak cukup didokumentasikan dan rawatan mereka. Beberapa
langkah-langkah yang disajikan di bawah ini.
Jumlah cyclomatic Jumlah ini pertama kali didefinisikan oleh T. McCabe pada tahun
1976, dan merupakan salah satu yang paling sering Langkah-langkah yang
digunakan selama perawatan. 26 Jumlah cyclomatic adalah metrik yang dibutuhkan
mempertimbangkan kompleksitas struktural kode sumber dengan mengukur jumlah
dari jalur independen linear dalam kode. Hal ini didasarkan pada konsep grafik-teori,
dan dihitung dengan mengubah kode ke grafik kontrol aliran setara dan kemudian
menerapkan sifat grafik. Dalam pekerjaan pemeliharaan, jumlah independen jalur
menunjukkan sejauh mana diperlukan untuk memahami dan melacak kapan
memeriksa atau mengubah komponen. Per Lehman hukum kedua evolusi perangkat
lunak, jumlah cyclomatic dan langkah-langkah kompleksitas lainnya akan meningkat
sebagai perangkat lunak sistem berkembang. Nomor kompleksitas McCabe
dinyatakan oleh: 26-28 (11.1) dimana CN M = Nomor kompleksitas McCabe, E =
jumlah tepi dalam program perangkat lunak yang diteliti, n = jumlah node atau
simpul, y = jumlah komponen yang terhubung atau tugas yang terpisah.

kabut Indeks
Keterbacaan mempengaruhi rawatan, khususnya untuk produk tekstual. Indeks Fog
adalah ukuran pembacaan berguna dan didefinisikan oleh:
22,29-30

Manajemen konfigurasi dipraktekkan dengan membentuk kontrol konfigurasi

papan karena banyak perubahan-pemeliharaan terkait diminta oleh pengguna atau
pelanggan
untuk memperbaiki kegagalan atau membuat tambahan. Dewan mengawasi proses
perubahan,
dan keanggotaannya mencakup pihak yang berkepentingan: pelanggan, pengguna,
dan pengembang.
Setiap masalah yang disorot ditangani dengan cara berikut:
22
1. Seorang pengguna, pengembang, atau pelanggan yang menemukan masalah
menggunakan formal
mengubah bentuk kontrol untuk merekam semua gejala yang berhubungan.
Demikian pula, dalam
kasus tambahan, semua informasi yang relevan dicatat.
2. Dewan kontrol konfigurasi secara resmi diberitahu tentang usulan
ubah.
3. Dewan bertemu dan membahas perubahan yang diajukan.
4. Setelah membuat keputusan tentang perubahan yang diminta, memprioritaskan
papan
perubahan dan memberikan individu yang tepat untuk membuat perubahan.
5. Individu yang ditunjuk (s) mengidentifikasi sumber masalah dan highlights
perubahan yang diperlukan. Bekerja dengan salinan tes, yang ditugaskan
tes individu dan mengimplementasikan perubahan.
6. individu yang ditunjuk (s) bekerja dengan pustakawan program perangkat lunak
untuk
mengontrol dan melacak perubahan atau modifikasi instalasi di operasional
sistem dan memperbarui terkait dokumentasi.
7. Sebuah laporan perubahan menggambarkan perubahan yang dilakukan diajukan
oleh ditunjuk
individual.
Langkah 6 di atas adalah langkah yang paling penting karena setiap saat
konfigurasi
Tim manajemen harus menyadari status setiap komponen / dokumen dalam
sistem. Hal ini memerlukan komunikasi yang efektif antara individu-individu yang
terlibat. Akibatnya,
perlu untuk memiliki jawaban atas pertanyaan yang tercantum below.33
Apa yang berubah?
Kapan perubahan terjadi?
Siapa yang bertanggung jawab atas perubahan yang sedang dipertimbangkan?
Siapa yang berwenang perubahan?
Siapa yang dibuat sadar perubahan?
Siapa yang benar-benar membuat perubahan?
Apakah prioritas perubahan?
Siapa yang bisa menghentikan permintaan perubahan?
Apakah perubahan dibuat efektif dan benar?
Pertanyaan-pertanyaan di atas mempertimbangkan penamaan, sinkronisasi,
delegasi,

otorisasi, routing, identifikasi, penilaian, pembatalan, dan otentikasi,

masing-masing.
ANALISIS DAMPAK
Pemeliharaan perangkat lunak tergantung pada dan dimulai dengan pelanggan atau
pengguna persyaratan. A
persyaratan menerjemahkan ke dalam perubahan yang tampaknya kecil sering
lebih luas;
akibatnya, lebih mahal untuk diterapkan daripada yang diantisipasi. Dalam keadaan
seperti itu
studi tentang dampak perubahan bisa memberikan informasi yang berguna,
terutama
dimana perubahan itu kompleks dan canggih.
Analisis dampak dapat didefinisikan sebagai penentuan risiko yang terkait dengan
diusulkan perubahan, termasuk estimasi efek pada faktor-faktor seperti usaha,
sumber daya, dan jadwal. Beberapa cara untuk mengukur dampak perubahan
diberikan
MAINTENANCE PENGURANGAN
Pengurangan jumlah pemeliharaan membantu meningkatkan produktivitas
pemeliharaan.
Seorang staf pemeliharaan dipersenjatai dengan pengetahuan terbaru,
keterampilan, dan teknik dapat
menuai produktivitas dan kualitas perbaikan yang signifikan.
Beberapa metode untuk mengurangi perawatan perangkat lunak adalah sebagai
berikut: 4,13,20,35-41
Penggunaan bahasa portabel, sistem operasi, dan alat-alat.
Gunakan pendekatan pemeliharaan preventif, seperti menggunakan batas tabel
yang cukup besar dari kemungkinan diperlukan.
Sorot tambahan mungkin dan desain perangkat lunak sehingga dapat
mudah menggabungkan perangkat tambahan tersebut.
Pertimbangkan faktor manusia di berbagai bidang seperti tata letak layar selama
perangkat lunak
desain. Ini adalah salah satu sumber perubahan atau modifikasi sering.
Memperkenalkan perawatan terstruktur yang menggunakan pendekatan untuk
mendokumentasikan
sistem yang ada saat ini dan termasuk pedoman untuk program membaca, dll