Kamis, 11 Oktober 2012

SRS Aplikasi Pembayaran (bagian 2)

Tulisan ini adalah lanjutan dari bagian ini:


III.4 Behavioral Models : Sequence Diagram

Sequence Diagram digunakan untuk menggambarkan kebiasaan/behavior suatu aplikasi. Selain itu, secara spesifik suatu Sequence Diagram menggambarkan sebuah skenario yang spesifik. Diagram ini menampilkan sejumlah objek dan pesan yang dilewatkan di dalam seuah Use-Case.

Tujuan pembuatan Sequence Diagram, yaitu :
1. menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu.
2. Menggambarkan skenario atau reangkaian langkah-langkah yang dilakukan sebagai respon dari sebuah event untuk menghasilkan output tertentu.





















III.5 Flow Models : Data Flow Diagram

Data Flow Diagram (DFD) merupakan suatu alat yang membantu seorang analis untuk menggambarkan interaksi antara proses dan data. Selain itu, DFD juga menggambarkan dimana data akan digunakan (diambil dari data storeage) dan data akan disimpan.
Sebuah DFD merupakan representasi grafis yang menggambarkan aliran informasi dan perubahan yang terjadi sehingga data berubah dari masukan menjadi keluaran. Data Flow Diagram digunakan untuk menggambarkan sebuah sistem atau perangkat lunak pada berbagai tingkatan abstraksi.





III.6 Activity Diagram

Activity diagram membantu seorang analis untuk memodelkan interaksi antara User dan Customer. Sehingga memudahkan Pengembang untuk menentukan proses yang terjadi di dalam suatu proses.













III.7 Entity Relationship Diagram

Entity Relationship Diagram (ERD) awalnya ditujukan sebagai model database relasional. Namun, penggunaan saat ini telah berkembang lebih dari itu.Di dalam ERD terdapat beberapa komponen utama, yaitu : obyek data, atribut, relasi, dan beberapa penentu tipe. Tujuan Utama ERD adalah untuk merepresentasikan obyek data dan relasi-relasinya.

Pemodelan data logika dikembangkan dalam empat tahapan, sebagai berikut :
1. Model Data Konteks
Model data ini digunakan untuk menentukan lingkup proyek yang tidak terlalu detail dalam membahas entitas dan aturan bisnis.
2. Model Data Key-Based
Model data untuk mengidentifikasikan setiap entitas dengan menambahkan entitas asiosiatif dan menyertakan primary key
3. Model Data Fully-Attributed
Model Data yang menyertakan semua atribut deskriptif secara menyeluruh
4. Model Data Ternormalisasi
Model data yang telah melalui proses normalisasi.
Normalisasi adalah sebuah teknik pengorganisasian data ke dalam tabel-tabel untuk memenuhi kebutuhan pengguna. Tujuannya untuk menhilangkan kerangkapan data, mengurangi kompleksitas data dan mempermudah modifikasi data.


SRS Aplikasi Pembayaran


Berikut ini saya berikan contoh tentang Pembuatan Dokumen SRS. Dokumen ini awalnya dikerjakan oleh Kelompok 5 Mata Kuliah RPL, angkatan 2009 Prodi Teknik Elektro Unsrat.

Bab Analisa Kebutuhan.
Analisa Kebutuhan merupakan sebuah tugas atau pekerjaan di dalam ilmu Rekayasa Perangkat Lunak yang menjembatani antara system-level requirement engineering dan software design.
Suatu proses Rekayasa Kebutuhan (Requirement Engineering) akan menghasilkan spesifikasi Perangkat Lunak (mulai dari fungsi/function, data, dan kebiasaan/behavior), mengidentifikasikan antarmuka antara Aplikasi dan elemen sistem lainnya, dan menentukan standarisasi yang harus dipenuhi oleh Perangkat Lunak.
Requirement Analysis mengijinkan Software Engineer/Analyst untuk memperbaiki spesifikasi software dan membuat model dari spesifikasi tersebut. Proses ini memberikan suatu hasil kepada Software Designer, berupa representasi informasi, fungsi, dan kelakuan yang bisa di terjemahkan menjadi data, arsitektur, antarmuka, dan rancangan component.
Dan akhirnya, spesifikasi kebutuhan akan memberikan pengertian kepada pengembang dan pengguna untuk membuat suatu aplikasi yang berkualitas.

II.1 Kebutuhan fungsional dan non fungsional

Kebutuhan fungsional menggambarkan kemampuan utama suatu aplikasi. Seorang Software Engineer akan menentukan fungsi-fungsi utama yang harus ada di dalam aplikasi, dimana fungsi-fungsi tersebut didapatkan dari proses Requirement Gathering yang dilakukan seorang Software Engineer terhadap User/Stakeholders.
Dari fungsi-fungsi utama tersebut, akan diperluas lagi menjadi  fungsi-fungsi yang lebih spesifik melakukan suatu pekerjaan. Pada akhirnya, fungsi-fungsi ini akan menjadi fitur ari aplikasi tersebut.
Kebutuhan Non-Fungsional adalah kebutuhan yang harus dipenuhi agar suatu Perangkat Lunak bisa dijalankan. Kebutuhan ini bukan merupakan fungsi utama, namun akan menentukan kualitas dari suatu Perangkat Lunak.

Kebutuhan Non-Fungsional Aplikasi Pembayaran ( Kasir )
1. Requirement Operasional
1.1 System bisaberjalan di semua platform yang menggunakan JVM
1.2 System bisamembuat Document HTML dan Word
2. Security Requirements
System menggunakan user Authentification untuk mencegah orang-orang yang tidakberhak

Kebutuhan Fungsional Aplikasi Pembayaran ( Kasir )
1. User melakukan LOGIN kedalam System
1.1 User bisa login sebagai admin
1.2 User bisa login sebagai user biasa
2. System bisamenghitungpembayaran
2.1 System bisamencari data berdasarkan ID barang
2.2 System bisamenghitung total pembayaranpelanggan
2.3 System bisamenghitungpembayarandankembalianpelanggan
3. bisamencetakstrukpembayaranpelanggan
4. bisamembuatlaporan (Admin only)
4.1 System bisamembuatlaporanharian
4.2 System bisamembuatlaporanmingguan
4.3 System bisamembuatlaporanbulanan
5. bisa me-manage inventory barang (Admin only)
5.1 System bisamenambah data baru
5.2 System bisamengedit data lama
5.3 System bisamenghapus data
System bisa menambah dan mengurangi jumlah barang


Bab Pemodelan Kebutuhan
Setelah melakukan Analisa kebutuhan dan mendapatkan kebutuhan-kebutuhan Perangkat Lunak baik dalam hal Data, Fungsi, dan Kebiasaan. Maka, kebutuhan-kebutuhan itu perlu dimodelkan, agar mudah dipahami oleh Pengembang dan Pengguna Aplikasi.

Apa itu Pemodelan Kebutuhan?

"Tulisan merupakan sebuah alat yang hebat untuk berkomunikasi, tetapi bukan cara yang tepat untuk merepresentasikan kebutuhan suatu Perangkat Lunak komputer.Pemodelan Analisis menggunakan kombinasi antara teks dan bentuk-bentuk diagram untuk menggambarkan suatu kebutuhan data, fungsi, dan kebiasaan dengan cara yang relatif mudah dimengerti, dan yang lebih penting, berusaha untuk memastikan kebenaran, kesempurnaan, dan konsistensi.”

Cara-cara membuat Pemodelan Analisis :
Data, fungsi, dan kebiasaan digambarkan dalam beberapa diagram yang berbeda. Model Data mendefinisikan object, atribut, dan hubungan. Model Fungsional mengindikasikan bagaimana data berubah di dalam sistem. Model kebiasaan menggambarkan akibat dari suatu kejadian

Pada dasarnya terdapat 4 model utama untuk menggambarkan suatu kebutuhan Aplikasi, yaitu :
Model berbasis Skenario (contohnya Use-Case dan User Stories)
Modela Kelas (contohnya Class Diagram dan Collaboration Diagram)
Model Data (contohnya Data Flow Diagram dan Entity Relationship Diagram)
Model Perilaku (contohnya State Diagram dan Sequence Diagram)

III.1 Functional Decomposition Diagram

Sebelum memulai Pemodelan Analisis, diawali dulu dengan menentukan fitur-fitur Aplikasi yang akan dibangun. Functional Decompotition Diagram (FDD) adalah sebuah tool yang bisa membantu analis untuk mendefinisikan proses bisnis dimulai dari kegiatan utama dan dilanjutkan dengan kegiatan yang lebih detail atau spesifik.
Pada prinsipnya, dengan membuat FDD, stakeholders dan analis bisa menemukan dambaran umum dari setiap fungsi-fungsi kerja (dari sudut pandang organisasi) dan dapat menempatkan dengan tepat, pada bagian apa dari fungsi-fungsi kerja yang ada, perangkat lunak akan dibangun. Ini disebut model konteks perangkat lunak.
Di dalam FDD, digambarkan semua kemampuan sistem secara umum dan secara spesifik.



III.2 Scenarion Based Models : Use-Case Diagram

Use-Case dibuat untuk menentukan elemen apa yang terdapat di luar sistem dan yang akan berinteraksi dengan sistem, dalam bentuk kegiatan atau aktivitas tertentu.



III.3 Class Models : Class Diagram

Class Diagram bukan hanya merupakan diagram yang paling banyak digunakan, tetapi juga merupakan diagram yang mempunyai jangkauan terbesar dalam Konsep Pemodelan. Bukan hanya elemen dasar yang dibutuhkan setiap orang, bahkan konsep tingkat lanjut yang jarang digunakan.
Sebuah Class Diagram menggambarkan tipe-tipe ibjek di dalam sistem dan berbagai jenis hubungan yang terdapat dalam sistem itu. Class Diagram juga menampilkan properti dan operasi suatu kelas dan prasyarat yang dibutuhkan sebagai cara agar terhubung denga objek-objek;

Tujuan pembuatan Class Diagram adalah :
1. menggambarkan keadaan(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut(fungsi/method).
2. Menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan , asosiasi, dan lain-lain.



Minggu, 07 Oktober 2012

Membangun Model Spesifikasi Software

Apa yang dimaksud dengan Membangun Model Spesifikasi Software?

Kita tahu bersama, setelah tim pengembang dan stakeholders selesai melakukan elisitasi dan pendefinisian persyaratan perangkat lunak, maka langkah selanjutnya adalah membangun model spesifikasi perangkat lunak. Model spesifikasi perangkat lunak, merupakan "gambaran" awal dari setiap kebutuhan fungsional (dan non fungsional) yang akan dikembangkan, sebagai fungsi (atau fitur) perangkat lunak tersebut.

Proses membangun model spesifikasi perangkat lunak, tidaklah sulit, namun memerlukan fokus perhatian yang extra dari tim pengembang. Aktivitas ini merupakan tugas system analyst, dengan tujuan, membangun model sistem perangkat lunak dgn "bahasa" yang dapat dipahami oleh tim pengembang dan, tentu saja stajeholders. Membahasakan sistem perangkat lunak dalam "bahasa" teknis, namun harus dapat dipahami oleh stakeholders adalah tantangan terbesar yang harus dihadapi oleh system analyst.

Biasanya, setelah daftar kebutuhan perangkat lunak, disepakati oleh stakeholders dan tim pengembang, maka system analyst akan segera membuat apa yang disebut requirements model. Inilah yang disebut representasi teknis dari sistem perangkat lunak yang akan dibangun. Proses pemodelan teknis dari requirements software ini, akan menggunakan teks dan diagram.

Aturan-aturan pemodelan spesifikasi teknis, ditulis oleh DeMarco, hingga kini masih digunakan dalam disiplin rekayasa perangkat lunak modern. Alan Davis mengatakan bahwa: ... Suatu pandangan kebutuhan dari sudut pandang tertentu tidak memadai untuk memahami atau mendeskripsikan perilaku yang dikehendaki dari suatu sistem yang kompleks ..., atas dasar pertimbangan DeMarco dan Alan Davis tersebut, maka disiplin pemodelan spesifikasi sistem perangkat lunak, dibedakan menjadi beberapa sudut pandang, yakni:
1). Model berbasis Skenario (scenario-based); model ini merupakan model perangkat lunak, dari sudut pandang user atau pengguna;
2). Model Data; yakni merupakan model yang menjelaskan bagaimana data ditransformasikan dalam sistem perangkat lunak yang akan dikembangkan;
3). Model Kelas (class-oriented); yakni merupakan model yang mendefinisikan objects, attributes serta relasi antar kelas yang ada;
4). Model berorientasi aliran (flow-oriented); adalah model yang menjelaskan bagaimana hubungan antara elemen fungsional dan data berinteraksi; bagaimana data dikelola, saat melintasi sistem perangkat lunak;
5). Model Perilaku (behavioral); yakni menggambarkan bagaiman sistem perangkat lunak "berperilaku" terhadap event-event yang datang dari luar sistem.

Jadi, banyak "model" bukan untuk membingungkan tim pengembang terlebih stakeholders. Justru dengan memandang sistem perangkat lunak dari "berbagai" perspektif, maka tim pengembang dan stakeholders akan semakin "memahami" perangkat lunak yang akan dikembangkan. Singkatnya, model membantu "proses pendefinisian" perangkat lunak.

Menurut Pressman, terdapat 3 tujuan dari tahap ini, yaitu:
1). untuk menjelaskan apa yang diinginkan oleh stakeholders;
2). untuk meletakkan dasar2 bagi tahap sottware design berikutnya;
3). untuk menajamkan sekumpulan requirements perangkat lunak, yang dapat divalidasi, saat akan membangun sistem perangkat lunak tersebut.




Requirements Software (again)

Sekali lagi, saya ingin menulis tentang Requirements Perangkat Lunak. Mengapa sekali lagi, karena sebenarnya sudah banyak tulisan saya tentang langkah-krusial ini. Silahkan melihat link URL dibawah ini untuk acuan tulisan-tulisan saya sebelumnya ....
1. Tentang memahami software requirements bisa dilihat di:
http://stanlysk.blogspot.com/2012/09/memahami-requirements-perangkat-lunak.html
dan disini:
http://stanlysk.blogspot.com/2012/07/requirements-engineering.html
2. Tentang Teknik QFD dalam pendefinisian Requirements Perangkat Lunak, dapat dilihat disini: 
http://stanlysk.blogspot.com/2012/10/qfd-dan-elisitasi-software-requirements.html

Semua tulisan diatas, sudah menjelaskan banyak mengenai pengertian, metode dan dokumentasi Persyaratan Perangkat Lunak.

Berikut ini, saya ingin memberikan sebuah kumpulan tautan lainnya, terkait metode pendefinisian perangkat lunak.
1. Tentang Pengertian Requirements Perangkat Lunak:
http://www.barbarabea.com/?page_id=134

2. Tentang menggunakan Excel dalam Melengkapi Pendefinisian Perangkat Lunak, bisa dilihat disini.: http://www.barbarabea.com/?page_id=11

Tulisan diatas, merupakan sebuah teknik yang sedikit berbeda, karena tidak menggunakan pendekatan buku teks, melainkan berfokus pada pendekatan praktisi. Namun demikian, pendekatan tersebut layak untuk dicoba, mengingat adanya kelemahan dalam bahasa notasi UML.

Sebuah slide prsentasi mengenati teknik pendefinisian perangkat lunak juga dapat ditemukan disini: http://www.barbarabea.com/wp-content/uploads/2011/07/Requirements%20Patterns%20Presentation%202011%20Public%20Domain.ppt

Demikian, kiranya dapat bermanfaat menambah khasanah pengetahuan dan kompetensi kita dalam mendefinisikan perangkat lunak!

Selasa, 02 Oktober 2012

Membuat Use Case dan Use Case Description 2

Berikut ini adalah sebuah teknik pembuatan Use Case Diagram pada studi kasus aplikasi berbasis Web 2.0. Langkah-langkah penentuan requirements, mengikuti pendekatan agile, yakni dimulai dengan pendefinisian masalah, kemudian dilanjutkan dengan pemodelan permasalahan. Persyaratan perangkat lunak, dikelompokkan dengan teknik QFD, dan menghasilkan persyaratan fungsional dan non fungsional.


1.1 Background
The using of internet by the government instituion and society rapidly grow. Internet user grows in number and services. North Sulawesi Local Government, especially the office of Investment Expert Staff seeing this phenomena as opportunity to promote exotic tourism. Using Web 2.0 technology to create competitive advantage as strategic and crusial considerations to foster investment climate for North Sulawesi tourism. Utilization of Web based 2.0 technology is expected to improve service, market share and shaping public opinion by providing targeted and comprehensive information on North Sulawesi exotic tourism, which is easily obtained by anyone, anywhere, anytime using any device.

1.2 Problems
Exotic tourism places owned by North Sulawesi Province is threatened by the onslaught of tourism promotions of some new netrants such as Wakatobi and Raja Amplat. While the number of foriegn tourist realtively declined over the 5 years before, the tourism potential of Bunaken National Park is not fully optimized by stakeholders. Lack of comprehensive information about Bunaken National Park is one of the resons for the decline of foreign tourist visiting. Structuring a comprehensive information related to the potential of tourism placesm tourism activities is one of a strategic solution that must be done to fix the pre-eminent tourism promotion. In addtion, the information must be displayed in such as interative user interface, constantly available for 24/7 and able to be found easily. Web Portal Amazing North Sulawesi is expected to be effective solution.

1.3 Functional Requirements
List of functional requirements are:
1). Viewing Info
1.1 The system can display information about the ads, profile, headline news, main headline news, North Sulawesi Profile and general articles.
1.2  The system can display links.
1.3  The system can displat visitor counter for each pages.
1.4 The system can display currency value and weather report.
2). Managing Info
2.1 Input ads, profile, news, headline, main headline and articles.
2.2 Edit ads, profile, news, headline, main headline and articles.
2.3 Delete ads, profile, news, headline, main headline and articles
2.4 Save ads, profile, news, headline, main headline and articles.
3). Collaborating
3.1 The system must provide facilities for  posting and reply comments for news, headline, main headline and articles.
3.2 The system must provide sharing and collaborating tools for social media, i.e: facebook, twitter dan G+.
3.3  The system musti provide polling feature.

1.4. Non-Functional Requirements
For non-functional requirements are distinguished in terms of operational, performance and security. Some non-functional terms to be met by the system are as follows:
Operational Requirements (the physical and technical systems that apply):
1) The system must be displayed in Indonesian and English
2) The system can be operated on a smartphone, desktop and notebook on the optimal display resolution.
3) The system must be able to work on all web browsers.
4) The System must running through the operating system Windows and Linux.
Performance Requirements (speed, capacity and reliability):
1) The system must be used or operated within 24 hours a day, 7 days a week and 356 days a year.
2) Each user interaction with the system should not be longer than 3 seconds.
Security Requirements
1) The system must provide privilege access for groups of admins and users.
2) The system must provide verification procedure for posting comments.

Gambar Use Case dan Use Case Description adalah sebagai berikut: