Laporan4 Kel 17

SISTEM INFORMASI PENUNJANG
KEGIATAN MAHASISWA FASILKOM UI

MyCampus
Project Charter
Analisa & Perancangan Sistem

Fakultas Ilmu Komputer
Universitas Indonesia
[Kelompok 17]
Ardini Ridhatillah
Ihsan Wahyu P.
Indah Wulansari
M. Faizal Ardi
Ratih Kemala
(1201007029)
(1201000539)
(1201000555)
(1201000644)
(1201000873)
EXECUTIVE SUMMARY
Kemajuan teknologi di bidang telekomunikasi bergerak (mobile) seperti Wireless

Application Protocol (WAP) dan General Packet Radio Service (GPRS) di masa
depan memberikan fasilitas-fasilitas baru untuk mobile services. Dalam proposal akhir
yang telah kami revisi ini, kami ingin memperkenalkan MyCampus, sebuah AgentBased Environment Mobile Services, yang dapat membantu mahasiswa Fakultas Ilmu
Komputer Universitas Indonesia (Fasilkom UI) dalam mengambil keputusan.
Lingkungannya berkisar pada koleksi agen-agen yang dapat di-customize serta secara
otomatis atau semi-otomatis mampu menemukan dan mengakses layanan-layanan
intranet di lingkungan Fasilkom UI. Agen-agen ini dapat membantu pengguna sistem
(user) dalam mengambil keputusan terhadap tugas yang akan dilakukan selanjutnya,
misalnya seorang mahasiswa Fasilkom UI yang ingin bertemu dengan Pembimbing
Akademiknya atau mencari temannya yang sedang berada di lab mahasiswa.
Kami telah melakukan analisa untuk mengidentifikasi layanan yang dapat diberikan
oleh sistem MyCampus, yang memberikan keuntungan terhadap batasan-batasan
teknologi WAP yang telah ada saat ini. Analisa yang telah kami lakukan antara lain
adalah kegunaan dari layanan, implementasi secara prototipe, adaptasi terhadap sistem
yang sudah ada dan platform dari server demi manajemen dan keamanan. Hasil dari
itu semua akan dipaparkan dalam laporan ini.
DAFTAR ISI
EXECUTIVE SUMMARY................................................................................................i
DAFTAR ISI..................................................................................................................ii
DAFTAR GAMBAR......................................................................................................v
DAFTAR TABEL.........................................................................................................vii
BAB I PENDAHULUAN..............................................................................................1
BAB II LATAR BELAKANG ORGANISASI..............................................................2
2.1. Profil Organisasi..................................................................................................2
2.2. Visi dan Misi.......................................................................................................3
2.3. Struktur Organisasi..............................................................................................3
BAB III MATRIKS PERNYATAAN MASALAH........................................................5
3.1. PIECES Frame Work Fakultas Ilmu Komputer Universitas Indonesia.............5
3.2. Tabel Pernyataan Masalah...................................................................................7
BAB IV PROJECT CHARTER......................................................................................9
4.1. Nama Proyek.......................................................................................................9
4.2. Sasaran Proyek....................................................................................................9
4.3. Gambaran Proyek................................................................................................9
4.4. Pernyataan Masalah...........................................................................................10
4.5. Ruang Lingkup Awal Proyek.............................................................................11
4.6. Visi Proyek........................................................................................................12
4.7. Batasan Bisnis...................................................................................................12
4.8. Batasan Teknologi.............................................................................................13
4.9. Strategi Proyek..................................................................................................13
4.10. Dokumentasi dan Komunikasi Proyek............................................................14
4.11. Organisasi dan Staf Proyek.............................................................................15
BAB V ANALISA PERMASALAHAN......................................................................16
5.1. Analisa Permasalahan dan Peluang..................................................................16
5.1.1. Ishikawa Diagram......................................................................................16
5.1.2. Cause-and-Effect Analysis.........................................................................19
5.2. Analisa Proses Bisnis.......................................................................................21
5.2.1. ER Diagram sistem yang sedang berjalan..................................................21
5.2.2. DFD sistem yang sedang berjalan..............................................................26
5.2.2.1. DFD Level 0........................................................................................26
5.2.2.2. DFD Level 1........................................................................................27
5.2.2. Diagram antar muka sistem yang sedang berjalan.....................................29
5.3. Objektivitas Peningkatan Sistem.......................................................................31
ii
BAB VI ANALISA KEBUTUHAN............................................................................35

6.1. Kebutuhan Fungsional.......................................................................................35
6.2. Kebutuhan Non-Fungsional..............................................................................36
6.3. Prioritas Kebutuhan Fungsional........................................................................38
BAB VII LOGICAL DESIGN......................................................................................39
7.1. Model Data........................................................................................................39
7.2. Model Proses.....................................................................................................43
7.2.1. DFD Level 0...............................................................................................43
7.2.2. DFD Level 1...............................................................................................46
7.2.3. DFD Level 2...............................................................................................48
7.3. Model Antar Muka............................................................................................50
BAB VIII ANALISA KEPUTUSAN...........................................................................54
8.1. Candidate Systems Matrix.................................................................................54
8.2. Feasibility Analysis Matrix...............................................................................56
8.3. Feasibility Analysis...........................................................................................58
8.3.1. Kandidat 1 (sistem yang sudah ada)...........................................................59
8.3.2. Kandidat 2..................................................................................................61
8.3.3. Kandidat 3..................................................................................................65
BAB IX PHYSICAL DESIGN......................................................................................67
9.1. Hasil Pemetaan ER Diagram.............................................................................67
9.2. Physical Data Flow Diagram (PDFD)..............................................................71
9.2.1. PDFD sistem keseluruhan..........................................................................71
9.2.2. PDFD Schedule Service.............................................................................74
9.3. Interface Design WML.....................................................................................77
9.3.1. Form Login.................................................................................................77
9.3.2. Menu Utama...............................................................................................78
9.3.3. Layanan Akademis.....................................................................................78
9.3.4. Layanan Dosen...........................................................................................80
9.3.5. Layanan Sesama Mahasiswa......................................................................81
9.3.6. Layanan Lab...............................................................................................83
9.3.7. Layanan Seputar Kampus...........................................................................84
9.4. Interface Design HTML....................................................................................87
9.4.1. Halaman Perubahan Jadwal Dosen............................................................87
9.4.2. Halaman Pengisian Kehadiran Dosen........................................................88
9.4.3. Halaman Pengisian Kegiatan Kampus (Event)..........................................89
9.4.4. Halaman Perubahan Jadwal Mahasiswa....................................................90
BAB X MANAJEMEN PROYEK...............................................................................91
10.1. Identifikasi Fase Pengerjaan Proyek...............................................................91
10.2. Estimasi Waktu Pengerjaan Proyek.................................................................94
iii
10.3. Definisi Keterkaitan Antarfase........................................................................94

10.4. Pengalokasian Sumber Daya...........................................................................95
10.5. Work Breakdown Structure..............................................................................96
10.6. Estimasi Biaya Proyek....................................................................................99
DAFTAR PUSTAKA.................................................................................................101
iv
DAFTAR GAMBAR
Gambar 1. Struktur Organisasi.......................................................................................4

Gambar 2. Struktur organisasi dan staf proyek............................................................15
Gambar 3. Ishikawa diagram 1....................................................................................16
Gambar 7. ERD sistem yang sudah ada.......................................................................22
Gambar 8. DFD level 0 sistem yang sudah ada............................................................26
Gambar 9. DFD level 1 sistem yang sudah ada............................................................27
Gambar 10. Diagram antar muka sistem yang sudah ada (mahasiswa).......................29
Gambar 11. Diagram antar muka sistem yang sudah ada (pegawai sekretariat)..........30
Gambar 12. ERD skema pada sistem yang akan dikembangkan.................................40
Gambar 13. DFD level 0..............................................................................................43
Gambar 14. DFD level 1..............................................................................................46
Gambar 15. DFD level 2 proses Schedule Service.......................................................48
Gambar 16. Diagram antar muka sistem yang baru (mahasiswa)................................50
Gambar 17. Diagram antar muka sistem yang baru (staf)............................................51
Gambar 18. Diagram antar muka sistem yang baru (pegawai sekretariat)..................52
Gambar 19. Diagram antar muka sistem yang baru (dosen)........................................53
Gambar 20. Hasil pemetaan ERD................................................................................67
Gambar 21. PDFD sistem keseluruhan........................................................................71
Gambar 22. PDFD Schedule Service............................................................................74
Gambar 23. Halaman login..........................................................................................77
Gambar 24. Halaman menu utama...............................................................................78
Gambar 25. Halaman layanan akademis......................................................................78
Gambar 26. Halaman jadwal kuliah.............................................................................79
Gambar 27. Halaman informasi nilai akademis pengguna...........................................79
Gambar 28. Halaman layanan informasi mengenai dosen...........................................80
Gambar 29. Halaman layanan jadwal dosen................................................................80
Gambar 30. Halaman layanan informasi kehadiran dosen...........................................81
Gambar 31. Halaman informasi mengenai rekan mahasiswa lain...............................81
Gambar 32. Halaman informasi jadwal rekan mahasiswa lain....................................82
Gambar 33. Halaman informasi kehadiran rekan mahasiswa lain di kampus..............82
Gambar 34. Halaman layanan informasi lab mahasiswa.............................................83

Gambar 35. Halaman informasi pengguna lab mahasiswa..........................................83
Gambar 36. Halaman informasi statistik lab................................................................84
Gambar 37. Halaman layanan informasi kegiatan kampus..........................................84
Gambar 38. Halaman informasi kegiatan kampus.......................................................85
Gambar 39. Halaman informasi e-mail header pengguna...........................................85
Gambar 40. Halaman informasi news header..............................................................86
Gambar 41. Halamn untuk mengubah jadwal dosen....................................................87
Gambar 42. Halaman pengisian kehadiran dosen........................................................88
Gambar 43. Halaman pengisian kegiatan kampus (event)...........................................89
Gambar 44. Halaman untuk mengubah jadwal mahasiswa..........................................90
vi
DAFTAR TABEL
Tabel 1. Pernyataan masalah..........................................................................................8

Tabel 2. Staf proyek......................................................................................................15
Tabel 3. Analisa hubungan sebab dan akibat................................................................21
Tabel 4. Keterangan entity pada ERD..........................................................................23
Tabel 5. Objektivitas peningkatan sistem.....................................................................32
Tabel 6. Kebutuhan non-fungsional.............................................................................37
Tabel 7. Prioritas kebutuhan fungsional.......................................................................38
Tabel 8. Keterangan ERD sistem yang baru.................................................................41
Tabel 9. Candidate system matrix................................................................................55
Tabel 10. Feasiblity analysis matrix.............................................................................56
Tabel 11. Pengalokasian sumber daya staf...................................................................96
Tabel 12. Work breakdown structure............................................................................98
Tabel 13. Complexity adjustment values......................................................................99
Tabel 14. Computing function point metrics..............................................................100
vii
BAB I
PENDAHULUAN
Saat ini puluhan juta peralatan mobile memiliki kemampuan berbasis internet. Mobile
internet membuka peluang baru untuk penerapan beberapa aplikasi dan layanan
mobile yang akan membantu user dalam menyelesaikan tugas-tugasnya secara efisien
dan efektif. Dewasa ini, telah banyak masyarakat yang menggunakan fasilitas-fasilitas
ekstra yang ditawarkan oleh telepon selular seperti GPRS, Bluetooth dan sebagainya.
Pengembangan terbaru dari teknologi telekomunikasi tersebut memberikan fasilitasfasilitas baru untuk pengguna telepon selular, bahkan untuk kalangan mahasiswa
Fasilkom UI. Dalam rangka meningkatkan infrastruktur untuk mahasiwa, setiap
teknologi baru yang hadir harus dipelajari kemungkinan penggunaannya dalam
kehidupan sehari-hari. Dalam kasus Wireless Application Protocol (WAP), sebuah tim
telah dibentuk untuk menyelidiki layanan-layanan inovatif berdasarkan teknologi ini.
Pada versi terakhir WAP (2.0) bersama implementasinya pada standar Global System
for Mobile Communication (GSM) telepon selular (ponsel) memberikan fasilitas yang
sangat terbatas seperti keterbatasan bandwidth yang hanya 9600 bit/sec dan resolusi
layar yang hanya 50 * 100 piksel. Oleh karena itu kami harus membuat penelitian
lebih lanjut mengenai kegunaan layanan ini.
Tim yang dibentuk untuk pengembangan bidang ini terdiri atas beberapa mahasiswa
Fakultas Ilmu Komputer yang sedng mengikuti mata kuliah Analisa dan Perancangan
Sistem pada semester genap 2003/2004. Tetapi pengembangan sistem ini tetap berada
di bawah naungan Unit Pelaksana Teknis Pusat Komputer (UPT Puskom) UI.
BAB II
LATAR BELAKANG ORGANISASI
2.1. Profil Organisasi

Pada tahun 1972, dilaksanakan pembentukan Pusat Ilmu Komputer (Pusilkom) UI
sebagai wahana pengembangan Ilmu Komputer di Indonesia khususnya di Universitas
Indonesia [UPT02].
Namun, pada tahun 1983 terjadi perubahan bentuk organisasi menjadi Unit Pelaksana
Teknis (UPT). Berdasarkan SK Mendikbud Nomor 0130/O/1983 mengenai Organisasi
dan Tata Kerja Universitas Indonesia, dibentuklah UPT Komputer UI, yang kemudian
berubah nama menjadi UPT Pusat Komputer (Puskom) UI. Sejalan dengan hal ini
maka Pusilkom UI secara fungsional menjadi Pelaksana Unit Organik UPT Komputer
UI, dan Kepala UPT dirangkap oleh Direktur Pusilkom.
Pada perkembangannya, Program Studi Ilmu Komputer (Prosilkom) UI yang telah
dibuka oleh Pusilkom UI sejak tahun 1986 secara resmi menjadi Fakultas Ilmu
Komputer (Fasilkom) UI pada tanggal 21 Oktober 1993 berdasarkan SK Mendikbud
Nomor 0370/O/1993. Seiring dengan perkembangan ini, pada tahun 1997 dilakukan
pemisahan jabatan Kepala UPT Puskom UI dengan Direktur Pusilkom UI. Sejak saat
itulah dilakukan serangkaian program restrukturisasi organisasi dan kegiatan sehingga
terbentuk UPT Puskom UI seperti saat ini.
Berdasarkan SK Mendikbud Nomor 0205/O/1995 tentang Organisasi dan Tata Kerja
Universitas Indonesia, kedudukan, tugas dan fungsi UPT Puskom UI adalah sebagai
berikut. Kedudukan UPT Puskom UI adalah sebagai unit pelaksana teknis di bidang
pengolahan data. Tugas UPT Puskom UI adalah mengumpulkan, mengolah,
menyajikan dan menyimpan data dan informasi serta menyediakan pelayanan untuk
program-program pendidikan, penelitian dan pengabdian kepada masyarakat. Fungsi
UPT Puskom UI terdiri dari tiga hal yaitu:
1. Mengumpulkan dan mengolah data dan informasi.

2. Menyajikan dan menyimpan data dan informasi.
3. Melakukan tata usaha komputer.
Untuk menunjang kelancaran tugasnya, UPT Puskom UI memiliki tiga kelompok
tenaga teknis yang meliputi Kelompok Pengelola Sistem Komputer, Kelompok
Pengelola Jaringan Komputer, serta Kelompok Pengelola Sistem Informasi.
2.2. Visi dan Misi

Mengembangkan Ilmu Komputer di Indonesia, khususnya di Universitas Indonesia
dengan menciptakan sarjana Ilmu Komputer yang handal dan dapat berperan dalam :
1. Penelitian dan pengembangan perangkat lunak komputer.
2. Pengembangan aplikasi dan bidang penelitian untuk memecahkan masalahmasalah yang dihadapi di dalam dunia industri dan rekayasa.
Melakukan pengembangan dan penerapan sistem informasi yang diperlukan oleh
suatu organisasi untuk dapat menjalankan fungsinya secara baik dan efisien.
2.3. Struktur Organisasi

Struktur organisasi dari UPT Puskom UI tertera pada gambar 1. Pada gambar tersebut
dapat dilihat bahwa organisasi UPT Puskom UI terdiri dari Kepala UPT Puskom UI,
Kelompok Tenaga Ahli, Sub Bagian Tata Usaha, Kelompok Pengelola Sistem
Komputer, Kelompok Pengelola Jaringan Komputer, dan Kelompok Pengelola Sistem
Informasi [UPT02].
Gambar 1. Struktur Organisasi
BAB III
MATRIKS PERNYATAAN MASALAH
3.1. PIECES Frame Work Fakultas Ilmu Komputer Universitas Indonesia
1. Model Tampilan (Performance)
a. Sistem yang sudah ada, baik informasi nilai, e-mail maupun news, hanya bisa
diakses secara konvensional.
b. Sulitnya mendapatkan informasi baik mengenai jadwal maupun ketersediaan
staf Fakultas Ilmu Komputer Universitas Indonesia saat ini.
c. Tidak adanya informasi baik mengenai jadwal maupun ketersediaan seorang
mahasiswa Fakultas Ilmu Komputer Universitas Indonesia saat ini.
d. Ketersediaan komputer di lab mahasiswa dan penggunanya hanya bisa dilihat
secara konvensional (datang langsung).
e. Pengumuman penting hanya dapat diketahui saat mahasiswa berada di
kampus.
2. Model Penyimpanan Informasi (Information)
a. Informasi mengenai jadwal kuliah dan nilai mahasiswa masih disimpan secara
manual oleh dosen pengajar yang bersangkutan dan ditempel di mading
Fakultas Ilmu Komputer Universitas Indonesia.
b. Infomasi mengenai jadwal dosen masih bersifat manual dengan ditempel di
pintu ruangan dosen yang bersangkutan. Selain itu, informasi kehadiran dosen
hanya tersimpan secara manual, yaitu dalam daftar kehadiran dosen di meja
satpam gedung A lantai 1 Fakultas Ilmu Komputer Universitas Indonesia.
c. Tidak ada sedikit pun informasi mengenai jadwal rekan sesama mahasiswa.
d. Belum tersedianya informasi mengenai ketersediaan komputer di lab
mahasiswa dan penggunanya.
e. Informasi pengumuman penting hanya dapat dilihat melalui mading maupun
forum internal.
3. Segi Ekonomi (Economic)

a. Biaya dan waktu yang dikeluarkan oleh seorang mahasiswa untuk pergi ke
kampus cukup besar.
b. Biaya yang dikeluarkan untuk mengakses internet secara konvensional (misal
warnet) lebih besar dibanding mengakses melalui GPRS.
4. Model Pengontrolan Sistem (Control)
a. Privasi data dapat dilanggar dengan mudah. Misalnya, siapapun dapat melihat
nilai yang dicapai oleh seorang mahasiswa yang ditempel di mading.
b. Tidak terdapat pihak yang dapat bertanggungjawab atas kesalahan
penyampaian informasi. Misalnya, siapapun dapat menambah, mengubah atau
menghilangkan informasi yang ditempel di mading.
5. Efisiensi Sistem (Efficiency)
Adanya data yang redundant. Misalnya, sebuah informasi yang sama ditempel di
mading di berbagai lokasi yang berbeda. Hal yang sulit adalah menjaga
kekonsistensian jika informasi tersebut harus diperbaharui.
6. Model Pelayanan Sistem (Service)
a. Model pelayanan sistem yang ada sekarang ini dinilai kurang efisien. Kita
ambil contoh ketika seorang mahasiswa yang datang untuk kuliah, sedangkan
mahasiswa tersebut memiliki rumah yang cukup jauh dari kampus. Namun
pada saat ia tiba di kampus ternyata dosen yang bersangkutan tidak hadir
sehingga kuliah ditiadakan. Setelah kami telaah lebih dalam lagi, ternyata
kejadian demikian sangat merugikan mahasiswa baik dari segi efisiensi waktu,
uang, dan tenaga.
b.
Secara keseluruhan model pelayanan yang ada kami nilai masih jauh
dari kata efisien mengingat masih banyak lagi perbaikan yang dapat dilakukan
untuk memperbaiki kualitas pendayagunaan waktu, uang, dan tenaga pihakpihak kampus.
3.2. Tabel Pernyataan Masalah

PERNYATAAN MASALAH
PROYEK: MyCampus
MANAJER PROYEK: M Faizal Ardi
DISUSUN OLEH: Ardini Ridhatillah
PENYESUAIAN TERAKHIR OLEH: Ratih Kemala
TANGGAL PENYUSUNAN: 29/ 02/ 2004
TANGGAL PENYESUAIAN TERAKHIR: 20/ 03/ 2004
No.
Pernyataan Singkat dari

Masalah atau Peluang
Tingkat
Kepentingan
Visibilitas
Peringkat
1.
Mahasiswa tidak bisa

mendapatkan informasi
(khususnya mengenai
kalender akademis, jadwal
kuliah, nilai-nilai
mahasiswa, jadwal dan
kehadiran dosen,
ketersediaan komputer di
lab mahasiswa, serta
pengumuman-pengumuman
lain yang diposting di
forum) yang dibutuhkan
kapanpun dan di manapun ia
membutuhkannya (di dalam
maupun di luar kampus).
4 Bulan
Tinggi
Solusi yang Ditawarkan

Mengembangkan sistem
yang sudah ada
(https://lasiana.ui.ac.id)
dengan menambahkan
beberapa layanan baru,
seperti membuatnya
sebagai webpage yang
berbasiskan WAP.
Selain itu akan
dikembangkan sistem yang
memberikan informasi lain
yang relevan dengan
kebutuhan umum
mahasiswa (khususnya
mengenai kalender
akademis, jadwal kuliah,
nilai-nilai mahasiswa,
jadwal dan kehadiran
dosen, ketersediaan
komputer di lab
mahasiswa, serta
pengumumanpengumuman lain yang
diposting di forum) dalam
bentuk webpage yang
berbasiskan WAP.
No.
Pernyataan Singkat dari

Masalah atau Peluang
Tingkat
Kepentingan
Visibilitas
Peringkat
Solusi yang Ditawarkan
2.
Ketidakefisienan mahasiwa
dari segi tenaga, waktu, dan
biaya untuk mengakses
informasi seputar
perkuliahan (akademis dan
non-akademis).
4 Bulan
Tinggi
alternatif yang dapat
diakses dengan biaya lebih
rendah dibandingkan
dengan mengakses internet
melalui PC dan
mengembangkan sistem
yang dapat melihat
header/subject dari berita
di forum dan e-mail,
kehadiran dosen, serta
ketersediaan tempat kosong
dil lab dalam bentuk
webpage yang berbasiskan
WAP.
3.
Kesulitan dalam
mendapatkan informasi
antara sesama rekan
mahasiswa.
3 Bulan
Sedang
yang menyediakan
informasi mengenai jadwal
dan kehadiran mahasiswa
dalam bentuk webpage
yang berbasiskan WAP.
4.
Pengelolaan data akademis

dan informasi kegiatan
mahasiswa yang kurang
baik dengan sistem yang
sudah ada.
3 Bulan
Sedang
Mengembangkan dan
mengoptimalkan fungsi
sistem digital yang sudah
ada agar lebih mudah
dalam hal update data dan
redundancy data dapat
dihindari.
Tabel 1. Pernyataan masalah
BAB IV
PROJECT CHARTER
4.1. Nama Proyek

Sistem informasi penunjang kegiatan mahasiswa Fasilkom UI MyCampus, sebuah
Agent-Based Environment Mobile Services.
4.2. Sasaran Proyek

Sasaran dari pengguna sistem ini adalah pihak-pihak yang berkepentingan dalam
sistem perkuliahan dan yang terlibat dalam aktivitas seputar kampus, yaitu mahasiswa
dan staf pengajar Fakultas Ilmu Komputer Universitas Indonesia yang memiliki
keterkaitan secara langsung dan tidak langsung dalam kegiatan akademis. Dengan
menggunakan program berteknologi WAP yang didukung dengan fasilitas GPRS dari
telepon selular yang kian menjamur penggunaannya, sistem MyCampus dinilai
sangat berguna untuk efisiensi segenap pihak-pihak yang berkepentingan dalam
perihal akademik dan aktivitas seputar kampus. Masalah efisiensi ini terdiri dari tiga
aspek, yaitu aspek waktu, tenaga, dan biaya. Melalui sistem MyCampus, pengguna
dapat melihat status dari suatu hal yang berkaitan dengan masalah akademika kampus
setempat. Dengan demikian pengguna dapat menghemat biaya dan tenaga yang
dikeluarkan untuk pergi ke kampus karena sistem ini dapat diakses di mana saja dan
kapan saja.
4.3. Gambaran Proyek

Pelaksanaan proyek ini diawali dengan menganalisa sistem informasi akademis
Fakultas Ilmu Komputer Universitas Indonesia yang sudah ada, baik informasi nilai
(https://lasiana.ui.ac.id), e-mail dan news yang sudah ada, antara lain dengan
mempelajari cara kerja sistem informasi tersebut dan menganalisa data-data yang
dibutuhkan untuk mengembangkan sistem tersebut. Setelah menganalisa, langkah
selanjutnya adalah mengumpulkan data-data dan informasi yang dibutuhkan untuk

dijadikan sebagai input dari sistem infomasi penunjang kegiatan mahasiswa Fasilkom
UI yang kami kembangkan.
Pelaksanaan proyek ini akan dilanjutkan dengan menyiapkan alat-alat ataupun
komponen yang dibutuhkan untuk mengembangkan sistem tersebut, kemudian setelah
semua persiapan telah selesai, kami akan mulai mengimplementasikannya.
Hasil dari proyek ini adalah sebuah sistem informasi penunjang kegiatan mahasiswa
Fakultas Ilmu Komputer Universitas Indonesia. Sistem yang kami kembangkan ini
tidak jauh berbeda dengan yang sudah ada, namun kami membuat sistem informasi
tersebut dalam webpage yang berbasiskan WAP. Selain itu kami menambahkan
beberapa layanan baru, yaitu layanan informasi dosen, mahasiswa dan statistik
pengguna lab mahasiswa.
4.4. Pernyataan Masalah

Alasan dari pengembangan sistem informasi penunjang kegiatan mahasiswa Fakultas
Ilmu Komputer Universitas Indonesia (MyCampus) ini adalah demi memberikan
kemudahan-kemudahan untuk mahasiswa. Setelah melakukan analisa mengenai
kendala yang ada dalam kegiatan mahasiswa, kami mendapatkan beberapa masalah
seperti:
1. Mahasiswa tidak bisa mendapatkan informasi (khususnya mengenai kalender
akademis, jadwal kuliah, nilai-nilai mahasiswa, jadwal dan kehadiran dosen,
ketersediaan komputer di lab mahasiswa, serta pengumuman-pengumuman
lain yang ada di forum) yang dibutuhkan kapanpun dan di manapun ia
membutuhkannya (di dalam maupun di luar kampus).
2. Ketidakefisienan mahasiwa dari segi tenaga, waktu, dan biaya untuk
mengakses informasi seputar perkuliahan (akademis dan non-akademis).
3. Kesulitan dalam mendapatkan informasi antara sesama rekan mahasiswa.
4. Pengelolaan data akademis dan informasi kegiatan mahasiswa yang kurang
baik dengan sistem yang sudah ada.
10
4.5. Ruang Lingkup Awal Proyek

Ruang lingkup dari sistem yang kami kembangkan dalam MyCampus ini meliputi:
1. Mahasiswa dapat melihat informasi nilai yang dicapai pada suatu mata kuliah
secara detil dan transparan. Staf pengajar memiliki kewajiban untuk membuat
informasi ini.
2. Mahasiswa dapat melihat jadwal perkuliahan.
3. Mahasiswa dapat melihat header email yang baru masuk maupun header news
dengan entry terbaru.
4. Mahasiswa dapat melihat informasi jadwal maupun kehadiran seorang dosen
saat ini.
5. Mahasiswa dapat melihat informasi jadwal maupun kehadiran mahasiswa lain
saat ini. Mahasiswa tersebut juga bisa membuat jadwalnya sendiri.
6. Aplikasi statistik lab. Kegunaan dari proses ini adalah pengguna dapat mencari
orang yang dimaksud dalam lingkungan lab saja. Pada proses ini, sistem
secara otomatis akan memperlihatkan daftar mahasiswa yang sedang login
pada komputer yang berada di dalam lab. Selain itu pengguna dapat
mengetahui jumlah pemakai lab (hal ini dapat menjadi pertimbangan bagi
pengguna untuk mengunjungi lab atau tidak). Fasilitas lain yang mendukung
aplikasi statistik lab ini adalah pengiriman pesan.
7. Aplikasi pemberitahuan pengumuman maupun event-event yang berlangsung
di lingkungan kampus. Apabila dianalogikan dengan aplikasi yang ada pada
telepon selular, aplikasi ini memilki kemiripan dengan reminder yang ada pada
kebanyakan telepon selular. Pemberitahuan mencakup event apa yang
berlangsung, kapan berlangsung, dan dimana berlangsung. Secara tidak
langsung aplikasi ini mengajak mahasiswa untuk turut serta dalam setiap acara
yang diadakan di kampus.
11
4.6. Visi Proyek

Adapun visi yang ingin kami raih dalam akhir pembuatan proyek ini adalah :
1. Mengingkatkan efisiensi pada tiga aspek terpenting, yaitu tenaga, waktu, dan
biaya bagi para mahasiswa.
2. Meningkatkan dukungan terhadap peran mahasiswa dalam hubungannya
dengan mahasiswa lain, dosen, fasilitas lab, kuliah dan kehidupan kampus.
3. Merangsang mahasiswa untuk berperan aktif dalam setiap event yang
berlangsung di kampus.
4. Mengurangi terjadinya kesalahpahaman dari mahasiswa mengenai rincian nilai
akhir dan juga terjadinya transparansi di kalangan mahasiswa dan dosen.
5. Efisiensi ini juga mencakup tidak hanya pada sistem perjadwalan dan
kehadiran dosen saja, melainkan juga dalam penggunaan komputer di lab.
6. Meningkatkan kepercayaan mahasiswa terhadap sistem akademik Fakultas
Ilmu Komputer Universitas Indonesia.
7. Meningkatkan kinerja dan reabilitas sistem Sarana Akademis (sarak) UI
dengan memanfaatkan teknologi yang sedang populer di kalangan pengguna
IT, yaitu teknologi WAP dan GPRS. Dari hal ini pula kami mengharapkan
adanya suatu nilai prestise lebih pada Fasilkom UI dibanding dengan kampus
lain.
4.7. Batasan Bisnis

1. Prototipe sistem yang telah kami kembangkan ini dapat diberikan kepada
sarak Fasilkom UI pada jangka waktu yang telah ditentukan untuk dijadikan
revisi atau feature tambahan yang mungkin diperlukan dalam pengembangan
lebih lanjut.
2. Tingkat keamanan merupakan skala prioritas tertinggi dalam pengembangan
sistem mengingat sistem tersebut hanya dapat diakses terbatas oleh pihak
mahasiswa saja.
12
3. Sistem lebih bersifat user friendly, karena sistem menggunakan tampilan yang
tidak jauh berbeda dengan tampilan-tampilan pada telepon selular.
4.8. Batasan Teknologi

Sistem informasi penunjang kegiatan mahasiswa Fakutas Ilmu Komputer Universitas
Indonesia ini harus memenuhi beberapa kriteria teknologi seperti:
1. Berjalan di atas sistem operasi Linux, yang dipilih karena reliable, cepat,
aman, compatible dan mudah dikonfigurasikan dengan sistem yang telah ada.
2. Menggunakan sistem otentikasi berbasiskan Lightweight Directory Access
Protocol (LDAP).
3. Menggunakan Apache webserver.
4. Database Management System (DBMS) menggunakan Oracle.
5. Bahasa pemograman PHP.
6. Desain interface menggunakan Wireless Markup Language (WML).
4.9. Strategi Proyek

Strategi pengembangan proyek menggunakan Framework for Systems Technics
(FAST) Methodology dengan beberapa fase tertentu. Adapun pelaksanaan dari
keseluruhan fase ini akan dijelaskan lebih lanjut pada bab Manajemen Proyek.
13
4.10. Dokumentasi dan Komunikasi Proyek

Berikut ini adalah petunjuk yang akan digunakan sebagai sarana dokumentasi dan
komunikasi proyek:
1. Project Team akan mengadakan pertemuan rutin setiap satu minggu sekali
untuk
membahas
mekanisme
proses
bisnis
yang
sedang
berjalan,
perkembangan dari implementasi yang telah dilakukan oleh Programmer dan

System Analyst, serta mengenai quality assurance management. Pada
pertemuan ini, Project Manager dan System Analyst akan memberikan
subrequirement berikutnya yang harus dipenuhi.
2. Jika dirasa diperlukan, Project Team baik secara keseluruhan atau hanya
bagian-bagian tertentu dapat mengadakan pertemuan di luar pertemuan rutin.
3. System Owner dan Project Team secara keseluruhan akan mengadakan
pertemuan setiap satu bulan sekali selama minimal dua jam untuk membahas
mengenai arah perkembangan dari proyek yang telah dilaksanakan, hambatan
yang dihadapi, resiko yang terjadi serta solusi yang ditawarkan.
4. Documentator membuat notulen untuk setiap pertemuan yang telah disebutkan
pada butir 1 sampai dengan 3.
5. Project Team dapat menggunakan sarana e-mail, telepon biasa, dan telepon
genggam sebagai sarana komunikasi.
14
4.11. Organisasi dan Staf Proyek
Gambar 2. Struktur organisasi dan staf proyek
No.
JABATAN
PEMEGANG JABATAN
1.
System Owner
Sarak Fasilkom UI
2.
Project Manager
M. Faizal Ardi, MFA
3.
Programmer
Ihsan Wahyu, IW
4.
System Analyst
Ratih Kemala, RK
5.
Designer
Indah Wulansari, IWS
6.
Bussiness Process System Analyst
Ardini Ridhatillah, AR
7.
Database Administrator
Ihsan Wahyu, IW
8.
Documentator
Ardini Ridhatillah, AR
9.
Debugger dan Tester
Indah Wulansari, IWS dan Ratih Kemala, RK

Tabel 2. Staf proyek
15
BAB V
ANALISA PERMASALAHAN
5.1. Analisa Permasalahan dan Peluang
5.1.1. Ishikawa Diagram
1. Ishikawa Diagram untuk permasalahan 1
Gambar 3. Ishikawa diagram 1
16
17
18
5.1.2. Cause-and-Effect Analysis

PROYEK: MyCampus
Analisa Sebab dan Akibat

Masalah dan Peluang
1. Mahasiswa tidak bisa mendapatkan

informasi (khususnya mengenai
kalender akademis, jadwal kuliah,
nilai-nilai mahasiswa, jadwal dan
kehadiran
dosen,
ketersediaan
komputer di lab mahasiswa, serta
pengumuman-pengumuman
lain
yang diposting di forum) yang
dibutuhkan kapanpun dan di
manapun ia membutuhkannya (di
dalam maupun di luar kampus).
Sebab dan Akibat
1.
Sistem Informasi Akademis

yang sudah ada belum tersedia yang
bersifat mobile.
2.
Informasi mengenai kalender

akademis, jadwal kuliah, dan nilai-nilai
mahasiswa masih disimpan secara
manual oleh dosen pengajar yang
bersangkutan dan ditempel di mading
ataupun
dapat
dilihat
secara
konvensional melalui sistem yang sudah
ada (https://lasiana.ui.ac.id).
3.
Informasi mengenai jadwal

dan kehadiran dosen masih dilakukan
secara manual (harus ditanyakan ke
satpam).
4.
Ketersediaan komputer di lab

mahasiswa dan penggunanya hanya
dapat diketahui secara konvensional
(melihat langsung lab tersebut).
5.
Informasi
mengenai
pengumuman penting hanya dapat
dilihat melalui mading maupun forum
internal. Bagi mahasiswa yang sibuk
atau tidak memiliki banyak waktu untuk
melihat pengumuman di mading atau
forum internal, sangat berkemungkinan
akan ketinggalan berita penting yang
hanya ada di mading atau forum internal
tersebut.
19

Masalah dan Peluang
2. Ketidakefisienan mahasiwa dari segi

tenaga, waktu, dan biaya untuk
mengakses
informasi
seputar
perkuliahan (akademis dan nonakademis).
1.
Sebab dan Akibat
Bagi mahasiswa yang sedang

tidak berada di lingkungan kampus dan
membutuhkan informasi akademis, biaya
yang dikeluarkan untuk mengakses
internet secara konvensional (misal
warnet)
lebih
besar
dibanding
mengakses melalui GPRS.
2. Untuk mahasiswa yang memiliki

kepentingan dengan dosen, dan ternyata
dosen tersebut tidak hadir, berarti tenaga
dan waktunya telah terbuang percuma
tanpa hasil apa pun. Selain itu, bagi
mahasiswa yang harus berkendaraan
untuk ke kampus, berarti biaya juga telah
terbuang percuma.
3.
Belum tentu e-mail yang

masuk atau berita di forum merupakan
sesuatu yang penting dan berguna bagi
orang yang bersangkutan (akan lebih
baik jika dapat dicek header-nya dahulu
sehingga jika ternyata berita yang ada
tidak terlalu penting, maka tidak perlu
membukanya).
4.
Mahasiswa sering kali harus

menyediakan waktunya secara khusus
untuk datang ke lab untuk melihat
apakah ada tempat kosong atau tidak.
Jika tidak ada tempat kosong, berarti
tenaga dan waktu telah terbuang
percuma.
20

Masalah dan Peluang
3.
Kesulitan
mendapatkan
informasi
sesama rekan mahasiswa.
dalam
antara
Sebab dan Akibat
1. Belum tersedianya informasi mengenai

jadwal dan kehadiran mahasiswa.
2. Jika seorang mahasiswa memiliki
kepentingan yang mendesak dengan
mahasiswa lain, maka akan sulit untuk
mengetahui keberadaannya.
4.
Pengelolaan
data
akademis dan informasi kegiatan
mahasiswa yang kurang baik dengan
sistem yang sudah ada.
1. Dapat terjadi data yang redundant dan

tidak konsisten jika informasi tersebut
harus diperbaharui. Misalnya, sebuah
informasi yang sama ditempel di mading
di berbagai lokasi yang berbeda.
2. Publikasi data yang kurang baik,
sehingga privasi data dapat dilanggar
dengan mudah. Misalnya, siapapun dapat
melihat nilai yang dicapai oleh seorang
mahasiswa yang ditempel di mading.
Tabel 3. Analisa hubungan sebab dan akibat
5.2. Analisa Proses Bisnis

5.2.1. ER Diagram sistem yang sedang berjalan
Untuk menggambarkan skema data-data yang diperlukan dalam sistem yang sudah
ada, kami menggunakan data model Entity Relationship Diagram (ERD). Sistem yang
sudah ada ini menggunakan proses otentikasi dari fasilitas yang telah disediakan oleh
LDAP, sedangkan data-datanya disimpan dalam suatu database tersendiri yang
dikelola oleh tim sarak Fasilkom UI, untuk selanjutnya database tersebut kami
namakan database SIAK.
Kami telah merevisi ERD pada sistem yang sedang berjalan ini, sehingga tidak lagi
seperti yang ada pada proposal-proposal sebelumnya. Hal ini dikarenakan kesalahan
21
kami dalam menganalisa sistem yang sedang berjalan sebelumnya. Berikut ini gambar
skema ERD pada sistem yang sedang berjalan.
Gambar 7. ERD sistem yang sudah ada
22
Entity
Keterangan
Mahasiswa
Data-data yang berisi daftar mahasiswa Fakultas Ilmu Komputer

Universitas Indonesia.
Mata kuliah
Data-data yang berisi daftar mata kuliah yang ditawarkan Fakultas Ilmu
Komputer Universitas Indonesia.
Dosen
Data-data yang berisi daftar dosen Fakultas Ilmu Komputer Universitas

Indonesia
Statistik
Data-data yang berisi mengenai statistik informasi akademis mahasiswa.
Jadwal
Data-data yang berisi informasi kegiatan perkuliahan mahasiswa dan dosen

Tabel 4. Keterangan entity pada ERD
Keterangan atribut:
Mahasiswa
KD_MHS
KD_PRG_STUDI
KD_FAK
NM_MHS
: nomor pokok mahasiswa dari tiap mahasiswa

: kode program studi yang diambil oleh mahasiswa
: kode fakultas
: nama mahasiswa
Mata kuliah
kd_mk
kd_fak
kd_jur
nm_mk
nm_singkat_mk_ind
nm_singkat_mk_ing
jml_sks
: kode mata kuliah

: kode fakultas
: kode jurusan
: nama mata kuliah
: nama singkat mata kuliah dengan bahasa Indonesia
: nama singkat mata kuliah dengan bahasa Inggris
: jumlah sks
Dosen
NM_DOSEN
NIP
KD_JUR
KD_FAK
: nama dosen
: nomor induk pegawai (dosen)
: kode jurusan
: kode fakultas
Statistik
tahun
sms
kd_mhs
kd_st_akademis
jml_mk
: tahun ajaran yang sedang dijalani mahasiswa

: keterangan semester
: kode mahasiwa (NPM)
: kode status akademis
: keterangan jumlah mata kuliah yang diambil oleh mahasiswa
23
jsks
jskso
jms
jsksko
jmk
jsksk
jskskos
jsksks
jmks
ips
ipk
ipks
sms_ke
flag_ip
: jumlah sks yang telah/sedang diambil oleh mahasiswa

: jumlah sks yang diperoleh mahasiswa
: jumlah mutu semester
: jumlah sks kumulatif yang diperoleh mahasiswa
: jumlah mutu kumulatif
: jumlah sks kumulatif mahasiswa
: jumlah sks kumulatif semu yang diperoleh mahasiswa
: jumlah sks kumulatif semu
: jumlah mutu kumulatif semu
: indeks prestasi semu mahasiswa
: indeks prestasi kumulatif mahasiswa
: IP kumulatif semu mahasiswa
: keinginan semester yang ingin diakses oleh pengguna
: tanda untuk penghitungan IP
Jadwal
SMS
TAHUN
KD_PRG_STUDI
SMS_KE
KD_RUANG
KD_GEDUNG
JAM_SELESAI
JAM_MULAI
KD_HARI
KD_FAK
NO_SEKSI
: keterangan semester
: keterangan tahun ajaran yang sedang dijalani mahasiswa
: kode program studi yang diambil mahasiswa
: keterangan semester yang ingin diakses oleh pengguna
: kode ruangan yang digunakan untuk kegiatan perkuliahan
: kode gedung yang digunakan untuk kegiatan perkuliahan
: keterangan waktu berakhirnya kegiatan perkuliahan
: keterangan waktu mulainya kegiatan perkuliahan
: kode hari diadakannya kegiatan perkuliahan
: kode fakultas
: nomor seksi
Keterangan ERD :
1. Tiap mahasiswa dapat mengakses sistem untuk dapat mengetahui berbagai
informasi mengenai mata kuliahnya. Tiap mahasiswa yang bersangkutan telah
dicatat di dalam entity mahasiswa. Seperti yang terlihat dalam entity di atas,
terdapat atribut kd_mhs yang merupakan atribut unik yang juga digunakan
sistem untuk proses otentifikasi.
2. Untuk dapat mengakses sistem dengan benar, maka syarat utama yang harus
dilakukan oleh pengguna (mahasiswa) adalah mengambil mata kuliah yang
terdapat pada fakultas ilmu komputer. Kemudian sistem akan mencatat
keterangan-keterangan mata kuliah yang bersangkutan seperti tahun
pengambilan, nilai yang diperoleh, dll (untuk keterangan lebih lengkap
terdapat pada gambar atribut di atas).
24
3. Untuk men-sinkronisasi data-data mata kuliah, maka dari tiap mata kuliah ini
dilengkapi dengan kode mata kuliah sehingga sistem dengan mudah dapat
mengakses mata kuliah yang dimaksud dengan baik dan benar.
Seperti yang telah dijelaskan pada keterangan di atas, proses bisnis dari sistem
yang sudah ada masih memiliki kekurangan meskipun secara operasional telah
berjalan memenuhi requirement yang ada. Namun dalam beberapa kondisi seperti
letak tempat tinggal mahasiswa yang jauh dan tidak terdapatnya fasilitas internet,
tentunya sistem ini membutuhkan requirement baru, dimana sistem dapat lebih
mudah diakses oleh pengguna yang tidak dapat menggunakan fasilitas internet.
Dalam kenyataannya, berdasarkan survei market, penggunaan telepon selular telah
populer dan penggunaannya sendiri tidak membutuhkan skill khusus seperti
penggunaan komputer.
25
5.2.2. DFD sistem yang sedang berjalan

Data Flow Diagram (DFD) adalah suatu model proses untuk menyusun dan
mendokumentasikan struktur dan aliran data yang melewati proses yang terdapat pada
sistem. Berikut ini adalah penjabaran model proses sistem yang sedang berjalan.
5.2.2.1. DFD Level 0
Kami telah melakukan perubahan/revisi pada bagian DFD level 0 ini,
karena setelah kami kaji ulang dan tanyakan kepada nara sumber kami
ternyata tidak ada external agent lain yang terlibat pada sistem yang sudah
ada (lasiana) ini selain mahasiswa. Pada DFD level 0 yang terdapat dalam
proposal kami yang terdahulu terdapat 2 external agent, yaitu Sekretariat
dan Mahasiswa. Pegawai sekreteriat dapat melihat, merubah atau
memasukkan nilai-nilai akademis mahasiswa melalui sistem yang sudah
ada, sedangkan mahasiswa dapat meminta berbagai macam request dan
merubah profilnya.
Pada kenyataannya, pegawai yang bertugas untuk memasukkan nilai-nilai
akademis mahasiswa bukanlah pegawai sekretariat, melainkan pegawai
UPT yang memasukkannya langsung ke dalam database SIAK, dengan
tanpa menggunakan antar muka tertentu (hanya menggunakan DBMS
saja). Sedangkan pegawai sekretariat memang tidak mempunyai akses
apapun dalam sistem lasiana ini.
Bentuk DFD level 0 yang telah kami revisi:
Gambar 8. DFD level 0 sistem yang sudah ada
26
Keterangan:
Pengguna sistem https://lasiana.ui.ac.id ini hanya mahasiswa. Mahasiswa
dapat melakukan berbagai macam request ke sistem. Request yang dapat
dilakukan antara lain adalah meminta sistem untuk memberikan informasi
mengenai nilai-nilai akademis dan profil mahasiswa yang bersangkutan
(pengguna) serta mengganti profil mahasiswa tersebut. Untuk dapat masuk
kedalam sistem, pengguna harus melalui proses otentikasi login terlebih
dahulu.
Input: Info Request atau Changed Profile
Output: Info atau Updated Profile
5.2.2.2. DFD Level 1
Dengan alasan yang sama, kami juga telah melakukan perubahan/revisi
pada bagian DFD level 1 ini. Bentuk DFD level 1 yang telah kami revisi:
Gambar 9. DFD level 1 sistem yang sudah ada
Keterangan:
Dalam DFD ini diasumsikan bahwa pengguna telah melakukan proses
otentikasi login terlebih dahulu, jadi kami hanya menjelaskan mengenai
27
proses yang dapat dilakukan oleh pengguna setelah melalui proses

otentikasi login terlebih dahulu.
1. Check Grade Info: proses untuk melihat informasi mengenai nilai-nilai
akademis pengguna.
Input: grade info request
Output: grade info
Deskripsi: proses ini akan mengambil informasi mengenai nilai-nilai
akademis pengguna dari database SIAK untuk kemudian ditampilkan
dalam antar muka sistem.
2. Check Academic Status: proses untuk melihat status akademis
pengguna.
Input: academic status request
Output: academic status
Deskripsi: proses ini akan mengambil informasi mengenai status
akademis pengguna dari database SIAK untuk kemudian ditampilkan
dalam antar muka sistem.
3. Profile Service: proses untuk melihat dan atau merubah profile
pengguna.
Input: view profile request atau edited profile
Output: updated profile
Deskripsi: proses ini akan mengambil informasi mengenai profile
pengguna dari server Dempo, kemudian jika pengguna ingin merubah
profilnya, maka proses ini akan memberikan data-data yang diubah
kepada server tersebut.
4. Edit Grade Form: proses untuk melihat dan atau merubah nilai-nilai
akademis mahasiswa
Input: edited grade form
Output: updated grade form
Deskripsi: proses ini hanya dapat dilakukan oleh pegawai sekretariat
untuk melakukan perubahan informasi mengenai nilai-nilai akademis
mahasiswa, proses ini akan memberikan data-data yang diubah kepada
database SIAK.
28
5.2.2. Diagram antar muka sistem yang sedang berjalan
Gambar 10. Diagram antar muka sistem yang sudah ada (mahasiswa)
Keterangan diagram antar muka sistem yang sudah ada (mahasiswa):

Pada sistem yang lama (lasiana) dimulai dengan membaca perintah dari pengguna
(mahasiswa). Adapun fitur-fitur yang ditawarkan dalam sistem ini adalah :
Melihat info nilai

Pada halaman ini, mahasiswa dapat melihat nilai-nilainya baik nilai dari tiap-tiap
semester maupun akumulasi nilai secara keseluruhan. Data nilai ini diambil dari
database SIAK.
Melihat status akademik

Status akademik mahasiswa adalah status apakah mahasiswa yang bersangkutan
telah melakukan pembayaran uang SPP atau belum. Data yang diambil juga
berasal dari database SIAK.
29
Melihat ataupun merubah profil

Pada halaman ini mahasiswa dapat melihat ataupun merubah profil-nya. Sistem ini
mengambil profil mahasiswa dari dempo. Pada saat pengguna telah masuk ke
dalam halaman yang menampilkan isi profil mahasiswa tersebut, sistem
menawarkan fitur tambahan untuk mengubah profil mahasiswa tersebut.
Gambar 11. Diagram antar muka sistem yang sudah ada (pegawai sekretariat)
Pada diagram antar muka sistem yang ada (pegawai sekretariat) terjadi perubahan
pada proses pengubahan nilai. Pada diagram sebelumnya, pegawai sekretariat
memiliki kewenangan untuk memasukkan nilai mahasiswa langsung ke dalam basis
data SIAK. Sedangkan seharusnya pegawai sekretariat hanya memiliki wewenang
untuk mengisi suatu form yang disediakan oleh pihak UPT untuk mengisi nilai-nilai
mahasiswa tersebut. Sedangkan untuk pemasukan data nilai-nilai mahasiswa ke dalam
basis data SIAK dilakukan oleh pihak UPT setelah menerima form yang telah diisi
oleh pegawai sekretariat.
30
5.3. Objektivitas Peningkatan Sistem

PROYEK: MyCampus
SYSTEM IMPROVEMENT OBJECTIVES

System Objectives
System Constraint
1. Meminimalisasi kesalahan yang terjadi
1. Jadwal
Sistem
yang
kami
akibat ketidaksesuaian jadwal kuliah
kembangkan ini harus selesai dalam
yang diingat oleh mahasiswa yang
jangka waktu kurang lebih 4 bulan.
bersangkutan
Hal ini berkaitan dengan akhir dari
dan
juga
dengan
kehadiran dosen yang mengajar mata
jadwal semester ini.
kuliah tersebut.
2. Dapat dijadikan sebagai sarana dan
2. Pengeluaran
Seluruh
total
atau acuan untuk meningkatkan mutu
pengeluaran yang ada kami pastikan
diri karena dengan adanya sistem ini,
untuk mencukupi dan tidak melebihi
mahasiswa dapat mengakses informasi
estimasi biaya yang telah kami buat
akademis lebih efisien sehingga waktu
sebelumnya.
yang ada dapat digunakan untuk

melakukan keperluan prioritas utama.
3. Memberi kemudahan bagi mahasiswa
3. Kebijaksanaan
Kebijakan
yang
untuk mengakses informasi akademis
diberlakukan oleh fakultas dan UPT
yang lebih dinamis dan up to date
setempat haruslah sesuai dengan yang
tanpa harus mengeluarkan biaya untuk
ada pada sistem. Untuk mewujudkan
pergi ke kampus.
kedisiplinan
dan
keteledoran
yang
tidak
terjadinya
berakibat
pada
human error.
31
SYSTEM IMPROVEMENT OBJECTIVES

System Objectives
4. Memberi
System Constraint
kemudahan
bagi
4. Teknologi : Sistem yang akan kami
mahasiswa yang kesulitan untuk
kembangkan
mencari keberadaan koleganya atau
mahasiswa Fasilkom UI melalui telepon
mahasiswa
selular atau alat elektronik lain yang
lain
untuk
suatu
keperluan yang mendesak.

5. Memberikan
uraian
dapat
digunakan
oleh
mendukung teknologi GPRS.

statistik
mengenai penggunaan lab, sehingga

memberikan
kemudahan
bagi
mahasiswa untuk mengetahui berapa

banyak
pengguna
lab
ataupun
mencari mahasiswa lain yang sedang

menggunakan
komputer
di
lab
mahasiswa.
6. Meningkatkan kesadaran mahasiswa
akan
keberadaan
dan bagiannya
dalam acara-acara akademik dan non

akademik
melalui
pemberitahuan
news atau events yang ada di sekitar

lingkungan kampus.
Tabel 5. Objektivitas peningkatan sistem
32
Keterangan Objektivitas Sistem:

1. Seorang mahasiswa memperoleh jadwal mata kuliah yang diambilnya dalam
suatu semester biasanya tidak luput dari faktor daya ingat yang kurang
sehingga mengakibatkannya kurang memiliki efisiensi dan kinerja yang baik
dalam akademis. Selain itu, keadaan tak terduga seperti penggantian jadwal
oleh dosen yang bersangkutan juga kerap kali terjadi dan menimbulkan
ketidakpastian waktu yang dapat merugikan pihak mahasiswa. Sehingga
seharusnya terdapat suatu sistem yang dapat mensinkronisasi kegiatan
perkuliahan mahasiswa dengan jadwal mata kuliah yang telah ditetapkan, dan
juga kehadiran dari dosen yang bersangkutan.
2. Ketidakpastian jadwal yang ada seringkali mengakibatkan terbengkalainya
pembagian waktu yang telah dibuat oleh mahasiswa. Ketika seorang
mahasiswa dihadapkan pada masalah ini seringkali mereka merasa kesulitan
dalam mengatur waktu yang ada, padahal terdapat banyak sekali tugas yang
cukup berat dan telah menjadi prioritas utama. Hasilnya, mahasiswa tidak
dapat memaksimalkan pengerjaan tugas tersebut dalam waktu yang
seharusnya dapat ia gunakan untuk mengerjakannya.
3. Fasilkom terdiri dari mahasiswa yang tinggal di daerah Depok, Jakarta, sampai
dengan daerah yang sulit dijangkau sekalipun. Bagi beberapa mahasiswa yang
berada di dareah yang jauh, bukan merupakan biaya yang cukup murah untuk
datang ke kampus hanya untuk melihat suatu informasi yang memiliki derajat
keperluan yang rendah. Selain itu diperlukan effort berupa tenaga dan waktu
untuk datang ke kampus. Seringkali terjadi suatu kerugian atas hal-hal
tersebut. Sehingga dinilai dari segi efisiensi waktu, seharusnya mahasiswa
tersebut dapat menggunakan waktunya untuk melakukan suatu hal yang lebih
penting. Jadi, diperlukan suatu sistem yang dapat mengakses informasi
tersebut dari jarak jauh yang dapat meminimalisasi kerugian yang didapat oleh
mahasiswa.
33
4. Keberadaaan tugas yang ada di Fasilkom yang cukup berat dalam segi kualitas
dan banyak dalam segi kuantitas, menuntut mahasiswa untuk dapat saling
berkomunikasi dengan rekan koleganya. Pencarian kolega juga bukan suatu
hal yang mudah ketika orang yang ingin dicari tidak memiliki telekomunikasi
telepon selular atau ketika alat komunikasi tersebut tidak dapat diakses. Hal
seperti ini seringkali memerlukan waktu yang cukup lama.
5. Masih terkait dengan pernyataan pada poin ke-4, laboratorium komputer
merupakan sarana bagi mahasiswa untuk mengerjakan tugas yang ada. Hal ini
mengingat bahwa sebagian besar waktu yang digunakan mahasiswa fasilkom
dikontribusikan pada penggunaan lab komputer baik untuk mengerjakan tugas
atau sekedar mencari informasi di internet. Berangkat dari hal tersebut maka
pengetahuan mahasiswa mengenai penggunaan lab dinilai menjadi sangat
penting. Sehingga mahasiswa juga dapat melakukan perkiraan kegiatan apa
yang lebih dilakukannya ketika mengetahui bahwa penggunaan lab telah
penuh terpakai.
6. Walaupun arus informasi akademis yang ada di lingkungan Fasilkom cukup
baik, terkadang informasi yang berkaitan dengan non-akademis seringkali
luput dari perhatian mahasiswa. Hal demikian menyebabkan mahasiswa
menjadi pasif dan kurang tanggap dengan perkembangan lingkungan
kampusnya sendiri.
34
BAB VI
ANALISA KEBUTUHAN
6.1. Kebutuhan Fungsional
Fungsi-fungsi yang harus ada di dalam sistem adalah sebagai berikut:
1. Sistem dapat melakukan otentikasi terhadap semua pengguna yang
menggunakan sistem tersebut, hal ini berkaitan langsung dengan keamanan
yang merupakan salah satu prioritas tertinggi dalam pengembangan proyek ini.
2. Sistem dapat melakukan pemetaan secara langsung dan realtime antara
request dari pengguna dengan database yang terdapat pada server dan
memberikan respon. Request yang dimaksud disini merupakan request secara
umum (misal, jadwal kuliah, nilai mata kuliah, kehadiran dosen, dsb) karena
sebagian besar request yang diminta oleh user akan berhubungan langsung
dengan database.
3. Sistem dapat melakukan evaluasi dan memberikan respon kepada pengguna
secara langsung, terutama dalam fungsi event reminder.
4. Sistem dapat melakukan interkoneksi antara LDAP, DBMS, webserver dan
interface dengan baik.
35
6.2. Kebutuhan Non-Fungsional

Jenis Kebutuhan
Model Tampilan (Performance)
Model Penyimpanan Data

(Information)
Penjelasan
Membuat sistem yang sudah ada baik
informasi nilai, e-mail maupun news (forum
internal) agar dapat diakses sebagai webpage
yang berbasiskan WAP.
Menyediakan informasi mengenai jadwal
dan ketersediaan staf dan mahasiswa Fasilkom
UI pada sistem yang kami kembangkan.
Menyediakan informasi mengenai
ketersediaan komputer di lab mahasiswa dan
penggunanya pada sistem yang kami
kembangkan.
Menyediakan informasi mengenai
pengumuman penting pada sistem yang kami
kembangkan.
Melakukan penyimpanan data mengenai
jadwal kuliah, pengumuman penting dan nilainilai mahasiswa Fasilkom UI dalam sistem
agar tidak perlu disimpan secara manual,
terdokumentasi dengan baik dan dapat
ditampilkan dalam sistem.
jadwal dan ketersediaan staf dan mahasiswa
Fasilkom UI dalam sistem demi kemudahan
bagi pihak-pihak tertentu yang terkait.
ketersediaan komputer di lab mahasiswa dan
penggunanya agar dapat ditampilkan dalam
sistem.
Data yang harus disimpan sehubungan dengan
sistem yang akan dikembangkan adalah NPM
mahasiswa guna menjamin keamanan
penggunaan sistem. Selain itu data-data yang
telah disebutkan diatas juga disimpan ke
dalam suatu database.
Informasi yang akan diberikan kepada
pengguna sebisa mungkin akan di-up date
dalam tiap perubahan dan atau
perkembangannya oleh administrator yang
bersangkutan.
36
Jenis Kebutuhan
Model Segi Ekonomi (Economic)
Model Pengontrolan Sistem (Control)
Penjelasan
Mengurangi biaya dan menghemat waktu
yang dikeluarkan oleh mahasiswa untuk pergi
ke kampus.
Mengurangi biaya untuk mengakses internet
secara konvensional.
Dalam pengembangan sistem ini, kami
menggunakan prinsip ekonomi dimana kami
mencoba menekan biaya pada bidang-bidang
tertentu. Diantaranya adalah biaya yang
digunakan dalam pengembangan sistem dan
juga biaya instalasi, serta pengoperasian lebih
lanjut mengingat sistem ini menggunakan
teknologi WAP.
Waktu yang kami perlukan dalam
pengembangan ini secara teknis adalah sekitar
4 bulan, namun pengembangannya secara
operasional adalah tidak terbatas. Hal ini
mengingat bahwa teknologi adalah sesuatu
yang terus berkembang dan perkembangannya
itu sendiri unstopable.
Meningkatkan privacy dari data nilai-nilai
mahasiswa Fasilkom UI.
Membatasi akses penggunaan terhadap
informasi yang terdapat dalam sistem.
Mencegah akses penuh dari penggunapengguna yang tidak berwenang.
Model Efisiensi Sistem (Eficiency)
Menggunakan sistem penyimpanan data

yang terpadu untuk menghindari terjadinya
penyimpanan data yang redundant.
Model Pelayanan Sistem (Service)
Mengefisiensikan pelayanan sistem yang

sudah ada.
Pengguna sistem ini adalah mahasiswa
Fasilkom UI yang dapat mengakses sistem ini
dimanapun dan kapanpun dengan
menggunakan telepon seluler yang
mendukung teknologi GPRS.
Tabel 6. Kebutuhan non-fungsional
37
6.3. Prioritas Kebutuhan Fungsional

Kebutuhan
Sistem yang dapat memberikan otentikasi mengenai siapa saja yang dapat
menggunakan sistem.
Sistem dapat melakukan kontrol terhadap konsistensi data pada database
Sistem yang dapat mengevaluasi dan memberikan respon, terutama dalam
fungsi event reminder.
Sistem yang dapat melakukan pemetaan antara request yang diberikan
dengan database secara langsung.
Sistem dapat melakukan interkoneksi antara LDAP, DBMS, webserver,
dan interface dengan baik
Prioritas
1
2
2
2
1
Tabel 7. Prioritas kebutuhan fungsional
Keterangan :
1. Prioritas 1 diberikan kepada kebutuhan fungsional yang memberikan peran
paling signifikan di dalam pengembangan sistem yang baru.
2. Prioritas 2 diberikan kepada kebutuhan fungsional yang memberikan peran
cukup signifikan di dalam pengembangan sistem yang baru.
38
BAB VIII
LOGICAL DESIGN
7.1. Model Data

Untuk mendokumentasikan dan menganalisa data-data yang diperlukan dalam sistem
yang kami kembangkan, kami menggunakan data model Entity Relationship Diagram
(ERD). Data model ini kami gunakan sebagai titik awal dari perancangan database.
Perubahan terjadi pada penambahan beberapa entity dan atribut pada ERD yang sudah
ada. Tidak ada perubahan yang signifikan dari penambahan ini. Adapun pertimbangan
dari adanya perubahan ini adalah meningkatkan efektivitas dari kinerja sistem
MyCampus.
Berikut ini gambar skema ERD pada sistem yang kami kembangkan. Dua buah entity,
yaitu lecturers (SIAK) dan students (SIAK), merupakan entity yang sudah ada di
database SIAK. Penggambarannya kembali di sini untuk memperjelas darimana
foreign key entity lain pada MyCDB berasal.
39
Gambar 12. ERD skema pada sistem yang akan dikembangkan
40
Entity
Keterangan
lectureSchedule
Data-data yang berisi jadwal kegiatan perkuliahan dosen
Lecturers
Data-data yang berisi daftar dosen-dosen pengajar Fakultas Ilmu

Komputer Universitas Indonesia
Availability
Data-data yang berisi daftar kehadiran dosen Fakultas Ilmu Komputer

Events
Data-data yang berisi mengenai beberapa event dan pengumuman yang

ada di lingkungan Fakultas Ilmu Komputer Universitas Indonesia pada
umumnya dan Universitas Indonesia pada umumnya
studentSchedule
Data-data yang berisi informasi kegiatan perkuliahan mahasiswa
Students
Data-data yang berisi keterangan dari mahasiswa Fakultas Ilmu Komputer

Computers
Data-data mengenai keadaan komputer di Fakultas Ilmu Komputer

Tabel 8. Keterangan ERD sistem yang baru
Keterangan atribut:
lectureSchedule
dayID
start
end
activity
: id dari hari diadakannya kegiatan perkuliahan

: keterangan waktu dimulainya kegiatan perkuliahan
: keterangan kegiatan yang dilakukan di luar kegiatan akademis
lecturers
NM_DOSEN
NIP
KD_JUR
: nama dosen
: nomor induk pegawai (dosen)
: kode jurusan
availability
time
available
: keterangan waktu keberadaan dosen

: keterangan kehadiran dosen
events
eventID
subject
body
time
deadline
: id event atau pengumuman yang ada

: subyek dari event atau pengumuman
: keterangan dari event atau pengumuman
: waktu dilaksanakannya event atau pengumuman
: deadline (batas waktu) dari event atau pengumuman
studentSchedule
dayID
start
end
activity
: id dari hari diadakannya kegiatan perkuliahan

: keterangan waktu dimulainya kegiatan perkuliahan
: kegiatan lain yang dilakukan di luar kegiatan akademis
41
students
KD_MHS
KD_PRG_STUDI
KD_FAK
NM_MHS
: nomor pokok mahasiswa dari tiap mahasiswa

: kode program studi yang diambil oleh mahasiswa
: kode fakultas
: nama mahasiswa
computers
computerID
osID
ip
status
: id dari tiap komputer yang ada

: id dari operating system yang dioperasikan komputer
: keterangan ip dari komputer
: status pemakaian komputer
Keterangan ERD
Atribut-atribut yang ada pada entity lecturers dan students adalah sama dengan
sistem lasiana yang lama. Dengan adanya sistem ini maka terdapat tabel-tabel
tambahan yang diperlukan untuk menunjang fasilitas-fasilitas yang ditawarkan
oleh sistem. Diantaranya yaitu tabel studentSchedule yang berfungsi untuk
menyimpan data-data jadwal dari mahasiswa-mahasiswa, yang kedua yaitu tabel
lecturerSchedule yang berfungsi untuk menyimpan data-data jadwal dari dosendosen.
42
7.2. Model Proses

Model proses untuk menyusun dan mendokumentasikan struktur dan aliran data yang
melewati proses yang terdapat pada sistem yang kami kembangkan adalah model
proses seperti Data Flow Diagram (DFD). Model proses ini telah kami kembangkan,
pada proposal-proposal kami sebelumnya hanya terdapat satu eksternal agent saja,
yaitu mahasiswa. Setelah kami analisa kembali, ternyata sistem MyCampus ini
membutuhkan tiga eksternal agent selain mahasiswa, yaitu dosen, sekretariat dan
satpam. Apa saja fungsionalitas dari masing-masing eksternal agent tersebut akan
dibahas dalam penjabaran berikut ini.
7.2.1. DFD Level 0
Gambar 13. DFD level 0
43
Keterangan:
Untuk dapat masuk kedalam sistem penunjang kegiatan mahasiswa ( MyCampus),
pengguna harus melalui proses otentikasi login terlebih dahulu. Pengguna sistem ini
terbagi menjadi 4, yaitu mahasiswa, dosen, satpam dan pegawai sekretariat. Berikut
penjelasan dari masing-masing pengguna sistem:
1.
Mahasiswa
Dalam sistem ini mahasiswa dapat melakukan berbagai request ke sistem,
request yang dapat dilakukan oleh pengguna antara lain adalah meminta sistem
untuk memberikan informasi mengenai jadwal kuliah, jadwal kehadiran dosen,
jadwal dari mahasiswa lain (dengan catatan bahwa mahasiswa tersebut
sebelumnya telah membuat jadwalnya sendiri dalam bentuk (format) yang telah
ditentukan sebelumnya), informasi nilai-nilai akademis, data statistik komputer
lab mahasiswa (user yang sedang login, jumlah komputer yang available), event
reminder, header dari e-mail yang baru masuk/belum dibaca dan subjek dari
news yang belum dibaca. Selain dapat melakukan request, mahasiswa juga dapat
merubah jadwal kuliah dan kehadirannya sendiri.
2.
Dosen
Dalam sistem ini dosen hanya dapat melihat dan merubah jadwal kehadirannya
saja melalui suatu form yang telah disediakan oleh sistem MyCampus.
3.
Satpam
Dalam sistem ini satpam hanya dapat melihat dan merubah jadwal kehadiran
dosen saja melalui suatu form yang telah disediakan oleh sistem MyCampus.
4.
Pegawai sekretariat
Dalam sistem ini pegawai sekretariat hanya dapat melihat dan merubah
informasi mengenai pengumuman-pengumuman penting (event).
Input dari sistem ini terdiri dari:

-
Mahasiswa: info request atau edit schedule form
Dosen: view schedule form request atau edited schedule form
Satpam: view availability form request atau edited availability form
Pegawai sekretariat: view event form request atau edited event form
44
Output dari sistem ini terdiri dari:

-
Mahasiswa: info atau updated schedule form
Dosen: updated schedule form
Satpam: updated availability form
Pegawai sekretariat: updated event form
45
7.2.2. DFD Level 1
Gambar 14. DFD level 1
46
Keterangan:
Dalam DFD ini diasumsikan bahwa pengguna telah melakukan proses otentikasi
terlebih dahulu, jadi kami hanya menjelaskan mengenai proses yang dapat dilakukan
oleh pengguna setelah melalui proses otentikasi terlebih dahulu.
1. Schedule Service: proses yang mengatur segala proses yang berhubungan dengan
jadwal. Dalam proses ini mahasiswa dapat mengubah/melihat jadwalnya sendiri
dan melihat jadwal mahasiswa lain atau dosen. Sedangkan dosen hanya dapat
mengubah/melihat jadwalnya sendiri. Untuk absensi dosen, datanya didapat dari
daftar kehadiran di pos satpam.
Input: edited lecturer availability info, view or edit shedule, view or update
shedule, result data.
Output: updated schedule, updates lecturer availability info, schedule data, fetch
or updated schedule data.
2. Grade Info Service: proses yang memberikan informasi atau data-data mengenai
nilai-nilai akademis pengguna.
Input: view grade info, result grade data
Output: view grade info, grade info data
3. Event Service: proses yang memberikan informasi mengenai pengumuman/event
yang ada di lingkungan kampus, baik bersifat akademis maupun non akademis
yang sebelumnya telah dimasukan ke dalam database.
Input: view event, edit event, updated event data.
Output: update event, updated event data, edit event data.
4. Lab Availability Service: proses ini akan memeriksa status tiap komputer yang
terdapat di lab, kemudian menampilkannya pada antar muka (interface) pengguna,
yang ditampilkan adalah nomor komputer yang available (tidak ada user yang
sedang login dalam komputer tersebut), dalam proses ini juga terdapat fungsi yang
menampilkan nomor komputer beserta user yang sedang login di komputer
tersebut dan persentase komputer yang sedang menggunakan Windows dan Linux
di lab mahasiswa.
Input: log on user, view lab availability info.
Output: user name, lab availability info.
47
5. E-mail Header Retrieval Service : proses yang memberikan informasi mengenai

header dari e-mail yang belum dibaca oleh pengguna.
Input: view e-mail request, e-mail header data.
Output: fetch e-mail header, e-mail header data.
6. News Retrieval Service : proses memberikan informasi mengenai header dari
berita di forum yang belum dibaca oleh user.
Input: view news header, news header data.
Output: fetch news, news header data.
7.2.3. DFD Level 2
Gambar 15. DFD level 2 proses Schedule Service
48
Keterangan:
Dalam DFD ini diasumsikan bahwa pengguna telah melakukan proses otentikasi
terlebih dahulu, jadi kami hanya menjelaskan mengenai proses yang dapat dilakukan
oleh pengguna setelah melalui proses otentikasi terlebih dahulu.
1.
User schedule: proses ini memberikan informasi mengenai jadwal pengguna

itu sendiri. Dalam proses ini, pengguna dapat melihat dan merubah jadwal
pengguna itu sendiri (yang telah dibuat sebelumnya dalam bentuk/format
tertentu).
Input: view schedule, change schedule
Output: updated user schedule
2.
Friend schedule: proses ini memberikan informasi mengenai jadwal

mahasiswa lain. Untuk melakukan proses ini pengguna cukup memasukkan user
name dari mahasiswa lain yang ingin diketahui oleh pengguna.
Input: user name
Output: friend scedule
3.
Lecturer schedule: proses ini memberikan keleluasaan bagi dosen untuk

mengubah jadwal keberadaan dosen tersebut selain fungsi untuk melihat informasi
mengenai jadwal dosen itu sendiri.
Input: view schedule, change schedule
Output: updated lecturer scedule
4.
Lecturer Attendance Info: proses ini memberikan informasi mengenai

keberadaan (absensi) dosen pada saat yang ditentukan. Selain itu pengguna (dalam
kasus ini adalah satpam) juga dapat merubah jadwal keberadaan dosen sesuai
dengan keberadaan dosen tersebut.
Input: view attendance info, change attendance info
Output: updated attendance info
49
7.3. Model Antar Muka
Gambar 16. Diagram antar muka sistem yang baru (mahasiswa)
Keterangan diagram antar muka sistem yang baru (mahasiswa):

Sistem dimulai dengan membaca perintah dari pengguna (dalam diagram di atas
mahasiswa yang menjadi pengguna). Dalam sistem ini, melalui WAP mahasiswa
dapat melakukan :
50
Melihat nilai dari mata kuliah
Melihat header news
Melihat jadwal dosen
Melihat jadwal kuliah dari mahasiswa yang bersangkutan
Melihat header e-mail
Melihat kehadiran dosen
Melihat kehadiran/jadwal mahasiswa lain
Melihat statistik penggunaan lab
Melihat pengumuman atau event yang ada
Perubahan yang terjadi adalah penambahan fitur untuk melihat jadwal pribadi dosen
dan mahasiswa lain yang diakses dari basis data MyCampus. Sedangkan untuk
jadwal yang berkaitan dengan akademis mahasiswa maupun dosen diakses dari basis
data SIAK.
Gambar 17. Diagram antar muka sistem yang baru (staf)
Keterangan diagram antar muka sistem yang baru:

Sistem dimulai dengan membaca perintah dari pengguna (dalam diagram di atas staf
yang menjadi pengguna). Pada sistem yang baru ini, pengguna dapat melakukan
proses pengisian kehadiran dosen dengan mengisi informasi mengenai kehadiran
dosen. Dimana data ini nantinya akan disimpan dalam suatu database dan dapat
diakses oleh sistem yang baru yang digunakan oleh mahasiswa untuk melihat jadwal
kehadiran dosen.
51
Gambar 18. Diagram antar muka sistem yang baru (pegawai sekretariat)

Pada diagram antar muka sistem yang baru untuk pegawai sekretariat terjadi
perubahan pada
Sistem pengisian nilai mahasiswa, seharusnya pegawai sekretariat mengisi

form nilai yang telah disediakan oleh pihak UPT. Sedangkan untuk
pemasukannya ke basis data SIAK meupakan wewenang penuh dari pihak
UPT, setelah menerima form dari pegawai sekretariat. Jadi pegawai sekretariat
tidak memiliki hak akses secara langsung ke basis data SIAK.
Sistem mengisi jadwal kuliah ditiadakan. Untuk jadwal kuliah, sudah

terotomasi ketika mahasiswa melakukan pengisian IRS, sedangkan untuk bagi
dosen sudah terotomasi saat melakukan pengisian jadwal mata kuliah. Dan
proses ini berada di luar mekanisme yang disediakan oleh MyCampus.
52
Gambar 19. Diagram antar muka sistem yang baru (dosen)

Sistem dimulai dengan membaca perintah dari pengguna (dalam diagram di atas
dosen yang menjadi pengguna). Pada sistem ini pengguna dapat melakukan operasi
pengisian jadwal-nya sendiri. Jadwal yang dimaksud adalah waktu kehadiran dosen
yang bersangkutan pada ruang kantornya dan lebih ke jadwal pribadinya. Hal ini
berguna bagi mahasiswa untuk mengetahui jadwal kehadiran dosen untuk keperluan
tertentu.
53
BAB VIII
ANALISA KEPUTUSAN
8.1. Candidate Systems Matrix

Karakteristik
Bagian sistem yang
terkomputerisasi
Kandidat 1
Belum ada pembuatan
laporan untuk dokumen
proses sistem.
Kandidat 2
Pembuatan laporan
untuk dokumen proses
sistem.
Kandidat 3
Sama seperti kandidat 2.
Data-data mengenai
nilai-nilai akademis
terkomputerisasi.
Data-data
mengenai nilai-nilai
akademis dan
informasi lainnya
yang lebih terpusat
dan terkomputerisasi
Data-data
mengenai nilai-nilai
akademis yang lebih
terpusat dan
terkomputerisasi
Sistem lebih
user friendly dan
handal dalam
mendukung proses
akademis.
Mempermudah
kegiatan akademis
mahasiswa.
Deskripsi singkat mengenai

bagian dari sistem yang
akan terkomputerisasi pada
kandidat yang
bersangkutan.
Keuntungan
Deskripisi singkat
mengenai keuntungan dari
bisnis yang akan
direalisasikan untuk
kandidat yang
bersangkutan.
Servers dan workstations
HP Proliant ML150 240.
HP Proliant ML150 280
Rancangan database
menggunakan Oracle,
antar muka
menggunakan bahasa
pemrograman PHP,
web-server Apache dan
sistem operasi Linux.
Rancangan database
menggunakan Oracle,
bahasa pemrograman
menggunakan PHP,
antar muka
menggunakan WML dan
sistem operasi Linux.
Deskripsi dari server dan

workstation yang
dibutuhkan untuk
mendukung kandidat yang
bersangkutan.
Perangkat lunak yang
dibutuhkan
Perangkat lunak yang
dibutuhkan dalam
merancang dan
mengembangkan kandidat
sistem yang bersangkutan,
misalnya untuk database,
sistem operasi, bahasa
pemrograman, dsb.
54
Karakteristik
Metode untuk memproses
data
Kandidat 1
Online client/ server.
Kandidat 2
Kandidat 3
Komputer yang
terhubung ke dalam
jaringan internet.
Telepon selular atau

perangkat elektronik
lain (PDA,
Communicator) yang
mendukung teknologi
GPRS.
Keyboard dan mouse.
Keypad pada telepon

selular atau stylus pada
perangkat elektronik
lain.
Oracle sebagai DBMS.
Misalnya online, batch,

deferred batch, remote
batch, atau real time
system.
Output devices
Deskripsi dari peralatan

yang akan digunakan oleh
user untuk menghasilkan
keluaran dari sistem, sesuai
dengan kebutuhan yang
ada.
Input devices
Deskripsi dari peralatan

yang akan digunakan oleh
user untuk memberi
masukan ke sistem.
Storage devices
Deskripsi singkat mengenai

data yang akan disimpan
dan diakses, media
penyimpan yang akan
digunakan, besar kapasitas
untuk penyimpanan data,
dan bagaimana
penyimpanan data tersebut
dapat terorganisir dengan
baik.
Tabel 9. Candidate system matrix
55
8.2. Feasibility Analysis Matrix

Kriteria Feasibillity
Bobot
Operational Feasibility
Kandidat 1
Kandidat 2
Kandidat 3
Sistem terbatas hanya

pada jaringan internet
konvensional. Kurang
memenuhi requirement
dan namun tidak
menyalahi SOP yang
ada.
Sistem memberikan
pelayanan lebih banyak
daripada kandidat 1.
Pengguna dapat
mengakses sistem
dengan lebih fleksibel.
Memenuhi requirement
dan tidak menyalahi
SOP yang ada, serta
mendukung proses
bisnis.
Sistem memberikan
pelayanan lebih banyak
daripada kandidat 1.
Memenuhi kebutuhan
fungsional pengguna
namun kurang
memenuhi requirement.
Nilai : 50
Nilai : 100
Nilai : 75
Hardware yang
digunakan sudah
kurang memadai. Antar
muka masih terbatas
pada jaringan internet
yang masih
konvensional.
Hardware yang
digunakan sudah lebih
memadai. Antar muka
dapat diakses dengan
menggunakan teknologi
GPRS.
Sama seperti kandidat 2
Nilai : 50
Nilai : 95
Nilai : 95
30%
Technical Feasibility
30%
Economic Feasibility
Costs :
Intangible Benefits :
Schedule Feasibility
Nilai total
30%
10%
100%
Sekitar $1,650
Sekitar $20,550
SOP lebih sederhana
meningkatkan
reliability kepada para
pengguna sistem
(mahasiswa).
Nilai : 90
Nilai : 0
57
Nilai : 85
Nilai : 85
3-4 bulan
Nilai : 90
93
Nilai : 95
86
4 bulan
Tabel 10. Feasiblity analysis matrix
56
Bobot dari feasibility tiap kriteria kandidat didasarkan atas observasi yang dilakukan
oleh system analyst, dimana system analyst mendapat input dari system designers and
builder untuk hal technical feasibility, dan mendapat input untuk analisis dan
rekomendasi akhir (final) dari system user dan system owner.
Tabel feasibility analysis di atas memperlihatkan perbandingan secara langsung dari
ketiga kandidat solusi. Kandidat pertama merupakan sistem yang sudah ada, tim
pengembang merasa sistem yang sudah ada dapat dijadikan kandidat solusi karena
sistem yang sudah ada dapat berjalan dengan baik tanpa ada masalah. Sedangkan
kandidat kedua dan ketiga adalah kandidat solusi yang ditawarkan oleh tim
pengembang yang merupakan perbaikan atau pengembangan dari sistem yang sudah
ada.
Ketiga kandidat solusi feasible (dapat dilaksanakan). Untuk mencari yang terbaik
maka perlu dilihat nilai Ranking (overall). Kandidat 2 memiliki nilai overall
kombinasi dari teknik, operasional, ekonomi, dan penjadwalan yang lebih baik dari
kandidat 1 dan 3, dimana kandidat 1 bernilai 57, kandidat 2 bernilai 93 dan kandidat 3
bernilai 86. Sehingga kandidat 2 mempunyai prioritas yang lebih tinggi dibanding
kandidat 1 dan 3.
Hasil Ranking (total penilaian) dari feasibility analysis, kandidat 2 lebih baik dari
kandidat 1 dan 3, disebabkan keunggulan mutlak dalam hal operational feasibility
dengan memenuhi kebutuhan sistem (requirement), dapat diakses dari mana saja dan
kapan saja (dengan dukungan teknologi GPRS) dan memberikan pelayanan yang
lebih baik dari kandidat 1 dan 3. Oleh karena itu tim pengembang merekomendasikan
implementasi kandidat solusi kedua.
57
8.3. Feasibility Analysis

Pada tahapan feasibilty analysis ini ada empat hal yang akan dianalisa dari setiap
kandidat, yaitu operational feasibility, technical feasibility, economic feasibility, dan
schedule feasibility.
Untuk menganalisa operational feasibility dibagi ke dalam dua tahap. Pertama, untuk
mengetahui apakah solusi yang ditawarkan dapat menyelesaikan permasalahan, yaitu
dengan menggunakan PIECES framework. Kedua, untuk mengetahui apakah solusi
yang ditawarkan dapat memberikan kepuasan pada end-user dan pihak manajemen
yang bersangkutan, yaitu dengan menggunakan metode usability analysis.
Untuk technical feasibility akan dianalisa apakah solusi yang ditawarkan bersifat
praktis, apakah teknologi yang dibutuhkan untuk mengembangkan sistem tersedia,
dan apakah terdapat tenaga ahli untuk memelihara sistem.
Untuk economic feasibility akan dianalisa apakah solusi yang ditawarkan bersifat
menguntungkan jika dipandang dari segi ekonomi, yaitu dengan menggunakan costbenefit analysis. Kami memilih untuk menggunakan metode payback analysis dalam
melakukan cost-benefit analysis.
Untuk schedule feasibility akan dianalisa apakah perancangan jadwal yang telah
dilakukan dan batas waktu yang telah ditetapkan dapat dilaksanakan tepat waktu tanpa
mengalami keterlambatan.
58
8.3.1. Kandidat 1 (sistem yang sudah ada)
PIECES frame work :

Performance :
Kemampuan sistem masih rendah, mengingat cara kerjanya
yang
hanya
bisa
diakses
melalui
jaringan
internet
konvensional.
Pelayanan sistem masih sedikit sehingga kurang mendukung
kegiatan mahasiswa.
Information :
- Input :
Sistem yang menerima input dari pengguna sistem (user)
melalui keyboard dan menampilkan output yang diminta
pengguna sistem dalam bentuk laporan data mengenai
nilai-nilai akademis mahasiswa.
- Output :
Laporan yang dihasilkan oleh sistem memberikan
informasi yang sesuai dengan masukkan user.
- Data yang disimpan :
Penyimpanan
data
terbatas
hanya
pada
nilai-nilai
akademis mahasiswa.
Data-data penting lain, seperti jadwal mahasiswa dan
dosen dan pengumuman penting belum tersimpan dalam
database sistem.
Economy :
- Costs (uang, waktu, tenaga, pikiran, dsb) :
Costs yang dikeluarkan oleh pengguna sistem (baik dari
segi uang, waktu maupun tenaga) untuk mengakses sistem
ini cukup besar.
Costs yang dikeluarkan untuk pemeliharaan sistem ini
tidak terlalu besar mengingat pelayanan yang diberikan
59
masih belum terlalu banyak, sehingga pemeliharaan

sistem ini tidak terlalu sulit.
- Keuntungan :
Pemeliharaan sistem ini tidak terlalu sulit, sehingga tidak
membutuhkan banyak tenaga ahli dan biaya.
Control :
Kontrol dilakukan oleh orang-orang tertentu yang mempunyai
akses tertentu terhadap sistem.
Efficiency :
Penyimpanan data masih kurang efisien.
Service :
Pelayanan yang diberikan oleh sistem masih sedikit
sehingga kurang mendukung kegiatan mahasiswa.
Usability Analysis :
Usability analysis digunakan untuk menganalisa kepuasan yang
dirasakan oleh pengguna sistem. Untuk kandidat 1 kami lakukan
dengan mewawancarai beberapa pengguna sistem, yang hasilnya
mengatakan bahwa sistem yang sedang berjalan kurang menunjang
kegiatan mahasiswa.
Dengan karakteristik dari sistem yang sudah ada, sistem dapat berjalan
dengan baik. Namun hardware yang digunakan dalam sistem kurang
memadai dan sistem masih terbatas hanya pada jaringan internet
konvensional.
60
Projected Annual Operating Costs :
1
1
Database Administrator
Network Administrator
Total Projected Annual Costs :

New hardware & software :
1
Total Development Costs :
$45
$55
$100
$1,550
$1,650
Sistem yang ada memiliki Standard Operational Procedure yang
cukup sederhana.
Sistem yang sudah ada telah berjalan sehingga tidak perlu jadwal untuk
melakukan pengembangan dari sistem ini.
8.3.2. Kandidat 2
PIECES frame work :

Performance :
Sistem lebih bersifat user friendly dan mendukung kegiatan
mahasiswa. Dinilai user friendly karena sistem yang
sekarang dikembangkan menggunakan telepon selular
sebagai output device. Berdasarkan survey bahwa sebagian
masyarakat banyak mengkonsumsi telepon selular sehingga
dapat dipastikan pengguna akan merasa familiar untuk
menggunakannya.
Sistem memberikan jenis layanan lebih banyak dari sistem
yang sudah ada sehingga lebih mendukung kegiatan
mahasiswa.
61
Kemampuan sistem sudah lebih ditingkatkan dari sistem

yang sudah ada sehingga sitem tidak hanya bisa diakses
melalui jaringan internet konvensional (dapat diakses
menggunakan teknologi GPRS).
Information :
- Input :
Keypad pada telepon selular atau stylus pada perangkat
elektronik lain.
- Output :
Data yang diinginkan oleh pengguna sistem yang dapat
dilihat melalui telepon selular atau perangkat lain (PDA,
communicator) yang mendukung teknologi GPRS.
- Data yang disimpan :
Data-data penting yang dapat mendukung kegiatan
mahasiswa dapat tersimpan dengan baik dalam database
sistem.
Penyimpanan data terstruktur dan terorganisir dengan
baik.
Penyimpanan data lebih aman.
Data dapat diakses dengan mudah dan cepat.
Economy :
- Costs (uang, waktu, tenaga, pikiran, dsb) :
Costs dalam hal uang yang harus dikeluarkan untuk
pengembangan sistem ini tidak terlalu besar, mengingat
sistem ini mengembangkan sistem yang sudah ada.
Cost dalam hal waktu, tenaga dan pikiran yang harus
dikeluarkan untuk pengembangan sistem ini termasuk
besar, karena sebelum melakukan pengembangan sistem,
tim pengembang harus mempelajari dan menganalisa
sistem yang sudah ada terlebih dahulu.
62
Cost yang harus dikeluarkan untuk pemeliharaan sistem

tidak terlalu besar, karena sistem yang kami kembangkan
tidak terlalu rumit.
- Keuntungan :
Dengan adanya beberapa layanan baru yang kami
kembangkan,
sistem
dapat
mendukung
kegiatan
mahasiswa.
Control :
Adanya fungsi login mengakibatkan tidak sembarang user
dapat mengakses sistem dan melakukan perubahan terhadap
data atau informasi. Hal ini dapat mencegah terjadinya
penipuan dan pemalsuan dokumen.
Data bersifat konsisten karena penyimpanan data terpusat
pada satu database.
Adanya kebijakan mengenai hak akses sistem sesuai dengan
kategori pengguna, user biasa atau administrator.
Efficiency :
Sistem
bersifat
user
friendly
sehingga
user
tidak
membutuhkan effort yang besar untuk dapat beradaptasi

dengan sistem.
Service :
Sistem
memberikan
data-data
mengenai
akademis
mahasiswa dan informasi lain yang diharapkan dapat

menunjang kegiatan mahasiswa Fasilkom UI.
Sistem mudah dipelajari dan digunakan.
Sistem bersifat fleksibel terhadap perubahan sesuai dengan
kebutuhan dan kebijakan yang ada.
Pengembangan sistem dengan menggunakan bahasa pemrograman
PHP dan antar muka WML memungkinkan untuk pembuatan
prototipe, sehingga tim pengembang dapat menggunakan prototipe
63
untuk dianalisa apakah prototipe yang ada sudah memenuhi

requirements.
Dalam kandidat 2 terdapat perbaikan dari kandidat 1, yaitu dalam hal
hardware yang digunakan, sehingga dapat meningkatkan kinerja sistem.
Antar muka sistem kandidat 2 juga lebih dikembangkan, yaitu dengan
menggunakan WML sehingga dapat memberikan pelayanan yang lebih
banyak dan baik dibanding dengan kandidat 1, sehingga kandidat ini dapat
dijadikan solusi pilihan.
Development Costs :
Personnel :
1
1
1
1
2
1
Project Manager (408 hours/ $10/hr)

Business Process System Analyst (332 hours/ $10/hr)
System Analyst, Lead Programmer (368 hours/ $10/hr)
Documentator (120 hours/ $10/hr)
Programmer (372 hours/ $10/hr)
Database Administrator (280 hours/ $10/hr)
$4,080
$3,320
$3,680
$1,200
$3,720
$2,800
New hardware & software :

1
Total Development Costs :
$1,750
$20,550
Projected Annual Operating Costs :

Personnel :
Salah satu Intangible Benefits yang dihasilkan dari pengembangan
sistem ini adalah meningkatkan reliability kepada para pengguna
sistem ini (dalam kasus ini para mahasiswa). Sistem ini secara tidak
langsung memberi keuntungan bagi para pengguna. Diantaranya
keefisienan pengguna dalam mengakses informasi-informasi
akademik, baik dari segi waktu, biaya dan juga tenaga. Dari
keuntungan ini, pengguna juga dapat meningkatkan kinerjanya
64
dalam perkuliahan sehingga diharapkan hasil yang dapat dicapai

oleh pengguna dalam akademis akan tepat guna.
Perancangan jadwal yang diajukan memang sedikit lebih lama disbanding
kandidat lain, namun sangat feasible karena jadwal tersebut disusun
berdasarkan waktu yang benar-benar dibutuhkan untuk pengembangan
sistem.
8.3.3. Kandidat 3
PIECES frame work :

Secara teknis pieces framework dari kandidat 3 menyerupai
kandidat ke-2. bedanya hanya pada benefit yang dihasilkan (lihat
pada system candidate matrix di atas). Hal ini dikarenakan sistem
yang akan dikembangkan menggunakan teknologi yang juga
memang
terbatas
dalam
tahap
implementasi
dan
juga
pengembangannya.
Costs :
65
Perancangan jadwal yang diajukan sangat feasible karena jadwal tersebut
disusun
berdasarkan
waktu
yang
benar-benar
dibutuhkan
untuk
pengembangan sistem.
66
BAB IX
PHYSICAL DESIGN
9.1. Hasil Pemetaan ER Diagram
Gambar 20. Hasil pemetaan ERD
Keterangan:
1. Tabel lectureSchedule
Tabel ini berisi semua daftar yang berkaitan dengan data dan juga status dari
dosen dari tiap mata kuliah. Data-data yang disimpan dalam tabel
lecturerSchedule:
a. NIP
merupakan suatu nomor unik sebagai pembeda antara dosen yang satu
dengan yang lainnya.
b. dayID
identitas unik yang membedakan suatu hari dengan 6 hari lain dalam
satu minggu.
67
c. start
waktu mulai aktivitas yang bersangkutan.
d. end
waktu berakhirnya aktivitas yang bersangkutan.
e. activity
Kegiatan pada suatu waktu.
2. Tabel studentSchedule
Tabel ini berisi informasi mengenai jadwal mata kuliah yang diikuti oleh
setiap mahasiswa. Data-data yang disimpan dalam table ini adalah :
a. KD_MHS
Merupakan suatu nomor unik yang membedakan seorang mahasiswa
dengan mahasiswa lain
b. dayID
identitas unik yang membedakan suatu hari dengan 6 hari lainnya
dalam satu minggu.
c. start
waktu dimulainya aktivitas yang bersangkutan.
d. end
waktu berakhirnya aktivitas yang bersangkutan.
e. activity
Kegiatan pada suatu waktu.
3. Tabel availability
Tabel ini berisi informasi mengenai kehadiran dosen sehari-hari.
a. NIP
merupakan suatu nomor unik sebagai pembeda antara dosen yang satu
dengan yang lainnya.
b. available
sebuah flag yang menandakan apakah seorang dosen telah melakukan
absen datang atau absen pulang.
c. time
Waktu terakhir flag di poin b di atas diubah.
68
4. Tabel events
Tabel ini berisi data mengenai event yang terjadi di seputar lingkungan
kampus baik yang bersifat akademis maupun non akademis. Data yang
berkaitan dengan tabel ini adalah :
a. eventID
merupakan nomor unik dari setiap event yang ada. Digunakan sebagai
pembeda antara satu event dengan event yang lain.
b. subject
subject dari pemberitahuan
c. body
batang tubuh dari pemberitahuan
d. time
waktu mulai berlakunya pengumuman.
e. deadline
Waktu berakhirnya pengumuman
5. Tabel computers
Tabel ini berisi informasi yang berkaitan dalam suatu komputer. Data yang
berkaitan dengan table ini adalah :
a. computerID
identitas unik yang membedakan sebuah komputer dengan komputer
yang lainnya.
b. osID
flag yang menandakan apakah suatu komputer sedang running Linux
atau Microsoft Windows.
c. ip
ip address dari komputer yang bersangkutan
d. status
status apakah sebuah komputer sedang hidup atau mati.
69
6. Tabel use
Tabel ini berisi informasi mengenai pemakaian komputer di setiap lab beserta
dengan keterangan informasi pengguna komputer tersebut. Data-data yang
disimpan dalam tabel ini adalah :
a. KD_MHS
identitas si pengguna komputer
b. computerID
identitas komputer yang digunakan
c. time
waktu saat mahasiswa mulai melakukan login.
70
9.2. Physical Data Flow Diagram (PDFD)

(Physical Data Flow Diagram) PDFD adalah pengembangan model proses secara
fisik untuk menyusun dan mengimplementasikan struktur dan aliran data yang
melewati proses yang terdapat pada sistem.
9.2.1. PDFD sistem keseluruhan
Gambar 21. PDFD sistem keseluruhan
71
Sistem informasi penunjang kegiatan mahasiswa MyCampus terdiri atas 5 proses

utama, dimana tiap-tiap proses submission menu tersebut menggunakan aplikasi
WML. Sebagian besar proses-proses itu akan melakukan koneksi ke database yang
menggunakan DBMS Oracle.
Berikut ini merupakan penjelasan dari masing-masing proses yang dilakukan sistem:
1. View Grade info
a. Tujuan: memberikan informasi atau data-data mengenai nilai-nilai
akademis mahasiswa.
b. Input: dari submission menu, mahasiswa dapat mengirimkan grade
request melalui tampilan antar muka WML yang diimplementasikan
dengan bahasa pemrograman PHP.
c. Output: sistem akan memberikan informasi mengenai nilai-nilai
akademis pengguna dengan menggunakan query select grade
(implementasi dengan menggunakan Oracle).
2. View Lab availability service
a. Tujuan: memberikan informasi mengenai status komputer di lab
mahasiswa.
b. Input: lab availability request
c. Output: jumlah komputer terpakai dari total komputer dalam satu
ruangan laboratorium komputer.
3. View Event
a. Tujuan: memberikan informasi mengenai event yang ada di lingkungan
kampus, baik bersifat akademis maupun non akademis
yang
sebelumnya telah dimasukkan ke dalam database.

b. Input: dari submission menu, mahasiswa dan sekretariat dapat
mengirimkan event request melalui tampilan antar muka WML yang
diimplementasikan dengan bahasa pemrograman PHP.
c. Output: sistem akan memberikan informasi mengenai event yang ada
di lingkungan kampus dengan menggunakan query select event
(implementasi dengan menggunakan Oracle). Jika pegawai sekretariat
72
melakukan update terhadap informasi event pada database, maka

sistem akan memberikan informasi mengenai event yang telah
diperbaharui.
4. Edit Event
a. Tujuan: membaharui informasi mengenai event yang ada di lingkungan
kampus, baik bersifat akademis maupun non akademis yang akan
dimasukkan ke dalam database MyCDB.
b. Input: dari submission menu, sekretariat dapat mengirimkan edited
event melalui tampilan antar muka HTML yang diimplementasikan
c. Output: sistem akan memperbaharui informasi mengenai event yang
ada di lingkungan kampus dengan menggunakan query updatet event
5. E-mail header retrieval service
a. Tujuan: memberikan informasi mengenai header dari e-mail yang
belum dibaca oleh pengguna.
b. Input: dari submission menu, pengguna dapat mengirimkan view email header request melalui tampilan antar muka WML yang
c. Output: sistem akan memberikan informasi mengenai header dari email yang belum dibaca oleh pengguna dengan menggunakan fasilitas
pengambilan header e-mail dari e-mail server Dempo.
6. News retrieval service
a. Tujuan: memberikan informasi mengenai header dari news yang belum
dibaca oleh pengguna.
b. Input: dari submission menu, pengguna dapat mengirimkan view news
subject
request
melalui
tampilan
antar
muka
WML
yang

c. Output: sistem akan memberikan informasi mengenai header dari email yang belum dibaca oleh pengguna dengan menggunakan fasilitas
pengambilan header news dari news server MHS.
73
9.2.2. PDFD Schedule Service
Gambar 22. PDFD Schedule Service
Berikut ini adalah penjelasan dari masing-masing proses :

1. View User Schedule
Keterangan tambahan untuk proses ini adalah bahwa proses ini dapat diakses
baik melalui komputer maupun telepon selular. Dapat dilihat pada gambar di
74
atas pada nomor proses 1.1.1.1 mahasiswa dapat mengakses MyCampus

melalui komputer , hal ini lebih dimaksudkan untuk mempermudah mahasiswa
dalam pengisian jadwal mata kuliah-nya sendiri untuk data yang akan berguna
dalam proses Friend Schedule (dijelaskan di bawah). Sedangkan pada proses
nomor 1.1.1.2 ini ditujukan untuk pengaksesan melalui telepon selular.
a. Tujuan: memberikan informasi mengenai jadwal kuliah dari mahasiswa
yang bersangkutan. Selain itu mahasiswa juga dapat melakukan
perubahan jadwal mata kuliah-nya sendiri. Untuk fungsi ini sistem telah
tersedia dalam web-base sehingga dapat mempermudah pengguna dalam
melakukan operasi pengubahan jadwal (proses nomor 1.1.1.1).
b. Input: dari submission menu pengguna dapat mengirimkan view user
schedule request baik melalui komputer melalui tampilan antar muka
HTML yang diimplementasikan dengan bahasa pemrograman PHP
maupun dengan telepon selular melalui tampilan antar muka WML yang
c. Output: sistem akan memberikan informasi mengenai schedule pengguna
itu sendiri dengan menggunakan query select schedule (implementasi
dengan menggunakan Oracle).
2. Edit User Schedule
a.
Tujuan: mengubah jadwal mata kuliah mahasiswa yang bersangkutan.
b.
Input: dari submission menu pengguna dapat mengirimkan edit user

schedule melalui tampilan antar muka HTML yang diimplementasikan
c.
Output: sistem akan meng-up date data yang ada dalam database
MyCampus (implementasi dengan menggunakan Oracle).
3. Friend Schedule
a.
Tujuan: mempermudah pengguna dalam mencari dan atau mengetahui

jadwal dan keberadaan rekan mahasiswa lainnya.
b.
Input: dari submission menu pengguna dapat mengirimkan view friend

schedule
request
melalui
tampilan
antar
muka
WML
yang
75
c.
Output: sistem akan memberikan informasi mengenai schedule pengguna

itu sendiri dengan menggunakan query select schedule (implementasi
dengan menggunakan Oracle).
4. View Lecturer Schedule

a.
Tujuan: pengguna dapat melihat informasi jadwal dosen.
b.
Input:
Mahasiswa
dari submission menu pengguna dapat mengirimkan view lecturer
schedule request melalui tampilan antar muka WML yang
Dosen
dari submission menu pengguna dapat mengirimkan view lecturer
schedule request melalui tampilan antar muka HTML yang
diimplementasikan dengan bahasa pemrograman PHP
c.
Output: sistem akan memberikan informasi mengenai schedule dengan

menggunakan query select schedule (implementasi dengan menggunakan
Oracle).
5. Edit Lecturer Schedule

a.
Tujuan: mengubah jadwal mata kuliah dari dosen yang bersangkutan.
b.
Input: dari submission menu pengguna dapat mengirimkan edited

lecturer
schedule
melalui
tampilan
antar
muka
HTML
yang

c.
Output: sistem akan meng-up date data schedule yang ada dalam
database MyCampus (implementasi dengan menggunakan Oracle).
6. View Lecturer Attendance Info

a.
Tujuan : melihat kehadiran dosen yang bersangkutan
b.
Input : dari submission menu pengguna dapat mengirimkan view lecturer

attendance
info
melalui
tampilan
antar
muka
HTML
yang

c.
Output : sistem akan memberikan informasi data mengenai kehadiran

dosen yang ada dengan menggunakan query select attendance info
76
7. Edit Lecturer Attendance Info

a.
Tujuan : mengubah jadwal kehadiran dosen yang bersangkutan.
b.
Input : dari submission menu pengguna dapat mengirimkan edit user

schedule melalui tampilan antar muka HTML yang diimplementasikan
c.
Output : sistem akan meng-up date data attendace info yang ada dalam
database MyCampus (implementasi dengan menggunakan Oracle).
9.3. Interface Design WML
9.3.1. Form Login
Gambar 23. Halaman login
Form Login digunakan untuk otentikasi pengguna. Pada form ini, pengguna harus
memasukkan nama login (Login Name) serta kata kunci user (Password).
77
9.3.2. Menu Utama
Gambar 24. Halaman menu utama
Dalam menu ini kami memberikan beberapa layanan yang dapat digunakan oleh
pengguna sistem MyCampus, seperti layanan akademis untuk melihat informasi
mengenai nilai-nilai akademis pengguna, layanan informasi mengenai staf pengajar
(dosen), rekan-rekan mahasiswa yang lain, lab mahasiswa dan kegiatan kampus.
Untuk dapat menggunakan layanan ini pengguna tinggal memilih layanan yang
diinginkannya.
9.3.3. Layanan Akademis
Gambar 25. Halaman layanan akademis
78
Pada layanan ini, mahasiswa dapat memilih untuk melihat jadwal kuliah atau melihat
nilainya.
Gambar 26. Halaman jadwal kuliah
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat jadwal kuliah
sesuai dengan semester dan hari yang dipilih melalui drop-down menu. Yang akan
muncul di tampilan adalah termasuk waktu, mata kuliah pada jam tersebut, dan
ruangannya.
Gambar 27. Halaman informasi nilai akademis pengguna
79
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat nilainya sesuai
dengan semester yang dipilih melalui drop-down menu. Selain itu, akan ditampilkan
juga IP pada semester tersebut dan IPK Sementara.
9.3.4. Layanan Dosen
Gambar 28. Halaman layanan informasi mengenai dosen
Dengan layanan ini, mahasiswa dapat mengetahui jadwal dosen atau kehadiran dosen
di kampus. Untuk itu, mahasiswa harus memilih nama dosen pada drop-down menu
yang disediakan.
Gambar 29. Halaman layanan jadwal dosen
80
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat jadwal dosen.
Isinya adalah nama dosen sesuai yang telah dipilih, jadwal mengajar, jadwal
pribadinya.
Gambar 30. Halaman layanan informasi kehadiran dosen
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat kehadiran dosen
di kampus (waktu dan kelas yang sedang diajar).
9.3.5. Layanan Sesama Mahasiswa
Gambar 31. Halaman informasi mengenai rekan mahasiswa lain
Dengan layanan ini, mahasiswa dapat mengetahui jadwal mahasiswa lain atau
kehadiran mahasiswa lain di kampus. Untuk itu, mahasiswa harus mengetikkan login
mahasiwa yang diinginkan pada kotak yang tersedia.
81
Gambar 32. Halaman informasi jadwal rekan mahasiswa lain
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat jadwal
mahasiswa lain. Private schedule ini bersifat pribadi, maka setiap mahasiswa bebas
menentukan akses tertentu dari jadwalnya sendiri. Jika ada beberapa jadwal yang
tidak ingin di-share, mahasiswa tersebut dapat mengeset permission-nya. Isinya
adalah login mahasiswa sesuai yang telah dipilih, jadwal kuliah, jadwal pribadinya.
Gambar 33. Halaman informasi kehadiran rekan mahasiswa lain di kampus
82
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat kehadiran
mahasiswa lain di kampus (log di lab dan kelas yang sedang diikuti).
9.3.6. Layanan Lab
Gambar 34. Halaman layanan informasi lab mahasiswa
Pada layanan ini, mahasiswa dapat memilih untuk melihat siapa saja pengguna lab
yang login atau melihat statistik lab pada saat itu.
Gambar 35. Halaman informasi pengguna lab mahasiswa
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat siapa saja
pengguna lab yang login pada saat itu.
83
Gambar 36. Halaman informasi statistik lab
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat statistik lab
pada saat itu.
9.3.7. Layanan Seputar Kampus
Gambar 37. Halaman layanan informasi kegiatan kampus
Pada layanan ini, ada tiga (3) fitur yang disediakan, yaitu untuk melihat pengumuman,
mengecek e-mail header, dan mengecek news header.
84
Gambar 38. Halaman informasi kegiatan kampus
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat pengumuman
seputar kegiatan kampus.
Gambar 39. Halaman informasi e-mail header pengguna
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat e-mail header di
dempo.
85
Gambar 40. Halaman informasi news header
Tampilan di atas akan muncul jika mahasiswa memilih untuk melihat news header di
forum internal.
86
9.4. Interface Design HTML
9.4.1. Halaman Perubahan Jadwal Dosen
Gambar 41. Halamn untuk mengubah jadwal dosen
Tampilan di atas adalah contoh dari pengoperasian pengubahan jadwal dosen. Jadwal
yang dimaksud tidak hanya terbatas pada jadwal perkuliahan saja. Pada tiap pengisian
jadwal ini, field activity diisi dengan nama aktivitas dalam satuan waktu dengan
keterangan waktu dimulai-nya aktivitas tersebut sampai dengan waktu berakhirnya.
Selain itu pada halaman ini, dosen juga dapat melihat jadwal-nya sendiri.
87
9.4.2. Halaman Pengisian Kehadiran Dosen
Gambar 42. Halaman pengisian kehadiran dosen
Halaman di atas adalah contoh tampilan yang akan digunakan oleh staf satpam dalam
mengisi informasi kehadiran dosen.
88
9.4.3. Halaman Pengisian Kegiatan Kampus (Event)
Gambar 43. Halaman pengisian kegiatan kampus (event)
Halaman di atas adalah contoh dari halaman yang akan digunakan oleh pengguna
(pegawai sekretariat) dalam pengisian event yang terjadi. Form di atas terdiri dari
keterangan waktu dimulai sampai berakhirnya event tersebut. Kemudian terdapat field
subject yang diisi dengan judul dari event yang dimaksud, field body yang berisi isi
dari event yang akan berlangsung tersebut.
89
9.4.4. Halaman Perubahan Jadwal Mahasiswa
Gambar 44. Halaman untuk mengubah jadwal mahasiswa
Halaman di atas adalah contoh halaman yang akan digunakan oleh pengguna
(mahasiswa) untuk mengisi kegiatan-kegiatan yang berhubungan dengan akademis.
Keterangan yang tercantum dalam halaman ini adalah mulai dari waktu dimulai
sampai berakhirnya kegiatan serta nama kegiatan tersebut. Form ini nantinya akan
disimpan ke dalam database MyCampus yang akan berguna dalam pengaksesan
friend schedule
90
BAB X
MANAJEMEN PROYEK
10.1. Identifikasi Fase Pengerjaan Proyek

Fase yang digunakan dalam pengerjaan proyek adalah sebagai berikut :
1. Scope Definition Phase
Fase ini bertujuan untuk menentukan kelayakan proyek, menetapkan ukuran dan
batasan proyek, visi proyek, constraints dan limitations, anggota tim proyek serta
anggaran dan jadwal pengembangan. Fase ini melibatkan system owner, project
manager dan system analyst.
Deliverable dari fase ini adalah :
Problem Statement, yaitu mengumpulkan masalah-masalah yang ada pada
sistem sekarang dan megelompokkannya sesuai tingkat visibilitasnya.
Penentuan problem statement dilakukan dengan menggunakan kerangka
kerja/framework PIECES.
Constraint, yaitu batasan-batasan misalnya batas anggaran, deadline,
resources/tenaga yang tersedia serta standar teknologi.
Initial Scope Statement, yaitu menetapkan baseline untuk mengontrol
perubahan scope yang mungkin terjadi selama proyek dilaksanakan, agar
tidak terjadi ketidaksesuaian antara requirement dan expectation dengan
anggaran dan jadwal.
Project staffing, estimasi anggaran, dan jadwal.
Statement of Work, yaitu kontrak atau persetujuan untuk pengembangan
sistem informasi yang menggabungkan keempat poin di atas untuk semua
pihak yang terlibat dalam proyek.
91
2. Problem Analysis Phase

Fase ini mempelajari sistem yang telah ada dan menganalisisnya untuk
menyediakan informasi bagi anggota proyek mengenai pemahaman atas masalahmasalah yang ada pada sistem itu sehingga proyek ini layak untuk dilaksanakan
(feasibility analysis). Pada fase ini, system user telah mulai dilibatkan sebagai
subyek bisnis. Selain itu juga melibatkan system owner, project manager dan
system analysis.
Deliverable dari fase ini adalah System Improvement Objective. Yaitu sasaran
peningkatan dari sistem yang mendefinisikan kriteria bisnis dimana sistem yang
baru akan dievaluasi. Tidak termasuk pendefinisian input, output atau pun proses.
Caranya dengan mempelajari aspek-aspek khusus dari sistem, seperti sejarah
sistem, culture, dan ciri khusus dari sistem.
3. Requirement Analysis Phase
Secara umum fase ini untuk menentukan behaviour dari sistem (apa yang bisa
dilakukan oleh sistem). Mencakup data, proses yang terjadi, antar muka yang
diperlukan, level of performance serta fasilitas-fasilitas yang harus dimilki sistem.
Fase ini juga lebih memfokuskan pada business requirement, dan belum mengarah
pada hal yang bersifat implementasi teknis dan solusi teknologi. Oleh sebab itu,
system designer tidak dilibatkan dalam fase ini.
Deliverable dari fase ini adalah Business Requirement Statement, untuk
menghasilkan requirement tersebut system analyst bekerjasama dengan system
user melalui mekanisme interview dan pembagian kuesioner.
4. Logical Design Phase
Pada fase ini Business Requirement dari fase sebelumnya ditranslasikan ke dalam
bentuk system model ( misalnya data flow diagram). Logical design maksudnya
desain yang dibuat masih belum mengandung solusi teknis.
Deliverable dari fase ini adalah Logical System Model dan Specification.
92
5. Decision Analysis Phase

Fase ini digunakan untuk mengetahui bagian dari proses bisnis yang berjalan yang
perlu dilakukan komputerisasi serta peningkatan performa dan kinerja. Pada fase
ini juga dilakukan technical feasibility, operational feasibility, economic
feasibility, schedule feasibility, dan risk feasibility.
Fase ini menentukan solusi teknis dari proyek yang diajukan, mencakup aspek
teknologi informasi yang cocok untuk sistem serta proses bisnis mana yang perlu
dikomputasi. Setelah itu dilakukan evaluasi berupa : Technical Feasibility,
Operational Feasibility, Economic Feasibility, Schedule Feasibility serta Risk
Feasibility.
Deliverable dari sistem ini : System Proposal
6. Physical Design and Integration Phase
Fase ini mirip dengan logical design dimana business requirement ditranslasikan
kedalam bentuk ke dalam bentuk physical design yang akan mengarah pada
konstruksi sistem dengan solusi teknologi dan implementasi teknis, seperti
database.
7. Construction and Testing Phase
Fase ini digunakan untuk membuat dan melakukan testing sistem terhadap
requirement yang telah diberikan serta melakukan penyesuaian antar muka
terhadap proses bisnis yang lama (sedang berjalan) dengan proses bisnis baru
(yang sedang dikembangkan).
8. Installation and Delivery
Fase ini digunakan untuk melakukan implementasi serta pemindahan secara
perlahan dan berkala dari proses bisnis yang lama menuju proses bisnis yang baru.
93
10.2. Estimasi Waktu Pengerjaan Proyek

Estimasi waktu lamanya pengerjaan proyek adalah sebagai berikut :
1. Preliminary Investigation : 18 Febuari 2004 25 Febuari 2004 (5 hari kerja)
2. Problem Analysis : 1 Maret 2004 17 Maret 2004 (12 hari kerja)
3. Requirements Analysis : 22 Maret 2004 05 April 2004 (10 hari kerja)
4. Decision Analysis : 07 April 2004 03 Mei 2004 (20 hari kerja)
5. Design : 06 Mei 2004 19 Mei 2004 (9 hari kerja)
6. Construction : 24 Mei 2004 14 Juni 2004 (16 hari kerja)
7. Implementation : 21 Juni 2004 15 Juli 2004 (19 hari kerja)
Keterangan lengkap mengenai waktu pengerjaan proyek dapat dilihat pada Gantt
Chart yang kami lampirkan dalam laporan ini.
10.3. Definisi Keterkaitan Antarfase

Scope Definition Phase adalah fase yang paling awal harus dilakukan di antara fasefase lainnya. Masing-masing fase harus dikerjakan secara berurutan, karena fase yang
lebih awal sangat dibutuhkan untuk pengerjaan berikutnya dan fase yang berikutnya
sebagian besar tidak dapat dikerjakan tanpa penyelesaian fase sebelumnya. Mungkin
pasda masing-masing fase akan dibagi-bagi lagi menjadi beberapa tahapan. Seperti
pada Physical Design and Integration Phase yang terbagi dalam beberapa tahapan
yang masing-masing tidak saling terkait dan dapat dilaksanakan secara paralel.
94
10.4. Pengalokasian Sumber Daya
No.
1.
Jabatan
Project
Manager(PM)
Tugas Utama
2.
System Analyst
(SA1)
Bertanggung jawab atas jalannya proyek yang sedang

dikerjakan
Mengkoordinasikan segala kegiatan.
Memeriksa & menyetujui draft user interface.
Menetapkan target mingguan.
Melakukan quality assurance management.
Melakukan pemeriksaan atas database requirement.
Membuat laporan berkala kepada pimpinan.
Memantau database requirement.
Menggali dari Business Process System Analyst terhadap
technical system requirements (workflow, security, dll)
Membuat system requirements, yang tidak termasuk
pekerjaan Business Process System Analyst.
Dengan bantuan informasi Business Process System Analyst,
membuat mock- up interface.
Mempelajari domain permasalahan yang terkait dengan
proyek ini.
Melakukan perancangan sistem (system design: DFD, UML,
ER).
Menyiapkan standar programming.
Melakukan system testing & user acceptance testing.
3.
Programmer
Melakukan implementasi dari desain yang telah dilakukan

dari System Analyst, Lead Programmer.
4.
Business Process
System Analyst
(SA2)
Memberikan informasi mengenai proses bisnis yang berlaku

kepada System Analyst, Lead Programmer dan Progammer.
Melakukan analisa permasalahan.
Melakukan analisa terhadap pelaksanaan proyek.
Melakukan analisa kebutuhan sistem.
Documentator
(Doc)
5.
Membuat dokumentasi aplikasi (UML, modul descriptions).

Membuat dokumentasi penggunaan aplikasi (manual).
Mengumpulkan semua dokumen yang diperlukan dalam
pelaksanaan proyek.
95
No.
6.
Jabatan
Debugger dan
Tester
Tugas Utama
Melakukan system testing. Hal ini dilakukan oleh tester. Pada

proses ini diharapkan tester dapat menemukan kekurangan
dari program.
Bug fix. Debugger bertugas memperbaiki kekurangan yang
ditemukan oleh tester.
7.
Database
Administrator
(DB)
Mendesain database yang diperlukan.

Melakukan implementasi desain database.
Membuat koneksi antara database dan sistem.
8.
Designer
Merancang alur aplikasi

Merancang interface
9.
System User
Melakukan tatap muka langsung dengan pengguna

(khususnya mahasiswa yang nantinya menggunakan sistem
MyCampus
Tabel 11. Pengalokasian sumber daya staf
10.5. Work Breakdown Structure

Phase
Activity
Number
Activity Name
Estimated
Hours
Preliminary
Investigation
Dependent
Upon
Role
1,2,3,4 in
preliminary
investigation
phase
1
2
3
4
List of problems,
opportunities, or directives
Negotiate scope
Plan the project
Present the project plan
24
PM
16
24
16
PM
PM and SA1
PM, SA1 dan Doc
Problem
Analysis
1,2,3,4 in
problem analysis
phase
1
2
3
4
Analyze the current system

Establish system
improvements objectives
Update the project plan
Present findings and
recommendation
12
16
SA1 and PM
SA1 and PM
16
24
SA1 and Doc

PM and SA1
96
Phase
Activity
Number
Activity Name
Estimated
Hours
Requirements
Analysis
Dependent
Upon
Role
1,2,3,4 in
requirements
analysis phase
1
2
3
4
Identify business
requirements
Analyze system
requirements
Prioritize business
requirements
12
SA2 and PM
12
PM and SA2
16
PM
16
SA2 and Doc
Descision
Analysis
1,2,3,4 in
decision analysis
phase
1
2
3
4
Identify candidate
solutions
Analyze candidate
solutions
Recommend a target
solution
Recommend a project
solution
24
PM and SA1
24
SA1 and PM
16
SA1
16
SA1
Design
1,2,3,4,5 in
design phase
1
2
3
4
5
Design the application

architecture
Design the system
database
Design the system
interface
Design the application
logic
40
SA1 and PR1
40
SA1, PR2 and DB
40
SA1 and PR1
40
SA1, PR2 and DB
16
Construction
SA1 and Doc

1,2,3,4,5 in
construction
phase
1
2
3
4
5
Interface building
Network environment
building
Database system building
Application engine
construction
System integration
24
24
PR1
Pr2 and DB
24
32
Pr2 and DB
PR1
32
PR1, PR2 and DB
97
Phase
Activity
Number
Activity Name
Estimated
Hours
Implementation
Dependent
Upon
Role
1,2,3,4,5,6,7 in
implementation
phase
1
2
3
4
5
6
7
Network testing
Database testing
Program testing
System testing
Preparation and
documentation release
Software installation
User acceptance test
16
16
16
16
16
PM, SA1 and SA2

PM, SA1 and SA2
PM, SA1 and SA2
PM, SA1 and SA2
Doc
8
8
PR2 and DB
PR1 and PM
Tabel 12. Work breakdown structure
98
10.6. Estimasi Biaya Proyek

Di sini kami akan memberikan estimasi dari cost yang diperlukan dalam
pengimplementasian sistem. Metode estimasi yang digunakan dalam pengerjaan
proyek ini adalah metode estimasi Function Point (FP). Metode estimasi FP adalah
metode estimasi biaya dengan cara mendekomposisikan
software menjadi
subfunction-subfunction dimana masing-masing subfunction tersebut diestimasi

banyaknya input dan dikalikan dengan bobot pengali yang merupakan tingkat
kesukaran pengimplementasianya. Akan tetapi estimasi ini akan terus direvisi sesuai
dengan perkembangan yang akan terjadi.
Complexity Adjustment Value
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Backup and Recovery

Data Communication
Distributed Processing
Performance Critical
Existing Operating Environment
On-line Data Entry
Input Transaction
Master Files
Complex Inquiries
Complex Internal Processing
Reusable Code
Installation Included
Multiple Installation
Fasilitate Change by User
5
4
4
5
4
2
4
5
3
4
4
2
2
2
Fi
46
Tabel 13. Complexity adjustment values
complexity adjustment value, Fi = 46
99
Computing Function Point
Bobot Pengali
Faktor Pengukur
Jumlah
Mudah
Sedang
Sulit
Jumlah masukkan dari user
38
= 152
Jumlah keluaran
11
= 77
Jumlah query
10
= 60
Jumlah berkas
15
10
15
= 150
Jumlah antar muka pemakai
13
10
= 91
Total
530
Tabel 14. Computing function point metrics
FPestimated
total x (0.65 + 0.01 x Fi)
530 x (0.65 + 0.01 x 46)
530 x 0.299
158.47
Lama Proyek =
4 bulan (ditentukan oleh customer)
Biaya
$ 10.0 per FP (ditentukan oleh software developer)
Dokumentasi =
1 halaman /FP
Total ( FPestimated Cost per FPestimated ) = 158.47 x $ 10.0 = $ 1587.4
100
DAFTAR PUSTAKA
Elmasri, R. dan Navathe, B. [1994] Fundamentals of Database System 2nd ed,

Addison-Wesley, 1994
Pressman, Roger S. [2001] Software Engineering A Practitioners Approach 5th ed,
McGrawHill, 2001
Whitten, Jeffrey L. System Analysis and Design Method 6th ed, McGrawHill, 2004
101

Laporan4 Kel 17

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Laporan4 Kel 17

Diunggah oleh

Hak Cipta:

Format Tersedia

SISTEM INFORMASI PENUNJANG

KEGIATAN MAHASISWA FASILKOM UI

Analisa & Perancangan Sistem

Kemajuan teknologi di bidang telekomunikasi bergerak (mobile) seperti Wireless

BAB VI ANALISA KEBUTUHAN............................................................................35

10.3. Definisi Keterkaitan Antarfase........................................................................94

Gambar 1. Struktur Organisasi.......................................................................................4

Gambar 34. Halaman layanan informasi lab mahasiswa.............................................83

Tabel 1. Pernyataan masalah..........................................................................................8

2.1. Profil Organisasi

1. Mengumpulkan dan mengolah data dan informasi.

2.2. Visi dan Misi

2.3. Struktur Organisasi

Gambar 1. Struktur Organisasi

3. Segi Ekonomi (Economic)

3.2. Tabel Pernyataan Masalah

MANAJER PROYEK: M Faizal Ardi

DISUSUN OLEH: Ardini Ridhatillah

PENYESUAIAN TERAKHIR OLEH: Ratih Kemala

TANGGAL PENYUSUNAN: 29/ 02/ 2004

TANGGAL PENYESUAIAN TERAKHIR: 20/ 03/ 2004

Pernyataan Singkat dari

Mahasiswa tidak bisa

Solusi yang Ditawarkan

Pernyataan Singkat dari

Solusi yang Ditawarkan

Pengelolaan data akademis

Tabel 1. Pernyataan masalah

4.1. Nama Proyek

4.2. Sasaran Proyek

4.3. Gambaran Proyek

selanjutnya adalah mengumpulkan data-data dan informasi yang dibutuhkan untuk

4.4. Pernyataan Masalah

4.5. Ruang Lingkup Awal Proyek

4.6. Visi Proyek

4.7. Batasan Bisnis

4.8. Batasan Teknologi

4.9. Strategi Proyek

4.10. Dokumentasi dan Komunikasi Proyek

perkembangan dari implementasi yang telah dilakukan oleh Programmer dan

4.11. Organisasi dan Staf Proyek

Gambar 2. Struktur organisasi dan staf proyek

M. Faizal Ardi, MFA

Indah Wulansari, IWS

Bussiness Process System Analyst

Debugger dan Tester

Indah Wulansari, IWS dan Ratih Kemala, RK

Gambar 3. Ishikawa diagram 1

2. Ishikawa Diagram untuk permasalahan 2

Gambar 4. Ishikawa diagram 2

3. Ishikawa Diagram untuk permasalahan 3

Gambar 5. Ishikawa diagram 3

4. Ishikawa Diagram untuk permasalahan 4

Gambar 6. Ishikawa diagram 4

5.1.2. Cause-and-Effect Analysis

MANAJER PROYEK: M Faizal Ardi

DISUSUN OLEH: Ardini Ridhatillah

PENYESUAIAN TERAKHIR OLEH: Ratih Kemala

TANGGAL PENYUSUNAN: 17/ 03/ 2004

TANGGAL PENYESUAIAN TERAKHIR: 19/ 03/ 2004

Analisa Sebab dan Akibat

1. Mahasiswa tidak bisa mendapatkan

Sebab dan Akibat

Sistem Informasi Akademis