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
system

The Design Phase 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.
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.