Software Process

Tim RPL
Program Studi Teknik Informatika
 Tujuan :
• Untuk mengenalkan Model Proses Perangkat Lunak
• Untuk menggambarkan 3 model proses dan kapan model-model
tersebut digunakan.
• Untuk menggambarkan Model Proses secara garis besar untuk
requirements engineering, software development, testing dan
evolution
• Untuk menjelaskan Model Rational Unified Process
• Sebagai roadmap untuk membangun produk perangkat lunak
berkualitas tinggi
• Adapted to meet the needs of software engineers and managers
• Menyediakan sebuah framework untuk mengelola aktivitas.
• Different types of projects require different software processes
• Work product by the software process 2
 A Layered
Technology
Software Engineering

tools
methods
process
a quality focus

For use only at the university level and in conjunction with the book,Software Engineering: A Practitioner's Approach,4/e, McGraw-Hill, 1997.
Transparencies copyright © 1996, R.S. Pressman & Associates, Inc. reproduced with permission.

3
 Software Process

• Sekumpulan aktivitas terstruktur yang dibutuhkan

untuk mengembangkan software system
Specification;
Design;
Validation;
Evolution.
• A software process model is an abstract
representation of a process. It presents a description
of a process from some particular perspective.
For use only at the university level and in conjunction with the book,Software Engineering: A Practitioner's Approach,4/e, McGraw-Hill, 1997.
Transparencies copyright © 1996, R.S. Pressman & Associates, Inc. reproduced with permission.

4
 Definition (What???)

• System or information engineering

• Software project planning
• Requirements analysis

For use only at the university level and in conjunction with the book,Software Engineering: A Practitioner's Approach,4/e, McGraw-Hill, 1997.
Transparencies copyright © 1996, R.S. Pressman & Associates, Inc. reproduced with permission.

5
 Development (How???)

• Software design
• Code Generation
• Software Testing

For use only at the university level and in conjunction with the book,Software Engineering: A Practitioner's Approach,4/e, McGraw-Hill, 1997.
Transparencies copyright © 1996, R.S. Pressman & Associates, Inc. reproduced with permission.

6
 Maintenance (Change)

• Correction
• Adaptation
• Enhancement
• Prevention

For use only at the university level and in conjunction with the book,Software Engineering: A Practitioner's Approach,4/e, McGraw-Hill, 1997.
Transparencies copyright © 1996, R.S. Pressman & Associates, Inc. reproduced with permission.

7
 A Common Process Framework

Common Process Framework

Framework Activities

Task sets
Tasks

Milestones, deliverables

SQA points

Umbrella activities

For use only at the university level and in conjunction with the book,Software Engineering: A Practitioner's Approach,4/e, McGraw-Hill, 1997.
Transparencies copyright © 1996, R.S. Pressman & Associates, Inc. reproduced with permission.

8
 Common Process Framework
• Communication
– Customer collaboration and requirement gathering
• Planning
– Establishes engineering work plan, describes technical risk, list
resource requirements, work product produced, and defines work
schedule
• Modeling
– Creation of models to help developers and customers understand
the requires and software design
• Construction
– Code generation and design
• Deployment
– Software delivered for customer evolution and feedback

9
 5 Framework Activity

• Communication
• Planning
• Modeling
• Construction
• Deployment
 Framework Activity (hal 32)

Satu aspek penting dari software proses adalah proses flow,

menjelaskan bagaimana aktivitas framework, aksi, tugas-tugas yang
terjadi dengan setiap framework activity dikelola dengan terurut,
seperti pada gambar berikut :
Framework Activity (hal 32)
.......Lanjutan Proses Flow

Communication Planning

Modeling

Construction Deployment

C. Parallel Process Flow

 Process Patterns

• Process pattern menjelaskan proses yang berhubungan dengan

masalah yang dihadapi selama pekerjaan software engineering,
mengidentifikasi lingkungan dimana masalah telah
ditemui/dihadapi dan menyarankan satu atau lebih solusi yang
tepat
• Process pattern menyediakan template – sebuah metode yang
konsisten untuk menggambarkan solusi dari masalah dalam
konteks proses software.
• Process pattern menyediakan sebuah mekanisme yang efektif
untuk mengatasi masalah yang berhubungan dengan proses
software. Pola ini memungkinkan untuk mengembangkan
deskripsi proses hirarki yang dimulai pada tingkat tertinggi level
abstrak
 Proses Assessment and Improvement

• Software Process tidak menjamin bahwa software akan

dikirim tepat waktu, memenuhi kebutuhan pelanggan,
atau hal tersebut akan menunjukkan karakteristik yang
akan menyebabkan karakteristik kualitas berjangka waktu
panjang.
• Process pattern harus disandingkan dengan pembuatan
software engineering yang solid.
• Proses itu sendiri dapat dinilai untuk memastikan bahwa
hal tersebut memenuhi kriteria proses dasar yang telah
terbukti penting untuk keberhasilan software engineering.
Sejumlah pendekatan yang berbeda pada penilaian software proses
dan perbaikan-perbaikan telah diusulkan selama beberapa dekade
terakhir.

Sejumlah pendekatan yang berbeda pada penilaian software proses

dan improvement telah diusulkan selama beberapa dekade terakhir:
Standard CMMI Assessment Method for process Improvement
(SCAMPI)
CMM-Based Appraisal for Internal Process Improvement (CBA
IPI)
SPICE (ISO/IEC1504)
ISO 9001:2000 for Software
 Capability Maturity Model Integration (CMMI)

Level 5: Optimizing

Level 4 : Quantitatively Managed

Level 3 : Defined

Level 2 : Managed

Level 1 : Performed
Level 0 : Incomplete

For use only at the university level and in conjunction with the book,Software Engineering: A Practitioner's Approach,4/e, McGraw-Hill, 1997.
Transparencies copyright © 1996, R.S. Pressman & Associates, Inc. reproduced with permission.

17
 Capability Maturity Model Integration
(CMMI)

• L 0 : Incomplete, Proses tidak dilakukan atau tidak mencapai semua

tujuan yang didefinisikan pada level 1
• L 1 : Performed, Proses dilakukan, tugas yang dibutuhkan untuk
menghasilkan produk kerja sedang dibangun.
• L 2 : Managed, Orang yang melakukan pekerjaan memiliki sumber daya
yang memadai dalam melakukan pekerjaannya, stakeholder terlibat aktif,
tugas kerja dan produk dipantau, dievaluasi, sesuai deskripsi proses.
• L 3 : Defined, Pengelolaan, dan proses rekayasa terdokumentasi,
terstandar, dan terintegrasi dalam proses perangkat lunak di seluruh
organisasi.
• L 4 : Quantitatively Managed, software process dan produk dipahami
secara terukur dan dikontrol menggunakan ukuran yang detail.
• L 5 : Optimazing, Peningkatan proses yang terus menerus diaktifkan oleh
umpan balik yang terukur dari proses dan ide-ide pengujian yang kreatif.
18
 SEI - CMMI

LEVEL FOKUS
• Optimizing • Continous process
improvement
• Quantitatively Managed • Quantitative management

• Defined • Process standardization

• Managed • Basic project management

• Performed
 LEVEL 3

• Software CMM Level 3

Foster-Miller achieved SW-CMM Level 3 certification in December
of 2005 to processes as defined by the Software Engineering
Institute at Carnegie Mellon ...
www.foster-miller.com/software_cmm_level3.htm
• Weserv Systems International, Inc. (WeServ), a wholly owned
subsidiary of Fujitsu Philippines, Inc., recently passed the
Capability Maturity Model for ...
www.fujitsu.com/ph/news/pr/20041215.html
• 11 October 2013, Jakarta, Indonesia—PT Sigma Cipta Caraka
(telkomsigma); for Finance and Non Banking Solution BU,
Banking Solution BU, Product and Technology BU today
announced that it has been appraised at Level 3 of the CMMI
Institute’s Capability Maturity Model Integration (CMMI).
 CMM LEVEL 4
• CMM Level 4
Certified Company | Software Application Development ...
Trigent is an SEI CMM Level 4 certified company with
development centers in the US and India. Provides
information about Trigent's software application ...
www.trigent.com/company/cmm-certified-company.htm
• On April 16th, Kingdee passed CMM Level 4 evaluation
with the United States' ... At present, less than 100
software companies pass CMM Level 4 worldwide and ...
global.kingdee.com/en/news/dongtai/76/2004-
04/542.htm
 CMM LEVEL 5
• Managing IT: Life After CMM Level 5
More than half the world's CMM Level 5 companies are based in
India. Software firms also used CMM to establish credentials as
developers of quality software ...
www.india-today.com/ctoday/20020401/mit2.html
• SEI CMM Level 5 Wipro is the first software services company in
the world ... We achieved CMM level 5 certification in June,
1999. As part of the CMM level ...
www.wipro.com/aboutus/quality/seicmm.htm
• PT Take United Indonesia
https://www.linkedin.com/company/pt-take-united-indonesia
 CMM LEVEL 5
• http://dqindia.ciol.com/content/advantage/103102703.asp
• Why “India Inside” Spells Quality 
Did you know that 75% of the world’s CMM Level 5
software centers were in India? Here’s how the quality
movement transformed the Indian IT services industry 
Monday, October 27, 2003
Europe, and the need for ISO certification, provided the
trigger to the quality movement in India. But the real
impetus came after Motorola’s software center at Bangalore
became the world’s second CMM Level 5 unit in 1994 (the
first was at NASA)
• Even for those familiar with India’s software industry, this is
a startling number.
• There are 80 software centers on the planet that are
assessed at CMM Level 5.Of all those centers, 60 are in
India.
 Core and the essence of
practice Software Engineering
• Pada level proses, prinsip utama menetapkan sebuah
filosofi dasar yang memandu tim software spt
melakukan aktivitas kerangka kerja dan “umbrella
activities”, menavigasi aliran proses, dan menghasilkan
sekumpulan produk kerja software.
• Pada level practice, prinsip utama menetapkan
sekumpulan nilai dan peran yang berfungsi sebagai
panduan dalam menganalisis masalah, merancang
solusi, mengimplementasikan dan menguji resolusi, dan
akhirnya menyebarkan software pada komunitas user.
 Communication Principles

• Mendengarkan
• Persiapan sebelum berkomunikasi
• Seseorang harus memfasilitasi aktivitas
• Aktivitas komunikasi face to face
• Komunikasi face-to-face adalah yang terbaik
• Catat dan dokumentasikan keputusan
• Berusaha untuk berkolaburasi
• Tetap fokus : modularize your discussion
• Bila sesuatu tidak jelas, gambarkan.
• Sekalinya setuju terhadap sesuatu, move on
• Negotiation adalah bukan sebuah kontes atau sebuah game
 Planning Principles

• Memahami cakupan project

• Melibatkan stakeholders dalam aktivitas perencanaan
• Memahami bahwa perencanaan itu selalu berulang (Recognize
that planning is iterative)
• Memperkirakan berdasarkan pada apa yang anda ketahui
• Pertimbangkan resiko yang didefinisikan pada saat perencanaan.
Be realistic
• Penambahan aturan seperti yang didefisikan pada perencanaan
• Menentukan bagaimana anda bermaksud untuk menjamin
kualitas.
• Menjelaskan bagaimana anda bermaksud untuk mengakomodasi
prubahan.
• Sering menelusuri perencanaan dan membuat penyesuaian yang
diperlukan
 Modeling Principles

• Tujuan utama dari tim software adalah membangun

perangkat lunak, bukan membuat model.
• Jangan membuat lebih banyak model dari yang
dibutuhkan
• Berusaha untuk menghasilkan model yang
sederhana yang akan menyelesaiakan masalah atau
software.
• Membangun model dalam sebuah cara yang
membuat mereka setuju untuk merubah.
• Dapat menyatakan tujuan secara jelas untuk setiap
model yang dibuat.
Lanjutan....modeling principle

• Adaptasi model-model yang kita kembangkan

dengan perubahan yang terjadi pada sistem.
• Cobalah membangun model yang berguna,
tetapi lupa membangun model yang sempurna.
• Jangan kaku dengan sintaks model. Jika model
saat ini dapat mengkomunikasikan isi dgn baik,
penampilan adalah nomer dua
• Jika naluri memberitahu bahwa model tersebut
tidak tepat walaupun tampaknya di atas kertas
baik-baik saja, mungkin kita punya alasan untuk
mempertimbangkan ulang
 Construction Principles

• Coding principles
• Validation Principles
• Testing Principles
 Coding Principles
Preparation principles : Before you write one
line of code, be sure you :
• Memahami masalah yang sedang dipecahkan
• Memahami prinsip dan konsep dasar perancangan
• Memilih bahasa pemrograman yang dibutuhkan
perangkat lunak dan lingkungan dimana akan
beroperasi.
• Memilih lingkungan pemrograman yang menyediakan
tools yang akan membuat pekerjaan menjadi lebih
mudah.
• Membuat sekumpulan pengujian unit yang akan
dijalankan sekalinya komponen yang dikodekan lengkap.
 Programming Principles

• Memahami arsitektur program dan

membuat antarmuka yang konsisten
terhadap arsitektur program
• Membuat logika kondisional sesederhana
mungkin
• Pilih struktur data yang akan memenuhi
kebutuhan perancangan.
 Validation Principes

After you’re completed your first coding

pass be sure you :
• Jika memungkinkan, lakukan penelusuran
kode program yang telah kita tulis untuk
melakukan pemeriksaan kebenaran
sintaks dan logikanya.
• Lakukan pengujian unit dan memperbaiki
kesalahan yang ditemukan.
 Testing Objectives :

• Pengujian adalah proses eksekusi sebuah

program dengan maksud menemukan
kesalahan.
• Sebuah kasus uji yang baik adalah yang
memilii probabilitas tinggi menemukan
kesalahan yang belum ditemukan.
• Pengujian yang sukses salah satunya
adalah bila dapat mengungkap kesalahan
yang belum ditemukan/ tidak diduga
sebelumnya.
 Testing Principles :

• P-1. Semua pengujian harus dilacak sesuai

kebutuhan pelanggan.
• P-2. Pengujian harus direncanakan jauh sebelum
memulai pengujian.
• P-3. Prinsip Pareto berlaku untuk software
testing.
• P-4. Pengujian harus dimulai dari “in the small”
dan menuju ke pengujian”in the large”.
• P-5. Pengujian yang lengkap adalah sesuatu
yang tidak mungkin
 Deployment Principles

• P-1: harapan pelanggan untuk software harus

dikelola.
• P-2: sebuah paket kiriman lengkap harus dirakit
dan diuji.
• P-3: dukungan harus ditetapkan sebelum
software dikirim
• P-4: materi instruksi yang tepat harus disediakan
pada end user.
• P-5: Software yang penuh dengan kesalahan
seharusnya diperbaiki lebih dulu, pengiriman
bisa dilakukan di waktu-waktu selanjutnya.
TERIMA KASIH