Prinsip pemilihan bahasa

pemrograman
Memiliki sintaks yang jelas
Memiliki semantik yang jelas
 Semantic (arti) dari setiap statement program
jelas.
Precedence operator dlm expresi mudah
dimengerti
Modular dan Information hiding
 Model Integrasi sub-modul yang dapat di-link oleh
beberapa sub-modul lain secara independent
 Setiap sub-modul yg di-link tsb menjadikan suatu
model abstraksi utk information
HARJANTO SUTEDJO - ATA
hiding
2008/2009 1
Prinsip pemilihan bahasa
pemrograman (cont.)
Abstraksi
 Tersedia fasilitas untuk mendefinisikan tipe data
baru sbg abstraksi data, maupun abstraksi
algoritma.
Orthogonal
 Hanya ada satu cara dalam mengekspresikan
suatu action, tidak bergantung tehadap komponen
lain (tipe data composite dan return function
sesuai tipe data yg diinginkan)
Portability
 Dapat diinstal proses kompilasi pada beberapa
jenis mesin dan OS.SUTEDJO - ATA
HARJANTO
2008/2009 2
Prinsip pemilihan bahasa
pemrograman (cont.)
Structure
 Control flow
 Name scope (bagaimana menggunakan referensi
variable) -> pointer
 Typing (static, dynamic)
Compiler dapat mendeteksi error melalui
check yang konsisten. Kesalah yg umum
seperti pemberian nama alias untuk suatu
variable -> tidak konsisten; type-checking;
Efisiensi
 Warning untuk variable yg tidak
HARJANTO SUTEDJO - ATA
digunakan tp
sudah dideklarasikan2008/2009 3
(cont.) Prinsip pemilihan
Bahasa Pemrograman
Seragam dalam penggunaan statement
Dapat mengantisipasi kondisi exception
Mampu menangani proses yg
concurrent (bersamaan) -> multithread,
parallel processing

HARJANTO SUTEDJO - ATA

2008/2009 4
Kategori Aplikasi
Paradigma pemrosesan data
 Pemrosesan record-record data
Paradigma komputasi numerik
 Melibatkan perhitungan matematika tingkat tinggi
(simulasi dan modelling), graphics, pengolahan
citra
Paradigma berorientasi proses
 ‘real-time programming’ melibatkan pemrosesan
record dan proses komputasi, komunikasi inter-
proses

HARJANTO SUTEDJO - ATA

2008/2009 5
Kategori Aplikasi
Paradigma system-programming
 Close to the machine (control-system,
embedded system, ….)
Paradigma proses auto-adaptive
 Implementasi Artificial Intelligent.

HARJANTO SUTEDJO - ATA

2008/2009 6
Perawatan Sistem
(Sistem Maintenance)
Melakukan modifikasi aplikasi (SW)
setelah digunakan/dipakai.
Biasanya tidak melakukan perubahan
besar terhadap arsitektur sistem.
Perubahan-perubahan terjadi melalui
modifikasi komponen yg ada dan/atau
penambahan komponen baru ke sistem.

HARJANTO SUTEDJO - ATA

2008/2009 7
 A Typical Maintenance Flow
Written:
MR’s

nominal Proposed
Customer
path M. R.’s
Help desk

Approved
M. R.’s

Maintenance Current source Change control board

engineer & documentation

Modified source
& documentation
HARJANTO SUTEDJO - ATA
MR:Maintenance Request 2008/2009 8
 A Typical Maintenance Flow
Marketing
nominal Written
path MR’s
Proposed
Customer Maintenance
manager M. R.’s
Help desk

Approved
M. R.’s

Maintenance Current source Change control board

engineer & documentation

Modified source Rejected

& documentation MR’s
HARJANTO SUTEDJO - ATA
2008/2009 9
Tipe Maintenance
Corrective Maintenance
 Memperbaiki kesalahan latent

 termasuk temporary patches

Adaptive Maintenance
 Respond terhadap perubahan
eksternal
 Perubahan hardware platform
 Perubahan software dukungan
Perfective Maintenance
 Meningkatkan mutu sistem yg sdh
dikembangkan
 user enhancements
 Peningkatan efisiensi
Preventative Maintenance
 Mempermudah perawatan
berikutnya HARJANTO SUTEDJO - ATA
2008/2009 10
 Documenting, commenting, etc.
Masalah yg dihadapi
Lima masalah utama:
 Rendahnya kualitas dokumentasi
 Banyak permintaan user utk peningkatan dan
perluasan
 Banyak menyita waktu utk maintenance
 Sulit menentukan komitmen waktu schedule
pertemuan
 Pertukaran susunan organisasi
Keterbatasan pemahaman
Moral
 KebanyakanHARJANTO
lebihSUTEDJO
tertarik-
ke
ATA
pengembangan
sistem 2008/2009 11
 4. Implementation
IEEE standard 840-1992 4.1 Input
1. Problem identification 4.2 Process
1.1 Input 1.2 Process 4.2.1 Coding and testing
1.3 Control 1.4 Output 4.2.3 Risk analysis & review
1.5 Quality factors 4.2.4 Test-readiness review
1.6 Metrics 4.3-4.6 Control, Output,
2. Analysis Quality factors, Metrics.
2.1 Input 5. System Test
2.2 Process 5.1-5.6 Input, Process, Control,
2.2.1 Feasibility analysis Output, Quality factors, Metrics.
2.2.2 Detailed analysis 6. Acceptance Test
2.3-2.6 Control, Output, 6.1-6.6 Input, Process, Control,
Quality factors, Metrics. Output, Quality factors, Metrics.
3. Design 7. Delivery
3.1-3.6 Input, Process, Control, 7.1-7.6
HARJANTO SUTEDJO - Input, Process, Control,
ATA
Output, Quality factors, Metrics.2008/2009 12
Output, Quality factors, Metrics.
 IEEE 1219-1992
Fase Perawatan 1: Problem Identification

a. Input
•Maintenance Request (MR) (Permintaan Perawatan)

•Mementukan jumlah perubahan

•Kalsifikasi berdasarkan tipe dan severity etc.
b. Process •Menerima atau menolak perubahan
•Membuat estimasi perhitungan awal biaya maintenance
•Prioritas
•Identifikasi MR sec. unique
c. Control •Memasukkan MR kedalam kegiatan kerja

d. Output
•MR yang valid

e. Selected quality
factors •Kejelasan MR
•Tingkat kebenaran MR (mis., type)

•Jumlah MR yang diabaikan

f. Selected metrics •Jumlah MR yang dilaksanakan
•Jumlah duplikasi MR
HARJANTO SUTEDJO - ATA
•Waktu yang diperlukan untuk
2008/2009 menemukan masalah 13
 IEEE 1219-1992
Fase Maintenance 2: Problem Analysis

a. Input •Dokumentasi asli Proyek

•MR yang sudah tervalidasi di fase identifikasi

•Mempelajari fisibilitas MR
b. Process •Investigasi dampak MR
•Analisa detail pekerjaan yang akan dilakukan yg berhubungan dg MR
•Menyempurnakan deskripsi MR

•Membuat technical review

•Verifikasi terhadap …
c. Control …startegi test yang cocok
…dokumentasi yang ter-update
•Identifikasi isu keselamatan dan keamanan

•Laporan fisibilitas
•Laporan detail analisis, termasuk dampak yang mungkin terjadi
d. Output •Requirement yg ter-update
•List modifikasi awal
•Rencana Implementation Perubahan
•Strategi Test

e. Selected quality
factors •Comprehensibility of the analysis

•Number of requirements that must be changed

f. Selected metrics •Effort (required
HARJANTO SUTEDJO
to analyze the MR) - ATA
•Elapsed time 2008/2009 14
 IEEE 1219-1992
Maintenance phase 3: Design

•Original project documentation

a. Input
•Analysis from the previous phase

•Create test cases

•Revise …
b. Process
…requirements
…implementation plan

c. Control •Verify design

•Inspect design and test cases

•Revised … •Updated …
…modification list
d. Output …design baseline
…detailed analysis
…implementation plan …test plans

•Flexibility (of the design)

e. Selected quality •Traceability
factors •Reusability
•Comprehensibility

•Effort in person-hours
f. Selected metrics •Elapsed time
HARJANTO SUTEDJO - ATA
•Number of applications of the change
2008/2009 15
 IEEE 1219-1992
Maintenance phase 4: Implementation

•Original source code

a. Input
•Original project documentation
•Detailed design from previous phase

•Make code changes and additions

b. Process •Perform unit tests
•Review readiness for system testing

•Inspect code
c. Control •Verify
CM control of new code
Traceability of new code

•Updated …
d. Output …software
…unit test reports
…user documents

•Flexibility
e. Selected quality •Traceability
factors •Comprehensibility
•Maintainability
•Reliability
•Lines of code
f. Selected metrics HARJANTO SUTEDJO - ATA
•Error rate
2008/2009 16
Pendekatan Maintenance
Filosofi Maintenance:
 Orang lain yg bertanggung jawab dlm maintenance (bukan pengembang)
 maintenance menjadi tantangan dlm reverse engineering
Tim pengembang membuat suatu long term komitmen untuk merawat
sistem.
Proses maintenance Basili:
 Quick-fix model
 Perubahan pd code semudah mungkin
 Degradasi struktur software menurun secara cepat
 Iterative enhancement model
 Perubahan berdasarkan analisis sistem
 Berusaha utk mengontrol kompleksitas dan merancang perawatan dgn
baik
 Full-reuse model
 Memulai dengan requirements utk sistem baru, sedapat mungkin
melakukan reengineering sistem yg ada.
 Memerlukan suatu budaya reuse yg mature agar sukses dlm
reengineering HARJANTO SUTEDJOterjadinya
(meminimumkan - ATA perubahan-perubahan).
2008/2009 17
Kualitas Maintenance
Metrics Maintenance:
 Number of lines of code under maintenance
 Person-months to perform various maintenance
tasks
 Defect count

HARJANTO SUTEDJO - ATA

2008/2009 18
 Quality Assurance
Quality assurance terdiri dari procedures, techniques, dan tools yang
digunakan utk meyakinkan bahwa sistem sesuai atau melampaui
standards yang sudah ditentukan pd saat proses pengembangan sistem.
Terdiri dari semua teknik yg digunakan untuk meningkatkan kualitas sistem:
1. Metode dan alat untuk menentukan System Requirements, System Analysis, System Design,
Implementation and Testing
 membantu dlm meyakinkan kualitas sistem
2. Standard dan procedure
 membantu meyakini proses pengembangan sistem yg dpt diulang
3. Prosedur Metrics dan pengukuran
 membantu meingkatkan proses pengembangan sistem
4. Review Formal technical pd setiap langkah
 to help uncover quality problems and to sign-off
5. Software configuration management dan change control
 meyakinkan bhw perubahan dilakukan secara terkontrol dan teratur
6. Multi-tiered testing
 HARJANTO
membantu dlm mencari SUTEDJO
kesalahan -
secara ATA
efektif
2008/2009 19
Prinsip Kualitas Assurance
1. Adanya standards dan atribut kualitas yang harus
dipenuhi oleh sistem.
memenuhi tujuan yg harus dicapai.
2. Adanya pengukuran kualitas sistem.
 Cara utk menentukan seberapa baik sistem sesuai
dengan atribut dan standar kualitas.

3.Perhitungan terhadap nilai atribut kualitas.

 Menilai seberapa baik pengembangan sistem yg
sudah dilakukan.

4.Penggunaan informasi kualitas sistem digunakan utk

meningkatkan kualitas sistem berikutnya.
 Terdapat feedback terhadap
HARJANTO SUTEDJO - proses
ATA pengembangan
sistem. 2008/2009 20
 Faktor Kualitas
Portability
Maintainability (Dapatkah dikonversi ke
(Dapatkah diperbaiki) komputer lain)
Flexibility Reusability
(Dapatkah diubah)
Product Product (Beberapa bagianb dpt
Testability
(Dapatkah diujikan) Revision Translation digunakan lagi)
Interoperability
(Interaksi dg sistem
lain)
Product
Operation

Correctness (Sesuai dgn yg diinginkan)

Reliability (Dapat bekerja secara akurat)
Efficiency (Proses Komputasi & jml code)
Integrity (Keamanan)
HARJANTO SUTEDJO - ATA
Usability (Mudah digunakan)
2008/2009 21
 Faktor Kualitas
Yang menentukan kualitas sistem:
Sisi customer -> sesuai spesifikasi
Sisi pengembang -> mudah melakukan perawatan dan test
 Kualitas sistem ditentukan juga oleh beberapa faktor
lain:
Atribut lain untuk kualitas sistem:
 safety – understandability – portability
 security – testability – usability
 reliability – adaptability – reusability
 resilience – modularity – efficiency
 robustness – complexity – learnability

 perlu dilakukan pemilihan atribut kualias yg kritis pd tahap awal

proses pengembanganHARJANTO
sistem dan merencanakan
SUTEDJO - ATA penentuan
klasifikasi sistem thd atribut 2008/2009 22
Metrics
Control metrics – digunakan untuk mengontrol proses
pengembangan (mis., biaya, waktu yg digunakan, penggunaan
disk, dll.)

Predictor metrics – untuk memprdiksi kualitas product

yg sesuai. (mis., cyclomatic complexity memprediksi
kemudahan prawatan )
External attribute: hanya dapat setelah software digunakan
(mis.,kemudahan perawatan)
Internal attribute: dapat diukur langsung dari software itu
sendiri (mis., cyclomatic complexity)

HARJANTO SUTEDJO - ATA

2008/2009 23
Faktor Kualitas dan Metrics Kualitas

HARJANTO SUTEDJO - ATA

2008/2009 24
Functionality, Usability, Reliability,
HARJANTO SUTEDJO - Performance and
ATA
Supporotability (FURPS) 2008/2009
metrics 25
Product Quality —
Design Quality Metrics
Tingkat perawatan komponen perancangan sistem
berhubungan ke:
 Cohesion – tingkat hubungan fungisonal komponen?
 Coupling – tingkat ketergantungan antar komponen.
 Understandability – tingkat kemudahan pemahaman apa yang
dilakukan oleh komponen?
 Adaptability – tingkat kemudahan merubah komponen
Kebanyakan faktor tersebut tidak dapat diukur secara
langsung, tetapi hal tsb beralasan untuk menyatakan
bahwa terdapat hubungan antara atribut dan
kompleksitas komponen.
 measure complexity
HARJANTO SUTEDJO - ATA
2008/2009 26
Product Quality —
Design Quality Metrics (2)
a) Structural fan-in/fan-out
fan-in – jumlah panggilan ke suatu komponen (dari luar)
fan-out – jumlah komponen yg terpanggil (diluar)

b) Informational fan-in/fan-out
– Mempertimbangkan jml parameter yang dikirim ditambah
pengaksesan ke struktur data yg di share.
complexity = length x (fan-in x fan-out)2
 sudah tervalidasi pd sistem Unix
 merupakan prediktor effort yg diperlukan untuk
implementasi
HARJANTO SUTEDJO - ATA
2008/2009 27
Software Maturity Index
SMI = [MT - (Fa + Fc + Fd)]/ MT

MT = jumlah subsystem pd current release

Fc = jumlah subsystem pd current release yang diubah
Fa = jumlah subsystem pd current release yang
ditambahkan
Fd = jumlah subsystem pd release sebelumnya yg
dihilangkan di current release.

HARJANTO SUTEDJO - ATA

2008/2009 28
Design structure quality index—DSQI
IEEE Standard 982.1-1988
Digunakan untuk membandingkan dengan perancangan
sebelumnya; jika DSQI terlalu rendah,
perancangan dan review lebih lanjut masih diperlukan.
Range (0 – 1)

DSQI = wiDi wi = relative weighting of each Di

Program structure:
D1 = 1 jika arsitektur dikembangkan menggunakan metode yg
berbeda
D1 = 0 selain itu
Subsystem independence: D2 = 1 - (S2/S1)
Subsystems not dependent on prior processing: D3 = 1 - (S3/S1)
Database size: D4 = 1 - (S5/S4)
Database compartmentalization: D5 = 1 - (S6/S4)
HARJANTO SUTEDJO - ATA
Subsystem entrance/exit 2008/2009
characteristic: D6 = 1 - (S7/S1) 29
DSQI
S1 = jumlah subsystem yang didefinisikan dalam arsitektur program
S2 = jumlah subsystem dimana correct function tergantung pd sumber
data input atau yang menghasilkan data digunakan di tempat lain.
S3 = jumlah subsystem dimana correct function tergantung pada prses
sebelumnya
S4 = jumlah item database (termasuk data objects dan semua atribut-
atribut yang mendefinisikan obyek)
S5 = jumlah total item database unique
S6 = jumlah segmen database segments (record yg berbeda atau
individual objects)
S7 = jumlah subsystem dengan jalur masuk dan keluar tunggal

HARJANTO SUTEDJO - ATA

2008/2009 30
Product Quality —
Program Quality Metrics
a) Halstead’s Software Science
Melihat operators dan operands dalam suatu komponen dan
menghitung nilai volume component, V, tingkat kesulitan
component, D, dan effort, E, yg diperlukan untuk implementasi
komponen.
n1 = jumlah operators unique pd suatu component
n2 = jumlah operand unique pd suatu component
N1 = jumlah total operators
N2 = jumlah total operands
L = N1+ N2 (component length)
V = L * log2(n1 + n2) (component volume in bits)
D = (n1/2) * (N2/n2) (tingkat kesulitan implementasi komponen)
E=V *D (effort yg diperlukan untuk implementasi)
HARJANTO SUTEDJO - ATA
2008/2009 31
 Product Quality —
Program Quality Metrics (2)
b) McCabe’s Complexity Metric
Merujuk kepada control flow suatu komponen

Cyclomatic Complexity –> mengukur kompleksitas logical komponen

 suatu indikasi tingkat kesulitan pengujian suatu komponen

c) Metrics kualitas yg lain:

 Length of code – Length of identifiers
 Depth of conditional nesting

 Pencapaian Standard dapat menghindari component yg

complex dan/atau problem penting yg ada di componen

HARJANTO SUTEDJO - ATA

2008/2009 32
Product Quality —
Pendekatan Formal
a) Membuktikan kebenaran spesifikasi sistem.
Pembuktian secara logis bhw kebutuhan sudah ditransformasi
ke sistem secara benar.
(mis. pembuktian assertions programs)
b) Statistical Quality Assurance
 Pengkategorian dan menentukan penyebab defect sistem
 80-20 rule  80% defects dapat di telusuri disebabkan
oleh 20%
 Mengisolir dan memperbaiki 20% penyebab tadi
c) The Cleanroom Process
 Kombinasi dua pendekatan di atas.

HARJANTO SUTEDJO - ATA

2008/2009 33
Capability Maturity Model
(CMM)
Key Processes in Place
Level 1: Initial process
Level 2: Repeatable process
Requirements Management
Software Project Planning
Software Project Tracking &
Oversight
Software Subcontract Management
Software Quality Assurance
Software Configuration Management
Level 5: Optimizing process
Fault Prevention
Technology Change Management
HARJANTO SUTEDJO -
Process Change Management
2008/2009
Level 3: Defined process
Organization Process Focus
Organization Process Definition
Training Program
Integrated Software Management
Software Product Engineering
Intergroup Coordination
Peer Reviews
Level 4: Managed process
Quantitative Process Management
Software Quality Management
ATA
34
Process Quality — SEI Capability
Maturity Model (CMM)
Level 1 Organization: Initial process (ad hoc)
 Tidak terdapat: formal procedures, estimasi biaya, perencanaan

proyek, mekanisme manajemen untuk meyakini bhw prosedur

telah diikuti dg baik.

Level 2 Organization: Repeatable process (intuitive)

 Pengontrolan Basis project; penggunaan metoda intuitive.

Level 3 Organization: Defined process (qualitative)

 Pendefinisian proses pengembangan secara institusional.

Level 4 Organization: Managed process (quantitative)

 Mengukur proses; penguatan process database

Level 5 Organization: Optimizing process

 Meningkatkan feedback; adanya- analisa
HARJANTO SUTEDJO ATA defect-cause dan
pencegahannya. 2008/2009 35
People Quality — People Capability
Maturity Model (PCMM)
Level 1 – Initial
 Tidak ada technical atau management training; staff talent bukan sumber yg kritis; tidak ada
organizational loyalitas

Level 2 – Repeatable
 Focus pd pengembangan praktik kerja dasar; mengutamakan perkrutan, pertumbuhan dan
pengembangan staff; training utk meningkatkan skill “gaps”; evaluasi kinerja.

Level 3 – Defined
 Focus pada penggabungan praktik kerja ke bisnis organisasi; strategic plan untuk
melokasikan dan mengembangkan kebutuhan talent; melokasikan dan
mengembangkan kebutuhan talent; adanya kompensasi terhadap skills-based

Level 4 – Managed
 Focus pd peningkatan kompetensi pd critical skills; mentoring; team-building;
quantitative competence goals; evaluation thd kefektifan work practices

Level 5 – Optimizing
 Focus pd peningkatan kemampuan team dan individual penggunaan best practices
HARJANTO SUTEDJO - ATA
2008/2009 36
SQA — The Bottom Line
Suatu organisasi harus memiliki manual kualitas
manual yaitu dokumentasi prosedur quality
assurance
Setiap proyek harus memiliki quality plan yaitu himpunan
quality attributes yang dianggap penting

Memiliki dokumentasi yang standard

Terdapat mekanisme (processes) pemantauan pemenuhan

kebutuhan kualitas pd organisasi .

Adanya reviews terhadap quality assurance

Metrics yang dapat digunakan utk menghindari bagian anomalous

software yang memiliki permasalahan kualitas
HARJANTO SUTEDJO - ATA
2008/2009 37