FASE DESAIN

PENDAHULUAN Aktivitas utama dalam Fase Disain adalah membuat top dan medium level dari disain sistem dan mendokumentasikannya dalam Spesifikasi Disain Aktivitas kedua dimulai dengan 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.

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 computer, metode interfacing, teknik konversi data, metode migrasi sitem 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, dalam hal perangkat keras, perangkat lunak, dan  jaringan infrastruktur; antarmuka pengguna, formulir dan laporan, dan program khusus, database, dan file yang akan dibutuhkan.

Sementara itu secara paralel dan bersama- sama tim bisnis atau manajemen akan melakukan perancangan terhadap komponen-komponen organisasi yang terkait seperti prosedur (SOP = Standar Operation Procedures), struktur organisasi, kebijakan- kebijakan, teknik pelatihan, pendekatan SDM dan sebagainya

Terdapat dua langkah dalam mendisain sistem software, yaitu : • Pertama, bagilah sistem menjadi beberapa komponen secara fungsional. • Kedua, hubungkanlah komponen-komponen tersebut.

 Hasil tahap ini, yang berupa cetak biru rancangan sistem, secara teknis dan secara manajemen akan dijadikan pegangan dalam proses konstruksi dan implementasi komponen-komponen pada sistem informasi yang akan dikembangkan.

4 Langkah dalam fase desain: 1. Strategi desain pertama kali dibuat. Ini menjelaskan apakah sistem tersebut akan dibuat oleh programmer perusahaan sendiri, apakah sistem akan outsourcing ke perusahaan lain (biasanya perusahaan konsultan), atau apakah perusahaan akan membeli  ada paket perangkat lunak.

2. Mengarah pada pengembangan desain arsitektur dasar untuk sistem, yang menggambarkan perangkat keras, perangkat lunak, dan infrastruktur jaringan yang akan digunakan. di banyak kasus, sistem akan menambah atau mengubah infrastruktur yang sudah ada dalam organisasi.

3. Spesifikasi database dan file yang dikembangkan, mendefinisikan dengan tepat data apa yg akan akan disimpan dan di mana mereka akan disimpan 4. Tim analis mengembangkan rancangan/design program, yang mendefinisikan program yang harus ditulis dan apa yang akan tiap program lakukan.

Kegiatan Fase Desain Design Physical System Design Architecture Desain Interface Desain Program Desain Databases and Files

Teknik yang digunakan Design strategy Architecture Design Hardware & software Selection Use scenario Interface structur Interface standards Interface prototype Interface evaluation Modeling Denormalization Performance tuning dll

DISAIN YANG TERSTRUKTUR (STRUCTURED DESIGN) Tujuan utama dari disain yang terstruktur adalah memecah sistem menjadi bagian yang lebih kecil, teratur dan mudah untuk dibangun. Desain Top Down Desain Bottom Up

Masalah pada fase desain Metode Pembuatan Software Metode dan tools yang digunakan hasilnya tidak optimal, sesuai dengan keinginan user. Organisasi Pembuatan Software Tidak adanya koordinasi pada saat proses pembuatan software, sehingga terjadi modul-modul yang tidak dapat digabungkan. Misalnya tidak sesuainya nama tabel, field, atau tipe data yang digunakan.

RENCANA TES PENERIMAAN

Tujuan dari penerimaan adalah mendapatkan pernyataan tertulis dari user bahwa produk (dalam hal ini sistem) yang dikirim sesuai dengan yang dijanjikan.

PERIODE PERCOBAAN ATAU PARALLEL RUN (THE TRIAL PERIOD OR PARALLEL RUN) Pendekatan yang paling umum untuk penerimaan Tim proyek memasang sistem baru untuk dicoba oleh user dimana tim akan menambahkan dimensi untuk peralihan sistem lama yang sudah berjalan dengan baik sebagai perbandingan dan cadangan. Dalam kedua kasus ini klien menggunakan sistem baru selama ‘X’ hari. Jika tidak ada masalah maka user menerimanya, jika ada masalah maka tim proyek berusaha memperbaikinya dan melakukan kembali percobaan selama ‘X’ hari.

Masalah Parallel Run Masalah kecil dapat membuat anda menjalankan kembali selama ‘X’ hari untuk jangka waktu yang tidak terbatas. Kadang-kadang sistem software yang rumit tidak pernah 100% di-debug. Mungkin sulit untuk mencari penyebab dari suatu masalah. Jika 10 user berada pada sistem yang interaktif dan sistem tersebut rusak, ini merupakan tantangan untuk menemukan dengan tepat apa yang menyebabkan sistem tersebut rusak

Tidak ada jaminan bahwa semua kelebihan sistem akan dicoba dalam ‘X’ hari. Pada beberapa kasus, ditemukannya masalah adalah setelah garansinya telah habis dan penjual (vendor) tidak mau memperbaikinya. Biarkan end user masuk ke sistem pada hari pertama yang penerapannya tidak selalu bermanfaat. Karena dalam hal ini faktor penampilan lebih berperan.

SOLUSI : PENERIMAAN YANG LENGKAP SEDIKIT DEMI SEDIKIT (SOLUTION : A THOROUGH BUT PIECEMEAL ACCEPTANCE) Pendekatan ini adalah menemukan serangkaian tes yang mendemonstrasikan semua fungsi yang dijanjikan. Penerimaan akan dilakukan secara resmi melalui seluruh tes ini kepada pelanggan. Keberhasilan tes diakhiri satu per satu. Jika sebuah tes gagal, Tim proyek dengan penuh harapan memperbaiki masalah langsung di tempat pengujian. Jika itu masalah utama maka tes ditunda sampai masalah dapat diperbaiki

Serangkaian tes dan perintah yang dijalankan sistem disebut Rencana Tes Penerimaan (Acceptance Test Plan / ATP). Pendekatan ini mempunyai manfaat sebagai berikut : 1. Anda dapat mendemonstrasikan semua fungsi yang dijanjikan. 2. Sebuah tindakan yang menyebabkan masalah selalu diketahui 3. User tidak merasa takut tentang semuanya.