Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Pengelolaan Proyek Sistem Informasi Fase Design. Outline Metode Mendesain Proses Desain Standar Desain Dokumentasi Teknik ◦ Outline Design Specification.

Presentasi serupa


Presentasi berjudul: "Pengelolaan Proyek Sistem Informasi Fase Design. Outline Metode Mendesain Proses Desain Standar Desain Dokumentasi Teknik ◦ Outline Design Specification."— Transcript presentasi:

1 Pengelolaan Proyek Sistem Informasi Fase Design

2 Outline Metode Mendesain Proses Desain Standar Desain Dokumentasi Teknik ◦ Outline Design Specification Menguji Desain

3 Fase Design Tujuan fase ini adalah: ◦ Membuat desain awal ◦ Desain yang detail ◦ Membuat laporan

4 Fase Design Membuat desain awal ◦ Desain awal mendeskripsikan kapabilitas fungsional secara umum dari sistem informasi yang diusulkan ◦ Perangkat yang digunakan pada fase ini adalah perangkat CASE dan perangkat lunak manajemen proyek ◦ Prototyping juga dilakukan pada tahap ini

5 Fase Design Membuat desain awal ◦ Prototyping ialah membuat model kerja dari komponen sistem sehingga sistem baru bisa segera diuji dan dievaluasi ◦ Dengan kata lain prototype adalah sistem dengan kemampuan kerja terbatas yang dikembangkan untuk menguji konsep-konsep desain

6 Fase Design Membuat desain yang detail ◦ Desain yang detail menggambarkan bagaimana sistem informasi yang diusulkan mampu memberikan kapabilitas yang digambarkan secara umum dalam desain awal

7 Fase Design Menulis laporan ◦ Semua pekerjaan dalam desain awal dan desain yang detail akan dikemas dalam laporan yang terperinci ◦ Anda dapat melakukan persentasi atau diskusi saat menyerahkan laporan ini kepada manajemen senior

8 Fase Design Output utama dari tahapan desain perangkat lunak adalah spesifikasi desain Spesifikasi ini meliputi spesifikasi desain umum yang akan disampaikan kepada stakeholder sistem dan spesifikasi desain rinci yang akan digunakan pada tahap implementasi Spesifikasi desain umum hanya berisi gambaran umum agar stakeholder sistem mengerti akan seperti apa perangkat lunak yang akan dibangun

9 Fase Design 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 dari desain database, desain proses, desain user interface yang mencakup desain input, output form dan report, desain hardware, software dan jaringan. Desain proses merupakan kelanjutan dari pemodelan proses yang dilakukan pada tahapan analisis

10 Fase Design Aktivitas utama: ◦ Membuat top dan medium level dari desain sistem dan mendokumentasikannya dalam Spesifikasi Desain ◦ Melakukan Rencana Test Penerimaan (Acceptance Test Plan/ATP)  ATP adalah sebuah dokumen tes yang akan digunakan untuk mendemonstrasikan seluruh fungsi sistem kepada user pada fase penerimaan

11 Fase Design Terdapat dua langkah dalam mendesain sistem software, yaitu: ◦ Pertama, bagilah sistem menjadi beberapa komponen secara fungsional ◦ Kedua, hubungkanlah komponen-komponen tersebut

12 Metode Mendesain Desain Terstruktur (Structured Design) Tujuan utama dari desain yang terstruktur adalah memecah sistem menjadi bagian yang lebih kecil, teratur dan mudah untuk dibangun

13 Metode Mendesain Top Down Design ◦ Desain Top Down dimulai dengan Top Level Design (TLD) ◦ Masing-masing komponen utama atau kotak dalam TLD dipecah menjadi sub-bagian dimulai dengan level teratas, kemudian turun ke level berikutnya, dst. ◦ Dimulai dengan MENU dan mendesainnya sebelum turun ke INQUIRY, UPDATE, dan REPORT GENERATION, yang akan diikuti dengan tingkat selanjutnya, jika ada

14 Metode Mendesain Bottom Up Design ◦ Pada kasus tertentu mungkin akan lebih mudah mendesain dengan menggunakan pendekatan dari level bawah ke level atas ◦ Hal ini sering ditemui pada kasus sistem pengontrolan proses dimana peralatan pengontrolan hardware pada level terbawah menentukan bagaimana sistem tersebut disatukan (integrasi sistem) ◦ Desain Bottom Up juga sangat cocok digunakan pada kasus dimana komponen software yang ada digabungkan dan disatukan dengan modul baru untuk membangun sebuah sistem

15 Metode Mendesain Umumnya 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

16 Metode Mendesain TLD yang lain ada juga yang cocok. Salah satu masukkan mungkin adalah menghilangkan INQUIRY, UPDATE dan REPORT GENERATION serta menggunakan rutin FILE 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

17 Metode Mendesain Prioritas Desain ◦ Pilihan TLD Anda 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 ini harus menjadi prioritas, bersama dengan user pada waktu perencanaan sistem, pada saat pendefinisian dan analisis

18 Metode Mendesain Medium Level Design ◦ 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 seluruh sistem dimulai dan menampilkan menu utama ke bagian register ◦ Kemudian program menunggu user untuk memindahkan mouse

19 Metode Mendesain ◦ Sub fungsi utama komponen MENU adalah:  Memulai sistem dan menampilkan main menu  Menangani perpindahan mouse  Menangani tombol pada mouse  Pindah ke Menu INQUIRY, UPDATE, WAREHOUSE atau REPORT ketika dipilih  Menangani kesalahan-kesalahan seperti pada on line help messages untuk seluruh sistem  Mematikan sistem jika QUIT dipilih ◦ Level terendah dari suatu menu menggambarkan modul. Sebuah modul adalah bagian terkecil yang dapat ditest dan dicompile

20 Metode Mendesain 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

21 Metode Mendesain Modul Terstruktur ◦ 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

22 Metode Mendesain Desain File Mengoptimalkan File ◦ Mengoptimalkan penyimpanan disk dengan mengurangi kerangkapan field-field dan file-file File History ◦ Apa yang kita lakukan tentang data pada siswa- siswa yang telah mengambil sebuah kursus? Pemecahan masalah ini dengan mendefinisikan sebuah file STUDENT_HISTORY dan setelah seorang siswa mengambil sebuah kursus, recordnya dipindahkan dari file STUDENT ke history

23 Metode Mendesain Pengujian Desain File ◦ Pada desain ini, setiap permintaan kebutuhan yang melibatkan pengaksesan data harus “diproses” dengan desain file. Hal ini menandai perkembangan selanjutnya ◦ Bentuk untuk jenis database query khusus ini sudah distandarisasi, dan ini disebut Structured Query Language (SQL)

24 Metode Mendesain Keuntungan dari Analisis & Desain yang Terstruktur Mengurangi Jumlah Kesalahan ◦ Tabel statistik berikut ini diambil dari hasil survei oleh TRW untuk proyek besar, dan DEC’s Customer Services Systems Engineering (yaitu departemen yang bertanggung jawab untuk memastikan bahwa produk-produk DEC baik software maupun hardwarenya benar-benar bebas dari virus)

25 Metode Mendesain Menggunakan metode tidak terstruktur: Analysis and Design Remaining Phase After Operation Effort Spent10%23%67% Problem Introduced 64%36% Problem Found 19%27%54% Dollars Spent (AVG) 25K57.5K167.5K Total: 250K

26 Metode Mendesain Menggunakan metode terstruktur: Analysis and Design Remaining Phase After Operation Effort Spent20%50%30% Problem Introduced 32%68% Problem Found 30%33%37% Dollars Spent (AVG) 40K50K100K Total: 190K

27 Metode Mendesain Meskipun biaya dimuka mengalami kenaikan, metode terstruktur tetap mengurangi biaya sistem secara keseluruhan

28 Proses Desain Design Team ◦ Pilihlah orang-orang terbaik untuk tim desain ◦ Tim desain yang baik tidak perlu orang yang menguasai bahasa pemrograman ◦ Mereka haruslah orang yang dapat mengkonsep semuanya ◦ Hindari orang-orang yang selalu menginginkan kesempurnaan (perfectionist) dalam tim desain

29 Proses Desain Design Meeting ◦ Merancang sesuatu mirip dengan 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

30 Standar Desain Buatlah aturan yang standar seperti berikut: ◦ 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

31 Standar Desain ◦ Standar pemrograman  Standar pemrograman terstruktur seperti:  Judul  Parameter-parameter (penerima, pengirim)  Masukan  Variabel yang digunakan  Memanggil subroutine  Penanganan kesalahan  Exit (hanya satu)

32 Dokumentasi Teknik Pertimbangkan hal-hal berikut ketika menulis dokumentasi teknik: ◦ Gunakan bahasa yang formal dan tepat ◦ Gunakan gambar, diagram yang terstruktur dan yang sejenisnya ◦ Buatlah agar maksud dari desain menjadi jelas pada beberapa halaman pertama, kemudian uraikan ◦ Cobalah untuk konsisten pada grafik-grafik dan struktur kalimat

33 Outline Design Specification Spesifikasi disain terdiri atas: ◦ Judul halaman dan daftar isi ◦ Gambaran umum (Overview) ◦ Daftar hardware/software yang akan dipakai ◦ Daftar urutan prioritas desain ◦ Diagram desain dan beberapa modul dictionary yang umum ◦ Beberapa kebiasaan penamaan modul yang umum ◦ Parameter yang dipakai dan Data Dictionaries

34 Outline Design Specification ◦ 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

35 Menguji Desain Ketika desain telah diselesaikan, semuanya harus berjalan dengan benar. Maksudnya adalah untuk menjamin hal-hal berikut ini: ◦ Semua keperluan Spesifikasi Fungsi sudah ditemukan ◦ Desain mudah diprogram dan dipelihara ◦ Dapat diimplementasikan sesuai dengan waktu dan anggaran


Download ppt "Pengelolaan Proyek Sistem Informasi Fase Design. Outline Metode Mendesain Proses Desain Standar Desain Dokumentasi Teknik ◦ Outline Design Specification."

Presentasi serupa


Iklan oleh Google