Proyek ini bertujuan untuk membuat aplikasi pelacakan pengiriman barang secara online untuk mempermudah pemantauan lokasi barang dan meningkatkan kepercayaan pelanggan. Dokumen ini menjelaskan tujuan, risiko, hasil yang diharapkan, jadwal, anggaran, asumsi, dan struktur organisasi proyek.
1. Project Charter
Project Name : Kirim Barang Online (KBO)
Project Number : 001/PMKTR/III/2017
Date : 6 Maret 2017
Revision Numbe n: -
A. Deskripsi dan Tujuan
Jasa pengiriman barang telah menjadi fasilitas yang sangat membantu
masyarakat dalam kegiatan kirim mengirim barang. Pengiriman barang tidak
hanya dilakukan di dalam negeri saja, bahkan juga ada yang ke luar negeri.
Banyak perusahaan ekspedisi pengiriman yang muncul menawarkan jasa
pengiriman barang. Dengan banyaknya perusahaan ekspedisi pengiriman
barang, menyebabkan konsumen memilih perusahaan mana yang dapat
dipercaya dan sesuai dengan yang mereka butuhkan. Tentunya, hal ini dilihat
dari banyak aspek terutama keamanan seperti pemantauan update akan lokasi
barang. Karena banyaknya pengiriman barang membuat pemantauan
pengiriman barang menjadi sedikit lebih sulit. Oleh karena itu diperlukan
aplikasi tracking lokasi armada pengiriman barang untuk mempermudah
pemantauan. Dengan adanya aplikasi tracking akan membuat pelanggan
percaya akan kemanan barangnya dan akan merasa nyaman dengan pelayanan
perusahaan.
B. Risks
Risiko dari aplikasi tracking lokasi transit barang online sudah diidentifikasi.
Manajer proyek akan menentukan dan menerapkan mitigasi risiko yang
diperlukan strategi penghindaran / sesuai untuk meminimalkan kemungkinan
risiko tersebut:
Terjadinya kebocoran data.
Terjadinya kondisi database tidak dapat digunakan dikarenakan matinya
listrik pada lokasi server.
Terjadinya kepalsuan data akibat kesalahan manusia pada saat verifikasi
barang.
Terjadinya bug pada saat proses penjalanan aplikasi yang tidak sesuai dengan
caranya.
C. Deliverables
Penjelasan dokumen ini meliputi SDPLN (Software Development Plan), SRS
(Software Requirement Specification), SAD (Software Architecture
Development), TSTPLN (Test Plan) dan User Documentation serta hasil dari
perencanaan. SDPLN yang menjelaskan secara umum dan global mengenai
rancangan aplikasi proyek. Rancangan aplikasi tersebut meliputi perkenalan
dokumen, gambaran umum proyek, struktur anggota dalam tim proyek, proses
2. manajemen, rencana proses secara teknik, rencana proses yang mendukung serta
rencana tambahan.
SRS menjelaskan berbagai macam kebutuhan pembuatan produk, yaitu
kebutuhan spesifik yang terdiri dari kebutuhan fungsionalitas, termasuk
didalamnya input, proses, dan output dari produk dan non-fungsionalitas.
Kebutuhan antar muka juga digambarkan dengan jelas di dalam dokumen ini,
terdiri dari kebutuhan antar pengguna, antar hardware yang menjelaskan
kebutuhan yang harus ada untuk menjalankan atau mengoperasikan aplikasi
sistem, kebutuhan antar software yang menjelaskan bagaimana cara pengguna
berinteraksi dengan sistem, dan kebutuhan antar komunikasi.
SAD menjelaskan tentang arsitektur proyek pembuatan aplikasi tracking
lokasi transit barang online yang akan dikerjakan. Dokumen ini diantaranya
berisi tentang Overview dari dokumen ini sendiri, Architectural Representation,
Architectural Goalsand Constraints, Use-Case View atau representasi
fungsionalitas dari proses, dan Logical View.
TSTPLN melingkupi tujuan-tujuan identifikasi informasi proyek dan
komponen perangkat lunaknya, daftar persyaratan yang diujikan untuk testing,
merekomendasikan dan menjelaskan strategi pengujian yang akan digunakan,
identifikasi kebutuhan yang diperlukan, serta daftar lampiran terkait.
D. Scope Definition
Batasan dari proyek ini adalah:
Tidak membahas tentang penggajian pengurus
Tidak membahas tentang pembuatan jurnal
Tidak membahas marketing perusahaan
Kebutuhan fungsional yang harus ada dalam sistem yang akan dibuat ini
adalah sebagai berikut:
Aplikasi dapat berjalan di perangkat mobile.
Aplikasi dapat menampung database barang.
Aplikasi dapat memantau atau tracking armada pengiriman barang.
Aplikasi harus dapat membantu konsumen dalam mengetahui pengiriman
barang mereka.
Aplikasi harus jelas pemakaiannya dan mudah digunakan.
Kebutuhan nonfungsional adalah kebutuhan tambahan yang tidak memiliki
input, proses, dan output. Namun demikian, kebutuhan nonfungsional ini
sebaiknya dipenuhi, karena akan sangat menentukan apakah sistem ini akan
diguakan user atau tidak.
Berdasarkan perfomancenya, aplikasi diharapkan dapat mempersingkat waktu
yang dibutuhkan untuk menyelesaikan setiap pemantauan barang. Semakin
sedikit waktu yang dibutuhkan, semakin besar troughput yang dapat dihasilkan.
3. Peningkatan ini diharapkan akan membuat konsumen lebih mempercayai jasa
pengiriman barang ini.
Kebutuhan non-fungsional berdasarkan information dari PIECES framework
adalah terintegrasinya data. Sistem yang baru juga diharapkan dapat mencegah
terjadinya redundancy data dan dapat menjaga akurasi dan konsistensi data.
Akurasi dan konsistensi data sangat dibutuhkan untuk mencegah adanya
kesalahan penginputan data tamu dan pengolahan data transaksi. Akurasi data
dapat dijaga dengan meminimalisasi terjadinya kesalahan dalam pencatatan,
sedangkan konsistensi dapat dijaga dengan perancangan dan implementasi
database yang baik.
Kebutuhan nonfungsional dari segi pengontrolan sistem yang diinginkan user
antara lain adalah sistem dapat mempermudah dalam penambilan keputusan
oleh pihak manajemen tingkat atas dalam waktu yang cepat. Untuk
meningkatkan reliabilitas sistem, sistem diharapkan memiliki backup data.
Backup data ini terutama dibutuhkan jika server down, misalnya karena matinya
aliran listrik. Dengan adanya backup data ini akses data tidak akan terhenti
apabila server down. Selain itu, sistem juga dapat menjaga keamanan data-data
yang disimpan, terutama untuk data-data yang bersifat confidential.
Kebutuhan dari segi efisiensi yaitu sistem diharapkan dapat mempercepat
dalam pengaksesan data dan mempermudah pihak anggota dalam mengetahui
kondisi akunnya dalam koperasi dan proses yang harus dikerjakan.
E. Project Milestones
Summary Milestone Schedule – List key project milestones relative to project
start.
Project Milestone Target Date (dd/mm/yyyy)
Project Start 09/03/2017
Complete Solution Analyst 24/03/2017
Complete Solution Design 10/04/2017
Complete Solution Simulation with Software 01/05/2017
Complete Solution Simulation and Testing 14/05/2017
Complete Installation Software 27/05/2017
Project Complete 31/05/2017
F. Budget Summary
Project Component Component Cost
Survey dan Analisa Rp 7.000.000
Desain dan Implementasi Sistem Rp 30.000.000
Biaya Lisensi Rp 10.000.000
Training Aplikasi Rp 2.000.000
Biaya Dokumentasi Rp 8.000.000
4. Total Rp 57.000.000
G. Assumptions, Constraints & Dependencies
Asumsi-asumsi dari proyek ini adalah:
1) Survey dan hari bekerjan dilakukan selama 1 minggu yang terdiri dari 5
hari(hari Sabtu dan Minggu tidak dihitung).
2) Biaya-biaya telah ada didalam akun yang jelas dan sudah ada di Koperasi
perusahaan.
Batasan-batasan untuk sistem ini, antara lain :
1) User hanya bisa melakukan tracking terhadap barang yang dikirimnya(bukan
barang orang lain).
2) Admin bisa melakukan modifikasi insert, update, dan delete data.
H. Project Organizational Structure
Function Name Role
Project Manager Rahmat Rijal 1. Menjadwalkan pelaksanaan
dan manajemen proyek.
2. Memantau kinerja proyek
pelaksanaan dari analisis
sampai implementasi.
3. Membuat dokumen SDPLN
yang mendefinisikan
rencana proyek.
Back-end programmer Farhan
Ramadhana
Membuat Back-end aplikasi
yang telah dirancang dan
direncanakan.
Front-end programmer Faishal Ilham Membuat Front-end aplikasi
yang telah dirancang dan
direncanakan.
System Analyst Ananda Ricky 1. Menganalisa proses bisnis
dalam koperasi.
2. Mendefinisikan prosedur
yang ada dalam sistem.
3. Membuat dokumen flow,
sistem flow.
4. Membuat dokumen SRS
yang mendefinisikan
spesifikasi kebutuhan
perangkat lunak.
I. Project Authorization
APPROVED BY: PROJECT MANAGER DATE 8 Maret 2017