Rekayasa Perangkat Lunak

Diadopsi dari presentasi Ian

1
Sommeriville, 2006
 Rekayasa Perangkat Lunak
• Ekonomi dari semua negara maju bergantung
pada perangkat lunak
• Semakin banyak sistem yang dikendalikan
perangkat lunak
• RPL berkenaan dengan teori, metode, dan alat
bantu untuk pengembangan perangkat lunak
profesional
• Pengeluaran untuk perangkat lunak menunjukkan
bagian yang signifikan dalam GNP dari semua
negara maju
Diadopsi dari presentasi Ian
2
Sommeriville, 2006
 Biaya Perangkat Lunak
• Biaya perangkat lunak seringkali mendominasi
biaya sistem komputer. Biaya perangkat lunak
pada PC seringkali lebih besar dari biaya perangkat
keras.
• Lebih besar biaya untuk memelihara perangkat
lunak dari pada untuk mengembangkannya.
• RPL berkenaan dengan pengembangan perangkat
lunak yang efektif biaya.

Diadopsi dari presentasi Ian

3
Sommeriville, 2006
 Pertanyaan Seputar RPL
• Apa itu perangkat lunak?
• Apa itu RPL?
• Apa perbedaan antara RPL dengan ilmu
komputer?
• Apa perbedaan antara RPL dan rekayasa sistem?
• Apa itu proses perangkat lunak?
• Apa itu model proses perangkat lunak?

Diadopsi dari presentasi Ian

4
Sommeriville, 2006
 Pertanyaan Seputar RPL
• Apa saja biaya RPL?
• Apa saja metode-metode RPL?
• Apa yang dimaksud dengan CASE (Computer-Aided
Software Engineering)?
• Apa atribut-atribut perangkat lunak yang baik?
• Apa saja tantangan utama dalam RPL?

Diadopsi dari presentasi Ian

5
Sommeriville, 2006
 Apa Itu Perangkat Lunak?
• Software is:
– (1) instructions (computer programs) that when executed
provide desired features, function, and performance;
– (2) data structures that enable the programs to adequately
manipulate information and
– (3) documentation that describes the operation and use of
the programs.
• Program komputer dan dokumentasi yang berkenaan
seperti kebutuhan, model rancangan, dan panduan
pengguna.

Diadopsi dari presentasi Ian

6
Sommeriville, 2006
 Apa Itu Perangkat Lunak?
• Perangkat lunak bisa dikembangkan untuk pelanggan
tertentu atau untuk pasar umum.
– Generik – dikembangkan untuk dijual kepada rentang pelanggan yang
berbeda, misalnya Excel atau Word.
– Bespoke (custom) – dikembangkan untuk pelanggan tunggal berdasarkan
spesifikasi mereka.

• Perangkat lunak baru dapat dibuat dengan

mengembangkan program baru, mengkonfigurasi
perangkat lunak generik, atau menggunaulang
perangkat lunak yang ada.

Diadopsi dari presentasi Ian

7
Sommeriville, 2006
 Apa Itu RPL?
• RPL merupakan disiplin rekayasa yang berkenaan
dengan semua aspek produksi perangkat lunak.
• Rekayasawan PL harus mengadopsi pendekatan
yang sistematis dan teroganisasi pada pekerjaan
mereka dan menggunakan alat bantu serta tehnik
sesuai dengan masalah yang akan diselesaikan,
batasan pengembangan, dan sumberdaya yang
tersedia.

Diadopsi dari presentasi Ian

8
Sommeriville, 2006
 Lapisan Teknologi

tools

methods

process model

a “quality” focus

Software Engineering

copyright 2009 by Roger Pressman.

9
 Lapisan Teknologi (2)
• Proses mendefinisikan framework yang harus
dikerjakan untuk mengirimkan secara efektif
teknologi rekayasa perangkat lunak.
• Metode RPL memberikan perspektif teknis
bagaimana membangun perangkat lunak.
– Meliputi communication, requirements analysis, design
modeling, program construction, testing, and support
• Kakas RPL memberikan dukungan otomatisasi
maupun semi-otomatisasi untuk proses dan
metode yang digunakan. Diadopsi dari presentasi Pressman 10
 Perbedaan RPL dan Ilmu Komputer

• Ilkom berkenaan dengan teori dan dasar-dasar;

RPL berkenaan dengan praktek pengembangan
dan penyerahan PL yang berguna.
• Teori-teori ilkom tidak cukup untuk berlaku
sebagai pondasi yang lengkap bagi RPL.

Diadopsi dari presentasi Ian

11
Sommeriville, 2006
 Perbedaan antara RPL dan rekayasa sistem

• Rekayasa sistem berkenaan dengan semua aspek

pengembangan sistem berbasis komputer
termasuk perangkat keras, perangkat lunak, dan
rekayasa proses.
• RPL merupakan bagian dari proses ini yang
berkenaan dengan pengembangan infrastruktur
perangkat lunak, kendali, aplikasi, dan basisdata
dalam sistem.

Diadopsi dari presentasi Ian

12
Sommeriville, 2006
 Perbedaan antara RPL dan rekayasa sistem

• Rekayasawan sistem terlibat dalam spesifikasi

sistem, perancangan arsitektur, integrasi, dan
penyerahan.

Diadopsi dari presentasi Ian

13
Sommeriville, 2006
 Apa itu proses perangkat lunak?
• Serangkaian aktivitas yang tujuannya adalah
pengembangan atau evolusi perangkat lunak.
• Aktivitas generik dalam semua proses perangkat
lunak adalah:
– Spesifikasi – apa yang harus dilakukan sistem dan
batasan-batasan pengembangannya.

Diadopsi dari presentasi Ian

14
Sommeriville, 2006
 Apa itu proses perangkat lunak?
– Pengembangan – produksi sistem perangkat lunak
– Validasi – memeriksa bahwa perangkat lunak tersebut
merupakan apa yang dibutuhkan pelanggan
– Evolusi – mengubah perangkat lunak sebagai
tanggapan permintaan perubahan.

Diadopsi dari presentasi Ian

15
Sommeriville, 2006
 Framework Aktivitas
• Communication
• Planning
• Modeling
– Analysis of requirements
– Design
• Construction
– Code generation
– Testing
• Deployment

copyright 2009 by Roger Pressman. 16

 Model proses perangkat lunak
• Gambaran sederhana dari proses perangkat lunak
yang disajikan dari perspektif tertentu.
• Contoh perspektif proses:
– Perspektif aliran kerja – urutan aktivitas;
– Perspektif aliran data – aliran informasi;
– Perspektif peran/aksi – siapa melakukan apa.

Diadopsi dari presentasi Ian

17
Sommeriville, 2006
 Model proses perangkat lunak
• Model proses generik:
– Waterfall;
– Pengembangan iteratif;
– RPL berbasis komponen.

Diadopsi dari presentasi Ian

18
Sommeriville, 2006
 Apa saja biaya RPL?
• Kira-kira 60% biaya adalah biaya pengembangan,
40% biaya pengujian. Untuk perangkat lunak
custom, biaya evolusi seringkali melebihi biaya
pengembangan.
• Biaya bervariasi tergantung dari jenis sistem yang
dikembangkan dan kebutuhan dari atribut-atribut
sistem seperti kinerja dan kehandalan sistem.

Diadopsi dari presentasi Ian

19
Sommeriville, 2006
 Metode RPL
• Pendekatan terstruktur terhadap pengembangan
perangkat lunak yang mencakup model sistem,
notasi, aturan, saran perancangan, dan panduan
proses.
• Deskripsi model
– Deskripsi dari model grafis yang harus dibuat;
• Aturan
– Batasan-batasan yang berlaku pada model sistem;

Diadopsi dari presentasi Ian

20
Sommeriville, 2006
 Metode RPL
• Rekomendasi
– Saran dalam praktek perancangan yang baik;
• Panduan proses
– Aktivitas apa saja yang akan diikuti.

Diadopsi dari presentasi Ian

21
Sommeriville, 2006
 The Essence of Practice
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

copyright 2009 by Roger Pressman. 22

 Understand the Problem
• Who has a stake in the solution to the problem? That is,
who are the stakeholders?
• What are the unknowns? What data, functions, and
features are required to properly solve the problem?
• Can the problem be compartmentalized? Is it possible to
represent smaller problems that may be easier to
understand?
• Can the problem be represented graphically? Can an
analysis model be created?

copyright 2009 by Roger Pressman. 23

 Plan the Solution
• Have you seen similar problems before? Are there patterns that are
recognizable in a potential solution? Is there existing software that
implements the data, functions, and features that are required?
• Has a similar problem been solved? If so, are elements of the
solution reusable?
• Can subproblems be defined? If so, are solutions readily apparent
for the subproblems?
• Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created?

copyright 2009 by Roger Pressman. 24

 Carry Out the Plan
• Does the solution conform to the plan? Is source code traceable to
the design model?
• Is each component part of the solution provably correct? Has the
design and code been reviewed, or better, have correctness proofs
been applied to algorithm?

copyright 2009 by Roger Pressman. 25

 Examine the Result
• Is it possible to test each component part of the solution? Has a
reasonable testing strategy been implemented?
• Does the solution produce results that conform to the data,
functions, and features that are required? Has the software been
validated against all stakeholder requirements?

copyright 2009 by Roger Pressman. 26

 Hooker’s General Principles
• 1: The Reason It All Exists
• 2: KISS (Keep It Simple, Stupid!)
• 3: Maintain the Vision
• 4: What You Produce, Others Will Consume
• 5: Be Open to the Future
• 6: Plan Ahead for Reuse
• 7: Think!

copyright 2009 by Roger Pressman. 27

 Atribut Perangkat Lunak yang Baik
• Perangkat lunak harus menyediakan fungsionalitas
dan kinerja yang dibutuhkan kepada pengguna
dan harus dapat dipelihara, diandalkan, dan
diterima.
• Dapat dipelihara (Maintainability)
– Perangkat lunak harus berevolusi untuk memenuhi
keperluan perubahan;

Diadopsi dari presentasi Ian

28
Sommeriville, 2006
 Atribut Perangkat Lunak yang Baik
• Andal (Reliability)
– Perangkat lunak harus bisa dipercaya;
• Efisien (Eficiency)
– Perangkat lunak tidak boleh memboroskan
penggunaan sumberdaya sistem;
• Dapat diterima (Acceptability)
– Perangkat lunak harus bisa diterima oleh pengguna
rancangan. Artinya bisa dimengerti, berguna, dan
cocok dengan sistem yang lain.

Diadopsi dari presentasi Ian

29
Sommeriville, 2006
 Tantangan Utama dalam RPL
• Heterogenitas
– Mengembangkan tehnik untuk membangun perangkat lunak yang
dapat mengatasi heterogenitas platform dan lingkungan eksekusi;
• Penyerahan
– Mengembangkan tehnik yang mengarah pada penyerahan perangkat
lunak yang cepat;
• Kepercayaan
– Mengembangkan tehnik yang menunjukkan bahwa perangkat lunak
bisa dipercaya oleh penggunanya.

Diadopsi dari presentasi Ian

30
Sommeriville, 2006
 Tanggung Jawab Profesional dan Etis

• RPL melibatkan tanggung jawab yang lebih besar

dari sekedar penerapan keahlian teknis.
• Rekayasawan perangkat lunak harus berlaku
secara jujur dan etis jika ingin dihargai sebagai
profesional.
• Perilaku etis lebih dari sekedar menjunjung tinggi
hukum.

Diadopsi dari presentasi Ian

31
Sommeriville, 2006
 Tanggung Jawab Profesional
• Kerahasiaan
– Rekayasawan harus menghargai kerahasiaan pegawai
atau kliennya.
• Kompeten
– Rekayasawan tidak boleh memberi gambaran yang
salah tentang tingkat kompetensinya. Mereka tidak
boleh secara sadar menerima pekerjaan yang diluar
kompetensinya.

Diadopsi dari presentasi Ian

32
Sommeriville, 2006
 Selesai

Diadopsi dari presentasi Ian

33
Sommeriville, 2006