Rabu, 08 April 2020

Data Flow Diagram atau sering disingkat DFD adalah perangkat-perangkat analisis dan perancangan yang terstruktur sehingga memungkinkan peng-analis sistem memahami subsistem secara visual sebagai suatu rangkaian aliran data yang saling berkaitan.

Symbol – symbol dfd :

gambar 7 1

Di dalam DFD terdapat 3 level, yaitu :

- Diagram Konteks : menggambarkan satu lingkaran besar yang dapat mewakili seluruh proses yang terdapat di dalam suatu sistem. Merupakan tingkatan tertinggi dalam DFD dan biasanya diberi nomor 0 (nol). Diagram ini sama sekali tidak memuat penyimpanan data dan tampak sederhana untuk diciptakan.

- Diagram Nol (diagram level-1) : merupakan satu lingkaran besar yang mewakili lingkaran lingkaran kecil yang ada di dalamnya. Merupakan pemecahan dari diagram Konteks ke diagram Nol. di dalam diagram ini memuat penyimpanan data.

- Diagram Rinci : merupakan diagram yang menguraikan proses apa yang ada dalam diagram Nol.

Fungsi dari Data Flow Diagram adalah :

Data Flow Diagram (DFD) adalah alat pembuatan sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi.

DFD ini adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data, dengan kata lain DFD yaitu alat pembuatan model yang memberikan penekanan hanya pada fungsi sistem.

DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi.

Contoh diagram dfd :

gambar 7 2

ERD BERDASARKAN ANALISA KASUS

BAB VI
ERD BERDASARKAN ANALISA KASUS

6.1 Pengertian erd

ERD adalah salah satu model yang digunakan untuk mendesain database dengan tujuan menggambarkan data yang berelasi pada sebuah database.

Komponen penyusun ERD adalah sebagai berikut :

gambar 6 1

Entitas adalah objek dalam dunia nyata yang dapat dibedakan dengan objek lain, sebagai contoh mahasiswa,dosen.

Entitias terdiri atas beberapa atribut sebagai contoh atribut dari entitas mahasiswa adalah nim,nama,alamat, dll.

Atribut nim merupakan unik untuk mengidentifikasikan / membedakan mahasiswa yg satu dengan yg lainnya.

Pada setiap entitas harus memiliki 1 atribut unik atau yang disebut dengan primary key.

Relasi adalah penghubung antara beberapa entitas.

6.2 Rancangan membuat erd suatu kasus

Menggunakan tahapan yang disebut metodologi, berikut tahapannya :

a. Tentukan entitas terlebih dahulu

b. Tentukan relasi antar entitas, bagaimana hubungan antara entitas satu dengan yang lainnya.

c. Gambarlah ERD yang sifatnya sementara atau secara manual

d. Buat atau isi kardinalitas, hal ini diperlukan untuk menentuka jumlah kejadian.

e. Tentukan primary key atau kunci utama dalam sebuah entitas.

f. Lalu gambar ERD berdasarkan kunci utama.

g. Tentukan atribut dari setiap entitas yang ada.

h. Menggambar ERD secara lengkap denan atribut.

i. Lakukan evaluasi dan pemeriksaan terhadap hasil, apabila terdapat kekeliruan dapat mengulang langkahnya.

Contoh ERD Sederhana :

gambar 6 2

Entitas Atribut

1. Mahasiswa 1. Nim, nama, jurusan,alamat

2. Mata kuliah 2. Kdmk, nama_mk, sks

Gambar ERD sederhana di atas memiliki 2 entitas dengan nama Mahasiswa dan Mata Kuliah, serta satu proses yang menghubungkan keduanya. Entitas Mahasiswa memiliki atribut seperti Nim, Nama, Jurusan dan Alamat. Sedangkan Mata Kuliah memiliki kdmk, Nama_mk dan sks. Proses krs memiliki masukan berupa nim, kdmk, ta dan smt.Dalam proses di atas setiap Mahasiswa yang ingin mengontrak mata kuliah.

DESAIN SYSTEM

BAB V
DESAIN SYSTEM

5.1 Desain system

Desain atau perancangan dalam pembangunan perangkat lunak merupakan upaya untuk mengonstruksi sebuah sistem yang memberikan kepuasan (mungkin informal) akan spesifikasi kebutuhan fungsional, memenuhi target, memenuhi kebutuhan secara implisit atau eksplisit dan segi performansi maupun penggunaan sumber daya, kepuasan batasan pada proses desain dan segi biaya, waktu, dan perangkat.

Pada tahap desain secara umum, komponen-komponen sistem informasi dirancang dengan tujuan untuk dikomunikasikan kepada user bukan untuk pemrogram. Komponen sistem informasi yang didesain adalah : Desain Output Output (keluaran) adalah produk dari sistem informasi yang dapat dilihat. Istilah output ini kadang-kadang membingungkan, karena output dapat terdiri dari macammacam jenis. Output dapat berupa hasil di media keras (seperti misalnya kertas, microfilm) atau hasil di media lunak (berupa tampilan di layar video). Disamping itu output dapat berupa hasil dari suatu proses yang akan digunakan oleh proses lain dan tersimpan di suatu media seperti tape, disk atau kartu.

5.2 Defenisi desain system

Defenisi desain system :

Tahap setelah analisis dari siklus pengembangan system, Pendefinisian dari kebutuhan-kebutuhan fungsional, Persiapan untuk rancang bangun implentasi, Menggambarkan bagaimana suatu sistem dibentuk , Sistem dibentuk dapat berupa penggambaran, perencanaan dan pembuatan sketsa atau pengaturan dari beberapa elemen yang terpisah ke dalam satu kesatuan yang utuh dan berfungsi, Termasuk menyangkut mengkonfigurasi dari komponen-komponen perangkat lunak dan perangkat keras dari suatu system

Sistem Secara Umum output pada tahap desain ini adalah output yang berupa tampilan di media keras atau di layar video.

· TIPE OUTPUT Output dapat diklasifikasikan ke dalam beberapa tipe, yaitu :

a. Output Intern (internal output) Adalah output yang dimaksudkan untuk mendukung kegiatan manajemen. Output jenis ini dapat berupa laporan-laporan terinci, laporan-laporan ringkasan dan laporan-laporan lainnya.

b. Output Ekstern (external output) Adalah output yang akan didistribusikan kepada pihak luar yang membutuhkannya. Contoh output ekstern adalah faktur, check, tanda terima pembayaran dan lain sebagainya.

· PROSES INPUT

proses dari input dapat melibatkan 3 tahapan utama, yaitu :

a. Penangkapan data (data capture) Merupakan proses mencatat kejadian nyata yang terjadi akibat transaksi yang dilakukan oleh organisasi ke dalam dokumen dasar.

b. Penyiapan data (data preparation) yaitu mengubah data yang telah ditangkap ke dalam bentuk yang dapat dibaca oleh mesin.

c. Pemasukan data (data entry) Merupakan proses memasukkan data ke dalam komputer.

Untuk mencapai tujuan , analis sistem harus dapat mencapai sasaran-sasaran yaitu :

1. Desain sistem harus berguna, mudah dipahami dan nantinya mudah digunakan.

2. Desain sistem harus dapat mendukung tujuan utama perusahaan sesuai dengan yang didefinisikan.

3. Desain sistem harus efisien dan efektif untuk dapat mendukung pengolahan transaksi, pelaporan manajemen dan mendukung keputusan yang akan dilakukan oleh manajemen dan yang tidak dilakukan oleh komputer.

4. Desain sistem harus dapat mempersiapkan rancang bangun yang terinci untuk masing-masing komponen dari sistem informasi yang meliputi data dan informasi, simpanan data, metode-metode, prosedur-prosedur, orang-orang, perangkat keras, perangkat lunak dan pengendalian intern.

5.3 Desain dengan mockup

Membuat Prototipe menggunakan Mockup :

1. Install aplikasi mockup di PC atau laptop lalu buka aplikasi nya :

gambar 5 1

1. Langkah berikutnya yaitu memilih platform yang akan digunakan ,

dengan cara memilih menu toolbar container, di bagian container telah disajikan berbagai macam platform penampil aplikasi yaitu Browser, Smartphone dan Ios.

gambar 5 2

2. Apabila tampilan device sudah muncul silahkan tambahkan keterangan di bagian atas dengan cara memilih menu text dan pilih label.

3. Setelah anda membuat keterangan login, langkah berikutnya membuat form username dan password dengan cara pilih bagian menu Form dan pilih text input.

4. Setelah form username dan kata sandi berhasil dibuat, langkah selanjutnya membuat tombol masuk dengan cara tetap pada menu form dan pilih button.

5. Bila prototipe berhasil dibuat, silahkan periksa dan jalankan hasil karya anda dengan menekan tombol play di bagian kanan atas aplikasi.

gambar 5 3

7. Setelah prototipe dirasa sudah baik ,silahkan export hasil nya ke bentuk PDF, dengan cara memilih menu project dan pilih export to PDF. Tutorial diatas merupakan salah satu pembuatan design prototipe login.

ANALISIS SYSTEM

BAB IV
ANALISIS SYSTEM

4.1 Defenisi analisis system

Analisis Sistem adalah penjelasan dari suatu sistem yang lengkap ke beragam bentuk elemennya dengan tujuan supaya bisa mengenali dan menilai beragam persoalan atau gangguan yang timbul pada sistem sehingga mendatangnya bisa dilakukan pencegahan, pemulihan dan peningkatan.

4.2 Teknik pengumpulan data

Ada 3 yaitu teknik :

a. Teknik Wawancara

b. Teknik Observasi

c. Teknik Kuisioner

1. TEKNIK WAWANCARA

Pegumpulan data dengan menggunakan wawancara lebih mudah yaitu :

· mudah dalam menggali bagian mana yang dianggap baik dan kurang baik

· Jika ada bagian perlu untuk digali lebih dalam,kita dapat langsung bertanya ke user

· Dapat mengetahui kebutuhan user secara lebih jelas

· User dapat menjelaskan kebutuhannya secara detail.

Namun ada kekurangan dalam menggunakan teknik wawancara :

· Wawancara sulit jika user kurang jelas menyebutkan kebutuhan nya

2. TEKNIK OBSERVASI

Pengumpulan data dengan menggunakan observasi lebih mudah yaitu :

· Analis dapat melihat langsung sistem lama berjalan.

· Mampu menghasilkan gambaran lebih baik.

Namun ada kekurangan dalam menggunakan teknik observasi yaitu :

· Butuh waktu lama karena jika observasi waktunya sangat terbatas

· Dapat mengganggu pekerjaan orang-orang pada bagian yang sedang diamati.

3. TEKNIK KUISIONER

Pengumpulan data dengan menggunakan kuisioner lebih mudah yaitu :

· Hasilnya lebih objektif ( kuisioner dapat dilakukan kepada orang banyak )

· Waktunya lebih singkat.

Namun ada kekurangan dalam menggunakan teknik kuisioner yaitu :

· Responden cenderung malas untuk mengisi kuisioner.

· Sulit untuk membuat pertanyaan yang singkat,jelas dan mudah dipahami.

4.3 Jenis kebutuhan

Kebutuhan yang dikumpulkan dengan menggunakan ketiga metode di atas dapat dikelompokkan menjadi beberapa kategori sebagai berikut :

1. Functional Requirement : kebutuhan yang terkait fungsi produk (system mampu mencetak laporan,menampilkan grafik dan lain-lain).

2. Performance Requirement : kebutuhan terkait kualitas dan kuantitas (skalabilitas, kecepatan, dan kapasitas).

3. Development Requirement : kebutuhan yang terkait tools untuk pengembangan sistem informasi baik software maupun hardware.

4. Deployment Requirement : kebutuhan terkait lingkungan dimana sistem akan digunakan baik perangkat software maupun hardware.

5. Support Requirement : kebutuhan yang terkait dukungan yang diberi sesudah sistem informasi digunakan.

6. Documentation Requirement : kebutuhan ini terkait dokumen apapun yang akan disertakan pada produk akhir.

7. Miscellaneous Requirement : kebutuhan tambahan lainnya yang tidak tercakup pada kategori kebutuhan lainnya

SOFTWARE REQUIREMENT SPESIFICATION ( SRS )

BAB III
SOFTWARE REQUIREMENT SPESIFICATION ( SRS )

3.1 Pengertian Software Requirements Specification (SRS)

Srs adalah suatu dokumen yang menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Pada dasarnya SRS adalah suatu dokumen yang menyatakan kebutuhan perangkat lunak sebagai hasil dari proses analisis yang dilakukan dalam konteks pengembangan perangkat lunak. Dokumen ini dibuat oleh developer (pembuat software) setelah menggali informasi dari calon pemakai software. Pembuatannya pun seharusnya mengikuti standar yang ada dan paling diakui oleh para praktisi rekayasa software di dunia. Oleh karena itu, standar yang akan dibahas di sini adalah standar dari IEEE. Dokumen ini dibuat untuk membantu membuat spesifikasi perangkat lunak yang akan dikembangkan. Isi dari dokumen ini sebagian besar adalah terjemahan dari dokumen IEEE Std 830-1993.

IEEE membuat standar SRS agar dokumen penting itu tidak ambigu dan tentu saja komplit. Dengan standar itu, user dapat mencurahkan semua keinginannya Istilah-istilah tersebut adalah:

· Kontrak: dokumen yang mengikat secara hukum dan disepakati oleh customer dan supplier, termasuk syarat-syarat teknologi dan organisasi, biaya, serta jadwal pengerjaan. Kontrak bisa mengandung sesuatu yang kurang formal tetapi bermanfaat, seperti komitmen atau harapan dari pihak yang terlibat.

· Customer (pelanggan) : Pihak yang membayar untuk produk dan biasanya yang menentukan persyaratan (requirements).

· Supplier (pemasok): Pihak yang membuat produk software untuk customer.

· Pengguna: Pihak yang mengoperasikan atau berinteraksi langsung dengan software. Pengguna dan customer biasanya bukan orang yang sama.

3.2 Manfaat SRS

Manfaatnya yaitu :

1. Sebagai bentuk perjanjian antara customer dan supplier tentang software apa yang akan dibuat.

2. Mengurangi beban dalam proses pengembangan software.

3. Sebagai bahan perkiraan biaya dan rencana penjadwalan.

4. Sebagai dasar validasi dan verifikasi software di ujung penyelesaian proyek nantinya.

5. Memfasilitasi transfer, semisal software tersebut ingin ditransfer ke pengguna atau mesin-mesin yang lain. Customer pun merasa mudah jika ingin mentransfer software ke bagian-bagian lain dalam organisasinya. Bahkan, jika terjadi pergantian personil developer, proyek dapat mudah ditransfer ke personil baru dengan memahami SRS ini.

6. Mendasari perbaikan produk software di kemudian hari. Jadi, kadang SRS boleh diperbaiki dengan alasan dan mekanisme tertentu serta atas kesepakatan antara customer dan developer.

3. Hal yang perlu dipertimbangkan dalam menyusun SRS :

Sifat SRS :

a. Fungsionalitas : Untuk apa suatu perangkat lunak dibuat.

b. Antar muka eksternal (External Interface) : Dengan apa perangkat lunak berinteraksi dengan user, system hardware, perangkat keras di luar sistem dan perangkat lunak lain.

c. Performansi : Sejauh apa kecepatan, ketersediaan (availability), waktu tanggap (response time),waktu recovery dari berbagai fungsi perangkat lunak yang dibuat.

d. Atribut : Seberapa tingkat portabilitas, tingkat kebenaran (correctness), tingkatpemeliharaan (maintainability), dan tingkat keamanan yang ingin dicapai.

e. Batasan perancangan : Apakah diperlukan suatu standar, bahasa yang khusus, kebijaksanaan integritasbasisdata, batasan sumberdaya, lingkungan operasi, dan lain-lain yang membatasi pilihan-pilihan yang bisa digunakan atau keputusan-keputusan yang bisa diambilketika perancangan.

Lingkungan SRS :

Mengingat SKPL pada akhirnya akan menjadi dasar bagi kontrak antara developer dan customer , maka suatu dokumen SKPL harus memenui syarat-syarat berikut:

Mendefinisikan kebutuhan software dengan benar. Kebutuhan software muncul karena ada pekerjaan yang harus diselesaikan atau karena ada karakteristik khusus dari proyek.

Tidak menjelaskan rancangan atau implementasi dengan rinci. Penjelasan tersebut tidak diperlukan karena bagi pengguna hal tersebut lebih teknis dan tidak perlu.

Tidak memaksakan penambahan suatu batasan dari perangkat lunak

Karakteristik dari SRS yang baik, yaitu:

· Correct (benar)

· Unambiguous (tidak ambigu, tapi jelas)

· Complete (lengkap)

· Consistent (konsisten)

· Ranked for importance and/or stability (prioritas penting dan atau stabilitas)

· Verifiable (dapat diverifikasi)

· Modifiable (bisa dimodifikasi)

· Traceable (bisa dilacak

yenni