1

Pemeliharaan Software(Software Maintenance)

Slide: 2

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: 3

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: 4

Spiral maintenance model

Specification Implemention

ValidationOperation

Start

Release 1

Release 2

Release 3

Slide: 5

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: 6

Saran untuk peningkatan Merancang agar SW bisa terpelihara Mengukur kompleksitas Mengimplementasikan procedure

management perubahan (SCM) Meningkatkan kemampuan staff Menambah tool pemeliharaan dan

metrics

Slide: 7

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: 8

Microsoft Windows NT 30 juta baris code

ditambahkan selama 6 tahun

Telecom switch software 5.2 juta modifikasi

sepanjang satu dekade

Web-based applications 73% dari biaya

pembuatan e-commerce digunakan untuk re-design web site setelah implementasi pertama

Growth of Windows NT

0

5

10

15

20

25

30

35

1992 1993 1994 1995 1996 1997 1998 1999 2000

Year

Lin

es o

f C

od

e (m

illi

on

s)

WINDOWS NT 3.51

WINDOWS NT 3.1

WINDOWS NT 3.5

WINDOWS NT 4.0

WINDOWS 2000

Slide: 9

Kategori pemeliharaan SW Corrective maintenance

perubahan yang dilakukan guna memperbaiki kesalahan

Adaptive maintenance Perawatan berdasarkan perubahan lingkungan

Perfective maintenance Perubahan untuk meningkatkan kualitas sistem

tanpa merubah fungsinya Preventive maintenance

Meningkatkan reliability, future maintainability, future enhancement (reverse engineering dan re-engineering)

Slide: 10

Proporsi kategori pemeliharaan SW

PerfectiveMaintenance(65%)

Correctivemaintenance(17%)

Adaptivemaintenance(18%)

Lientz and Swanson (1980)

Slide: 11

Proses Pemeliharaan

Changerequest

Impactanalysis

SystemReleaseplanning

Changeimplementation

Systemrelease

Perfectivemaintenance

Adaptivemaintenance

Correctivemaintenance

Slide: 12

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: 13

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: 14

Structured vs. unstructured pemeliharaan SW

Configuration

Evaluation design

software

Plan approach

Modify design

Recode

Review

Test and Release

Evaluation code

?

Review

Recode

code

Slide: 15

Biaya Pemeliharaan Biaya yang dikeluarkan untuk melakukan

pemeliharaan software yang bisa mencapai 80% dari total biaya pembuatan software.

M = p + KeM = total usaha yang dikeluarkan untuk

pemeliharaanp = productivity effortK = empirical constantc = pengukuran kompliksitas yang bisa berdasarkan

kekurangan terhadap perancangan yang baik dan kokumentasi yang baik

d = derajat familiarty software

(c-d)

Slide: 16

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: 17

Software Evolution evolution is key

part of lifecycleInitial development

Evolution

first running versionevolution changes

Servicing

loss of evolvabilityservicing patches

Close-down

Phase-out

servicing discontinued

Switch-off

Slide: 18

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: 19

Contoh:A tale of two systems’ evolution

Age (years) 20 10

Size in Total Lines of Code (LOC) 181,652 189,999

Size in Function Points (FP) 1,321 1,446

Number of Modules 109 45

% of Online Modules 7% 62%

% of Batch Modules 93% 38%

Average Module Size (LOC) 1,666 3,878

Financial System Shipping System

Slide: 20

Pendefinisian pengukuran software evolution

Amplitude = ukuran modifikasi software

Periodicity = interval waktu antara perubahan

Deviation = variability panjang interval waktu

tim e

modific

ations

tim e

mo

dific

atio

ns

Slide: 21

Slide: 22

Slide: 23

Kategori pengukuranevolusi software

Kategori Amplitude Periodik Deviation Deskripsi I Rendah Panjang Rendah Sangat sedikit berubah:

modifikisi kecil yang jarang muncul pada suatu model yang well-behaved.

II Rendah Panjang Tinggi Modifikasi kecil yang akdang terjadi dengan variansi behavior sistem program yang lebar

III Rendah Pendek Rendah Modifikasi kecil yang konstan occurring muncul di suatu madel yang baik (well-behaved)

IV Rendah Pendek Tinggi Modifikasi kecil yang konstan dengan variansi behavior sistem program yang lebar.

V Tinggi Panjang Rendah Modifikasi besar yang jarang muncul di suatu model yang baik (well-behaved)

VI Tinggi Panjang Tinggi Modifikasi besar yang jarang muncul dengan variansi behavior sistem program yang lebar

VII Tinggi Pendek Rendah Modifikasi besar yang konstan muncul di suatu model yang baik (well-behaved)

VIII Tinggi Pendek Tinggi Sangat mudah berubah: Most volatile: modifikasi besar dengan variansi behavior sistem program yang lebar

Slide: 24

Software Re-engineering Reorganisasi dan modifikasi sistem

software agar bisa dipelihara (maintainable)

Slide: 25

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: 26

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 re-strukturisasi.

Slide: 27

Keuntungan melakukan Re-engineering SW Mengurangi risiko

Adanya risiko yang tinggi pada pengembangan softwarebaru. (yaitu masalah pengembangan, staff, dan spesisfikasi).

Mengurangi biaya Biaya re-engineering secara signifikan

lebih kecil dari dari biaya pembuatan software baru

Slide: 28

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

Business process re-engineering

Slide: 29

Forward engineering dan re-engineering

Understanding andtransformation

Existingsoftware system

Re-engineeredsystem

Design andimplementation

Systemspecification

Newsystem

Software re-engineering

Forward engineering

Slide: 30

Proses re-engineering

Reverseengineering

Programdocumentation

Datareengineering

Original data

Programstructure

improvement

Programmodularisation

Structuredprogram

Reengineereddata

Modularisedprogram

Originalprogram

Source codetranslation

Slide: 31

Faktor biaya Re-engineering

Kualitas software yang akan di re-engineered

Fasilitas pendukung yang tersedia untuk proses re-engineering

Besarnya konversi data yang diperlukan

Adanya staff yang ahli untuk proses re-engineering

Slide: 32

Pendekatan Re-engineering

Automated restructuringwith manual changes

Automated sourcecode conversion

Restructuring plusarchitectural changes

Automated programrestructuring

Program and datarestructuring

Increased cost

Slide: 33

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.

Source code translation

Slide: 34

Automaticallytransla te code

Design translatorinstructions

Identify sourcecode differences

Manuallytransla te code

System to bere-engineered

System to bere-engineered

Re-engineeredsystem

Proses translate Program

Slide: 35

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.)

Reverse engineering

Slide: 36

Data stucturediagrams

Program stucturediagrams

Traceabilitymatrices

Documentgeneration

Systeminformation

store

Automatedanalysis

Manualannotation

System to bere-engineered

Proses reverse engineering

Slide: 37

Reverse engineering sering diawali oleh re-engineering tapi dapat juga di keseluruhan proses reverse engineering itu sendiri Disain dan specification system dapat di-

reverse-engineered sehingga bisa dijadikan sebagai input ke requirements specification process untuk penggantian system (system”s replacement)

Disain dan specification dapat di-reverse- engineered untuk mendukung pemeliharaan program

Reverse engineering

Slide: 38

Meningkatkan struktur program

Program direstrukturisasi secara otomatis untuk menghilangkan cabang non-kondisi.

Statement kondisi disederhanakan sehingga mudah dibaca.

Slide: 39

Spaghetti logic

Slide: 40

Kontrol logic terstruktur

Slide: 41

Contoh penyederhanaan suatu kondisi

-- Kondisi yang kompleksif not (A > B and (C < D or not ( E > F) ) )...

--Kondisi yang sederhanaif (A <= B and (C>= D or E > F)...

Slide: 42

Restrukturisasi program yang otomatis

Graphrepresentation

Programgenerator

Restructuredprogram

Analyser andgraph builder

Program to berestructured

Slide: 43

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: 44

Modularitas Program

Proses re-organisasi suatu program sehingga program yang berkaitan terkumpul menjadi satu module.

Biasanya dilakukan secara manual pada inspeksi program dan re-organisasi

Slide: 45

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: 46

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: 47

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 DBMS-based system or changing from one DBMS to another

Objective is to create a managed data environment

Slide: 48

Pendekatan untuk data re-engineering

Approach Description Data cleanup 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.

Data extension 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.

Data migration 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.

Slide: 49

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: 50

Data migration

Databasemanagement

system

Logical andphysical

data models

describes

File 1 File 2 File 3 File 4 File 5 File 6

Program 2 Program 3

Program 4 Program 5 Program 6 Program 7

Program 1

Program 3 Program 4 Program 5 Program 6

Program 2Program 7

Program 1

Becomes

Slide: 51

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: 52

Data value inconsistencies

Data inconsistency DescriptionInconsistent defaultvalues

Different programs assign different default values to the same logical dataitems. This causes problems for programs other than those that created thedata. The problem is compounded when missing values are assigned adefault value that is valid. The missing data cannot then be discovered.

Inconsistent units The same information is represented in different units in differentprograms. For example, in the US or the UK, weight data may berepresented in pounds in older programs but in kilograms in more recentsystems. A major problem of this type has arisen in Europe with theintroduction of a single European currency. Legacy systems have beenwritten to deal with national currency units and data has to be converted toeuros.

Inconsistent validationrules

Different programs apply different data validation rules. Data written byone program may be rejected by another. This is a particular problem forarchival data which may not have been updated in line with changes todata validation rules.

Inconsistentrepresentationsemantics

Programs assume some meaning in the way items are represented. Forexample, some programs may assume that upper-case text means anaddress. Programs may use different conventions and may therefore rejectdata which is semantically valid.

Inconsistent handlingof negative values

Some programs reject negative values for entities which must always bepositive. Others, however, may accept these as negative values or fail torecognise them as negative and convert them to a positive value.

Slide: 53

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: 54

The data re-engineering process

Entity namemodification

Literalreplacement

Data definitionre-ordering

Datare-formattingDefault value

conversion

Validation rulemodification

Dataanalysis

Dataconversion

Dataanalysis

Modifieddata

Program to be re-engineered

Change summary tables

Stage 1 Stage 2 Stage 3