7

BAB II

LANDASAN TEORI

2.1 Quality

Menurut Organisasi Internasional untuk Standarisasi (ISO 9000, edisi

kedua, 2000) yang dikutip oleh Murali (2011) pada bukunya yang berjudul

“Mastering Software Quality Assurance” mendefinisikan kualitas sebagai sejauh

mana seperangkat karakteristik yang melekat telah memenuhi persyaratan.

Kualitas dapat digunakan dengan kata sifat seperti buruk, baik, atau sangat baik.

Melekat sebagai lawan yang ditugaskan, berarti berada di dalam sesuatu, sebagai

karakteristik permanen.

2.1.1 Quality dari Sudut Pandang Penyedia

Menurut Murali (2011) Kualitas adalah atribut dari suatu produk

atau jasa yang diberikan kepada konsumen yang sesuai dalam keseluruhan

atau melebihi yang terbaik dari spesifikasi yang tersedia untuk produk atau

layanan. Hal ini termasuk membuat spesifikasi yang tersedia untuk

pengguna akhir dari produk atau jasa.

Spesifikasi yang membentuk dasar dari produk atau layanan yang

disediakan mungkin telah ditetapkan oleh badan pemerintah, asosiasi

industri, atau badan standar. Dimana definisi tersebut tidak tersedia.

8

2.2 Quality Assurance

Dalam glosarium dari Capability Maturity Model Integration (CMMI)

dokumen model untuk pengembangan (versi 1.2, 2006) yang dikutip oleh Murali

(2011), Quality Assurance didefinisikan sebagai “Cara terencana dan sistematis

untuk menjamin pengelolaan yang menetapkan standar, praktek, prosedur, dan

metode proses yang diterapkan”.

2.2.1 Software Quality Assurance

Software Quality Assurance (SQA) adalah proses formal untuk

mengevaluasi dan mendokumentasikan kualitas produk kerja yang

dihasilkan selama setiap tahap Software Development Lifecycle (SDLC).

Tujuan utama dari proses SQA adalah untuk memastikan produksi dari

produk kerja berkualitas tinggi sesuai dengan kebutuhan yang dinyatakan

dan standar yang ditetapkan (Rekha, 2012:70).

Software Quality Assurance (SQA) melibatkan seluruh proses

pengembangan perangkat lunak-monitoring dan meningkatkan proses,

memastikan bahwa setiap standar yang disepakati dan prosedur telah

diikuti atau dilaksanakan, dan memastikan bahwa masalah-masalah telah

ditemukan dan ditangani. Hal ini berorientasi pada pencegahan. Software

Quality Assurance bertujuan untuk mengembangkan metodologi

pengembangan perangkat lunak yang akan menghasilkan perangkat lunak

yang berkualitas (Isha, 2014:738).

9

2.2.2 Process and Product Quality Assurance (PPQA)

Process and Product Quality Assurance (PPQA) adalah SQA yang

utama, area proses Software Quality Assurance dalam CMMI. Meskipun

ada banyak definisi dari Software Quality Assurance SQA dengan fungsi

utamanya dalam CMMI (di bawah Process and Product Quality

Assurance PPQA) adalah berpusat pada kesesuaian dan kepatuhan

terhadap proses deskripsi, standar dan prosedur yang ditetapkan

sebelumnya (Rekha, 2012:74).

Menurut (Mary Beth Chrissis, 2011) tujuan dari Process and

Product Quality Assurance adalah untuk menyediakan manajemen dan

karyawan dengan pengetahuan obyektif ke dalam proses dan produk kerja

yang terkait.

Area proses Process and Product Quality Assurance melibatkan

hal berikut:

Secara objektif mengevaluasi proses yang dilakukan, produk kerja

dan jasa terhadap deskripsi proses yang berlaku, standar dan

prosedur.

Mengidentifikasi dan mendokumentasikan masalah ketidak

sesuaian.

Memberikan umpan balik kepada staf proyek dan manajer hasil

kegiatan Quality Assurance.

Memastikan bahwa masalah-masalah pelanggaran ditangani.

10

Process and Product Quality Assurance mendukung area proses

pengiriman produk berkualitas tinggi dengan menyediakan staf proyek dan

manajer di semua tingkat dengan visibilitas yang tepat kedalam, dan

umpan balik pada, proses dan produk kerja terkait di seluruh kehidupan

proyek.

Process and Product Quality Assurance (PPQA) merupakan proses

area dari tingkat kematangan kedua, yaitu managed. PPQA memiliki 2

spesific goals dan 4 spesific practice yang berhubungan dengan spesific

goal. Berikut merupakan spesific goals dan spesific practice dari PPQA :

SG 1 Objectively Evaluate Processes and Work Products

SP 1.1 Objectively Evaluate Processes

SP 1.2 Objectively Evaluate Work Products

SG 2 Provide Objective Insight

SP 2.1 Communicate and Resolve Noncompliance Issues

SP 2.2 Establish Records

2.3 Capability Mature Model Integration (CMMI)

Menurut (Mary Beth Chrissis, 2011) CMMI (Capability Maturity Model

Integration) model adalah sekumpulan praktik terbaik yang membantu organisasi

untuk meningkatkan proses mereka. Model ini dikembangkan oleh tim produk

dengan anggota dari industri, pemerintah, dan Software Engineering Institute

(SEI). Model ini yang disebut CMMI untuk development (CMMI-DEV),

11

memberikan satu set pedoman komprehrensif yang terintegrasi untuk

mengembangkan produk dan jasa.

CMMI-DEV memberikan panduan untuk menerapkan praktek CMMI

terbaik dalam pengembangan organisasi. Praktik terbaik dalam model fokus pada

kegiatan untuk mengembangkan produk dan layanan berkualitas untuk memenuhi

kebutuhan pelanggan dan pengguna akhir.

Menurut Gokhan Halit Soydian (2012: p777) CMMI memainkan berbagai

macam peran, yaitu suatu pendekatan pengembangan proses, suatu cara untuk

mendeskripsikan karakteristik proses yang efektif, suatu sekumpulan elemen-

elemen penting dari proses efektif untuk satu atau lebih pengetahuan, suatu proses

CMM yang membantu dalam definisi dan pemahaman dari proses organisasi

CMMI terdiri dari lima tingkat kematangan, yaitu Initial, Managed,

Defined, Quantitatively Managed, dan Optimizing.

Kematangan tingkat 1 : Initial

Pada tingkat kematangan 1, proses biasanya adhoc dan kacau.

Organisasi biasanya tidak menyediakan lingkungan yang stabil untuk

mendukung proses. Keberhasilan dalam organisasi ini tergantung pada

kompetensi dan tindakan dari orang-orang dalam organisasi dan bukan

pada menggunakan proses yang terbukti. Meskipun dalam kekacauan,

tingkat kematangan 1 organisasi sering menghasilkan produk dan jasa

yang bekerja, tetapi mereka sering melebihi anggaran dan jadwal yang

didokumentasikan dalam rencana mereka.

12

Kematangan tingkat 2 : Managed

Pada tingkat kematangan 2, proyek telah memastikan bahwa proses

yang direncanakan dan dilaksanakan sesuai dengan kebijakan; proyek

mempekerjakan orang-orang terampil yang memiliki sumber daya yang

memadai untuk menghasilkan output yang terkendali; melibatkan

pemangku kepentingan yang bersangkutan; dipantau, dikendalikan, dan

ditinjau; dan dievaluasi untuk kepatuhan terhadap deskripsi proses mereka.

Kematangan tingkat 3 : Defined

Pada tingkat kematangan 3, proses ditandai dan dipahami dengan

baik, dan telah dijelaskan dalam standar, prosedur, tools, dan metode.

Perlengkapan organisasi standar proses, yang merupakan dasar untuk

tingkat kematangan 3, didirikan dan ditingkatkan dari waktu ke waktu.

Standar proses ini digunakan untuk menetapkan konsistensi di seluruh

organisasi.

Kematangan tingkat 4 : Quantitatively Managed

Pada tingkat kematangan 4, organisasi dan proyek menetapkan

sasaran kuantitatif untuk kualitas dan proses kinerja dan menggunakannya

sebagai kriteria dalam mengelola proyek. Tujuan kuantitatif didasarkan

pada kebutuhan pelanggan, pengguna akhir, organisasi, dan pelaksana

proses. Kualitas dan proses kinerja dipahami dalam statistik dan dikelola

sepanjang hidup proyek.

13

Kematangan tingkat 5 : Optimizing

Pada tingkat kematangan 5, sebuah organisasi terus-menerus

meningkatkan proses yang didasarkan pada pemahaman kuantitatif untuk

tujuan bisnis dan kebutuhan kinerja. Organisasi menggunakan pendekatan

kuantitatif untuk memahami variasi yang melekat dalam proses dan

penyebab dari hasil proses. Tingkat kematangan 5 berfokus pada terus

meningkatkan kinerja proses melalui proses yang bertahap dan inovatif

dan peningkatan teknologi.

Berikut adalah tabel maturity level (Weiliang, 2012:1912) :

Tabel 2.1 : Maturity Level dalam CMMI

Maturity Level Key Process Area

5. Optimizing

OID: Organizational Innovation and Deployment

CAR: Causal Analysis and Resolution

4. Quantitatively Managed

OPP: Organizational Process Performance

QPM: Quantitative Project Management

3. Defined

RD: Requirements Development

TS: Technical Solution

PI: Project Integration

Ver: Verification

Val: Validation

OPF: Organizational Process Focus

OPD: Organizational Process Definition

OT: Organizational Training

14

IPM: Integrated Project Management

RskM: Risk Management

DAR:Decision Analysis and Resolution

2. Managed

ReqM: Requirements Management

PP: Project Planning

PMC: Project Monitoring and Control

SAM: Supplier Agreement Management

MA: Measurement and Analysis

PPQA: Process and Product Quality Assurance

CM: Configuration Management

1. Initial

Setiap area proses mencakup beberapa specific goals dan generic goals,

secara sistematis, setiap generic goals berisi beberapa specific practice dan setiap

generic goal berisi beberapa generic practice. Keterkaitan antara process area,

goals dan practice digambarkan pada oleh struktur CMMI sebagai berikut

(Weiliang, 2012:1912) :

15

Gambar 2.1 Diagram Struktur CMMI

(Sumber : Weiliang,2012,p1913)

2.4 Software Development

Menurut John Dooley (2011) Software development adalah proses

pengambilan satu set persyaratan dari user (pernyataan masalah), menganalisis

mereka, merancang solusi untuk masalah ini, dan kemudian mengimplementasi

solusi pada komputer. Software development adalah penyempitan focus software

16

engineering hanya pada bagian yang bersangkutan dengan penciptaan software

yang sebenarnya. Dan itu adalah perluasan dari focus pemrograman untuk

menyertakan analisis, desain, dan menyelesaikan masalah.

2.4.1 Software Development Life Cycle

Software Development Life Cycle adalah proses untuk

mengembangkan software. Proses ini dibagi menjadi beberapa tahap

seperti Requirement Analysis, Design, Coding, Testing, Installation dan

Maintenance. Semua kegiatan ini dilakukan dengan cara yang berbeda

sesuai dengan kebutuhan per-klien. Masing-masing cara ini dikenal

sebagai Software Development Life Cycle Model. Setiap sistem harus

melalui fase-fase ini baik dalam skala kecil atau skala besar (Kumar,

2013:216).

Menurut Massey (2012, p25), software lifecycle model

menggambarkan suatu fase-fase siklus software dan urutan dimana fase-

fase tersebut dijalankan atau dieksekusi.

Berikut adalah fase-fase software development lifecycle (Kumar,

2013:216)

A. Requirement Analysis

Requirement Analysis adalah tahap awal dari Software

Development Life Cycle. Tujuan dari tahap ini adalah untuk

memahami kebutuhan klien dan untuk mendokumentasikannya

dengan benar. Penekanan dalam requirement analysis adalah

mengidentifikasi apa yang dibutuhkan dari sistem. Ini adalah fase

17

yang paling penting dalam Software Development Life Cycle.

Output dari requirement analysis adalah Spesifikasi Kebutuhan

Software (Software Requirement Specification).

B. Design

Tahap Ini adalah langkah pertama untuk berpindah dari

domain masalah kearah domain solusi. Ini adalah fase yang paling

kreatif dalam Software Development Life Cycle. Tujuan dari tahap

ini adalah untuk mengubah spesifikasi kebutuhan ke dalam

struktur. Output dari tahap ini adalah Dokumen Desain Software

(Software Design Document).

C. Coding

Pada fase ini Dokumen Desain Software (SDD) diubah

menjadi kode dengan menggunakan beberapa bahasa

pemrograman. Ini adalah fase logis dari Software Development Life

Cycle. Output dari tahap ini adalah kode program.

D. Testing

Ini adalah fase yang paling penting dan kuat. Testing yang

efektif akan memberikan kontribusi untuk memberikan produk

software yang berkualitas tinggi, user lebih puas, biaya

maintenance yang lebih rendah, dan hasil yang lebih akurat dan

dapat diandalkan.

18

E. Maintenance

Fase ini dimulai setelah deliver produk. Jika terjadi error

atau modifikasi yang diperlukan hal itu akan diimplementasikan

dalam fase ini.

2.5 Goal Question Metric

Menurut S.Raju dan Dr G.V Uma (2014, p3) pendekatan Goal Question

Metric (GQM) adalah sebuah metode untuk melakukan studi empiris pada proyek

perangkat lunak (software). Sedangkan menurut Mahmoud Khraiweish (2013,

p108) paradigma GQM adalah suatu proses yang membantu organisasi untuk

fokus terhadap kegiatan pengukuran pada tujuan mereka. Metode GQM

dikembangkan untuk evaluasi berbagai tujuan dari perangkat lunak. GQM

dirancang oleh Victor Basili dan merupakan sistem pertanyaan dan jawaban

sederhana untuk kebutuhan evaluasi.

Menurut S.Raju dan Dr G.V Uma (2014, p3) GQM mendefinisikan pengukuran

kedalam 3 tingkat, yaitu:

Conceptual level (Goal)

Goal didefinisikan untuk sebuah objek untuk berbagai alasan, yang

berhubungan dengan berbagai model kualitas dari berbagai sudut pandang

dan saling berhubungan terhadap lingkungan tertentu.

Operational level (Question)

19

Satu set pertanyaan digunakan untuk mendefinisikan model dari objek

studi dan kemudian berfokus pada objek yang mencirikan penilaian atau

pencapaian dari tujuan tertentu (specific goal).

Quantitave level (Metric)

Satu set metrik, berdasarkan model, yang terkait dengan setiap pertanyaan

untuk menjawabnya dengan cara yang terukur.

2.6 Pengukuran Kepatuhan Specific Practice CMMI

Kriteria pengukuran yang akan digunakan dalam mengukur setiap proses

pengembangan dan menghasilkan produk software didalam tesis ini dengan

menggunakan SCAMPI (Standard CMMI Appraisal Method for Process

Improvement). SCAMPI dirancang untuk memberikan ukuran penilaian kualitas

relatif terhadap model CMMI. Penilaian SCAMPI digunakan untuk

mengidentifikasi kekuatan dan kelemahan proses yang sedang berjalan. Untuk

lebih jelasnya akan dapat dilihat pada Tabel 2.2.

20

Tabel 2.2 Kriteria Penilaian SCAMPI

Kode Kriteria Deskripsi

FI Fully Implemented

Satu atau lebih objek langsung sudah ada dan dinilai

sudah memadai

Setidaknya terdapat paling sedikit 1 objek tidak langsung

dan/atau penegasan untuk mengkonfirmasi implementasi

Tidak ada kelemahan yang tercatat

LI

Largely

Implemented

Satu atau lebih objek langsung sudah ada dan dinilai

sudah memadai

Setidaknya terdapat paling sedikit 1 objek tidak langsung

dan/atau ada penegasan untuk mengkonfirmasi

implementasi

Satu atau lebih kelemahan tercatat

PI

Partially

Implemented Objek langsung tidak ada atau dinilai tidak memadai

Satu atau lebih objek tidak langsung atau saran tegas

bahwa beberapa aspek dari practice diimplementasikan

Satu atau lebih kelemahan tercatat

ATAU

Satu atau lebih objek langsung sudah ada dan dinilai

sudah memadai

Tidak ada petunjuk lain (objek tidak langsung,

penegasan) mendukung objek langsung

Satu atau lebih kelemahan tercatat

NI Not Implemented Objek langsung tidak ada atau dinilai tidak memadai

Tidak ada petunjuk lain (objek tidak langsung,

penegasan) mendukung implementasi practice

Satu atau lebih kelemahan tercatat

NY Not Yet

Unit dasar dan grup support belum mencapai tahap di

dalam alur kerja untuk mengimplementasikan practice

Sumber (S. U. Team, 2011:145)

21

2.7 Literature Review

Berikut ini adalah literature review yang digunakan oleh penulis dalam

penulisan thesis:

Tabel 2.3 Literature Review

No Penulis Judul Metode Hasil

1 Mahmoud

Khraiwesh,

Process and

Product Quality

Assurance

Measures in

CMMI, 2014

Menggunakan

pendekatan GQM

dengan metode

CMMI

Menerapkan GQM

dalam metode CMMI

Mengukur quality

assurance proses dan

produk pada proses

area

Melakukan tes data

dengan cronbach

alpha di SPSS

2 Isha Sahni,

Anshul

Anand

Software

Quality

Assurance,

2014

Menggunakan

pendekatan CMM

model

Mengetahui alasan

terdapat bug pada

software

Mengurangi risiko

bug pada software

dengan CMM model

3 Divya

Bindal, Jyoti

Enhancing

Software

Mempelajari

kegiatan dan

22

Tamak Quality Using

Quality

Assurance

Practices in the

Project Life-

Cycle, 2013

demonstrasi Quality

Assurance di dalam

organisasi

Mengetahui peran

dari Quality

Assurance

4 Weiliang

Zhou,

Yaping Li

Research on

Quality

Measuring of

CMMI Cyclic

Implementation

in Software

Process, 2012

Menggunakan

pendekatan

judgement

metric dengan

metode CMMI

Menggunakan

delphi method

Melakukan

pengukuran dan

perhitungan berat

Implementasi model

evaluasi dari hasil

pengolahan data

5 Rekha

Chouhan,

Dr.Rajeev

Mathur

Role of

Software

Quality

Assurance in

Capability

Maturity Model

Integration,

2012

Menggunakan

pendekatan

CMMI

Peran-peran dari

Software Quality

Assurance dalam

CMMI requirements

development,

requirements

management,

product integration,

technical solution,

verification,

23

validation dan PPQA

(Product and

Process Quality

Assurance)

6 S.Raju dan

Dr. G.V.

Una

A Quantitative

Measurement of

Software

Requirement

Factors using

Goal Question

Metric (GQM)

Approach, 2014

Menggunakan

pendekatan GQM

Melakukan

pengukuran

berdasarkan software

requirement factor

Mendapatkan hasil

pengukuran terhadap

software requirement

factor

7 Naresh

Kumar,

A. S.

Zadgaonkar,

dan Abhinav

Shukla

Evolving a New

Software

Development

Life Cycle

Model SDLC -

2013 with

Client

Satisfaction,

2013

Menggunakan

waterfall model,

prototype model,

incremental

model, SDLC -

2013 model

Mendapatkan

perbandingan hasil

development

software dengan

waterfall model,

prototype model,

incremental model,

SDLC -2013 model

dari segi

understanding

requirement, cost,

24

schedule, risk

involvement, user

involvement,

guaranty of success,

client satisfaction,

flexbility, time

frame, dan initial

product feel