Pemeliharaan Software (Software Maintenance)

Definisi


modifikasi produk software setelah di reales untuk:

 

memperbaiki kesalahan (faults), untuk meningkatkan performa atau atribut lainnya (reliable, maintainable, ), adaptasi produk software terhadap lingkungan baru. (IEEE)

Slide: 2

Alasan kesulitan pemeliharaan SW



Rendahnya kualitas software yang berjalan (yang sudah ada). Sistem tidak dirancang untuk memperhatikan konsep pemeliharaan Pemeliharaan bukan merupakan bagian yang dirasakan perlu pada suatu SW
Slide: 3

Spiral maintenance model

Specification Start
Release 1

Implemention

Operation
Release 2 Release 3

Validation

Slide: 4

Sistem Software saat kini bisa lebih mudah berubah volatile daripada sebelumnya


Mencerminkan perubahan lingkungan bisnis yang cepat Menekankan pada pengembangan metode yang baru:
   

Faktor-faktor peningkatan Pendekatan iterasi Model evolutionary Memiliki Biological paradigm bukan assembly line paradigm
Slide: 5

Saran untuk peningkatan

  

 

Merancang agar SW bisa terpelihara Mengukur kompleksitas Mengimplementasikan procedure management perubahan (SCM) Meningkatkan kemampuan staff Menambah tool pemeliharaan dan metrics

Slide: 6

Permasalah yang ada?

Pemeliharaan SW membutuhkan 50-80% dari total biaya pembuatannya Biaya pemeliharaan SW di seluruh dunia diperkirakan mencapai $30 billion Masih sedikit penelitan yang mengarah ke pemeliharaan software

Slide: 7

Microsoft Windows NT


Growth of Windows NT
35

Lines of Code (m illions)

30 juta baris code ditambahkan selama 6 tahun

30 25 20 15 10 5 0

WINDOWS 2000

Telecom switch software  5.2 juta modifikasi sepanjang satu dekade Web-based applications  73% dari biaya pembuatan ecommerce digunakan untuk re-design web site setelah implementasi pertama

WINDOWS NT 4.0 WINDOWS NT 3.51 WINDOWS NT 3.5 WINDOWS NT 3.1

1992

1993

1994

1995

1996

1997

1998

1999

2000

Year

Slide: 8

Kategori pemeliharaan SW


Corrective maintenance


perubahan yang dilakukan guna memperbaiki kesalahan Perawatan berdasarkan perubahan lingkungan Perubahan untuk meningkatkan kualitas sistem tanpa merubah fungsinya Meningkatkan reliability, future maintainability, future enhancement (reverse engineering dan reengineering)
Slide: 9

Adaptive maintenance


Perfective maintenance


Preventive maintenance


Proporsi kategori pemeliharaan SW

Corrective maintenance (17%)

Adaptive maintenance (18%) Lientz and Swanson (1980)

Perfective Maintenance (65%)

Slide: 10

Proses Pemeliharaan

Change request

Impact analysis

System Release planning

Change implementation

System release

Perfective maintenance

Adaptive maintenance

Corrective maintenance

Slide: 11

Karakteristik Pemeliharaan SW


Aktivitas pada fase pemeliharaan dan dampak pendekatan software engineering untuk keberhasilan aktifitas tersebut. Biaya untuk fase pemeliharaan software. Masalah yang sering dijumpai ketika prosees pemeliharaan software.
Slide: 12

Permintaan perubahan


Perubahan yang diminta oleh users, customers atau management Pada kenyataannya, semua perubahan memerlukan analisis yg hati-hati Pada kenyataan, perubahan SW dirasakan perlu untuk  Memperbaiki kesalahan  Perubahan system s environment  Urgently required business changes
Slide: 13

Structured vs. unstructured pemeliharaan SW

software
Evaluation design Plan approach
? Configuration

code
Evaluation code

Modify design Recode

Review

Recode
Review

Test and Release

Slide: 14

Biaya Pemeliharaan


Biaya yang dikeluarkan untuk melakukan pemeliharaan software yang bisa mencapai 80% dari total biaya pembuatan software.

M = p + Ke (c-d)
M = total usaha yang dikeluarkan untuk pemeliharaan p = productivity effort K = empirical constant c = pengukuran kompliksitas yang bisa berdasarkan kekurangan terhadap perancangan yang baik dan kokumentasi yang baik d = derajat familiarty software
Slide: 15

Permasalahan yang ada

 

   

Kesulitan melakukan pelacakan evolusi software pd versi sebelumnya, Kesulitan pelacakan pada proses pengembangan software, Sulit untuk mengerti program orang lain, Tidak adanya dokumentasi yang baik, Tidak adanya nara sumber, Kebanyakan software dirancang tanpa adanya pemikiran untuk diubah
Slide: 16

Software Evolution
Initial development first running version


evolution changes

evolution is key part of lifecycle

Evolution

loss of evolvability servicing patches

Servicing

servicing discontinued Phase-out Switch-off Close-down

Slide: 17

Alasan evolusi SW


Memperbaiki dan menajamkan requirement



Beberapa requirement yang ditemukan pada tahap inisial pengemebangan SW.

 

Perubahan pada lingkungan operasi Iterasi pengembangan SW



Menambahkan satu fitur pada satu saat, membaca resiko pada integrasi sistem Pengiriman yang cepat untuk versi yang kecil

Slide: 18

Contoh: A tale of two systems evolution

Financial System Shipping System
Age (years) Size in Total Lines of Code (LOC) Size in Function Points (FP) Number of Modules % of Online Modules % of Batch Modules Average Module Size (LOC) 20 181,652 1,321 109 7% 93% 1,666 10 189,999 1,446 45 62% 38% 3,878
Slide: 19

Pendefinisian pengukuran software evolution



Amplitude = ukuran modifikasi software Periodicity = interval waktu antara perubahan Deviation = variability panjang interval waktu

md a n o ific tio s

time

md o ifica n tio s

time

Slide: 20

Slide: 21

Slide: 22

Kategori pengukuran evolusi software

Kategori I Amplitude Rendah Periodik Panjang II Rendah Rendah Rendah Tinggi Panjang Deviation Deskripsi Rendah Sangat sedikit berubah: modifikisi kecil yang jarang muncul pada suatu model yang well-behaved. Tinggi Modifikasi kecil yang akdang terjadi dengan variansi behavior sistem program yang lebar Rendah Modifikasi kecil yang konstan occurring muncul di suatu madel yang baik (well-behaved) Tinggi Modifikasi kecil yang konstan dengan variansi behavior sistem program yang lebar. Rendah Modifikasi besar yang jarang muncul di suatu model yang baik (well-behaved) Tinggi Modifikasi besar yang jarang muncul dengan variansi behavior sistem program yang lebar Rendah Modifikasi besar yang konstan muncul di suatu model yang baik (well-behaved) Tinggi Sangat mudah berubah: Most volatile: modifikasi besar dengan variansi behavior sistem program yang lebar

III

Pendek

IV

Pendek

Panjang

VI

Tinggi

Panjang

VII

Tinggi

Pendek

VIII

Tinggi

Pendek

Slide: 23

Software Re-engineering


Reorganisasi dan modifikasi sistem software agar bisa dipelihara (maintainable)

Slide: 24

Re-engineering Sistem


Restrukturisasi atau penulisan ulang suatu sistem tanpa merubah fungsionalitasnya, Dapat diaplikasikan kalau beberapa (bukan keseluruhan) sub-system dari suatu sistem yang besar sering memerlukan perawatan, Memerlukan effort tambahan untuk memudahkan perawatan. Sistem mungkin di re-strukturisasi atau re-dokumentasi

Slide: 25

Kapan melakukan Re-engineering



Kalau perubahan sistem kebanyakan dilakukan pada bagian sistem maka dilakukan re-engineering pd bagian tesebut Ketergantungan terhadap dukungan hardware/software yang penting Jika ada dukungan tools untuk restrukturisasi.
Slide: 26

Keuntungan melakukan Reengineering SW



Mengurangi risiko


Adanya risiko yang tinggi pada pengembangan softwarebaru. (yaitu masalah pengembangan, staff, dan spesisfikasi). Biaya re-engineering secara signifikan lebih kecil dari dari biaya pembuatan software baru
Slide: 27

Mengurangi biaya


Business process re-engineering



Konsentrasi pada proses re-disian bisnis agar lebih responsive dan efficient Bergantung pada sistem komputer baru untuk mendukung proses perbaikan Software re-engineering didisain untuk mendukung proses yang ada

Slide: 28

Forward engineering dan reengineering

System specification Forward engineering Existing software system Software re-engineering Understanding and transformation Re-engineered system Design and implementation New system

Slide: 29

Proses re-engineering
Original program Reverse engineering Source code translation Program structure improvement Structured program Reengineered data Program modularisation Data reengineering Program documentation Modularised program Original data

Slide: 30

Faktor biaya Re-engineering



 

Kualitas software yang akan di reengineered Fasilitas pendukung yang tersedia untuk proses re-engineering Besarnya konversi data yang diperlukan Adanya staff yang ahli untuk proses reengineering
Slide: 31

Pendekatan Re-engineering
Automated program restructuring Program and data restructuring

Automated source code conversion

Automated restructuring with manual changes

Restructuring plus architectural changes

Increased cost

Slide: 32

Source code translation

 

Melibatkan konversi code dari satu bahasa pemrograman ke yang lain mis.: COBOL ke C++ Diperlukan karena:  Perubahan Hardware platform  Kemampuan Staff yang kurangan  Perubahan kebijakan Organisational Akan realisitis jika translate dilakukan sec. Otomatis.

Slide: 33

Proses translate Program

System to be re-engineered System to be re-engineered Re-engineered system

Identify source code differences

Design translator instructions

Automatically translate code

Manually translate code

Slide: 34

Reverse engineering


Menganalisa software untuk mengerti disain dan spesifikasi SW. Bisa merupakan bagian proses re-engineering tetapi dapat juga digunakan untuk melakukan spesifikasi ulang dalam re-implementasi sistem. Dapat menggunakan Program understanding tools (browsers, cross-reference generators, dll.)
Slide: 35

Proses reverse engineering

Program stucture diagrams System information store Manual annotation Document generation Data stucture diagrams Traceability matrices

Automated analysis System to be re-engineered

Slide: 36

Reverse engineering


Reverse engineering sering diawali oleh reengineering tapi dapat juga di keseluruhan proses reverse engineering itu sendiri  Disain dan specification system dapat di-reverseengineered sehingga bisa dijadikan sebagai input ke requirements specification process untuk penggantian system (system s replacement)  Disain dan specification dapat di-reverseengineered untuk mendukung pemeliharaan program
Slide: 37

Meningkatkan struktur program



Program direstrukturisasi secara otomatis untuk menghilangkan cabang non-kondisi. Statement kondisi disederhanakan sehingga mudah dibaca.

Slide: 38

Spaghetti logic
Start: Get (Time-on, Time-off, Time, Setting, Temp, Switch) if Switch = off goto off if Switch = on goto on goto Cntrld off: if Heating-status = on goto Sw-off goto loop on: if Heating-status = off goto Sw-on goto loop Cntrld: if Time = Time-on goto on if Time = Time-off goto off if Time < Time-on goto Start if Time > Time-off goto Start if Temp > Setting then goto off if Temp < Setting then goto on Sw-off: Heating-status := off goto Switch Sw-on: Heating-status := on Switch: Switch-heating loop: goto Start

Slide: 39

Kontrol logic terstruktur

loop -- The Get statement finds values for the given variables from the systems -- environment. Get (Time-on, Time-off, Time, Setting, Temp, Switch) ; case Switch of when On => if Heating-status = off then Switch-heating ; Heating-status := on ; end if ; when Off => if Heating-status = on then Switch-heating ; Heating-status := off ; end if; when Controlled => if Time >= Time-on and Time < = Time-off then if Temp > Setting and Heating-status = on then Switch-heating; Heating-status = off; elsif Temp < Setting and Heating-status = off then Switch-heating; Heating-status := on ; end if; end if ; end case ; end loop ;
Slide: 40

Contoh penyederhanaan suatu kondisi

-- Kondisi yang kompleks if not (A > B and (C < D or not ( E > F) ) )... --Kondisi yang sederhana if (A <= B and (C>= D or E > F)...

Slide: 41

Restrukturisasi program yang otomatis

Program to be restructured Analyser and graph builder Graph representation Program generator Restructured program

Slide: 42

Masalah pada restrukturisasi



Masalah restrukturisasi :  Kehilangan documentasi  Kebutuhan akan komputasi yang tinggi Restrukturisasi tidak bisa membantu pada sistem yang memiliki kelemahan modularisainya yaitu komponen-komponen yg terkait terseber di seluruh code.

Slide: 43

Modularitas Program
Proses re-organisasi suatu program sehingga program yang berkaitan terkumpul menjadi satu module.  Biasanya dilakukan secara manual pada inspeksi program dan reorganisasi


Slide: 44

Tipe-tipe Modul


Abstraksi Data  Abstract data type untuk pengelompokkan data structures dan operasinya Hardware modules  Fungsi yang diperliukan untuk interface dg hardware (driver). Functional modules  Module terdiri dari fungsi-fungsi yang memiliki tugas yang saling terkait. Process support modules  Modules yang berfungsi mendukung proses bisnis
Slide: 45

Recovering data abstractions



Many legacy systems use shared tables and global data to save memory space Causes problems because changes have a wide impact in the system Shared global data may be converted to objects or ADTs
  

Analyse common data areas to identify logical abstractions Create an ADT or object for these abstractions Use a browser to find all data references and replace with reference to the data abstraction

Slide: 46

Data re-engineering


Involves analysing and reorganising the data structures (and sometimes the data values) in a program May be part of the process of migrating from a file-based system to a DBMSbased system or changing from one DBMS to another Objective is to create a managed data environment
Slide: 47

Pendekatan untuk data reengineering

Approach Data cleanup Description The data records and values are analysed to improve their quality. Duplicates are removed, redundant information is deleted and a consistent format applied to all records. This should not normally require any associated program changes. In this case, the data and associated programs are re-engineered to remove limits on the data processing. This may require changes to programs to increase field lengths, modify upper limits on the tables, etc. The data itself may then have to be rewritten and cleaned up to reflect the program changes. In this case, data is moved into the control of a modern database management system. The data may be stored in separate files or may be managed by an older type of DBMS.

Data extension

Data migration

Slide: 48

Data problems


End-users want data on their desktop machines rather than in a file system. They need to be able to download this data from a DBMS Systems may have to process much more data than was originally intended by their designers Redundant data may be stored in different formats in different places in the system
Slide: 49

Program 1

Program 2

Program 3

File 1

File 2

File 3

File 4

File 5

File 6

Program 4

Program 5

Program 6

Program 7

Becomes

Program 3

Program 4

Program 5

Program 6

Program 2

Program 7

Program 1

Database management system

describes

Logical and physical data models

Data migration
Slide: 50

Data problems


 

Data naming problems  Names may be hard to understand. The same data may have different names in different programs Field length problems  The same item may be assigned different lengths in different programs Record organisation problems  Records representing the same entity may be organised differently in different programs Hard-coded literals No data dictionary

Slide: 51

Data value inconsistencies

Data inconsistency Inconsistent default values Description Different programs assign different default values to the same logical data items. This causes problems for programs other than those that created the data. The problem is compounded when missing values are assigned a default value that is valid. The missing data cannot then be discovered. The same information is represented in different units in different programs. For example, in the US or the UK, weight data may be represented in pounds in older programs but in kilograms in more recent systems. A major problem of this type has arisen in Europe with the introduction of a single European currency. Legacy systems have been written to deal with national currency units and data has to be converted to euros. Different programs apply different data validation rules. Data written by one program may be rejected by another. This is a particular problem for archival data which may not have been updated in line with changes to data validation rules. Programs assume some meaning in the way items are represented. For example, some programs may assume that upper-case text means an address. Programs may use different conventions and may therefore reject data which is semantically valid. Some programs reject negative values for entities which must always be positive. Others, however, may accept these as negative values or fail to recognise them as negative and convert them to a positive value.

Inconsistent units

Inconsistent validation rules

Inconsistent representation semantics Inconsistent handling of negative values

Slide: 52

Data conversion


Data re-engineering may involve changing the data structure organisation without changing the data values Data value conversion is very expensive. Special-purpose programs have to be written to carry out the conversion
Slide: 53

The data re-engineering process

Program to be re-engineered Data analysis

Data analysis

Entity name modification Literal replacement Data definition re-ordering Stage 1 Stage 2

Data re-formatting Default value conversion Validation rule modification Stage 3

Data conversion

Change summary tables

Modified data
Slide: 54