TI1153 Konsep Dan Prinsip Analisis

Restyandito Konsep & Prinsip Analisis Kebutuhan - 1
TI 1153
REKAYASA PERANGKAT LUNAK 1
Rekayasa
Perangkat Lunak
TI1153
Restyandito
e-mail : dito@ukdw.ac.id
website : http://lecturer.ukdw.ac.id/~dito
TI1153 Konsep & Prinsip Analisis Kebutuhan Restyandito - 2
KONSEP & PRINSIP
ANALISIS KEBUTUHAN
Penyebab kegagalan / masalah pada pengembangan software :
requirement yg tidak lengkap 13.1%
keterlibatan pengguna minim 12.4%
kurangnya sumber daya 10.6%
harapan yg tidak realistis 9.9%
kurang dukungan dari management 9.3%
perubahan kebutuhan & spesifikasi 8.7%
kekurangan perencanaan 8.1%
sistem sudah tidak dibutuhkan 7.5%
semua melibatkan identifikasi kebutuhan
Penyebab kegagalan / masalah pada pengembangan software :
requirement yg tidak lengkap 13.1%
keterlibatan pengguna minim 12.4%
kurangnya sumber daya 10.6%
harapan yg tidak realistis 9.9%
kurang dukungan dari management 9.3%
perubahan kebutuhan & spesifikasi 8.7%
kekurangan perencanaan 8.1%
sistem sudah tidak dibutuhkan 7.5%
Analisis Kebutuhan
b
i
a
y
a

u
n
t
u
k

m
e
n
c
a
r
i

d
a
n

m
e
m
p
e
r
b
a
i
k
i

k
e
s
a
l
a
h
a
n
log
scale
1
10
100
Reqmts
0.75
Design
1.00
Code
1.50
Test
3.00
System
test
10.00
Field
use
60-100
Analisis Kebutuhan
TI 1153
Analisis Kebutuhan
identifikasi masalah
spesifikasi
analisis & pemodelan
desain
implementasi
pengujian
Inception Elaboration Construction Transition
Analisis Kebutuhan
Tahap
Core Workflows
Requirements
Analysis
Design
Implementation
Testing
iter.
#1
iter.
#2

iter.
#n-1
iter.
#n
Iterasi
Identifikasi Kebutuhan
Identifikasi kebutuhan sistem dapat ditunjukkan dg 2 mode:
domain model: menjelaskan kebutuhan data statis aplikasi
use-case model: menjelaskan kebutuhan proses dinamis
aplikasi
domain model dan use-case model dibangun melalui beberapa
tahap pengembangan
inception phase: identifikasi masalah dan cakupan proyek
elaboration phase: identifikasi sisa kebutuhan (80%)
construction phase: jika masih ada kebutuhan masih dapat
diidentifikasi dilanjutkan implementasi sistem
transition phase: tidak ada lagi identifikasi kebutuhan, kecuali
terjadi perubahan kebutuhan
Identifikasi Kebutuhan (Outline)
Identifikasi Kebutuhan Sistem Umum
Life Cycle Role, Artifacts, Workers and Process
Importance & Difficulty
Process
Identifikasi Kebutuhan Sistem Unified Development Process
Domain Modeling
Use-Case Modeling
User-interface Description & Prototyping
Validating System Requirements
TI 1153
Workers & Artifacts
Use-Case
Specifier
Use-Case
Description
bertanggung
jawab
User-Interface
Designer
User-interface
Description &
Prototyping
bertanggung
jawab
Architect
Architecture
Description
bertanggung
jawab
Domain
Analyst
bertanggung
jawab
Domain
Description
System
Analyst
Domain
Model
Actors Glossary
Use-Case
Model
bertanggung
jawab
WORKERS
system analyst - responsible for the whole set of requirements;
delimits system; finds classes and associations; finds actors and use
cases
domain analyst - assists the system analyst in specifying detailed
descriptions of one or more classes and their associations
architect - describes the architectural view of the use-case model
use-case specifier - assists the system analyst in specifying
detailed descriptions of one or more use cases
user-interface designer - visually shapes the user interface
ARTIFACTS
domain model - a model of the persistent classes and their
associations in the context of the system
use-case model - a model of a system containing actors and use
cases and their relationships captures user requirements
actors - users of the system, outside the system, that collaborate
with the system represents the external environment
glossary - defines important and
used by analysts and other developers
ARTIFACTS
domain description - a description of the classes and
associations in the domain model
use case description - a description of some functionality that the
system offers for an abstraction of a set of scenarios
user-interface description & prototyping - helps us to
understand and specify the interactions between human actors
and the system
architecture description - depicts the architecturally significant
use cases (5-10%); those that describe some important and
critical functionality or the involve some important requirement
TI 1153
UDP - Process
Architect
System
Analyst
Use-Case
Specifier
Find Classes
and Associations
Prioritize
Use Cases
Prototype
User-Interface
Detail
Use Cases
Structure the
Use-Case Model
User-Interface
Designer
Find Actors and
Use Cases
Domain
Analyst
Detail Classes
and Associations
Domain Modeling
identifikasi class yang penting dan asosiasi antar class dalam konteks
sistem
things that exist or events that occur in the systems environment
diperoleh dari
high-level problem statement
lower-level requirements
domain experts (users)
class dapat berupa:
business objects (mis. orders, accounts, dll.)
real-world objects and concepts (mis. suppliers, customers, dll.)
events (kedatangan/keberangkatan pesawat, penjualan, reservasi, dll.)
Domain Modeling
Untuk tiap class harus ditentukan pula attributes
nama yg bermakna
penjelasan singkat
pembayaran transaksi untuk mencatat pembayaran
aliases
synonim
customer = client
akronim
requisition-number = requis-num, reqno
panjang
jumlah digit atau huruf
DOKUMENTASI
nilai yg diijinkan
continuous
harga: Rp. 0,- hingga Rp. 1.000.000.000,-
discrete
status-pernikahan: single, menikah, janda, cerai
encoding - physical representation of the value
supplementary - other information relevant to use of the
attribute
DOKUMENTASI
Domain Modeling
TI 1153
untuk tiap class tambahkan operasi yang dapat dilakukan
untuk tiap asosiasi jelaskan / tentukan :
sebuah nama(optional)
peran (sesuai kebutuhan)
multiplicity
association class (jika dibutuhkan)
DOKUMENTASI
Domain Modeling
District
*
1 1
*
Tinggal-di Tinggal-di
Manusia
Mahasiswa Dosen
District
* 1 Tinggal-di
Domain Modeling
Manusia
Mahasiswa Dosen
District
*
1 1
*
Tinggal-di Tinggal-di
Belajar-di
1
*
Domain Modeling
Use Case Modeling
mengidentifikasi sifat sistem (behavior) dari sudut pandang
pengguna
dibuat berkolaborasi dengan domain model
berfungsi:
identifikasi kebutuhan
merencanakan iterasi pengembangan
memvalidasi sistem
dynamic model dimulai dengan analisis use-case
Semua kebutuhan fungsional dijelaskan dalam use case
TI 1153
sesuatu di luar sistem yang berinteraksi secara
langsung dengan sistem
menyediakan input atau memanfaatkan output dari
sistem
suatu role yang dapat diperankan oleh pengguna
multiple roles per user; multiple users per role
actor name
aktor dapat digunakan sbg sumber utk menemukan use-case
aktor adalah classifier (like a class)
pengguna adalah instance dari classifier
Use Case Model
Actor
Siapa yg berkepentingan terhadap kebutuhan tertentu?
Dimana dalam organsisasi, sistem akan digunakan?
Siapa yg akan diuntungkan dengan penggunaan sistem baru ini?
Siapa yg menyediakan informasi bagi sistem, menggunakan
informasi, dan menghapus informasi dari sistem?
Siapa yg akan men-support dan memelihara sistem?
Apakah sistem menggunakan sumber daya dari luar?
Apakah sistem berinteraksi dengan sistem lain?
Seringkali domain model class
and an actor that represent the same thing
Use Case Model
Actor
MENENTUKAN AKTOR
a specific way of using the system by performing
some part of its functionality
serangkaian kejadian yang disebabkan oleh interaksi
aktor pertimbangkan sudut pandang pengguna
use-case name
Mulai dengan kondisi atau kejadian normal atau biasa
acuhkan pengecualian, alternatif, dll
use case harus dinamai dari persepektif pengguna sebagai
kata kerja aktif
menunjukan deskripsi tujuan dari use case dan definisi
fungsionalitas tingkat tingfi
Use Case Model
Use Case
Apa pekerjaan yang diinginkan aktor untuk dilakukan oleh sistem?
Informasi apa yang diakses (buat, simpan, ubah, hapus, baca)
aktor dari sistem?
Perubahan eksternal apa yg perlu diketahui oleh sistem?
Adakah kejadian di sistem yg perlu diketahui oleh aktor?
Use Case Model
Identifikasi
TI 1153
Pegawai
Manager Salesman
Validate user
Check password Retinal scan
Use Case Model
Identifikasi
a concrete, focused, informal description of a single
use of the system from the viewpoint of a single actor
Jenis-jenis skenario
as-is - describes a current situation (used to understand
the current system)
visionary - describes a future system
evaluation - describes user tasks to be used to evaluate the
system (e.g., acceptance tests)
training - used for introducing new users to the system
Use Case Model
Skenario
Use Case Yang Baik
Use case biasanya merepresentasikan fungsionalitas utama yg
lengkap dari awal hingga akhir.
Mahasiswa pada sistem registrasi UKWD:
memilih matakuliah
didaftarkan pada matakuliah
mendapat tagihan
Berhubungan dengan
kejadian ygutuh!
Registrar pada sistem registrasi UKWD:
menambah kelas
menghapus kelas
mengubah kelas
Berhubungan dengan
Class objek ygsama !
Use Case - Documentation
nama use case
actors yang terlibat
entry conditions
bagaimana dan kapan use case dimulai (termasuk prakondisi)
flow of events
urutan aksi yg diperlukan urutan kejadian yg normal
Interaksi apa yg terjadi antara use case dengan aktor
data apa yg dibutuhkan use case
exit conditions
bagaimana dan kapan use case diakhiri (termasuk postkondisi)
kebutuhan khusus (jika ada)
alternate or exceptional flows (jika ada)
narasi harus event-response oriented
(mis. Sistem melakukan X jika pengguna melakukan Y)
TI 1153
Use Case
<<include>>
beberapa use cases dapat berbagi fungsionalitas yg sama
Pisahkan fungsionalitas tersebut, dan letakkan dalam use case yg
terpisah, dan dihubungkan dengan semua use case yg
membutuhkannya dengan kata <<include>>
Validate user
<<include>>
mendaftar matakul memilih makul
yg diajar
melihat daftar
peserta makul
<<include>> <<include>>
include use case
(biasanya tdk dipanggil
scr langsung oleh user)
use case utama
(dipanggil
langsung oleh
user)
memodelkan kondisi tambahan pada urutan aksi suatu use case
digunakan untuk menunjukkan:
behavior yg opsional
behavior yg terjadi pada kondisi khusus
beberapa sub-flow yang dijalankan
berdasarkan pilihan actor
menambahkan deskripsi use case pada use case yang sudah ada
<<extend>>
(semester invalid)
memilih matkul
extend
use case
main
use case
semester tdk valid
extension
point label
Use Case
<<extend>>
Teknik Spesifikasi Aplikasi
FAST (Facilitated Application Specification
Techniques), pendekatan yg mendorong munculnya
tim gabungan antara pelanggan dan pengembang
yg bekerjasa utkmengidentifkasi masalah,
mengusulkan elemen pemecahan, menegosiasi
pendekatan yg berbeda dan mengkhususkan
rangkaian persyaratan pemecahan awal.
Tahap-tahap FAST:
1. Pertemuan dilakukan di sisi netral dan dihadiri baik oleh
pengembang maupun pelanggan
2. Dibuat aturan main untuk persiapan dan partisipasi
3. Sebuah agenda yg cukup formal diusulkan utk mencakup
semua hal penting ttp tidak terlalu formal agar dapat
mengalirkan gagasan bebas
4. Ada seorang fasilitator untuk mengkontrol pertemuan
5. Digunakan mekanisme definisi dapat merupakan sebuah
lembar kerja, digram flip, stiker dinding, etc)
6. Tujuannya adalah mengidentifikasi masalah, mengusulkan
elemn pemecahan awal dalam suatu atomosfir yg kondusif thd
pencapaian tujuan
TI 1153
Fasilitator
Perekam
Pengembang Pelanggan
Pemasaran
Hal pertama yangharus didiskusikan Hal pertama yangharus didiskusikan
adalah justifikasi untuk produk baru adalah justifikasi untuk produk baru
!
!
Contoh: SafeHome
DESKRIPSI PRODUK
Penelitian kami menunjukkan bahwa pasar untuk sistem keamanan rumah
berkembang pada laju 40% per tahun. Kami ingin memasuki pasar tersebut
dengan membangun sebuah sistem keamanan rumah berbasis mikroprosesor
yg akan melindungi dari dan atau mengenali berbagai situasi yg tidak
diinginkan, seperti tamu tak diundang, api, banjir, dsb.
Produk tsb secara tentatif disebut SafeHome dan akan menggunakan
sensor yg sesuai utk mendeteksi setiap keadaan,dapat diprogram oleh pemilik
rumah, dan akan secara otomatis menelepon sebuah agen pemonitor jika
berhasil mendeteksi suatu keadaan.
Contoh: SafeHome
DAFTAR
OBJEK
detektor asap
sensor pintu
sensor jendela
detektor gerakan
alarm
panel kontrol
display
nomor telpon
DAFTAR
LAYANAN
setting alarm
pemonitoran sensor
pemencetan no telp.
pemrograman panel
pembacaan display
DAFTAR
BATASAN
biaya pembuatan
user friendly
berinterface lgs
dengan telp
DAFTAR
KRITERIA
deteksi kejadian
dalam detik
dapat membuat
skema prioritas

Contoh: SafeHome
SPESIFIKASI MINI
Kontrol Panel
dipasang di dinding
ukurannya kira-kira 20x30 cm
berisi 12 tombol dan kunci khusus
terdapat LCD display
semua interaksi pelanggan terjadi
melalui kunci yg digunakan utk
mengaktifkan dan mematikan
sistem

Contoh: SafeHome
TI 1153
SPESIFIKASI MINI
Perangkat Lunak
Perangkat Lunak SafeHome memungkinkan
pemilik rumah utk mengkonfigurasi sistem
keamanan pada saat sistem diinstal, memonitor
semua sensor yang terhubung ke sistem
keamanan, dan berinteraksi dg pemilik rumah
melalui tombol dan kunci-kunci fungsi yang
diisikan k dalam panel kontrol SafeHome.
Contoh: SafeHome
Contoh: SafeHome
SPESIFIKASI MINI
Perangkat Lunak
Selama instalasi, kontrol panel
SafeHome digunakan untuk
memprogram dan mengkonfigurasi
sistem. Tiap-tiap sensor ditandai
dengan nomor dan tipe, sebuah
password master diprogram untuk
mengunci dan membuka sistem, dan
nomor telepon menjadi in untuk
penekanan tombol nomorpada saat
event sensor berlangsung.
Contoh: SafeHome
SPESIFIKASI MINI
Perangkat Lunak
Semua interaksi dengan SafeHome
diatur oleh subsistem user-interface
yang membaca input yang diberikan
melalui papan ketik dan kunci-kunci
fungsi, tampilan yang menunjukkan
pesan dan status sistem pada
tampilan LCD.

Contoh: SafeHome [ Pemodelan domain fungsional ]
Perangkat Lunak SafeHome
mengkonfigurasi
sistem
sensor
monitor
interaksi dg
pemakai
pembagian horisontal
TI 1153
Contoh: SafeHome [ Pemodelan domain fungsional ]
Perangkat Lunak SafeHome
mengkonfigurasi
sistem
sensor
monitor
interaksi dg
pemakai
p
e
m
b
a
g
i
a
n

f
u
n
g
s
i

s
e
c
a
r
a

v
e
r
t
i
k
a
l
penyelidikan
event sensor
mengaktifkan
fungsi alarm
membaca
status
sensor
identifikasi
jenis event
mengaktifkan
/ mematikan
sensor
mengaktifkan
alarm audible
memasang
no telp
Contoh: SafeHome [ Use Case Modeling ]
tentukan siapa saja actors yang terlibat dalam skenario
siapa aktor utama? aktor kedua?
apa yg ingin dicapai / dibutuhkan oleh aktor bersangkutan?
adakah pra-kondisi yang harus dipenuhi?
adakah pengecualian-pengecualian dalam skenario?
bagaimana aktor tersebut berinteraksi dg sistem?
apa yg harus dilakukan oleh aktor?
adakah pra-kondisi yang harus dipenuhi?
HomeOwner
ConfigurationManager
Sensors
MonitoringSubsystem
HomeOwner memasukkan passwords agar dapat berinteraksi
memperoleh informasi mengenai status rumah
memperoleh informasi mengenai kondisi sensor
menekan panic button jika terjadi keadaan darurat
mengaktifkan / menonaktifkan sistem keamanan
Use-case memulaiPengawasan
Primary Actor PemilikRumah
Tujuan
Mengaktifkan sistem untuk mengawasi sensor saat pemilik
rumah tidak di rumah (atau di dalam rumah)
Pra-Kondisi Sistem telah diprogram untuk memvalidasi password dan
mengenali berbagai macam sensor.
Pemicu Pemilik rumah ingin mengaktifkan fungsi alarm
Skenario Pemilik rumah : mengamati control panel
Pemilik rumah : memasukkan password
Pemilik rumah : memilih pergi atau di rumah
Pemilik rumah : mengamati lampu indikator yg menunjukkan
bahwa sistem sudah aktif
TI 1153
Pengecualian Control panel belum siap: Pemilik Rumah memeriksa
control panel, memeriksa semua sensor
Password yg dimasukkan salah, sistem membunyikan
beep sekali, Pemilik Rumah memasukkan ulang password
yg benar
Pemilik Rumah memilih di rumah, control panel
membunyikan beep 2x dan lampu indikator di rumah
menyala, sesor dihidupkan
Pemilik Rumah memilih pergi, control panel
membunyikan beep 3x dan lampu indikator pergi menyala
TI 1153
Referensi
Pressman, Roger S., Software Engineering: A
Practitioners Approach, 6
th
Edition, McGraw-Hill,
2005 (bab 8)
Pressman,Roger S., Rekayasa Perangkat Lunak:
Pendekatan Praktisi (Buku 1), Penerbit Andi, 2002
(bab 11)
The End
terima kasih

TI1153 Konsep Dan Prinsip Analisis

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TI1153 Konsep Dan Prinsip Analisis

Diunggah oleh

Hak Cipta:

Format Tersedia

Restyandito Konsep & Prinsip Analisis Kebutuhan - 1

Teknik Spesifikasi Aplikasi

Teknik Spesifikasi Aplikasi

TI1153 Konsep & Prinsip Analisis Kebutuhan Restyandito - 40

Anda mungkin juga menyukai