SOFTWARE REQUIREMENT SPESIFICATON (SRS)

A.Pengertian Software Requirement Spesification

Secara sederhana, Software Requirement Specifications (SRS) adalah dokumen yang menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Dokumen ini dibuat oleh developer (pembuat software) setelah menggali informasi dari calon pemakai software. 

Metode mendefinisikan SRS dijelaskan oleh IEEE ( Institute of Electrical and Electronic Engineer ) spesifikasi 830-1998. IEEE membuat standar SRS agar dokumen penting itu tidak ambigu dan tentu saja komplit. Lengkap. Dengan standar itu, si penggguna dapat mencurahkan semua keinginannya terkait software tersebut dengan jelas dan akurat sehingga sang developer pun dapat memahami apa yang diinginkan pengguna dengan tepat.

Tujuan Software Requirement Spesification

1.Memberikan umpan balik kepada pelanggan.

2.Masalah terurai menjadi beberapa bagian.

3.Berfungsi sebagai masukan untuk spesifikasi desain

4.Berfungsi sebagai dokumen induk untuk pengujian dan validasi strategi yang akan di terapakan pada persyaratan untuk verifikasi.

B.Karakteristik Mendasar dari Kualitas SRS

Karakteristik mendasar dari kualitas SRSawalnya dipresentasikan pada april 1998 Software Technology Conference presentation “Doing Requirements Right the Fisrt Time”. Dicetak ulang dengan izin dari Software Assurance Technology Center di NASA (http://www.gsfc.nasa.gov/) . karakteristik kualitas ini terkait erat dengan apa yang disebut sebagai “indikator kekuatan dan kelemahan” yang akan ditentukan selanjutnya.

Terimakasih

SDLC (System Development Life Cycle)

A.Pengertian SDLC (System Development Life Cycle)

SDLC atau siklus hidup pengembangan sistem adalah siklus yang digunakan dalam pembuatan atau pengembangan sistem informasi yang bertujuan untuk menyelesaikan masalah secara efektif. Dalam pengertian lain, SDLC adalah tahapan kerja yang bertujuan untuk menghasilkan sistem berkualitas tinggi yang sesuai dengan keinginan pelanggan atau tujuan dibuatnya sistem tersebut.

Terimakasih

REKAYASA PERANGKAT LUNAK

A.PENGERTIAN REKAYASA PERANGKAT LUNAK

Rekayasa perangkat lunak (software engineering) merupakan pembangunan dengan menggunakan prinsip atau konsep rekayasa dengan tujuan menghasilkan perangkat lunak yang bernilai ekonomi yang dipercaya dan bekerja secara efisien menggunakan mesin.

B.Mitos Perangkat Lunak

Ada beberapa bagian dari mitos software, antara lain:

• Mitos Managements

Mitos : Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu.

Realita : Walau hasil program sama, produktivitas dan kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments.

•  Mitos Langganan/Customer

Mitos : Kebutuhan proyek yang terus menerus berubah dapat dengan mudah di atasi karena software itu bersifat fleksibel.

Realita : Kenyataannya memang benar bahwa kebutuhan software berubah, tetapi dampak dari perubahan berbeda dari waktu ke waktu.

•  Mitos Praktisi

Mitos : Tidak ada metode untuk analisis desain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding.

Realita : Metode untuk analisis desain dan testing diperlukan dalam pengembangan software.

Terimakasih 

 

 

ENTITY RELATIONSHIP DIAGRAM (ERD)

A.Pengertian ERD (Entity Relationship Diagram)

ERD merupakan sebuah model untuk menjelaskan hubungan antar basis data berdasarkan objek-objek dasar data yang mempunyai hubungan antar relasi. ERD memodelkan struktur data dan hubungan antar data, untuk menggambarkan tersebut diperlukan beberapa notasi dan simbol.

Menurut Brady dan Loonam (2010), ERD merupakan teknik yang digunakan untuk memodelkan kebutuhan data dari suatu organisasi, biasanya oleh sistem analis dalam tahap analisis persyaratan proyek pengembangan sistem. Sementara seolah-olah teknik diagram atau alat peraga memberikan dasar untuk desain database relasional yang mendasari sistem informasi yang dikembangkan

Terimakasih

DATA FLOW DIAGRAM (DFD)

A.Definisi DFD (DATA FLOW DIAGRAM)

Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi. DFD ini sering disebut juga dengan nama Bubble chart, bubble diagram, model proses, diagram alur kerja, atau model fungsi.

• Bentuk Data Flow Diagram

Terdapat dua bentuk DFD, yaitu diagram alur data fisik, dan diagram alur data logika. Diagram alur data fisik lebih menekankan pada bagaimana proses dari sistem diterapkan, sedangkan diagram alur data logika lebih menekankan proses-proses apa yang terdapat di sistem.

1.  Diagram Alur Data Fisik (DADF)
2. Diagram Alur Data Logika (DADL)

 

Terimakasih

DESAIN SISTEM

Definisi desain sistem

Desain sistem dapat dibagi dalam dua bagian, yaitu desain sistem secara umum (general systems design) dan desain sistem terinci (detailed systems design) desain sistem secara umum disebut juga dengan desain secara makro (macro design). Desain sistem terinci disebut juga dengan desain sistem secara phisik (physical system design) atau desain internal (internal design).

• Tujuan Desain Sistem

Tahap desain sistem mempunyai dua maksud atau tujuan utama, yaitu sebagai berikut :

1.  Untuk memenuhi kebutuhan kepada pemakai sistem.
2. Untuk memberikan gambaran yang jelas dan rancang bangun yang lengkap kepada pemrogram komputer dan ahli-ahli teknik lainnya yang terlibat.

Tujuan kedua ini lebih condong kepada desain sistem yang terinci, yaitu pembuatan rancang bangun yang jelas dan lengkap untuk nantinya digunakan untuk pembuatan program komputer.

Untuk mencapai tujuan tersebut, analisis sistem harus dapat mencapai sasaran-sasaran sebagai berikut :

1. Desain sistem harus berguna, mudah dipahami dan nantinya mudah digunakan. Ini berarti bahwa data harus mudah ditangkap, metode-metode harus mudah diterapkan dan informasi harus mudah dihasilkan serta mudah dipahami dan digunakan. 
2.  Desain sistem harus dapat mendukung tujuan utama perusahaan sesuai dengan yang didefinisikan pada tahap perencanaan sistem yang dilanjutkan pada tahap analisis sistem.
3. Desain sistem harus efisien dan efektif untuk dapat mendukung pengolahan transaksi, pelaporan manajemen dan mendukung keputusan yang akan dilakukan oleh manajemen, termasuk tugas-tugas yang lainnya 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.

• DESAIN SISTEM SECARA UMUM

Tujuan dari desain sistem secara umum adalah untuk memberikan gambaran secara umum kepada user tentang sistem yang baru. Desain sistem secara umum merupakan persiapan dari desain terinci. Desain secara umum mengidentifikasikan komponen-komponen sistem informasi yang akan didesain secara rinci. Desain terinci dimaksudkan untuk pemrogram komputer dan ahli teknik lainnya yang akan mengimplementasi sistem. Tahap desain sistem secara umum dilakukan setelah tahap analisis sistem selesai dilakukan dan hasil analisis disetujui oleh manajemen.

 

 Terimakasih

ANALISIS SISTEM

A.DEFINISI ANALISIS SISTEM

Analisis sistem adalah penguraian dari suatu sistem informasi yang utuh ke dalam bagian-bagian komponennya dengan maksud untuk mengidentifikasikan dan mengevaluasi permasalahan-permasalahan, kesempatan-kesempatan, hambatan-hambatan yang terjadi dan kebutuhan-kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan-perbaikannya.

Atau secara lebih mudahnya, analisis sistem adalah penelitian atas sistem yang telah ada dengan tujuan untuk merancang sistem yang baru atau diperbarui. Tahap analisis sistem ini merupakan tahap yang sangat kritis dan sangat penting, karena kesalahan di dalam tahap ini akan menyebabkan juga kesalahan di tahap selanjutnya. Tugas utama analis sistem dalam tahap ini adalah menemukan kelemahan-kelemahan dari sistem yang berjalan sehingga dapat diusulkan perbaikannya.

• Teknik Wawancara

Berikut ini adalah beberapa panduan dalam melakukan kegiatan wawancara agar memperoleh data yang diharapkan :

1.  Buatlah jadwal wawancara dengan narasumber dan beritahukan maksud dan tujuan wawancara.
2. Buatlah panduan wawancara yang akan anda jadikan arahan agar pertanyaan dapat fokus kepada hal-hal yang dibutuhkan.
3. Gunakan pertanyaan jelas dan mudah dipahami.
4. Cobalah untuk menggali mengenai kelebihan dan kekurangan sistem yang telah berjalan sebelumnya.
6. Anda boleh berimprovisasi dengan mencoba menggali bagian-bagian tertentu yang menurut Anda penting.

• Teknik Observasi

Berikut ini adalah beberapa petunjuk untuk melakukan observasi yaitu sebagai berikut :

1.  Tentukan hal-hal apa saja yang akan diobservasi agar kegiatan observasi menghasilkan sesuai dengan yang diharapkan.
2. Mintalah izin kepada orang-orang yang berwenang pada bagian yang akan diobservasi.
3. Berusaha sedikit mungkin agar tidak menggangu pekerjaan orang lain.
4. Jika ada yang Anda tidak mengerti, cobalah bertanya. Jangan membuat asumsi sendiri.

 

• Teknik Kuisioner

 Berikut ini adalah beberapa cara yang dapat dilakukan untuk membuat kuisioner menghasilkan data yang baik yaitu sebagai berikut :

1.  Hindari pertanyaan isian, lebih baik pilihan ganda, karena responden biasanya malas untuk menulis.
2. banyak, dan jika reponden menuliskan sesuatu sering kali susah untuk dipahami.
3. Buatlah pertanyaan yang tidak terlalu banyak.
4. Buatlah pertanyaan singkat, padat, dan jelas.

Terimakasih