SDLC

&Software
Development
Methodologies

Paulus Harsadi, S.Kom

Software Development
Life Cycle

Software Development Life Cycle (SDLC)

Planning

Implementation

Analysis

Design

Project Phases
1. Planning: Why build the system?
Identifying Business Value, Feasibility Analysis

(System Request/Proposal)

2. Analysis: Who, what, when, where will the system be?

User Requirement Gathering (System Specification)

3. Design: How will the system work?

Architecture Design, Interface Design, Data Design, Program
Design (System Specification)

4. Implementation: System delivery

System Construction, Testing, Installation, Maintenance (New

System)

Processes and Deliverables

Process

Product

Planning

System Request
(Proposal)

Analysis
Design

System Specification

Implementation

New System and

Maintenance Plan

Planning
1. Identifying business value (nilai bisnis)
Lower costs
Increase profits

2. Analyze feasibility (analisis kelayakan)

Technical Feasibility
Economic Feasibility
Organizational Feasibility

3. Develop workplan (Mengembangkan rencana

kerja)
4. Staff the project

Analysis
1. Requirement Gathering by answering the
questions:
Who will use the system?
What will the system do?
When will it be used?

2. Investigate the current system

3. Identify possible improvements
4. Develop a concept for new system

Design
1. Architecture design

Hardware description
Software description
Network infrastructure

2. User Interface design

How users interact with system

Forms / reports used by the system

3. Data Design

What data is to be stored

What format the data will be in
Where the data will be stored

4. Program Design
What programs need to be written
Exactly what each program will do

Design
These deliverables:
1.
2.
3.
4.

Architecture design (deployment diagram)

User Interface design
Database design (ER diagram)
Program design (UML)

(System Specification)
The System Specification is given to the
programming team for implementation

Implementation
1. Construction
New system is built and tested
Often testing is the longest part

2. Testing
1.
2.
3.
4.

Unit Testing (Blackbox and Whitebox Testing)

Integration Testing
System Testing
User Acceptance Test

3. Installation
Old system is turned off
New system is turned on

Dokumen perangkat Lunak

Software Project Management Plan (SPMP)

Software Requirement Specification (SRS)
Software Design Description (SDD)
Software Test Plan (STP)
Software Test Description (STD)
Software Test Result (STR)
Software Version
User Guide / User Manual

Software Development
Methodologies

What Is a Methodology?
A formalized approach to implementing
the SDLC (series of steps and
deliverables)
Menulis coding tanpa memikirkan
kebutuhan sistem mungkin berhasil
untuk program kecil, tapi tidak untuk
pekerjaan yang besar

PENGEMBANGAN PERANGKAT LUNAK

Proses dimana persoalan/kebutuhan pemakai diterjemahkan
menjadi produk perangkat lunak melalui suatu rangkaian
aktivitas tertentu sesuai model proses, metode, dan alat
bantu yang digunakan.

State of The Art

Metodologi Pengembangan Perangkat Lunak
1920an, alat bantu flowchart sudah mulai dikenal
Metodologi pengembangan perangkat lunak mulai
dikenal sejak tahun 1960an sejak diperkenalkannya
SDLC (System Development Life Cycle)
1970an : Pemrograman Terstruktur
1980an : Metodologi Analisa dan Perancangan
Sistem Terstruktur (Structured System Analysis and
Design Methodology / SSADM)

State of The Art

Metodologi Pengembangan Perangkat Lunak
1990an :
Object Oriented Programming (OOP)
Rapid Application Development (RAD)
Scrum Development
Team Software Process (dibangun oleh Watts Humphey)
2000an :
Extreme Programming (1999)
Rational Unified Process /RUP (1998)
Agile Unified Process / AUP (2005)
Integrated Methodology (QAIassist IM) (2007)

Major Methodologies
1.

Structured Design
Waterfall Method
Parallel Development

2.

Rapid Application Development (RAD)

Phased Development
Prototyping
Throw-away Prototyping

3.

Agile Development
Extreme Programming (XP)
Scrum

Structured Design Methodology

Projects move methodically from one to
the next step
Generally, a step is finished before the
next one begins

Waterfall Method

Fase Waterfall model

Mendefinisikan dan Menganalisis
kebutuhan
Perancangan System dan Software
Pengujian unit dan Implementasi
Pengujian Sistem dan Integrasi
Pengoperasian dan Pemeliharaan

Kelebihan Waterfall model

Proses-prosesnya mudah dipahami dan jelas

Mudah dalam pengelolaan proyek
Dokumen dihasilkan setiap akhir fase
Sebuah fase dijalankan setelah fase sebelumnya selesai/
Struktur sistem jelas
Mengidentifikasi persyaratan sistem lama sebelum
pemrograman Dimulai, meminimalkan perubahan
persyaratan
Kondisi tepat SDLC Waterfall
Kebutuhan user telah sangat dipahami
Kemungkinan terjadinya perubahan kebutuhan user kecil

Kelemahan Waterfall model

Proyek dunia nyata jarang mengikuti alur proses
Kesulitan jika terjadi perubahan kebutuhan atau
sulitnya mengakomodasi perubahan setelah proses
sedang berlangsung
Waktu pengerjaan bertambah
Ada anggota tim yang harus menunggu pekerjaan
pekerja lain
Kesabaran customer/klien
Pengerjaan ulang sulit dilakukan

Parallel Development
Addresses problem of time gap between
proposal and delivery (mengatasi
kesenjangan)
General process:
1.
2.

Breaks project into parallel subproject

Integrates them at the end

Parallel Development

Rapid Application Development

Merupakan model proses pengembangan
perangkat lunak secara linear
sequential(berurutan) yang menekankan pada
siklus pengembangan yang sangat singkat.

Rapid Application Development

1. Phased development
A series of versions

2. Prototyping
System prototyping

3. Throw-away prototyping
Design prototyping

Rapid Application Development

Critical elements to speed up the SDLC:
1. CASE tools
2. Visual programming languages
3. Code generators

RAD: Phased Development

Break overall system into a series of
versions
Each version has Analysis, Design, and
Implementation
Output from on version is the input to
the next
Incorporate ideas, issues, lessons learned
in one version into the next version

RAD: Phased Development

Pros
Gets useful system
to users quickly
Most important
functions tested most

Cons
Initial system is
intentionally incomplete
(inisialisasi awal
sengaja tdk lengkap)
System requirements
expand as users see
versions
(kebutuhan sistem
bertambah)

RAD: Prototyping
Analysis, Design, Implementation are
performed concurrently (bersamaan)
Start with a "quick-and-dirty" prototype
Menyediakan fungsi yang minimal

Repeat process, refining the prototype

each time (penyempurnaan)
Stop when prototype is a working system

RAD: Prototyping

Kelemahan Prototyping
Walaupun pemakai melihat berbagai
perbaikan dari setiap versi prototype, tetapi
pemakai mungkin tidak menyadari bahwa
versi tersebut dibuat tanpa memperhatikan
kualitas dan pemeliharaan jangka panjang.
Karena perancangan dilakukan secara cepat.
Pengembang kadang-kadang membuat
kompromi implementasi dengan
menggunakan sistem operasi yang tidak
relevan dan algoritma yang tidak efisien.

RAD: Throw-Away Prototyping

Use prototypes only to understand
requirements
Example: use html to show UI

Prototype is not a working design

Once requirements are understood, the
prototypes are thrown away (persyaratan
paham, prototipe di buang)
The system is then built using SDLC

RAD: Throw-Away Prototyping

Kelemahan RAD
Untuk proyek dengan skala besar, RAD
membutuhkan sumber daya manusia yang cukup
untuk membentuk sejumlah tim RAD.
RAD membutuhkan pengembang dan pemakai yang
mempunyai komitmen untuk melaksanakan berbagai
aktivitas melengkapi sistem dalam kerangka waktu
yang singkat.
Akan menimbulkan masalah jika sistem tidak dapat
dibuat secara modular.
RAD tidak cocok digunakan untuk sistem yang
mempunyai resiko teknik yang tinggi.

Agile Development
Just a few rules that are easy to learn and
follow
Streamline the SDLC (merampingkan)
Eliminate much of the modeling and documentation
Emphasize simple, iterative application development

Examples include:
Extreme Programming (XP)
Scrum
Dynamic Systems Development Model (DSDM)

Extreme Programming (XP)

Pendekatan baru untuk
pengembangan berdasarkan
pengembangan dan pengiriman
bertahap sangat kecil dari fungsi yang
ada
Mengandalkan kode perbaikan
konstan, keterlibatan user dalam tim
pengembangan dan pemrograman
berpasangan

Extreme Programming (XP)

pengembangan perangkat lunak yang ringan dan

termasuk salah satu agile methods yang dipelopori
oleh Kent Beck, Ron Jeffries, dan Ward Cunningham.
XP merupakan agile methods yang paling banyak
digunakan dan menjadi sebuah pendekatan yang
sangat terkenal.
Sasaran XP adalah tim yang dibentuk berukuran
antara kecil sampai medium saja, tidak perlu
menggunakan sebuah tim yang besar. Hal ini
dimaksudkan untuk menghadapi requirements yang
tidak jelas maupun terjadinya perubahanperubahan requirements yang sangat cepat.

Extreme Programming (XP)

Core Values of XP
1.
2.
3.
4.

Communication All to All

Simplicity KISS, refactoring
Feedback Embrace Change
Courage Quality First, test and efficient coding

Extreme Programming (XP)

1.
2.
3.
4.
5.

User Stories about system do

Code small program
User Feedback
Repeat
Standards are important
Naming conventions
Coding practices

Extreme Programming

Kelebihan Extreme Programming

Menjalin komunikasi yang baik dengan klien.
(Planning Phase)
Menurunkan biaya pengembangan (Implementation
Phase)
Meningkatkan komunikasi dan sifat saling
menghargai antar developer. (Implementation Phase)
XP merupkan metodologi yang semi formal.(Planning
Phase)
Developer harus selalu siap dengan perubahan arena
perubahan akan selalu diterima, atau dengan kata
lain fleksibel. (Maintenance Phase)

Kelemahan Extreme Programming

Tidak bisa membuat kode yang detail di awal (prinsip
simplicity dan juga anjuran untuk melakukan apa
yang diperlukan hari itu juga).
XP juga memiliki keunggulan yang sekaligus menjadi
kelemahannya, yaitu XP tidak memiliki dokumentasi
formal yang dibuat selama pengembangan. Satusatunya dokumentasi adalah dokumentasi awal yang
dilakukan oleh user.

Spiral Model
Proses digambarkan sebagai spiral bukan sebagai
urutan aktivitas dengan backtracking
Setiap loop dalam spiral merupakan tahap dalam
proses.
Tidak ada fase tetap seperti spesifikasi atau
desain-loop dalam spiral dipilih tergantung pada
apa yang dibutuhkan.
Risiko secara eksplisit dinilai dan diselesaikan
selama proses.

Spiral Model

Spiral model sectors

Setting Tujuan
Tujuan khusus untuk fase identifikasi
Penilaian dan Pengurangan Resiko
Resiko dinilai dan kegiatan disiapkan untuk
mengurangi resiko kunci
Pengembangan dan Validasi
Sebuah model pengembangan untuk sistem terpilih
yang dapat menjadi salah satu model generik
Perencanaan
Proyek terakhir di-review dan fase berikutnya dari
spiral direncanakan

Kelemahan Spiral Model

Sulit untuk meyakinkan pemakai (saat situasi
kontrak) bahwa penggunaan pendekatan ini akan
dapat dikendalikan.
Memerlukan tenaga ahli untuk memperkirakan
resiko, dan harus mengandalkannya supaya
sukses.
Belum terbukti apakah metode ini cukup efisien
karena usianya yang relatif baru.

Rational Unified Process(RUP)

Suatu model proses modern diturunkan dari UML
(Unified Modelling Languange) dan proses-proses
yang terkait di dalamnya.
Terdapat 3 perspektif
Perspektif Dinamik, yang menunjukkan fase dari
waktu ke waktu
Perspektif Statik, yang menunjukkan proses
aktivitas
Perspektif Praktis, yang menyarankan pemakaian
terbaik

Mode Fase RUP

Mode Fase RUP

Inception/ Permulaan
Penetapan kasus bisnis untuk sistem.
Elaboration/ Elaborasi-Perluasan
Pengembangan dan pemahaman domain
masalah dan arsitektur sistem
Construction/ Pembangunan
Perancangan sistem, pemrograman dan uji coba
Transition/ Transisi
Penyebarluasan sistem di lingkungan operasional

Kelebihan RUP
Menyediakan akses yang mudah terhadap pengetahuan
dasar bagi anggota tim.
Menyediakan petunjuk bagaimana menggunakan UML
secara efektif.
Mendukung proses pengulangan dalam pengembangan
software.
Memungkinkan adanya penambahan-penambahan pada
proses.
Memungkinkan untuk secara sistematis mengontrol
perubahan- perubahan yang terjadi pada software
selama proses pengembangannya.
Memungkinkan untuk menjalankan test case dengan
menggunakan Rational Test

Praktek RUP yang baik

Membangun perangkat lunak secara iteratif

Mengelola kebutuhan
Menggunakan arsiterktur berbasis komponen
Perangkat lunak dengan model visual
Memverifikasi kualitas perangkat lunak
Pengendalian terhadapa perubahan perangkat
lunak

Kelemahan RUP
Metodologi ini hanya dapat
digunakan pada pengembangan
perangkat lunak yang berorientasi
objek dengan berfokus pada UML
(Unified Modeling Language)

Selecting the Appropriate Methodology

1.
2.
3.
4.
5.
6.

Clarity of User Requirements

Familiarity with Technology
System Complexity
System Reliability
Short Time Schedules
Schedule Visibility

Selecting the Right Methodology

5 Problems in the Software Development

1. Poor Requirements - if requirements are unclear,
incomplete, too general, and not testable, there may be
problems.
2. Unrealistic Schedule - if too much work is crammed in
too little time, problems are inevitable.
3. Inadequate Testing (test tdk madai)- no one will know
whether or not the software is any good until
customers complain or systems crash.
4. Featuritis - requests to add on new features after
development goals are agreed on.
5. Miscommunication - if developers don't know what's
needed or customer's have erroneous expectations,
problems can be expected.

5 Solutions in the Software Development

1. Solid Requirements - clear, complete,
detailed, cohesive, attainable, testable
requirements that are agreed to by all
players. In 'agile'-type environments,
continuous close coordination with
customers/end-users is necessary to ensure
that changing/emerging requirements are
understood.

5 Solutions in the Software Development

2. Realistic Schedules - allow adequate time for
planning, design, testing, bug fixing, retesting, changes, and documentation;
personnel should be able to complete the
project without burning out.

5 Solutions in the Software Development

3. Adequate Testing (tdk memadai)- start
testing early on, re-test after fixes or
changes, plan for adequate time for testing
and bug-fixing. 'Early' testing could include
static code analysis/testing, test-first
development, unit testing by developers,
built-in testing and diagnostic capabilities,
automated post-build testing, etc.

5 Solutions in the Software Development

4. Stick to Initial Requirements where Feasible bersiaplah untuk membela melawan perubahan
yang berlebihan dan penambahan setelah
pembangunan telah dimulai, dan bersiaplah
untuk menjelaskan konsekuensi. Jika perubahan
diperlukan, mereka harus cukup tercermin
secara perubahan jadwal terkait. Jika
memungkinkan, bekerja erat dengan pelanggan
/ pengguna akhir untuk mengelola ekspektasi.

5 Solutions in the Software Development

5. Communication - membutuhkan penelusuran dan
pemeriksaan saat yang tepat; membuat ekstensif
menggunakan alat komunikasi kelompok groupware, wiki, alat pelacak bug dan mengubah
alat manajemen, kemampuan intranet, dll .;
memastikan bahwa informasi / dokumentasi
tersedia dan up-to-date - sebaiknya elektronik,
bukan kertas; mempromosikan kerja sama tim dan
kerja sama; menggunakan protoypes dan / atau
komunikasi terus-menerus dengan end-user jika
mungkin untuk memperjelas harapan.