Software Development

Brigida Arie Minartiningtyas, M.Kom.

Apa itu Rekayasa
Perangkat Lunak ?
Disiplin ilmu yang membahas semua
aspek produksi perangkat lunak,
mulai dari tahap awal spesifikasi,
desain, konstruksi, testing sampai
pemeliharaan setelah digunakan
Software Engineer harus mengadopsi :

• Pendekatan sistematis dan terorganisir untuk

pekerjaan mereka

• Penggunaan alat dan teknik yang tepat

tergantung pada masalah yang akan dipecahkan

• Kendala pengembangan dan sumber daya yang

tersedia
 COMPUTER SCIENCE CUSTOMER

Computer
Theories Functions
Problems

SOFTWARE
ENGINEERING

Tools & Techniques to solve

problems
 Various roles
Interact
Provide the Software requirements
Software knowledge for engineer
Engineering Software designer/
architect
Software
Engineers Software test engineer
Domain
expert
Software maintenance
Can play the role of engineer
/ manage projects
Software project
End user Is the art and science manager
of building high-quality
+ management software, across ALL ...
phases

Will use
Software Programming
Program Provide the
knowledge for

Developers /
programmers

ONLY

Sumber : https://romisatriawahono.net/se/
Rekayasa perangkat lunak BUKAN (hanya)
pemrograman

• Tapi untuk menjadi software engineer yang baik,

seseorang harus pandai pemrograman

Rekayasa perangkat lunak adalah studi

dan penerapan rekayasa untuk desain,
pengembangan, pengujian, dan
pemeliharaan sistem perangkat lunak
Rekayasa perangkat lunak menangani
masalah seperti:
• Bagaimana dapat mengembangkan perangkat lunak
dalam waktu singkat, biaya terendah dan dengan
kualitas terbaik?
• Bagaimana dapat menguji perangkat lunak dalam waktu
singkat, biaya terendah dan dengan kualitas tertinggi?
• Jika memiliki tim programmer yang besar, bagaimana
dapat menugaskan orang-orang terbaik untuk tugas
pengembangan dan pengujian?
• Bagaimana dapat memastikan bahwa kami telah
menanyakan persyaratan perangkat lunak dari klien
dengan cara yang paling efisien dan efektif?
Tantangan Software
Engineer
Software yang baik :

1. Harus memberikan fungsionalitas

dan kinerja yang dibutuhkan
pengguna perangkat lunak

2. Harus dapat dipelihara, dapat

diandalkan, dan dapat digunakan
Kapan proyek perangkat
lunak dimulai?
Ketika seseorang melihat peluang untuk
menciptakan nilai bisnis dari penggunaan
teknologi informasi

Kemudian dia membuat permintaan sistem

Analisis kelayakan digunakan untuk

membantu dalam keputusan apakah akan
melanjutkan proyek atau tidak
Software Development
Life Cycle
 Planning

Implementation Analysis

Design
Planning : Mengapa Software harus Dikembangkan?
• System request, feasibility analysis

Analysis: Siapa, Kapan Digunakan dan Alur Kerja Software?

• Requirement gathering, business process modeling

Design: Bagaimana Bekerja dan Komposisi dari Software?

• Program design, user interface design, data design

Implementation: Konstruksi dan Penyerahan Software

• System construction, testing, documentation and installation
 Planning
• System Proposal

Implementation Analysis
• New System • System
Spesifiction

Design
• System
Spesification
Planning (System Proposal)
1.User/Product Owner membawa permintaan
kebutuhan (perubahan) software (System Request)
ke System Analyst
2.System Analyst membuat analisis kelayakan
(Feasibility Analysis) dari System Request tersebut
Analysis & Design
3.Setelah dinyatakan layak, System Analyst melakukan
analysis dan design, dan hasilnya adalah System
Specification. Business Analyst membantu System
Analyst memahami proses bisnis dari software yang
akan dibangun
Implementation
4.System Specification diserahkan oleh System Anayst ke
Programmer untuk dilakukan Konstruksi (Coding)
5.Hasil Konstruksi berupa Kode Program diserahkan ke
Software Tester untuk dilakukan Pengujian
(Unit, Integration, System, User Acceptance Testing)
6.Instalasi (delivery) software dan manajemen
perubahan. Software = Kode Program + Dokumentasi
(Pengembangan dan Penggunaan)

Maintenance
7.Siklus kembali ke 1 apabila ada permintaan perubahan
(Permintaan Perubahan Software)
 Project Manager

Business System Software

Programmer
Analyst Analyst Tester

User/Product Owner
User/Product Owner

Pihak yang membutuhkan software

(requirement), yang menganalisis bahwa ada
business value (benefit) apabila suatu proses
bisnis diautomasi menggunakan software
• Kebutuhan dan business value ini diwujudkan dalam
bentuk System Request

Diperlukan skill, pengetahuan dan

pemahaman tentang domain bidang dan
proses bisnis

• Bukan di bidang komputernya

Business Analyst

Fokus pekerjaan membantu user/product

owner di masalah domain dan bidang
(business) dari software
• Nilai bisnis (business value) dari software (sistem)
• Perbaikan bisnis proses yang diperlukan untuk
pengembangan software

Diperlukan skill, pengetahuan dan

pemahaman tentang domain bidang dan
proses bisnis
• Bukan di bidang komputernya
System Analyst

Orang yang menganalisis kebutuhan bisnis,

mengidentifikasi peluang untuk perbaikan, mendesain
software (sistem) untuk mengimplementasikan idenya

Fokus pekerjaan ke software dan sistem informasinya,

bukan domain atau bidangnya

• Bagaimana software bisa meningkatkan ROI dan mempercepat BEP dari

layanan (organisasi)
• Mendesain software dan sistem baru
• Menjamin standard kualitas dari software dan sistem yang dibangun

Diperlukan skill, pengetahuan dan pemahaman tentang

design analysis, programming, business (lesser degree)
Project Manager

Tugas utama di perencanaan, schedule, budget dan

monitoring pekerjaan

Harus bisa memberi jaminan bahwa kebutuhan dan business

value yang diharapkan user/product owner bisa terpenuhi

Mampu mengelola member team development

• Yang tidak semua memiliki kemampuan teknis dan komunikasi yang
baik

Apabila sumber daya manusia terbatas, atau project skala kecil,

bisa dirangkap oleh Systems Analyst
Planning
System Request

Identifikasi Business Value (System

Request)
1.Lower Costs
2.Increase Productivity
3.Increase Profits

Analisis Kelayakan
1.Technical Feasibility
2.Economic Feasibility
3.Organizational Feasibility
 System Request
(Business Value Identification)

Increase
Lower Cost Increase Profit
Productivity

Feasibility Analysis
Organizational
Technical Economic
(Goals, Core
(Capabilities) (ROI, BEP)
Business)
 System Request: Sistem Penjualan Musik Online
Project Sponsor: Margaret Mooney, Vice President of Marketing
Business Needs: Project ini dibangun untuk:
1. Mendapatkan pelanggan baru lewat Internet

2. Meningkatkan efisiensi penanganan masalah pelanggan melalui internet

Business Requirements:
Sistem yang mendukung penjualan musik secara online. Fitur-fitur yang harus ada:
1. Fitur Pencarian Produk
2. Fitur Pencarian Toko yang Menyediakan Stok Produk
3. Fitur Pemesanan Produk Melalui Toko yang Menyediakan
4. Fitur Pembayaran dengan Berbagai Pilihan Pembayaran

Business Value:
Intangible Value:
▪ Meningkatkan kenyamanan dan kepuasan pelanggan
▪ Meningkatkan brand recognition tentang perusahaan di dunia Internet
Tangible Value:
1. Meningkatkan penjualan dari pelanggan baru lewat Internet:
• Rp 400 juta peningkatan penjualan dari pelanggan baru dan Rp 600 juta dari
pelanggan lama
2. Mengurangi biaya operasional untuk menangani komplain dari pelanggan
• Rp 100 juta pengurangan tahunan biaya telepon untuk menangani pelanggan
 System Request – Online ATM System
Project Sponsor: Margaret Mooney, Vice President of Marketing
Business Need: Project ini dibuat dengan tujuan untuk mendapatkan pelanggan
baru yang menggunakan Internet dam memberikan layanan yang
lebih baik ke pelanggan yang ada melalui layanan berbasis
Internet
Business Requirements:
Dengan menggunakan Online ATM System, pelanggan dapat melakukan seluruh
transaksi perbankan. Fitur utama yang ada pada sistem ini adalah:
1. Pengecekan Saldo
2. Pengiriman Uang
3. Transaksi Pembayaran Tagihan

Business Value:
Keuntungan Intangible:
- Meningkatkan layanan ke pelanggan
- Mengurangi komplen dari pelanggan

Keuntungan Tangible:
- $750,000 transaksi keuangan dari pelangan baru
- $1,875,000 transaksi keuangan dari pelanggan lama
- $50,000 pengurangan biaya telepon untuk melayani pelanggan
Feasibility Analysis

Technical feasibility
Can we build it?

Economic feasibility
Should we build it?

Organizational feasibility
If we build it, will they come?
Technical Feasibility
• Familiarity with application: Kurang terbiasa menghasilkan lebih banyak
risiko
• Familiarity with technology: Kurang terbiasa menghasilkan lebih banyak
risiko
• Project size: Proyek besar memiliki lebih banyak risiko
• Compatibility: Semakin sulit mengintegrasikan sistem dengan teknologi
perusahaan yang ada, semakin tinggi risikonya

Economic Feasibility
• Return on Investment (ROI)
• Break Even Point (BEP)
• Intangible Benefit
Organizational Feasibility
• Apakah proyek perangkat lunak secara strategis sejalan dengan bisnis?
Analysis
Pengumpulan dan analisis kebutuhan
(Requirements):
• Siapa yang menggunakan software?
• Apa yang dilakukan oleh software?
• Kapan software digunakan?

Investigasi Software yang Ada (Baseline)

Identifikasi Peluang untuk Perbaikan

Kembangan konsep untuk software baru

Design
Program Design
• Software seperti apa yang ingin dibuat
• Komposisi dan arsitektur dari software
User Interface Design
• Bagaimana pengguna berinteraksi dengan software
• Pahami form/laporan yang digunakan oleh perusahaan
Data Design
• Data apa yang akan disimpan
• Format data yang disimpan
• Dimana data akan disimpan
Paradigm Diagram
Data Oriented Data Flow Diagram

Process Oriented Flowchart

Object Oriented (Data + Process) UML

Implementation
Konstruksi Software (Pembuatan Kode Program)
• Assigning The Programmers
• Coordinating The Activities
• Managing The Schedule
Pengujian Software
• Unit Testing
• Integration Testing
• System Testing
• User Acceptance Test

Dokumentasi
• User Documentation
• System Documentation
Installation
• Software lama dimatikan
• Software baru diaktifkan (instalasi)
 Planning

Implementation Analysis

Design
Requirement

Bagian tersulit dari membangun perangkat lunak adalah

menentukan dengan tepat apa yang dibangun. Tidak ada
pekerjaan konseptual lain yang lebih sulit dari membangun
technical requirements. Tidak ada pekerjaan lain yang
dapat melumpuhkan sistem jika dilakukan dengan salah.

(Brooks, 1987)
Penyebab
Requirements tidak
KEGAGALAN
Kurangnya
perencanaan lengkap (13.1%)
(8.1%)
•Sistem tidak lagi
dibutuhkan (7.5%)

Perubahan Kurangnya
requirements dan keterlibatan
spesifikasi (8.7%) pengguna (12.4%)

Kurangnya
Kurangnya sumber
dukungan
daya (10.6%)
eksekutif (9.3%)

Ekspektasi tidak
realistis (9.9%)
44
Memahami Kebutuhan Pengguna

1. Sampling dokumentasi, formulir, dan database yang ada

2. Penelitian & kunjungan lapangan
3. Observasi lingkungan kerja
4. Wawancara
5. Prototipe
6. Join Requirement Gathering

45
1. Sampling dokumentasi, formulir, dan database yang ada

1. Mengumpulkan fakta dari dokumentasi yang ada

2. Carilah bagan organisasi <untuk menentukan stakeholder>
3. Melacak semua dokumen yang mengarah pada proyek seperti: review kinerja, pengukuran kerja, IS
project request <masa lalu dan masa depan>
4. Melacak semua dokumen yang menggambarkan masalah, SOP, garis besar pekerjaan, instruksi tugas
5. Lacak semua dokumen sistem terdahulu 46
Dikumpulkan dan dianalisis untuk mendapatkan?

1. Penyebab masalahnya
2. Siapa yang bertanggung jawab dan siapa yang memiliki pemahaman terbaik tentang masalah ini
3. Fungsi bisnis
4. Dokumentasi kabur atau ambigu yang akan diminta dalam wawancara 47
2. Penelitian & Kunjungan Lapangan

1. Jika organisasi "mau berbagi“, informasi berharga bisa didapatkan

2. Jurnal komputer dan buku referensi adalah sumber yang baik, 48
 3. Observasi Lingkungan Kerja

Teknik pencarian fakta dimana analis sistem berpartisipasi atau

melihat seseorang melakukan aktivitas untuk belajar tentang sistem
1. Orang merasa tidak nyaman
2. Beberapa aktivitas mungkin terjadi pada waktu yang tidak biasa
3. Beberapa kali orang melakukan pelanggaran SOP

49
 4. Kuesioner

Dokumen yang memungkinkan analis

mengumpulkan informasi dan opini dari responden

(+)
1. Bisa dijawab dengan cepat
2. Murah
3. Bisa memberikan fakta nyata, karena anonim
4. Respon bisa dianalisis dengan cepat

(-)
1. Tidak ada jaminan bahwa seseorang akan
menjawab semua pertanyaan
2. Pertanyaan cenderung tidak fleksibel
3. Tidak bisa mengamati bahasa tubuh
4. Tidak bisa memperbaiki jawaban yang tidak
lengkap
5. Pertanyaan bagus sulit dipersiapkan
50
 5. Interview

1. Bisa memotivasi orang yang diwawancarai untuk merespon secara bebas

dan terbuka terhadap pertanyaan
2. Mendapatkan lebih banyak umpan balik dari orang yang diwawancarai
3. Mampu mengadaptasi pertanyaan untuk masing-masing individu
4. Amati orang yang diwawancarai melalui komunikasi nonverbal 51
 Jenis Interview

1. Tidak terstruktur : biarkan orang yang diwawancarai memberikan kerangka

kerja dan mengarahkan pembicaraan. Pertanyaan terbuka
2. Terstruktur : pewawancara memiliki pertanyaan khusus. Pertanyaan lengkap 52
1. Berpakaian dengan tepat
2. Sopan
3. Dengarkan baik-baik
4. Kontrol wawancara
5. Amati komunikasi non verbal
6. Keep Easy
7. Sabar
8. Kontrol diri
9. Selesai tepat waktu
10. Kirim kembali ringkasan wawancara untuk memperjelas 53
1. Berasumsi jawabannya sudah selesai
2. Mengungkap petunjuk lisan dan nonverbal
3. Menggunakan jargon <kata khusus, kata-kata teknis>
4. Mengungkap bias pribadi anda <prasangka>
5. Berbicara bukan mendengarkan
6. Berasumsi apapun tentang topik tertentu
7. Rekaman

54
6. Join Requiremet Gathering

pertemuan kelompok yang sangat

terstruktur dilakukan untuk menganalisis
dan menentukan kebutuhan

1. Sponsor
2. Fasilitator
3. Pengguna dan manajer
4. Penulis
55
5. Staf TI