METODOLOGI MANAJEMEN PROYEK FASE 3 : Desain

  Hera Agustina, S.Kom., MMSI METODOLOGI MANAJEMEN PROYEK

FASE 3 : Desain

Pendahuluan

• 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.

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.

Langkah Dalam Fase Desain

  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 Mendesain

Sistem Software

  1. Bagilah sistem menjadi beberapa komponen secara fungsional.

  2. Hubungkanlah komponen-komponen tersebut.

Output

• 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.

• 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.

Masalah Dalam Fase Desain

• Metode pembuatan software, metode dan tools yang digunakan tidak optimal sehingga mempengaruhi kualitas produk dan tidak sesuai dengan keinginan user.

  pembuatan software, tidak adanya

• Organisasi koordinasi pada proses pembuatan software sehingga terjadi modul-modul yang tidak dapat digabungkan. Misalnya ketidaksesuaian nama tabel, field, dll.

Tujuan

• Membuat desain awal
• Desain yang detail
• Membuat laporan

  Membuat Desain Awal

• 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.

Desain yang Detail

  

Menggambarkan bagaimana sistem

informasi yang diusulkan mampu

memberikan kapabilitas yang

digambarkan secara umum dalam

desain awal.

Menulis Laporan

• 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.

Kegiatan

  

Design Sistem Fisik

Desain Arsitektur

Desain Interface

Desain Program

  

Desain Database dan File

Teknik yang Digunakan

• Design Strategy Architecture •Design Hardware dan Software •Selection Use Scenario

  •Interfacse Structure

  •Interface Standards

  Teknik

• •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

• 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)

  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 digunakan

untuk semua tingkatan yang rendah.

  

Parameter yang mendahului.

Rincian perintah, panjang, format / tipe.

  

Penanganan kesalahan.

Setiap modul melewati keadaan dimana

kesalahan muncul dan

nomor kesalahan untuk ditangani. Standar pemrograman.

Standar pemrograman terstruktur seperti pemunculan kode

(white space, memasukkan, komentar-komentar), konsep

yang diperbolehkan, organisasi, ukuran modul, dan

ketergantungan secara rinci. Membuat ‘template’ yang

berisi 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

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