Archive for 2016
Perkiraan Pembuatan Project (Estimate Task Durations)
Perkiraan Pembuatan Project
(Estimate Task Durations)
- Optimistic duration (OD) : perkiraan lama minimum waktu yang diperlukan untuk melakukan tugas.
- Pessimistic duration (PD) : perkiraan lama maksimum waktu yang diperlukan untuk melakukan tugas.
- Expected duration (ED) : lama perkiraan waktu yang diperlukan untuk menyelesaikan sebuah tugas.
- Most likely duration (D) : lama perkiraan waktu yang diperlukan untuk menyelesaikan sebuah tugas, berdasarkan nilai rata-rata optimistic, pessimistic, dan expected duration (durasi optimistis, pesimistis, dan diharapkan).
- JUDUL : SISTEM INFORMASI PENJUALAN KASIR TOKO SUMBER REZEKI.
- Pelaksanaan dalam pembuatan aplikasi ini membutuhkan waktu kurang lebih 2 bulan.
- Tahap pelaksanaan.
- Bulan = 24 Hari efektif
- Optimistic Duration (OD) : 40 Days
- Pessimistic Duration (PD) : 70 Days
- Expect Duration (ED) : 50 Days
- Most Likely Duration (D) : 52 Days
PEMODELAN ANALISIS
ELEMEN MODEL ANALISIS
Model analisis harus
dapat mencapai tiga sasaran utama yakni untuk :
·
Menggambarkan apa yang dibutuhkan untuk
pelanggan
·
Membangun dasar bagi pembuatan desain
perangkat lunak
·
Membatasi serangkaian persyaratan yang
dapat divalidasi begitu perangkat lunak dibangun.
Untuk mencapai sasaran
tersebut dibuatlah model analisis yang berisi:
• Data Dictionary
Penyimpanan
yang berisi deskripsi dari semua obyek data yang dikonsumsi atau diproduksi
oleh perangkat lunak.
• Entity Relationship
Diagram (ERD)
Menggambarkan hubungan antara obyek data.
• Data Flow Diagram
(DFD)
o
Memberikan indikasi mengenai bagaiman
data ditransformasi pada saat data bergerak melalui sistem
o
Menggambarkan fungsi-fungsi (dan sub
fungsi) yang mentransformasikan aliran data.
• State Transition
Diagram
Menunjukkan bagaimana sistem bertingkah laku
sebagai akibat dari kejadian eksternal.
• Control
Specification (CSPEC)
Informasi tambahan mengenai aspek kontrol
dari perangkat lunak
PEMODELAN DATA
Pemodelan data
merupakan sebuah tahapan dalam merancang sebuah sistem informasi. Pemodelan
data berfokus pada data apa yang akan disimpan yang menggambarkan hubungan
entara entiti set yang dibutuhkan oleh sebuah organisasi dalam pengelolaan
data.
Untuk dapat menjawab
tentang pemodelan data sebagai berikut :
1.
Bagaimana komposisi dari masing-masing
obyek data dan atribut apa yang menggambarkab obyek tersebut?
2.
Dimana obyek saat ini berada?
3.
Bagaimana hubungan antara masing-masing
obyek data dan obyek lainnya?
4.
Bagaimana hubungan antara obyek dengan
proses yang mentransformasikannya? Digunakan Entity Relational Diagram
(ERD)
1. Obyek Data, Atribut
dan Hubungan
Obyek Data Adalah
representasi dari hamper semua informasi gabungan yang harus dipahami oleh
perangkat lunak. Atribut Menentukan property suatu obyek data dan mengambil
salah satu dari tiga karakteristik yang berbeda.
o
Menamai sebuah contoh dari obyek data
o
Menggambarkan contoh
o
Membujat referensi ke contoh yang lain
pada tabel yang lain.
Hubungan Obyek data disambungkan satu dengan lainnya
dengan berbagai macam cara.
2. Kardinalitas dan
Modalitas Kardinalitas
Model data harus dapat
merepresentasikan jumlah peristiwa dari obyek di dalam hubungan yang diberikan
·
Satu ke satu (1:1) Misalnya: seorang suami hanya dapat memiliki
satu istri, dan seorang istri hanya mempunyai satu suami
·
Satu ke banyak (1:N) Misalnya: seorang
ibu dapat memiliki banyak anak, tetapi seorang anak hanya dapat memiliki satu
ibu
·
Banyak ke banyak (M:N) Misalnya:
seorang paman dapat memiliki banyak keponakan, sementara itu seorang keponakan
dapat memiliki banyak paman
Modalitas Modalitas dari suatu hubungan adalah nol bila
tidak ada kebutuhan eksplisit untuk hubungan yang terjadi atau hubungan itu bersifat opsional.
Modalitas bernilai satu jika suatu kejadian dari hubungan merupakan perintah.
3. Entity Relational
Diagram
Pada mulanya digunakan
untuk desain sistem database relational dan telah dikembangkan oleh yang
lainnya. Serangkaian komponen utama diidentifikasikan untuk ERD: obyek data,
atribut, hubungan dan berbagai tipe indicator. Tujuan utama dari ERD adalah
untuk mewakili obyek data dan hubungan mereka.
PEMODELAN FUNGSIONAL DAN ALIRAN INFORMASI
Informasi
ditransformasikan pada saat dia mengalir melalui sebuah sistem berbasis
komputer. Sistem tersebut menerima input dengan berbagai cara dan menghasilkan
suatu output. Akibatnya kita dapat menciptakan suatu model aliran bagi setiap
sistem berbasis komputer tanpa melihat ukuran dan kompleksitasnya.
1. Diagram Aliran
Data/ Data Flow Diagram (DFD)
Merupakan sebuah
teknik grafis yang menggambarkan aliran informasi dan transformasi yang
diaplikasikan pada saat data bergerak dari input menjadi output. Dikenal juga dengan sebutan grafik aliran
data atau buble chart.
Komponen-komponen DFD
:
·
Proses : menunjukkan apa yang
dikerjakan oleh sistem. Setiap proses memiliki nama yang unik dan nomor yang
ditempatkan dalam simbol.
·
External entity adalah di luar sistem,
tetapi mereka merupakan salah satu bagian yang memberikan input data ke dalam
sistem atau digunakan oleh output sistem
·
Data Flow adalah tempat penyimpanan data
·
Data Store : Proses dapat menempatkan data ke dalam data
store atau mengambil / mendapatkan data store. Setiap data store mempunyai nama
yang unik External Entity
Pemodelan Tingkah Laku
:
Model prilaku
menggambarkan bagaimana PL merespon event atau stimulan eksternal. Untuk model
tersebut, anlisis harus melakukan langkah-langkah sebagai berikut :
·
Evaluasi semua use-case untuk
mendapatkan pemahaman menyeluruh tentang urutan interaksi di dalam sistem.
·
Mengenali event yang mengendalikan
urutan interaksi dan memahami bagaimana event mempunyai relasi terhadap objek
spesifik.
·
Membuat urutan untuk setiap use-case.
·
Membangun state diagram untuk sistem.
·
Review model behavioral untuk
memverifikasi akurasi dan konsistensi
·
Mekanik dari analisis terstruktur
·
Dalam konteks pemodelan perilaku, dua
karakter keadaan harus diperhatikan:
·
Keadaan setiap class ketika sistem
menjalankan fungsinya, dan
·
Keadaan sistem ketika diobservasi dari
luarsebagaimana sistem menjalankan fungsinya.
Keadaan class
mengambil baik karakter aktif maupun pasif [CHA93].
•
Sebuah keadaan pasif adalah status saat
ini dari semua atribut objek.
•
Keadaan aktif dari sebuah objek
menggambarkan status saat ini pada objek tersebut ketika menjalankan
transformasi atau proses.
MEKANIK DARI ANALISIS TERSTRUKTUR
Model Proses Perangkat
Lunak Evolusioner
Model evolusioner
adalah model iteratif. Model itu ditandai dengan tingkah laku yang memungkinkan
perekayasa perangkat lunak mengembangkan versi perangkat lunak yang lebih
lengkap sedikit demi sedikit.
Model Pertambahan
Model inkremental
menggabungkan elemen-elemen model sekuensial linier dengan filosofi prototipe
iteratif. Pada saat model pertambahan dipergunakan, pertambahan pertama sering
merupakan produk inti (core product), yaitu sebuah model pertambahan yang
dipergunakan, tetapi beberapa muka tambahan tetap tidak disampaikan. Produk
inti tersebut dipergunakan oleh pelanggan (atau mengalami pengkajian lebih
detail). Sebagai hasil dari pemakaian dan/atau evaluasi, maka dikembangkan
rencana bagi pertambahan selanjutnya. Rencana tersebut menekankan modifikasi
produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan
penyampaian fitur serta fungsionalitas tambahan. Proses ini diulang mengikuti
penyampaian setiap pertambahan sampai bisa menghasilkan produk yang lengkap. Model
proses pertambahan tersebut, seperti model prototipe dan pendekatan-pendekatan
evolusioner yang lain, bersifat iteratif. Tetapi tidak seperti model prototipe,
model pertambahan berfokus pada penyampaian produk operasional dalam setiap
pertambahannya. Pertambahan awal ada di versi stripped down dari produk akhir,
tetapi memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform
untuk evaluasi oleh pemakai.
Model Spiral
Model spiral yang pada
awalnya diusulkan oleh Boehm adalah model proses perangkat lunak yang
evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol
dan aspek sistematis dari model sekuensial linier. Model itu berpotensi untuk
pengambangan versi pertambahan perangkat lunak secara cepat.
•
Model spiral dibagi menjadi sejumlah
aktivitas kerangka kerja, disebut juga wilayah tugas, di antara tiga sampai
enam wilayah tugas. Gambar 2.8. menggambarkan model spiral yang berisi enam
wilayah tugas : Komunikasi pelanggan – tugas-tugas yang dibutuhkan untuk
membangun komunikasi yang efektif di antara pengembang dan pelanggan
•
Perencanaan – tugas-tugas yang
dibutuhkan untuk mendefinisikan sumber-sumber daya, ketepatan waktu, dan proyek
informasi lain yang berhubungan.
•
Analisis risiko – tugas-tugas yang
dibutuhkan untuk menaksir risiko-risiko, baik manajemen maupun teknis.
•
Perekayasa – tugas-tugas yang
dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut
•
Konstruksi dan peluncuran – tugas-tugas
yang dibutuhkan untuk mengkonstruksi, menguji, memasang (install) dan
memberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi).
•
Evaluasi pelanggan – tugas-tugas yang
dibutuhkan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada
evaluasi representasi perangkat lunak, yang dibuat selama masa perekayasaan,
dan diimplementasikan selama masa pemasangan.
Ketika proses
evolusioner ini mulai, tim rekayasa perangkat lunak bergerak searah jarum
mengelilingi spiral tersebut dengan dimulai intinya. Lintasan pertama putaran
spiral menghasilkan perkembangan dari spesifikasi produk; putaran spiral
selanjutnya mungkin dipakai untuk mengembangkan sebuah prototipe, dan secara
progresif mengembangkan versi perangkat lunak yang lebih canggih.
Tidak seperti model
proses klasik yang berakhir pada saat perangkat lunak sudah disampaikan, model
spiral bisa disesuaikan agar perangkat lunak bisa dipakai selama hidup
perangkat lunak komputer.
Model spiral menjadi
sebuah pendekatan yang realistis bagi perkembangan sistem dan perangkat lunak
skala besar. Karena perangkat lunak terus bekerja selama proses bergerak,
pengembang dan pemakai memahami dan bereaksi lebih baik terhadap risiko dari
setiap tingkat evolusioner. Model spiral menggunakan prototipe sebagai mekanisme
pengurangan risiko.
Model Rakitan Komponen
Model rakitan komponen
menggabungkan beberapa karakteristik model spiral. Model ini bersifat
evolusioner, sehingga membutuhkan pendekatan iteratif untuk menciptakan
perangkat lunak. Tetapi model rakitan komponen merangkai aplikasi dari komponen
perangkat lunak sebelum dipaketkan (kadang-kadang disebut “kelas”).
Model rakitan komponen
membawa kepada penggunaan kembali perangkat lunak, dan kegunaan kembali tersebut
memberi sejumlah keuntungan yang bisa diukur pada perekayasa perangkat lunak.
Model perkembangan
Konkuren
Model proses konkuren
sering digunakan sebagai paradigma bagi pengembangan aplikasi klien/server.
Sistem klien/server dirancang dari serangkaian komponen fungsional. Bila
diaplikasikan kepada klien/server, model proses konkuren akan mendefinisikan
aktivitas di dalam dua dimensi : dimensi sistem, dan dimensi komponen. Isu
tingkat sistem ditujudengan menggunakan tiga aktivitas : desain, assembly, dan
pemakaian. Dimensi komponen dituju dengan dua aktivitas : desain dan
rea-lisasi. Konkuren dicapai dengan dua cara :
•
aktivitas sistem dan komponen yang
berlangsung secara simultan dan dapat dimodelkan dengan menggunakan pendekatan
orientasi keadaan yang digambarkan di atas;
•
aplikasi klien/server khusus
diimplementasikan dengan banyak komponen di mana masing-masing bisa dirancang
dan direalisasikan secara konkuren.
Kenyataannya model
proses konkuren bisa diaplikasikan ke dalam semua tipe perkembangan perangkat
lunak, dan memberikan gambaran akurat mengenai keadaan tertentu dari sebuah
proyek.
KAMUS DATA
Kamus data adalah
suatu daftar data elemen yang terorganisir dengan definisi yang tetap dan
sesuai dengan sistem, sehingga user dan analis sistem mempunyai pengertian yang
sama tentang input, output, dan komponen data strore. Kamus data ini sangat membantu analis
sistem dalam mendefinisikan data yang mengalir di dalam sistem, sehingga
pendefinisian data itu dapat dilakukan dengan lengkap dan terstruktur.
Pembentukan kamus data dilaksanakan dalam tahap analisis dan perancangan suatu
sistem. Pada tahap analisis, kamus
data merupakan alat komunikasi antara user dan analis sistem tentang data yang
mengalir di dalam sistem, yaitu tentang data yang masuk ke sistem dan tentang
informasi yang dibutuhkan oleh user. Sementara itu, pada tahap perancangan
sistem kamus data digunakan untuk merancang input, laporan dan database. Pembentukan kamus data didasarkan atas alur
data yang terdapat pada DFD. Alur data pada DFD ini bersifat global, dalam arti
hanya menunjukan nama alur datanya tanpa menunjukan struktur dari
OVERVIEW MENGENAI METODE ANALISIS KLASIK
Data Structured
Systems Development
Data Structure System
Development (DSSD), yang disebut juga dengan metodologi Warnier-Orr terjadi
dari kerja perintis mengenai analisis domain informasi yang dilakukan oleh J.D
Warnier. Warnier mengembangkan sebuah notasi untuk mempresentasikan hirarki informasi
dengan menggunakan tiga kontruksi untuk urutan, pemilihan, dan pengulangan dan
mendemonstrasikan bahwa struktur perangkat lunak dapat ditarik dari struktur
data.. Ken Orr memperluas kerja Warnier untuk mencakup pandangan yang lebih
luas mengenai domain informasi yang telah dikembangkan kedalam DSSD
Jackson System
Development
Jackson System
Development (JDS) mengembangkan kerja yang dilakukan oleh M.A. Jackson tentang
analisis domain informasi dan hubungannya dengan desain system dan program.
Dalam kalimat Jackson , “Pengembang memulai dengan menciptakan sebuah model
realistis dimana system diperhatikan, realitas yang memperlengkapi masalah
subjek (system)nya..”
SADT
Structured analysis
and design technique (SADT) adalah sebuah teknik yang telah digunakan secara
luas sebagai sebuah notasi untuk definisi system, representasi proses, analisis
persyaratan perangkat lunak dan desaign system /perangkat lunak.
KONSEP DAN PRINSIP ANALISIS
KONSEP
DAN PRINSIP ANALISIS
Tugas analisis persyaratan merupakan
sebuah proses penemuan, perbaikan, pemodelan, dan spesifikasi. Ruang lingkup
perangkat lunak, yang secara mendasar dikembangkan oleh perekayasa sistem dan
diperbaiki selama perancanaan proyek perangkat lunak, diperbaki secara detail.
Model-model data yang dibutuhkan, aliran kontrol dan informasi, dan tingkah laku operasional
diciptakan. Pemecahan alternatif dianalisis dan dialokasikan ke berbagai elemen
perangkat lunak. Baik pengembang maupun pelanggan melakukan peran aktif dalam
analisis persyaratan dan spesifikasi. Pelangga berusaha memformulasikan kembali
konsep yang tidak jelas dari fungsi perangkat lunak dan kinerja ke dalam detail
yang konkrit. Pengembang bertindak sebagai interogator, konsultan, dan pemecah
masalah.
ANALISIS
PERSYARATAN
Merupakan sebuah
tugas sebuah rekayasa perangkat lunak (RPL) yang menjembatani antara alokasi
perangkat lunak dan perancangan perangkat lunak. Analisis persyaratan
memungkinkan perekayasa sistem menentukan fungsi dan kinerja perangkat lunak,
menunjukkan interface dan elemen-elemen di dalamnya, dan membangun batasan yang
harus dipenuhi oleh perangkat lunak. Analisis persyaratan memberikan
model-model yang akan diterjemahkan ke dalam data, arsitektur, interface, dan
desain prosedural kepada perancang perangkat lunak. Akhirnya, spesifikasi
persyaratan memberikan cara kepada pengembang dan pelanggan untuk menilai
kualitas perangkat lunak yang telah dibangun. Pada awalnya, analis mempelajari
spesifikasi sistem (bila ada) dan rencana proyek perangkat lunak. Penting untuk
memahami perangkat lunak dalam suatu konteks sistem dan mengkaji ruang lingkup
perangkat lunak yang telah digunakan untuk memunculkan estimasi perencanaan.
Selanjutnya adalah membangun komunikasi untuk analisis untuk menjamin
pengenalan masalah. Tujuannya adalah mengenali elemen masalah dasar seperti
dirasakan oleh pelanggan.
TEKNIK
KOMUNIKASI
Mengawali
Proses
Menurut Gause dan
Weinberg [GAU89] menyarankan agar analis memulainya dengan mengajukan
pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada pelanggan,
tujuan keseluruhan, dan keuntungan.
Contoh:
- Siapa di balik permintaan untuk pekerjaan ini?
- Apa keuntungan ekonomi dari pemecahan yang berhasil?
- Rangkaian pertanyaan berikutnya memungkinakan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan.
Contoh:
- Masalah apakah yang akan diselesaikan oleh pemecahan ini?
- Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana pemecahan tersebut akan digunakan?
Rangkaian
pertanyaan berikutnya berfokus pada efektifitas pertemuan. [GAU89] memberikan
contohnya sebagai berikut:
- Apakah ada orang lain yang dapat memberikan informasi tambahan?
- Apakah ada hal lain yang harus saya tanyakan kepada anda?
Pertanayan-pertanyaan tersebut akan
membantu anda mengawali komunikasi yang perlu untuk berhasilnya analisis. Pada
dasarnya sesi tanya jawab seharusnya digunakan pada pertemuan pertama dan
kemudian diganti dengan format yang mengkombinasikan lemen-elemen pemecahan masalah, negosiasi, dan
spesifikasi.
Teknik Spesifikasi Aplikasi yang
Terfasilitasi
Sebuah mekanisme definisi (dapat merupakan sebuah lembar kerja, diagram flip, stiker dinding, atau papan tembok) digunakan. FAST bukanlah obat bagi masalah yang dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan langkah maju konkrit ke arah pengembangan spesifikasi.
Penyebaran
Fungsi Kualitas
Disebut juga
Quality function deployment (QFD) adalah teknik manajemen kualitas yang
menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat
lunak.
QFD
mengidentifikasi 3 persyaratan [ZUL92] yaitu:
- Persyaratan normal:
- Sasaran dan
- tujuan dinyatakan bagi sebuah produk atau sistem selama pertemuan dengan pelanggan.
Bila persyaratan
ini ada, maka pelanggan akan menjadi puas.
Conoth: tipe
tampilan grafis yang diminta, dan tingkat kerja yang didefinisikan. Persyaratan yang diharapkan: Persyaratan ini implisit
terhadap produk atau
sistem dan sangat fundamental sehingga
pelanggan tidak menyatakannya
secara eksplisit. Ketidakhadirannya
menyebabkan ketidakpuasan. Contoh:
Mudahnya instalasi perangkat lunak.
Exciting requirment: Persyaratan ini
sangat diharapkan oleh pelanggan dan
terbukti sangat
memuaskan bila ada. Misalnya, perangkat lunak pengolah kata
diharapkan dengan
fitur standar. Produk yang disampaikan berisi sejumlah
kemampuan layout
halaman yang sangat menyenangkan dan tidak terduga.
Dalam kenyataan,
QFD mencakup seluruh proses rekayasa [AKA90]. Tetapi
banyak konsep QFD
dapat diaplikasikan ke dalam masalah komunikasi pelanggan
yang dihadapi oleh
perekayasa perangkat lunak selama tahap awal analisis
persyaratan.
PRINSIP-PRINSIP
ANALISIS
Masing-masing
metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis
dihubungkan oleh serangkaian prinsip operasional:
- Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
- Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
- Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
- Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan.
- Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
Dengan
mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah
secarasistematis. Domain informasi diuji sehingga fungsi itu dapat dipahami
secara lebih lengkap. Model-model digunakan sehingga karakteristik fungsi dan
tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan
untuk mengurangi keruwetan. Pandangan esensial dan implementasi dari perangkat
lunak diperlukan untuk
mengakomodasi
batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan
fisik yang
dibebankan oleh elemen sistem yang lain. Perekayasa perangkat lunak yang
mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi
perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.
- Domain Informasi
- Pemodelan
Model dalam perangkat lunak harus dapat
memodelkan informasi yang ditransformasikan oleh perangkat lunak, fungsi (dan
subfungsi) yang memungkinkan transformasi terjadi, dan tingkah laku sistem pada
saat transformasi terjadi.
Dalam beberapa kasus, model yang kita
buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan,
tingkah laku sistem, dan karakteristik lain sebagai simbol yang berbeda dan
dapat dikenali. Informasi deskriptif dapat diberikan dengan menggunakan bahasa
natural atau bahasa khusus untuk menggambarkan persyaratannya.
Prinsip analisis operasional
mengharuskan kita membangun model fungsi dan tingkah laku, yaitu:
Model fungsional: Perangkat lunak mentransformasi informasi, dan untuk melakukannya,
perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input,
pemrosesan, dan output. Pada saat model fungsional dari suatu aplikasi dibuat,
perekayasa perangkat lunak memfokuskan diri pada fungsi-fungsi masalah khusus. Model fungsi dimulai dengan sebuah
model
tingkat konteks
tunggal (yakni nama perangkat lunak yang akan dibuat).
Dengan serangkaian
iterasi, maka lebih banyak lagi detail fungsional
diberikan, sampai
seluruh rancangan dari semua fungsionalitas sistem
terwakili.
Model tingkah laku: Sebagian besar perangkat lunak merespon kejadiankejadian
dari dunia luar.
Karakteristik stimulus-respon ini membentuk
dasar dari model
tingkah laku. Model tingkah laku menciptakan
representasi pernyataan-pernyataan
perangkat lunak dan event-event yang
menyebabkan
perangkat lunak mengubah pernyataan.
Model yang
diciptakan selama analisis persyaratan melayani sejumlah peran
penting:
- Model membantu
analis dalam memahami informasi, fungsi, dan tingkah
laku suatu sistem,
sehingga membuat tugas analisis persyaratan menjadi
lebih mudah dan
lebih sistematis.
- Model menjadi
titik fokus bagi kajian sehingga merupakan kunci bagi
penentuan
kelengkapan, konsistensi, dan akurasi dari spesifikasi.
- Model menjadi
dasar bagi pengerjaan desain, memberi perancang suatu
representasi
esensial dari perangkat lunak yang dapat diterjemahkan ke
dalam suatu
konteks implementasi.
Meskipun metode
pemodelan yang digunakan sering menjadi masalah preferensi
personal atau
organisasional, aktivitas pemodelan adalah dasar bagi kerja analisis
yang baik.
- Pembagian
Masalah sering
menjadi terlalu luas atau terlalu rumit untuk dipahami sebagai satu
kesatuan. Karena
itulah kita cenderung membagi masalah seperti itu ke dalam
bagian-bagian
sehingga dapat dipahami dengan mudah dan kemudian
membangun interface antara
bagian-bagian tersebut, sehingga keseluruhan fungsi
dapat dilakukan. Prinsip analisis
operasi keempat menyatakan bahwa domain
informasi,
fungsional, dan tingkah laku perangkat lunak dapat dibagi-bagi.
Secara mendasar
pembagian mendekomposisi suatu masalah ke dalam bagian
konstituennya.
Secara konseptual, kita membangun sebuah representasi hirarki
dari informasi
atau fungsi dan kemudian membagi elemen bagian paling atas
dengan
(1)mengekspos detail pertambahan dengan bergerak secara vertikal dalam
hirarki,
(2)mendekomposisi masalah dengan bergerak secara horisontal dalam
hirarki.
Contoh: system
keamanan safehome
- Pandangan
esensial dan implementasi
Pandangan esensial
persyaratan perangkat lunak menyajikan fungsi yang akan
dikerjakan dan dan
di informasikan yg akan diproses tanpa melihat detail
implementasinya.
Contoh: Pandangan esensial dari fungsi
safehome read sensor status
Tidak tergantung
dari bentuk fisik dari data atau type sensor yang
Di gunakan.
Pandangan
implementasi persyaratan perangkat lunak menyajikan manifestasi
dunia nyata dari
pemrosessan fungsi-fungsi dan struktur informasi.
Contoh: Input safehome dimana
perangkat/ element (sensor)
menggunakan pertimbangan pandangan
implementasi.
- Prototyping perangkat
Analisis harus dilakukan tanpa
mengabaikan paradigma rekayasa PL yg di
aplikasikan ; tetapi bentuk yg diambil
oleh analisis akan bermacam- macam.
Dalam banyak kasus
sangat mungkin untuk mengaplikasikan prinsip operasional
dan menarik sebuah
model PL yang melaluinya sebuah desain dapat
dikembangkan,pengaplikasian
prinsip analisis dan penyusunan model perangkat
lunak yg akn dibangun yang disebut
prototype untuk penilaian pelanggan dan
pengembang.
- Pemilihan prototyping
Paradigma prototyping terbatas dan
tidak terbatas. Pendekatan terbatas
sering disebut: throw away prototyping.
Dengan menggunakn pendekatan
tersebut,
prototyping sebagai sebuah demonstrasi kasar dari sebuah
persyaratan.Kemudian
prototype dikesampingkan dan perangkat lunak
direkayasa dgn
menggunakan suatu paradigma yang berbeda.Pendekatan
tidak terabatas sering disebut
evolusionary prototyping,menggunakan
prototyping
sebagai bagian utama dari aktivitas analisis yang akan
diteruskan ke
dalam desain dan konstruksi.
Sebelum perangkat
terbatas atau tidak terbatas dipilih, perlu ditentukan
apakah system yang
akan dibangun dapat menerima prototyping atau
tidak.Sejumlah factor calon
prototiyping[BOA84] dapat ditentukan: area
aplikasi,
kompleksitas aplikasi, krakteristik pelanggan, dan karakteristik
proyek.
~ metode dan
Peranti Prototyping
Agar prototyping
perangkat lunak efektif,maka harus dikembangkan
suatu prototype
dengan cepat sehingga pelanggan dengan dapat menilai
hasil dan
perubahan yang di rekomendasikan. Untuk melakukan
prototyping dengan
tepat ad tiga kelas metode dan peranti generik missal:
(AND 92,TAN 92):
teknik generasi keempat komponen perangkat lunak
reusable,spesifikasi
normal,dn lingkungan prototyping.
- Spesifikasi
Metode spesifikasi
sama dengan pemecahan masalah. Pereka PL yang dipaksa
bekerja dengan
spesifikasiyang tidak lengkap,tidak konsisten,atau salah akan
mengalami frustasi
atau keraguan.akibatnya, kualitas ,ketepatan waktu dan
kelengkapan
perangkat lunak menjadi korban.
- Prinsip
spesifikasi
Spesifikasi, tanpa
mempedulikan mode dimana kita melakukannya, dapat
dilihat sebagai
sebuah proses representasi. Persyaratan diwakilkan dengan suatu
cara yg membawa ke
arah implementasi yang berhasil. Berikut ini sejumlah
prinsip spesifikasi
yang diadaptasi dari kerja Blazer dan Goldman[BLA 86].
1.Memisahkan
fungsional dari implementasi
2. Mengembangkan
suatu model dari system yang diperlukan yg meliputi
data dan respon
fungsional dari suatu system terhadap berbagai stimulus
dari lingkungan.
3.Membangun
konteks dimana PL beroperasi dengan menentukan cara
dimana komponen
system yg lain berinteraksi dengan PL.
4.Menentukan
lingkungan dimana system beroperasi dan menunjukan
bagaimana “
sekumpulan agen yang sangat terjalin bereaksi terhadap
stimulus dalam
lingkungan.
5.Menciptakan
sebuah model yg kognitif daripada model desain atau
implementasi.Model
kognitif menggambarkan sebuah system
sebagaimana
dirasakan oleh komunitas pemakainya.
6.mengenali
spesifikasi harus toleran terhadap ketidak lengkapan dan
dapat di tambah.
7.Membangun muatan
dan struktur spesifikasi dengan suatu cara yang
akan memungkinkan
spesifikasi dapat ditambah agar dapat berubah.
- Representasi
Kita mengetahui
bahwa persyaratan PL dapat ditentukan dalam berbagai cara.
Akan tetapi, bila
persyaratan itu dimasukan pada kertas atau media presentasi
electronic, maka
diperoleh panduan sederhana:
-Format dan muatan
representasi harus relevan dengan masalah.
-Informasi yang di
isikan kedalm spesifikasi harus disarangkan.
- Spesifikasi
persyaratan PL
Spesifikasi
persyaratan PL dibuat pada puncak tugas analisis. Fungsi dan kinerja
yang dialokasikan
pada PL sebagai bagian dari rekayasa system, diperhalus
dengan membangun
sebuah diskripsi informasi lengkap,diskripsi tingkah laku dan
fungsional
lengkap,indikasi persyaaratan kinerja dan batasan desain, criteria
validasi yang
sesuai, dan data lain yang berkenaan dengan persyaratan. The
Nation Bureau of Standards, IEE(
standard no. 830- 1984) dan Departement
Pertahanan AS mengusulkan format calon untuk spesifikasi persyaratan
perangkatan
perangkat lunak. Berikut merupakan kerangka kerj untuk spesifikasi.
a.Pendahuluan
-Refrensi system
-Deskripsi
keseluruhan
-Batasan proyek PL
b.Deskripsi
informsi
-Representasi isi
informasi
-Representasi
aliran informasi
- aliran data
- aliran kontrol
c.Deskripsi
fungsional
-Pembagian
fungsional
-deskripsi
fungsional
- gambaran
pemrosesan
- retriksi /
keterbatasan
- persyaratan
kinerja
- batasan desain
- diagram pendukung
- diskripsi control
- spesifikasi control
- batasan desain
d.Diskripsi
prilaku
- peryataan system
- event dan
tindakan
e.Validasi dan
kreteria
-batas kinerja
- kelas- kelas pengujian
- respon PL
- pertimbangan khusus
f.Bibliografi
g.Lampiran
- Kajian spesifikasi
Kajian dari suatu spesifikasi persyaratan
perangkat lunak dilakukan baik oleh
pelanggan atau pengembang PL. Karena
spesifikasi membentuk dasar bagi
desain dan
aktivitas rekayasa selanjutnya, maka kajian harus dilakukan dengan
hati- hati.
Kajian dilakukan
pertama kali pada tingkat makroskopik.pada tingkat ini pengkaji
akan memastikan
bahwa spesifikasi sudah lengkap, konsisten, dan, akurat.
Pertanyaan -
pertayan berikut dapat di ajukn:
Apakah tujun dan
sasaran yang diyatakan bagi perangkat lunak
tetap konsisten
dengan tujuan dan sasaran system?
Apakah
interface penting kesemua element system sudah
digambarkan?
Apakah aliran
informasi dan struktur didefinisikan dengan tepat
bagi domain masalah
Apakah diagram jelas?apakah masing
masing dapat berdiri sendiri
tanpa teks pendamping
Apakah fungsi mayor tetap ada pada
ruang lingkup, dan sudah
digambarkan dengan
lengkap dn tepat?
Apakah tingkah
laku PL konsisten dengan informasi yang harus
diproses dan
fungsi harus dilakukannya?
Apakah
batasan desain realistis?
Apakah resiko teknologis pengembang
sudah dipertimbangkan?
Apakah criteria validasi dinyatakan
secara detail?apakah criteria
tersebut kuat
untuk menggambarkan sebuah system yang berhasil.
Apakah ada
inkonsistensi,penghilangan?
Apakah kontak
dengan pelanggan sudah lengkap?
Apakah pemakai
sudah mengkaji manual pemakai pemulaan atau
prototype?
Bagaimana estimasi perencanaan
mempengaruhi
Pengkaji dapat
mengembangkan pertayaan diatas dengan :
Mencari konektor
persuasive
Bila suatu daftar
yang diberikan tidak lengkap,pastikan jenisnya
sudah dipahami.
Pastikan jangkauan yg dinyatakan tidak
berisi asumsi yg tidak
dinyatakan.
Hti hatilah pada
kata kerja yang kabur
Hati hati terhadap
kata ganti yang ambiguitas
Cari pertanyaan
yang mengimplimentasikan kepastian
Bila kajian lengkap
spesifikasi persyaratan PL diakhiri oleh pelanggan atau
pengembang.
Perubahan yang diminta setelah spesifikasi itu di akhiri tidak akan
dieleminasi,
tetapi pelanggan harus mencata bahwa masing – masing perubahan setelah
pengakhiran
spesifikasi merupakan ekstensi dari ruang lingkup PL yang demikian dapt
menambah biay dan atau dapat
memperpanjang jadwal proyek.Bahkan dengan prosedur
kajian terbaikpun, tetap ada sejumlah
masalah spesifikasi. Spesifikasi sulit di uji dalam
berbagai cara yang
berarti sehingga inkonsistensi dn penghilangan dapat berlangsung
tanpa terlihat.Selama kajian ,
perubahan terhadap terhadap spesifikasi dapat
disetujui.Sangat sulit untuk menili
pengaruh global dari suatu perubahan ; yaitu
bagaimana suatu perubahan dalam suatu
fungsi mempengaruhi persyaratan bagi fungsi-
fungsi yang lain.
