Perencanaan Perangkat Lunak

Perencanaan Perangkat
Lunak
Pertemuan ke 9-10
• Proses manajemen proyek perangkat lunak dimulai
dengan sekumpulan aktivitas yang dikumpulkan
secara kolektif, yang disebut dengan perencanaan
proyek. Aktivitas pertamanya adalah melakukan
estimasi untuk mengetahui alokasi waktu, biaya,
sumber daya, dan aktivitas kegiatan pada suatu
proyek. Meskipun estimasi tidak pernah eksak, tetapi
estimasi tidak dapat dihindari dalam pelaksanaan
suatu proyek, karena estimasi merupakan dasar untuk
perencanaan semua aktivitas proyek dan dalam
perencanaan proyek memberikan suatu road map
indikasi kesuksesan proyek.
• Tujuan perencanaan proyek perangkat lunak
adalah untuk memberikan suatu framework bagi
seorang manager untuk melakukan estimasi terhadap
resources, biaya, dan jadwal. Dalam melakukan
estimasi seharusnya mendefinisikan skenario best
case dan worst case sebagai hasil realisasi suatu
proyek.
Ruang Lingkup Perangkat Lunak
• Fungsi mendeskripsikan fungsionalitas produk
perangkat lunak, yang akan digunakan untuk
melakukan estimasi terhadap resources, biaya dan
jadwal selama proses pelaksanaan proyek.
• Performansi mendeskripsikan kebutuhan untuk
pemrosesan dan response time produk perangkat
lunak.
• Interfaces mendeskripsikan kebutuhan interface
dengan perangkat lunak lain, perangkat keras, dan
lingkungan yang digunakan untuk menjalankan
produk perangkat lunak.
• Reliabiliti mendeskripsikan tingkat reliabilitas
terhadap produk perangkat lunak yang dihasilkan.
• Constraint mendeskripsikan batasan-batasan yang
diberlakukan terhadap produk perangkat lunak yang
dihasilkan.
Mesin Penjual Minuman (MPM)
MPM adalah sebuah mesin yang berfungsi untuk menjual
minuman secara otomatis.
Cara kerjanya adalah sebagai berikut:
Seorang pembeli harus memasukkan koin dengan harga
tertentu ke dalam mesin. Kemudian pembeli harus
memasukkan jenis minuman yang dibeli. Jika koin yang
dimasukkan sudah memenuhi syarat harga beli, maka mesin
akan mengeluarkan minuman yang dibeli tersebut.
Beberapa masalah yang mungkin dihadapi oleh mesin adalah:
• Seseorang yang berusaha memasukkan benda, tetapi bukan
koin, ke dalam mesin untuk mendapatkan minuman secara
ilegal
• Seseorang yang iseng memasukkan sampah ke dalam mesin
yang akan menyebabkan kerusakan mesin
• Seseorang yang berusaha menekan tombol-tombol secara
sembarang tanpa prosedur yang benar untuk mengacaukan
mesin
1. Menerima objek dari pembeli untuk membayar minuman
(SRS-MPM-01)
2. Memeriksa apakah objek yang dimasukkan adalah benarbenar
koin yang sah/valid. Hal ini harus dilakukan dengan
cara memeriksa ukuran, berat, dan ketebalan (SRS-MPM-
02)
3. Menerima koin dalam bentuk 1000-an, 500-an, dan 100-
an. Koin dalam bentuk lain akan dianggap sampah oleh
mesin dan akan dikembalikan ke pembeli (SRS-MPM-03)
4. Perhitungan pembayaran ataupun proses pemilihan
minuman hanya akan dilakukan jika koin yang
dimasukkan sudah dideteksi keabsahannya (SRS-MPM-
04)
5. Menerima masukan jenis minuman dari pembeli (SRSMPM-
05)
6. Memeriksa apakah minuman yang dibeli masih tersedia
dalam jumlah cukup, jika tidak mencukupi maka mesin
akan mengembalikan koin secara otomatis dan
memberikan pesan ke pembeli (SRS-MPM-06)
7. Menerima jenis bermacam-macam minuman,
sehingga tabel harga juga harus dapat diubah
setiap saat (SRS-MPM-07)
8. Mengembalikan koin jika pembeli membatalkan
pembelian (SRS-MPM-08)
9. Mengeluarkan jenis minuman yang dibeli jika
tersedia dan jumlahnya memenuhi (SRS-MPM-
09)
10. Mengembalikan koin kepada pembeli jika koin
yang dimasukkan melebihi harga minuman yang
dibeli (SRS-MPM-10)
11. Me-nonaktif-kan tombol pemilihan minuman
setelah minuman dikeluarkan dari mesin, sampai
koin berikutnya terdeteksi keabsahannya (SRSMPM-
11)
Resources
Orang
Komponen S/W yang
Dapat Digunakan
Hardware/Software
Tools
Orang
• Kebutuhan Orang yang akan terlibat
dalam proyek perangkat lunak meliputi
manajer (manajer proyek, manajer
konfigurasi, dan manager quality
assurances), software engineer (analyst,
designer, programmer, tester), dan tenaga
pendukung administrasi.
Komponen software
• adalah mengacu pada pengembangan
produk perangkat lunak dengan
menggunakan block-block dengan tujuan
untuk mudah dalam melakukan reference,
mengaplikasikan, memvalidasi, dan
mengintegrasikan. Sehingga untuk
perencanaan proyek perangkat lunak yang
akan dikerjakan dapat memiliki kategori
sebagai berikut :
1. Off-the-shelf components. Perangkat lunak
sudah ada (dari proyek sebelumnya) dan siap
digunakan untuk current proyek tanpa adanya
modifikasi.
2. Full-experience components. Spesifikasi,
analysis, design, code, dan data test sudah ada
(dari proyek sebelumnya) dapat digunakan untuk
current proyek dengan melakukan sedikit
modifikasi.
3. Partial-experience components. Spesifikasi,
analysis, design, code, dan data test yang sudah
ada dari proyek sebelumnya dapat digunakan
untuk current proyek dengan melakukan
modifikasi substasi masing-masing.
4. New components. Komponen perangkat lunak
dibangun oleh team software engineer mulai dari
awal untuk kebutuhan current proyek.
Hardware/software tools
• adalah berhubungan dengan kebutuhan
perangkat keras dan perangkat lunak lain
yang dibutuhkan pada pengembangan
proyek produk perangkat lunak.
Estimasi Proyek Perangkat Lunak
• Estimasi adalah kegiatan pengujian/perkiraan
nilai/jumlah dari sesuatu yang akan dihitung,
umumnya berdasarkan pada model-model
probabilistic.
• Kegunaan estimasi sebagai dasar perencanaan
meliputi alokasi resources, biaya, dan jadwal,
sebagai pendukung proses pengambilan
keputusan meliputi pengadaan resources dan
aktivitas
Estimasi Proyek
ESTIMASI
PROYEK
Perencanaan
Sistem
Perencanaan
Proyek
Manajemen
Proyek
Pengendalian
Proyek
Pengendalian
Biaya
Peng-Auditan
Proyek
Review Rinci
Proyek
Basis Data Ketrampilan
dan Produktivitas
Basis Data Informasi
Biaya
Metoda-metoda estimasi
1. Algorithmic Model. Model ini dikembangkan dari
review proyek (sebelumnya) dan relasi matematik
yang menghubungkan antara biaya dan ukuran
perangkat lunak (umumnya jumlah baris kode
program / KLOC (Kilo Line of Code)). Contohnya
adalah Model COCOMO (Constructive Cost
Model)
2. Expert Judgment. Hasil konsultasi dengan satu
atau beberapa pakar yang diputuskan dengan
konsensus.
3. Analogical Estimation. Menggunakan analogi
satu atau beberapa proyek yang sejenis yang
sudah selesai dikerjakan.
4. Parkinson Law. Biaya ditetapkan oleh
ketersediaan resources. Misalnya, perangkat
lunak di deliver selama 12 bulan dan jika tersedia
5 orang, maka estimasi usaha = 60 bulan-orang.
5. Winning Price. Estimasi menggunakan harga
yang dipercaya akan menyelesaikan pekerjaan
(sesuai / yang dapat dianggarkan).
6. Functional Estimation. Estimasi didasarkan pada
fungsi lojik dari arsitektural perangkat lunak. Biaya
di estimasi ke dalam fungsi global dan dipecah ke
dalam sub-sub fungsi. Contohnya adalah model
Function Point.
7. Design Estimation. Estimasi biaya diperoleh dari
penjumlahan biaya komponen elementer
perangkat lunak, misalnya unit modul penyusun
perangkat lunak
Kesimpulan Metoda
• Dari sekian metoda estimasi yang perlu
diperhatikan adalah tidak ada metoda
yang lebih baik/jelek antara satu dengan
yang lainnya. Setiap metoda memiliki
kelebihan dan kekurangan, sehingga
untuk mendapatkan estimasi yang baik
seharusnya beberapa metoda harus dikaji
secara sejajar dan kemudian hasilnya
dibandingkan

s/w requirement

S/W Requirement
Pertemuan ke-3
2
Definisi
• Webster Dictionary:
– Something required; something wanted or needed
• IEEE Standard 729:
– A condition or capability needed by a user to solve a
problem or achieve an objective
– A condition or capability that must be met or possessed
by a system to satisfy a contract, standard,
specification, or other formally imposed document
3
Fase Requirement
S/W Requirement
S/W Design
dst
System Requirement
System design
H/W Requirement S/W Requirement
H/W Design S/W Design
Pembangunan S/W Pembangunan Sistem
dst dst
4
Hasil Requirement
The interface
The system
The environment
5
SRS
(S/W Requirement Specification)
• Dokumen yang berisi deksripsi lengkap
mengenai apa kemampuan S/W (what)
tanpa menjelaskan bagaimana (how) S/W
akan melaksanakan kemampuan tsb.
6
Aktivitas Fase Requirement
The seed idea
Problem analysis
Product description
Delineating constraint
Refining constraint
Trade-off between conflicting constraints
A relatively complete understanding of requirement
A consistent and complete SRS
Understanding the problem
Expanding information
Consistency checking
congealing
7
Mengapa SRS diperlukan ?
• Banyak kesalahan yang timbul pada fase
requirement
• Kebanyakan kesalahan tidak dideteksi sejak
dini
• Kebanyakan kesalahan tsb sebenarnya bisa
dideteksi lebih dini
• Dengan tidak mendeteksi kesalahan sejak
dini, biaya perbaikan akan bertambah tinggi
8
Mengapa SRS diperlukan ? (2)
• Akibat kesalahan fase requirement:
– S/W yang dihasilkan tidak sesuai dengan
kebutuhan user
– Interpretasi yang berbeda terhadar kebutuhan
user dapat menyebabkan perbedaan pandangan
antara user dan developer
– Pengujian S/W akan sulit dilakukan
– Waktu dan biaya habis untuk membangun S/W
yang salah
9
Apa yang harus ada pada SRS ?
• Antarmuka eksternal sistem dengan
lingkungannya :
– S/W lain
– Port komunikasi
– H/W
– User
10
Apa yang harus ada pada SRS ? (2)
• Dua tipe:
– Behavioral: what the system does
– Non behavioral, a.l.:
• Level of efficiency
• Reliability
• Security
• Maintainability
• Portability
• Visibility
• Capacity
11
Apa yang tidak perlu ada pada SRS ?
• Project requirement:
– staffing, schedule, costs, milestones, activities, phases,
reporting procedures)
• Designs
• Product assurance plan:
– Configuration management plan
– V&V plan
– Test plan
– Quality assurance plan
12
Atribut SRS yang baik
• Correct
• Unambiguous
• Complete
• Verifiable
• Consistent
• Understandable by
customers
• Modifiable
• Traced
• Traceable
• Design independent
• Annotated
• Concise
• Organized
13
Standard SRS
• DOD DI-MCCR-80025A
• NASA’s SMAP-DID-P200-SW
• IEEE/ANSI 830-1984
14

Pengantar Software Engineering

Pengantar Software
Engineering
Pertemuan ke-1
Apa Itu Software ?
Software merepresentasikan masalah di dunia
nyata
Software <> Program
Software, meliputi :
Data
Program
Dokumen (Requirement, analisis,
design, implementasi, pengujian
pemeliharaan)
Solusi untuk masalah yang komplek harus dibuat
dengan cara sistematik
Karakteristik S/W
S/w merupakan komponen logik, bukan fisik
(seperti bangunan dan komputer)
S/W pengembangannya berbeda dengan
produk manufaktur yang umum
S/W tidak mengenal masa wear out
S/W dibangun berdasarkan kebutuhan,
bukan komponen yang sudah ada
Krisis Software
Dalam pengembangan S/W sering terjadi
permasalahan :
Keterlambatan
Over Budget
Kurang berkualitas
Software Engineering
Teknologi yang harus digunakan oleh setiap
orang/kelompok yang akan membangun s/w,
dengan melalui serangkaian proses,
sekumpulan metode, dan alat bantu (tools)
Alasan Perlu S/W Engineering
Untuk mendapatkan s/w yang benar, dan
membuat s/w menjadi benar
S/W adalah sesuatu yang kompleks dalam
hal :
1. Domain Problem : Business Rule
2. Data Size
3. Solution : Algorithm
Pembangunan s/w harus dikelola dengan
baik untuk memelihara kebenarannya
Produk S/W Engineering
Produk yang diperoleh melalui tahapan
System Developmet Life Cycle (SDLC)
Contoh SDLC
1. Waterfall Model
2. V Model
3. Prototyping
4. Spiral Model
5. RAD Model
Proses S/W Engineering
Management Process
1. Project Management
2. Configuration Management
3. Quality Assurance Management
Technical Process adalah metode yang
harus diaplikasikan pada setiap tahapan
SDLC (Requirement, analisis, design,
implementasi, pengujian, pemeliharaan)
Kapan S/W Engineering
Diaplikasikan
Pre-Project
Project Inititation
Project Realisation
Software Delivery and Maintenances
Siapa Saja Yang Terlibat
Manager
1. Project Managemer
2. Configuration Manager
3. Quality Assurance Manager
Software Developer
1. Analist
2. Designer
3. Programmer
Supporting
1. Administrasi
2. Technical Support
3. Welfare
Permasalahan yang Sering
Muncul Hingga Kini
Perkembangan H/W sangat cepat, melebihi
kemampuan kita membangun S/W
Kemampuan membangun S/W masih
ketinggalan dari kebutuhan akan S/W
Perlu usaha besar untuk membangun S/W
yang sangat handal dan berkualitas
Kemampuan kita untuk memelihara S/W
yang ada tidak didukung oleh design yang
baik dan sumber daya yang memadai
Perspektif Industri
DULU
- Cost untuk H/W tinggi
- H/W oriented Management
- Programming (art form, trial and error)
Sekarang
- Cost untuk S/W tinggi
- Perhatian terhadap S/W tinggi :
Mengapa sangat lama?
Mengapa biaya mahal?
Mengapa error sulit dideteksi di awal?
Mengapa sulit mengukur kemajuan pembangunan
S/W?
Software Aplikasi
System S/W
Real Time S/W
Business S/W
Engineering and Scientific S/W
Embedded S/W
Artificial Intelligen S/W