INTERAKSI MANUSIA DAN KOMPUTER

Rekayasa Perangkat Lunak

 Rekayasa perangkat lunak merupakan disiplin ilmu
yang digunakan untuk memahami proses desain
atau siklus desain.
 Desain perangkat lunak merupakan proses interaksi
melalui “Cetak Biru” yang menggambarkan suatu
pandangan menyeluruh dari perangkat lunak yang
akan dikembangkan/bangun, meliputi : proses
desain pada tingkat abstraksi yang tinggi, yang
dapat ditelusuri sampai data spesifik, fungsional
dan lainya
Roles Played by the Manager
and by the Information Specialist
Phase Manager Information Specialist

Planning Define problem Support

Analysis Control System Study

Design Control Design system

Implementation Control Implement system

Use Control Make available

1-4
Phases in the SDLC

1) Planning
2) Analysis
3) Design
4) Implementation
5) Use

7-5
Planning Phase
 Benefits
 Define scope of the project

 Spot potential problems

 Arrange tasks in sequence

 Provide basis for control

7-6
Steps
1. Recognize problem (the trigger)
2. Define problem
3. Set objectives
4. Identify constraints

Recall that objectives, standards, and

constraints are problem-solving elements.

7-7
Steps (cont.)
5.Conduct feasibility study (TENLOS)
 Technical

 Economic return
 Noneconomic return

 Legal and ethical

 Operational

 Schedule

7-8
Steps (cont.)
6.Prepare study project proposal
 Goes to MIS steering committee
7.Approve or disapprove (go/no go)
 Key questions?
1.Will the system accomplish its goals?
2.Is this the best way to go about it?

7-9
Steps (cont.)
8.Establish a control mechanism
 Think in terms of:
 1. What
 2. Who
 3. When (Person-months versus calendar months)

 PERT and CPM network diagrams

PERT (Program evaluation and review technique)

CPM (Critical Peth Methode)

7-10
 The Planning Phase
MIS Steering Comm Manager Systems Analyst
Recognize the
1. problem

Define the
problem
2.
Set system
3. objectives Consult

Identify system
4. constraints

Conduct a
5. feasibility study

Prepare a system
6. study proposal

7. Approve or disapprove the study project

8. Establish a control mechanism

7-11
 The Analysis Phase
MIS Steering
Committee Manager Systems Analyst

1. Announce the system study

2. Organize the project team

3. Define information needs

4. Define system performance criteria

Prepare
5. design
proposal

6. 7-12
Approve or disapprove the design project
MIS Steering Committee Manager Systems Analyst

Prepare the
1. detailed
design

The Design Phase

system

2. Identify
alternate
system
configurations

3. Evaluate
system
configurations

4. Select the
best
configuration

5. Prepare the
implementation
proposal

Approve or disapprove the system

6. implementation 7-13
 The Implementation Phase
MIS Steering Committee Manager Information Specialists

1. Plan the implementation

2. Announce the implementation

3 Obtain the
hardware resources
4 Obtain the software
resources
5
Prepare the database
Control Control 6 Prepare the
physical facilities
7
Educate the
participants and users

8. Cutover the new system

7-14
 The Use Phase
MIS Steering Committee Manager Information Specialists
2
1 Audit the
system
Use the
Control
system
3 Maintain
the
system

4 Prepare
re-
engineering
proposal

Approve or disapprove the

5
reengineering proposal

7-15
 Model air terjun (waterfall)
1. Requirements analysis and spesification
Mengumpulkan apa yang dibutuhkan secara lengkap untuk
kemudian dinalisis guna mendefinisikan kebutuhan yang harus
dipenuhi oleh program yang akan dibangun (fase yang harus
dikerjakan untuk menghasilkan desain lengkap).

2. System and software desain

setelah apa yang dibutuhkan selesai dikumpulkan dan sudah lengkap
maka desain kemudian dikerjakan.

3. Implementation and unit testing

desain program diterjemahkan kedalam kode-kode dengan
menggunakan bahasa pemrograman yang sudah ditentukan.
Program yang dibangun langsung diuji secara unit. Bekerja dengan
baik atau tidak
4. Integration and system testing
penyatuan unit-unit program untuk kemudian diuji secara
keseluruhan (system testing)

4. Operation and maintenance

mengoperasikan program dilingkungannya dengan melakukan
pemeliharaan, seperti penyesuaian atau perubahan untuk adaptasi
dengan situasi yang sebenarnya.
 KAKU  Fase berikutnya dapat
dikerjakan apabila fase sebelumnya
sudah lengkap
 Perubahan-Perubahan sulit
diakomodasi Pada kenyataanya jarang
sekali mitra/pengguna dapat menyusun
kebutuhanya secara lengkap
 Proyek besar sebaiknya dipecah menjadi
sub-proyek sehingga dapat dikerjakan di
beberapa tempat
 Spesifikasi Kebutuhan
 Desainer dan pengguna (customer) mencoba untuk menangkap apa
yang di harapkan pada suatu sistem untuk ada/tersedia
 Dapat dinyatakan dalam bahasa alami/sehari-hari atau bahasa yang
labih presisi seperti halnya analisis tugas yang akan di sediakan

 Desain Arsitektur
 Deskripsi tingkat tinggi tentang bagaimana suatu sistem akan
menyediakan pelayanan yang dibutuhkan
 Memilah sistem kedalam komponen-komponen utama sistem dan
bagaimana mereka saling berhubungan
 Perlu untuk memenuhi baik kebutuhan fungsional maupun yang non
fungsional

 Desain Detail
 Penghalusan komponen-komponen arsitektur dan hubungannya untuk
mengidentifikasi modul-modul yang akan diimplementasikan secara
terpisah
 Penghalusan ditentukan oleh kebutuhan-kebutuhan non fungsional
 Pengkodean dan Test Unit
 Implementasi dan Pengetesan modul-modul individu dalam suatu
bahasa pemrograman yang dapat dieksekusi

 Integrasi dan Pengetesan

 Mengkombinasikan modul-modul untuk menghasilkan komponen-
komponen dari deskripsi arsitektur

 Operasi dan Pemeliharaan

 Produk diantarkan kepada pengguna (customer) dan semua masalah /
perbaikan disediakan oleh desainer saat produk tersebut masih
dipakai
 Bagian terbesar dari siklus hidup
 Verifikasi
 Pendesainan produk secara benar

 Validasi
 Pendesainan produk yang benar

 Jurang formalitas
 Validasi akan selalu bergantung pada beberapa perluasan arti subjektif
dari bukti yang ada

 Manajemen dan Masalah Kontrak

 Desain dalam konteks komersial dan legal
Model Evaluasi Proses Software
 Model evaluasi proses software bersifat
iteratif atau mengandung perulangan.
Hasil proses berupa produk yang semakin
lama semakin lengkap hingga versi
terlengkap dihasilkan sebagai produk akhir.
Dua model dalam evolutionary software
process model.
 <!>Perbaikan dari Model Waterfall yang kaku dan
linear. Waterfall cocok dipakai pada Sistem Besar
dan dibagi menjadi beberapa sub-proyek.
Incremental Model (evolusionary)
Incremental Model
a. Kombinasikan elemen-elemen dari waterfall dengan sifat iterasi/perulangan.
b. Elemen-elemen dalam wateerfall dikerjakan dengan hasil yang berupa produk
dengan spesifikasi tertentu dan fase berulang hingga menghasilkan produk Final.
c. Produk hasil inkrementasi pertama biasanya adalah produk inti (core product)
yaitu produk yang memenuhi kebutuhan dasar.
d. Hasil review akan menjadi bekal untuk pembangunan pada inkrementasi
berikutnya.
e. Model ini cocok jika jumlah anggota tim pengembang/pengembang PL tidak
cukup.
f. Mampu mengakomodasi perubahan secara fleksibel.
g. Produk yang dihasilkan pada inkrementasi pertama adalah produk yang sudah
bisa berfungsi dengan spesifikasi dasar.
h. Mungkin terjadi kesulitan memetakan kebutuhan pengguna.
Spiral Model
 Proses digambarkan sebagai spiral. Setiap loop mewakili suatu fase dari
proses software. Loop paling dalam berfokus pada kelayakan sistem, loop
selanjutnya tentang definisis kebutuhan, loop berikutnya lagi berkaitan
dengan desain sistem dan seterusnya. Setiap loop dibagi menjadi beberapa
sektor :

a. Objective settings (menentukan tujuan)

Menentukan tujuan dari fase yang ditentukan. Perencanaan sudah disiapkan.

b. Risk assesment and reduction (penanganan dan pengurangan resiko).

setiap risiko dianalisis secara detail pada sektor ini. Langkah penanganan
dilakukan, misalnya membuat prototipe.
Spiral Model
c. Development and Validation (Pembangunan dan pengujian)
setelah evaluasi risiko maka model pengembangan sistem dipilih. Misalnya
jika resiko user interface dominan maka dibuatkan prototipe user interface.
d. Planning
proyek dievaluasi atau ditinjau ulang dan diputuskan untuk terus ke fase
selanjutnya atai tidak.

 Pada model spiral, risiko sangat dipertimbangkan. Risiko adalah sesuatu yang
mungkin akan mengakibatkan terjadinya kesalahan. Model spiral merupakan
pendekatan yang realistis untuk PL berskala besar.
RAD adalah model proses pembangunan PL yang inkremental. RAD
menekankan pada siklus pembangunan yang pendek/singkat. RAD
mengadopsi model waterfall dan pembangunan dalam waktu singkat
dicapai dengan menerapkan component based construction. Waktu
yang singkat adalah batasan yang penting untuk model ini. Jika
kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk
menyelesaikan secara komplet software yang dibuat adalah misalnya 60
sampai 90 hari.
• Business Modelling : Menjawab pertanyaan: Informasi apa yang
mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa
yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa
yang mengolah informasi? – (Kebutuhan dari Sistem)
• Data Modelling : Aliran informasi yang sudah didefinisikan disusun
menjadi sekumpulan objek data – (Analisis Kebutuhan dan Data)
• Pocess Modelling: Objek data yang sudah didefinisikan diubah
menjadi aliran informasi yang diperlukan untuk menjalankan fungsi-
fungsi bisnis.
• Application Generation: RAD menggunakan komponen program
yang sudah ada atau membuat komponen yang bisa digunakan lagi
• Testing dan Turnover: Komponen yang sudah ada sudah melalui
pengujian. Namun demikian komponen baru dan interface harus
tetap diuji.
 Aturan desain menyarankan bagaimana meningkatkan tingkat kegunaan
 Standar
 Diatur oleh organisasi nasional atau internasional seperti ISO atau
BSI untuk memastikan kepastian pemenuhan syarat-syarat tertentu
oleh komunitas besar para desainer
 Standar memerlukan teori mendasar dan secara pelan mengubah
teknologi
 Standar perangkat keras berdasarkan faktor fisiologi atau
ergonomi
 Standar perangkat lunak pada faktor psikologi dan teori kognitif
 Standar perangkat keras lebih umum digunakan dibandingkan
dengan standar perangkat lunak
 Perangkat keras harga cenderung mahal dan sulit untuk diubah
 Otoritas tinggi dan level rendah detil
 ISO 9241 mendefinisikan tingkat kegunaan/daya guna sebagi
keefektifan, efisiensi dan kepuasan dengan mana pengguna
menyelesaikan suatu tugas
 ATRIBUT daya guna terdiri dari:

1. EFEKTIVITAS :
 Seberapa tepat, lengkap dan akurat seorang
user dapat mencapai tujuan

2. EFISIENSI :
 Resource yang dikeluarkan oleh seorang user
untuk melakukan dan mencapai tujuan dengan
cepat dan tepat tanpa ada pemborosan

3. KEPUASAN :
 Respons dari user berupa kenyamanan
penggunaan dan sikap positif dalam
menggunakan produk.

35
 Garis Pedoman (guidelines)
 Lebih bersifat saran dan umum
 Banyak buku teks dan laporan penuh berisikan garis pedoman
 Abstrak dari garis pedoman (prinsip) dapat digunakan selama
aktifitas awal siklus hidup
 Garis pedoman detil (petunjuk gaya – style guides) dapat
digunakan selama aktifitas siklus hidup lebih lanjut
 Pemahaman pembeneran untuk garis pedoman ini akan
membantu dalam hal penyelesaian konflik yang terjadi
 Tes akhir tingkat kegunaan berdasarkan pada pengukuran pengalaman
pengguna
 Rekayasa tingkat kegunaan meminta pengukuran tingkat kegunaan
spesifik harus dibuat secara eksplisit/jelas sebagai suatu kebutuhan

 Spesifikasi tingkat kegunaan :

 Atribut / prinsip tingkat kegunaan
 Konsep pengukuran
 Metode pengukuran
 Level kekinian/kasus terburuk/level perencanaan/kasus terbaik

 Permasalahan
 Spesifikasi tingkat kegunaan membutuhkan level detil yang mungkin
tidak bisa didapat di awal desain
 Pemenuhan spesifikasi tingkat kegunaan tidak berarti harus memenuhi
tingkat kegunaan itu sendiri
Dasar Pemikiran Desain
Dasar pemikiran desain adalah informasi yang menjelaskan mengapa suatu
sistem komputer seperti itu adanya.
1. Keuntungan-keuntungan dari dasar pemikiran desain:
a. Komunikasi melalui siklus hidup
b. Penggunaan kembali pengetahuan desain melintasi produk-produk
c. Pelaksanaan disiplin desain
d. Merepresentasikan argumen untuk nilai yang harus dibayar untuk desain
2. Orientasi proses, menjaga urutan pertimbangan dan pembuatan keputusan
3. Orientasi struktur, penekanan pada struktur post hoc alternatif desain
Teknik-teknik dasar pemikiran desain
 Sistem informasi berbasis Issue (Issue-based Inf. Sys)
 Berdasar hasil banyak riset
 Berorientasi proses
 Struktur hierarki issue-issue
 Posisi adalah pemecahan potensial issue
 Argumen memodifikasi hubungan diantara issue
 Analisis ruang desain
 Berorientasi struktur
 Dasar pemikiran psikologis
 Skenario diobservasi pada sistem
 Klaim psikologis sistem dibuat secara ekplisit
 Aspek negatif desain digunakan iterasi desain selanjutnya
 Desain berulang (iteratif) mengatasi permasalahan yang melekat pada
kebutuhan yang tidak lengkap dan sebagai bentuk evaluasi daya guna
untuk mendapatkan umpan balik dengan membangun dan mengevaluasi
Prototype

 Prototipe
 Simulasi atau animasi dari beberapa fitur dari bakal sistem
 Berbagai jenis prototipe
 Throw-away (sekali pakai, buang)
 Incrementasi (bertingkat)
 Evolutionary (evolusi)

 Masalah Manajemen
 Waktu
 Perencanaan
 Fitur non – fungsional
 kontrak
 Storyboard (papan cerita)
 Tidak perlu harus berbasis komputer
 Dapat dianimasikan

 Simulasi fungsional terbatas

 Beberapa bagian dari fungsionalitas sistem disediakan oleh desainer
 Perkakas seperti HyperCard banyak dijumpai sekarang ini
 Teknik dari Wizard of Oz

 Peringatan mengenai desain berulang

 Kelembaman desain – keputusan yang mulanya buruk akan tetap jadi
buruk
 Pendiagnosisan permasalahan derajat kegunaan nyata dalam prototipe
dan bukan hanya sekedar gejala-gejalanya
Prototype

OK?
design prototipe evaluate done

Re design

Gambar. Prototipe dan evaluasi

Kertas mock ups merupakan suatu desain prototipe yang dirancang
diatas kertas yang meliputi elemen-elemennya. Yang pertama dilakukan
adalah membuat sketsa diatas kertas desaindan
mengimplementasikannya dikomputer dan memberikan print out yang
lebih terperinci. Proses ini penting untuk dilakukan sebelum
menggunakan komputer, untuk mengurangi waktu yang digunakan
mendesain sistem.
Kertas Mock-Up – Sketsa interaktif
Dalam kasus tertentu working prototipe hanya dibuat dengan
menggunakan algoritma yang sederhana. Menggunakan data fake,
seperti gambar bukan video atau lainnya. Teknik wizard of oz untuk
menampilkan suatu simulasi interface dan responnya. Working
prototipe bertujuan memberikan suatu gambaran tentag sistem yang
akan dibangun. Skenario dari suatu prototipe adalah sepertiga dari
keseluruhan sistem yang alan dibangun.
Proses Prototype
 Vertical prototype
 Kemampuan sistem hanya ditampilkan sebagian
 Horizontal Prototype
 Semua interface ditampilkan tetapi kemampuanya
tidak ditampilkan
 Skenario Prototype
 Hanya menampilkan sebagian fitur dan fungsi
 <!> Skenario adalah uraian interaksi manusia
dengan komputer dan membantu proses desain
yang berfokus pada keperluan user.
Bila berbicara tentang proyek pemrograman, orang sering
membayangkan bahwa semua kerja harus dilakukan dibelakang
keyboard, mengetik kode-kode. Bayangan itu memang benar untuk
proyek yang berukuran kecil . Namun untuk proyek yang lebih besar,
pemrograman tidak mungkin dapat melakukannya dengan langsung
duduk mengetikkan kode. Diperlukan suatu perencanaan agar proyek
itu dapat sukses.
Apa jadinya jika suatu proyek tidak direncanakan terlebih dahulu?
Maka kemungkinan yang terjadi antara lain : banyak kode sedikit fitur,
banyak bug, banyak waktu yang akan dihabiskan atau kehilangan fitur.
Ada beberapa tipe ide guna memulai suatu proyek :
1. Memperbaiki atau membuat sesuatu lebih baik, meniru atau
memperbaiki sesuatu yang telah dibuat. Dengan berbekal ide ini
maka pembuatan proyek akan memerlukan lebih sedikit langkah
dan lebih sedikit waktu
2. Ide baru dimana pemrograman akan membuat sesuatu yang benar-
benar baru.
3. Kebutuhan pasar yang bisa menjadi hasil dari kombinasi ke dua ide
sebelumnya
Proyek pemrograman selalu dimulai dengan aplikasi dasar guna
meletakkan struktur-struktur tambahan. Area dasar ini sangat
menetukan bentuk interface yang akan dibuat sehingga perlu mendapat
perhatian khusus. Alasannya :
1. kode-kode program berasosiasi dengan kejadian ketika aplikasi
digunakan.
2. Beberapa informasi atau instruksi diberikan end user waktu
memulai penggunaan aplikasi.
3. Kode program yang baik harus bisa dikembangkan pada suatu saat.