Ayuliana/ Testing dan Implementasi/Mei2009

1
SOFTWARE MAINTENANCE

Definisi Software Maintenance
Lebih dari sekedar memperbaiki kesalahan
Dideskripsikan dengan 4 macam aktivitas yang dilakukan setelah program di-released dan digunakan
Aktivitas pertama terjadi karena sangat tidak beralasan untuk mengasumsikan bahwa ujicoba software akan
menemukan seluruh kesalahan laten dalam suatu software sistem yang besar.
Selama penggunaan program tersebut, kesalahan akan terjadi dan dilaporkan kepada pihak pengembang.
Proses yang menyertakan diagnosis dan korektif dari satu atau lebih kesalahan disebut corrective
maintenance
Aktivitas kedua, yang berkontribusi terhadap definisi maintenance yang terjadi karena perubahan yang
mendadak yang ditemukan dalam setiap aspek perhitungan (computing)
Pembaharuan generasi hardware dapat dilakukan dalam kurun 24 bulan, SO baru atau new released
muncul secara regular, peralatan tambahan dan elemen sistem lainnya secara berkala di-upgrede atau
dimodifikasi. Penggunaan aplikasi software dapat mencapai 10 tahun atau lebih.
Karena itu adaptive maintenance, yaitu aktivitas yang memodifikasi software yang secara tepat berhadapan
dengan perubahan lingkungan (environment) sangat diperlukan
Aktivitas ketiga, dapat diaplikasikan pada definisi maintenance terjadi ketika paket software berhasil.
Ketika software digunakan, rekomendasi untuk kemampuan yang baru, modifikasi terhadap fungsi yang
sudah ada, dan kebutuhan umum lainnya dapat diterima dari para user.
Untuk memenuhi permintaan dalam kategori ini, perfective maintenance, dilakukan.
Aktivitas ini dilakukan untuk mayoritas dari seluruh usaha yang dilakukan pada software maintenance
Aktivitas maintenance keempat terjadi ketika software diubah untuk meningkatkan kemampuan
pemeliharaan, atau keandalan, atau untuk menyediakan basis yang lebih baik untuk peningkatan dimasa
mendatang.
Sering disebut sebagai preventive maintenance, aktivitas ini dikarakteristikan dengan teknik reverse
engineering dan ire-engineering

Karakteristik Maintenance
Untuk memahami karakteristik dari software maintenance, dapat dilihat topik dari 3 sudutpandang yang
berbeda :
o Aktivitas-aktivitas dibutuhkan untuk menyelesaikan fase maintenance dan pengaruh pendekatan
pengembangan software dalam efisiensinya dari aktivitas tersebut
o Biaya yang terkait dengan fase maintenance
o Masalah-masalah yang ditemukan secara frekuensi ketika software maintenance dilakukan

Structured vs Unstructured maintenance
o Alur kejadian yang dapat terjadi sebagai hasil dari permintaan maintenace diilustrasikan pada gambar 1.
o J ika elemen yang tersedia dari konfigurasi software adalah source code, maka aktivitas maintenance
dimulai dengan evaluasi secara teliti dapa kode, sering menyulitkan bila hanya memiliki sedikit
dokumentasi internal
o Karakteristik bagian seperti struktur program, struktur data global, interface sistem, dan batasan
desain/performa menjadi sulit untuk diketahui dengan pasti dan salah penafsiran
o Percabangan dari perubahan-perubahan yang diakibatkan dari kode yang sulit ditafsirkan
o Regression test tidak mungkin dilaksanakan karena tidak tersedianya record testing
o Maka saat ini, yang dilakukan adalah unstructured maintenance, dan membayar sejumlah harga yang
menyertakan software yang belum dikembangkan dengan metodology yang baik
o J ika terdapat konfigurasi software lengkap, tugas maintenance dimulai dengan evaluasi desain
dokumentasi.
o Struktural penting, performa, dan karakteristik interface ditentukan.
o Pengaruh dari kebutuhan modifikasi diperkirakan dan pendekatan direncanakan.
o Desain dimodifikasi dan direview, source code baru dibangun, regression test dilaksanakan dengan
menggunakan informasi yang terdapat dalam test specification, dan software di-release kembali



Ayuliana/ Testing dan Implementasi/Mei2009

2

Gambar 1. Structured VS Unstructured maintenance


o Urutan kegiatan ini mengacu kepada structured maintenance dan terjadi sebagai hasil dari metodology
pengembangan software aplikasi yang terdahulu
o Walaupun keberadaan konfigurasi software tidak memberikan jaminan maintenance yang bebas
masalah, tetapi setidaknya dapat mengurangi usaha yang sia-sia dan meningkatkan kualitas perubahan
ataupun perbaikan secara keseluruhan

Maintenance Cost
o Biaya maintenace suatu software terus meningkat. Ditahun 1970-an biaya maintenan antara 35-40%
dari budget software untuk sistem informasi organisasi
o Ditahun 1980-an angka ini melonjak hingga 60%, dan dipertengahan 1990-an hampir mendekati 80%
o Satu biaya yang tidak terlihat dalam software maintenance membangun kesempatan yang ditunda atau
hilang karena ketersediaan sumberdaya harus diteruskan kepada tugas maintenance
o Biaya tidak terlihat lainnya, diantaranya :
Ketidakpuasan customer yang sepertinya melegitimasi permintaan untuk perbaikan atau modifikasi
tidak dapat dialamatkan pada waktu tertentu
Penurunan dalam keseluruhan kualitas software sebagai hasil dari perubahan yang
memperkenalkan kesalahan laten dalam software maintenance
Kehebohan/pergolakan yang diakibatkan selama usaha pengembangan, ketika staff harus ditarik
untuk bekerja pada tugas maintenance
Ayuliana/ Testing dan Implementasi/Mei2009

3
o Biaya akhir dari software maintenance secara dramatis penurun dalam produktivitas.
o Usaha yang dikeluarkan dalam maintenance dapat dibagi menjadi beberapa aktivitas produktif (seperti
analisis dan evaluasi, modifikasi desain, coding) dan juga aktivitas wheel spinning (seperti mencoba
memahami kode, mencoba menafsirkan struktur data, karakteristik interface, batasan performa)
o Dapat dibuat model untuk usaha maintenance :
M =p +K e(c-d)
Dimana:
M =Total usaha yang dikeluarkan untuk maintenance
P =Usaha Produktvitas
K =konstanta empiris
c =Ukuran komplesitas yang dapat diatributkan pada kekurangan
dokumentasi dan desain yang baik
d =Ukuran untuk tingkatan pengenalan terhadap software

o Model diatas dapat digunakan untuk mengindikasikan bahwa usaha(biaya) dapat meningkat secara
ekponensial jika pendekatan pengembangan softwarenya buruk (penggunaan pengembangan software
yang buruk) dan tidak adanya orang atau grup yang menggunakan pendekatan tersebut tidak tersedia
untuk melakukan maintenance

Masalah-masalah
o Masalah utama yang dihubungkan dengan software maintenance dapat ditelusuri melalui defisiensi
bagaimana software direncanakan dan dikembangkan.
o Seperti istilah klasik Pay now or pay more later.
o Kurangnya pengawasan dan disiplin dalam aktivitas pengembangan software mendekati permasalah
dalam software maintenance nantinya
o Dari beberapa masalah klasik yang dapat dihubungkan dengan software mintenance diantaranya :
Sangat sulit bahkan mustahil untuk menelusuri evolusi dari software melalui beberapa versi atau
release. Perubahan tidak didokumentasikan secara tepat
Sangat sulit bahkan mustahil untuk menelusuri proses melalui software yang dibuat
Sering secara luarbiasa sulitnya untuk memahami program milik orang lain. Kesulitan bertambah
dengan semakin sedikitnya elemen dalam konfigurasi software. J ika code tidak terdokumentasi,
maka beberapa masalah pasti diharapkan
Tidak tersedianya orang lain untuk menjelaskan. Mobilitas dalam personel software cukup tinggi.
Dokumentasi tidak tersedia atau kalupun ada sangat buruk. Keberadaan software harus
terdokumentasi sejak awal, tetapi dokumentasi harus konsisten dan sesuai dengan source code,
baru dapat bernilai
Kebanyakan software tidak didesain untuk perubahan. Kecuali metode desain dapat
mengakomodasi perubahan melalui konsep seperti fungsional independen atau object classes
Maintenance bukan merupakan pekerjaan yang penting. Biasanya persepsi ini muncul dari level
frustasi yang tinggi terkait dengan pekerjaan maintenance

MAINTAINABILITY

Maintainability didefinisikan secara kualitatif merupakan kemudahan suatu software untuk di mengerti,
diperbaiki, diadaptasi dan/atau dikembangkan.

Faktor-faktor pengontrol (Controlling factors)
Maintainability dari suatu software dapat dipengaruhi oleh banyak factor. Kecerobohan/ kekurang hati-hatian
dalam desain, coding, dang testing akan memberikan dampak negative yang jelas untuk kemampuan
pemeliharaan software yang dihasilkan. Dibawah ini terdapat beberapa factor yang berhubungan dengan
lingkungan pengembangan software, diantaranya :
1. Ketersediaan staff software yang berpotensi/pilihan
2. Struktur system yang mudah dipahami
3. Kemudahan penanganan system
4. Menggunakan bahasa pemograman standar
5. Menggunakan system operasi standar
6. Struktur dokumentasi yang terstandarisasi
Ayuliana/ Testing dan Implementasi/Mei2009

4
7. Ketersediaan kasus uji
8. Tersedianya fasilitas debugging
9. Ketersediaan computer yang tepat untuk melakukan pemeliharaan

Sebagai tambahan terhadap factor-faktor diatas, harus ditambahkan ketersediaan orang atau kelompok
yang mengembangkan proyek . Faktor-faktor diatas merefleksikan karakteristik dari sumber daya hardware dan
software yang digunakan selama pengembangan. Faktor-faktor lainnya mengindikasikan kebutuhan akan
standarisasi metode, sumberdaya dan pendekatan. Faktor yang paling penting yang mempengaruhi
maintainability adalah rencana untuk maintainability. J ika software dilihat sebagai elemen sistem yang akan
diubah sewaktu-waktu, maka software yang berkemampuan untuk dipelihara akan dibuat.

Ukuran-ukuran kuantitatif (Quantitative Measures)
Maintainability software sangat sulit untuk diukur, tetapi dapat diperkirakan secara tidak langsung dengan
mempertimbangkan atribut dari aktivitas maintenance yang dapat diukur. Beberapa maintainabilityn metrics
yang berhubungan dengan usaha yang dikeluarkan selama pemeliharaan :
1. Waktu pengenalan masalah
2. Waktu tunda administratif
3. Waktu pengumpulan maintenance tool
4. Waktu analisis masalah
5. Waktu penggantian/perubahan spesifikasi
6. Waktu koreksi aktif(modifikasi)
7. Waktu uji lokal
8. Waktu uji global
9. Waktu review maintenance
10. Waktu recovery total
Setiap pengukuran diatas dapat diperoleh tanpa kesulitan dan dapat membantu manajer untuk
mengindikasikan teknik dan tool yang efisien. Sebagai tambahan pada pengukuran berorientasi waktu,
maintainability dapat diukur secara tidak langsung dengan mempertimbangkan struktur desain dan software
complexity metrics.

Reviews
Karena maintainability merupakan karakteristik mendasar dari semua software, maka harus dipastikan
faktor-faktor yang disebutkan sebelumnya dibangun/dilakukan selama fase pengembangan.
Pada setiap level dari proses review pengembangan software, maintainability harus dipertimbangkan.
Selama review kebutuhan, area untuk kebutuhan selanjutnya dan revisi potensial harus dicatat, software
portability didiskusikan, dan interface sistem yang dapat mempengaruhi software maintenance
dipertimbangkan.
Selama review desain, desain data, desain arsitektural, desain prosedural, dan desain interface dievaluasi
untuk kemudahan modifikasi dan kualitas desain keseluruhan.
Review pengkodean menekankan pada dokumentasi internal dan bentuk, merupakan 2 faktor yang
mempunyai pengaruh dalam maintainability
Terakhir, setiap langkah uji dapat menyediakan petunjuk mengenai bagian program yang memerlukan
pemeliharaan awal (preventive maintenance) sebelum software tersebut diluncurkan secara resmi
Review maintenance formal yang paling penting terjadi pada akhir ujicoba, yang biasa disebut dengan
review konfigurasi. Review ini memastikan bahwa seluruh elemen konfigurasi software telah lengkap,
dipahami, dan dilengkapi dengan pengawasan modifikasi.

MAINTENANCE TASKS
Tugas yang terhubung dengan pemeliharaan software dimulai jauh sebelum permintaan akan pemeliharaan
tersebut muncul. Pada dasarnya, organisasi pemeliharaan harus memberitahukan, melaporkan dan
mengevaluasi prosedur yang harus dijelaskan dan menstandarisasi urutan dari kejadian yang harus
didefinisikan untuk setiap permintaan pemeliharaan. Sebagai tambahan, prosedur penyimpanan catatan untuk
aktivitas maintenance harus dilakukan dan review serta kriteria evaluasi didefinisikan.


Organisasi Pemeliharaan (Maintenance Organization)
Struktur organisasi maintenace hampir sama seperti struktur organisasi pada umumnya. Seperti terlihat
pada gambar dibawah ini :
Ayuliana/ Testing dan Implementasi/Mei2009

5

Gambar 2. Organization

Maintenance request terhubung melalui maintenance controller, yaitu seseorang yang meneruskan
permintaan untuk evaluasi ke system supervisor. System supervisor adalah anggota dari staff teknikal yang
telah diberikan tanggungjawab untuk mengenali bagian-bagian kecil dari program. Ketika evaluasi dibuat,
perubahan autoritas pengawasan harus menetapkan aksi yang harus dilakukan. Controller dan change control
authority dapat dilakukan oleh satu orang atau (untuk jika sistem yang besar) sekelompok manajer dan staff
teknikal senior.

Laporan (Reporting)
Seluruh software maintenance harus direpresentasikan dalam bentuk standar. Normalnya, pengembang
software membuat maintenance request report (MRF), biasanya disebut software problem report, yang telah
dilengkapi oleh user yang menginginkan aktivitas maintenance. J ika ditemukan kesalahan, deskripsi lengkap
dari keadaan yang mengarahkan kepada kesalahan (termasuk input data, listing dan materi support lainnya)
harus disertakan. Untuk permintaan adaptive atau perfective maintenance, catatan spesifikasi perubahan harus
disertakan.
MRF merupakan dokumentasi yang dibuat, secara eksternal yang digunakan sebagai basis untuk
perencanaan tugas-tugas maintenance. Secara internal, software change reports (SCR) mengindikasikan :
1. Usaha-usaha penting yang dibutuhkan untuk memenuhi MRF
2. Sifat-sifat modifikasi yang dibutuhkan
3. Prioritas permintaan
4. data after the fact mengenai modifikasi

SCR diberikan untuk perubahan otoritas control sebelum rencana pemeliharaan selanjut







Alur kejadian (Flow of Events)
Urutan kejadian yang terjadi sebagai hasil dari permintaan maintenance dapat dilihat dari gambar
berikut :
Ayuliana/ Testing dan Implementasi/Mei2009

6


Maintenance flow of event

Kebutuhan pertama adalah untuk menentukan tipe/jenis maintenance yang harus dilakukan. Dalam banyak
kasus, user mungkin akan memperlihatkan permintaan/request sebagai indikasi dari kesalahan software
(corrective maintenance) sedangkan pengembang mungkin melihat permintaan yang sama sebagai adaptif atau
pengembangan (enhancement)
Berdasarkan gambar diatas, permintaan untuk corrective maintenance (error path) dimulai dengan
evaluasi dari kerumitan kesalahan. J ika terdapat masalah yang pelik (misalkan tidak berfungsinya system
kristis), personil ditetapkan dibawah pengarahan supervisor system, dan analisis masalah dimulai dengan
segera.
Untuk masalah yang tidak terlalu rumit, permintaan untuk corrective maintenance dievaluasi dan
dikategorikan dan kemudian dijadwalkan dalam keterhubungannya dengan tugas-tugas yang lain yang
memerlukan sumberdaya pengembangan software.
Dalam beberapa kasus, masalah mungkin bias menjadi sangat pelik, hingga pengawasan normal untuk
maintenance harus diabaikan sementara. Kode harus dimodifikasi segera, tanpa evaluasi keterhubungan untuk
Ayuliana/ Testing dan Implementasi/Mei2009

7
efek samping potensial dan pembaharuan dokumentasi yang tepat. Mode fire-fighting untuk corrective
maintenance ini disediakan hanya untuk situasi krisis dan harus dilakukan dalam jumlah persentase yang kecil
dari keseluruhan aktivitas maintenance. Harus dicatat bahwa fire fighting maintenance ini menunda pengawasan
dan evaluasi. Setelah krisis teratasi, aktivitas tersebut harus dilakukan untuk memastikan bahwa perbaikan
yang ada tidak mengarahkan kepada masalah yang lebih pelik lagi.
Permintaan untuk adaptive dan perfective maintenance mengikuti eda. Adaptasi dievaluasi dan
dikategorikan untuk ditempatkan dalam urutan aksi maintenance, begitupun terhada penambahan
(enhancement). Tetapi tidak seluruh permintaan enhancement dilaksanakan. Strategi bisinis, ketersediaan
sumberdaya, arah produk software saat ini dan mendatang, dan isu lainnya dapat menyebabkan permintaan
akan enhancement ditolak. Enhancement pun ditempatkan dalam urutan maintenance. Prioritas dari setiap
permintaan di tetapkan dan pekerjaan yang dibutuhkan dijadwalkan, termasuk usaha pengembangan lainnya
jika ada. J ika ditetapkan sebagai prioritas tertinggi, maka pekerjaan dapat dimulai segera.
Tanpa memperhatikan jenis dari maintenance, tugas-tugas teknikal yang sama dilakukan. Tugas
maintenance ini meliputi modifikasi desain software, review, keperluan modifikasi kode, ujicoba unit dan
integrasi (termasuk ujicoba regresi menggunakan kasus uji), uji validasi, dan review. Pada kenyataannya
software maintenance adalah pengembangan software yang diaplikasikan secara rekursif. Penekanannya
akan berubah sesuai dengan jenis maintenance tetapi pendekatan selanjutnya akan tetap. Kejadian akhir dari
alur maintenance adalah review yang memvalidasi ulang semua elemen dari konfigurasi software dan
memastikan bahwa Maintenance Request Form(MRF) telah dilengkapi.
Setelah tugas maintenance lengkap, sangat baik untuk mengadakan situation review. Secara umum
review ini harus dapat menjawab pertanyaan :
1. Pada situasi terakhir, aspek apa dari desain, kode atau test yang telah dilakukan secara berbeda?
2. Sumberdaya maintenance apa yang seharusnya ada, tetapi tidak?
3. Apa penghalang mayor/minor dalam usaha ini?
4. Apakan preventive maintenance diindikasikan dengan tipe dari permintaan yang dilaporkan?

Situation review mempunyai pengaruh penting terhadap penyelenggaraan usaha maintenance
berikutnya dan menyediakan feedbacj yang penting untuk manajemen efektif dari organisasi software.

Penyimpanan Record (Record keeping)
Sejarahnya penyimpanan record dalam semua fase dari proses pengembangan software tidaklah tepat.
Penyimpanan record untuk maintenance software bahkan tidak ada. Karena alasan ini maka secara frekuensi
sulit memperkirakan teknik maintenance yang efektif, tidak mampu menetapkan kualitas dari program yang
diproduksi, dan segan untuk menentukan biaya maintenance sesungguhnya.
Masalah pertama yang muncul dalam penyimpanan record maintenance adalah data apa yang layak
untuk disimpan. Swanson menyediakan beberapa daftar seperti dibawah ini :
1. Identifikasi program
2. J umlah perintah source
3. J umlah instruksi kode mesin
4. Bahasa pemrograman yang digunakan
5. Tanggal instalasi program
6. J umlah penggunaan program sejak diinstalasi
7. J umlah kesalahan pemrosesan terkait dengan no 6
8. Perubahan level dan identifikasi program
9. J umlah perintah source yang ditambahkan dalam perubahan
10. J umlah perintah source yang dihapuskan dalam perubahan
11. J umlah orang/jam yang diperlukan per perubahan
12. Tanggal perubahan program
13. Idetifikasi pengembang software
14. Identifikasi MRF
15. J enis maintenance
16. Tanggal mulai dan akhir maintenance
17. J umlah komulatif orang/jam yang dibutuhkan dalan satu maintenance
18. Keuntungan bersih terkait dengan maintenance yang dilakukan

Data diatas dikumpulkan untuk setiap usaha maintenance. Pekerjaan lainnya dalam pengukuran
maintenance difokuskan pada karakteristik software yang lebih berpengaruh terhadap frekuensi maintenance
dan model empiris untuk memperkirakan jumlah kerja maintenance berdasarkan karakteristik program yang lain.
Ayuliana/ Testing dan Implementasi/Mei2009

8

Evaluasi
Evaluasi dari aktivitas software maintenance sering dibingungkan dengan kurangnya hard data. J ika
penyimpanan record diinisiasikan, sejumlah pengukuran dari performa maintenance dapat dilakukan. Ukuran-
ukuran potensial diantaranya :
1. J umlah rata-rata kesalahan pemrosesan per pelaksanaan program
2. Total orang-jam yang dikeluarkan dalam setiap kategori maintenance
3. J umlah rata-rata perubahan program yang dilakukan per program, per bahasa, per jenis maintenance
4. J umlah rata-rata orang-jam yang dikeluarkan per perintah source yang ditambahkan atau dihapus
selama maintenance
5. Rata-rata orang-jam dikeluarkan per bahasa
6. Rata-rata waktu mengulang untuk MRF
7. Persentase untuk permintaan maintenance berdasarkan tipe

Tujuh ukuran diatas dapat menyediakan bingkai kerja kuantitatif dari pemilihan teknik pengembangan,
pemilihan bahasa, pemilihan usaha maintenance, alokasi sumberdaya, dan isu lainnya.

MAINTENANCE SIDE EFFECT

Efek samping dari maintenance
Modifikas dari suatu software dapat berakibat sangat fatal, terkadang sering terdengar ungkapan : Apa
yang saya lakukan hanya merubah satu statement tetapi sangat disayangkan setiap kali perubahan diberikan
kepada prosedur logical yang rumit, akan potensial mengakibatkan terjadinya kesalahan. Dkumentasi desain
dan ujicoba regresi yang cermat dapat membantu untuk mengurangi kesalahan, tetapi akan ditemukan efek
sampingan (side effect) dari maintenance.
Ketika digunakan dalam konteks software maintenance, maka istilah side effect dinyatakan sebagai
kesalahan atau perilaku yang tidak diharapkan yang muncul sebagai akibat dari modifikasi. Freedman dan
Weinberg mendefinisikan 3 kategori utama untuk side effect.

1. Coding Side Effects
Perubahan sederhana pada satu statement terkadang dapat memberikan hasil yang menghancurkan.
Penggantian yang tidak hati-hati/tidak terdeteksi dapat berakibat pada kegagalan software. Walaupun tidak
semua side effect memiliki konsekuensi yang dramatik , perubahan mengakibatkan kesalahan dan
kesalahan selalu mengarah kepada masalah.
Walaupun setiap perubahan pengkodean potensial mengakibatkan kesalahan, kumpulan perubahan
dibawah ini cenderung menimbulkan kesalahan, diantaranya :
1. Penghapusan / perubahan sub program
2. Penghapusan / modifikasi label statement
3. Penghapusan / modifikasi identifier
4. Perubahan-perubahan dibuat untuk meningkatkan kemampuan performa eksekusi
5. Modifikasi pembukaan/penutupan file
6. Modifikasi operator logical
7. Perubahan-perubahan desain yang di-translate kedalam perubahan kode utama
8. Perubahan-perubahan dibuat untuk uji logical suatu kondisi tertentu

Range dari coding side effect mulai dari pendeteksian kesalahan-kesalahan yang menyusahkan dan
penanganan selama ujicoba regresi terhadap masalah yang menyebabkam kesalahan software selama
operasi.

2. Data Side Effects
Selama maintenance, modifikasi sering dilakukan pada elemen individual suatu struktur data atau
struktur data itu sendiri. Ketika data diubah, desain software menjadi tidak sesuai lagi dengan data dan
kesalahan dapat terjadi. Data side effects terjadi sebagai hasil dari perubahan yang dilakukan terhadap
struktur informasi software.
Beberapa perubahan-perubahan data berikut yang secara frekuensi dapat mengakibatkan side effects,
diantaranya :
Pendefinisian ulang konstanta lokal maupun global
Pendefinisian ulang format record atau format file
Ayuliana/ Testing dan Implementasi/Mei2009

9
Penambahan atau pengurangan ukuran array atau permintaan struktur data yang lebih besar
Perubahan/modifikasi terhadap data global
Inisialisasi ulang untuk control flags dan pointer
Pengaturan ulang argument untuk I/O atau subprogram.

Data side effects dapat dibatasi dengan dokumentasi desain yang mendeskripsikan struktur data dan
menyediakan referensi silang yang berhubungan dengan elemen data, record, file dan struktur lainnya
beserta modul software

3. Documentation Side Effects
Maintenance harus focus kepada keseluruhan konfigurasi software dan bukan pada perubahan
/modifikasi source code saja. Documentation side effects terjadi ketika perubahan terhadap source code
tidak direfleksikan kedalam dokumentasi desain atau manual user.
Kapanpun perubahan terhadap alur data, arsitektur desain, prosedur modul dan perubahan tertentu
lainnya dilakukan, maka dukungan dokumentasi teknikal harus diperbaharui. Dokumentasi desain yang tidak
merefleksikan kondisi terakhir dari suatu software secara akurat, lebih buruk daripada tidak ada
dokumentasi sama sekali. Side effects muncul dalam urutan-urutan kerja maintenance ketika pembacaan
dokumen teknikal mengarah kepada penafsiran yang salah mengenai karakteristik software.
Untuk user, software dapat dikatakan baik jika dokumentasi (baik tertulis maupun interaktif)
mendeskripsikan kegunaannya. J ika modifikasi terhadap executable software tidak direfleksikan dalam
dokumentasi user, maka sides effects pasti akan terjadi. Sebagai contoh, perubahan terhadap perintah atau
format input interaktif, jika tidak didokumentasikan secara benar dapat mengakibatkan kesalahan yang
signifikan. Pesan kesalahan baru yang tidak terdokumentasikan dapat menyebabkan kebingungan. Tabel
konten yang kadaluarsa dapat menyebabkan user frustasi dan tidak puas.
Documentation side effects dapat dikurangi secara subtansial jika seluruh konfigurasi direview sebelum
software di-release ulang. Kenyataannya, beberapa permintaan maintenance tidak memerlukan perubahan
terhadap desain software ataupun source code, tetapi mengindikasikan kurangnya kejelasan dalam
dokumentasi user.