Beberapa
Definisi
Adaptif
perubahan adalah sebuah perubahan yang dibuat agar menjadi cocok dengan kondisi
yang berbeda. Perubahan
tindakan adalah proses hasil yang dibuat berbeda dalam kurun waktu tertentu.
Perbaikan
perubahan adalah sebuah perubahan yang dibuat dalam rangka menghapus beberapa
kesalahan.
Jenis
system E adalah system criteria penerimaan dimana para stakeholder puas dengan penampilan
kinerja sistem dalam situasi sesungguhnya.
Dukungan
yang ada adalah layanan kepada konsumen untuk membantu penggunaan produk secara
berkesinambungan dari suatu produk yang ditawarkan.
Perubahan
perfektif adalah perubahan yang dilakukan agar lebih meningkat.
Pasca
evolusi pengiriman adalah evolusi perangkat lunak merujuk secara eksplisit pada
periode dimana produk disampaikan kepada pelanggan.
Pencegahan
perubahan adalah perubahan yang dilakukan untuk mencegah atau membalikkan
keadaan.
Dampak
efek adalah sebuah konsekuensi dari suatu tindakan di satu tempat atau juga
terjadi ditempat lain seperti efek pada batu yang jatuh dikolam dan
mengakibatkan gelombang/ riak jauh dari titik dampak.
Jenis
sistem S adalah sistem dimana kriteria penerimaan itu benar relatif terhadap
spesifikasi yang mutlak.
Evolusi
perangkat lunak adalah suatu kecenderungan terhadap perangkat lunak untuk
berubah seiring berjalannya waktu.
Klasifikasi
Perubahan
1. Perubahan Korektif
Perubahan
korektif mengacu pada modifikasi diawali dengan kelainan dalam perangkat lunak
· Kesalahan
desain terjadi ketika perubahan dalam perangkat lunak tidak benar, tidak
lengkap, salah pada saat diperintahkan atau permintaan perubahaan salah
dipahami.
· Kesalahan
logika dari hasil tes yang tidak valid dan kesimpulan, implementasi yang salah
dari spesifikasi desain, alur logika yang salah atau tidak lengkap pengujian
data.
·
Kesalahan
koding disebabkan oleh implementasi dari rinci desain logika dan penggunaan
yang salah dari logika kode sumber. Cacat juga disebabkan oleh kesalahan
pengolahan data dan kesalahan sistem kerja.
Klasifikasi
Perubahan
·
Segala
kesalahan ini, kadang kadang disebut ‘kesalahan sisa’ atau ‘bug’, mencegah
perangkat lunak dan menyesuaikannya dengan spesifikasi yang telah disepakati.
·
Pada
saat terjadi kegagalan suatu sistem tindakan yang harus diambil untuk
memulihkan operasi dari sistem perangkat lunak. Berada dibawah tekanan dari
manajer personil perawatan terkadang mengambil jalan untuk melakukan perbaikan
darurat yang dikenal sebagai ‘patch’. Sifat Ad Hoc dari pendekatan ini
menimbulkan berbagai masalah yang mencakup kompleksitas program yang meningkat
dan efek riak yang tidak terduga.
·
Peningkatan
komplesitas program biasanya berasal dari degenerasi struktur program yang
membuat program ini semakin sulit, dan sangat sulit untuk memahaminya.
Terkadang hal ini disebut juga sebagai ‘sindrome spagheti’ atau ‘kelelahan
perangkat lunak’, yang berarti hambatan dari program untuk sebuah perubahan
program maksimum.
2. Perubahan Adaptif
· Perubahan
adaptif adalah perubahan yang didorong oleh kebutuhan untuk mengakomodir
modifikasi sistem dalam perangkat lunak. Dalam konteks ini lingkugan yang
mengacu pada totalitas dari semua kondisi dan pengaruh dari luar yang bertindak
atas sistem.
· Pemeliharaan
adaptif dapat meliputi semua sebagai konsekuensi perangkat lunak yang bergerak
kehardware yang berbeda atau kompilator plaltform perangkat lunak, sistem
operasi baru atau prosesor baru.
·
Kadang
kadang program perlu dimodifikasi agar dapat keuntungan penuh dari fasilitas
tambahan yang disediakan oleh versi baru dari sistem operasi atau masuknya
sebuah sistem manajemen database baru.
· Contoh
dari sebuah kebijakan pemerintah memiliki efek luas dalam sistem perangkat
lunak, adalah diberlakukannya pengenalan euro untuk Negara Negara uni eropa.
3. Perubahan Perfektif
· Istilah
ini digunakan untuk menjelaskan perubahan yang dilakukan untuk mengembangkan
persyaratan yang ada dari suatu sistem. Sebuah karya keberhasilan dari perngkat
lunak cenderung mengalami suksesi perubahan sehingga adanya peningkatan
persyaratan. Hal ini didasarkan pada prinsip itu sebagai perangkat lunak
menjadi berguna, pecobaan pengguna dengan kasus baru diluar ruang lingkup yang
itu pada awal dikembangkannya.
·
Pengembangan
dalam kebutuhan dapat membawa bentuk :
·
Peningkatan
pada fungsi sistem yang ada
·
Perbaikan
dalam hal efisiensikomputasional
·
Penambahan
fungsi baru
·
Dicabut
yang berlebihan atau menolak fungsionalitas.
4. Perubahan pencegahan
Perubahan
pencegahan dilakukan untuk mencegah kerusakan atau untuk meningkatkan pemeliharaan
perangkat lunak. Perubahan ini biasanya dawali dari dalam organisasi
pemeliharaan dengan tujuan untuk membuat program lebih mudah untuk dipahami dan
dengan demikian melakukan pekerjaan perawatan masa depan lebih mudah.
Pencegahan biasanya tidak menimbulkan peningkatan yang substansional dalam
fungsi dasar.
Pengaruh
riak yang tak terduga berarti bahwa perubahan pada satu bagian dari suatu
program dapat mempengaruhi bagian lain dengan cara yang tak terduga, sehingga
menyebabkan penyimpangan dalam logika sistem. Hal ini sering disebabkan
kurangnya waktu untuk melakukan analisis dampak menyeluruh sebelum dilakukan
perubahan.
Hubungan Antara
Klasifikasi Perubahan
Mengacu pada
layanan yang disediakan untuk memenuhi non-pemrograman-terkait permintaan
kerja.
Komunikasi yang efektif: Ini adalah penting antara pihak-pihak yang terkena
dampak perubahan pada sistem perangkat lunak. Pemeliharaan adalah bagian yang
paling pelanggan-intensif dari perangkat lunak siklus hidup karena proporsi
yang lebih besar dari upaya pemeliharaan dihabiskan memberikan perangkat
tambahan yang diminta oleh konsumen daripada dihabiskan untuk jenis-jenis
perubahan sistem. Waktu dan sumber daya yang dihabiskan perlu dibenarkan oleh
kepuasan pelanggan.
Pelatihan pengguna akhir: Pelatihan mengacu pada proses melengkapi pengguna
dengan pengetahuan cukup dan keterampilan yang memungkinkan mereka menggunakan
sistem secara maksimal.
Menyediakan informasi bisnis: Pengguna harus berbagai jenis informasi tepat
waktu dan akurat untuk memungkinkan mereka mengambil keputusan bisnis
strategis. Misalnya, sebuah perusahaan berencana untuk membuat perangkat
tambahan besar untuk sistem manajemen database pertama mungkin ingin mengetahui
biaya operasi semacam. Dengan informasi tersebut, perusahaan berada dalam
posisi yang lebih baik untuk mengetahui apakah lebih ekonomis untuk
meningkatkan sistem yang ada atau untuk menggantinya sama sekali.
Beberapa Definisi :
Gambar -
karakter atau atribut seperti umumnya dirasakan.
Pemeliharaan krisis - Para keadaan saat ini di mana permintaan untuk sistem
kualitas perangkat lunak tinggi yang canggih jauh melebihi pasokan sistem
seperti ini, tetapi sistem yang ada tidak memiliki kapasitas untuk berkembang
secara tepat dengan kemajuan teknologi.
Nomenklatur - terminologi, sistem penamaan dalam konteks tertentu.
Batasan
dalam Perubahan Software
— Batasan Sumber
Daya
— Ketidaktersediaan
SDM dengan skill yang memadai
— Ketidaktersediaan
tools dan environment
— Ketidaktersediaan
dana
—
Kualitas Buruk
dari Sistem yang ada
— Perubahan bisa
menyebabkan ripple effect yang tidak bisa diprediksi dan potensi gagalnya sistem
—
Kualitas sangat
buruk sehingga perubahan tidak mungkin dilakukan Maintenance
sudah tidak layak dilakukan. Ini tidak berarti bahwa membuat sistem baru bisa
dilakukan.
Batasan
dalam Perubahan Software
— Strategi
Organisasi
— Persaingan
— Strategi budget
— Inertia
— Resistensi dari
pengguna
— Kegagalan sistem
yang lama
— Hardware tidak
mendukung
— Menarik dan
memelihara staff berkualitas
— Membutuhkan
biaya tinggi
— Menimbulkan
banyak permasalahan lain
Solusi
Potensial
Realokasi
Anggaran dan Usaha
Berdasarkan pengamatan bahwa perangkat lunak biaya pemeliharaan minimal
sebanyak pengembangan baru, beberapa penulis telah mengusulkan bahwa daripada
mengalokasikan sumber daya lebih sedikit untuk mengembangkan unmaintainable
atau sulit-untuk-memelihara system, lebih banyak waktu dan sumber daya harus
diinvestasikan dalam pembangunan - spesifikasi dan desain - sistem lebih
maintainable.
Penggunaan pendekatan kebutuhan lebih maju spesifikasi, desain teknik dan
alat-alat, prosedur jaminan kualitas dan standar seperti seri ISO 9000 dan
standar pemeliharaan yang bertujuan mengatasi masalah ini. Hal ini diyakini
bahwa penyebaran ini, alat-alat teknik dan standar sebelumnya pada dalam
pengembangan siklus hidup akan menyebabkan sistem lebih maintainable.
Lengkap
Penggantian Sistem
Risiko dan biaya yang terkait dengan penggantian sistem yang lengkap sangat
tinggi dan berikut ini harus dipertimbangkan:
Kendala Ekonomi: korektif dan pemeliharaan preventif dilakukan secara periodic
dengan biaya yang relatif kecil tetapi bertahap. Dengan sedikit pengecualian,
peningkatan dan adaptif permintaan pekerjaan juga dilakukan sebentar-sebentar
di sebagian kecil dari biaya pengembangan sistem baru. Dalam jangka panjang,
biaya yang terjadi dalam menjalankan kegiatan ini menambahkan hingga jumlah
yang besar selama hidup sistem. Dalam jangka pendek, bagaimanapun, organisasi
mampu untuk membayar biaya pemeliharaan yang relatif kecil sementara pada saat
yang sama mendukung proyek-proyek yang lebih ambisius dan finansial menuntut
Residu
kesalahan yang dalam sistem yang baru: Penciptaan sistem lain ada jaminan bahwa
itu akan berfungsi lebih baik dari yang lama. Pada instalasi, kesalahan dapat
ditemukan dalam fungsi sistem lama dilakukan dengan benar dan kesalahan residu
akan perlu diperbaiki seperti yang ditemukan. Sebuah sistem baru tidak akan
bebas dari kesalahan.
Database informasi: Sistem lama adalah kumpulan fungsi, dan dengan demikian,
mencakup banyak pengalaman, merupakan gudang ide-ide yang dapat memungkinkan
identifikasi blok bangunan dari sistem masa depan, dan mungkin berisi
manajemen, operasional dan informasi keuangan tentang organisasi serta aturan
bisnis yang telah bertambah selama bertahun-tahun. Kumpulan set asumsi
(kadang-kadang dikenal sebagai sistem pengetahuan asumsi dasar) yang mendasari
paradigma yang berbeda dan fungsi yang digunakan untuk mengembangkan sistem,
yang tertanam dalam sistem lama.
Ketersediaan pengetahuan tersebut dapat berguna untuk pengembangan sistem masa
depan, sehingga mengurangi kemungkinan re-inventing the wheel. Ini akan menjadi
tidak realistis untuk sebuah organisasi untuk berpisah dengan seperti aset.
Peningkatan sistem yang ada
Sistem yang ada sekarang perlu
mendapatkan potensi untuk berkembang
ke keadaan yang lebih tinggi,
memberikan lebih canggih user-driven
fungsi, kemampuan menerapkan teknologi canggih, dan memungkinkan integrasi sistem
lainnya dengan cara yang hemat
biaya.
Model
Perbaikan
Cepat
Ini adalah
pemadam pendekatan, menunggu permasalahan terjadi dan kemudian mencoba untuk
memperbaikinya secepat mungkin.
Sangat dibatasi lingkungan (waktu, uang, orang)
Tanpa analisis rinci tentang efek jangka panjang
Sedikit dokumentasi tidak ada
Sering kali, perusahaan akan merilis perbaikan cepat sebagai tindakan
sementara. Solusi nyata akan diimplementasikan, bersama dengan koreksi lain dan
perangkat tambahan, sebagai upgrade besar di kemudian hari.
Pada tahun 1983 Boehm mengusulkan sebuah model untuk
proses pemeliharaan berdasarkan model ekonomi dan prinsip. Keputusan ekonomi
adalah kekuatan pendorong utama di balik banyak proses dan tesis Boehm adalah
bahwa model ekonomi dan prinsip-prinsip tidak hanya meningkatkan produktivitas
dalam pemeliharaan tetapi juga membantu pemahaman dari proses.
Model Osborne
Osborne hipotesis bahwa permasalahan
teknis yang timbul dalam perawatan adalah karena komunikasi manajemen yang tidak memadai
dan kontrol, serta merekomendasikan
sebuah strategi yang meliputi:
dimasukkannya persyaratan perawatan
dalam spesifikasi perubahan;
sebuah jaminan kualitas
perangkat lunak program yang menetapkan
persyaratan jaminan kualitas;
alat verifikasi bahwa
tujuan pemeliharaan telah
dipenuhi;
penilaian kinerja untuk memberikan umpan
balik kepada manajer.
Perancangan Model Perangkat
Tambahan
Model tersebut menganggap dokumentasi
yang lengkap sebagaimana bergantung
pada modifikasi ini sebagai
titik awal untuk setiap iterasi. Model ini secara eksplisit mendukung pemakaian ulang dan juga mengakomodasi model lain, misalnya
model cepat memperbaiki. Masalah dengan iteratif
batang peningkatan model dari asumsi yang dibuat tentang adanya dokumentasi lengkap dan kemampuan dari tim perawatan
untuk menganalisis produk yang ada
secara penuh.
Reuse-yang Berorientasi
pada Model
Model ini
didasarkan pada prinsip bahwa perawatan dapat dipandang sebagai kegiatan yang
melibatkan penggunaan kembali komponen program yang ada.
Model penggunaan kembali memiliki empat langkah utama:
Identifikasi bagian-bagian dari sistem lama yang kandidat untuk digunakan
kembali,
Memahami bagian-bagian sistem,
Modifikasi bagian sistem lama yang sesuai dengan persyaratan baru,
Integrasi bagian-bagian diubah ke dalam sistem baru.
Sebelum melakukan perubahan apapun, adalah penting untuk
memahami produk perangkat lunak secara keseluruhan dan program dipengaruhi oleh perubahan tertentu, ini melibatkan:
Memiliki pengetahuan umum tentang apa
sistem perangkat lunak dilakukan dan
bagaimana kaitannya dengan lingkungannya, mengidentifikasi di mana dalam perubahan
sistem adalah untuk dilaksanakan;
memiliki pengetahuan yang mendalam
tentang bagaimana bagian yang akan
diperbaiki atau dimodifikasi kerja.
Pemahaman Program mengkonsumsi proporsi yang signifikan dari
upaya perawatan dan
sumber daya. Di Hewlett Packard
diperkirakan membaca kode (elemen mendasar dalam pemahaman)
biaya $ 200 juta per tahun. Data dari industri dan sumber
lain juga menunjukkan bahwa sekitar
setengah dari upaya keseluruhan
pengeluaran mempengaruhi perubahan digunakan dalam
program pemahaman. Biaya ini cenderung meningkat dalam hal programmer mempertahankan
program yang ditulis oleh orang lain, tidak akurat, out-tanggal-atau bahkan tidak ada dokumentasi sistem, atau kerusakan dalam struktur
program akibat beberapa tahun
perbaikan ad hoc cepat.
Beberapa definisi
Chunking -
Proses menyusun unit kecil informasi (seperti laporan program) ke dalam unit
yang lebih besar (seperti prosedur). Masing-masing unit informasi dikenal
sebagai sepotong.
Kognitif proses - bagaimana pengetahuan yang dimanipulasi dalam memori manusia
selama pembentukan dan penggunaan model mental.
Struktur kognitif - cara di mana pengetahuan disimpan dalam memori manusia.
Pemahaman - pemahaman, kemampuan untuk memahami hubungan umum khusus.
Pengambilan dukungan fitur - Sebuah atribut dari produk perangkat lunak yang
dapat membimbing personil pemeliharaan dalam keputusan teknis dan manajemen
proses pembuatan.
Eksekusi efek - Perilaku sistem ketika dijalankan.
Fungsional -
laporan layanan yang sistem harus menyediakan.
Jiwa model - masih merupakan representasi abstrak dari suatu entitas.
Kebutuhan non-fungsional - kendala pada layanan dan fungsi yang ditawarkan oleh
sistem.
Domain permasalahan - Masalahnya adalah tugas yang dilakukan oleh perangkat
lunak dan masalah domain merupakan daerah yang tugas itu berada.
Produk-lingkungan kaitannya - Ini adalah hubungan antara seluruh sistem dan
unsur-unsur lingkungan di mana ia beroperasi.
Kosakata masalah - Kesulitan yang timbul dari penggunaan nama pengenal yang
gagal untuk menyampaikan makna yang dimaksud.
Tujuan Memahami
Program
Permasalahan Domain
Di sistem perangkat lunak besar,
misalnya dalam bidang seperti kesehatan,
perawatan telekomunikasi dan keuangan, masalah biasanya
dipecah menjadi sub-masalah dikelola atau elemen yang
lebih kecil, masing-masing yang ditangani oleh unit program yang berbeda seperti modul, prosedur
atau fungsi .
Dalam rangka untuk melakukan perubahan atau hanya untuk memperkirakan sumber daya yang diperlukan untuk tugas pemeliharaan,
pengetahuan tentang domain masalah secara
umum dan sub-masalah secara khusus
sangat penting sehingga mengarahkan
personil pemeliharaan dalam pemilihan
algoritma yang sesuai, metodologi dan alat.
Pemilihan personel dengan level yang sesuai keahlian dan keterampilan adalah aspek lain. Informasi
dapat diperoleh dari berbagai sumber - dokumentasi sistem,
pemakai akhir, atau kode sumber program.
Dampak Pelaksanaan
Pada tingkat yang tinggi dari abstraksi,
personil pemeliharaan perlu tahu (atau dapat memprediksi) apa hasil program akan
menghasilkan untuk masukan yang diberikan tanpa harus mengetahui mana unit program memberikan kontribusi terhadap
hasil keseluruhan atau bagaimana hasilnya tercapai.
Pada tingkatan rendah abstraksi, mereka perlu mengetahui hasil
bahwa unit program individu akan menghasilkan pada eksekusi. Pengetahuan tentang aliran data, mengontrol aliran dan pola algoritmik dapat memfasilitasi tercapainya tujuan ini.
Selama pemeliharaannya, informasi ini dapat membantu personil pemeliharaan untuk menentukan apakah perubahan diimplementasikan mencapai efek yang diinginkan.
Penyebab-Dampak Hubungannya
Pada program besar dan kompleks,
pengetahuan dari relasi ini adalah penting
dalam sejumlah cara.
Hal ini memungkinkan personil
pemeliharaan yang untuk alasan tentang bagaimana komponen dari produk perangkat lunak
berinteraksi selama eksekusi.
Hal ini memungkinkan programmer untuk
memprediksi besarnya perubahan dan
efek knock-on yang
timbul dari perubahan.
Hubungan sebab-akibat dapat digunakan untuk melacak arus informasi melalui program ini. Titik dalam program di mana
ada gangguan yang tidak biasa alur tersebut mungkin menandakan sumber bug.
Produk-Lingkungan Hubungannya
Suatu produk adalah perangkat lunak
sistem. Lingkungan adalah totalitas dari semua
kondisi dan pengaruh dari luar
yang bertindak atas produk,
misalnya aturan bisnis, peraturan pemerintah, pola kerja, perangkat lunak dan platform
perangkat keras operasi.
Hal ini penting bagi personil perawatan untuk mengetahui tidak hanya alam tetapi sejauh mana relasi.
Pengetahuan tersebut dapat digunakan
untuk memperkirakan bagaimana perubahan
dalam unsur-unsur ini akan
mempengaruhi produk pada umumnya
dan program yang mendasarinya
pada khususnya.
Pengambilan Dukungan Fitur
Sifat Produk Perangkat Lunak ini seperti kompleksitas dan rawatan adalah contoh yang dapat membimbing personel pemeliharaan teknis
dan manajemen proses pengambilan keputusan seperti pilihan, proses
pengambilan keputusan penganggaran analisis, dan alokasi sumber daya.
Ada banyak faktor yang akan mempengaruhi
sejauh mana personil pemeliharaan yang
dapat memperoleh pengetahuan seperti
tentang sistem. Ini termasuk
strategi pemahaman, keahlian domain, kualitas dokumentasi,
presentasi dan organisasi, praktek
pemrograman dan implementasi masalah, dan alat pendukung.
Tidaklah
penting bahwa setiap anggota dari tim proyek pemeliharaan memahami setiap aspek
dari sistem dipertahankan. Proses Pemahaman tentang didorong oleh kebutuhan
untuk mengetahui. Anggota dari tim pemeliharaan - manajer, analis, perancang
dan programer - semua memiliki pemahaman yang berbeda atau informasi yang
dibutuhkan tergantung dari tingkat di mana mereka berfungsi.
Manajer
Mengingat bahwa salah satu tanggung jawab manajemen membuat keputusan, manajer
harus memiliki keputusan dukungan pengetahuan dalam rangka untuk membuat
keputusan. Tingkat Pemahaman tentang yang diperlukan akan tergantung pada
keputusan yang akan diambil.
Sebagai contoh, untuk dapat mengestimasi biaya dan lamanya perangkat tambahan
utama, pengetahuan tentang ukuran program (dalam hal baris poin kode atau
fungsi) diperlukan. Perkiraan itupun selanjutnya dapat digunakan untuk
menentukan apakah atau tidak itu adalah lebih hemat untuk menggantikan sistem
dengan sistem vendor.
Para analis
Dalam pengembangan perangkat lunak
para analis membutuhkan pemahaman
dari domain masalah (misalnya untuk perawatan, keuangan atau kesehatan)
untuk melakukan tugas-tugas seperti
untuk menentukan kebutuhan fungsional
dan non-fungsional, dan untuk membangun
hubungan di antara sistem dan
elemen yang lingkungan.
Selama pemeliharaannya, para analis akan
peduli dengan mengetahui bagaimana
perubahan dalam lingkungan ini (misalnya,
peraturan pemerintah yang baru atau
sistem operasi baru) akan
mempengaruhi sistem. Jadi,
sebelum melakukan perubahan tersebut, analis perlu memiliki pandangan global dari sistem, yaitu, suatu
gambaran umum dari interaksi antara unit-unit fungsional utama.
Analis juga diperlukan untuk menentukan implikasi perubahan yang
pada kinerja sistem.
Perancang
Selama perawatan, pekerjaan dari
perancang adalah untuk:
mengekstraksi informasi ini dan hanya
menentukan bagaimana perangkat tambahan
mampu ditampung oleh, arsitektur aliran data struktur, data dan mengontrol aliran dari sistem yang ada;
pergi melalui kode sumber untuk mendapatkan gambaran kasar dari ukuran pekerjaan, wilayah dari
sistem yang akan terpengaruh, dan
pengetahuan dan keterampilan yang akan
diperlukan oleh tim pemrograman
yang melakukan pekerjaan.
Pemakaian konsep seperti menyembunyikan informasi, dekomposisi program
modular, abstraksi data, orientasi
objek, dan notasi desain yang baik seperti diagram aliran data, diagram aliran kontrol,
grafik struktur dan proses hirarki
input / output (HIPO) grafik ini dapat membantu perancang memperoleh pemahaman yang baik dari sistem sebelum merancang perubahan.
Pemrogram
Pemrogram perawatan yang diperlukan untuk mengetahui efek pelaksanaan sistem
pada berbagai tingkat abstraksi, pengetahuan kausal dan pengetahuan tentang
hubungan produk-lingkungan.
Pada tingkatan abstraksi yang lebih tinggi (misalnya, pada tingkat sistem),
pemrogram perlu mengetahui fungsi dari masing-masing komponen sistem dan
hubungan kausal mereka.
Pada tingkat yang lebih rendah abstraksi (misalnya, prosedur individu atau
modul), pemrogram perlu memahami 'apa setiap pernyataan program tidak, urutan
eksekusi (aliran kontrol), efek yang transformasional terhadap objek data
(aliran data), dan tujuan dari satu set pernyataan program (fungsi).
Meskipun pada prinsipnya, adalah mungkin untuk menggolongkan
peran personil pemeliharaan yang,
dalam prakteknya divisi tidak jelas dipotong. Tanggung jawab akan tergantung pada faktor-faktor seperti
pengorganisasian kerja pemeliharaan (lihat
bab 10) dan pada ukuran tim pemeliharaan.
Dalam keadaan dimana beberapa individu
yang ditugaskan untuk tugas-tugas
pemeliharaan, mereka cenderung untuk melakukan tugas analis, desainer dan
programmer meskipun tidak selalu bersamaan.
Dengan demikian, mereka perlu memahami bukan hanya masalah implementasi
tingkat rendah seperti mengontrol aliran, aliran data, struktur data yang dan aspek algoritmik dari sistem
tetapi diharapkan juga untuk
memahami desain arsitektural sistem
dan dapat mengetahui setiap masalah
lainnya yang mungkin diperlukan untuk
pemeliharaan sukses dan evolusi.
Faktor-Faktor
yang
Mempengaruhi Pemahamam
Keahlian
Programmer yang menjadi pakar dalam domain aplikasi tertentu atau dengan bahasa pemrograman tertentu
berdasarkan atas repertoar pengetahuan dan keterampilan yang mereka
mendapatkan dari bekerja dalam domain atau dengan
bahasa.
Akibatnya, programmer lebih berpengalaman adalah dengan domain aplikasi atau
dengan bahasa pemrograman, mudah dan lebih cepat itu adalah untuk memahami program dan
memang, perangkat lunak sistem secara
keseluruhan.
Penerapan Masalah
Ada sejumlah masalah
implementasi yang dapat mempengaruhi kemudahan dan sejauh mana pengelola suatu paham
sebuah program. Kompleksitas yang melekat pada masalah asli dipecahkan oleh program
ini adalah faktor. Pada tingkat
program, gaya penamaan, komentar,
tingkat bersarang,, kejelasan mudah dibaca, kesederhanaan, mekanisme dekomposisi, menyembunyikan
informasi dan pengkodean standar
dapat mempengaruhi pemahamam.
Dokumen
Pengembang perlu untuk memiliki akses ke dokumentasi sistem yang memungkinkan mereka untuk memahami
masalah fungsi, desain, implementasi dan
lainnya yang mungkin relevan untuk pemeliharaan sukses.
Terkadang bagaimanapun, dalam dokumentasi sistem tidak akurat, ketinggalan zaman atau tidak ada. Dalam kasus seperti ini pengelola harus resor untuk dokumentasi internal ke kode sumber Programnya sendiri - Program komentar.
Organisasi dan
Penyusunan Program
Membacakan kode sumber program semakin diakui sebagai aspek penting dari
pemeliharaan, terlebih lagi pada situasi dimana teks program adalah
satu-satunya sumber informasi tentang sebuah produk perangkat lunak. Dalam
terang ini, program harus diatur dan disajikan dengan cara yang akan
mempermudah teliti, browsing, visualisasi dan akhirnya pemahaman.
Secara teoritis, efektivitas organisasi dan penyajian kode sumber yang harus
memfasilitasi identifikasi beacon, seruan rencana dan pembangunan potongan,
yang semuanya adalah pusat untuk Pemahaman tentang program. Pemakaian lekukan
untuk menekankan struktur logis dari sebuah program adalah contoh dari sebuah
'mercusuar struktur'. Ketika digunakan dengan cara ini, struktur:
memberikan petunjuk yang Pemrogram digunakan untuk merumuskan, mengkonfirmasi
dan menyempurnakan hipotesis selama Pemahaman tentang (seperti terlihat dalam
model Brooks ');
menyediakan petunjuk bahwa panduan programmer dalam seruan rencana yang cocok,
dan
mempromosikan pembentukan sepotong program. Potongan tersebut kemudian
dibandingkan dengan rencana terkandung dalam basis pengetahuan programmer '-
sebuah repertoar keterampilan pemrograman dan teknik.
Dalam proses pemahaman membutuhkan banyak
total waktu keseluruhan yang dihabiskan
untuk melakukan perubahan.
Alasan untuk hal ini mencakup salah, di luarterkini
atau bahkan tidak ada dokumentasi,
kompleksitas sistem dan kurangnya
pengetahuan domain yang cukup pada bagian dari pengelola.
Salah satu cara mengatasi masalah ini
adalah abstrak dari kode sumber informasi yang
relevan. tentang sistem,
seperti spesifikasi dan desain,
dalam suatu bentuk yang mempromosikan
pemahaman.
Rekayasa terbalik adalah teknik yang
ini dapat digunakan untuk melakukan hal
ini. Rekayasa terbalik saja tidak
menyebabkan perubahan dalam program,
tetapi hanya membuka jalan bagi implementasi
lebih mudah dari perubahan yang
diinginkan.
Perubahan ini diimplementasikan
menggunakan teknik seperti teknik
maju, restrukturisasi, dan rekayasa
ulang.
Beberapa
Definisi
Abstrak -
model "yang merangkum detail dari
topik tersebut merepresentasikan".
Teruskan teknik -
teknik pendekatan perangkat lunak tradisional dimulai dengan
analisis kebutuhan dan kemajuan untuk implementasi dari sistem.
Pembenahan - proses pemeriksaan dan perubahan dimana sistem diubah
oleh rekayasa terbalik pertama
dan kemudian rekayasa ke depan.
Restrukturisasi - transformasi sistem dari
satu bentuk representasi yang
lain.
Melakukan rekayasa balik - proses
melakukan analisis sistem subjek ke:
mengenali komponen sistem dan antar hubungan mereka dan
membuat representasi sistem tersebut
dalam bentuk lain atau pada tingkat abstraksi yang lebih tinggi.
Abstraksi
Abstraksi ini dicapai dengan menyoroti fitur penting dalam sistem subjek dan mengabaikan yang tidak
relevan.
Ada tiga jenis abstraksi yang dapat dilakukan terhadap sistem perangkat
lunak:
Ini merupakan abstrak dari sistem target dari urutan tepat di mana operasi dilakukan.
Ada dua kelompok dari proses tersebut
bisa diabstraksikan: proses konkuren
dan terdistribusi.
Proses konkuren berkomunikasi melalui
data bersama yang disimpan dalam ruang memori yang ditunjuk.
Proses yang Terdistribusi biasanya berkomunikasi melalui 'messagepassing'
dan tidak memiliki daerah data bersama.
Menyelidiki reverse Rekayasa
Tujuan dari rekayasa terbalik ini adalah untuk memperantarai perubahan dengan memungkinkan
sistem perangkat lunak untuk dapat
dipahami dalam bentuk apa yang
dilakukannya, bagaimana cara kerjanya dan representasi arsitekturalnya.
Untuk
memberikan pandangan alternatif:
Alat Redocumentation dapat digunakan untuk memberikan dokumentasi alternatif
seperti diagram arus data, diagram kontrol aliran dan diagram relasi entitas
selain dokumentasi yang ada. Ini adalah cara di mana pandangan lain dari sistem
dapat diperoleh.
Sebagai contoh, diagram arus data menggambarkan sistem dari sudut pandang
aliran data dalam sistem dan di luar. Kontrol diagram aliran, sebaliknya,
menunjukkan sistem dari kondisi perspektif aliran kontrol antara berbagai
komponen.
Produktivitas dapat ditingkatkan dengan penggunaan
kembali perangkat lunak karena sedikit
waktu dan usaha yang diperlukan
untuk menentukan, merancang,
melaksanakan dan menguji sistem
baru.
Kualitas produk baru cenderung lebih tinggi, terutama karena komponen digunakan kembali akan telah melalui siklus
pengujian yang sangat teliti. Reuse
menghasilkan produk yang berkualitas
lebih dapat diandalkan, lebih kuat
dan lebih tinggi.
Hasil observasi memberitahu telah dibuat bahwa 60-85% dari program yang digunakan untuk membangun sistem
sudah ada dan dapat dibakukan dan digunakan kembali.
Perlu ditegaskan bahwa manfaat berasal dari penggunaan kembali komponen perangkat lunak yang baik - yaitu, komponen yang
telah direkayasa dengan baik, ketat
diuji dan terbukti aman dan handal.
Sasaran bagi Penggunaan Kembali
Proses
Proses penggunaan kembali dapat penerapan suatu metodologi yang diberikan
kepada masalah yang berbeda.
Secara umum, sebuah operasi yang diulang menjadi dikenal dan lebih mudah
dilakukan; permasalahan tersebut ditemukan dan diselesaikan dan dengan demikian
manfaat dari pengulangan cenderung meningkat.
Personil
Penggunaan kembali personil berarti menggunakan kembali pengetahuan yang mereka
peroleh dalam masalah yang sama sebelumnya atau area aplikasi. Keahlian ini
dikenal sebagai domain pengetahuan.
Kesulitan dalam pengarsipan jenis pengetahuan dan pergantian personil di dalam
industri
Perangkat lunak
Cara untuk meminimalkan dampak dari masalah ini adalah melalui penerapan
analisis domain untuk menangkap pengetahuan ini dalam bentuk dapat digunakan
kembali atau melalui tindakan untuk memerangi pergantian staf tinggi atau
alat-alat seperti basis pengalaman perangkat lunak.
Produk
penggunaan kembali produk melibatkan menggunakan artefak yang menjadi produk
yang timbul dari proyek serupa.
3.a. data
Data dapat digunakan kembali ini memungkinkan berbagi data antara aplikasi dan
juga mendorong Program usabilitas luas.Data dapat digunakan kembali memegang peranan penting dalam sistem database.
Untuk aplikasi yang berbeda untuk berbagi data dalam database ini, data harus dalam
format yang mempermudah transfer data antara aplikasi.
3.b. disain
Perancangan sistem dapat direpresentasikan dengan berbagai cara, misalnya
menggunakan diagram konteks, diagram aliran data, diagram relasi entitas,
diagram keadaan transisi dan model objek.
Pengiriman kembali yang sudah ada sebelumnya desain selama pengembangan produk
sejenis dapat meningkatkan produktivitas dan meningkatkan kualitas produk.
Meskipun potensi ini, hanya sedikit bukti dari desain ulang luas, yang ditandai
dengan kurangnya segala bentuk katalog desain perangkat lunak standar.
3.c. program
Penggunaan kembali program ini adalah penggunaan kembali komponen kode yang
dapat diintegrasikan menjadi sebuah sistem perangkat lunak dengan adaptasi
sebelumnya sedikit atau tidak ada;
misalnya, perpustakaan (berisi fungsi ilmiah dan telah dikenal algoritma),
bahasa tingkat tinggi dan berorientasi pada masalah bahasa.
1.a. Kotak
hitam Penggunaan Kembali
Pada kotak hitam kembali,
komponen digunakan kembali tanpa modifikasi. Karena pengguna tidak perlu memodifikasi komponen sebelum menggunakan
kembali itu, hanya informasi
mengenai apa yang dilakukannya disediakan,
memastikan bahwa pengguna tidak dapat mengubah
pelaksanaan komponen.
1.b. Kotak putih Penggunaan
Kembali
Pada white-box penggunaan
kembali, komponen digunakan kembali setelah modifikasi. Pendekatan
untuk digunakan kembali mensyaratkan
bahwa pengguna diberikan bersama
informasi pada komponen apa dilakukan dan bagaimana cara kerjanya.
Akses ke kode sumber dari modul implementasi memungkinkan pengguna untuk memodifikasi
komponen sesuai dengan
persyaratan sistem target.
Pendekatan
komposisi yang berbasis untuk digunakan kembali melibatkan menyusun sebuah
sistem baru sebagian dari komponen yang ada. Ada dua cara utama di mana komponen
tersebut dapat diperoleh.
Yang pertama adalah melalui proses yang dikenal sebagai desain untuk digunakan
kembali. Ini melibatkan mengembangkan komponen dengan maksud menggunakan mereka
mengenai lebih dari satu kali.
Cara kedua adalah melalui reverse engineering.
Untuk
mengakomodasi sifat evolusi dari sistem perangkat lunak selama hidup, adalah
penting untuk mengantisipasi perubahan. Ini berarti merancang dan menerapkan modul yang rentan terhadap modifikasi.
Demikian pula, dengan penggunaan kembali, komponen kandidat harus dirancang dan
dilaksanakan dengan cara yang melindungi mereka dari terlalu banyak perubahan
ketika mereka harus
digunakan kembali.
Artinya, jika manfaat signifikan dapat menuai dari penggunaan kembali komponen,
masalah usabilitas yang seharusnya tidak menjadi soal kebetulan atau
ketinggalan jaman.
