Tahapan desain adalah tahapan di mana spesifikasi proyek secara lengkap dibuat. Tahapan desain menjawab pertanyaan "Bagaimana sistem yang akan dibuat?" Pada tahapan desain ada beberapa dokumen yang akan dibuat, meliputi: Process Modelling (Pemodelan proses) Data Modelling (Pemodelan data) Interface Design (Desain antar muka) Tahapan di atas termasuk dalam tahapan desain secara logis (logical design). Setelah keseluruhan fase desain logikal selesai, tahapan berikutnya adalah desain fisik (Physical design). Tahapan fisik adalah tahapan di mana perangkat lunak dikonstruksi. Tahapan inilah yang sering dinamakan coding.
Gambar oleh Gerd Altmann dari Pixabay |
Tahapan Desain Sistem Dalam Penelitian Sistem Informasi - Tahapan desain adalah tahapan di mana spesifikasi proyek secara lengkap dibuat. Tahapan desain menjawab pertanyaan "Bagaimana sistem yang akan dibuat?" Pada tahapan desain ada beberapa dokumen yang akan dibuat, meliputi:
- Process Modelling (Pemodelan proses)
- Data Modelling (Pemodelan data)
- Interface Design (Desain antar muka)
Tahapan di atas termasuk dalam tahapan desain secara logis (logical design). Setelah keseluruhan fase desain logikal selesai, tahapan berikutnya adalah desain fisik (Physical design). Tahapan fisik adalah tahapan di mana perangkat lunak dikonstruksi. Tahapan inilah yang sering dinamakan coding.
PEMODELAN PROSES (PROCESS MODELLING)
Setelah tahapan analisis selesai, maka usulan kebutuhan sistem harus diterjemahkan menjadi sistem informasi berbasis komputer. Proses mengubah usulan kebutuhan menjadi perangkat lunak bukan hal yang mudah. Harus ada beberapa langkah yang digunakan untuk mempermudah dan menjamin perangkat lunak yang dihasilkan berkualitas. Langkah awal desain biasanya dimulai dengan pemodelan sistem. Model digunakan untuk menyederhanakan cara mengkomunikasikan proses-proses bisnis yang harus dilakukan sistem dengan cara yang formal antar pemain pengembangan sistem informasi. Pemodelan yang dilakukan biasanya mencakup dua hal, yaitu pemodelan proses dan pemodelan data.
PROSES MODEL
Pemodelan proses adalah cara formal untuk menggambarkan bagaimana bisnis beroperasi. Mengilustrasikan aktivitas-aktivitas yang dilakukan dan bagaimana data berpindah di antara aktivitas-aktivitas itu. Ada banyak cara untuk merepresentasikan proses model. Cara yang populer adalah dengan menggunakan data flow diagram (DFD). Ada dua jenis DFD, yaitu DFD logis dan DFD fisik. DFD logis menggambarkan proses tanpa menyarankan bagaimana mereka akan dilakukan, sedangkan DFD fisik menggambarkan proses model berikut implementasi pemrosesan informasinya.
DATA FLOW DIAGRAM
Untuk membaca suatu DFD kita harus memahami dulu, elemen-elemen yang menyusun suatu DFD. Ada empat elemen yang menyusun suatu DFD, yaitu:
- PROSES, Aktivitas atau fungsi yang dilakukan untuk alasan bisnis yang spesifik, biasa berupa manual maupun terkomputerisasi.
- DATA FLOW, Satu data tunggal atau kumpulan logis suatu data, selalu diawali atau berakhir pada suatu proses.
- DATA STORE, Kumpulan data yang disimpan dengan cara tertentu. Data yang mengalir disimpan dalam data store. Aliran data di-update atau ditambahkan ke data store.
- EXTERNAL ENTITY, Orang, organisasi, atau sistem yang berada di luar sistem tetapi berinteraksi dengan sistem.
Masing-masing elemen akan diberi lambang tertentu untuk membedakan satu dengan yang lain. Ada beberapa metode untuk menggambarkan elemen-elemen tersebut.
MENGGAMBARKAN PROSES BISNIS DENGAN DFD
Proses bisnis biasanya terlalu kompleks untuk ditunjukkan dalam satu DFD. Dekomposisi adalah proses untuk menggambarkan sistem dalam hierarki dari diagram DFD. Diagram anak menggambarkan proses yang lebih detail dibandingkan dengan diagram induk. Harus ada proses balancing untuk menjamin informasi yang disajikan dalam satu lebel dari suatu DFD secara akurat direpresentasikan pada DFD level berikutnya.
CONTEXT DIAGRAM
DFD pertama dalam proses bisnis. Menunjukkan konteks di mana proses bisnis berada. Menunjukkan semua proses bisnis dalam 1 proses tunggal (proses 0). Context diagram juga menunjukkan semua entitas luar yang menerima informasi dari atau memberikan informasi ke sistem.
LEVEL 0 DIAGRAM
Menunjukkan semua proses utama yang menyusun keseluruhan sistem. Level ini juga menunjukkan komponen internal dari proses 0 dan menunjukkan bagaimana proses-proses utama direlasikan menggunakan data flow. Pada level ini juga ditunjukkan bagaimana proses-proses utama terhubung dengan entitas eksternal. Pada level ini juga dilakukan penambahan data store.
LEVEL 1 DIAGRAM
Umumnya diagram level 1 diciptakan dari setiap proses utama dari level 0. Level ini menunjukkan proses-proses internal yang menyusun setiap proes-proses utama dalam level 0, sekaligus menunjukkan bagaimana informasi berpindah dari satu proses ke proses yang lainnya. Jika misalnya proses induk dipecah, katakanlah menjadi 3 proses anak, maka 3 proses anak ini secara utuh menyusun proses induk.
LEVEL 2 DIAGRAM
Menunjukkan semua proses yang menyusun sebuah proses pada level 1. Bisa saja penyusunan DFD tidak mencapai level 2 ini. Atau mungkin harus dilanjutkan ke level berikutnya (level 3, level 4, dan seterusnya).
PEMODELAN DATA (DATA MODELLING)
Proses model menggambarkan keseluruhan proses bisnis yang akan dilakukan oleh sistem informasi yang akan dibangun. Proses model juga menjelaskan data-data yang terlibat dalam proses-proses tersebut. Tetapi proses model tidak menggambarkan bagaimana data diorganisir dan dikelompokkan. Juga tidak menggambarkan hubungan logis antar kelompok data. Untuk masalah seperti ini diperlukan pemodelan lain yaitu pemodelan data.
DATA MODEL
Data model adalah cara formal untuk menggambarkan data yang digunakan dan diciptakan dalam suatu sistem bisnis. Model ini menunjukkan orang, tempat atau benda di mana data diambil dan hubungan antar data tersebut. Pemodelan data juga dibedakan menjadi dua, yaitu model data logis (logical data model) dan model data fisik (physical data model). Model data logis menunjukkan pengaturan data tanpa mengindikasikan bagaimana data tersebut disimpan, dibuat, dan dimanipulasi. Model data fisik menunjukkan bagaimana data akan disimpan sebenarnya dalam database atau file. Penyusunan pemodelan data harus seimbang dengan pemodelan proses. Salah satu cara pemodelan data adalah dengan ERD (Entity Relationship Diagram).
THE ENTITY RELATIONSHIP DIAGRAM (ERD)
Apakah ERD itu? ERD adalah gambar atau diagram yang menunjukkan ifnormasi dibuat, disimpan , dan digunakan dalam sistem bisnis. Entitas biasanya menggambarkan jenis informasi yang sama. Dalam entitas digunakan untuk menghubungkan antar entitas yang sekaligus menunjukkan hubungan antar data. Pada akhirnya ERD bisa juga digunakan untuk menunjukkan aturan-aturan bisnis yang ada pada sistem informasi yang akan dibangun. Bagaimana menggunakan ERD untuk menunjukkan aturan bisnis? Ada beberapa poin yang bisa dilihat untuk menjawab pertanyaan ini:
- Aturan bisnis adalah batasan yang harus diikuti ketika sistem beroperasi.
- Simbol ERD hanya menunjukkan satu instance dari entitas harus ada sebelum instance lain dari suatu entitas. Sebagai contoh: seorang dokter harus ada sebelum perjanjian ketemu dengan dokter dibuat.
- Simbol ERD dapat menunjukkan ketika salah satu instance dari suatu entitas dapat direlasikan dengan satu anggota atau lebih dari entitas lainnya. Sebagai contoh, satu dokter bisa memiliki banyak pasien, satu pasien bisa jadi hanya memiliki satu dokter utama.
- Simbol ERD juga menunjukkan ketika eksistensi dari suatu instance dalam suatu entity adalah opsional untuk sebuah relasi dengan instance lain dari suatu entitas. Sebagai contoh, pasien mungkin memiliki atau mungkin tidak memiliki biaya asuransi.
ELEMEN-ELEMEN ERD
Seperti data flow diagram, ERD juga menggunakan simbol-simbol khusus untuk menggambarkan elemen-elemen ERD.
Entitas
Entitas bisa berupa orang, kejadian, atau benda di mana data akan di kumpulkan. Untuk menjadi sebuah entitas, suatu objek harus menampilkan beberapa kali event. Sebagai contoh, jika sebuah firma hanya memiliki 1 gudang, maka gudang tersebut bukan entitas. Tetapi jika perusahaan memiliki banyak gudang, maka gudang bisa menjadi instance suatu entitas jika perusahaan ingin menyimpan data untuk setiap anggota dari gudang.
Atribut
- Informasi yang diambil tentang sebuah entitas.
- Hanya yang digunakan oleh organisasi yang dimasukkan dalam model.
- Nama atribut harus merupakan kata benda.
- Kadang nama entitas diletakkan di depan nama atribut untuk ketelitian.
Identifier
- Satu atau lebih atribut dapat menjadi identifier entitas, yang secara unik mengidentifikasi setiap anggota dari entitas.
- Concatenated identifier (identifier gabungan) terdiri dari beberapa atribut.
- Identifier bisa saja artifisial, seperti dengan membuat nomor ID.
- Identifier tidak akan dikembangkan sampai fase desain.
Relationships
- Hubungan antar entitas.
- Entitas pertama dalam relationship disebut entitas induk, entitas kedua disebut sebagai entitas anak.
- Relationship harus memiliki nama yang berupa kata kerja.
- Relationship berjalan 2 arah.
Sebagai contoh, jika dimiliki dua entitas, yaitu buku dan toko buku, maka bisa dibuat beberapa relationship, di antaranya:
- Toko buku memesan buku.
- Toko buku menampilkan buku.
- Toko buku menstok buku.
- Toko buku menjual buku.
- Toko buku mengembalikan buku.
Relationship memesan, menampilkan, menstok, menjual, dan mengembalikan mendefinisikan hubungan yang relevan antara buku dan toko buku.
Kardinalitas
- Kardinalitas mengacu pada berapa kali instance dari suatu entitas dapat berelasi dengan instance lain di entitas yang berbeda.
- Satu instance dalam suatu entitas mengacu pada satu dan hanya satu instance pada entitas lainnya (1:1).
- Satu instance dalam suatu entitas mengacu ke satu atau lebih instance yang berelasi (1:N).
- Satu atau lebih instance dalam suatu entitas mengacu pada satu atau lebih instance pada entitas yang berelasi (M:N).
Modalitas
- Mengacu pada apakah suatu instance dari entitas anak dapat ada tanpa suatu relasi dengan instance dari entitas induk atau tidak.
- Not Null, berarti bahwa suatu instance pada entitas yang berelasi harus ada untuk suatu instance dari entitas lain untuk disebut valid.
- Null, berarti bahwa tidak ada instance dalam entitas yang berelasi yang diperlukan untuk instance pada relasi lain untuk dikatakan valid.
MEMVALIDASI ERD
Untuk membuat ERD, diperlukan latihan dan jam terbang. Ada beberapa pedoman yang perlu diperhatikan untuk membuat ERD, di antaranya:
- Entitas harus memiliki banyak kejadian/realitas.
- Hindari penggunaan atribut yang tidak perlu.
- Berilah label yang jelas untuk semua komponen.
- Pasangkan kardinalitas dan modalitas yang jelas dan benar.
- Pecah atribut menjadi level serendah mungkin yang diperlukan.
- Label harus merefleksikan istilah-istilah bisnis yang umum.
- Asumsi harus disebutkan dengan jelas.
NORMALISASI
Normalisasi adalah teknik yang digunakan untuk memvalidasi model data. Serangkaian aturan diberlakukan pada data model logis untuk meningkatkan pengaturannya. Biasanya ada tiga aturan yang digunakan.
LANGKAH-LANGKAH NORMALISASI
Berikut adalah langkah-langkah yang digunakan untuk melakukan normalisasi terhadap data model yang telah kita peroleh:
Unnormalized Entity (0 Normal Form)
Mulai dengan Entitas dari model data logis.
First Normal Form (1NF)
Apakah ada atribut yang memiliki nilai ganda untuk satu anggota dari suatu entitas?
Ya: Hilangkan atribut yang berulang dan grup yang berulang. Buat entitas yang menggambarkan atributatributnya. Biasanya diperlukan penambahan relasi untuk menghubungkan entitas baru dan lama.
Tidak: Model data ada dalm bentuk 1NF (1 Normal Form).
Cari kelompok-kelompok atribut yang berulang dan pisahkan ke dalam entitas yang berbeda.
Second Normal Form (2NF)
Apakah identifier terdiri dari lebih dari satu atribut? Jika ya, apakah nilai atribut tergantung hanya pada satu bagian dari identifier?
Ya: Hilangkan ketergantungan parsial. Hilangkan atribut suatu entitas di mana nilai-nilai mereka tergantung pada ke semua identifier. Biasanya diperlukan penambahan relasi untuk menghubungkan entitas baru dan lama.
Tidak: Model data dalam bentuk 2NF (2 Normal Form).
Jika ada entitas yang memiliki identifier gabungan, cari atribut yang hanya bergantung pada identifier. Jika ditemukan, pindahkan ke entitas baru.
Third Normal Form (3NF)
Apakah ada nilai-nilai atribut yang tergantung pada entitas yang bukan identifier?
Ya: Hilangkan ketergantungan transitif atau entitas turunan. Pindahkan atribut ke entitas dimana atribut tersebut bergantung pada identifier. Biasanya diperlukan penambahan relasi untuk menghubungkan entitas baru dan lama.
Tidak: Model data ada dalam bentuk 3NF (3 Normal Form).
Cari atribut yang bergantung hanya pada atribut lain yang bukan merupakan identifier. Jika ditemukan, pindahkan menjadi entitas baru. Pindahkan juga atribut-atribut yang perlu dipindahkan.
MENYEIMBANGKAN ERD DENGAN DFD
Semua aktivitas analisis merupakan aktivitas-aktivitas yang saling berkaitan, termasuk pemodelan proses dan pemodelan data. Proses model akan berisi dua hal, yaitu data flow dan data store. Komponen data dalam DFD ini harus diseimbangkan dengan ERD, di mana data store diseimbangkan dengan entitas dan elemen data diseimbangkan dengan atribut. Untuk mempermudah, banyak tool CASE yang menyediakan fitur untuk mengecek ketidakseimbangan.
HIERARCHY INPUT OUTPUT CHART (HIPO)
HIPO merupakan teknik untuk mendokumentasikan pengembangan suatu sistem yang dikembangkan oleh IBM.
HIPO dapat digunakan untuk memenuhi kebutuhan beberapa pengguna untuk kepentingan berbeda-beda, antara lain:
- Seorang manajer dapat menggunakan dokumentasi HIPO untuk memperoleh gambaran umum sistem.
- Seorang Programer menggunakan HIPO untuk menentukan fungsi-fungsi dalam program yang dibuatnya.
- Programer juga dapat menggunakan HIPO untuk mencari fungsi-fungsi yang dimodifikasi dengan cepat.
Teknik ini mempunyai beberapa tujuan utama. Pertama dapat dibuat sebuah struktur yang menggambarkan hubungan antar fungsi dalam program secara hierarkis. Sasaran kedua adalah untuk menentukan fungsi-fungsi apa saja yang harus ada dalam sistem yang dikembangkan. Sasaran ketiga adalah untuk mendapatkan gambaran input dari fungsi dan output apa yang dihasilkan.
JENIS DIAGRAM HIPO
Paket HIPO terdiri dari 3 jenis diagram, yaitu diagram daftar isi visual (visual table of content). Diagram ringkas (overview diagram), dan diagram rinci (detail diagram).
DAFTAR ISI VISUAL (DIV)
Diagram ini memuat semua modul yang ada dalam sistem berikut nama dan nomornya, yang nantinya akan diperinci dalam diagram ringkas dan diagram rinci. Dalam DIV juga bisa dilihat fungsi-fungsi utama yang menyusun sebuah sistem dan hubungan antar fungsi tersebut.
DIAGRAM RINGKAS
Diagram ringkas menerangkan input, proses, dan output dari sistem. Diagram ringkas menggambarkan input dan output dari fungsi-fungsi yang telah didefinisikan dalam daftar isi visual.
DIAGRAM RINCI
Diagram rinci HIPO digunakan untuk memperinci input, proses, dan output yang telah digambarkan dalam diagram ringkas. Dalam input data dijelaskan field-field datanya secara detail. Untuk fungsi, juga dideskripsikan proses apa yang dilakukan oleh fungsi-fungsi tersebut.
DESAIN ANTARMUKA
Beberapa aplikasi akan memiliki antarmuka pengguna yang sederhana, yang lain akan memiliki antramuka pengguna yang kompleks. Antarmuka pengguna merupakan tampilan di mana pengguna berinteraksi dengan sistem. Karena ada berbagai tingkat pengguna, untuk mendesain suatu antarmuka pengguna diasumsikan pengguna yang menggunakannya nanti merupakan pengguna akhir. Dalam mendesain, hanya ada 1 antarmuka pengguna untuk setiap pengguna, kecuali untuk beberapa sistem yang memiliki fasilitas pengguna yang bertingkat, maka antarmuka pengguna akan berhubungan dengan level atau hak akses user tersebut. Tujuan dari antarmuka pengguna adalah untuk memungkinkan pengguna menjalankan setiap tugas dalam kebutuhan pengguna (user requirement). Jadi dalam membangun sebuah antarmuka pengguna harus berdasar pada kebutuhan pengguna.
Dalam mengembangkan antarmuka pengguna perlu diingat beberapa prinsip antarmuka pengguna yang lain, yaitu:
- Antarmuka yang baik tida mengharuskan pengguna untuk mengingat tampilan antarmuka pengguna.
- Antarmuka pengguna menampilkan apa yang dimengerti oleh pengguna atau visualisasi keadaan dari sistem sekarang.
Dalam hal ini, ada beberapa hal yang harus dihindari:
- Menampilkan terlalu banyak informasi dan terlalu banyak pilihan.
- Menampilkan terlalu sedikit informasi, terlalu sedikit pilihan, dan tanpa konteks.
- Eksploitasi struktur menu standar yang sudah familiar dengan perangkat lunak yang sering digunakan user.
MERANCANG ANTARMUKA PENGGUNA
Untuk mengetahui seperti apa antarmuka pengguna dari suatu sistem ketika perangkat lunak dikembangkan. Seringkali analis membuat dulu konsep rancangan antarmuka pengguna untuk seluruh form secara lengkap. Dari rancangan ini akan terlihat bagaimana pengguna akan memasukkan data, melakukan pemilihan menu, maupun mendapatkan output hasil pemrosesan sistem informasi.
Rancangan antarmuka pengguna seringkali cukup detail. Tetapi itu biasanya diperuntukkan pengguna yang cukup familiar dengan sistem yang terkomputerisasi. Yang paling penting adalah, dalam merancang antarmuka pengguna usahakan menyesuaikan dengan perangkat lunak yang sudah familiar digunakan oleh pengguna akhir. Sebagai contoh, karena sebagian besar pengguna akhir familiar menggunakan MS WORD maka bisa dirancang antarmuka pengguna yang mengakomodasi gaya MS WORD dalam menempatkan pilihan-pilihan menunya.
Al Fatta, Hanif. 2007. Analisis & Perancangan Sistem Informasi. Yogyakarta: ANDI
KOMENTAR