Aria Kurniawan 09560046

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:

• ·         fungsi abstraksi

• ·         abstraksi data

• ·         proses abstraksi.

    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.