Sesi 1 Pendahuluan

TP501 – Pembangunan Perangkat Lunak

Eka Lia Febrianti, S.Kom, M.Kom
Capaian Pembelajaran Materi Perkuliahan

 Mahasiswa mampu menjelaskan prinsip dasar , problem &

solution, model, dan metode pembangunan perangkat lunak.
 Mahasiswa mampu melakukan desain dan implementasi

perangkat lunak yang baik sesuai requirement, dengan

memperhatikan aspek kualitas dan pemeliharaan PL serta
memodelkan hasil desain dan implementasi PL dengan
menggunakan UML Dan DFD dengan baik dan benar,
secara semantik dan sintak, dan merepresentasikannya
dalam dokumen pembangunan perangkat lunak

2
Topik Bahasan
 Pengertian Perangkat Lunak
 Pengertian Software Engineering
 Evolusi Perangkat Lunak / Software
 Sifat Dan Karakteristik Software
 Komponen Perangkat Lunak
 Masalah Perangkat Lunak

3
Computer Science

4
Pengertian Perangkat Lunak

5
Software Engineering

6
Evolusi Perangkat Lunak

7
Sifat dan Karakteristik Software
 Software merupakan elemen sistem logik dan bukan elemen
sistem fisik seperti hardware
 Elemen itu tidak aus, tetapi bisa rusak.
 Elemen software itu direkayasa atau dikembangkan dan

bukan dibuat di pabrik seperti hardware

 Software itu tidak bisa dirakit/disusun.

8
Komponen Perangkat Lunak
1. Bentuk Bahasa
2. Bentuk Translator
3. Bentuk Mesin

9
Masalah Perangkat Lunak
1. Estimasi jadwal dan biaya yang seringkali tidak tepat
2. Produktivitas orang-orang software(programmer) yang tidak
dapat mengimbangi permintaan kebutuhan software
3. Kualitas software yang kurang baik.

10
Solusi Masalah Perangkat Lunak
1. Memperoleh biaya software yang lebih rendah.
2. Menghasilkan Software berkinerja tinggi , handal dan tepat
waktu.
3. Menghasilkan Software yang dapat bekerja pada berbagai
platform.
4. Menghasilkan software dengan biaya perawatan rendah.

11
It’s Back To Software Engineering
Methodology Process !!!!!

12
Rekayasa Perangkat Lunak Yang Baik
 Memiliki methodology yang cocok dan juga compatible
dengan perangkat lunak yang akan dibangun.
 Mengikuti prinsip dari rekayasa perangkat lunak

13
Prinsip Rekayasa Perangkat Lunak
 The Reason It all Exists 
 Keep It Simple
 Maintain the vision
 What You Produce Other Will Consume
 Be Open To The Future
 Plan Ahead For Reuse
 Think Firts !!!!

14
NEXT ---- > Model dan Metode PPL

15
Sesi 2 Model Dan Metode PPL
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom, M.Kom.
Topik Bahasan
 Waterfall Development Model
 Prototype Development Model
 Rapid Application Development

17
Waterfall Development Model
merupakan paradigma model pengembangan perangkat lunak
paling tua, dan paling banyak dipakai. Model ini mengusulkan
sebuah pendekatan perkembangan perangkat lunak yang
sistematik dan sekuensial yang dimulai pada tingkat dan
kemajuan sistem pada seluruh tahapan analisis, desain , kode,
pengujian, dan pemeliharaan.

18
Tahapan Model Waterfall

19
Waterfall – Analisa Kebutuhan
• Pada tahapan ini dilakukan pengumpulan kebutuhan dari
perangkat lunak yang akan dibangun, dimana kebutuhan itu
meliputi kebutuhan fungsional (Kebutuhan Bisnis) dan
Kebutuhan Non Functional (Performance , Scalability , Dan
Sutainability)

20
 Waterfall – Desain
• Tahapan ini melihat bagaimana perangkat lunak akan dibangun dan
bagaimana sistem akan beroperasi dengan penekanan khusus pada
perangkat keras, perangkat lunak, infrastruktur jaringan dan antarmuka
pengguna. Tujuan utama tahap ini adalah menciptakan blueprint yang
akan memenuhi semua persyaratan yang ada pada analisa kebutuhan,
kemudian mengidentifikasi semua input, proses dan output yang
dibutuhkan dan juga untuk membantu menghindari kesalahpahaman
dengan melibatkan para pemangku kepentingan seperti manajer dan
pengguna.
• Ada Dua Jenis Design
1. Logical Design
2. Physical Design

21
Waterfall - Pengkodean

Lets Code !!!! .

22
Waterfall - Pengujian
Setelah Proses Pengkodean selesai, dilanjutkan dengan proses
pengujian pada program perangkat lunak, baik Pengujian logika
internal, maupun Pengujian eksternal fungsional untuk
memeriksa segala kemungkinan terjadinya kesalahan dan
memeriksa apakah hasil dari pengembangan tersebut sesuai
dengan hasil yang diinginkan.

1. Unit Testing
2. Integration testing
3. Stress Testing

23
Waterfall - Implementasi
Tahap ini berkaitan erat dengan proses deployment program
yang telah diselesaikan dan diuji , proses deployment
dilakukan dengan memperhitungkan (Server , Jaringan ,
Storage). Pada Tahap Ini Juga terjadi proses instalasi
program yang telah dibuat.

Ada empat cara di mana ini bisa dilakukan.

1. Instalasi langsung,
2. Instalasi parallel
3. Single-Location Installation
4. Instalasi Fase
24
Kelebihan Model Waterfall
 Tahapan proses pengembangannya tetap (pasti), mudah
diaplikasikan, dan prosesnya teratur.
 Cocok digunakan untuk produk software/program yang sudah

jelas kebutuhannya di awal, sehingga minim kesalahannya.

 Software yang dikembangkan dengan metode ini biasanya

menghasilkan kualitas yang baik.

 Documen pengembangan sistem sangat terorganisir, karena

setiap fase harus terselesaikan dengan lengkap sebelum

melangkah ke fase berikutnya.

25
Kekurangan Model Waterfall
 Proyek yang sebenarnya jarang mengikuti alur sekuensial seperti diusulkan, sehingga
perubahan yang terjadi dapat menyebabkan hasil yang sudah didapatkan tim
pengembang harus diubah kembali/iterasi sering menyebabkan masalah baru.
 Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena
komitmen harus dilakukan pada tahap awal proses.
 Sulit untuk mengalami perubahan kebutuhan yang diinginkan oleh
customer/pelanggan.
 Pelanggan harus sabar untuk menanti produk selesai, karena dikerjakan tahap per
tahap, dan proses pengerjaanya akan berlanjut ke setiap tahapan bila tahap
sebelumnya sudah benar-benar selesai.
 Perubahan ditengah-tengah pengerjaan produk akan membuat bingung tim
pengembang yang sedang membuat produk.
 Adanya waktu kosong (menganggur) bagi pengembang, karena harus menunggu
anggota tim proyek lainnya menuntaskan pekerjaannya.

26
Model Prototype
 Dalam Model Prototype, prototype dari perangkat lunak yang
dihasilkan kemudian dipresentasikan kepada pelanggan, dan
pelanggan tersebut diberikan kesempatan untuk memberikan
masukan sehingga perangkat lunak yang dihasilkan nantinya
betul-betul sesuai dengan keinginan dan kebutuhan
pelanggan.
 Perubahan dan presentasi prototype dapat dilakukan berkali-

kali sampai dicapai kesepakatan bentuk dari perangkat lunak

yang akan dikembangkan.

27
Tahapan Model Prototype

28
Prototype – Initial Requirement
 Pelanggan dan pengembang bersama-sama mendefinisikan
format seluruh perangkat lunak, mengidentifikasikan semua
kebutuhan, dan garis besar sistem yang akan dibuat.

29
Prototype - Prototyping
 Membangun prototyping dengan membuat perancangan
sementara yang berfokus pada penyajian kepada pelanggan
(misalnya dengan membuat input dan format output)

30
Prototype - Evaluasi
 Evaluasi ini dilakukan oleh pelanggan, apakah prototyping
yang sudah dibangun sudah sesuai dengan keinginan
pelanggan atau belum. Jika sudah sesuai, maka langkah
selanjutnya akan diambil. Namun jika tidak, prototyping
direvisi dengan mengulang langkah-langkah sebelumnya.

31
Protoype - Code
 Pada tahapan ini prototype yang sudah disetujui / disepakati
diterjemahkan kedalam bahasa pemrograman yang sesuai

32
Prototype – Pengujian Sistem
 Setelah sistem sudah menjadi suatu perangkat lunak yang
siap pakai, kemudian dilakukan proses Pengujian. Pengujian
ini dilakukan dengan White Box, Black Box, Basis Path,
pengujian arsitektur, dll.

33
Prototype - Maintain
 Perangkat lunak yang telah diuji dan diterima pelanggan siap
untuk digunakan. Dan di pelihara , untuk menjaga
sustainability dari program yang dibuat.

34
Kelebihan Model Prototype
 Pelanggan berpartisipasi aktif dalam pengembangan sistem,
sehingga hasil produk pengembangan akan semakin mudah
disesuaikan dengan keinginan dan kebutuhan pelanggan.
 Penentuan kebutuhan lebih mudah diwujudkan.
 Mempersingkat waktu pengembangan produk perangkat lunak.
 Adanya komunikasi yang baik antara pengembang dan pelanggan.
 Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan

pelanggan.
 Lebih menghemat waktu dalam pengembangan sistem.
 Penerapan menjadi lebih mudah karena pelanggan mengetahui apa

yang diharapkannya.

35
Kekurangan Model Prototype
 Proses analisis dan perancangan terlalu singkat.
 Biasanya kurang fleksibel dalam mengahadapi perubahan.
 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.
 Pengembang kadang-kadang membuat kompromi

implementasi dengan menggunakan sistem operasi yang

tidak relevan dan algoritma yang tidak efisien.

36
Rapid Application Development
Rapid Aplication Development (RAD) adalah sebuah model
proses pengembangan perangkat lunak sekuensial linier yang
menekankan siklus perkembangan yang sangat pendek (kira-
kira 60 sampai 90 hari). Model RAD ini merupakan sebuah
adaptasi “kecepatan tinggi” dari model sekuensial linier dimana
perkembangan cepat dicapai dengan menggunakan
pendekatan konstruksi berbasis komponen

37
TAHAPAN RAD

38
RAD – Business Modelling
Fase ini untuk mencari aliran informasi yang dapat menjawab
pertanyaan berikut:

1. Informasi apa yang menegndalikan proses bisnis?

2. Informasi apa yang dimunculkan?
3. Di mana informasi digunakan ?
4. Siapa yang memprosenya ?

39
RAD – Data Modelling
 Selama tahap Pemodelan Data, semua informasi yang
dikumpulkan selama fase Modeling Bisnis dianalisis. Melalui
analisis, informasi dikelompokkan bersama menjadi
kelompok-kelompok berbeda yang dapat berguna bagi
perusahaan. Kualitas setiap kelompok informasi secara hati-
hati diperiksa dan diberi deskripsi yang akurat. Hubungan
antara kelompok-kelompok ini dan kegunaannya
sebagaimana didefinisikan dalam langkah Modeling Bisnis
juga ditetapkan selama fase ini.

40
RAD - Process Modeling
 Aliran informasi yang didefinisikan di dalam fase data
modeling ditransformasikan untuk mencapai aliran informasi
yang perlu bagi implementasi sebuah fungsi bisnis.
Gambaran pemrosesan diciptakan untuk menambah,
memodifikasi, menghapus, atau mendapatkan kembali
sebuah objek data.

41
RAD - Application Generation
 Selain menggunakan bahasa pemrograman generasi ketiga,
RAD juga memakai komponen program yang telah ada atau
menciptakan komponen yang bisa dipakai lagi. Ala-alat bantu
bisa dipakai untuk memfasilitasi konstruksi perangkat lunak.

42
RAD - Testing and Turnover
 Karena proses RAD menekankan pada pemakaian kembali,
banyak komponen program telah diuji. Hal ini mengurangi
keseluruhan waktu pengujian. Tetapi komponen baru harus
diuji dan semua interface harus dilatih secara penuh.

43
Kelebihan RAD
 Lebih efektif dari Pengembangan Model waterfall/sequential
linear dalam menghasilkan sistem yang memenuhi
kebutuhan langsung dari pelanggan.
 Cocok untuk proyek yang memerlukan waktu yang singkat.
 Model RAD mengikuti tahap pengembangan sistem seperti

pada umumnya, tetapi mempunyai kemampuan untuk

menggunakan kembali komponen yang ada sehingga
pengembang tidak perlu membuatnya dari awal lagi sehingga
waktu pengembangan menjadi lebih singkat dan efisien.

44
Kekurangan RAD
 Model RAD menuntut pengembangan dan pelanggan memiliki komitmen di
dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di
dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak
ada, proyek RAD akan gagal.
 Tidak semua aplikasi sesuai untuk RAD, bila system tidak dapat dimodulkan
dengan teratur, pembangunan komponen penting pada RAD akan menjadi
sangat bermasalah.
 RAD tidak cocok digunakan untuk sistem yang mempunyai resiko teknik yang
tinggi.
 Membutuhkan Tenaga kerja yang banyak untuk menyelesaikan sebuah
proyek dalam skala besar.
 Jika ada perubahan di tengah-tengah pengerjaan maka harus membuat
kontrak baru antara pengembang dan pelanggan.

45
What Next
 Agile Software Development
 Evolutionary Software Process Models

46
Sesi 3 Model Dan Metode PPL
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, M.Kom.
Topik Bahasan
 Evolutionary Software Process Models
 Agile Development Model

48
Evolutionary Software Process Models
Model Evolutionary Development bersifat iteratif (mengandung
perulangan). Hasil prosesnya berupa produk yang makin lama
makin lengkap sampai versi terlengkap dihasilkan sebagai
produk akhir dari proses. Model Evolutionary Development /
Evolutionary Software Process terbagi menjadi 2, yaitu :

1. Model Incremental
2. Model Spiral

49
Model Incremental
 Model Incremental merupakan hasil kombinasi elemen-
elemen dari model waterfall yang diaplikasikan secara
berulang, atau bisa disebut gabungan dari Model linear
sekuensial (waterfall) dengan Model Prototype. Elemen-
elemen tersebut dikerjakan hingga menghasilkan produk
dengan spesifikasi tertentu kemudian proses dimulai dari
awal kembali hingga muncul hasil yang spesifikasinya lebih
lengkap dari sebelumnya dan tentunya memenuhi kebutuhan
pemakai.

50
Tahapan Model Incremental

51
Kelebihan Model Incremental
 Personil bekerja optimal.
 mampu mengakomodasi perubahan secara fleksibel, dengan

waktu yang relatif singkat dan tidak dibutuhkan anggota/tim kerja

yang banyak untuk menjalankannya.
 Pihak konsumen dapat langsung menggunakan dahulu bagian-

bagian yang telah selesai dibangun. Contohnya pemasukan data

karyawan.
 Mengurangi trauma karena perubahan sistem. Klien dibiasakan

perlahan-lahan menggunakan produknya setiap bagian demi

bagian.
 Memaksimalkan pengembalian modal investasi konsumen.

52
Kekurangan Model Incremental
 Tidak cocok untuk proyek berukuran besar (lebih dari
200.000 baris coding).
 Sulit untuk memetakan kebutuhan pemakai ke dalam

rencana spesifikasi tiap-tiap hasil dari increament.

53
Model Spiral
Model ini mengadaptasi dua model perangkat lunak yang ada
yaitu model prototyping dengan pengulangannya dan model
waterfall dengan pengendalian dan sistematikanya.  Model ini
dikenal dengan sebutan Spiral Boehm. Pengembang dalam
model ini memadupadankan beberapa model umum tersebut
untuk menghasilkan produk khusus atau untuk menjawab
persoalan-persoalan tertentu selama proses pengerjaan proyek.

54
Tahapan Model Spiral

55
Tahapan Model Spiral
 Tahap Liason:pada tahap ini dibangun komunikasi yang baik dengan calon
pengguna/pemakai.
 Tahap Planning (perencanaan):pada tahap ini ditentukan sumber-sumber
informasi, batas waktu dan informasi-informasi yang dapat menjelaskan proyek.
 Tahap Analisis Resiko:mendefinisikan resiko, menentukan apa saja yang menjadi
resiko baik teknis maupun manajemen.
 Tahap Rekayasa (engineering):pembuatan prototipe.
 Tahap Konstruksi dan Pelepasan (release):pada tahap ini dilakukan
pembangunan perangkat lunak yang dimaksud, diuji, diinstal dan diberikan
sokongan-sokongan tambahan untuk keberhasilan proyek.
 Tahap Evaluasi:Pelanggan/pemakai/pengguna biasanya memberikan masukan
berdasarkan hasil yang didapat dari tahap engineering dan instalasi.

56
Kelebihan Model Spiral
sangat mempertimbangkan resiko kemungkinan munculnya
kesalahan sehingga sangat dapat diandalkan untuk
pengembangan perangkat lunak skala besar. Pendekatan
model ini dilakukan melalui tahapan-tahapan yang sangat baik
dengan menggabungkan model waterfall ditambah dengan
pengulangan-pengulangan sehingga lebih realistis untuk
mencerminkan keadaan sebenarnya. Baik pengembang
maupun pemakai dapat cepat mengetahui letak kekurangan
dan kesalahan dari sistem karena proses-prosesnya dapat
diamati dengan baik..

57
Kekurangan Model Spiral
Waktu yang dibutuhkan untuk mengembangkan perangkat
lunak cukup panjang demikian juga biaya yang besar. Selain
itu, sangat tergantung kepada tenaga ahli yang dapat
memperkirakan resiko. Terdapat pula kesulitan untuk
mengontrol proses. Sampai saat ini, karena masih relatif baru,
belum ada bukti apakah metode ini cukup handal untuk
diterapkan.

58
Agile Software Development
Agile Development Methods adalah sekelompok metodologi
pengembangan perangkat lunak yang didasarkan pada prinsip-
prinsip yang sama atau pengembangan sistem jangka pendek
yang memerlukan adaptasi cepat dari pengembang terhadap
perubahan dalam bentuk apapun. Agile memiliki pengertian
bersifat cepat, ringan, bebas bergerak, dan waspada

59
Agile Alliance’s Manifesto
 Interaksi dan personel lebih penting daripada proses dan alat, di dalam agile
interaksi antar anggota tim sangatlah penting, karena tanpa adanya interaksi yang
baik maka proses pembuatan perangkat lunak tidak akan berjalan sesuai rencana.
 Perangkat lunak yang berfungsi lebih penting daripada dokumentasi yang lengkap,
saat melakukan proses demonstrasi kepada klien, perangkat lunak yang berfungsi
dengan baik akan lebih berguna daripada dokumentasi yang lengkap.
 Kolaborasi dengan klien lebih penting daripada negosiasi kontrak, salah satu ciri
dari agile adalah klien menjadi bagian dari tim pengembangan perangkat lunak.
Kolaborasi yang baik dengan klien saat proses pembuatan perangkat lunak
sangatlah penting ketika menggunakan agile. Karena fungsi-fungsi dari perangkat
lunak yang dikembangkan harus terus menerus dibicarakan dan diimprovisasi
disesuaikan dengan keinginan klien.
 Respon terhadap perubahan lebih penting daripada mengikuti rencana, agile
development methods berfokus terhadap kecepatan respon tim ketika klien
menginginkan perubahan saat proses pembuatan perangkat lunak.
60
Model Agile Development Method
 Acceptance Test Driven Development (ATDD)
 Agile Modeling
 Adaptive Software Development (ASD)
 Crystal Methods
 Dynamic Systems Development Method (DSDM)
 Scrum
 Extreme Programming
 Kanban

61
Tahap Utama Agile Development Method

62
Kelebihan Agile Development Methods
 Proses Iterative dan Incremental
 Requirement dapat berubah sewaktu-waktu
 Pelacakan requirement dengan melihat Backlog produk
 Keterlibatan user secara aktif
 Rilis yang lebih cepat dan berkala, fungsi dirilis setiap akhir

iterasi
 Testing dilakukan setiap saat

63
Kekurangan Agile Development Method
 Agile jarang dipraktekkan secara langsung
 Interksi dengan customers yang berlebihan
 Agile sulit diimplementasikan dalam proyek yang berskala

besar
 Membutuhkan manajemen tim yang terlatih
 Lemah dalam perencanaan arsitektur, 2 Scrum dan Extreme

Programming
 Keterbatasan waktu dalam perencanaan Proyek

64
What Next
 Software Quality

65
Sesi 4 Software Quality
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom.M.Kom.
Topik Bahasan
 Apa Yang Dimaksud Dengan Software Quality
 Kriteria Software Yang Berkualitas
 Kualitas Software menurut Mc Call

67
Bagaimana Menilai Suatu Software ???

68
Software Quality
Software quality adalah pemenuhan terhadap kebutuhan
fungsional dan kinerja yang didokumentasikan secara eksplisit,
pengembangan standar yang didokumentasikan secara
eksplisit, dan sifat-sifat implisit yang diharapkan dari sebuah
software yang dibangun secara profesional 

69
Kriteria Software Berkualitas
 Memenuhi kebutuhan pemakai.

 Memenuhi standar pengembangan software.

 Memenuhi sejumlah kriteria implisit.

70
Mc Call Software Quality
McCall dan kawan-kawan pada tahun 1977 telah mengusulkan
suatu penggolongan faktor-faktor atau kriteria yang mempengaruhi
kualitas software. Pada dasarnya, McCall menitikberatkan faktor-
faktor tersebut menjadi tiga aspek penting, yaitu yang berhubungan
dengan:

 Sifat-sifat operasional dari software (Product Operations)

 Kemampuan software dalam menjalani perubahan (Product

Revision
 Daya adaptasi atau penyesuaian software terhadap lingkungan

baru (Product Transition)

71
Product Operation
Sifat-sifat operasional suatu software berkaitan dengan hal-hal
yang harus diperhatikan oleh para perancang dan
pengembang yang secara teknis melakukan penciptaan
sebuah aplikasi. Hal-hal yang diukur di sini adalah yang
berhubungan dengan teknis analisa, perancangan, dan
konstruksi sebuah software.

72
Product Operation Lanjutan
Faktor-faktor McCall yang berkaitan dengan sifat-sifat operasional software
adalah:

 Correctness – sejauh mana suatu software memenuhi spesifikasi dan mission

objective dari users;
 Reliability – sejauh mana suatu software dapat diharapkan untuk melaksanakan
fungsinya dengan ketelitian yang diperlukan.
 Efficiency – banyaknya sumber daya komputasi dan kode program yang
dibutuhkan suatu software untuk melakukan fungsinya
 Integrity – sejauh mana akses ke software dan data oleh pihak yang tidak
berhak dapat dikendalikan
 Usability – usaha yang diperlukan untuk mempelajari, mengoperasikan,
menyiapkan input, dan mengartikan output dari software.

73
Product Revision

Setelah sebuah software berhasil dikembangkan dan

diimplementasikan, akan terdapat berbagai hal yang perlu
diperbaiki berdasarkan hasil uji coba maupun evaluasi. Sebuah
software yang dirancang dan dikembangkan dengan baik, akan
dengan mudah dapat direvisi jika diperlukan. Seberapa jauh
software tersebut dapat diperbaiki merupakan faktor lain yang
harus diperhatikan.

74
Faktor-Faktor Product Revision
Faktor-faktor McCall yang berkaitan dengan kemampuan
software untuk menjalani perubahan adalah:

 Maintainability – usaha yang diperlukan untuk menemukan

dan memperbaiki kesalahan (error) dalam software.
 Flexibility – usaha yang diperlukan untuk melakukan

modifikasi terhadap software yang operasional

 Testability – usaha yang diperlukan untuk menguji suatu

software untuk memastikan apakah melakukan fungsi yang

dikehendaki atau tidak

75
Product Transition
Setelah integritas software secara teknis telah diukur dengan
menggunakan faktor product operational dan secara
implementasi telah disesuaikan dengan faktor product revision,
faktor terakhir yang harus diperhatikan adalah faktor transisi –
yaitu bagaimana software tersebut dapat dijalankan pada
beberapa platform atau kerangka sistem yang beragam.

76
Faktor Product Transition
Faktor-faktor McCall yang berkaitan dengan tingkat adaptibilitas
software terhadap lingkungan baru:

 Portability – usaha yang diperlukan untuk mentransfer software

dari suatu hardware dan/atau sistem software tertentu agar dapat
berfungsi pada hardware dan/atau sistem software lainnya.
 Reusability – sejauh mana suatu software (atau bagian software)
dapat dipergunakan ulang pada aplikasi lainnya
 Interoperability – usaha yang diperlukan untuk menghubungkan
satu software dengan lainnya

77
Jadi ???

78
Kesimpulan

79
NEXT
 Software Quality Assurance

80
Sesi 5 Software Quality Assurance
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom, M.Kom.
Topik Bahasan
 Apa Itu Quality Management
 Apa Yang Dimaksud Dengan Software Quality Assurance
 ISO 9001

82
Quality Management

Memastikan tingkat kualitas yang dibutuhkan oleh suatu produk

tercapai . Hal ini meliputi :

1. Menetapkan prosedur dan standar

2. Menerapkan prosedur dan standar untuk produk dan proses
3. Memeriksa prosedur apakah telah diimplementasikan atau
tidak
4. Mengumpulkan dan menganalisis berbagai data berkualitas

83
SQA
Software Quality Assurance adalah proses sistematis untuk
memeriksa apakah sebuah software telah dikembangkan
sesuai dengan kebutuhan yang telah ditentukan sebelumnya
atau tidak.

84
Element SQA
 Software Quality Assurance - pembentukan jaringan prosedur dan
standar organisasi yang mengarah ke perangkat lunak berkualitas
tinggi
 Software Quality Planning - pemilihan prosedur dan standar yang tepat
dari kerangka kerja ini dan adaptasi ini ke proyek perangkat lunak
tertentu
 Software Quality Control - definisi dan pemberlakuan proses yang
memastikan bahwa prosedur dan standar kualitas proyek sedang
diikuti oleh tim pengembangan perangkat lunak
 Software Quality Metrics - mengumpulkan dan menganalisis data
berkualitas untuk memprediksi dan mengontrol kualitas produk
perangkat lunak yang sedang dikembangkan

85
QA And QE ?
QA Tester memiliki tugas utama melaksanakan pengujian
terhadap perangkat atau emulator, membuat alur pengujian,
serta membuat laporan hasil pengujian. Sementara QA
Engineer (QE) biasanya bertugas untuk membuat porgram
pengujian otomatis, membuat laporan pengujian, memberikan
masukan atas aplikasi yang diuji, serta berkomunikasi dengan
pihak-pihak yang berkepentingan, seperti pengembang
UI/UX, back end atau product manager (PM).

86
 Element I
Software Quality Assurance

87
Software Development Standard

88
Kenapa Harus Standar
 Standar menyediakan enkapsulasi praktik terbaik, atau
setidaknya paling tepat.
 Standar menyediakan kerangka kerja di mana proses

jaminan kualitas dapat dilaksanakan.

 Standar membantu kesinambungan pekerjaan ketika
dilakukan oleh orang yang berbeda di seluruh siklus hidup
produk perangkat lunak.

89
 Standards should not be avoided. If they are too
extensive for the task at hand, then they should be
tailored !!!!!!.

90
Pendekatan SDS Sederhana

91
 Element II
Software Quality Planning

92
Software Quality Plan
 Tailoring - SQP harus memilih standar organisasi yang sesuai untuk produk
tertentu
 Standarisasi - SQP harus menggunakan (panggilan keluar) hanya menyetujui
proses organisasi dan standar produk Jika standar baru diperlukan,
peningkatan kualitas harus dimulai
 Elemen - elemen SQP biasanya didasarkan pada elemen-elemen model ISO-
9001 . SQP tidak ditulis untuk pengembang perangkat lunak. Ini ditulis untuk
SQE sebagai panduan untuk SQC dan bagi pelanggan untuk memantau
kegiatan pengembangan
 Hal-hal seperti produksi perangkat lunak, rencana produk perangkat lunak dan
manajemen risiko harus didefinisikan dalam SDP, IP
 Faktor Kualitas tidak boleh dikorbankan untuk mencapai efisiensi. Jangan
mengambil pekerjaan jika proses kualitas tidak dapat ditegakkan

93
 Elemen III
Software Quality Control

94
Metode SQC
SQC melibatkan pengawasan proses pengembangan
perangkat lunak untuk memastikan bahwa prosedur dan STD
sedang diikuti. Kegiatan berikut merupakan SQC:

 Quality Review
 Testing
 Quality Audits

95
Quality Review
 Peer Review
 Walkthrough
 Desk Inspection

96
Test
 Engineering Dry-run
 SQE Dry-run
 TFR

97
Quality Audits
 SQE Audits
 Independent Audit

98
Defect Detection

At Baseline Capture 0
System Requirements Analysis 0 79

D Software Requirements Analysis 0 0 1

E Preliminary Design 0 6 2 10
S
T Detailed Design 1 0 0 0 42
T
E Code 0 0 0 1 2 37
A
C Unit Test 0 0 0 0 0 0 0
G
T Software Integration 1 0 0 0 4 1 0 0
E
E Software Qualification Test 0 0 0 0 0 0 0 0 0

D System Integration 1 0 0 0 4 5 0 0 0
System Test 0 0 0 0 0 0 0 0
Post System Test 0 0 0 0 0 0 0 0 0

% De fe cts Originate d in This Phase That We re Contained By This Phase 93% 33% 91% 81% 86%

% Defects Originated in This Phase Plus Defects

93% 11% 95% 79% 74% 0% 36% 0%
That Escaped From Earlier Phases That Were Contained By This Phase

% De fects Originate d In This Phase Out Of All Defe cts 44% 2% 6% 27% 22% 0% 0% 0%

Chart Data Last Updated: 10/3/01

99
 Element IV
Software Quality Matric

10
0
Metrics Collection
 Software Measurement- proses menurunkan nilai numerik
untuk beberapa atribut produk perangkat lunak atau proses
perangkat lunak. Perbandingan nilai-nilai ini satu sama lain
dan dengan STD memungkinkan penarikan kesimpulan
tentang kualitas produk perangkat lunak atau prosesnya.
 Metric Yang Digunakan Terdiri dari

1. Control Metric
2. Predictor Metric

10
1
The Process of Product Measurement

10
2
Predictor and Control Metrics

10
3
Software Product Metric
Ada dua kategori metrik produk perangkat lunak:

 Metrik dinamis - metrik ini dikumpulkan dengan mengukur

elemen selama eksekusi program. Metrik ini membantu untuk
menilai efisiensi dan keandalan produk perangkat lunak.
Parameter yang dikumpulkan bisa mudah diukur (yaitu waktu
eksekusi, waktu rata-rata antara kegagalan)
 Metrik statis - metrik ini dikumpulkan dengan mengukur

parameter produk akhir dari pengembangan perangkat lunak.

10
4
The Ilities

10
5
Contoh Software Metric

10
6
Lanjutan

10
7
ISO 9001
ISO 9001 adalah ketentuan standar yang diakui secara
internasional untuk sertifikasi Sistem Manajemen Mutu (SMM).

Sistem Manajemen Mutu adalah kemampuan suatu

perusahaan atau penyedia jasa/produk dalam menjaga kualitas
mutu dari produk maupun jasa yang dijualnya. Jika suatu
perusahaan sudah memiliki sertifikasi ISO 9001, maka dapat
dikatakan bahwa produk atau jasa yang ditawarkan
perusahaan tersebut sudah tentu memiliki mutu yang terjamin.

10
8
Manfaat ISO 9001
 Menjamin kepuasan pelanggan terhadap produk/jasa yang dijual
 Meningkatkan kepercayaan pelanggan terhadap perusahaan
 Menanamkan rasa bangga bagi karyawan sehingga memotivasi

mereka untuk bekerja lebih baik lagi

 Mempermudah perusahaan untuk memperoleh bisnis dan mitra

yang lebih baik dan lebih banyak

 Sebagai materi untuk menganalisa kemampuan suatu perusahaan
 Meningkatkan manajemen pengendalian resiko sehingga

perusahaan lebih stabil

 Sistem perusahaan jadi semakin rapi dan terarah

10
9
Prinsip ISO 9001

11
0
ISO 9001 Element
Quality System Requirements Software Quality Responsibilities
 Management Responsibility  Management Responsibility
 Quality system  Quality system
 Contract review  Contract review
 Design Control  Design Control
 Document control  Document control
 Purchasing  Purchasing
 Purchaser supplied product  -
 Product identification and traceability  Product identification and traceability
 Process control  Process control
 Inspection and testing  Inspection and testing
 Inspection, measuring and test equipment  -
 Inspection and test status  Inspection and test status
 Control of non-conforming product  -
 Corrective action  Corrective action
 Handling, storage, preservation, packaging and shipping  -
 Quality records  Quality records
 Internal quality audits  Internal quality audits
 Training  Training
 Servicing  -
 Statistical techniques  Statistical techniques

11
1
Next
 Software Maintenance

11
2
Sesi 6 Software Maintenance
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom, M.Kom.
Topik Bahasan
 Apa Yang Dimaksud Dengan Software Maintenance
 Jenis-Jenis Software Maintenance
 Masalah-Masalah Yang Terdapat Pada Maintenance

11
4
Software Maintenance
Perawatan perangkat lunak (software maintenance) adalah
aktivitas yang dimulai sejak perangkat lunak mulai digunakan
(after delivery) hingga akhirnya perangkat lunak tersebut tidak
dapat digunakan lagi (retired).

11
5
Kenapa Harus Maintenance
 Market Conditions
 Client Requirements
 Host Modifications

11
6
Tujuan Software Maintenance
 to correct
 to improve
 to adapt
 to prevent.

11
7
Ada 4 Kategori Perawatan Perangkat Lunak Yaitu :

1. Corrective Maintenance
2. Adaptive Maintenance
3. Perfective Maintenance
4. Preventive Maintenance

11
8
Aktifitas Pemeliharaan
IEEE menyediakan kerangka aktifitas untuk pemeliharaan perangkat
lunak :

 Identification & Tracing

 Analysis
 Design
 Implementation
 System Testing
 Acceptance Testing
 Delivery 
 Maintenance management 

11
9
Kenapa Biaya Maintenance Kadang Lebih Tinggi Dibandingkan
Dengan Biaya Produksi !!!!!!

12
0
Software Lifecycle Cost

12
1
Maintenance Cost Factor
 Structure of Software Program
 Programming Language
 Dependence on external environment
 Staff reliability and availability

12
2
Stabilitas Tim

Biasanya tim pengembang dan tim pemelihara adalah orang

yang berbeda karena tim pengembang biasanya sudah lari ke
proyek baru sehingga tim pemeliharanya tidak begitu paham
atas sistem yang dikembangkan.

12
3
Tanggung Jawab Kontrak
Kontrak bagi pengembang dan pemelihara kebanyakan
terpisah atau diberikan kepada perusahaan yang berbeda dan
bahkan bukan pengembang sistem aslinya, akibatnya tidak ada
insentif bagi pengembang untuk membuat sistem yang mudah
untuk diubah.

12
4
Keahlian Staff
staff pemelihara kebanyakan tidak berpengalaman dalam hal
pemeliharaan software dan staff pemelihara sering diaangap
tidak memerlukan keahlian yang mendalam di bidang software.

12
5
Umur dan Struktur Program
Program yang sudah tua biasanya strukturnya sudah
terdegradasi oleh perkembangan jaman sehingga sangat sulih
dipahami oleh pemelihara.

12
6
Masalah – Masalah Yang Sering Ditemui
 Kesulitan melakukan pelacakan evolusi software pd versi
sebelumnya,
 Kesulitan pelacakan pada proses pengembangan software,
 Sulit untuk mengerti program orang lain,
 Tidak adanya dokumentasi yang baik,
 Tidak adanya nara sumber,
 Kebanyakan software dirancang tanpa adanya pemikiran

untuk diubah.

12
7
NEXT

 Masalah – Masalah Yang Sering Ditemui Pada Saat Proses

Instalasi Program Selesai

12
8
 Sesi 7 SMLC
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom, M.Kom.
Topik Bahasan
 Apa Itu SMLC
 Tahapan SMLC

13
0
Apa itu SMLC ?
Merupakan Siklus pemeliharaan perangkat lunak yang terdiri
dari beberapa tahapan dimana antara satu tahapan dengan
tahapan lainnya saling berhubungan . SMLC merupakan
bagian dari SDLC. SMLC terdapat pada bagian akhir dari
SDLC

13
1
Tahapan SMLC
 Problem identification 
 Analysis
 Design phase
 Implementation 
 System test 
 Acceptance test 
 Delivery

13
2
Problem Identification
Pada fase ini, permintaan untuk modifikasi dalam perangkat
lunak diidentifikasi dan diberi nomor identifikasi. Setiap
Modifikasi Permintaan (MR) kemudian dinilai untuk
menentukan jenis aktivitas pemeliharaan (korektif, adaptif,
perfective, dan preventif). Setelah klasifikasi, masing-masing
MR diberi skala prioritas untuk menentukan urutan yang akan
diproses.

13
3
Tahapan Problem Identification

13
4
Problem Analysis
Dalam fase ini, kelayakan dan ruang lingkup setiap permintaan
modifikasi yang divalidasi ditentukan dan disiapkan untuk
menggabungkan perubahan dalam perangkat lunak. Atribut
input terdiri dari permintaan modifikasi yang divalidasi,
perkiraan awal sumber daya, dokumentasi proyek, dan
informasi repositori.

13
5
Design Phase
Pada fase ini, modifikasi yang dibuat dalam perangkat lunak
dirancang. Atribut input terdiri dari output yang dihasilkan oleh
fase analisis (analisis rinci), proyek dan dokumentasi sistem,
kode sumber perangkat lunak, dan basis data.

13
6
Implementation
Pada fase ini, modifikasi sebenarnya dalam kode perangkat
lunak dibuat, fitur baru yang mendukung spesifikasi perangkat
lunak yang sekarang ditambahkan, dan perangkat lunak yang
dimodifikasi diinstal. Atribut input terdiri dari kode sumber,
output dari fase desain, dan sistem yang dimodifikasi serta
dokumentasi proyek

13
7
Tahapan implementasi

13
8
System Test
Pada fase ini, pengujian regresi (sejenis pengujian sistem) dilakukan pada
sistem yang dimodifikasi untuk memastikan bahwa tidak ada kesalahan
baru dalam perangkat lunak sebagai akibat dari aktivitas pemeliharaan.
Atribut masukan terdiri dari dokumentasi perangkat lunak yang diperbarui,
laporan tinjauan persiapan tes, dan sistem yang diperbarui.

13
9
Tahapan System Test

14
0
Acceptance Test

Pada fase ini, acceptance test dilakukan pada sistem yang

terintegrasi sepenuhnya oleh pengguna atau oleh pihak ketiga.
Tujuannya adalah untuk mendeteksi kesalahan dan
memverifikasi bahwa fitur perangkat lunak sesuai dengan
persyaratan yang tercantum dalam permintaan modifikasi.
Atribut input terdiri dari sistem yang terintegrasi penuh, rencana
uji, uji kasus, dan prosedur uji.

14
1
Tahapan Acceptance Test

14
2
Delivery
Pada fase ini, sistem perangkat lunak yang dimodifikasi (atau
baru) dikirimkan ke pengguna. Selain itu, pengguna disediakan
dengan dokumentasi yang tepat yang terdiri dari manual dan file
bantuan yang menggambarkan pengoperasian perangkat lunak
bersama dengan spesifikasi perangkat kerasnya. Atribut masukan
terdiri dari versi sistem yang sepenuhnya diuji dan diterima.

14
3
Tahapan Delivery

14
4
Masalah – Masalah Yang Sering Ditemui
 Kesulitan melakukan pelacakan evolusi software pd versi
sebelumnya,
 Kesulitan pelacakan pada proses pengembangan software,
 Sulit untuk mengerti program orang lain,
 Tidak adanya dokumentasi yang baik,
 Tidak adanya nara sumber,
 Kebanyakan software dirancang tanpa adanya pemikiran

untuk diubah.

14
5
NEXT

 SMLC

14
6
Sesi 8 Software Architecture
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom, M.Kom
Topik Bahasan
 Arsitektur Perangkat Lunak

14
8
Arsitektur Perangkat Lunak

Sebuah spesifikasi sistem abstrak yang terdiri dari komponen

fungsional yang dijelaskan dalam hal behaviour dan interface
yang memiliki hubungan interkoneksi. Interkoneksi menentukan
komponen mana yang saling berinteraksi

Bagaimana sistem diurai dan di organisasikan kedalam bentuk

komponen . Dimana komponen tersebut di deskripsikan dalam
bentuk interface.

14
9
Arsitektur Perangkat Lunak (2)
Gambaran bagaimana elemen/komponen fungsional
perangkat lunak / software disusun, diorganisasi dan
distrukturkan sehingga:

◦ Hubungan antar elemen/komponen dapat dijelaskan.

◦ Interface yang menghubungkan elemen/komponen dapat
didefinisikan.
◦ Wujud dan penempatan elemen/komponen dalam tempat
penyimpanan sekunder secara fisik dapat ditetapkan.

15
0
Hubungan Software , Arsitektur , Dan
Infrastruktur

15
1
Jenis Arsitektur Perangkat Lunak
 Data Centered Architectures
 Data Flow Architecture
 Call And Return Architecture
 Layered Architecture
 Event-Based, Implicit Invocation
 Repositories
 Table Driven Interpreters
 Heterogeneous Architectures

15
2
Data Centered Architecture

15
3
Data Flow Architecture

15
4
Call and Return Architecture

15
5
Layered Architecture

15
6
Event-based Architecture

15
7
Repositories

15
8
Table Driven Interpreter

15
9
NEXT

 Object Oriented Analysis And Design

16
0
 Sesi 9 OOAD
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom, M.Kom.
Topik Bahasan
 OOAD
 UML

16
2
Object Ori[ented Analysis And Design

OOAD adalah metode analisis yang memerikasa requirements

dari sudut pandang kelas kelas dan objek yang ditemui dalam
ruang lingkup permasalahan yang mengarahkan arsitektur
software yang didasarkan pada manipulasi objek-objek system
atau subsistem.OOAD merupakan cara baru dalam memikirkan
suatu masalah dengan menggunakan model yang dibuat
menurut konsep sekitar dunia nyata. Dasar pembuatan adalah
objek,yang merupakan kombinasi antara struktur data dan
perilaku dalam satu entitas.

16
3
Konsep Dasar OOAD
 Objek (object)
 Kelas (class)
 Asosiasi dan Agregasi

16
4
Tahapan OOAD

16
5
Kelebihan OOAD
 OOAD lebih mudah digunakan dalam pembangunan sistem
 Waktu pengembangan, level organisasi, ketangguhan,dan penggunaan

kembali (reuse) kode program lebih tinggi dibandingkan dengan metode

OOAD
 Tidak ada pemisahan antara fase desain dan analisis, sehingga

meningkatkan komunikasi antara user dan developer dari awal hingga

akhir pembangunan sistem.
 Analis dan programmer tidak dibatasi dengan batasan implementasi

sistem, jadi desain dapat diformliasikan yang dapat dikonfirmasi dengan

berbagai lingkungan eksekusi.
 Relasi obyek dengan entitas (thing) umumnya dapat di mapping dengan

baik seperti kondisi pada dunia nyata dan keterkaitan dalam sistem. Hal
ini memudahkan dalam mehami desain
16
6
Kelebihan OOAD (2)
 Memungkinkan adanya perubahan dan kepercayaan diri yang tinggi
terhadap kebenaran software yang membantu untuk mengurangi resiko
pada pembangunan sistem yang kompleks
 Encapsulation data dan method, memungkinkan penggunaan kembali pada
proyek lain, hal ini akan memperingan proses desain, pemrograman dan
reduksi harga.
 OOAD memungkinkan adanya standarisasi obyek yang akan memudahkan
memahami desain dan mengurangi resiko pelaksanaan proyek.
 Dekomposisi obyek, memungkinkan seorang analis untuk memcah masalah
menjadi pecahan-pecahan masalah dan bagian-bagian yang dimanage
secara terpisah. Kode program dapat dikerjakan bersama-sama. Metode ini
memungkinkan pembangunan software dengan cepat, sehingga dapat
segera masuk ke pasaran dan kompetitif. Sistem yang dihasilkan sangat
fleksibel dan mudah dalam memelihara
16
7
Kekurangan OOAD
 Pada awal desain OOAD, sistem mungkin akan sangat simple.
 Pada OOAD lebih fockus pada coding dibandingkan dengan SSAD.
 Pada OOAD tidak menekankan pada kinerja team seperti pada
SSAD.
 Pada OOAD tidak mudah untuk mendefinisikan class dan obyek
yang dibutuhkan sistem.
 Sering kali pemrogramam berorientasi obyek digunakan untuk
melakukan anlisisis terhadap fungsional siste, sementara metode
OOAD tidak berbasis pada fungsional sistem.

16
8
Kekurangan OOAD (2)
 OOAD merupakan jenis manajemen proyek yang tergolong
baru, yang berbeda dengan metode analisis dengan metode
terstruktur. Konsekuensinya adalah, team developer butuh
waktu yang lebih lama untuk berpindah ke OOAD, karena
mereka sudah menggunakan SSAD dalam waktu yang lama
 Metodologi pengembangan sistem dengan OOAD
menggunakan konsep reuse. Reuse merupakan salah satu
keuntungan utama yang menjadi alasan digunakannya OOAD.
Namun demikian, tanpa prosedur yang emplisit terhadap reuse,
akan sangat sliit untuk menerapkan konsep ini pada skala besar
(Hantos, 2005).

16
9
UML

UML merupakan singkatan dari “Unified Modelling

Language” yaitu suatu metode permodelan secara visual
untuk sarana perancangan sistem berorientasi objek.
UML adalah suatu bahasa yang sudah menjadi standar pada
visualisasi, perancangan dan juga pendokumentasian sistem
software. Saat ini UML sudah menjadi bahasa standar dalam
penulisan blue print software.

17
0
Tujuan atau fungsi dari penggunaan UML
 Dapat memberikan bahasa permodelan visual kepada pengguna dari
berbagai macam pemerograman maupun proses rekayasa.
 Dapat menyatukan praktek-praktek terbaik yang ada dalam
permodelan.
 Dapat memberikan model yang siap untuk digunakan, merupakan
bahasa permodelan visual yang ekspresif untuk mengembangkan
sistem dan untuk saling menukar model secara mudah.
 Dapat berguna sebagai blue print, sebab sangat lengkap dan detail
dalam perancangannya yang nantinya akan diketahui informasi yang
detail mengenai koding suatu program.
 Dapat memodelkan sistem yang berkonsep berorientasi objek, jadi
tidak hanya digunakan untuk memodelkan perangkat lunak (software)
saja.
 Dapat menciptakan suatu bahasa permodelan yang nantinya dapat
dipergunakan oleh manusia maupun oleh mesin. 17
1
Jenis – Jenis Diagram UML

 Use Case Diagram

 Activity Diagram
 Sequence Diagram
 Class Diagram
 StateMachine Diagram
 Collaboration Diagram
 Component Diagram
 Deployment Diagram

17
2
USE CASE DIAGRAM

17
3
Contoh Use Case Diagram

17
4
Activity Diagram

17
5
Contoh Activity Diagram

17
6
Sequence Diagram

17
7
Contoh Sequence Diagram

17
8
Class Diagram

17
9
Contoh Class Diagram

18
0
Collaboration Diagram

18
1
Component Diagram

18
2
Contoh Component Diagram

18
3
Deployment Diagram

18
4
Contoh Deployment Diagram

18
5
NEXT

 Software Security

18
6
Sesi 10 Software Security
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom, M.Kom.
Topik Bahasan
 Software Security

18
8
18
9
Secure SDLC

19
0
Masalah
 Kenapa masalah keamanan bukan prioritas dalam pembangunan
perangkat lunak
 Penambahan biaya
 Penambahan kebutuhan non-fungsional
 Waktu yang makin panjang untuk implementasinya
 Mengurangi Agilitas Dari Perangkat Lunak Yang Akan Dibangun

19
1
Contoh Kecil Security Pada Software
 Users must authenticate? Is anonymous allowed?
 Password

◦ Length? Strength?
◦ Aging? (History?)
◦ Failed attempts locked out? How many times? How to unlock?
◦ Must be shown with asterisks (*)
 Concurrent access allowed?
 Changes must be logged
 Audit log must provide enough data for forensic

19
2
Statistik Vulneribilitas Perangkat Lunak

19
3
Dasar-Dasar Keamanan Perangkat Lunak
 Confidentiality
 Integrity
 Availability

19
4
Confidentiality
 Confidentiality atau kerahasian menyatakan bahwa data tidak dapat
diakses oleh orang yang tidak berhak.

 Serangan terhadap aspek ini dilakukan dengan berbagai cara seperti

misalnya menyadap jaringan, menerobos akses dari sistem
komputer, sampai ke menanamkan trojan horse dan keylogger6.

 Cara-cara pengamanan terhadap serangan kerahasiaan antara lain

adalah dengan menggunakan kriptografi (yaitu mengubah data
sehingga terlihat seperti sampah), membatasi akses ke sistem
dengan menggunakan userid dan password sehingga ini dikaitkan
juga dengan access control
19
5
Integrity
 Integrity mengatakan bahwa data tidak boleh berubah tanpa ijin
dari pihak yang berhak.
 Serangan terhadap aspek ini dilakukan melalui serangan man in
the middle (MITM). Data transaksi ditangkap (intercepted) di
tengah jalan, dimodifikasi, dan kemudian diteruskan ke tujuan.
Penerima tidak sadar bahwa data sudah berubah dan
memproses yang sudah berubah ini.
 Perlindungan terhadap serangan dapat dilakukan dengan
menambahkan message digest (signature, checksum) dalam
pesan yang dikirimkan secara terpisah sehingga ketika terjadi
perubahan akan terdeteksi di sisi penerima.

19
6
Availability

 Aspek availability menyatakan bahwa data harus tersedia ketika

dibutuhkan.
 Serangan terhadap aspek ini adalah dengan cara membuat
sistem gagal berfungsi, misalnya dengan melakukan permintaan
(request) yang bertubi-tubi. Serangan ini disebut sebagai Denial
of Service (DoS).
 Perlindungan terhadap serangan ini dapat dilakukan dengan
menggunakan sistem redundant dan backup. Keberadaan sistem
yang redundan membuat sistem menjadi lebih tahan terhadap
serangan.

19
7
Security Requirement

 Security requirement dikaitkan dengan faktor yang terkait dengan

keamanan, yaitu confidentiality, integrity, dan availability
 authentication requirement, authorization requirement, auditing
requirement, session management requirement, errors and
exceptions management requirement, configuration parameters
management requirement, sequencing and timing requirement,
archiving requirement, international requirement, deployment
requirement, procurement requirement, antipiracy requirement

19
8
Secure Design

Masalah keamanan ini harus ditemukan dengan segera karena

memperbaiki masalah security setelah software tersebut menjadi
bagian dari production biayanya dapat membengkak seratus (100) kali
lebih mahal

19
9
Prinsip Secure Design
 Economy of mechanism
 Fail-safe defaults
 Akses menggunakan prinsip permission bukan exclusion.
 Complete mediation.
 Open design.
 Separation of privilege.
 Least privilage.
 Least common mechanism.
 Psychological acceptability.

20
0
Secure Coding
 Kecerobohan pemrogram (programmer, coder) dapat
menghasilkan lubang keamanan yang seharusnya tidak ada

20
1
Kesalahan Programmer
 Buffer Overflow
 Exception
 URL With Parameter
 Without use of anti injection
 OWASP TOP 10 List
 CWE / SANS

20
2
Skenario Pengujian Untuk Security
 Normal
 Ekstrim
 Abuse
 Standard Data Set
 Fuzzing

20
3
NEXT

 Software Evaluation

20
4
Sesi 11 Software Evaluation
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom, M.Kom
Topik Bahasan
 Software Evaluation

20
6
Apa Itu Software Evaluation
 Evaluasi perangkat lunak adalah mendefinisikan seberapa
baik perangkat lunak teersebut dapat beroperasi pada
organisasi yang menerapkannya untuk memperbaiki prestasi
di masa mendatang.

20
7
Kenapa Perlu Evaluasi ????

20
8
Tujuan Evaluasi
 Menilai kemampuan teknis Perangkat Lunak
 Menilai pelaksanaan operasional Perangkat Lunak
 Menilai pendayagunaan Perangkat Lunak

20
9
Pihak Yang Dapat Melakukan Evaluasi
Terhadap Sistem
 Tim Audit khusus, yang dikumpulkan untuk maksud tersebut
yang diambil diantara para eksekutif organisasi yang
bersangkutan.
 Tim audit intern, yang mengerjakan unit operasional.
 Organisasi konsultasi di luar organisasi.

21
0
Evaluasi Yang Dapat Dilakukan
 Evaluasi secara menyeluruh
 Evaluasi sistem perangkat keras/ perangkat lunak
 Evaluasi aplikasi

21
1
Proses evaluasi bukan hanya menitikberatkan pada penentuan
kelemahan dan keunggulan SIM saja, tetapi lebih dari itu adalah
pada usaha-usaha perbaikan yang perlu dilakukan !!!!!.

21
2
Evaluasi Fungsi Perangkat Lunak
 Evaluasi sistem perangkat keras/perangkat lunak yang masih
berlaku.
 Evaluasi sistem perangkat keras/perangkat lunak baru atau
pengganti.
 Evaluasi aplikasi 
 Penghitungan manfaat secara kuantitatif dari aplikasi SIM.
 Analisis biaya manfaat dari alternatif desain SIM.

21
3
Evaluasi Perangkat Keras/Perangkat Lunak
yang Masih Berlaku
Tujuan dari evaluasi perangkat keras atau perangkat lunak
yang masih berlaku yaitu untuk menentukan hal-hal berikut :
Apakah ada sumber daya baru yang diperlukan ??.
Apakah ada sumber daya perangkat keras/perangkat lunak
baru yang harus diganti ??
Apakah pengaturan kembali akan memperbaiki daya guna.
Apakah tambahan sumber daya akan memperbaiki
ketepatgunaan sistem.

21
4
Hasil Evaluasi

 Penambahan sumber daya baru

 Penggantian saluran data berkecepatan rendah menjadi

berkecepatan tinggi
 Penambahan kapasitas memori utama

 Peniadaan suatu saluran data yang tidak terpakai

 Penambahan pada unit memori

 Perubahan dalam organisasi memori

 Perubahan dalam perangkat lunak manajemen data

 Perubahan “spooling” perangkat lunak

21
5
Evaluasi perangkat keras/perangkat
lunak baru atau pengganti
 Studi kelayakan
 Penyiapan spesifikasi dan penawaran

21
6
Evaluasi Perangkat Lunak

 Kelayakan teknis (Technical Feasilibility)

 Kelayakan operasional (Operational Feasibility)
 Kelayakan ekonomis (Economic Feasibility)
 Kelayakan hukum (Law Feasibility)
 Kelayakan jadwal (Schedule Feasibility)

21
7
Manfaat Aplikasi
Nilai Suatu Aplikasi atau perangkat lunak dapat berupa :
1. Ekonomis
2. Non Ekonomis

21
8
NEXT

 Software Migration

21
9
Sesi 11 System Migration
TP501 – Pembangunan Perangkat Lunak
Eka Lia Febrianti, S.Kom, M.Kom
Topik Bahasan
 System Migration

22
1
Apa Itu Software Migration
 Pemindahan perangkat lunak yang telah ada ke lingkungan
baru.

22
2
Kenapa Perlu Migrasi ???

22
3
Latar Belakang Migrasi
 Lingkungan dimana perangkat lunak tersebut ditempatkan tidak
dapat lagi menyediakan resource yang maksimal untuk menunjang
runtime dari perangkat lunak tersebut.
 Hardware Cycle Time

22
4
Proses Migrasi
 Extract.
 Transform
 Load

22
5
Evaluasi Yang Dapat Dilakukan
 Evaluasi secara menyeluruh
 Evaluasi sistem perangkat keras/ perangkat lunak
 Evaluasi aplikasi

22
6
Migrasi Nambah Biaya ?

22
7
Scope Migrasi
 Migrasi Sistem.
 Migrasi Data.
 Migrasi Platform 

22
8
Strategi Migrasi
 Dilakukan secara bertahap dan parallel. Parallel disini
dalam arti aplikasi yang menggunakan sistem basis data
lama tetap dipertahankan sampai sistem pendukung basis
data baru dapat menjalankan operasionalnya dengan baik
 Utilitas / mekanisme teknisnya dapat menggunakan :

1. Aplikasi impor atau ekspor data yang biasanya terdapat

pada sistem database baru.
2. Scripting / programming dengan bahasa pemograman
populer seperti c#, perl, php, java, dan lain-lain.

22
9
Masalah Migrasi

 Cost
 Compability
 Reliability
 Security
 Effort

23
0
NEXT

 Back To Start

23
1