2. ANALISIS DAN PERANCANGAN SISTEM PENERIMAAN
MAHASISWA BARU UNIVERSITAS NEGERI JAKARTA
Hanifa Fissalma1
, Hamidillah Ajie,S.Si,M.T2
, Bambang.P.Adhi,S.Pd.M.Kom3
1
Mahasiswa Prodi Pendidikan Teknik Informatika dan Komputer, Teknik Elektro, FT – UNJ
2,3
Dosen Prodi Pendidikan Teknik Informatika dan Komputer, Teknik Elektro, FT – UNJ
1
halimiliul@gmail.com, 2
hamidillah@yahoo.com, 3
bambang_padhi@yahoo.com
_________________________________________________________________________________________
Abstrak
Sistem penerimaan mahasiswa baru merupakan sistem yang harus di setiap universitas, salah satunya di
Universitas Negeri Jakarta. analisis sistem dan perancangan digunakan untuk menganalisis, merancang, dan
mengimplementasikan perbaikan dalam dukungan pengguna dan fungsi yang bisnis yang dapat dicapai melalui
penggunaan sistem informasi terkomputerisasi. Dengan menggunakan konsep Reuse-Oriented, sistem Penmaba
2015 dikembangkan dengan ditambah, diubah maupun dihapus requirement-nya sesuai dengan kebijakan yang
diberlakukan saat ini. Selain itu, penambahan web service sebagai perantara antara sistem dan database sebagai
tambahan fitur di sistem yang baru. Feature Driven Development (FDD) adalah salah satu Agile Method yang
belum mempunyai aturan baku dalam pembuatan model penelusuran antar-requirement maupun antar feature.
Pembuatan model penelusuran requirement pada metode pengembangan FDD dengan menggunakan data sample
dari requirement aplikasi sistem Penmaba 2015. Penelitian dilakukan selama bulan Februari hingga bulan Mei
2016. Penelitian bermula dengan merumuskan masalah, mengumpulkan data-data terkait, melakukan analisis
komponen data dengan menggunakan FDD, lalu memodifikasi data dan melakukan perancangan yang
diantaranya merancang requirement yang baru, pemodelan UML, dan rancangan tampilan. Selain itu,
ditambahkan web service sebagai kelebihan yang tidak ada di sistem Penmaba 2015.
Kata kunci: Analisis, Perancangan, Requirement, Reuse-Oriented, Feature Driven Development, dan Web
Service
_________________________________________________________________________________________
1. Pendahuluan
Untuk mendaftar di perguruan tinggi negeri
terdapat tiga jalur masuk yang bisa diikuti oleh calon
pendaftar, yaitu Seleksi Nasional Masuk Perguruan
Tinggi Negeri (SNMPTN), Seleksi Bersama Masuk
Perguruan Tinggi Negeri (SBMPTN) dan jalur
mandiri. SNMPTN dan SBMPTN dilaksanakan oleh
pemerintah (Direktorat Jenderal Pendidikan Tinggi
(DIKTI) Kementrian Pendidikan dan Kebudayaan),
sementara perguruan tinggi hanya menerima hasil
calon mahasiswa yang diterima. Sedangkan jalur
mandiri dilaksanakan dan diatur oleh masing-masing
perguruan tinggi. Universitas Negeri Jakarta
mengadakan jalur mandiri dari tahun 2012 dengan
nama Penerimaan Mahasiswa Baru (PENMABA).
Sistem Penerimaan Mahasiswa Baru adalah
sebuah mekanisme penerimaan mahasiswa baru di
lingkungan perguruan tinggi, termasuk di
Universitas Negeri Jakarta. Mekanisme penerimaan
mahasiswa baru di Universitas Negeri Jakarta
meliputi runtutan proses yang dimulai dari
pendaftaran, penentuan Uang Kuliah Tunggal
(UKT), hingga mahasiswa yang diterima membayar
uang kuliah pertama yang sudah ditentukan.
Diadakannya sistem penerimaan mahasiswa baru ini
diharapkan perguruan tinggi dapat mengetahui
jumlah dan sebaran pendaftar calon mahasiswa baru,
yang nantinya berdampak pada akreditasi perguruan
tinggi dan peningkatan mahasiswa baru yang
memiliki kualitas yang baik.
Bagi calon mahasiswa yang ingin mencari
perguruan tinggi, akan memerlukan banyak
informasi. Untuk itu, Universitas Negeri Jakarta
harus menyediakan informasi sebanyak-banyaknya
terkait Universitas Negeri Jakarta itu sendiri, seperti
jalur masuk, biaya studi, beasiswa yang tersedia,
informasi mengenai biaya hidup dan lain
sebagainya. Dengan adanya informasi yang dimiliki
sebelumnya, akan menghasilkan pendaftar calon
mahasiswa sebanyak-banyaknya.
Sejauh ini, di Universitas Negeri Jakarta
memiliki sistem informasi untuk masing-masing
jalur masuk. Sehingga data mahasiswa yang diterima
di tiap tahun terdapat ketidakseragaman data yang
ada di satu departemen dan didepartemen lain.
Selain itu, masih sedikitnya informasi yang disajikan
bagi calon mahasiswa yang diterima di Universitas
Negeri Jakarta mengenai kehidupan kampus, UKT,
beasiswa dan lain sebagainya.
Salah satu sistem informasi yang harus
dirancang dengan baik untuk Universitas Negeri
Jakarta adalah Sistem Informasi Penerimaan
Mahasiswa Baru. Universitas Negeri Jakarta sudah
3. mulai melakukan pendaftaran jalur PENMABA
sejak tahun 2012 namun hingga saat ini senantiasa
mengalami perubahan dan perbaikan dari tahun ke
tahun, baik karena adanya perubahan peraturan
maupun perubahan kebutuhan sistem.
Kendala yang dihadapi oleh Sistem Penerimaan
Mahasiswa Baru 2015 adalah :
1. Masih adanya beban puncak penerimaan
mahasiswa baru, yaitu pada saat setelah
pengumuman SBMPTN keluar dan di akhir
menjelang penutupan pendaftaran seleksi
mandiri UNJ, yang mengakibatkan sistem
sulit diakses.
2. Belum adanya sistem yang mengintegrasikan
penerimaan mahasiswa baru untuk seluruh
jalur masuk.
Selain kendala secara teknis, terdapat kendala
lain diantaranya :
1. Adanya perubahan kebijakan dari tahun ke
tahun mengenai Sistem Penerimaan
Mahasiswa Baru
2. Penyampaian informasi yang lambat dari
pimpinan kepada tim pengembang yang
mengakibatkan terlambatnya jadwal kerja
pengembangan sistem
3. Sejauh ini pembuatan sistem informasi di
Universitas Negeri Jakarta tidak diawali
dengan analisis dan perancangan, namun
langsung ke implementasi. Sehingga
seringkali terjadi terlewatnya requirement
dan terhambatnya perbaikan bug.
2. Dasar Teori
2.1. Reuse Oriented Software Engineering
Software reuse adalah proses penerapan atau
memperbarui sistem perangkat lunak menggunakan
komponen perangkat lunak yang sudah ada. Sebuah
penggunaan kembali perangkat lunak yang baik.
Proses memfasilitasi peningkatan produktivitas,
kualitas, dan kehandalan, dan penurunan biaya dan
waktu pelaksanaan. Pendeknya, pengembangan
proses reuse dan repositori menghasilkan basis
pengetahuan yang meningkatkan kualitas setelah
penggunaan kembali, meminimalkan jumlah
pekerjaan pembangunan yang diperlukan untuk
proyek-proyek masa depan, dan akhirnya
mengurangi risiko proyek-proyek baru yang
berdasarkan pengetahuan repositori
(A.Ravi,DR.K.Nirmala.2015:431).
Pada sebagian besar proyek perangkat lunak,
ada beberapa reuse software. Hal ini sering terjadi
ketika orang-orang yang bekerja pada proyek tahu
bahwa desain atau kode mirip dengan apa yang
dibutuhkan. Mereka mencari, mengubah sesuai yang
dibutuhkan, dan menggabungkannya ke dalam
sistem mereka (Sommerville,2009:35).
Tipe dari Software Reuse adalah :
1. Application System Reuse, menggabungkan
kembali seluruh aplikasi dengan penggabungan
satu aplikasi kedalam lainnya (COTS reuse)
atau membuat keluarga aplikasi seperti
MS.Office.
2. Component Reuse, komponen (subsistem) dari
satu aplikasi digunakan kembali ke dalam
aplikasi lain.
3. Function Reuse, menggunakan kembali
komponen software yang menerapkan satu
fungsi yang terdefinisi dengan baik.
Meskipun tahap persyaratan spesifikasi awal
dan tahap validasi sama dengan proses perangkat
lunak lain, tahap-tahap dalam proses reuse-oriented
berbeda. tahap ini adalah:
1. Component Analysis, yaitu mengingat kembali
spesifikasi requirement.
2. Requirement Modification, Selama tahap ini,
requirement dianalisis menggunakan informasi
tentang komponen yang telah ditemukan.
Mereka kemudian dimodifikasi untuk
mencerminkan komponen yang tersedia.
3. System Design with Reuse, Selama tahap ini,
kerangka sistem dirancang atau kerangka kerja
yang ada digunakan kembali. Para perancang
memperhitungkan komponen yang digunakan
kembali dan mengatur kerangka untuk
memenuhi ini. Beberapa software baru
mungkin harus dirancang jika komponen dapat
digunakan kembali tidak tersedia.
4. Development and Integration Software, yang
tidak dapat diperoleh secara eksternal
dikembangkan, dan komponen yang
terintegrasi untuk menciptakan sistem baru.
Integrasi sistem, dalam model ini, dapat
menjadi bagian dari pembangunan proses.
(Sommerville,2009:35)
Gambar 2(a). Model Software Reuse-oriented
2.2. Feature Driven Development
Feature Driven Development (FDD)
merupakan proses yang diperancangan dan
dilaksanakan untuk menyajikan hasil kerja secara
berulang-ulang dalam waktu tertentu dan dapat
diukur. FDD merupakan pendekatan yang mengacu
pada pembuatan sistem menggunakan metode yang
mudah dimengerti dan diimplementasikan, teknik
problem solving, dan pelaporan yang mudah
dimengerti dan dikontrol oleh stakeholders (Palmer
dan Felsing,2002).
Unsur penting dalam FDD adalah fitur.
Palmer dan Felsing (2002) mendefinisikan fitur
sebagai : “<action> <result> <object>” di mana
<object> dapat merujuk ke orang, tempat atau hal.
Misalnya, menghitung bunga dari uang yang
dipinjamkan. Merancang fitur-driven membutuhkan
perancangan yang lebih sederhana yang
mengembangkan hanya fitur yang diperlukan dan
diminta. FDD berfokus pada proses yang
4. berkesinambungan, integrasi dan rilis kecil, yang
mengurangi perubahan yang bertentangan dan
memperpendek siklus umpan balik dengan
memberikan umpan balik yang cepat dan perbaikan.
FDD terdiri dari lima rangkaian proses dalam
menperancangan serta membangun sistem. Bagian
iteratif pada proses FDD (Design by Feature and
Build by Feature) mendukung pengembangan Agile
dengan proses adaptasi cepat untuk melakukan
perubahan requirement dan kebutuhan bisnis.
Gambar 2(b). Siklus dalam FDD
Berikut ini rangkaian proses FDD menurut
Palmer dan Felsing (2001):
1. Develop an Overall Model
Dalam fase ini deskripsi domain permasalahan
keseluruhan disusun. Setelah mendapatkan
pemahaman tentang fungsi kebutuhan bisnis,
keahlian domain, dan ruang lingkup
keseluruhan proyek, Domain Expert memulai
keseluruhan model perancangan. persyaratan
didokumentasikan diatur dengan penggunaan-
kasus yang tepat dan spesifikasi teknis.
Domain Expert menyajikan apa yang disebut
“walkthrough” yang mana anggota tim dan
Chief Architect diberitahu deskripsi level tinggi
dari sistem. Walkthrough ialah memaparkan
requirement yang didapat untuk dijelaskan
kembali kepada para developer.
Setelah walkthrough awal, domain keseluruhan
dibagi lagi menjadi domain yang berbeda
daerah. Sebuah panduan rinci diadakan untuk
anggota domain. Setelah setiap walkthrough,
tim pengembangan kecil bekerja sama secara
efektif untuk menghasilkan model obyek.
2. Build a Feature List
Feature list adalah apa yang dilihat klien untuk
validitas dan kelengkapan sistem. Fitur dalam
langkah ini berbasis customer bukan teknologi.
Bahasa yang digunakan sesederhana mungkin
agar klien paham. Pada tahap selanjutnya
setelah menentukan keseluruhan rangkaian
sistem, kini para pengembang harus
mengidentifikasi fitur-fitur apa saja yang dapat
di jadikan list pada setiap modul yang
dihasilkan.
Fase ini melakukan kegiatan awal untuk
mengidentifikasi semua fitur untuk mendukung
model keseluruhan yang dirancang dalam
Tahap 1. Daftar di Fitur dirancang dalam fase
ini dimaksudkan untuk mengatasi semua
persyaratan yang telah diidentifikasi. Tahap ini
juga dapat dianggap sebagai dekomposisi
fungsional dari model domain yang diperoleh
dari Tahap 1. Daftar mayor fitur disusun,
kemudian dibagi lagi menjadi fitur set.
Berikut ini pola mendefinisikan sebuah fitur
menurut Coad (1999) :
<action> the <result> <by |for|of|to> a(n)
<object>
Dimana sebuah <object> merupakan orang,
tempat, atau sesuatu.
Contoh :
a. Menampilkan biodata calon mahasiswa
b. Menghapus data Lokasi
3. Plan by Feature
Fase ini merupakan kegiatan awal yang
menghasilkan pengembangan (Design and
Build) High-Level Plan. High-Level Plan ini
berisi semua fitur, berdasarkan prioritas dan
dependensi mereka.
Manajer Proyek, Development Manager, Chief
Programmer dan Aktor lainnya bertindak
bersama-sama untuk menyiapkan daftar
berurutan dari semua fitur yang tercantum
dalam fase 2, dan memilah fitur berdasarkan
prioritas mereka. Mengidentifikasi saling
ketergantungan antara fitur sebelum
pelaksanaan adalah bagian penting dari fase
ini.
Jadwal dan tonggak utama ditetapkan untuk tes
fitur ini. Sebuah jadwal proyek diidentifikasi,
adalah :
a. Saling Ketergantungan antara fitur.
b. Menyeimbangkan beban kerja seluruh tim
yang berbeda dan Class Owner.
c. Faktor risiko yang terlibat dalam
pelaksanaan fitur.
d. Kompleksitas yang terlibat dalam
pelaksanaan fitur.
e. Setiap faktor eksternal lainnya.
4. Design by Feature dan Build by Feature
Setelah mendapatkan set fitur yang didaftar
dengan prioritas, Class Owner membantu
membentuk tim fitur mereka. tim fitur
menangani sekelompok kecil fitur, yang
merupakan bagian dari daftar fitur
dikembangkan dalam fase 3.
Setiap iterasi umumnya dijadwalkan selama 2
hari sampai 2 minggu. Dalam fase ini, sistem
berjalan melalui proses berurutan dari
pengembangan produk: Perancangan,
Pengembangan, Unit Pengujian, Integrasi dan
Sistem Pengujian. Setelah iterasi sukses, fitur
selesai didorong ke membangun utama,
sedangkan Perancangan berikutnya dan
membangun iterasi dimulai dengan satu set
baru fitur.
Chief Programmer bertanggung jawab untuk
membantu membentuk tim Fitur dengan
5. mengidentifikasi Class Owner mungkin terlibat
dalam pengembangan setiap set fitur. Setiap
tim Fitur mendokumentasikan urutan
perkembangan menggunakan sequence
diagram untuk fitur ditetapkan. Tim
memperbarui Object Model berdasarkan isi
dari masing-masing sequence diagram.
Gambar 2(c). Proses Design and Build by Feature
3. Metodologi
3.1. Alat dan Bahan Penelitian
Perangkat keras yang digunakan adalah:
1. Processor Intel Core(TM) i5CPU M 430
@2.27GHz
2. Besaran memori RAM 2048 MB
3. Kapasitas Harddisk 320 GB
Perangkat lunak yang digunakan adalah:
1. Windows 7 64-bit sebagai sistem operasi
2. EdrawMax 7.9 untuk pembuatan model
diagram UML dan perancangan tampilan
3. Microsoft Word untuk penyusunan kamus
data dan web service
4. Microsoft excel untuk analisis dan
penyusunan requirement
Perangkat lainnya:
1. Handphone sebagai alat perekam
wawancara
Sedangkan bahan penelitian yang digunakan
oleh Penulis mencakup dokumentasi,diantaranya
SRS dan user guide, yang didalamnya terdapat
daftar requirement, usecase diagram, activity
diagram dan struktur data.
3.2. Diagram Alir Penelitian
Secara garis besar, metode penelitian yang
akan dilaksanakan seperti diagram alir dibawah ini :
Gambar 3. Diagram Alir Penelitian
Proses pertama dalam penelitian ini adalah
merumuskan masalah yang dipaparkan pada bahasan
sebelumnya, lalu melakukan studi pustaka untuk
mencari literatur yang berkenaan dengan penelitian
ini. Setelah itu, melakukan rancangan wawancara
dalam rangka untuk memenuhi informasi dan data
dalam penelitian ini. Selanjutnya, melakukan
pengumpulan data, diantaranya SRS, user guide dan
hasil wawancara untuk dianalisis berdasarkan
functional requirement. Lalu dilakukan spesifikasi
data yaitu pengumpulan functional requirement dari
Sistem Penmaba 2015, dianalisis functional
requirement berdasarkan aktor, use case dan
databasenya.
Setelah dilakukan analisis, langkah selanjutnya
adalah melakukan modifikasi data dengan
menambah, mengubah dan menghapus requirement
dari Sistem Penmaba 2015 untuk dijadikan acuan
requirement Sistem Penmaba Mandiri. Selanjutnya
melakukan perancangan data yang diantaranya
perancangan functional requirement dengan Feature
Driven Development, pemodelan UML,
pembentukan kamus data, perancangan wireframe,
dan perancangan web service. Langkah terakhir
dilakukan kesimpulan dan saran untuk penelitian ini.
4. Hasil dan Analisis
4.1. Spesifikasi dan Analisis Sistem Lama
Aktor pada sistem Penmaba 2015 adalah
sebagai berikut :
Tabel 4(a). Daftar Aktor Sistem Penmaba 2015
No. Aktor Deskripsi
1 User Merupakan pengunjung yang
mengakses sistem tanpa melakukan
login terlebih dahulu. Pengunjung
ini memiliki hak akses untuk
melihat informasi seputar Penmaba
2015, daftar program studi, daftar
lokasi dan lain sebagainya.
6. 2 Calon Peserta User yang terdaftar dengan level
User sebagai pendaftar namun
belum melakukan proses
pembayaran.
3 Peserta User yang terdaftar dengan level
User sebagai pendaftar dan sudah
melakukan proses pembayaran.
4 Super Admin User yang terdaftar dengan level
User sebagai super admin, yang
mempunyai kewenangan untuk
menambah User, lokasi, ruang dan
memantau hasil monitoring panel.
5 Helpdesk User yang terdaftar dengan level
User sebagai helpdesk, yang
mempuyai kewenangan untuk
melihat data lokasi, ruang. Dan
memantau hasil monitoring panel
6 Dekan, Rektorat
dan BAAK
User yang terdaftar dengan level
User sebagai dekan,rektorat dan
BAAK, yang mempunyai
kewenangan untuk memantau hasil
monitoring panel
Tahap selanjutnya adalah menemukan use
case. Use case dapat terlihat melalui source code
sistem Penmaba 2015 dan dalam dokumentasi SRS
Penmaba 2015 . Daftar use case Penmaba 2015
adalah :
Tabel 4(b). Daftar Use Case Sistem Penmaba 2015
No. Use Case Deskripsi
1 Melihat informasi
Penmaba 2015
Merupakan proses melihat
informasi seputar Penmaba
2015
2 Daftar Merupakan peserta yang akan
melakukan proses pendaftaran
pertama kali harus
mendaftarkan Username
terlebih dahulu, untuk dapat
melanjutkan proses selanjutnya.
3 Login Merupakan proses
memasukkan Username dan
password oleh semua aktor,
kecuali User
4 Pilih prodi Merupakan proses setelah
terdaftar menjadi User, calon
peserta tersebut diwajibkan
untuk memilih jenis ujian dan
program studi tujuan untuk
dapat diproses berapa besar
biaya yang harus dikeluarkan.
5 Cetak tagihan Merupakan proses setelah
memilih jenis ujian dan
program studi tujuan, calon
peserta mencetak tagihan untuk
kemudian dibayarkan ke pihak
Bank.
6 Upload foto Merupakan proses mengupload
foto yang syaratnya disesuaikan
dengan syarat dan ketentuan
yang telah tercantum pada
website informasi.
7 Isi biodata Merupakan proses untuk
mengisi biodata peserta yang
akan digunakan untuk
mencetak kartu peserta.
8 Cetak kartu peserta Merupakan proses setelah
proses pengisian biodata
selesai, peserta dapat
melakukan cetak kartu peserta
dan tidak dapat mengganti isian
biodata sebelumnya.
9 Monitoring panel Merupakan proses yang
digunakan oleh admin pada
admin panel untuk memantau
rekapitulasi.
10 Upload ruang dan
lokasi
Merupakan proses yang
digunakan oleh admin untuk
menambahkan ruang dan lokasi
jika ruang dan lokasi yang ada
telah habis atau mendekati
habis.
11 Tambah User Merupakan proses yang
digunakan oleh admin untuk
menambahkan User dengan
level User tertentu.
12 Cetak album dan
cetak daftar kehadiran
Merupakan proses untuk
mencetak album saat pada satu
ruang telah terisi penuh.
Dari use case yang dijabarkan, lalu dibuat
diagram use case nya. Diagram use casenya adalah :
Gambar 4(a). Diagram Use Case Sistem Penmaba 2015
Didalam database sistem Penmaba 2015,
terdapat 24 tabel. Berdasarkan source code yang
ada, dari keseluruhan tabel yang ada di dalam
database sistem Penmaba 2015, terdapat beberapa 8
tabel yang tidak digunakan, diantaranya :
Tabel 4(c). Daftar Database Sistem Penmaba 2016 yang Tidak
Digunakan
No. Nama Tabel Deskripsi Alasan
1 Baak_daftar Untuk menyimpan
data mahasiswa
untuk diserahkan
kepada BAAK
Data untuk
BAAK sudah
didapat dari
tabel peserta
2 berita Untuk menyimpan
data berita
Semua berita
yang ada di
sistem
Penmaba 2015
ditampilkan
secara statis
3 slider Untuk menyimpan
gambar slider
Slider
ditampilkan
dalam secara
statis
7. 4 cadangan Untuk menyimpan
data mahasiswa
cadangan atau
jalur kerjasama
Data
mahasiswa
cadangan
sudah termasuk
dalam tabel
peserta
5 Tb_pesertafire Untuk menyimpan
data mahasiswa
prodi Fire Saftey
Engineering
Teknik Mesin
Data
mahasiswa
prodi tersebut
sudah termasuk
dalam tabel
peserta
6 kabupatensekol
ah
Untuk menyimpan
data kabupaten
sekolah
Data kabupaten
diambil dari
tabel kabupaten
7 propinsisekolah Untuk menyimpan
data propinsi
sekolah
Data propinsi
diambil dari
tabel propinsi
8 Tw_menu Untuk menyimpan
data menu yang
ada di sistem
Data menu
ditampilkan
secara statis
Berdasarkan wawancara dengan narasumber
dan melihat dari source code sistem Penmaba 2015,
terdapat beberapa masalah yang dialami pada saat
sistem Penmaba 2015 berlangsung, diantaranya :
1. Masih terdapatnya beban puncak yaitu saat
setelah pengumuman SBMPTN dan
menjelang penutupan.
2. Adanya kecenderungan pembuatan multiple
user.
3. Banyaknya tabel di database yang tidak
digunakan.
4. Aktor dekan, rektorat dan BAAK tidak
pernah menggunakan akunnya, hanya
mengandalkan laporan cetak yang didapat
dari super admin atau helpdesk.
4.2. Modifikasi Sistem
Modifikasi dilakukan dengan menambah,
mengubah atau menghilangkan requirement, baik
functional requirement maupun non-functional
requirement untuk meningkatkan kualitas dan
pemenuhan kebutuhan fungsional. Daftar modifikasi
sistem sebagai berikut :
Tabel 4(d). Daftar Modifikasi Sistem
No. Nama Fitur Aksi Alasan
Pembuatan
portal
penmaba
Penambahan
sistem
Adanya kebutuhan
untuk menampung
mahasiswa yang
diterima dari seluruh
jalur masuk, tidak
hanya yang berasal
dari Penmaba saja.
Karena mahasiswa
yang diterima melalui
jalur SNMPTN dan
SBMPTN masih
menggunakan cara
manual untuk
mengumpulkan
datanya
1. Pembuatan
Web Service
Tambah fitur Pembuatan web
service dilakukan agar
nantinya semua fungsi
yang dibutuhkan oleh
sistem Penmaba dapat
diambil dari web
service. Selain itu,
mengikuti
perkembangan zaman
yang sekarang ini
banyak menggunakan
web service
2. Perubahan
Aktor pada
sistem Admin,
baik di Portal
Penmaba dan
Penmaba
Mandiri
Ubah Subjek Awalnya user admin
berjumlah 5 aktor,
yaitu : Super admin,
Helpdesk, BAAK,
Rektorat dan Dekan.
Diubah menjadi hanya
3 aktor yaitu Super
Admin, Helpdesk dan
Panitia. Hal ini
dikarenakan aktor
BAAK, Rektorat dan
Dekan tidak pernah
mengakses sistem dan
hanya meminta
rekapitulasi berbentuk
cetak kepada super
admin atau helpdesk.
Aktor panitia
merupakan Panitia
Penmaba Mandiri
UNJ
Tambah
rekapitulasi
per bidang
keahlian
Tambah fitur Adanya kebutuhan
untuk mengetahui
jumlah peserta
berdasarkan bidang
keahlian, untuk
nantinya berpengaruh
pada ruang ujian
3. Tambah
rekapitulasi
sisa ruang dan
kursi ujian
Tambah fitur Adanya kebutuhan
untuk mengetahui sisa
ruang dan kursi yang
dipakai ujian
4. Tambah
rekapitulasi
uji
keterampilan
Tambah fitur Adanya kebutuhan
untuk mengetahui
jumlah pendaftar yang
mengikuti uji
keterampilan serta
peserta yang sudah
membayar uji
keterampilan
5. Lihat log
transaksi
Tambah fitur Adanya kebutuhan
untuk mengetahui
aktifitas yang
dilakukan oleh admin
sehingga jika terjadi
perubahan data, dapat
diketahui siapa yang
bertanggung jawab
pada perubahan data
tersebut
Lihat grafik Tambah fitur Adanya kebutuhan
untuk melihat grafik
jumlah pendaftar
secara umum
berdasarkan waktu
6. Non-
functional
requirement
Penjelasan
rinci
1. Sistem Penmaba
Mandiri
menggunakan
bootstrap dan build
in php,
meminimalisasikan
design dengan
mengacu pada alur
pendaftaran dengan
memaksimalkan
JavaScript untuk
mengakses web
service agar
meminimalisasi
8. pengambilan data
secara menyeluruh.
2. Sistem ditampilkan
dalam bahasa
Indonesia
3. Sistem harus
tersedia 24 jam dan
360 hari dalam
setahun untuk
kebutuhan
pendaftaran
4. Sistem tidak boleh
kehilangan data di
database
5. Dapat mendukung
1000 aktifitas
setiap hari tanpa
gangguan
6. Proses login hanya
dalam waktu
kurang dari 5 detik
4.3. Perancangan Portal Penmaba
4.3.1. Penentuan Fitur Utama
Tahap pertama dalam pembuatan daftar
requirement adalah menentukan fitur utama. Fitur
utama untuk Portal Penmaba adalah :
User :
1. Menampilkan informasi umum seputar
penerimaan mahasiswa baru dari semua jalur
dan Universitas Negeri Jakarta
2. Login
3. Buat Akun
4. Lupa Password
5. Isi Biodata
Admin:
1. Login
2. Manajemen user
3. Manajemen berita
4. Manajemen beasiswa
5. Manajemen informasi UKT
6. Manajemen penerimaan
4.3.2. Daftar Functional Requirement dan
Functional Area
Langkah selanjutnya adalah membuat daftar
functional requirement. Functional requirement
dikumpulkan berdasarkan tingkatan user (Calon
Mahasiswa, Admin, Helpdesk,Panitia) dan
dikelompokkan berdasarkan kesamaan ciri dan
dimensi yang disebut functional area. Setelah itu,
diberikan pengkodean dan pelabelan pada daftar
functional requirement yang dimulai dari RPP001.
RPP yang berarti “Requirement Portal Penmaba”
dan 001 dipilih secara bebas.
Tabel 4(e). Daftar Functional Requirement Dan Functional
Area Portal Penmaba
KODE
_REQ
NAMA
FUNCTIONAL
AREA
RPP020 menyediakan fasilitas button
login bagi user
LOGIN
RPP033 calon mahasiswa dapat
melakukan login
RPP034 menampilkan pesan
peringatan jika username
atau password salah
RPP021 menyediakan fasilitas button
buat akun untuk user yang
akan membuat akun
BUAT AKUN
RPP026 menampilkan fasilitas isi
biodata terkait pembuatan
akun
RPP027 user umum dapat mengisi
biodata untuk pembuatan
akun
RPP028 menampilkan pesan
peringatan jika data yang
diisi calon mahasiswa ada
yang kurang atau salah
4.3.3. Generalisasi
Generalisasi merupakan tahap pengefisiensi
requirement dalam rangka membagi domain area
kerja. Angggota tim developer akan mengerjakan
proyek tersebut berdasarkan pembagian domain area
yang telah diterima. Domain area adalah
penggeneralisasian terhadap requirement dan
domain secara keseluruhan.
Tabel 4(f). Generalisasi Functional Requirement Portal
Penmaba
KODE
_REQ
NAMA
GENERALISASI
RPP037 admin dapat melakukan
login
admin,helpdesk
dan panitia dapat
melakukan login
RPP038 menampilkan pesan
peringatan jika terdapat
kesalahan pada
pengisian username atau
password
RPP081 panitia dapat melakukan
login
RPP082 menampilkan pesan
peringatan jika terdapat
kesalahan pada
pengisian username atau
password
RPP093 helpdesk dapat
melakukan login
RPP094 menampilkan pesan
peringatan jika terdapat
kesalahan pada
pengisian username atau
password
RPP039 admin dapat menambah
data user lainnya sesuai
dengan level usernya admin dapat
menambah data
user
RPP040 terdapat pesan
peringatan perihal
penambahan data user
Tabel 4(g). Hasil Generalisasi Functional
Requirement Portal Penmaba
KODE
_REQ_GEN
NAMA GENERALISASI
GRPP001 user umum dapat melihat informasi umum
GRPP002 calon mahasiswa dapat melakukan login
GRPP003 user umum dapat membuat akun
GRPP004 calon mahasiswa dapat melakukan lupa
password
GRPP005 calon mahasiswa dapat mengisi biodata
GRPP006 calon mahasiswa dapat melihat biodata
GRPP007 calon mahasiswa dapat mengubah biodata
GRPP008 user umum dapat melihat informasi
penerimaan
9. 4.3.4. Pembuatan Feature List
Setelah membuat tabel hasil generalisasi
requirement, kemudian requirement dibuat
menjadi kalimat-kalimat feature. Berikut ini
adalah tabel sebagian dari perubahan aturan
feature berdasarkan penggeneralisasian
functional requirement :
Tabel 4(h). Penulisan Feature List Portal Penmaba
NAMA
GENERALISASI
FEATURE LIST
user umum dapat melihat
informasi umum
melihat informasi umum
calon mahasiswa dapat
melakukan login
melakukan login
user umum dapat
membuat akun
membuat akun
calon mahasiswa dapat
melakukan lupa password
melakukan lupa password
calon mahasiswa dapat
mengisi biodata
mengisi biodata
calon mahasiswa dapat
melihat biodata
melihat biodata
calon mahasiswa dapat
mengubah biodata
mengubah biodata
user umum dapat melihat
informasi penerimaan
melihat informasi
penerimaan
4.3.5. Pembuatan Feature Set
Untuk memudahkan penelusuran proses
antar feature, maka diberikan pengkodean untuk
masing-masing feature dan dicantumkan pula
subjek atau pelaku aktif yang menggunakan
fungsi tersebut. Tanda checklist menandakan
hubungan antara feature dengan subjek. Untuk
lebih jelasnya, terdapat hasil sebagian dari
feature set berikut :
Tabel 4(i). Daftar Feature Set Portal Penmaba
nomor
feature
Subjek feature
list
Admin Helpdes
k
Paniti
a
FSPP009 v v v melakukan
login
FSPP010 v menambah
data user
FSPP011 v v v melihat
daftar user
FSPP012 v mengubah
data user
FSPP013 v menghapu
s data user
FSPP014 v menambah
data
beasiswa
FSPP015 v melihat
data
beasiswa
FSPP016 v mengubah
data
beasiswa
4.4. Perancangan Penmaba Mandiri
4.4.1. Penentuan Fitur Utama
Tahap pertama dalam pembuatan daftar
requirement adalah menentukan fitur utama. Fitur
utama antara Sistem Penmaba 2015 dengan
Penmaba Mandiri tidak begitu banyak mengalami
perubahan, hanya pada fitur Rekapitulasi
ditambahkan rekapitulasi sisa ruang dan kursi,
rekapitulasi bagi yang sudah membayar dan
rekapitulasi uji keterampilan yang sudah membayar,
sedangkan manajemen pengumuman dihilangkan
karena tidak terpakainya fitur tersebut di sistem
Penmaba 2015. fitur utama di Penmaba Mandiri
yaitu :
Front-end:
1. Informasi umum
2. Login
3. Buat Akun
4. Lupa Password
5. Pilih paket ujian
6. Pilih program studi
7. Cetak tagihan
8. Isi biodata
9. Cetak kartu
Back-end:
1. Login
2. Manajemen user
3. Manajemen peserta
4. Manajemen lokasi
5. Manajemen ruang
6. Cetak album dan daftar hadir
7. Rekapitulasi
8. Grafik pendaftar
4.4.2. Daftar functional requirement dan
Functional Area
Langkah selanjutnya adalah membuat daftar
functional requirement. Requirement pada sistem
Penmaba 2015 dikembangkan dengan
ditambah,diubah atau dihapus requirement-nya
berdasarkan kebijakan yang berlaku saat ini. Lalu,
functional requirement dikumpulkan berdasarkan
tingkatan user (Pendaftar, Peserta, Admin,
Helpdesk, Panitia) dan dikelompokkan berdasarkan
kesamaan ciri dan dimensi yang disebut functional
area. Setelah itu, diberikan pengkodean dan
pelabelan pada daftar functional requirement yang
dimulai dari RPM001. RPM yang berarti
“Requirement Penmaba Mandiri” dan 001 dipilih
secara bebas.
Tabel 4(j).Daftar Functional Requirement Dan Functional
Area Penmaba Mandiri
KODE
_REQ
NAMA FUNCTIONA
L AREA
RPM013 semua user dapat melihat
button menuju buat akun
BUAT AKUN
RPM020 user umum dapat melihat
kolom isian yaitu username,
nama depan, nama belakang,
password, ulangi password,
email dan nomor telepon
RPM014 semua user dapat melihat
button menuju lupa password
LUPA
PASSWORD
RPM018 pendaftar dan peserta dapat
melihat kolom isian untuk
mengisi alamat email user
10. RPM019 pendaftar dan peserta dapat
melihat pesan peringatan
terkait pengiriman email
RPM015 semua user dapat melihat
button menuju login
LOGIN
RPM016 pendaftar dan peserta dapat
melihat kolom isian untuk
mengisi username dan
password untuk melakukan
proses login
RPM017 pendaftar dan peserta dapat
melihat pesan peringatan jika
terdapat kesalahan pengisian
username atau password
4.4.3. Generalisasi
Generalisasi merupakan tahap pengefisiensi
functional requirement dalam rangka membagi
domain area kerja. Angggota tim developer akan
mengerjakan proyek tersebut berdasarkan
pembagian domain area yang telah diterima.
Domain area adalah penggeneralisasian terhadap
requirement dan domain secara keseluruhan.
Tabel 4(k). Generalisasi Functional Requirement Penmaba
Mandiri
KODE
_REQ
NAMA GENERALISASI
RPM013 semua user dapat melihat
button menuju buat akun
user umum dapat
membuat akun
RPM020 user umum dapat melihat
kolom isian yaitu
username, nama depan,
nama belakang, password,
ulangi password, email dan
nomor telepon
RPM014 semua user dapat melihat
button menuju lupa
password
pendaftar dan
peserta dapat
melakukan lupa
password
RPM018 pendaftar dan peserta dapat
melihat kolom isian untuk
mengisi alamat email user
RPM019 pendaftar dan peserta dapat
melihat pesan peringatan
terkait pengiriman email
Tabel 4(l). Hasil Generalisasi functional Requirement
Penmaba Mandiri
KODE
_REQ_GEN
NAMA GENERALISASI
GRPM001 semua user dapat melihat informasi umum
GRPM002 user umum dapat membuat akun
GRPM003 pendaftar dan peserta dapat melakukan lupa
password
GRPM004 pendaftar dan peserta dapat melakukan login
GRPM005 pendaftar dapat memilih paket ujian dan
program studi
GRPM006 pendaftar dapat melihat paket ujian dan
program studi yang sudah dipilih
GRPM007 pendaftar dapat mencetak tagihan
GRPM008 peserta dapat mengupload foto dan mengisi
biodata
GRPM009 peserta dapat melihat foto dan biodata yang
sudah diisi
GRPM010 peserta dapat mengubah biodata
GRPM011 peserta dapat mencetak kartu
4.4.4. Pembuatan Feature List
Setelah membuat tabel hasil generalisasi
requirement, kemudian requirement dibuat menjadi
kalimat-kalimat feature. Berikut ini adalah tabel
sebagian dari perubahan aturan feature berdasarkan
penggeneralisasian requirement :
Tabel 4(m). Penulisan Feature List Penmaba Mandiri
NAMA GENERALISASI FEATURE LIST
semua user dapat melihat
informasi umum
melihat informasi umum
user umum dapat membuat
akun
membuat akun
pendaftar dan peserta dapat
melakukan lupa password
melakukan lupa password
pendaftar dan peserta dapat
melakukan login
melakukan login
pendaftar dapat memilih
paket ujian dan program studi
memilih paket ujian dan
program studi
pendaftar dapat melihat paket
ujian dan program studi yang
sudah dipilih
melihat paket ujian dan
program studi
pendaftar dapat mencetak
tagihan
mencetak tagihan
peserta dapat mengupload
foto dan mengisi biodata
mengupload foto dan mengisi
biodata
peserta dapat melihat foto
dan biodata yang sudah diisi
melihat foto dan biodata yang
sudah diisi
peserta dapat mengubah
biodata
mengubah biodata
peserta dapat mencetak kartu mencetak kartu ujian
4.4.5. Pembuatan Feature Set
Untuk memudahkan penelusuran proses antar
feature, maka diberikan pengkodean untuk masing-
masing feature dan dicantumkan pula subjek atau
pelaku aktif yang menggunakan fungsi tersebut.
Tanda checklist menandakan hubungan antara
feature dengan subjek. Untuk lebih jelasnya,
terdapat hasil sebagian dari feature set berikut :
Tabel 4(n). Daftar Feature Set Penmaba Mandiri
nomor
feature
Subjek feature list
user
umum
pendaftar peserta
FSPM001 v melihat
informasi
umum
FSPM002 v membuat
akun
FSPM003 v v melakukan
lupa
password
FSPM004 v v melakukan
login
FSPM005 v memilih
paket ujian
dan program
studi
FSPM006 v melihat paket
ujian dan
program
studi
FSPM007 v mencetak
tagihan
FSPM008 v mengupload
foto dan
mengisi
biodata
11. FSPM009 v melihat foto
dan biodata
yang sudah
diisi
FSPM010 v mengubah
biodata
FSPM011 v mencetak
kartu ujian
5. Kesimpulan dan Saran
Berdasarkan hasil pembahasan penelitian pada
skripsi ini, maka dapat diambil kesimpulan bahwa
reuse-oriented dapat diterapkan didalam
pengembangan suatu sistem informasi untuk dapat
mempersingkat waktu pengembangan sistem, dan
penerapan salah satu Agile Method yaitu Feature
Driven Development (FDD) pun dapat dilakukan
dengan tujuan untuk mempermudah penelusuran jika
terjadi kesalahan dalam testing hasil akhir aplikasi
dan dapat digunakan sebagai acuan dalam
pengembangan proyek selanjutnya di Universitas
Negeri Jakarta.
Dari hasil penelitian yang telah Penulis
lakukan, untuk penelitian yang selanjutnya Penulis
mengharapkan untuk :
1. Adanya penambahan fitur log pada sistem
admin, agar diketahui aktifitas admin didalam
sistem, sehingga bila terjadi kesalahan, super
admin dapat mengetahui admin mana yang
harus bertanggung jawab.
2. Adanya perbaikan dalam hal rancangan
tampilan maupun database yang lebih baik.
3. Menerapkan metodologi lain diluar FDD dalam
pengumpulan requirement.
Daftar Pustaka:
2015, Software Requirement Specification Situs
Penmaba Universitas Negeri Jakarta tahun
2015, Pustikom Universitas Negeri Jakarta.
A.Ravi,DR.K.Nirmala.2015. Software Reusability:
A Framework Using Software Components
and Reusable Assets.[Prosiding] Journal of
Theoretical and Applied Information
Technology, 28th February 2015. Vol.72
No.3.Hlm.431
Dennis,A;Wixom,B.H dan Tegarden,D.2009.System
Analysis Design UML Version 2.0 3rd
Edition. New York : John Wiley &Sons,Inc.
Kendall J.E & Kendall K.E. 2011. System Analyst
and Design 8th Edition. New Jersey :
Prentice Hall.
Palmer,S.R & Felsing.J.M.2002. A Practical Guide
to Feature-Driven Development.Upper
Saddle River,New Jersey : Prentice-Hall
Sommerville,Ian. 2009. Software Engineering 9th
Edition. Boston : Addison-Wesley.
Tripathy,P & Naik .K. 2014. Software Evolution and
Maintenance: A Practitioner’s
Approach.New York : John Wiley
&Sons,Inc.
Valacich,J.S;George,J.F & Hoffer,J.A. 2012.
Essential of Systems Analysis and Design 5th
Edition. New Jersey : Prentice Hall.
Zave,P.1997. Classification of Research Efforts in
Requirements Engineering. ACM Computing
Surveys, 29(4),315-321.
View publication statsView publication stats