OOAD
Situasi
permasalahan (konteks metodologi)
Klien : Pengguna yang sudah mengerti sistem
tersebut atau sudah pengalaman dalam hal sistem
Komitmen : Analis dan programmer tidak dibatasi dengan batasan implementasi sistem,
jadi desain dapat diformliasikan yang dapat dikonfirmasi dengan berbagai
lingkungan eksekusi
Membantu dalam mengidentifikasi klien : waktu pengembangan, level organisasi,
ketangguhan,dan penggunaan kembali (reuse) kode program lebih tinggi
Situasi : Well-structured dikarenakan Relasi obyek dengan entitas (thing) umumnya dapat di mapping
dengan baik seperti kondisi pada dunia nyata dan keterkaitan dalam sistem
Situasi yang bagaimana metodologi sesuai : tergantung dari kebutuhan dan dari sudut pandang mana anda
melihatnya. Yang perlu anda ingat adalah tujuan dari pemodelan itu sendiri,
yang mana agar pada akhir proyek sistem dapat diperoleh sistem informasi yang
memenuhi kebutuhan pemakai, tepat waktu dan sesuai anggaran, serta mudah
digunakan, dimengerti dan dipelihara
Situasi yang diinginkan : 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
Kemampuan dari problem solver (pemakai
metodologi)
Seberapa tinggi tingkat abstraksi dan
pemikiran teknis yang diminta metodologi yang harus dipenuhi oleh pemakai? : Belajar memahami cara kerja sistem yang baru dengan mengikuti
pembelajaran dari si pembuat
Apakah
filosofi yang ada di metodologi cocok dengan cara pandang pemakai? : Itu ditentukan dari
niatnya sipemakai, jika kesan si pemakai
tidak bertanggung jawab maka tidak akan cocok dan harus diganti
Keahlian
dan pengetahuan apa yang dipersyaratkan oleh metodologi yang perlu dipenuhi
oleh pemakai? : Sudah berpengalaman dalam penggunaan
sistem tersebut sehingga akan dipenuhi syaratnya
Apakah
suasana mental (mental constructs) dari pemakai dilihat? : ya, seperti mental yang tidak sehat yaitu secara relatif bisa dilihat pada individu jauh dari kemampuan
beradaptasi atau selalu mengalami kesulitan
dalam beradaptasi sehingga akan sulit mempelajari kegunaan
sistem yang baru
Proses
pemecahan masalah (methodology itself)
-Tahap 1 : Analisi Masalah :
a. Menentukan masalah
b. Mengidentifikasi penyebab dari masalah
tersebut
c. Menentukan pemecahan masalahnya
d. Mengidentifikasikan kebutuhan informasi
yang dibutuhkan untuk memecahkan masalah tersebut
-Tahap 2 : Menentukan Kebutuhan
Pemakai
Apa yang diperlukan si pemakai di
penggunaan sistem tersebut
-Tahap 3 : Identifikasi Skenario
Pemakai
Apakah si pemakai tersebut sudah
berpengalaman dalam sebuah sistem
-Tahap 4 : Penentuan desain secara konseptual/logis
-Tahap 5 : Desain Sistem
Mengidentifikasi
solusi alternatif dan memilih tindakan terbaik,mendesain solusi yang dipilih
-Tahap 6 :
Implementasi Sistem
RUP
RUP (Rational Unified Process ) adalah suatu metode rekayasa perangkat
lunak yang dikembangkan dengan mengumpulkan berbagai best practises yang
terdapat dalam industri pengembangan perangkat lunak. Ciri utama metode ini
adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus
pengembangan perangkat lunak
Situasi
permasalahan (konteks metodologi)
Klien : Semua pemakai seperti dalam 1
kantor semuanya bisa memakai sistem tersebut
Komitmen : Proses ini memiliki beberapa model yang
masing-masing menjelaskan pendekatan terhadap berbagai tugas atau aktivitas
yang terjadi selama proses
Membantu
dalam mengidentifikasi klien : RUP menggunakan konsep object oriented, dengan aktifitas
yang berfokus pada pengembangan model dengan menggunakan Unified Model Language
(UML). Melalui gambar dibawah dapat dilihat bahwa RUP memiliki, yaitu:
§ Dimensi pertama digambarkan secara horizontal. Dimensi ini mewakili aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir dari awal dari phase selanjutnya. Setiap phase dapat berdiri dari satu beberapa iterasi. Dimensi ini terdiri atas Inception, Elaboration, Construction, dan Transition.
§ Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni ‘who is doing, what, how dan when’. Dimensi ini terdiri atas
§ Dimensi pertama digambarkan secara horizontal. Dimensi ini mewakili aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir dari awal dari phase selanjutnya. Setiap phase dapat berdiri dari satu beberapa iterasi. Dimensi ini terdiri atas Inception, Elaboration, Construction, dan Transition.
§ Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni ‘who is doing, what, how dan when’. Dimensi ini terdiri atas
Situasi : Well-structured
1. Mengadaptasi proses
2. Menyeimbangkan prioritas dari para stakeholders
3. Melakukan kolaborasi antar tim
4. Mendemonstrasikan hasil-hasil yang ada secara berulang-ulang
5. Menaikkan level abtraksi dari sebuah software
6. Memfokuskan pada kualitas secara terus-menerus
2. Menyeimbangkan prioritas dari para stakeholders
3. Melakukan kolaborasi antar tim
4. Mendemonstrasikan hasil-hasil yang ada secara berulang-ulang
5. Menaikkan level abtraksi dari sebuah software
6. Memfokuskan pada kualitas secara terus-menerus
Situasi
yang bagaimana metodologi sesuai : Pihak klien
dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak,
mengidentifikasikan semua kebutuhan end user
Situasi yang diinginkan : pendekatan
perangkat lunak yang dilakukan berulang-ulang (iterative), fokus pada
arsitektur (architecture-centric), lebih diarahkan berdasarkan penggunaan kasus
(use case driven)
Kemampuan dari problem solver (pemakai
metodologi)
Seberapa
tinggi tingkat abstraksi dan pemikiran teknis yang diminta metodologi yang
harus dipenuhi oleh pemakai? : tidak tinggi, dikarenakan sistem tersebut sangat mudah dipahami dan hanya
pengembangan model
Apakah
filosofi yang ada di metodologi cocok dengan cara pandang pemakai? : Itu ditentukan dari
niatnya si pemakai, jika pemakai tersebut
kurang maka pengalaman dalam sistem tersebut maka pengembangan model tersebut
menjadi tidak berguna
Apakah
suasana mental (mental constructs) dari pemakai dilihat? : ya, seperti mental yang tidak sehat yaitu secara relatif bisa dilihat pada individu jauh dari kemampuan
beradaptasi atau selalu mengalami kesulitan
dalam beradaptasi sehingga akan sulit mempelajari kegunaan
sistem yang baru
Proses
pemecahan masalah (methodology itself)
-Tahap 1 : Inception/insepsi
A .Menentukan
Ruang lingkup proyek
B.
Membuat 'Business Case'
C.
Menjawab pertanyaan 'apakah yang dikerjakan dapat menciptakan 'good business
sense' sehingga proyek dapat dilanjutkan
-Tahap 2 : Elaboration/elaborasi
A.
Menganalisa berbagai persyaratan dan resiko
B.
Menetapkan 'Base line'
C.
Merencanakan fase berikutnya yaitu construction
-Tahap 3 : Construction/kontruksi
A. Melakukan
sederetan iterasi
B.
Pada setiap iterasi akan melibatkan prose berikut : analisa desain, implementasi
dan testing
-Tahap 4 : Transition/Transisi
A.
Membuat apa yang sudah dimodelkan menjadi suatu produk jadi
B.
Dalam fase ini dilakukan:
· Beta
dan performance testing
· Membuat
dokumentasi tambahan seperti: training dan user
guide
· Membuat
rencana peluncuran produk ke komunitas pengguna
No comments:
Post a Comment