PROGRAM STUDI TEKNIK INFORMATIKA UNIVERSITAS WIDYATAMA
Rekayasa Perangkat
Lunak
Modul Praktikum
Laboratorium Software Engineering Agustus 2011Disusun oleh :
LEMBAR PENGESAHAN
REKAYASA PERANGKAT LUNAK
MODUL PRAKTIKUM
Disusun Oleh : Falahah
Telah disetujui dan disahkan untuk dijadikan bahan ajar di Jurusan Teknik Informatika
Bandung, Agustus 2011
Ka. Lab Software Engineering, Ka. Prodi. Teknik Informatika,
KATA PENGANTAR
Praktikum Rekayasa Perangkat Lunak akan menggunakan pendekatan terstruktur, dengan kemungkinan penggunaan CASE untuk alat bantu pemodelan. Mata praktikum ini merupakan bagian dari mata kuliah Rekayasa Perangkat Lunak dan dikelola oleh Laboratorium Software Engineering.
Pelaksanaan praktikum ini terjadwal dilaksanakan sesuai jadwal kuliah, dan untuk memudahkan pelaksanaan praktikum, laboratorium Software Engineering menyusun modul ini dengan harapan dapat memudahkan penyampaian materi praktikum, memudahkan menuntun mahasiswa dalam memahami tahapan teknik dan metoda penyelesaian masalah, serta mudah mengawasi keselarasan dan kesesuaian antara materi kuliah dengan praktikum. Dalam menyelesaikan masalah-masalah yang ada pada modul ini diharapkan mahasiswa tidak hanya bergantung pada modul ini, namun dapat mencari referensi lain.
Pada kesempatan ini tak lupa kami ucapkan terima kasih atas dukungan kepala laboratorium dan asisten laboratorium/praktikum yang telah banyak membantu dalam penyusunan modul praktikum ini.
Bandung, Agustus 2011
Penyusun
TEKNIS PELAKSANAAN PRAKTIKUM
Pelaksanaan praktikum Rekayasa Perangkat Lunakdimulai dengan tahap persiapan, pelaksanaan dan evaluasi sebagai berikut :
1. Peserta praktikum harus menyelesaikan Tugas Pendahuluan dan/atau Tugas Rumah serta Laporan Praktikum pada saat akan memulai modul baru. Tugas dibuat dalam bentuk laporan sebagai tugas individu dan/atau kelompok.
2. Laporan diserahkan kepada dosen/asisten dengan tertib sebelum praktikum dimulai.
3. Selama di ruang praktikum, praktikan harus mengikuti semua petunjuk/penjelasan yang diberikan instruktur/asisten dan mengerjakan semua Latihan Praktium. Bila sampai akhir pertemuan per praktikum masih terdapat soal latihan yang belum selesai dikerjakan, praktikan diharuskan menyelesaikan/mengerjakan soal tersebut di “rumah” dan dikumpulkan pada pertemuan berikutnya. Sebaliknya, apabila praktikan telah menyesaikan soal latihan praktikum sebelum waktunya habis, praktikan dapat melanjutkan latihan soal untuk pertemuan berikutnya.
4. Tugas Kelompok dan Tugas Besar dikerjakan dalam bentuk laporan (anggota kelompok maksimal 4 (empat) orang).
5. Praktikan harus mengerjakan/menyelesaikan semua soal yang terdapat dalam modul, baik tugas pendahuluan, latihan maupun tugas rumah.
6. Ujian praktikum dapat dilakukan di akhir praktikum (pertemuan kesebelas), apabila diperlukan.
7. Modul praktikum ini sebanyak 5 modul, dan maksimal dilaksanakan dalam empat belas kali pertemuan.
Halaman Depan (sampul), berisi informasi :
<Nama Modul>
<Nama Tugas>
<Tugas Ke-...>
Untuk memenuhi tugas Praktikum Rekayasa Perangkat Lunak Di Prodi. Teknik Informatika
Disusun oleh : <NIM> <Nama >
Laboratorium Software Engineering
Jurusan Teknik Informatika – Universitas Widyatama Bandung
2011
Asisten/Instruktur Halaman : n/m
Dimana <n : halaman ke-> dan <m : jumlah halaman>
Halaman Isi, terdiri dari :
Permasalahan/ Pendahuluan (Latar Belakang Masalah, Batasan Masalah, dst) Isi (Landasan Teori, Analisa, dst) dan/atau
Penyelesaian masalah (algoritma, print-out program, hasil running program, hasil analisa dst)
Kesimpulan
Catatan : Tugas diprint dengan tinta warna hitam, presentasi disajikan dalam bentuk file power point dan semua praktikan wajib menyerahkan soft copy semua laporan dan file presentasi.
PENILAIAN
Teknik penilaian praktikum Rekayasa Perangkat Lunak adalah sebagai berikut : 1. Setiap modul yang telah dilaksanakan oleh praktikan akan dinilai dengan angka
berskala 0 – 100, yang meliputi nilai : Tes Awal/Akhir (10%), dari skala 0-100
Tugas Rumah dan/atau Tugas Pendahuluan (20 %), dari skala 0 – 100 Laporan Praktikum (25 %), dari skala 0 – 100
Latihan-latihan (45 %), dari skala nilai 0-100
Ketiga nilai tersebut akan dijumlahkan , sebagai nilai per modul.
2. Nilai yang telah dihasilkan dari masing-masing modul akan dijumlahkan, kemudian hasil penjumlahan akan dibagikan dengan jumlah modul, sehingga mendapat nilai rata-rata.
3. Nilai akhir praktikum dapat diambil dari Rata-rata : Nilai rata-rata modul : 70 % s.d. 80 % Tugas Besar/Ujian : 20 % s.d. 30 %
Kehadiran : 10 %
4. Nilai akhir praktikum akan dimasukkan sebagai komponen nilai kuliah Rekayasa Perangkat Lunak.
DAFTAR ISI
KATA PENGANTAR ... 1
Daftar Table dan Gambar 7
1 RENCANA PENGEMBANGAN PERANGKAT LUNAK 8
1.1 TUJUAN ... 8
1.2 TEORI ... 8
1.2.1 Organisasi Tim dalam Proyek Pengembangan Perangkat Lunak ... 8
1.2.2 Tahapan Pengembangan Perangkat Lunak ... 9
1.2.3 Dokumen Rencana Pengembangan Perangkat Lunak (RPPL) ... 9
1.3 Latihan ... 17
1.4 Tugas Pendahuluan I (dikumpulkan pada pertemuan ke satu) ... 18
2 IDENTIFIKASI KEBUTUHAN DAN PEMODELAN PROSES 19
II.1 TUJUAN ... 19
II.2 TEORI ... 19
2.1.1 Flowchart ... 20
2.1.2 Data Flow Diagram ... 29
2.1.3 SPESIFIKASI PROSES ... 43
2.1.4 Kamus Data (Data Dictionary) ... 47
2.2 Dokumen yang Terlibat dalam Fase Analisa atau Spesifikasi ... 47
2.2.1 Pemodelan Data ... 48
2.2.2 SRS (Software Requirement Specification) ... 49
2.3 Latihan dan Tugas ... 51
3 PERANCANGAN PERANGKAT LUNAK 59
3.1 TUJUAN ... 59
3.2 TEORI ... 59
3.2.1 Structure Chart ... 61
3.2.2 Perancangan Antar Muka ... 74
4 PENGUJIAN 79
4.1 TUJUAN ... 79
4.2 TEORI ... 79
4.2.1 Black Box Testing ... 79
4.2.2 White Box Testing ... 84
4.3 Dokumen Pengujian (STP [Software Test Plan] dan STR [Software Test Result]) 90 4.4 Latihan (pertemuan 8 dan 9) ... 92
5 IMPLEMENTASI 93
5.1 TUJUAN ... 93
5.2 TEORI ... 93
5.3 Latihan : (Pertemuan ke sepuluh) ... 96
Daftar Table dan Gambar
Table 1-1 Kerangka Dokumen Rencana Pengembangan Perangkat Lunak (RPPL) ... 9
Table 2-1 CRUD Matrix ... 42
Table 2-2 Kerangka SRS ... 49
Table 4-1 Kerangka Dokumen Pengujian ... 90
Table 4-2 Contoh Software Test Plan (STP) ... 91
Table 4-3 Contoh Software Test Result (STR) ... 91
Table 5-1 Kerangka Dokumen Implementasi ... 93
Table 5-2 Tabel penjelasan struktur program ... 95
Gambar 2-1 Contoh Flowchart Sistem Helpdesk ... 20
Gambar 2-2 Simbol flowchart untuk Proses ...21
Gambar 2-3 Simbol flowchart untuk Data ...21
Gambar 2-4 Garis dan simbol-simbol khusus ... 22
Gambar 2-5 Diagram Proses Bisnis dalam Format BPMN ... 22
Gambar 2-6 Flowchart Penjualan Pulsa Elektronik ... 25
Gambar 2-7 Flowchart Existing System ... 26
Gambar 2-8 Flowchart yang Sudah Direvisi (1) ... 26
Gambar 2-9 Flowchart Hasil Penggabungan Proses Redundan ... 27
Gambar 2-10 Flowchart Hasil Penambahan Proses Baru ... 27
Gambar 2-11 Simbol DFD menurut Gane & Sarson ... 29
Gambar 2-12 Simbol DFD menurut Yourdon ... 30
Gambar 2-13 DFD Level 0, Order System ... 30
Gambar 2-14 Context Diagram ... 31
Gambar 2-15 Berbagai bentuk spesifikasi proses ... 43
Gambar 3-1 Simbol Dasar Structured chart ... 61
Gambar 3-2 Contoh DFD yang Mengandung Transaction Center ... 71
Gambar 3-3 Contoh Structure chart dengan Transaction Center ... 72
Gambar 5-1 Struktur Program Sistem Informasi Penggajian ... 95
Gambar 5-2 Contoh Form Input Password ... 96
1 R ENCANA PENGEMBANGAN PERANGKAT LUNAK
(1 kali pertemuan) 1.1 TUJUAN
Tujuan modul ini, adalah:
• Praktikan dapat membiasakan diri untuk menyusun Dokumen Rencana Pengembangan Perangkat Lunak (Proposal) secara terstruktur baik dalam satu tim maupun individu.
• Praktikan memahami organisasi tim dalam proyek pengembangan perangkat lunak
1.2 TEORI
1.2.1 Organisasi Tim dalam Proyek Pengembangan Perangkat Lunak
Sebuah perangkat lunak, tergantung ukuran dan ruang lingkupnya, dapat dikembangkan oleh satu orang atau beberapa orang yang tergabung dalam satu tim. Jika berupa tim, biasanya peranan setiap anggota tim dibagi-bagi berdasarkan fungsi-fungsi berikut :
1. Software Project Manager : pertama berhubungan dengan konsumen, menetapkan anggaran dan jadwal pelaksanaan proyek perangkat lunak.
2. Software Engineer
• Analyst : berhubungan dengan konsumen secara lebih rinci; bertugas mendeskripsikan/menggali fungsi dan unjuk kerja software yang akan dibangun.
• Designer : bertugas merancang algoritma/prosedur yang tepat untuk fungsi tersebut disesuaikan dengan hardware atau software pendukung yang ada.
• Programmer : mengimplementasikan algoritma dalam bentuk kode-kode sesuai dengan software yang ada.
3. Software Configuration Management : memantau fungsi-fungsi/prosedur-prosedur yang telah ditentukan, mencatat konfigurasi pada tahap-tahap/ waktu-waktu tertentu berdasarkan kenyataan yang ada.
4. System Administrator : bertugas melakukan pengelolaan terhadap sistem pada saat diimplementasikan.
5. Software Quality
• Software Quality Assurance: bertugas melakukan pengawasan apakah software yang dibangun telah berjalan sesuai dengan fungsi dan kebutuhannya.
1.2.2 Tahapan Pengembangan Perangkat Lunak
Pengembangan perangkat lunak perlu direncanakan dengan seksama, sesuai dengan pendekatan yang sudah dipilih, misalnya waterfall, RAD atau pendekatan lainnya. Semua tahapan tersebut perlu direncanakan dalam satu kerangka kerja yaitu Proyek Pengembangan Perangkat Lunak. Semua perencanaan dalam Proyek Pengembangan Perangkat Lunak ini mengacu pada kaidah-kaidah perancangan proyek pada umumnya yaitu :
1. Penyusunan Rencana yang meliputi rencana rincian kegiatan, sumber daya (baik sumber daya manusia maupun sumber daya lainnya), biaya, control, kendali mutu dan sebagainya.
2. Pelaksanaan dan monitoring 3. Evaluasi.
Semua rencana tersebut dituangkan dalam satu dokumen yaitu semacam proposal yang disebut sebagai Rencana Pengembangan Perangkat Lunak. Dalam beberapa kasus, rencana ini juga dijadikan dasar penentuan kontrak pekerjaan, sehingga sering disebut sebagai project charter.
1.2.3 Dokumen Rencana Pengembangan Perangkat Lunak (RPPL)
Pada umumnya sebelum melakukan pengembangan atau pembangunan suatu perangkat lunak, terlebih dahulu dibuat proposal proyek pengembangan atau pembangunan perangkat lunak tersebut. Hal ini bertujuan untuk memberikan gambaran secara ringkas mengenai perangkat lunak yang akan dikembangkan atau dibangun.
Format/kerangka dari dokumen Rencana Pengembangan Proyek adalah sebagai berikut :
Table 1-1 Kerangka Dokumen Rencana Pengembangan Perangkat Lunak (RPPL)
Kerangka Dokumen Keterangan
Abstraksi Abstraksi/Rangkuman dokumen (RPPL)
Daftar Isi Daftar Gambar Daftar Tabel
Daftar Isi, Daftar Gambar dan Daftar Tabel dalam Dokumen RPPL
1 Pendahuluan 1.1 Gambaran Umum
Proyek
Ringkasan dari latar belakang dan lingkup proyek (serta hubungannya dengan proyek lain bila ada)
1.3 Daftar Definisi dan
Singkatan Menjelaskan definisi dan singkatan dalam RPPL 1.4 Referensi Referensi/dokumen/bahan acuan yang digunakan 2 Organisasi Proyek
2.1. Struktur Organisasi Struktur organisasi tim pengembang dengan mengidentifikasi dan menggambarkan jalur komunikasi dan pertanggungjawaban tim
2.2. Otoritas, Hak dan Tanggung Jawab Anggota Tim
Otoritas, hak dan tanggung jawab tiap anggota tim 3 Proses Manajerial
3.1 Tujuan dan Prioritas
Manajemen Tujuan dan prioritas proyek pengembangan perangkat lunak 3.2 Asumsi,
Ketergantungan dan Kendala
Menjelaskan asumsi yang digunakan pada pelaksanaan proyek, kebergantungan pada hal yang eksternal dan kendala yang perlu dipertimbangkan
3.3 Batasan Pengembangan Proyek
Menjelaskan batasan pengembangan proyek 3.4 Dokumentasi
Perangkat Lunak Menjelaskan dokumen yang akan dilaporkan dan waktu penyerahan dokumen 3.5 Rencana Penugasan Berdasarkan struktur organisasi (poin 2.1), sebutkan
jumlah dan tipe/jenis personalia yang dibutuhkan, menyangkut :
• Keahlian • Saat mulai
• Cara memfungsikan (retaining) dan memberhentikan personalia
4 Proses Teknis Menjelaskan tentang rencana penggunaan : • Sistem Komputer (Hardware dan Software) • Metode pengembangan (pemodelan)
• Notasi, alat Bantu, teknik dan metode lain yang digunakan.
5 Paket Kerja dan Jadwal Menjelaskan :
• Paket kerja (menjelaskan tugas dari masing-masing anggota tim pada setiap tahap)
• Jadwal Pelaksanaan
Lampiran Berisi penjelasan tambahan pada laporan ini
Hingga saat ini, tidak ada format standar untuk Project Charter atau Rencana Pengembangan Perangkat Lunak. Elemen-elemen yang dilaporkan bervariasi tergantung pada jenis aplikasi, organisasi dan pihak yang terlibat. Contoh di atas menunjukkan beberapa hal yang sebaiknya ada pada sebuah Project Charter.
Berikut ini beberapa contoh isi dokumen rencana pengembangan perangkat lunak Contoh 1 : Mesin Jual Otomatis
Gambaran Umum Proyek
Sebuah perusahaan yang bergerak dibidang pemasaran produk makanan, minuman, rokok dan surat kabar, dalam rangka meningkatkan hasil penjualan dan mutu pelayanannya bermaksud untuk menggunakan Mesin Jual Otomatis (MJO) untuk melayani konsumen yang ingin membeli produk-produk yang dipasarkannya.
Mesin Jual Otomatis (MJO) tersebut memiliki panel kendali yang berfungsi sebagai interface antara konsumen dengan MJO. Pada panel kendali tersebut terdapat tombol yang berfungsi untuk memilih jenis produk yang akan dibeli dan tombol yang digunakan untuk memasukan jumlah produk yang dibeli, selain itu panel kendali ini mempunyai layar yang berfungsi untuk memberikan pesan-pesan yang berkaitan dengan penjualan produk yang dipasarkannya. Pada panel kendali ini juga terdapat fasilitas untuk memasukan koin dari konsumen.
Mesin ini mampu mendeteksi jumlah uang dan nilai uang yang dimasukan. Bila konsumen telah memasukan sejumlah koin tertentu, maka mesin akan menghitung nilai uang tersebut. Jika nilai uang tersebut cukup untuk membayar produk yang dipilih, maka mesin akan mengeluarkan produk yang diinginkan. Jika nilai koin yang dimasukan lebih dari nilai produk yang dipilih, maka mesin akan mengeluarkan koin kembaliannya. Sedangkan jika nilai koin tidak cukup maka mesin akan memberikan pesan bahwa uang yang dimasukan tidak cukup. Selain itu mesin juga akan memberikan pesan jika produk yang diinginkan habis, koin kembalian tidak cukup, dan penampung uang telah penuh.
Jenis koin yang dideteksi adalah uang dengan pecahan seribuan, lima ratusan dan seratusan. Tabel harga produk disimpan dalam file database yang menyimpan informasi tentang jenis produk, harga dari masing-masing produk serta stok dari masing-masing produk tersebut dan kapasitas penyimpanan uang.
1.3. Tujuan
Dokumen ini mendefinisikan aktifitas dan tanggung jawab dari perusahaan yang memberikan kontrak dan pihak pengembang
Klien dibagi menjadi dua komponen funsional utama dalam sistem yang dikembangkan yaitu sistem antar muka dan sistem intelegensia
1.4 Referensi
Untuk penanganan proyek ini digunakan acuan dokumen sebagai berikut: Software Engineering : A Practitioner’s Approach
- Yourdon, Edward, “Modern Structured Analysis”, Prentice Hall, 1989 - Davis, Allan M.,” Software Requirements : Analysis & Specification”,
Prentice Hall - … dan seterusnya
3.1 Tujuan dan Prioritas Manajemen
Membangun aplikasi MJO (Mesin Jual Otomatis) untuk memenuhi kebutuhan perusahaan dalam rangka meningkatkan hasil penjualan dan mutu pelayanannya terhadap konsumen.
3.2. Batasan Masalah
Mesin ini dibuat untuk melayani konsumen yang ingin membeli produk makanan, minuman, rokok dan surat kabar secara otomatis. Uang yang digunakan untuk melakukan transaksi pada mesin ini adalah uang koin dengan pecahan 100, 500 dan 1000.
Proyek ini meliputi pengembangan secara lengkap dari MJO meliputi spesifikasi, perancangan, implementasi serta pengujian dari sebagian produk MJO tersebut.
3.3 Dokumentasi Perangkat Lunak
Proyek ini harus menyerahkan dokumen-dokumen sebagai berikut : Dokumen Analisa (SRS)
Dokumen Perancangan (SDD) Dokumen Implementasi
Dokumen Pengujian (STP dan STR) Software Aplikasi dan Code Program 3.4 Rencana Penugasan
Proyek ini dikerjakan oleh tim pengembang yang terdiri dari : Software Project Manager : Amir
Software Analyst : Budi Eni Software Designer : Cici Amir Software Quality Assurance : Deny Software Developer : Eni
Deny
4. Paket Kerja dan Jadwal Pelaksanaan
Proyek ini dilaksanakan selama praktikum RPL, review dan tanggal penyerahan akan diatur sesuai dengan persetujuan project manager.
1 2 3 4 5 6 7 8 9 10 11 12 1 Persiapan 2 Analisa 3 Perancangan 4 Implementasi 5 Pengujian
Berikut ini contoh Project Charter yang diambil dari situs saic.ncifcrf.gov/projectmanagement/pm/docs/ProjectCharterExample.doc
Project Name: LMT/PEL LIMS Deployment Project Prepared by John Doe and Mary Smith
Date: 8/22/06
Initialization
LABORATORY INFORMATION MANAGEMENT SYSTEMS (LIMS) DEPLOYMENT
February 6, 2006 (Supersedes the December 15, 2005 general LIMS Deployment Charter) Operating Group Task #95: Provide Plan for LIMS deployment at Facility A and funding plan.
Project Manager: John Doe, CIO
Project Administrator: Mary Smith, Project Management Office
Synopsis: Laboratory Information Management Systems (LIMS) are information management systems designed to track, organize, store and report on laboratory-generate data and analytical results. In addition, when used in core laboratories, the LIMS provides a portal for generating accounting reports and the systematic distribution of resulting data back to the requesting scientists and collaborators. LIMS can operate in both highly regulated and non-regulated environments. LIMS can meet all Good Laboratory Practice (GLP) requirements by providing full sample tracking, user certification, instrument and calibration management, standards & reagents management, full auditing, CFR21 Part 11, report and sample scheduling, bar coding, on-line help, and other functions. By eliminating several common sources of human error and by connecting directly to the laboratory-based instrumentation, LIMS improve laboratory efficiency. A full-featured LIMS will manage various laboratory data types including sample log-in, reporting analytical results, billing, and other related operations.
Purpose/
Business Need: As a result of the increased use of various high throughput technologies in virtually all areas of biological research, sophisticated software is needed to help research and diagnostic laboratories manage, analyze, and organize complex data. In addition, core technology facilities must be able to manage and distribute the data back to collaborating scientists in a controlled and secure manner. They must also have billing, tracking, and other capabilities to perform administrative functions efficiently. A well-designed LIMS can provide the solution to all of these production requirements.
Acceptance: The scope of the LMT component of the project includes a tested, documented, and functional LIMS no longer dependent on the Finch system. Enhancements will be developed separately and not be included in this project. Once the basic functionality has been documented and approved by the LMT, its users, the Customer, the Informatics Group, and the Project Manager, changes will not be made to the scope without the written approval of the LMT head and the Informatics Group Project Manager.
PEL
An initial needs assessment of the PEL lab and user-base will establish the basic functionality of the LIMS for this project. Enhancements will be developed separately and not be included in this project. Once the basic functionality has been documented and approved by the PEL, its users, the Customer, the Informatics Group, and the Project Manager, changes will not be made to the scope without the written approval of the PEL head and the Informatics Group Project Manager.
Standard development process utilized in the LIMS project:
1) Informatics Group LIMS developer will collect user requirements and document it as requirement description for user review.
2) Informatics Group LIMS developer will write the corresponding use cases to cover requirements.
3) Informatics Group LIMS developer will have system architecture design for user review.
4) Informatics Group LIMS developer will write detailed design document for major components/classes.
5) During the software development phase, unit testing, regression testing and system integration testing are required.
6) During the software quality assurance phase, QA testing and user acceptance testing will be required.
7) Final user acceptance testing will be given prior to the final production release.
Product
Description and Deliverables:
The LIMs to be deployed in the support laboratories will provide various functions for the designated recipient laboratories. Additionally, the LIMs described in this document will be deployed in various stages that each will represent a milestone. The Project Management Plan includes a Work Breakdown Structure and timeline for the achievement of those milestones (each with significant improvements and/or additional capabilities). This approach is designed to provide an immediate benefit to the recipient laboratories and demonstrate robust core functionalities which will then be extended in the subsequent versions of the software. LMT LIMS
Phase I: Data Analysis
Phase II: Barcode Inventory Tracking System Phase III: Reporting System
Phase IV: System Consolidation PEL LIMS
Phase I: Needs Analysis
Phase III: Implementation and testing
Phase IV: System Consolidation, Documentation, Training; Production Release
Project
Management: Project Management processes according to the standards and methodology set forth in the Project Management Institutes' Body of Knowledge will be used to manage the deployment of the LIMS project. The Project Management Plan (PMP) will include the following elements:
Project Charter
Description of the Project Management (PM) approach Scope statement
Work Breakdown Structure
Cost estimates, start and finish dates, roles and responsibilities Performance measurements baselines for scope, schedule, and cost
Major milestones and target dates for each Resources, effort, and related costs Risk Management Plan
Quality Management Plan
Communications Management Plan
The project management plan is a living document that will be updated by the Project Manager and Project Management Administrator as required. The plan will be executed and overall project performance evaluated on a regular basis to provide confidence that quality standards are being met in each laboratory module of the LIMS. The project team will be developed to maximize skills and competencies to enhance project performance. Information will be disseminated to project stakeholders on a schedule outlined in the Communications Plan. Assumptions,
Constraints, Risks:
High level project risks and constraints include, but are not limited to ● Funding availability—To date 78% of the total dollars for LIMS
development at the Facility has been supported by Company A, Inc. Maintenance, updates, refinements, and continued deployment of the LIMS now necessitate support through the Customer’s contract. While there is agreement on the basic necessity for continued deployment of LIMS, funding for this and future LIMS development has currently not been identified.
● Availability of Skilled Resources—The proposed human resource requirements for the LMT-PEL LIMS development, caBIG compliance modification, and ongoing systems maintenance includes a LIMS Integrator, LIMS Programmer, and LIMS HelpDesk support. These are the minimal resource requirements to support the scope of this project within the schedule identified in the PMP.
● Laboratory Commitments—Accurate identification of LIMS requirements, interpretation, testing, and design depend on the patience
● Current industry standards for LIMS—caBIG compliance standards are subject to change; new LIMS standards may evolve.
● Laboratory Requirement Changes—Congressional appropriations can affect the mission, scope, and management of Government laboratories at any time, thus also affecting LIMS requirements at any time during the development process.
A detailed Risk Assessment is included in the PMP.
Resources:
Project Resources: Human Resources:
1 Project Manager (project duration)—plan, manage, control project (25%)
1 Project Administrator (project duration)—facilitate project planning, execution, and communication (30%)
1 (+) IT Developer per laboratory—design and develop LIMS according to individual lab specifications (100%)
1 IT Developer—assist in design and development (100%)
1 IT Support staff (ongoing)—support installed LIMS product (training, helpdesk, system maintenance) (100%)
Material and Services Resources: Equipment: Hardware, Software Financial Resources:
Labor: $********
Equipment: Hardware, Software: $3,000 Travel: $10,000 (LIMS Meetings)
Communica-tion and
Reporting: Communication will follow the Communications Plan outlined in the PMP. Stakeholders include Customer Management, Company A, Inc., Management, the LIMS Deployment Project Team, LMT & PEL laboratory staff, and LMT & PEL users.
Status reports will be submitted to Customer Management through the OG representative monthly.
Company A, Inc., Management will be updated weekly for the Customer/Contractor meeting.
Communications among the Project Team members will be weekly initially, and as needed as the project progresses.
LMT & PEL laboratory staff will be apprised as participants in the process.
LMT & PEL users will be apprised informally throughout the process by the respective LMT & PEL program spokespersons for their projects.
The Project Manager will be the communication focal point with the Group A until the transition of the LMT LIMS is complete to Group B.
All change requests will be documented, submitted to, and assessed by the Project Manager (PM) and Team Lead for impact and project necessity prior to PM approval. If change is approved, the project schedule, scope, and budget will be updated accordingly and
communicated to appropriate stakeholders in accordance with the Communications Plan. The PM/project team will communicate the approved change and updated schedule to the staff responsible for implementing the change.
Project Team: PROJECT TEAM ROLES AND RESPONSIBILITIES
John Doe: Project Manager (PM)—Preparing project plan; monitoring and controlling project; approving project changes; quality assurance Michael Doe: Project Team Lead—Supervising technical staff assigned to project; monitoring/approving project change requests; informing the PM on all issues impacting the project and project plan.
Sue Jones: Project Team member—Liaison with Group A and communicating quality issues as required
Jane Smith: Project Team member—LIMS liaison between LMT and LMT users and the Project Team; communicate status of LMT LIMS progress and problem resolution; reporting quality status for LMT LIMS
John Smythe: Project Team member—Performs needs analysis for LMT and PEL LIMS requirements; contributes to establishing quality performance objectives
Jerry Schultz: LIMS Integrator and Project Team member—Software developer responsible for fulfillment of the project's technical requirements in accordance with the Project Quality Assurance Plan Mary Smith: Project Team member—Project Management administration; assurance that appropriate project management processes are observed throughout the project, including Quality Assurance reporting standards in accordance with the Communications Plan.
Customer and Contractor Managements' Project Team participation is important to provide clarification and guidance on any and all matters affecting the project team's ability to execute the project successfully. Approval(s): Project Manager:
Date: Sponsor: Date: 1.3 Latihan
1 Buat organisasi tim pengembang proyek perangkat lunak dan pilih salah satu kasus berikut (opsional)
2 Buatlah sebuah project charter sederhana untuk salah satu kasus berikut, atau kasus-kasus lain yang diberikan oleh instruktur, secara berkelompok. Kasus 1 : Mesin Parkir
Terdapat 2 Mesin yaitu di pintu masuk dan di pintu keluar. Di pintu masuk Operator mencek apakah ada space parkir yang masih kosong, jika masih ada operator memasukan nomor kendaraan dan memberikan kartu parkir kepada pemilik kendaraan, selanjutnya mesin secara otomatis akan menambahkan jumlah kendaraan yang parker dan pintu palang dibuka kemudian kendaraan masuk. Sebaliknya jika tidak
space yang kosong operator memberikan informasi kepada pemilik kendaraan jika tempat parkir telah penuh.
Sedangkan di pintu keluar operator menerima kartu parkir dari user dan mencatat kembali nomor kendaraan, selanjutnya mesin secara otomatis akan menghitung total biaya yang harus dibayar oleh pemilik kendaraan. Jika uang lebih maka operator akan memberikan kembalian (jumlah kembalian dihitung oleh mesin) dan kemudian operator membuka pintu keluar dan kendaraan bisa keluar, disini mesin secara otomatis akan mengurangi jumlah kendaraan yang parkir.
Kasus 2 : Poliklinik Sehat Aja
Sebuah rumah sakit daerah memiliki beberapa unit pengobatan, misalnya kebidanan, anak, penyakit dalam, umum dlsb. Setiap pasien yang datang ke rumah sakit harus mendaftar di bagian administrasi dan boleh memilih unit mana yang akan dikunjungi. Jika belum mengetahui unitnya, pasien disarankan untuk ke bagian umum terlebih dahulu. Setiap pasien yang baru pertama kali berobat akan diberi nomor identitas dan dibuatkan kartu berobat. Kartu ini harus dibawa setiap kali pasien datang berobat dan berlaku untuk semua bagian unit pengobatan. Setelah pasien memiliki kartu berobat, setiap kali berobat maka pasien harus mendaftar dan diberi nomor pendaftaran ke unit pengobatan tertentu. Setiap unit pengobatan terdapat beberapa orang dokter yang melayani pasien. Pasien yang telah memiliki nomor pendaftaran, akan membawa formulir diagnosis untuk diisi oleh dokter yang melayaninya. Formulir diagnosis ini diserahkan kembali ke bagian administrasi untuk dientri ke data rekam medik, dan digunakan sebagai dasar perhitungan pembayaran biaya berobat (di luar biaya pendaftaran).
Berikut ini contoh form rekam medik No. Pendaftaran : 200708-00101
Tgl : 20 Juli 2008 11.30 WIB
No. Pasien : A-002 Nama/JK/Usia : Anita/ P / 30 thn
Kode Poliklinik : UM (Umum) Isikan hasil diagnosa di bawah ini
No. Diagnosa Penanganan
1. Sakit perut dan pusing Diapet 30
2. demam stopcold, 10 3. ... Tindakan lain : 1. Suntik : ………. Rp. 2. Alat (USG/Bor/Rontgen) : ... Rp. 3. Bedah minor : ... Rp. 4. Lain-lain : ……….. Rp.
Kode Dokter : ACA (Aca Suraca)
Kode petugas medis : INO ( Indra Yuwono)
1.4 Tugas Pendahuluan I (dikumpulkan pada pertemuan ke satu) Tugas individu :
2 IDENTIFIKASI KEBUTUHAN DAN PEMODELAN PROSES
(3 kali Pertemuan) II.1 TUJUAN
Tujuan modul ini, adalah:
• Praktikan dapat menyebutkan kebutuhan fungsional dan non fungsional sebuah perangkat lunak.
• Praktikan dapat memodelkan proses menggunakan berbagai alat pemodelan • Praktikan dapat mendefinisikan spesifikasi sistem berdasarkan kebutuhan • Praktikan dapat membuat laporan spesifikasi kebutuhan perangkat lunak. II.2 TEORI
Keberhasilan dalam pembuatan sebuah perangkat lunak terletak pada keberhasilan mendefinisikan kebutuhan yang paling tepat untuk pengguna perangkat lunak tersebut. Identifikasi kebutuhan meliputi juga proses penentuan ruang lingkup (scope) pengembangan perangkat lunak (termasuk sasaran/tujuan dikembangkannya perangkat lunak, karakteristika pengguna dan output yang diharapkan dari perangkat lunak tersebut), dan identifikasi kebutuhan fungsional ataupun non fungsional. Salah satu alat untuk menggali requirement adalah memodelkan sistem yang menjadi fokus pengembangan aplikasi/software. Jika sistem tersebut terkait dengan fungsi bisnis, pemodelan ini seringkali disebut sebagai pemodelan proses bisnis.
Manfaat pemodelan proses bisnis antara lain :
Memahami proses yang sedang berjalan Menyamakan persepsi dengan klien Mengalisis peluang perubahan
Pada saat ini terdapat berbagai pendekatan dalam memodelkan proses bisnis, yang secara garis besar dapat dibagi menjadi dua yaitu :
• Berbasis teks : Process description
• Berbasis grafis : menggambarkan proses bisnis dalam satu diagram.
Untuk yang berbasis grafis, pendekatan yang digunakan cenderung beragam, tidak standar dan beberapa diantarnya tergantung pada vendor, contohnya UML dan ARIS. Selain itu ada juga pendekatan pemodelan proses yang menggunakan konsep aliran data yang terlibat dalam setiap proses. Pendekatan ini dikenal dengan nama Data Flow Model, dan diagramnya disebut dengan Data Flow Diagram (DFD).
2.1.1 Flowchart
Pendekatan yang paling umum digunakan untuk memodelkan proses adalah menggunakan Flowchart. Pemodelan proses menggunakan flowchart merupakan pengembangan pemanfaatan flowchart pada penggambaran algoritma program, Standar notasi yang digunakan biasanya mengacu pada . Mulai tahun 2004 dikenalkan BPMN (business process modeling notation) sebagai notasi standar yang umum digunakan untuk menggambarkan flowchart yang terkait dengan pemodelan proses bisnis.
Berikut ini salah satu contoh flowchart :
Gambar 2-1 Contoh Flowchart Sistem Helpdesk
Simbol-simbol yang digunakan pada flowchart sesuai dengan standar dari ISO 5807:1985, Information processing -- Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts, sebagai berikut :
Gambar 2-4 Garis dan simbol-simbol khusus
Berikut ini contoh diagram flowchart yang digambar menggunakan simbol standar BPMN :
Gambar 2-5 Diagram Proses Bisnis dalam Format BPMN Dekomposisi Proses
Dekomposisi merupakan salah satu teknik/pendekatan yang sering digunakan untuk menyederhanakan proses yang rumit. Dengan teknik dekomposisi, kita dapat melihat proses melalui bagian-bagian yang lebih mudah dipahami. Teknik dekomposisi digunakan pada hampir semua pendekatan, dan terdiri atas beberapa tahapan sebagai berikut :
1 Identifikasi Proses : mengidentifikasi proses-proses apa saja yang berhasil ditemui pada sistem/ruang lingkup yan dikaji.
2 Klasifikasi proses : mengelompokan proses-proses yang memiliki karakteristik kemiripan tertentu.
3 Identifikasi hubungan antar proses : untuk memetakan keterkaitan antar proses dan memahami gambaran sistem secara keseluruhan.
Teknik dekomposisi sangat bermanfaat untuk menggambarkan Flowchart maupun Data flow diagram.
Teknik Pemodelan Flowchart
• Perhatikan siklus proses : setiap proses memiliki siklus misalnya tahap inisialisasi, preparation, execution, monitoring dan evaluation.
• Identifikasi proses dari dua sudut pandang atau dimensi yaitu dimensi ruang dan waktu.
o Time / waktu : kapan proses itu terjadi, digunakan untuk menentukan urut-urutan proses.
o Space / ruang : dimana proses itu terjadi, digunakan untuk menentukan pelaku, pemilik atau penanggung jawab proses.
• Buat deskripsi proses dalam bentuk narasi. Biasanya dalam tahap awal, narasi tidak terstruktur.
• Tandai kata kerja dan kata benda Kata kerja ◊ kandidat proses Kata benda :
à kandidat data (input/output) à Fungsi/ pelaku proses
• Buat tabel fungsionalitas vs proses
• Tuliskan semua proses sesuai fungsionalitas • Gambarkan flow proses
• Tambahkan elemen data pelengkap (input/output) Contoh 2.1: Agen Pulsa Elektronik
Setiap orang dapat menjadi agen penjualan pulsa elektronik dengan cara mendaftarkan diri ke distributor. Setelah terdaftar, agen akan memiliki kode agen, dan diharuskan melakukan deposit di bank-bank yang sudah ditentukan. Setelah melakukan deposit, agen akan mengirimakan sms konfirmasi dan menunggu jawaban dari distributor. Jika sudah ada konfirmasi dari distributor, agen dapat mulai berjualan pulsa. Setiap transaksi pulsa yang berhasil akan mengurangi saldo deposit agen di distributor, dan agen maupun konsumen akan mendapatkan laporan hasil transaksi. Agen juga akan mendapatkan informasi sisa saldo. Setelah mencapai jumlah transaksi tertentu, agen berhak mendapatkan bonus atau bentuk keuntungan lainnya misalnya ekstra pulsa, harga diskon dan lain-lain.
Mendaftarkan diri Konfirmasi deposit
Menjawab konfirmasi deposit Menjual pulsa
Menghitung saldo deposit Mengirimkan laporan transaksi Menghitung total transaksi per agen Menentukan bonus
Langkah 2 : Dekomposisi Proses : Pendaftaran
Kelola Deposit Deposit baru Konfirmasi deposit Perhitungan saldo deposit Transaksi
Penjualan pulsa Laporan transaksi Perhitungan bonus
Perhitungan rekap penjualan per agen Pemberian bonus penjualan
Langkah 3 : Identifikasi Data Fungsi Agen Konsumen Distributor Data Data agen Data transaksi Data deposit
Langkah 4 : Klasifikasi Proses sesuai fungsi
Konsumen Agen Distributor
Mendaftar Konfirmasi pendaftaran
Konfirmasi deposit Menjawab konfirmasi deposit Membeli pulsa Menjual pulsa Mencatat transaksi
Menghitung deposit
Mengirimkan laporan transaksi Menghitung rekap transaksi Memberikan bonus Setelah diperoleh tabel di atas, gambarkan flowchart untuk kasus tersebut.
Gambar 2-6 Flowchart Penjualan Pulsa Elektronik Manfaat lain pemodelan flowchart:
• Identifikasi proses yang terlalu rumit atau dianggap merupakan pemborosan • Memperbaiki proses
Gambar 2-7 Flowchart Existing System Perbaikan 1 : Lakukan beberapa langkah secara paralel
Perbaikan 2 : Proses yang duplikat dapat digabung
Gambar 2-9 Flowchart Hasil Penggabungan Proses Redundan
Perbaikan 3 : Menambahkan proses baru untuk meningkatkan fungsi kontrol atau efektivitas proses secara keseluruhan.
Beberapa kekeliruan dalam menggambarkan flowchart : 1. Pilihan yang tidak ada pilihannya :
2.1.2 Data Flow Diagram
Data flow diagram (DFD) merupakan representasi grafis aliran data di sepanjang sistem informasi dengan menggambarkan data yang terlibat pada setiap proses. DFD ini dapat menunjukan data masukan dan keluaran setiap proses pada sistem, dan tidak menunjukan waktu proses tersebut terjadi atau urut-urutan proses. Teknik penggambarannya dengan menggunakan pendekatan “Top Down”, mulai dari satu “black box” proses tunggal yang dikembangkan (explode) menjadi beberapa sub proses. DFD disebut juga dengan nama bubble chart, bubble diagram, business flow model, function model, dan lain-lain.
Simbol-simbol yang digunakan untuk menggambarkan DFD ada 2 jenis yaitu menurut Gane & Sarson dan Yourdon/ De Marco.
:
Gambar 2-11 Simbol DFD menurut Gane & Sarson Simbol DFD menurut Yourdon/De Marco :
Gambar 2-12 Simbol DFD menurut Yourdon Contoh 2.2:
Gambar 2-13 DFD Level 0, Order System
1.0 Check Status 2.0 Issue Status Messages 3.0 Generate Shipping Order ACCOUNTING CUSTOMER WAREHOUSE 4.0 Manage Accounts Receivable 5.0 Produce Reports Order In-Stock Request
Status Data Status Message Pending Orders D1 Order Data Order Data Shipping Order Shipping Confirmation Invoice Payment Accounts Receivable D2
Accounting Data Accounts Receivable Data Order Data
Inventory Reports
Context Diagram
DFD dapat digambarkan secara hirarkikal, dengan pendekatan top-bottom, dari proses utama hingga ke sub proses yang paling rinci. DFD untuk proses utama disebut dengan Context Diagram yang merupakan perwakilan dari sistem itu sendiri. DFD untuk proses-proses yang diturunkan dari proses utama diberi nama sesuai tingkatan/level misalnya DFD level 0, 1, 2, dan seterusnya.
Penentuan kedalaman/kedetilan penurunan DFD ini disesuaikan dengan kebutuhan dan didasari oleh prinsip dekomposisi.
Context diagram menggambarkan sistem sebagai satu kesatuan tunggal dengan semua elemen-elemennya, termasuk pihak yang berinteraksi, keluaran dan masukan sistem. Context diagram dapat dianggap sebagai sebuah “black box”, dan tidak menjelaskan apa yang terjadi di dalam sistem. Context diagram terdiri atas satu proses tunggal yaitu sistem/perangkat lunak itu sendiri, dikelilingi oleh terminator (source/sink) yang berinteraksi dengan sistem, dan dilengkapi dengan panah yang menggambarkan aliran data keluar/masuk ke sistem.
Manfaat Penggambaran Context Diagram salah satunya adalah untuk menjawab pertanyaan :
• Masukan apa yang diperlukan oleh sistem ? • Apa keluaran sistem?
• Dengan pihak mana sistem akan berinteraksi Contoh 2.3 :
Secara umum, aturan penggambaran DFD didasari oleh prinsip-prinsip berikut : 1 Input pada suatu proses selalu berbeda dengan output proses .
2 Setiap elemen diberi nama yang berbeda. Untuk menyederhanakan gambar, data store atau source/sink diagram boleh digambarkan ulang.
3 Semua proses diberi nama dengan kata kerja. Aliran data, source/sinks dan data store diberi nama dengan kata benda.
Proses :
Elemen proses mewakili satu aktivitas terhadap data di dalam sistem. Elemen ini diberi nama berupa kata kerja dan menerima input dan mengeluarkan output (tidak ada proses yang hanya menerima input saja atau mengeluarkan output saja). Setiap proses diberi nomor untuk kemudahan penelusuran kepada proses sebelumnya atau proses berikutnya. Nomor tidak selalu menunjukan urutan proses.
Contoh :
Identifikasi Proses :
Hindari proses yang tidak melakukan apa-apa tetapi hanya memindahkan/meneruskan data dan mengeluarkan output data yang tidak berubah sama sekali. Contoh identifikasi proses yang tepat misalnya:
• Melakukan perhitungan (menghitung rata-rata nilai, menghitung pajak). • Membuat keputusan (menyetujui order).
• Mengurutkan, menyaring atau merangkum data (menampilkan data tagihan yang belum dibayar pada periode tertentu).
• Mengatur data untuk keperluan tertentu (membuat laporan, menjawab pertanyaan).
• Memicu proses lain (misalnya : mematikan mesin, menjalankan mesin) • Menggunakan penyimpanan data (create, read, update, delete record). Aturan Penggambaran Proses :
• Boleh menghasilkan lebih dari satu output atau menerima lebih dari satu input.
• Dapat terhubung dengan simbol lain apa saja (termasuk dengan simbol proses lainnya).
Manakah pengambaran proses yang paling tepat ?
Aliran Data :
Aliran data mewakili jalur perpindahan data dari satu elemen sistem ke elemen lainnya. Aliran data digambarkan dalam bentuk panah berarah yang menunjukkan arah sumber dan tujuan data. Aliran data dari proses ke data store dapat digambarkan dengan dua panah terpisah atau digabung menjadi satu panah dengan arah bolak-balik.
Data dapat berpindah, dari satu tempat ke tempat lain di dalam sistem, misalnya : • Dari external entity (source) ke sistem
• Dari sistem ke external entity (sink)
• Dari simbol internal ke simbol internal lainnya, tetapi salah satu ujungnya harus berawal atau berakhir di proses.
Aturan Penggambaran Aliran Data :
• Panah harus selalu dilengkapi dengan nama data yang dilewatkan, nama data ini harus berupa kata benda.
• Fork, menggambarkan data yang sama keluar dari satu lokasi menuju dua atau lebih proses, data source atau sink yang berbeda.
• Join, menggambarkan data yang sama datang dari dua atau lebih proses , data store atau source/sinks yang berbeda ke lokasi yang sama.
• Aliran data tidak dapat kembali ke tempat asal data tersebut. • Aliran data ke arah data store berarti update (merubah isi data).
• Aliran data dari arah data store berarti retrieve (menggunakan/mengambil) Data Store
Data store menggambarkan tempat penyimpanan data yang merupakan bagian internal dari sistem. Data store disertakan pada sistem bila sistem melakukan transformasi data seperti store, add, delete, atau update. Setiap data store ini nantinya harus terkait dengan entitas data pada Entity Relationship Diagram (ERD). Data store secara fisik dapat berwujud file pada komputer, log, dokumen dan lain-lain.
Aturan penggambaran data store :
• Data store harus diberi nama kata benda dan boleh dilengkapi dengan nomor untuk memudahkan penjelasan.
• Data store harus memiliki minimal satu aliran data masuk atau keluar. • Data tidak dapat berpindah langsung dari satu store ke store lainnya.
• Data tidak dapat berpindah langsung dari sumber di luar sistem ke data store, dan sebaliknya
Manakah penggambaran aliran data dan data store yang kurang tepat ? Jelaskan jawaban anda !
Source/Sink (External Entity)
External entity adalah asal atau tujuan data yang terdapat di luar sistem. External entity dapat berupa nama bagian di luar organisasi, orang, lembaga, fungsi, atau sistem/perangkat lunak lain. Source adalah entitas yang mengirimkan data ke dalam sistem, sink adalah entitas yang menerima data dari sistem.
Contoh :
Identifikasi External Entity :
• Pihak luar, orang, sistem dan tempat penyimpanan data. • Berada di luar sistem, tetapi berinteraksi dengan sistem.
• Bentuk interaksi : menerima informasi dari sistem, memicu sistem untuk melakukan sesuatu, memberikan informasi kepada sistem
– Contoh : customer, manager,
• Tidak termasuk external entities : staf admin, atau staf lain yang hanya berperan “memindahkan” data.
Aturan Penggambaran :
• Harus tersambung ke proses melalui data flow • Diberi nama berupa kata benda.
Dari berbagai aturan penggambaran DFD yang sudah disebutkan sebelumnya, maka dapat disimpulkan bahwa aturan penggambaran aliran data seperti pada tabel berikut:
Dekomposisi DFD
Seperti halnya pada teknik pemodelan proses menggunakan flowchart, pada DFD juga diterapkan dekomposisi dengan tujuan memudahkan menganalisis permasalahan.
Dekomposisi pada DFD dilakukan dengan cara menguraikan satu proses utama (context) menjadi sub-sub proses. Setiap tahapan berikutnya disebut dengan “Level” Setiap tingkatan rinci yang diturunkan dari hasil dekomposisi disebut dengan Level, sehingga seringkali proses dekomposisi disebut dengan leveling.
• Level 0 : Menggambarkan semua proses UTAMA yang terjadi pada suatu sistem
• Level 1 : Menggambarkan semua sub proses dari salah satu proses pada level 0 • Level 2 : menggambarkan semua sub proses dari salah satu proses pada level 1.
Contoh 2-3:
Context Diagram
Level 0
Level 1
Level 0
Contoh 2 .4:
MyMaid adalah sebuah portal yang dikhususkan untuk memfasilitasi jasa pembantu rumah tangga. Pengguna aplikasi berbasis web ini meliputi Perusahaan Jasa PRT dan konsumen pengguna jasa PRT. Melalui situs ini, Perusahaan Jasa PRT dapat mengiklankan perusahaannya, ketersediaan PRT dan syarat bagi pengguna jasa PRT. Untuk dapat mengisikan data PRT, Perusahaan Jasa PRT harus mendaftar menjadi member dengan menyerahkan bukti identitas perusahaan. Data ini akan divalidasi oleh pengelola MyMaid, baik dengan cara menyelidiki kelengkapan data maupun kunjungan fisik. Setelah dianggap valid, Perusahaan akan mendapatkan nomor keanggotaan dan mulai dapat mengisikan berbagai info seperti profil perusahaan dan profil tenaga PRT yang ditawarkan. Konsumen pengguna jasa PRT dapat menggunakan sistem tanpa harus mendaftar terlebih dahulu, misalnya untuk melihat-lihat profil perusahaan ataupun profil tenaga PRT yang ditawarkan. Situs juga dilengkapi dengan fasilitas pencarian data PRT dengan kriteria tertentu. Konsumen diwajibkan mendaftar jika bermaksud memesan jasa PRT dari perusahaan tertentu. Pesanan konsumen akan diteruskan oleh sistem kepada perusahaan tersebut melalui email dan perusahaan dapat memberikan konfirmasi kepada konsumen langsung melalui email. Sistem tidak bertanggung-jawab terhadap semua transaksi yang terjadi antara pengguna jasa PRT dengan perusahaan penyedia jasa PRT, juga tidak bertanggung jawab terhadap keakuratan data masing-masing perusahaan pada portal. Pengguna dapat melaporkan keluhan terhadap perusahaan tertentu kepada admin sistem dan admin sistem berhak menerapkan sanksi terhadap perusahaan tersebut misalnya menonaktifkan akun atau menghapus akun.
Langkah-langkah penggambaran DFD : Tahap 1:
• Tentukan judul sistem yang representatif : MyMaid Portal • Tentukan pihak yang berinteraksi dengan sistem :
– Konsumen
– Perusahaan Jasa PRT – Pengelola MyMaid
Tahap 2 : Tentukan masukan/keluaran utama : • Konsumen :
– IN : info pencarian, pesanan, keluhan, info konsumen – OUT : info profil perusahaan, info tenaga PRT
• Perusahaan Jasa PRT (PJ-PRT)
– IN : Identitas perusahaan, profil perusahaan, profil tenaga PRT – OUT: Pesanan konsumen, konfirmasi pendaftaran, status akun. • Pengelola MyMaid :
– IN : validasi pendaftaran, sanksi member – OUT : keluhan, informasi pendaftaran PJ-PRT. Gambarkan :
Context Diagram
Dekomposisi Proses :
• Identifikasi proses-proses :
– PJ-PRT : mendaftarkan diri, mengisi informasi profil dan tenaga PRT. – Konsumen : mendaftarkan diri, mengisi pesanan, mengisi keluhan,
– Pengelola MyMaid : validasi akun member, membaca keluhan, memberikan sanksi.
• Analysis dan Sintesis : – Pendaftaran
• Pendaftaran PJ-PRT
– Pendaftaran PJ-PRT baru – Validasi akun pendaftaran • Pendaftaran konsumen
– Kelola data Profil dan PRT • Kelola data Profil PJ-PRT • Kelola data profil PRT • Kelola informasi jasa PRT – Kelola Pesanan dan Keluhan
• Entri data pesanan • Entri data keluhan • Entri sanksi member Dekomposisi Diagram :
CRUD Matriks : Digunakan untuk menganalisis sumber data, dan menentukan otoritas atas data. Untuk kasus diatas, dapat dibuat CRUD matriks sebagai berikut : Table 2-1 CRUD Matrix
Level Nomor Proses
Nama Proses Konsumen PJ-PRT Pengelola MyMaid
0 1.0 Pendaftaran CRU CRU RUD
2.0 Kelola data profil dan
PRT
CRUD
3.0 Kelola Pesanan dan
Keluhan CR R RUD
1 1.1 Pendaftaran Konsumen CRU
1.2 Pendaftaran PJ-PRT CRU RUD
2.1 Kelola Data Profil
PJ-PRT R CRUD
2.2 Kelola data PRT R CRUD
2.3 Kelola Informasi Jasa
PRT R CRUD
3.1 Entri data pesanan CRU R
3.2 Entri data keluhan CRU RUD
3.3 Entri sanksi member R CRUD
2.1.2 Validasi akun pendaftaran CRUD RUD 2.1.3 SPESIFIKASI PROSES
PSPEC atau process specification adalah deskripsi tentang apa yang terjadi pada proses level paling bawah, pada suatu diagram aliran data. Disebut juga dengan “MINISPEC” (Miniatur Specification) [De Marco].
Gambar 2-15 Berbagai bentuk spesifikasi proses Format Process specification :
• Nomor proses dan nama proses : harus sesuai dengan nomor dan nama proses pada DFD
• Deskripsi proses : menjelaskan apa yang harus dikerjakan
• daftar aliran data input dan output: harus sama seperti nama data pada DFD, nama data yang digunakan pada rumus atau logika program harus sesuai dengan kamus data.
• Tipe proses : batch, online (perlu rancangan tampilan), manual (harus memiliki prosedur yang jelas yang harus dikerjakan oleh karyawan).
• Penggunaan kode prewritten: memuat nama sub program atau function yagn digunakan.
• Deskripsi logika proses : berupa kebijakan atau aturan bisnis, bukan bahasa komputer /pseudocode.
• Referensi logika metoda: berupa deskripsi dalam bahasa inggris terstruktur atau decision table atau decision tree.
Contoh : Total_charge = 0 REPEAT get_next_room IF room_type = ‘EXECUTIVE’ total_charge=total_charge+60$ ELSE total_charge=total_charge + 35$ UNTIL all_booked_rooms_processed OR total_charge > credit_limit
Format standar Decision Table
Condition and actions Rules
Condition stub (daftar semua kondisi
yang mungkin terjadi di dalam proses) Rules : memuat semua hal-hal yang mengidentifikasi berbagai kombinasi yang mungkin terjadi
Action Stub : memuat semua tindakan yang mungkin terjadi dalam proses
Action entries : indicator yang menyatakan action mana yang akan dikerjakan.
Contoh :
Decision table untuk proses pemilihan catalog mana yang akan dikirimkan ke konsumen yang hanya memesan melalui catalog.
Langkah-langkah penyusunan Decision Tree :
1. Tentukan kondisi yang mempengaruhi keputusan : jumlah kondisi akan menjadi jumlah baris pada bagian kiri atas decision tables
2. Tentukan tindakan yang paling mungkin dilakukan : jumlah tindakan yang mungkin dilakukan akan menjadi jumlah baris di bagian kiri bawah table 3. Tentukan kondisi alternative untuk semua kondisi : Bentuk sederhananya
adalah dua alternative (Y atau N), bisa juga ada banyak alternative.
4. HItung jumlah maksimum kolom pada decision table : merupakan banyaknya alternative untuk setiap kondisi, misalnya ada 4 kondisi dan untuk setiap kondisi ada 2 alternatif maka aka nada 16 kemungkinan (2x2x2x2)
5. Isikan alternative kondisi
6. Lengkapi table dengan menyisipkan X rule action yang diperlukan 7. Kombinasikan rule yang paling mungkin terjadi
8. Periksa situasi yang tidak mungkin terjadi 9. Tata ulang sehingga mudah dipahami
Setelah decision table dibuat, selanjutnya lakukan pemeriksaan kelengkapan dan ketepatan (completeness and accuracy). Biasanya terdapat 4 macam masalah yang mungkin terjadi :
• Incompleteness : jika ada kondisi yang terlewat dicantumkan, maka seluruh tabel harus diubah.
• Impossible situation : misalnya tidak mungkin ada mahasiswa yang berumur di atas 50 tahun.
• Contradiction : terjadi bila ada beberapa aturan yang memerlukan tindakan yang berbeda tetapi memenuhi kondisi yang sama.
• Redundancy : terjadi jika sekumpulan alternative memerlukan tindakan yang sama persis.
Decision Tree
Decision tree digunakan jika terdapat pencabangan yang rumit pada struktur pengambilan keputusan.
Cara membuat decision tree :
• Mulai dari sisi kiri yaitu dari akar tree dan dilanjutkan dengan pencabangan kea rah kanan.
• Identifikasi semua kondisi dan aksi serta urutan dan waktunya (jika dianggap penting).
• Gambarkan dalam bentuk jaringan alternative keputusan.
Contoh : decision tree untuk persetujuan pembelian non tunai di sebuah supermarket.
Pemilihan model spesifikasi proses :
• Structured English digunakan jika banyak tindakan berulang atau jika komunikasi dengan end-user sering dilakukan.
• Decision table digunakan jika terdapat kombinasi kondisi, tindakan dan aturan yang rumit atau diperlukan metoda yang efektif untuk menghindari situasi yang tidak mungkin, rendundan atau kontradiktif.
• Decision tree digunakan jika urutan kondisi dan tindakan bersifat kritikal atau jika tikda setiap kondisi relevan dengan setiap tindakan.
2.1.4 Kamus Data (Data Dictionary)
Kamus data adalah daftar terorganisir dari semua elemen data yang ada pada suatu sistem dengan definisi yang jelas/tepat, sehingga user dan analisis sistem bisa mendapat kesepahaman dari input, output dan komponen dari penyimpanan dan kalkulasi “intermediate” yang ada.
Notasi kamus data yang digunakan dalam analisa sistem, yaitu Tabel 2.3 Tabel Kamus Data
No. Notasi Keterangan
1 = Terdiri dari/didefinisikan sebagai/maksudnya adalah 2 + Dan
3 (…) Opsional
4 {…} Iterasi/pengulangan
5 […] Pemilihan dari beberapa alternatif 6 *…* Komentar
7 @ Identifier dari state
8 | Pemisahan pada pemilihan (atau) Contoh :
DATA STRUCTURE
ORDER= ORDER NUMBER +ORDER DATE+[ PERSONAL CUSTOMER NUMBER, CORPORATE ACCOUNT NUMBER]+ SHIPPING ADDRESS=ADDRESS+(BILLING ADDRESS=ADDRESS)+
1 {PRODUCT NUMBER+
PRODUCT DESCRIPTION+ QUANTITY ORDERED+ PRODUCT PRICE+
PRODUCT PRICE SOURCE+ EXTENDED PRICE } N+ SUM OF EXTENDED PRICES+
PREPAID AMOUNT+
(CREDIT CARD NUMBER+EXPIRATION DATE)
(QUOTE NUMBER)
ADDRESS=(POST OFFICE BOX NUMBER)+ STREET ADDRESS+ CITY+ [STATE, MUNICIPALITY]+(COUNTRY)+POSTAL CODE
2.2 Dokumen yang Terlibat dalam Fase Analisa atau Spesifikasi
- IRS (Interface Requirement Specification) menjelaskan sistem secara global serta kaitannya dengan lingkungan sekitarnya.
- SRS (Software Requirement Specification) menjelaskan sistem secara detail termasuk fungsi-fungsi /proses yang harus dipenuhi.
2.2.1 Pemodelan Data
Pemodelan data merupakan aktivitas penting pada perancangan sistem. Model data dijadikan acuan untuk perancangan basis data. Kaitan antara analisis kebutuhan dengan pemodelan data dapat dilihat pada diagram berikut :
Pemodelan data dimulai dengan membuat skema konseptual data yang merupakan panduan untuk menurunkan rancangan data. Skema konseptual ini harus dapat dihubungkan dengan kamus data dan nama-nama data yang terdapat pada DFD, seperti pada contoh berikut :
Salah satu alat untuk memodelkan data secara konseptual yaitu menggunakan ER Diagram, yang menyatakan data dalam bentuk relasi antar entitas yang memiliki sekumpulan atribut.
Contoh :
Bentuk ERD yang lebih terinci yang terkait dengan perancangan basis data dapat dilihat pada contoh berikut ;
2.2.2 SRS (Software Requirement Specification)
SRS adalah hasil akhir dari proses analisis. Fungsi dan kinerja yang harus dipenuhi sebagai bagian dari rekayasa sistem ditetapkan dengan deskripsi yang lengkap, baik deskripsi fungsional dan behavioral .
Format/kerangka SRS, adalah sebagai berikut : Table 2-2 Kerangka SRS
Kerangka Dokumen Keterangan
Abstraksi Abstraksi/Rangkuman dokumen (SRS)
Daftar Gambar Daftar Tabel
6 Pendahuluan
1.5 Tujuan Tujuan penyusunan dokumen SRS dan
menentukan siapa yang akan menggunakan SRS ini
1.6 Ruang Lingkup Perangkat Lunak Memberikan batasan pembuatan SRS 1.7 Daftar Definisi dan Singkatan Menjelaskan definisi dan singkatan dalam SRS
1.8 Referensi Referensi/dokumen/bahan acuan yang digunakan
1.9 Overview SRS Menjelaskan isi dan organisasi dari SRS secara
singkat 7 Deskripsi Umum
Perspektif Produk Menjelaskan :
Identifikasi perangkat lunak Kemampuan perangkat lunak
Tujuan dan keuntungan perangkat lunak Fungsi-Fungsi produk Menjelaskan kesimpulan dari fungsi yang umum
yang akan dilakukan oleh perangkat lunak
Karakteristik Pengguna Menjelaskan karakteristik umum dari user
perangkat lunak
Batasan Umum Menjelaskan item-item yang akan membatasi
pilihan pengembangan perangkat lunak
Asumsi dan Ketergantungan Menjelaskan factor-faktor yang dapat
mengakibatkan perubahan pada perangkat lunak
8 Kebutuhan Spesifik Berisi semua kebutuhan perangkat lunak hingga
tingkat yang paling rinci 9. Kebutuhan Antarmuka
Antarmuka Pengguna Menjelaskan format layar, menu, tata letak dst Antarmuka Hardware Menjelaskan perangkat keras yang akan
digunakan
Antarmuka Software Menjelaskan perangkat lunak yang akan digunakan (basis data, sistem operasi dll)
Antarmuka Komunikasi Menjelaskan perangkat komunikasi yang akan digunakan (protokol jaringan lokal)
10. Kebutuhan Fungsional Tujuan dan prioritas proyek pengembangan
perangkat lunak
DCD (Data Context Diagram) Menjelaskan Context Diagram perangkat lunak DFD (Data Flow Diagram) Level 1 Menjelaskan DFD level 1 perangkat lunak
(data-in, data-out, PSPEC, CSPEC, Data Dictionary) DFD (Data Flow Diagram) Level 2 Menjelaskan DFD level 2 perangkat lunak
(data-in, data-out, PSPEC, CSPEC, Data Dictionary) DFD (Data Flow Diagram) Level n Menjelaskan DFD level n perangkat lunak
(data-in, data-out, PSPEC, CSPEC, Data Dictionary)
Unjuk Kerja Menjelaskan unjuk kerja perangkat lunak
Batasan Perancangan Menjelaskan batasan perancangan yang akan
dihasilkan oleh standar lain, keterbatasan hardware dan lain-lain
Atribut
Ketersediaan (Availability) Menjelaskan faktor untuk menjamin tingkat ketersediaan seluruh sistem (recovery dll)
Keamanan (Security) Menjelaskan faktor untuk menjamin tingkat keamanan perangkat lunak
Keterpeliharaan (Maintainability) Menjelaskan atribut yang berhubungan dengan kemudahan perawatan dari perangkat lunak Dst
Kebutuhan Lain – Lain
Basis Data Menjelaskan kebutuhan logis untuk setiap
informasi yang disimpan dalam basis data
Sistem Operasi Menjelaskan kebutuhan sistem operasi dari perangkat lunak
Adaptasi Tempat Menjelaskan kebutuhan tempat dan adaptasinya dari perangkat lunak
Lampiran Berisi penjelasan tambahan pada laporan ini
2.3 Latihan dan Tugas
Latihan 2.1 (Pertemuan 2) : Untuk setiap kasus berikut, kerjakanlah hal-hal berikut : 1. Definisikan ruang lingkup sistem yang akan dikembangkan.
2. Tuliskan kebutuhan yang berhasil anda identifikasi, beserta jenis kebutuhan tersebut (fungsional/non fungional).
3. Analisislah kasus-kasus tersebut, apakah ada peluang perbaikan proses ataukah ada proses-proses / aktivitas lain yang perlu ditambahkan untuk memperbaiki kualitas proses tersebut.
4. Gambarkan flowchart untuk masing-masing kasus. I. Sistem Informasi Pendaftaran Siswa Baru (PSB)
Siswa yang akan mendaftar ke sebuah sekolah harus mengisi formulir pendaftaran dan melengkapi persyaratan, yang terdiri atas fotokopi surat keterangan lulus yang memuat nilai UAN, surat pengantar dari sekolah asal, form yang sudah diisi lengkap, foto, dan surat pendukung lainnya (jika ada). Petugas pendaftaran akan memeriksa kelengkapan dan keabsahan persyaratan. Jika semua sudah lengkap maka data-data tersebut akan diisikan ke file calon siswa. Selanjutnya tim PSB akan melakukan proses seleksi berdasarkan informasi pada file calon siswa. Proses ini meliputi penetapan nilai UAN minimum, total murid yang akan diterima, prosentase yang diterima melalui jalur normal (berdasarkan hasil UAN), jalur prestasi dan jalur tidak mampu. Kriteria murid yang masuk jalur prestasi (misalnya karena prestasi di bidang olahraga / kesenian), dan kriteria yang masuk jalur tidak mampu. Hasil proses seleksi akan disimpan pada file hasil seleksi. Berdasarkan file hasil seleksi maka petugas akan
1. Membuat surat yang dikirimkan ke semua siswa.
2. Membuat laporan akhir penerimaan siswa untuk diserahkan ke Dinas Pendidikan
Jika siswa dinyatakan diterima maka siswa ini akan melakukan pendaftaran ulang dengan menunjukkan surat pemberitahuan tanda kelulusan.
Untuk mendukung proses PSB tersebut, diperlukan sistem informasi yang memiliki kemampuan sebagai berikut :
1. Mencatat data calon siswa 2. Mencatat kriteria seleksi
3. Mencatat hasil seleksi dan menampilkan penelusuran seleksi berdasarkan pemenuhan kriteria
4. Mencatat siswa yang mendaftar ulang setelah dinyatakan lulus seleksi. II. Sistem Jasa Penyedia Tenaga Kerja
PT MM (Maunya Maju) adalah sebuah perusahaan yang berbisnis sebagai penyedia jasa tenaga kerja sementara (part time) yang biasanya dibutuhkan oleh perusahaan untuk mengisi lowongan dalam jangka waktu singkat, khususnya untuk pekerjaan yang terkait dengan keahlian komputer. Karyawan yang disediakan khususnya adalah yang memiliki ketrampilan menggunakan software seperti word processing, excel, atau memiliki ketrampilan teknik seperti instalasi atau reparasi kerusakan komputer. Setiap karyawan harus melewati uji kompetensi untuk tingkatan ketrampilan tertentu. Untuk keperluan tersebut, dibuatlah suatu system yang dapat menempatkan karyawan sesuai dengan persyaratan yang diminta oleh perusahaan yang membutuhkan karyawan tersebut.
Aktivitas bisnis pada proses tersebut adalah :
1. Perusahaan klien menelpon PT.MM dan mengajukan permintaan karyawan dengan spesifikasi tertentu. Permintaan ini dicatat pada laporan permintaan. Jika klien tersebut adalah klien baru, maka data perusahaan client akan dicatat pada master file klien.
2. Berdasarkan permintaan tersebut dilakukan pemilihan pada data karyawan yang sudah ada, yang memenuhi kualifikasi yang diminta. Data ini disesuaikan dengan data file master karyawan.
3. Jika ditemukan calon karyawan yang sesuai, maka dibuatkan dokumen kontrak kerja yang datanya diperoleh dari file master karyawan dan master klien.
4. Kontrak yang sudah selesai digunakan untuk melakukan pembaruan pada data master karyawan. File permintaan tenaga kerja kemudian ditambahkan catatan waktu kontrak dan informasi karyawan yang menjalankan kontrak tersebut. 5. Setiap bulan, dibuat laporan jadwal penempatan untuk setiap karyawan yang
meliputi informasi klien, informasi karyawan, dan informasi permintaan tenaga kerja, yang diurutkan berdasarkan tanggal kontrak setiap karyawan. 6. Untuk setiap permintaan yang masuk, akan diberikan surat konfirmasi apakah
permintaan tersebut dapat dipenuhi atau tidak. Latihan 2.2 (Pertemuan 3) :
1. Buatlah DFD untuk level-level berikutnya untuk kasus Portal Pembantu MyMaid di atas.
2. Cari Kesalahan pada DFD berikut :
3. Gambarkan atau revisi DFD untuk kasus-kasus berikut : 3.1. Perwalian Online
Diberikan sebuah DFD untuk sistem perwalian online seperti berikut.
Deskripsi prosesnya secara singkat adalah :
Mahasiswa yang sudah membayar SPP dapat melakukan perwalian secara online dengan mendaftar untuk mengisi form rencana studi. Dosen wali akan memeriksa data mahasiswa yang sudah mengisi form rencana studi, memeriksa nilai kuliah semester sebelumnya dan memberikan konfirmasi perwalian (menyetujui/tidak
studi. Informasi pada kartu rencana studi akan disimpan pada data perwalian. Kaprodi akan mendapat laporan berupa rekapitulasi data mahasiswa yang sudah melakukan perwalian online.
Berdasarkan deskripsi proses tersebut, analisislah diagram diatas apakah sudah tepat. Jika belum, tuliskan beberapa kekeliruan yang mungkin ditemukan pada diagram tersebut, dan perbaikilah diagram tersebut agar sesuai dengan deskripsi proses dan kaidah pembuatan DFD yang benar.
Lakukanlah analisis yang sama, jika, misalnya di Universitas Abrakadabra berlaku sistem perwalian yang dapat digambarkan pada DFD level 0 berikut :
3.2. Sistem Penggajian
Perhatikan gambar DFD di halaman berikut. Pada dfd tersebut, terdapat beberapa tanda yaitu a,b,c dan d. Untuk setiap tanda, jelaskan kesalahan yang ditunjuk oleh tanda tersebut (jika memang ada kesalahan), misalnya :
a. Tanda a : kesalahan dalam pemberian nama file b. Tanda b : tidak ada kesalahan
3.3. Penjualan Pulsa Elektronik
Diberikan DFD seperti pada gambar berikut, yang merupakan model aplikasi penjualan pulsa melalui sms.
Untuk dapat berjualan pulsa, anggota harus mendaftar, cukup dengan mengirimkan data diri melalui sms. Setelah mendaftar, anggota akan mendapatkan PIN dan nomor
