Selasa, 08 November 2011

Resume Sistem Pakar

  1. Definisi sistem pakar
Sistem pakar adalah sebuah program computer yang mencoba meniru atau mensimulasikan pengetahuan (knowledge) dan keterampilan (skill) dari seorang pakar pada area tertentu.
Sistem ini akan mencoba memecahkan suatu permasalahan sesuai dengan kepakarannya.
·         Sistem pakar merupakan salah satu aplikasi dari kecerdasan buatan(artificial intelligence).
·         AI sendiri berakar dari keinginan manusia untuk membuat sebuah mesin cerdas.
·         Dewasa ini sistem pakar telah diaplikasi dalam banyak bidang, misalnya : industri manufaktur, pertanian, medis, militer de-es-be.
Manfaat Sistem Pakar :
1.      Memungkinkan orang awam bisa mengerjakan pekerjaan para ahli
2.      Bisa melakukan proses secara berulang secara otomatis
3.      Menyimpan pengetahuan dan keahlian para pakar
4.      Mampu mengambil dan melestarikan keahlian para pakar (terutama yang termasuk keahlian langka)
5.      Mampu beroperasi dalam lingkungan yang berbahaya.
6.      Memiliki kemampuan untuk bekerja dengan informasi yang tidak lengkap dan mengandung ketidakpastian. Pengguna bisa merespon dengan jawaban ’tidak tahu’
7.      atau ’tidak yakin’ pada satu atau lebih pertanyaan selama konsultasi dan sistem pakar tetap akan memberikan jawaban.
8.      Tidak memerlukan biaya saat tidak digunakan
9.      Dapat digandakan (diperbanyak) sesuai kebutuhan dengan waktu yang minimal dan sedikit biaya
10.  Dapat memecahkan masalah lebih cepat daripada kemampuan manusia dengan catatan menggunakan data yang sama.
11.  Menghemat waktu dalam pengambilan keputusan
12.  Meningkatkan kualitas dan produktivitas karena dapat memberi nasehat yang konsisten dan mengurangi kesalahan
13.  Meningkatkan kapabilitas sistem terkomputerisasi yang lain.
14.  Mampu menyediakan pelatihan. Pengguna pemula yang bekerja dengan sistem pakar akan menjadi lebih berpengalaman. Fasilitas penjelas dapat berfungsi sebagai guru.



Kelemahan Sistem Pakar :
1.    Biaya yang diperlukan untuk membuat, memelihara, dan mengembangkannya sangat mahal
2.    Sulit dikembangkan
3.    Sistem pakar tidak 100% benar
4.    Pendekatan oleh setiap pakar untuk suatu situasi atau problem bisa berbeda-beda, meskipun sama-sama benar.
5.    Transfer pengetahuan dapat bersifat subjektif dan bias
6.    Kurangnya rasa percaya pengguna dapat menghalangi pemakaian sistem pakar.

Konsep Dasar Sistem Pakar :
Konsep dasar sistem pakar mengandung :
1.     keahlian,
2.     ahli/pakar,
3.     pengalihan keahlian,
4.     Mengambil keputusan,
5.     aturan,
6.     kemampuan menjelaskan.

Contoh Permasalahan
Contoh klasik permasalahan dalam sistem pakar adalah masalah 2 ember air. “Diberikan 2 ember air yang berkapasitas 8 liter dan 6 liter. Kita dapat mengisi satu ember dari ember lainnya dan proses penakarannya hanya dengan memakai 2 ember tersebut. Bagaimana kita bisa mendapatkan tempat 4 liter dalam 8 ember. Asumsikan tidak ada air yang hilang dalam proses penakaran”
Langkah penyelesaian :
1.      Menentukan aksi-aksi (problem space) yang bisa mengubah kondisi pada kedua ember dalam bentuk rule atau tree-diagram seperti dalam gambar  contoh kemungkinana aksi dibawah ini :
a)      Isi ember 8 liter
b)      Isi ember  6 liter
c)      Kosongkan ember  8 liter
d)      Kosongkan ember  6 liter
e)      Isikan seluruh air dalam ember  8 liter ke 6 liter
f)       Isikan seluruh air dalam ember  6 liter ke 8 liter
g)      Penuhi ember  8 liter dari 6 liter
h)      Penuhi ember  6  liter dari 8 liter

2.      Menentukan urutan aksi untuk menghasilkan solusi, seperti :

Struktur Sistem Pakar
     Secara umum struktur sebuah sitem pakar terdiri atas 3 komponen utama, yaitu :
1.      Knowledge base (Basis pengetahuan) adalah bagian dari sebuah sistem pakar yang mengandung/menyimpan pengetahuan (domain knowledge).
2.      Working memory mengandung/menyimpan fakta-fakta yang termuka selama proses konsultasi dengan sistem pakar. Selama proses konsultasi, user memasukkan fakta-fakta yang dibutuhkan. Kemudian sistem akan mencari padanan tentang fakta tersebut dengan informasi yang ada dalam knowledge base untuk menghasilkan fakta baru.
3.      Inference engine bertugas mencari padanan antara fakta yang ada di dalam working memory dengan fakta-fakta domain knowledge tertentu yang ada di dalam knowledge base, kemudian inference engine mengabil kesimpulan dari problem yang diajukan kepada sistem.
Gambar Struktur dasar sistem pakar

Heuristic Searching Sebagai Dasar dari Artificial Intelligence Note:
(AI)
         Para peneliti awal kecerdasan buatan menitik beratkan pada penyelesaian masalah yang tidak menggunakan metoda komputasi konvensional. Hal ini disebabkan metoda pemecahan masalah konvensional tidak dapat lagi digunakan. Permasalahan pada sistem AI tidak memiliki algoritma tertentu. Kalaupun ada tentulah sangat kompleks.
         Karena itu haruslah ditemukan sebuah teknik baru yang mirip dengan cara yang digunakan oleh manusia untuk menyelesaikan masalah dan dapat diimplementasikan pada komputer.
         Salah satu metoda yang cukup terkenal adalah metoda searching.
         Searching dalam sebuah struktur data telah menjadi dasar bagi algoritma komputer, tetapi proses searching pada AI memiliki perbedaan. Metoda searching pada AI merupakan searching problem space bukan searching data (e.g., angka, karakter, string) tertentu. Proses searching ini berupa jalur yang menggambarkan keadaan awal sebuah masalah menuju kepada penyelesaian masalah yang diinginkan (i.e., the solved problem). Jalur-jalur ini mengambarkan langkah-langkah penyelesaian masalah. Melalui proses searching menuju sebuah penyelesaian akan terbentuk sebuah solution space.
         Perhatikan contoh penyelesaian masalah komputer pada Gambar dibawah ini Langkah pertama untuk mengetahui apakah komputer dapat digunakan atau tidak adalah men-switch ON. Selanjutnya dengan melakukan inspeksi terhadap kondisi lampu indikator kita dapat menentukan langkah berikutnya. Misalnya kondisi lampu OFF. Dengan melakukan searching terhadap problem space kita akan tiba pada sebuah penyelesaian masalah agar komputer dapat diaktifkan kembali.


2.    Sistem Berbasis Aturan (Rule Based System)
Sistem berbasis aturan adalah sebuah program yang menggunakan aturan IF-THEN.
Model ini berbeda debgan pemrograman konvensional, misalnya rule tidak harus berada pada urutan tertentu.
Contoh dari sistem berbasis aturan adalah sbb:
IF Sabtu OR Minggu                  THEN Nonton bioskop
IF  NOT (Sabtu OR Minggu)       THEN Bekerja
IF Nonton Bioskop                      THEN pergi keluar
IF Bekerja                                  THEN pergi keluar
IF NOT (Bisa pergi keluar)         THEN Tinggal di rumah
IF  Cuaca baik                           THEN Bisa pergi keluar
IF  Hujan                                                THEN Bawa Payung
IF  Hujan            AND Bawa Payung      THEN Bisa pergi keluar

Perbedaan Sistem Konvensional dan Sistem Pakar
Sistem Konvensional
Sistem Pakar
Fokus pada solusi
Fokus pada problem
Programmer bekerja sendiri
Team-work
sequensial
iterative

Data, Informasi dan Pengetahuan (Knowledge)
·         Data merupakan hasil pengukuran atau catatan (record) tentang sebuah kejadian (misalnya : suhu, waktu, harga,dsb ). Data dapat berupa angka, huruf, gambar, suara dsb.
·         Informasi merupakan hasil olahan dari data sedemikian rupa sehingga karakteristik dari data tersebut dapat diuji, misalnya rata-rata, varian, distribusi dsb.
·         Pengetahuan merupakan informasi yang diletakkan pada konteks/lingkungan tertentu, misalnya peta jawa, distribusi kinya di Indonesia, dsb.

Keuntungan Representasi dengan Rule-Based
·         Modularity :
Karena setiap rule pada KBS dibagi secara jelas, maka mudah dan flexibel bagi knowledge engineer untuk menambah, memodifikasi, menghapus rule yang ada.
·         Uniformity :
Semua Knowledge pada sistem mempunyai format yang sama
·         Naturalness :
Rule adalah ekspresi yang natural dari Knowledge


Kerugian representasi dengan Rule-Based
·         In-efficiency :
Exekusi untuk pencocokan rule dan fakta memerlukan waktu yang lama (Setiap 1 cycle, harus menguji banyak rule).
·         Coverage Domain :
Berbeda permasalahan, akan beda rule dan setiap domain permasalahan akan memerlukan puluhan bahkan ratusan rule.

Proses Reasoning
·         Proaes reasoning dari sebuah sistem berbasia atruran adalah tahapan proses mulai dari sekumpulan fakta menuju solusi, jawaban dan kesimpulan.
·         Terdapat dua macam cara yang dapat digunakan untuk menghasilkan suatu kesimpulan, yaitu :
o   Forward Chaining (data driven) : kesimpulan dihasilkan dari seperangkat data yang diketahui.
-          Forward Chaining yang diimplementasikan sebagai inference networks sangat baik untuk aplikasi monitoring dan diagnosa yang control sistemnya ‘real time’
-          Juga sangat baik untuk persoalan yang relasi antar faktanya sangat mudah ditetapkan
o   Backward Chaining (goal driven) : memilih beberapa kesimpulan yang mungkin dan mencoba membuktikan kesimpulan tersebut dari bukti-bukti yang ada.
-          Backward Chaining sangat sesuai  untuk aplikasi yang inputnya sangat banyak, dibandingkan konklusinya.
-          Juga sangat baik untuk persoalan diagnosis (mis medical diagnosis) dimana user berhubungan langsung dengan KBS.

Forward Reasoning
Merupakan proses inferensi dimulai dari seperangkat data yang ada menuju ke kesimpulan.
Fungsi masing-masing step untuk gambar diatas dijelaskan sebagai berikut :
1.      Matching
Adalah setiap rule yang ada pada basis pengetahuan dibandingkan dengan fakta-fakta yang diketahui untuk mencari rule mana yang memenuhiaaaaa(istilah ‘memenuhi’ berarti : situasi, premis, atau antecedent bernilai benar).
2.      Confict Resolution
Pada langkah pertama sangat mungkin dihasilkan suatu kondisi dimana beberapa rule dipenuhi. Conflict Resolution bertugas untuk mencari rule dimana yang memiliki prioritas tertinggi yang berpotensi untuk dieksekusi.
3.      Education
Langkah terakhir dari proses forward reasoning adalah eksekusi dari rule. Proses ini menghasilkan dua kemungkinan, yaitu : fakta baru diturunkan dan ditambahkan fact base atau rule baru dihasilkan dan ditambahkan ke knowledge base.
Backward Reasoning
Mekanisme inferensi pada backward reasoning berbeda dengan forward reasoning. Walaupun kedua proses melibatkan pengujian terhadap masing-masing rule, backward reasoning mulai dari konklusi yang diharapkan menuju fakta-fakta yang mendukung konklusi tersebut.

3.    Propositional Logic dan Predicate Calculus
Propositional Logic
Propositional Logic Merupakan salah satu bentuk (bahasa) representasi logika yang paling tertua dan paling sederhana.
Beberapa fakta dapat digambarkan dan dimanipulasi dengan menggunakan aturan-aturan aljabar Boolean.
Propositional logic membentuk statement sederhana atau statement yang kompleks dengan menggunakan propositional connective, dimana mekanismen ini menentukan kebenaran dari sebuah statement kompleks dari kebenaran yang direpresentasikan oleh statement lain yang lebih sederhana.
Beberapa operator penghubung yang sering kali dipakai dalam propositional logic antara lain:

Tabel Operator penghubung

Tabel Kebenaran


 Predicate Calculus
·         Kalkulus predikat, disebut juga logika predikat member tambahan kemampuan untuk mempresentasikan pengetahuan dengan lebih cermat dari rinci.
·         Representasi pengetahuan dengan menggunakan predicate calculus merupakan dasar bagi penulisan bahasa pemrograman PROLOG
·         Contoh :
Propositional : Manusia menjelajah Mars
Predicate calculus : Jelajah (manusia, mars)
Propositional : Jono menyukai Rebeca
Predicate calculus :  suka (jono, rebeca)
Propositional :  Rebeca cantik
Predicate calculus : cantik (Rebeca)
Variabel
·         Dimana predicate calculus huruf dapat digunakan untuk menggantikan argument
·         Simbol-simbol juga bisa untuk merancang beberapa objek atau individu.
Contoh : x = jono, y = Rebeca, maka pernyataan jono menyukai Rebeca dapat ditulis dalam bentuk predicate calculus suka (x,y).
·           Dalam beberapa hal variable dibutuhkan agar pengetahuan dapat diekspresikan dalam kalkulus predikat sehngga nantinya dapat dimanipulasi dengan mudah dalam proses inferensi.
Fungsi
·         Predicate calculus memperbolehkan penggunaan symbol untuk mewakili fungsi-fungsi.
Contoh : ayah (jono)=Santoso, ibu (Rebeca)=Rini
·         Fungsi juga dapat digunakan bersamaan dengan predikat
Contoh : Teman (ayah(Jono), ibu(Rebeca)=teman(Santoso.Rini)
Operator
Predicate calculus menggunakan operator yang sama seperti operator-operator yang berlaku pada propotional logic.
Contoh :
Diketahui dua buah statement sebagai berikut :
Suka (Jono.Rebeca)
Suka (Dani,Rebeca)
Pada 2 predikat diatas, terdapat dau oarng menyukai rebeca. Untuk memberikan pernyataan adanya kecemburuan di antara mereka, maka:
Jika suka(x,y) AND suka(z,y), maka TIDAK suka(x,z).





4.    Membangun KBS dengan Sistem Berbasis Aturan
Sebagai contoh permasalahan akan diambil kasus pada Health Maintenance Organization (HMO).
HMO adalah sebuah organisasi yang member layanan kesehatan bagi anggotanya, misalnya layanan pengobatan, layanan panggilan ambulan, dsb.
Untuk menjamin bahwa masalah kesehatan serius akan mendapatkan prioritas layanan, seorang manajer telah menempatkan seseorang untuk melakukan screening awal terhadap pasien. Screering dilakukan dengan cara berkonsultasi dengan sistem pakar untuk menentukan status dan jenis layanan yang tepat bagi pasien.
Langkah-Langkah membangun KBS
·         Langkah 1 : Isolasi area bagi KBS
Untuk membatasi permasalahan pada sistem pakar yang akan dibangun harus diberikan batasan organisasi dan juga layanan yang dapat diberikan oleh sistem. Sebagai contoh untuk sistem HMO, batasan struktur organisasi dan layanan ditunjukkan dalam gambar.
·         Langkah 2 : Target Keputusan
Langkah selanjutnya adalah menentukan target keputusan bagi sistem pakar. Pasien pada umumnya membutuhkan bantuan untuk penyakit yang baru diderita (new case) atau penanganan kelanjutan dari penyakit yang sudah lama diderita (flow up case).  Atau mungkin juga pasien yang lainnya membutuhkan informasi atau layanan ini, sedangkan mereka yang bukan merupakan anggota akan diarahkan untuk ikut serta dalam keanggotaan HMO. Karena iti dapat ditentukan dalam 3 hal factor utama yang menentukan target keputusan,yaitu :
-          HMO status : Bagaimana status keanggotaan dari pasien? Deklarasi keanggotaan dari pasien akan diikuti dengan validasi nomor id.
-          Reason : Apa alas an datang ke HMO? Apakah new case, follow-up case, information seeking other visit?
a)       

b)       

Gambar Blok diagram organisasi dan layanan HMO

-          Problem : Bagaiamana keseriusan dari kondisi pasien sekarang? Dalam hal ini dapat diidentifikasi dari temperature dan symptom yang lain.

·         Langkah 3 : Membuat Dependency Diagram (Diagram Ketergantungan)

Gambar Dependency Diagram HMO

·         Langkah 4 : Membuat Tabel Keputusan
Tabel keputusan diturunkan dari  Dependency diagram pada gambar diatas,karena dalam gambar tersebut terdapat tiga segitiga, maka akan terdapat 3 tabel keputusan. Tabel keputusan untuk set 1 (Rule 1-5) adalah sebagai berikut :
Gambar Blok diagram target keputusan








Tabel keputusan set 1


Penyederhanaan table keputusan set 1


·         Langkah 5 : Menulis IF-THEN Rule
Berdasarkan table keputusan yang telah direduksi dapat diturunkan sistem berbasis aturan seperti ditunjukkan dibawah ini :










Rabu, 21 September 2011

Swebok Chapter 6 - Software Maintenance

Swebok - Chapter 6
Software Maintenance

Upaya pengembangan perangkat lunak mengakibatkan pengiriman perangkat lunak produk yang memenuhi kebutuhan pengguna. Dengan demikian, produk perangkat lunak harus berubah atau berkembang. Setelah di operasi, cacat ditemukan, operasi berubah, dan permukaan pengguna persyaratan baru. Fase pemeliharaan siklus hidup dimulai berikut masa garansi atau dukungan pasca implementasi pengiriman, tapi kegiatan pemeliharaan terjadi jauh lebih awal. 
Perawatan perangkat lunak merupakan bagian integral dari hidup perangkat lunak siklus. Namun, belum, historis, menerima yang sama tingkat perhatian yang fase-fase lain. Secara historis, pengembangan perangkat lunak telah memiliki jauh lebih tinggi profil dari pemeliharaan perangkat lunak di kebanyakan organisasi. Ini sekarang berubah, sebagai organisasi berusaha untuk menekan hasil maksimal dari investasi pengembangan perangkat lunak mereka dengan operasi perangkat lunak menjaga selama mungkin. Kekhawatiran tentang Tahun 2000 (Y2K) rollover terfokus signifikan perhatian pada fase perawatan perangkat lunak, dan Paradigma Open Source telah membawa perhatian lebih lanjut untuk masalah perangka lunak artefak mempertahankan dikembangkan oleh lain. 
Dalam Panduan, perawatan perangkat lunak didefinisikan sebagai Totalitas kegiatan yang dibutuhkan untuk memberikan biaya-efektif dukungan untuk perangkat lunak. Kegiatan yang dilakukan selama pra-pengiriman panggung, serta selama pengiriman pasca- panggung. Pra-pengiriman kegiatan meliputi perencanaan pasca- operasi pengiriman, untuk pemeliharaan, dan untuk logistik tekad untuk kegiatan transisi. Pasca-pengiriman Kegiatan meliputi modifikasi perangkat lunak, pelatihan, dan operasi atau interfacing ke divisi bantuan. 
KA Pemeliharaan Software terkait dengan semua yang lain aspek rekayasa perangkat lunak. Oleh karena itu, KA ini deskripsi adalah terkait dengan semua bab lain dari Panduan. 


TOPIK UNTUK PEMELIHARAAN PERANGKAT LUNAK 

1. Pemeliharaan Perangkat Lunak Fundamental 
Bagian pertama memperkenalkan konsep-konsep dan terminologi yang membentuk dasar yang mendasari untuk memahami peran dan ruang lingkup perawatan perangkat lunak. Topik yang memberikan definisi dan menekankan mengapa ada kebutuhan untuk pemeliharaan. Kategori pemeliharaan perangkat lunak penting untuk memahami makna yang mendasarinya. 

1.1. Definisi dan Terminologi 
Perawatan perangkat lunak didefinisikan dalam Standar IEEE untuk Pemeliharaan perangkat lunak, IEEE 1219, sebagai modifikasi produk perangkat lunak setelah pengiriman untuk kesalahan yang benar, untuk meningkatkan performa atau atribut lainnya, atau untuk mengadaptasi produk untuk lingkungan dimodifikasi. Standar juga alamat kegiatan pemeliharaan sebelum pengiriman produk perangkat lunak, tetapi hanya dalam lampiran informasi standar. 

IEEE / EIA 12207 standar untuk siklus hidup perangkat lunak dasarnya menggambarkan proses pemeliharaan sebagai salah satu utama siklus proses kehidupan, dan menjelaskan pemeliharaan sebagai proses dari produk perangkat lunak mengalami "Modifikasi untuk kode dan dokumentasi terkait karena untuk masalah atau kebutuhan untuk perbaikan. Tujuannya adalah untuk memodifikasi produk perangkat lunak ada sambil melestarikan integritas. "ISO / IEC 14764, internasional standar untuk perawatan perangkat lunak, mendefinisikan perangkat lunak pemeliharaan dalam hal yang sama sebagai IEEE / EIA 12207 dan menekankan pra-pengiriman aspek pemeliharaan, perencanaan, misalnya. 

1.2. Sifat Pemeliharaan 
Pemeliharaan perangkat lunak menopang produk perangkat lunak sepanjang siklus hidup operasional. Modifikasi permintaan akan dicatat dan dilacak, dampak dari usulan perubahan ditentukan, kode dan perangkat lunak lainnya artefak dimodifikasi, pengujian dilakukan, dan versi baru dari produk perangkat lunak dirilis. Juga, pelatihan dan harian dukungan yang diberikan kepada pengguna. Pfleeger [Pfl01] menyatakan bahwa "Pemeliharaan memiliki lingkup yang lebih luas, dengan lebih untuk melacak dan kontrol "dari pembangunan.

Pemelihara didefinisikan oleh IEEE / EIA 12207 sebagai organisasi yang melakukan kegiatan pemeliharaan [IEEE12207.0-96]. Dalam KA ini, istilah kadang-kadang akan merujuk kepada individu yang melakukan kegiatan-kegiatan, kontras mereka dengan pengembang. 
IEEE / EIA 12207 mengidentifikasi kegiatan utama pemeliharaan perangkat lunak seperti: pelaksanaan proses; masalah dan analisis modifikasi, modifikasi 
implementasi; pemeliharaan review/penerimaan; migrasi; dan pensiun. Kegiatan ini dibahas dalam topik 3.2 Kegiatan Pemeliharaan. 

Pengelola dapat belajar dari pengetahuan pengembang dari perangkat lunak. Kontak dengan para pengembang dan awal keterlibatan pengelola membantu mengurangi usaha pemeliharaan. Dalam beberapa kasus, perangkat lunak insinyur tidak dapat dijangkau atau telah pindah ke lain tugas, yang menciptakan tantangan tambahan untuk  pengelola. Pemeliharaan harus mengambil produk dari pengembangan, kode, atau dokumentasi, misalnya, dan dukungan segera dan berkembang / memelihara mereka progresif selama siklus hidup perangkat lunak. 
Gambar Topik Pemeliharaan Perangkat Lunak
1.3. Kebutuhan Pemeliharaan 
Memperbaiki kesalahan Pemeliharaan diperlukan untuk memastikan bahwa perangkat lunak 
terus untuk memenuhi kebutuhan pengguna. Pemeliharaan. Memperbaiki desain berlaku untuk perangkat lunak yang dikembangkan menggunakan hidup perangkat lunak.Menerapkanperangkat tambahan Model siklus (misalnya, spiral). Sistem perubahan karena Antarmuka dengan sistem lain. 
Mengadaptasi program sehingga hardware yang berbeda, perangkat lunak, fitur sistem, dan telekomunikasi fasilitas dapat digunakan:
  • Migrasi perangkat lunak
  • Mempertahankan fungsi kontrol atas perangkat lunak  
  • Mempertahankan kontrol atas modifikasi perangkat lunak 
  • Menyempurnakan fungsi yang ada
  • Mencegah kinerja perangkat lunak dari tingkat yang rendah 

1.4. Mayoritas Biaya Pemeliharaan 
Pemeliharaan mengkonsumsi bagian terbesar dari siklus hidup perangkat lunak sumber daya keuangan. Sebuah persepsi umum perangkat lunak pemeliharaan adalah bahwa hal itu hanya perbaikan kesalahan. Namun, penelitian dan survei selama bertahun-tahun telah menunjukkan bahwa mayoritas, lebih dari 80%, dari upaya pemeliharaan perangkat lunak digunakan untuk non-korektif tindakan. Faktor-faktor yang mempengaruhi pemeliharaan sistem dapat membantu untuk mengandung biaya. Pfleeger menyajikan beberapa teknis dan non-teknis faktor yang mempengaruhi perangkat lunak biaya pemeliharaan, sebagai berikut: 
  • Jenisaplikasi 
  • Software baru 
  • Ketersediaan staf pemeliharaan perangkat lunak 
  • Rentang hidup perangkat lunak 
  • Karakteristik hardware 
  • Kualitas desain perangkat lunak, konstruksi, dokumentasi dan pengujian 

1.5. Evolusi Perangkat Lunak 
Perawatan perangkat lunak dan evolusi sistem pertama ditujukan pada tahun 1969. Selama periode dua puluh tahun, penelitiannya menyebabkan perumusan delapan "Hukum 
Evolusi ". Temuan utama meliputi fakta bahwa pemeliharaan perkembangan evolusi, dan bahwa keputusan pemeliharaan dibantu dengan memahami apa yang terjadi pada sistem (dan software) dari waktu ke waktu. Lain menyatakan bahwa pemeliharaan perkembangan lebih lanjut, kecuali bahwa ada masukan tambahan (atau kendala)-ada yang besar Perangkat lunak tidak pernah lengkap dan terus berkembang. Seperti berkembang, tumbuh lebih kompleks kecuali beberapa tindakan diambil untuk mengurangi kompleksitas ini. Karena perangkat lunak menunjukkan perilaku yang teratur dan tren, ini dapat diukur. Upaya untuk mengembangkan prediksi model memperkirakan usaha pemeliharaan telah dibuat, dan, sebagai hasilnya, alat manajemen berguna telah dikembangkan. 
1.6. Kategori Pemeliharaan                
Lientz & Swanson awalnya didefinisikan tiga kategori pemeliharaan: korektif, adaptif, dan perfektif. Definisi ini kemudian diperbarui dalam Standar Perangkat Lunak Rekayasa Perangkat Lunak-Pemeliharaan, ISO / IEC 14764 untuk memasukkan empat kategori, sebagai berikut: 
1.      Pemeliharaan korektif: modifikasi Reaktif dari produk perangkat lunak dilakukan setelah pengiriman untuk memperbaiki menemukan masalah 
2.      Pemeliharaan adaptif: Modifikasi perangkat lunak produk dilakukan setelah pengiriman untuk menyimpan perangkat lunak produk dapat digunakan dalam berubah atau mengubah lingkungan 
3.      Pemeliharaan perfektif: Modifikasi perangkat lunak produk setelah pengiriman untuk meningkatkan kinerja atau rawatan
4.      Pemeliharaan preventif: Modifikasi perangkat lunak produk setelah melahirkan untuk mendeteksi dan benar laten kesalahan dalam produk perangkat lunak sebelum mereka menjadi efektif kesalahan 
ISO / IEC 14764 mengklasifikasikan adaptif dan perfektif pemeliharaan perangkat tambahan. Hal ini juga kelompok-kelompok bersama pemeliharaan korektif dan preventif kategori ke koreksi kategori, seperti yang ditunjukkan pada Tabel 1. Software pemeliharaan, kategori terbaru, yang paling sering dilakukan pada produk perangkat lunak dimana keamanan sangat penting. 

Tabel Software katagori pemeliharaan

2. Isu kunci dalam Pemeliharaan Perangkat Lunak 
Sejumlah isu kunci harus ditangani untuk menjamin efektif pemeliharaan perangkat lunak. Hal ini penting untuk memahami bahwa pemeliharaan perangkat lunak menyediakan unik teknis dan manajemen tantangan untuk perangkat lunak. Mencoba untuk menemukan kesalahan dalam perangkat lunak berisi 500K baris kode bahwa insinyur perangkat lunak tidak 
mengembangkan adalah contoh yang baik. Demikian pula, bersaing dengan pengembang perangkat lunak untuk sumber daya adalah pertempuran konstan. Perencanaan untuk masa mendatang, sementara coding rilis berikutnya dan mengirimkan patch darurat untuk rilis saat ini, juga menciptakan tantangan. Bagian berikut menyajikan beberapa isu teknis dan manajemen yang terkait dengan pemeliharaan perangkat lunak. Mereka telah dikelompokkan di bawah berikut judul topik: 
  • Masalah teknis 
  • Manajemen masalah 
  • Biaya estimasi dan 
  • Tindakan 

2.1. Masalah Teknis 
2.1.1. Keterbatasan pemahaman 
Pemahaman yang terbatas mengacu pada seberapa cepat perangkat lunak insinyur dapat memahami mana untuk membuat perubahan atau koreksi dalam perangkat lunak yang individu ini tidak berkembang. Penelitian menunjukkan bahwa beberapa% 40 sampai 60% dari usaha pemeliharaan dikhususkan untuk memahami perangkat lunak harus dimodifikasi. Jadi, topik dari perangkat lunak pemahaman adalah kepentingan besar untuk insinyur perangkat lunak. Pemahaman lebih sulit dalam teks yang berorientasi representasi, dalam kode sumber, misalnya, di mana ia seringkali sulit untuk melacak evolusi dari perangkat lunak melalui nya rilis / versi jika perubahan tidak didokumentasikan dan ketika para pengembang tidak tersedia untuk menjelaskannya.
2.1.2. Pengujian 
Biaya mengulangi pengujian penuh pada sepotong utama perangkat lunak dapat menjadi signifikan dalam hal waktu dan uang. Regresi pengujian, pengujian ulang selektif perangkat lunak atau komponen untuk memverifikasi bahwa modifikasi tidak menimbulkan efek yang tidak diinginkan adalah penting untuk pemeliharaan. Selain itu, 
mencari waktu untuk menguji sering sulit. Ada juga tantangan tes koordinasi ketika anggota yang berbeda tim pemeliharaan bekerja pada masalah yang berbeda pada waktu yang sama. Ketika perangkat lunak melakukan kritis fungsi, mungkin mustahil untuk membawa secara offline untuk menguji. KA Pengujian Software menyediakan informasi tambahan dan referensi tentang masalah ini di sub-topik nya 2.2.6 Pengujian regresi. 

2.1.3. Dampak analisis 
Dampak Analisi menjelaskan bagaimana melakukan, biaya efektif, analisis lengkap dari dampak perubahan yang ada perangkat lunak. Pengelola harus memiliki pengetahuan yang mendalam struktur perangkat lunak dan konten. Mereka menggunakan pengetahuan untuk melakukan dampak analisis, yang mengidentifikasi semua sistem dan produk perangkat lunak dipengaruhi oleh permintaan perubahan perangkat lunak dan mengembangkan perkiraan sumber daya yang dibutuhkan untuk mencapai perubahan. Selain itu, risiko membuat perubahan ditentukan. Permintaan perubahan, kadang-kadang disebut modifikasi permintaan (MR) dan sering disebut laporan masalah (PR), harus pertama dianalisis dan diterjemahkan ke dalam istilah perangkat lunak. Hal ini dilakukan setelah permintaan perubahan memasuki konfigurasi perangkat lunak manajemen proses. Arthur menyatakan bahwa tujuan dari analisis dampak adalah: 
·         Penentuan ruang lingkup perubahan dalam rangka merencanakan dan melaksanakan pekerjaan 
·         Pengembangan sumber daya perkiraan yang akurat dibutuhkan untuk melakukan pekerjaan 
·         Analisis biaya / manfaat dari perubahan yang diminta 
·         Komunikasi kepada orang lain dari kompleksitas suatu diberikan perubahan 
Tingkat keparahan masalah adalah sering digunakan untuk memutuskan bagaimana dan ketika masalah akan diperbaiki. 
 2.1.4. Maintainability 
Bagaimana seseorang mempromosikan dan menindaklanjuti rawatan masalah selama pembangunan? IEEE [IEEE610.12-90] mendefinisikan rawatan sebagai kemudahan yang perangkat lunak dapat dipertahankan, ditingkatkan, disesuaikan, atau diperbaiki untuk memenuhi persyaratan yang ditentukan. ISO / IEC mendefinisikan rawatan sebagai salah satu karakteristik kualitas (ISO9126-01). 
Rawatan sub-karakteristik harus ditentukan, Ulasan, dan dikontrol selama pengembangan perangkat lunak dalam rangka untuk mengurangi biaya pemeliharaan. Jika hal ini berhasil dilakukan, maka pemeliharaan perangkat lunak akan meningkatkan. Hal ini sering sulit dicapai karena rawatan sub-karakteristik yang penting bukan fokus selama proses pengembangan perangkat lunak. Para pengembang disibukan dengan hal lain dan sering mengabaikan persyaratan pengelola itu. Hal ini pada gilirannya dapat, dan sering,mengakibatkan kurangnya sistem dokumentasi, yang merupakan penyebab utama kesulitan dalam Program pemahaman dan dampak analisis. Hal ini juga telah diamati bahwa kehadiran sistematis dan matang 
2.2. Isu manajemen 
2.2.1. Keselarasan dengan tujuan organisasi 
Tujuan organisasi menjelaskan bagaimana untuk menunjukkan pengembalian investasi kegiatan pemeliharaan perangkat lunak. Bennett menyatakan bahwa pengembangan perangkat lunak "awal biasanya berbasis proyek, dengan skala waktu yang ditetapkan dan anggaran. Penekanan utama adalah untuk memberikan tepat waktu dan sesuai anggaran untuk memenuhi kebutuhan pengguna. Sebaliknya, pemeliharaan perangkat lunak sering memiliki tujuan memperpanjang hidup perangkat lunak selama mungkin. Selain itu, mungkin didorong oleh kebutuhan untuk memenuhi permintaan pengguna untuk pembaruan perangkat lunak dan perangkat tambahan. Dalam kedua kasus, laba atas investasi jauh lebih sedikit yang jelas, sehingga tampilan pada tingkat manajemen senior sering dari kegiatan utama mengkonsumsi sumber daya yang signifikan tanpa jelas diukur manfaat bagi organisasi”
2.2.2. Staffing 
Staf mengacu pada bagaimana untuk menarik dan menjaga perangkat lunak. Pemeliharaan sering tidak dipandang sebagai glamor bekerja. Deklava menyediakan daftar staf yang terkait masalah berdasarkan data survei. Sebagai hasilnya, personil pemeliharaan perangkat lunak sering dipandang sebagai "Warga negara kelas dua" dan moral sehingga menderita. 
2.2.3. Proses 
Proses perangkat lunak adalah serangkaian kegiatan, metode, praktek, dan transformasi yang digunakan orang untuk mengembangkan dan memelihara perangkat lunak dan produk terkait. Pada tingkat proses, pemeliharaan perangkat lunak kegiatan berbagi banyak kesamaan dengan pengembangan perangkat lunak (misalnya, perangkat lunak manajemen konfigurasi adalah kegiatan penting dalam keduanya). Pemeliharaan juga membutuhkan beberapa kegiatan yang tidak ditemukan dalam pengembangan perangkat lunak.

3,2 Rincian pada kegiatan yang unik). 
Kegiatan-kegiatan ini tantangan bagi manajemen.
2.2.4. Organisasi aspek pemeliharaan 
Aspek organisasi menjelaskan bagaimana untuk mengidentifikasi organisasi dan / atau fungsi akan bertanggung jawab untuk pemeliharaan perangkat lunak. Tim yang mengembangkan perangkat lunak tidak selalu ditugaskan untuk menjaga perangkat lunak setelah itu operasional. 

2.2.5. Outsourcing 
Outsourcing pemeliharaan menjadi industri besar. Perusahaan-perusahaan besar yang outsourcing seluruh portofolio perangkat lunak sistem, termasuk pemeliharaan perangkat lunak. Seringkali, pilihan outsourcing kurang misi- perangkat lunak penting, sebagai perusahaan tidak mau kehilangan kendali dari software yang digunakan dalam bisnis inti mereka. Carey mengatakan bahwa beberapa akan outsource hanya jika mereka dapat menemukan cara-cara mempertahankan pengendalian strategis. Namun, kontrol langkah-langkah sulit untuk menemukan. Salah satu tantangan utama bagi agen outsourcing adalah untuk menentukan lingkup jasa pemeliharaan yang diperlukan dan rincian kontrak. McCracken (McC02) menyatakan bahwa 50% dari agen outsourcing memberikan pelayanan tanpa perjanjian tingkat layanan yang jelas. Outsourcing perusahaan biasanya menghabiskan sejumlah bulan menilai perangkat lunak sebelum mereka akan masuk ke dalam hubungan kontrak. [Dor02] Tantangan lain diidentifikasi adalah transisi dari perangkat lunak untuk pemasang iklan. 
2.3. Estimasi Biaya Pemeliharaan 
Insinyur perangkat lunak harus memahami yang berbeda kategori pemeliharaan perangkat lunak, hal di atas, Untuk menjawab pertanyaan memperkirakan biaya pemeliharaan perangkat lunak. Untuk tujuan perencanaan, memperkirakan biaya aspek penting dari perawatan perangkat lunak. 
2.3.1. Biaya estimasi 
Hal itu disebutkan dalam sub-topik 2.1.3, Bahwa Dampak Analisis dapat mengidentifikasi semua sistem dan produk perangkat lunak dipengaruhi oleh permintaan perubahan perangkat lunak dan mengembangkan sebuah estimasi sumber daya yang dibutuhkan untuk mencapai perubahan itu. 
2.3.2. Model Parametrik 
Beberapa pekerjaan telah dilakukan dalam menerapkan parametrik Biaya pemodelan untuk perawatan perangkat lunak. Dari signifikansi adalah bahwa data dari proyek lampau adalah diperlukan dalam untuk menggunakan model. Jones [Jon98] membahas semua aspek memperkirakan biaya, termasuk fungsi poin (IEEE14143.1-00), dan memberikan sebuah bab rinci tentang pemeliharaan estimasi. 

2.3.3. Pengalaman 
Pengalaman, dalam bentuk penilaian ahli (menggunakan Teknik Delphi, misalnya), analogi, dan bekerja struktur breakdown, beberapa pendekatan yang harus digunakan untuk menambah data dari model parametrik. Jelas pendekatan yang terbaik untuk estimasi pemeliharaan untuk menggabungkan data empiris dan pengalaman. Data ini harus disediakan sebagai hasil dari program pengukuran. 

2.4. Pemeliharaan Perangkat Lunak Pengukuran 
Grady dan Caswell membahas pembentukan perusahaan-lebar pengukuran perangkat lunak program, di mana bentuk pengukuran perangkat lunak pemeliharaan dan data koleksi dijelaskan. Perangkat Lunak Praktis dan Sistem Pengukuran (PSM) proyek menjelaskan masalah mendukung pengukuran proses yang digunakan oleh banyak organisasi dan sangat praktis. 
Ada perangkat lunak langkah-langkah yang umum untuk semua usaha, kategori berikut mana Piranti Lunak Rekayasa Institute (SEI) telah mengidentifikasi: ukuran; usaha; jadwal, dan kualitas. Langkah-langkah ini merupakan titik awal yang baik untuk pengelola. Diskusi 
proses dan produk pengukuran disajikan dalam Perangkat Lunak Rekayasa Proses KA. Perangkat lunak program pengukuran dijelaskan dalam Perangkat Lunak 
Manajemen Rekayasa KA. 
2.4.1. Tindakan Tertentu 
Untuk menyajikan teknik pembandingan internal yang untuk membandingkan organisasi yang berbeda pemeliharaan internal. Pengelola harus menentukan langkah-langkah yang sesuai untuk organisasi yang bersangkutan. [IEEE121998; ISO9126-01; Sta94] menunjukkan langkah-langkah yang lebih khusus untuk program pengukuran perangkat lunak pemeliharaan. 
Daftar yang mencakup sejumlah langkah untuk masing-masing dari empat sub-karakteristik rawatan: 
  • Dianalisis: Ukuran upaya pemelihara atau sumber daya dikeluarkan dalam mencoba untuk mendiagnosa kekurangan atau penyebab kegagalan, atau dalam mengidentifikasi bagian yang akan dimodifikasi 
  •  Berubah-ubah: Ukuran usaha pengelola itu terkait dengan menerapkan tertentu modifikasi 
  • Stabilitas: Ukuran perilaku tak terduga perangkat lunak, termasuk yang ditemui selama pengujian 
  • Testability: Ukuran pengelola dan pengguna ' upaya dalam mencoba untuk menguji perangkat lunak dimodifikasi Tindakan tertentu dari pemeliharaan perangkat lunak dapat diperoleh dengan menggunakan alat komersial yang tersedia. 

3. Proses Pemeliharaan 
Para subarea Proses Pemeliharaan menyediakan referensi dan standar yang digunakan untuk menerapkan perawatan perangkat lunak proses. Pemeliharaan Kegiatan topik membedakan pemeliharaan dari pengembangan dan menunjukkan hubungannya kegiatan rekayasa perangkat lunak lain. 
Kebutuhan untuk proses rekayasa perangkat lunak baik didokumentasikan. CMMI £ model berlaku untuk perangkat lunak pemeliharaan proses, dan mirip dengan pengembang' 
proses. [SEI01] Software Kemampuan Pemeliharaan Kematangan model yang mengatasi proses unik dari pemeliharaan perangkat lunak yang dijelaskan dalam (Apr03, Nie02, Kaj01). 
3.1. Proses Pemeliharaan 
Proses pemeliharaan menyediakan kegiatan yang diperlukan dan input rinci / output untuk kegiatan-kegiatan, dan dijelaskan dalam pemeliharaan perangkat lunak standar IEEE 1219 dan ISO / IEC 14764. 
Proses pemeliharaan model yang digambarkan dalam Standar untuk Pemeliharaan Perangkat Lunak (IEEE1219) dimulai dengan pemeliharaan perangkat lunak upaya selama tahap pasca-pengiriman dan membahas item seperti perencanaan untuk pemeliharaan. Itu proses digambarkan dalam Gambar 2. 
Gambar 2. Proses Perbaikan/Pemeliharaan
3.2. Pemeliharaan Kegiatan 
Seperti telah dicatat, kegiatan pemeliharaan banyak yang serupa kepada mereka dari pengembangan perangkat lunak. Pengelola melakukan analisis, desain, coding, pengujian, dan dokumentasi. Mereka harus melacak persyaratan dalam kegiatan mereka seperti yangdilakukan  di pengembangan, dan update dokumentasi sebagai acuan dasar perubahan. ISO/IEC14764 merekomendasikan bahwa, ketika pemelihara mengacu pada proses perkembangan yang sama, ia harus beradaptasi untuk memenuhi kebutuhan spesifik nya [ISO14764-99: s8.3.2.1, 2]. Namun, untuk perawatan perangkat lunak, beberapa kegiatan melibatkan proses unik untuk perawatan perangkat lunak. 
3.2.1. Unik kegiatan 
Ada sejumlah proses, kegiatan, dan praktek yang unik untuk perawatan perangkat lunak, misalnya: 
  • Transisi: urutan terkontrol dan terkoordinasi kegiatan selama perangkat lunak mana yang ditransfer progresif dari pengembang untuk pengelola 
  • Permintaan Modifikasi Penerimaan / Penolakan: permintaan modifikasi bekerja melalui tertentu Ukuran / usaha / kompleksitas mungkin ditolak oleh pengelola dan dialihkan untuk pengembang
  • Permintaan Modifikasi dan Bantuan Masalah Laporan Desk: akhir-pengguna mendukung fungsi yang memicu penilaian, prioritas, dan biaya dari modifikasi permintaan
  • Dampak Analisis
  • Dukungan Perangkat Lunak: bantuan dan saran kepada pengguna tentang permintaan untuk informasi (misalnya, aturan bisnis, validasi, berarti data dan ad-hoc 
    permintaan / laporan)
  • Service Level Agreements (SLA) dan khusus (Domain-spesifik) kontrak pemeliharaan yang tanggung jawab dari pengelola
3.2.2. Mendukung kegiatan 
Pengelola juga dapat melakukan kegiatan pendukung, seperti pemeliharaan perangkat lunak perencanaan, konfigurasi perangkat lunak manajemen, verifikasi dan validasi, kualitas perangkat lunak jaminan, review, audit, dan pelatihan pengguna. 


3.2.3. Perencanaan kegiatan pemeliharaan 
Salah satu kegiatan penting untuk perawatan perangkat lunak adalah perencanaan, dan pengelola harus mengatasi masalah yang terkait dengan sejumlah perencanaan perspektif: 
  • Perencanaan bisnis (tingkat organisasi) 
  • Perencanaan pemeliharaan (tingkat transisi) 
  • Rilis / versi perencanaan (tingkat perangkat lunak) 
  • Perangkat lunak individu permintaan perubahan perencanaan (Tingkat permintaan) 
    Pada tingkat permintaan individu, perencanaan dilakukan selama analisis dampak (lihat sub-topik Dampak 2.1.3 Analisis untuk rincian). Kegiatan perencanaan rilis / versi 
    mensyaratkan bahwa pengelola
  • Kumpulkan tanggal ketersediaan individu permintaan 
  • Setuju dengan pengguna pada konten berikutnya rilis / versi 
  • Mengidentifikasi potensi konflik dan mengembangkan alternatif 
  • Menilai risiko rilis yang diberikan dan mengembangkan back-rencana dalam masalah kasus harus muncul 
  • Menginformasikan seluruh stakeholder 

3.2.4. Manajemen konfigurasi perangkat lunak 
Standar IEEE untuk Pemeliharaan Perangkat Lunak, IEEE 1219 [IEEE1219-98], menjelaskan konfigurasi perangkat lunak manajemen sebagai elemen penting dari pemeliharaan proses. Manajemen konfigurasi perangkat lunak prosedur harus menyediakan untuk verifikasi, validasi, dan audit setiap langkah yang diperlukan untuk mengidentifikasi, otorisasi, menerapkan, dan rilis produk perangkat lunak. 
Hal ini tidak cukup untuk sekedar melacak Permintaan Modifikasi atau Soal Laporan. Produk perangkat lunak dan setiap perubahan dibuat untuk itu harus dikontrol. Kontrol ini didirikan oleh melaksanakan dan menegakkan perangkat lunak yang disetujui manajemen konfigurasi (SCM) proses. Perangkat Lunak Manajemen Konfigurasi KA memberikan rincian SCM dan membahas proses dimana mengubah perangkat lunak permintaan diajukan, dievaluasi, dan disetujui. SCM untuk pemeliharaan perangkat lunak yang berbeda dari SCM untuk perangkat lunak. 

3.2.5. Kualitas perangkat lunak 
Hal ini tidak cukup, baik, hanya berharap bahwa peningkatan berkualitas akan hasil dari pemeliharaan perangkat lunak. Ini harus direncanakan dan proses dilaksanakan untuk mendukung proses pemeliharaan. Kegiatan dan teknik untuk Jaminan Kualitas Perangkat Lunak (SQA), V & V, review, dan audit harus dipilih dalam konser dengan semua yang lain 
proses untuk mencapai tingkat kualitas yang diinginkan. Hal ini juga merekomendasikan bahwa pengelola beradaptasi perangkat lunak pengembangan proses, teknik dan kiriman. Misalnya untuk pengujian dokumentasi, dan hasil tes. 

4. Teknik Pemeliharaan 
Subarea ini memperkenalkan beberapa pada umumnya diterima teknik yang digunakan dalam perawatan perangkat lunak. 
4.1.            Pemahaman Program 
Programer menghabiskan waktu yang cukup dalam membaca dan pemahaman program-program dalam rangka untuk melaksanakan perubahan. Kode browser adalah alat kunci untuk pemahaman program.
 4.2. Reengineering 
 Reengineering didefinisikan sebagai pemeriksaan dan perubahan perangkat lunak untuk menyusun kembali dalam bentuk baru, dan termasuk pelaksanaan berikutnya dari bentuk baru. Dorfman dan Thayer menyatakan bahwa rekayasa ulang adalah yang paling radikal (dan mahal) bentuk perubahan. Lain percaya rekayasa ulang yang dapat digunakan untuk perubahan kecil. Hal ini sering tidak dilakukan untuk meningkatkan rawatan, tetapi untuk menggantikan penuaan perangkat lunak warisan. Arnold menyediakan Kompendium komprehensif topik, misalnya: konsep, alat dan teknik, studi kasus, dan risiko serta manfaat yang terkait dengan rekayasa ulang. 
4.3. Reverse engineering 
Reverse engineering adalah proses menganalisis perangkat lunak untuk mengidentifikasi komponen-komponen perangkat lunak dan antar hubungan mereka dan menciptakan representasi dari perangkat lunak dalam bentuk lain atau pada tingkat lebih tinggi dari abstraksi. Terbalik rekayasa pasif; tidak mengubah perangkat lunak, atau menghasilkan perangkat lunak baru. Upaya reverse engineering menghasilkan panggilan grafik dan grafik kontrol aliran dari kode sumber. Satu jenis reverse engineering redocumentation. Lain 
jenis pemulihan desain. Refactoring adalah program transformasi yang mereorganisasi program tanpa mengubah perilakunya, dan merupakan bentuk reverse engineering yang bertujuan untuk memperbaiki struktur program.