Sistem ini bertujuan untuk melacak lokasi truk pengiriman barang PT. Ekspedisi Surabaya. Dokumen ini menjelaskan tujuan, lingkup, risiko, hasil yang diharapkan, jadwal, anggaran, dan struktur tim proyek sistem pelacakan truk pengiriman barang tersebut.

1. FOR INTERNAL USE ONLY
1PROJECTCHARTER
PROJECT CHARTER
PROJECT NAME
Sistem Informasi Tracking Truk
PT. Ekspedisi Surabaya
PROJECT NUMBER
PRPL/2017/II/05
DATE
5 Maret 2017
REVISION NUMBER
0.0
1. ProjectDescriptionand Goals
Bagian ini menjelaskan kebutuhan bisnis, kepentingan dan masalah dari proyek,misalnya
sampai pada justifikasi project karena kebutuhan organisasi, kebutuhan customer,
peningkatan teknologi, kebutuhan kebijakan, tujuan saving cost, maupun improvement
process.
Dari tahun ke tahun transaksijualbeli online meningkat . Mayoritas masyarakat
lebih suka membeli barang secara online daripada di toko. Hal ini berdampak
pada kebutuhan pengiriman barang antar daerah. Meningkatnya kebutuhan
pengriman barang sebanding dengan meningkatnya transaksijual beli online. PT
Ekspedisi sebagai perusahaan ekspedisi barang, kami kesulitan dalam melacak
keberadaan setiap barang yang dikirim.
Untuk mendukung kelancaran operasional, dibutuhkan aplikasi yang dapat
melacak lokasi armada pengiriman barang, yang digunakan untuk memantau
keberadaan lokasibarang yanbg dikirim. Aplikasi yang yang akan dibuat diharap
dapat memenuhi kebutuhan informasipemakai mengenai: Melihat posisisetiap
truk pengiriman yangsedang bertugas secara interaktif, Daftarbiodata karyawan
termasuk supir, Mengelola barang,Mengelola status barang, Daftar pengaduan
pembeli
2. Risks
Bagian ini menjelaskan resiko-resiko yang mungkin terjadi dalam pengerjaan proyek.
Risiko dari sistem informasi tracking truk ini telah diidentifikasi. Manajer proyek
akan menentukan dan menerapkan mitigasi risiko yang diperlukan strategi
penghindaran / sesuai untuk meminimalkan kemungkinan risiko tersebut:
 Terjadinya kebocoran data.

2. FOR INTERNAL USE ONLY
2PROJECTCHARTER
 Terjadinya kesalahan data posisi truk pengiriman akibat kesalahan sistem
dan terganggunya jaringan.
 Terjadinya kepalsuan data akibat kesalahan manusia pada saatentry data.
 Terjadinya bug pada saat proses penjalanan aplikasi yang tidak sesuai
dengan caranya.
3. Deliverables
Bagian ini menjelaskan dokumen-dokumen yang akan diberikan,meliputi: SDPLN, SRS, SAD,
test plan dan user documentation serta hasil dari perencanaan.
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 Sistem
Informasi yang akan dibuat. Rancangan sistem tersebut meliputi perkenalan
dokumen, gambaran umum proyek, struktur anggpta dalam tim proyek, proses
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 softwareyang menjelaskan bagaimana cara pengguna
berinteraksi dengan sistem, dan kebutuhan antar komunikasi.
SAD menjelaskan tentang arsitektur proyek perangkat lunak 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.

3. FOR INTERNAL USE ONLY
3PROJECTCHARTER
4. Scope Definition
Bagian ini menjelaskan ruang lingkup proyek, misalnya spesifikasi fungsi dari proyek.
Batasan dariproyek ini adalah:
 Tidak membahas tentang penggajian karyawan
 Tidak membahas tentang pembuatan laporan keuangan
Kebutuhan fungsionalyang harus ada dalam sistem yang akan dibuat ini adalah
sebagai berikut:
 Sistem harus dapatmenampilkan posisisetiap truk pengiriman yang
sedang bertugas secara real time
 Sistem harus dapatmengelola biodata karyawan diperusahaan
 Sistem harus dapatmengelola data barang
 Sistem harus dapatmengupdate status barang yang dikirim
 Sistem harus dapatmengelola pengaduan konsumen
Kebutuhan nonfungsionaladalah kebutuhan tambahan yang tidak memiliki
input, proses, dan output. Namun demikian, kebutuhan nonfungsionalini
sebaiknya dipenuhi, karena akan sangatmenentukan apakah sistem ini akan
digunakan user atau tidak.
Berdasarkan perfomancenya, sistemdiharapkan dapatmempersingkatwaktu
yang dibutuhkan untuk menyelesaikan setiap pekerjaan. Semakin sedikit waktu
yang dibutuhkan, semakin besar troughputyang dapat dihasilkan. Peningkatan
kecepatan dan troughputini diharapkan dapat terjadi pada semua
proses/pekerjaan. Besarnya peningkatan ini tergantung pada jenis
proses/pekerjaannya.
Kebutuhan nonfungsionaldari segipengontrolan sistemyang 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 bersifatconfidential.

4. FOR INTERNAL USE ONLY
4PROJECTCHARTER
Kebutuhan dari segi efisiensi yaitu sistemdiharapkan dapat mempercepat
dalam pengaksesan data dan mempermudah pihak anggota dalam mengetahui
posisibarang yang dikirim.
5. ProjectMilestones
Bagian ini menjelaskan gambaran umum jadwal proyek yang akan dikerjakan.
Project Milestone Target Tanggal (dd/mm/yyyy)
Proyek dimulai 06/03/2017
Pekerjaan analis selesai 13/03/2017
Pekerjaan desainer selesai 20/03/2017
Pengerjaan softwareselesai 16/05/2017
Simulasi dan testing selesai 31/05/2017
Instalasisoftwareselesai 3/06/2017
Pembuatan manual dan dokumen-
dokumen pendukung selesai
05/06/2017
Proyek berakhir 06/06/2017
6. Budget Summary
Bagian ini menjelaskan pembiayaan proyek secara ringkas.
PROJECT COMPONENT COMPONENT COST
Survey dan Analisa Rp. 3.750.000,00
Pembelian Komponen Sistem Rp. 26.400.000,00
Desain dan ImplementasiSistem Rp. 10.000.000,00
Biaya Lisensi Rp. 7.500.000,00
Training Aplikasi Rp. 1.000.000,00
Biaya Dokumentasidan Pembuatan
Manual Book
Rp. 3.300.000,00
Total Rp. 51.950.000,00

5. FOR INTERNAL USE ONLY
5PROJECTCHARTER
7. Assumptions,Constraints & Dependencies
Bagian ini menjelaskan hal-hal yang mendukung sistem, batasan, dan ketergantungannya
dengan sistem yang lain (jika ada).
Asumsi-asumsidariproyek ini adalah:
1. Survey dan hari bekerja dilakukan selama 1 minggu yang terdiri dari5 hari
(hariSabtu dan Minggu tidak dihitung).
2. Biaya-biaya telah ada didalam akun yang jelas dan sudah ada di Koperasi
Karyawan PT. EkspedisiSurabaya
Batasan-batasan untuk sistemini, antara lain :
1. User biasa hanya bisa melihat biodata,status pengiriman
barang,mengirimkan pengaduan
2. Admin bisa melakukan insert, update, dan delete data
3. Admin bisa memantau posisitruk pengiriman barang
8.ProjectOrganizational Structure
Bagian ini berisikan daftar anggota team/kelompok beserta fungsi dan tugas-tugasnya di
dalam team/kelompok project ini.
Function Name Role
ProjectManager Bambang Sudibyo  Menjadwalkan
pelaksanaan dan
manajemen
proyek
 Memantau
milestone proyek
 Membuat
dokumen SDPLN
yang
mendefinisikan
rencana proyek
Programmer Alexander delpiero  Membuat aplikasi
yang telahDidier Drogba

6. FOR INTERNAL USE ONLY
6PROJECTCHARTER
dirancang dan
direncanakan.
 Membuat test
plan untuk
implementasi
sistem.
 Control
keselarasan dan
kesesuaian
dengan dokumen
rancangan.
Sistem Analyst Jose Mourinho  Menganalisa
proses bisnis.
 Mendefinisikan
prosedur yang
ada dalam sistem.
 Membuat
dokumen flow,
systemflow.
 Membuat
dokumen SRS
yang
mendefinisikan
spesifikasi
kebutuhan
perangkatlunak.
Network Engineer Peter Cech  Membuat
rancangan system
dengan HIPO dan
DF
 Membuat basis
data dan ERD
Peter Parker

7. FOR INTERNAL USE ONLY
7PROJECTCHARTER
(Entity Relational
Diagram).
 Membuat
dokumen SAD
yang
mendefinisikan
arsitektur sistem.
9. ProjectAuthorization
Bagian ini berisikan persetujuan/otorisasi project yang disahkan oleh project manager dan
project sponsor.
APPROVED BY: PROJECT MANAGER
Bambang Sudibyo
DATE
06/03/2017
APPROVED BY: DIRECTOROF PT.
EKSPEDISI
Fajar Baskoro, S.Kom.,
M.T.
DATE
06/03/2017