metodologi manajemen proyek fase 3 :...
TRANSCRIPT
Hera Agustina, S.Kom., MMSI
METODOLOGI
MANAJEMEN
PROYEK
FASE 3 : Desain
• Aktivitas utama dalam fase desain adalah membuat top
dan medium level dari desain sistem dan
mendokumentasikannya dalam spesifikasi desain.
• Aktivitas kedua dimulai dengan Rencana Tes
Penerimaan (Acceptance Test Plan / ATP).
• ATP adalah sebuah dokumen tes yang akan digunakan
untuk mendemonstrasikan seluruh fungsi sistem kepada
user pada fase penerimaan.
Pendahuluan
Free PPT _ Click to add title
• Pada tahap desain tim teknologi informasi
bekerja sama dengan tim bisnis atau
manajemen melakukan perancangan
komponen-komponen sistem terkait.
• Tim teknologi informasi akan melakukan
perancangan teknis dari teknologi informasi
yang akan dibangun, seperti sistem basis
data, jaringan komputer, metode interfacing,
teknik konversi data, metode migrasi sistem
dan sebagainya.
• Model-model umum seperti flowchart, ER Diagram, DFD,
dan lain sebagainya dipergunakan sebagai notasi umum
dalam perancangan sistem secara teknis.
• Tahap desain memutuskan bagaimana sistem akan
beroperasi.
• Secara paralel bersama manajemen akan melakukan
perancangan terhadap komponen-komponen organisasi
yang terkait.
Free PPT _ Click to add title
• Hasil dari tahap ini adalah cetak biru
rancangan sistem yang akan dijadikan
pegangan dalam proses konstruksi dan
implementasi komponen-komponen pada
sistem informasi yang akan dikembangkan.
1. Strategi desain, menjelaskan apakah sistem akan
dibuat oleh programmer perusahaan atau
menggunakan jasa konsultan.
2. Mengarah pada pengembangan desain arsitektur dasar
untuk sistem.
3. Menspesifikasikan database dan file yang
dikembangkan.
4. Tim analis mengembangkan rancangan/desain
program.
Langkah Dalam Fase Desain
Langkah Dalam Mendesain
Sistem Software
1. Bagilah sistem menjadi beberapa
komponen secara fungsional.
2. Hubungkanlah komponen-komponen
tersebut.
• Output utama dari tahapan desain perangkat lunak
adalah spesifikasi desain.
• Spesifikasi ini meliputi spesifikasi desain umum yang
akan disampaikan kepada stakeholder sistemdan
spesifikasi desain rinci yang akan digunakan pada
tahap implementasi.
• Spesifikasi ini hanya berisi gambaran umum agar
stakeholder sistem mengerti akan seperti apa
perangkat lunak yang akan dibangun.
Output
• Spesifikasi desain rinci atau kadang disebut desain
arsitektur rinci perangkat lunak diperlukan untuk
merancang sistem sehingga memiliki konstruksi
yang baik, proses pengolahan data yang tepat dan
akurat, bernilai, memiliki aspek user friendly, dan
memiliki dasar-dasar untuk pengembangan
selanjutnya.
• Desain arsitektur ini terdiri atas desain database,
desain proses, desain user interface yang mencakup
desain input, output form dan report, desain
hardware, software dan jaringan.
• Metode pembuatan software, metode dan tools yang
digunakan tidak optimal sehingga mempengaruhi
kualitas produk dan tidak sesuai dengan keinginan user.
• Organisasi pembuatan software, tidak adanya
koordinasi pada proses pembuatan software sehingga
terjadi modul-modul yang tidak dapat digabungkan.
Misalnya ketidaksesuaian nama tabel, field, dll.
Masalah Dalam Fase Desain
Tujuan
• Membuat desain awal
• Desain yang detail
• Membuat laporan
• Desain awal mendeskripsikan kapabilitas fungsional secara
umum dari sistem informasi yang diusulkan.
• Perangkat yang digunakan pada fase ini adalah perangkat
CASE (Computer Aided Software Engineering) dan
perangkat lunak manajemen proyek.
• Prototyping juga dilakukan pada tahap ini.
• Prototyping adalah membuat model kerja dari komponen
sistem sehingga sistem baru bisa segera diuji dan dievaluasi.
• Prorotype adalah sistem dengan kemampuan kerja terbatas
yang dikembangkan untuk menguji konsep-konsep desain.
Membuat Desain Awal
Desain yang Detail
Menggambarkan bagaimana sisteminformasi yang diusulkan mampu
memberikan kapabilitas yang digambarkan secara umum dalam
desain awal.
• Semua pekerjaan dalam desain awal dan
desain yang detail akan dikemas dalam laporan
yang terperinci.
• Dapat melakukan presentasi atau diskusi pada
saat penyerahan laporan kepadan manajemen
senior.
Menulis Laporan
Kegiatan
Design Sistem Fisik
Desain Arsitektur
Desain Interface
Desain Program
Desain Database dan File
Teknik yang Digunakan
Teknik
•Design Strategy Architecture
•Design Hardware dan Software
•Selection Use Scenario
•Interfacse Structure
•Interface Standards
•Interface Prototype
•Interface Evaluation
•Modeling
•Denormalization
•Performance Tuning
Structured Design
• Tujuan utama dari disain yang terstruktur
adalah memecah sistem menjadi bagian
yang lebih kecil, teratur dan mudah untuk
dibangun.
Top Down Design
• Dimulai dengan Top Level Design (TLD).
• Masing-masing komponen utama dalam TLD
dipecah menjadi sub-bagian dimulai dengan level
teratas, kemudian turun kelevel berikutnya, dst.
• Dimulai dengan MENU dan mendisainnya sebelum
turun ke INQUIRY, UPDATE, dan REPORT GENER
ATION, yang akan diikuti dengan tingkat selanjutnya
, jika ada.
Contoh Top Down Design
Contoh Top Down Design
Bottom Up Design
• Pada kasus tertentu mungkin akan lebih mudah
mendisain dengan menggunakan pendekatan dari
level bawah / rendah ke level atas.
• Hal ini sering ditemui pada kasus sistem pengontrolan
proses dimana perlatan pengontrolan hardware pada
level terbawah menentukan bagaimana sistem
tersebut disatukan (integrasi sistem).
• Disain Bottom Up juga sangat cocok digunakan pada
kasus dimana komponen software yang ada
digabungkan dan disatukan dengan modul baru untuk
membangun sebuah sistem.
Contoh Bottom Up Design
Contoh Bottom Up Design
Top Level Design
• Banyak TLD yang dapat mencapai atau memperoleh hasil yang
sama dalam sebuah sistem software.
• Semakin banyak paket program yang anda beli, semakin berkurang
pemrograman yang harus anda lakukan.
• Keputusan untuk membeli paket program lebih mudah
dibandingkan harus membuat sendiri, akan tetapi lebih mahal, dan
umumnya kurang efisien dibandingkan dengan program tertulis
biasa yang sama.
• Salah satu masukkan mungkin adalah menghilangkan INQUIRY,
UPDATE dan REPORT GENERATION dan menggunakan rutin FIL
E HANDLER yang umum untuk melakukan semua kegiatan akses
file.
• Sedikit penurunan kinerja akan terlihat oleh
karena pemanggilan yang sering pada FILE
HANDLER, tetapi sistem akan menjadi lebih
kecil.
• Setiap pilihan TLD memilki keuntungan dan
kerugian dan melibatkan pertukaran dan
kompromi.
Prioritas Desain
Pilihan TLD akan mempengaruhi hal-hal berikut ini :
• Biaya Sistem (System Cost)
• Waktu yang diperlukan untuk membangun sistem (Time
to Build The System)
• Sifat mudah dipakai (User Friendliness)
• Kinerja (Performance)
• Ukuran Sistem (System Size)
• Kehandalan (Reliability)
• Kemampuan modifikasi (Modifiability)
Item-item tersebut harus menjadi prioritas, bersama dengan user pada waktu perencanaan sistem,
pada saat pendefinisian dan analisis. Ini akan membuat pilihan
TLD jauh lebih mudah.
Medium Level Desain
• Setelah TLD terpilih, kita harus membagi masing-masing
fungsi atau komponen utama menjadi beberapa sub
fungsi atau komponen.
• Disain top down ini dimulai dengan kotak menu.
Diasumsikan bahwa komponen ini dipanggil ketika selur
uh sistem dimulai dan menampilkan menu utama ke
bagian register.
• Kemudian program menunggu user untuk memindahkan
mouse.
• Sub fungsi utama komponen MENU adalah :
1. Memulai sistem dan menampilkan main menu
2. Menangani perpindahan mouse
3. Menangani tombol pada mouse
4. Pindah ke Menu INQUIRY, UPDATE, WAREHOUSE
atau REPORT ketika dipilih.
5. Menangani kesalahan-kesalahan seperti pada on line
help messages untuk seluruh sistem
6. Mematikan sistem jika QUIT dipilih
• Level terendah dari suatu menu menggambarkan modul.
Sebuah modul adalah bagian terkecil yang dapat ditest dan
dicompile.
Modul Terstruktur
Sebuah modul terstruktur memiliki ciri-ciri sebagai berikut :
• Berfungsi sepenuhnya sebagai fungsi tunggal. Misalnya dapat diterima, diedit,
diformat ulang dan melewati parameter tunggal.
• Ukurannya kecil. Ukuran yang ditetapkan berkisar antara 50 – 100 baris yang dapat
dieksekusi atau paling banyak 2 halaman.
• Dapat diprediksi. Semua ciri dapat terlihat dengan membaca kode program. Hal ini
tidak dipengaruhi oleh kode tersembunyi dalam modul lain atau dalam sistem operasi.
• Tidak tergantung (Independent) Perubahan dalam modul atau parameter tidak
mempengaruhi sistem.
• Meskipun hal ini tidak didefinisikan secara jelas dalam modul terstruktur, lihatlah
kegunaannya kembali – suatu modul yang cukup lengkap dan umum mengakibatkan
anda dapat menggunakannya pada aplikasi lain dengan memodifikasi sedikit
mungkin.
Desain File
• Mengoptimalkan File
Mengoptimalkan penyimpanan disk dengan
mengurangi kerangkapan field-field dan file-file.
• File History
Mendefinisikan sebuah file dan memindahkan record
ke dalam file yang telah didefinisikan.
• Pengujian Desain File
Pada disain ini, setiap permintaan kebutuhan yang
melibatkan pengaksesan data harus “diproses”
dengan disain file. Hal ini menandai perkembangan
selanjutnya.
Keuntungan Desain dan
AnalisisTerstruktur• Mengurangi jumlah kesalahan.
• Meskipun biaya dimuka mengalami kenaikan, metode
terstruktur tetap mengurangi biaya sistem secara
keseluruhan.
Tim Desain
• Pilihlah orang-orang terbaik untuk tim disain.
• Tim disain yang baik tidak perlu orang yang
menguasai bahasa pemrograman.
• Mereka haruslah orang yang dapat
mengkonsep semuanya.
• Hindari orang-orang yang selalu
menginginkan kesempurnaan (perfectionis)
dalam tim disain.
Pertemuan Desain
• Merancang sesuatu mirip dengan urun remuk
(brainstorming) : beberapa orang berkumpul dalam
suatu ruangan yang tenang dan tidak terganggu.
• Setiap orang diharapkan untuk mengeluarkan semua
ide mereka agar semua elemen yang berfungsi dapat
digunakan dan juga memikirkan bagaimana cara
menguasainya.
• Tulis semua ide yang ada, dan kemudian akhirnya
ide-ide yang ada disusun ke dalam modul-modul yang
unik.
Hal-Hal yang Perlu
Dipertimbangkan• Gunakan bahasa yang formal dan tepat.
• Gunakan gambar, diagram yang terstruktur
dan yang sejenisnya.
• Buatlah agar maksud dari disain menjadi
jelas pada beberapa halaman pertama.
Kemudian uraikan.
• Cobalah untuk konsisten pada grafik-grafik
dan struktur kalimat.
Standar Ketentuan
Beberapa ketentuan disain. Format struktur diagram, modul dan
kaidah penamaan variabel ini digunakanuntuk semua tingkatan yang rendah.
Parameter yang mendahului.Rincian perintah, panjang, format / tipe.
Penanganan kesalahan.Setiap modul melewati keadaan dimana
kesalahan muncul dannomor kesalahan untuk ditangani.
Standar pemrograman.Standar pemrograman terstruktur seperti pemunculan kode(white space, memasukkan, komentar-komentar), konsepyang diperbolehkan, organisasi, ukuran modul, danketergantungan secara rinci. Membuat ‘template’ yangberisi komentar seperti :• Judul• Parameter-parameter (penerima, pengirim)• Masukkan (hanya satu)• Variabel yang digunakan• Memanggil subroutine• Penanganan kesalahan• Exit (hanya satu)
Programmer memulai dengan template ini dan mengisikan kode proses.
Spesifikasi Desain
• Judul halaman dan daftar isi
• Gambaran umum (Overview)
• Daftar hardware / software yang akan dipakai
• Daftar urutan prioritas disain
• Diagram disain dan beberapa modul
dictionary yang umum
• Beberapa kebiasaan penamaan modul yang
umum
• Parameter yang dipakai dan Data Dictionaries
• Penanganan kesalahan. Jelaskan bagaimana kesalahan
akan ditangani
• Standar pemrograman terstruktur
• Alat pemrograman terstruktur
• Top Level Design. Termasuk struktur diagram TLD
• Medium Level Design. Termasuk struktur diagram MLD
• Modul dan kamus data
• File dan Tabel
Menguji Desain
• Semua keperluan Spesifikasi Fungsi
sudah ketemu.
• Disain mudah diprogram dan
dipelihara.
• Dapat diimplementasikan sesuai
dengan waktu dan anggaran.
Merubah Permintaan Sesuai Desain
Beberapa disain yang rinci akan selalu membawa pada perubahan permintaan.
Anda harus kembali kepada user sekarang dan meyakinkan user bahwa dia sebenarnya
tidak menginginkan apa yang dia minta sebelumnya.
Outline
Pelaksanaan
• Kasus acceptance test dibagi menjadi dua sub grup :
1. Test case dasar
2. Test case yang lebih kompleks untuk dieksekusi
• Acceptance test dilakukan dalam dua fase :
1. Fase pertama test case dari kelompok tes dasar dieksekusi
2. Jika hasil tes pertama memuaskan, lalu dilanjutkan fase kedua
dimana test case yang kompleks dieksekusi
3. Sebagai tambahan, subset dari level sistem test case dieksekusi
oleh perencana acceptance test untuk dikonfirmasi sebagai hasil
tes.
Aktivitas
• Pengembang memberikan pelatihan kepada
customer dalam menggunakan sistem.
• Pengembang dan customer Bersama-sama
memperbaiki masalah yang muncul selama
acceptance tes.
• Pengembang dan customer menyelesaikan
masalah yang muncul dalam perbedaan
kriteria penerimaan.
Aktivitas
• Pengembang memberikan pelatihan kepada
customer dalam menggunakan sistem.
• Pengembang dan customer Bersama-sama
memperbaiki masalah yang muncul selama
acceptance tes.
• Pengembang dan customer menyelesaikan
masalah yang muncul dalam perbedaan
kriteria penerimaan.
Dokumen ACC
Laporan Acceptance Test
• Aktivitas acceptance test didisain
untuk mencapai kesimpulan :
1. Terima sistem yang dikirimkan
2. Terima sistem setelah permintaan
modifikasi dilakukan.
3. Jangan terima sistem
• Biasanya keputusan tingkat menengah yang berguna dibuat
sebelum membuat keputusan akhir.
1. Keputusan yang dibuat tentang kelanjutan acceptance
test pada fase pertama acceptance test bukanlah janji.
2. Jika hasil tes tidak memuaskan, rubah sistem sebelum
acceptance test bisa dilanjutkan ke fase selanjutnya.
• Selama eksekusi acceptance test, tim menyiapkan laporan
harian.
Laporan Status Acceptance Test
Laporan Acceptance Test