See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/306060393

ANALISIS DAN PERANCANGAN SISTEM PENERIMAAN MAHASISWA BARU

UNIVERSITAS NEGERI JAKARTA

Working Paper · June 2016

DOI: 10.13140/RG.2.1.3112.2161

CITATIONS READS

0 13,017

3 authors:

Hanifa Fissalma Hamidillah Ajie

Jakarta State University Jakarta State University
2 PUBLICATIONS   0 CITATIONS    18 PUBLICATIONS   5 CITATIONS   

SEE PROFILE SEE PROFILE

Bambang Prasetya Adhi

Jakarta State University
19 PUBLICATIONS   6 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Design and Development of Student Admission System in State University of Jakarta View project

All content following this page was uploaded by Hanifa Fissalma on 12 August 2016.

The user has requested enhancement of the downloaded file.

 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 jumlah dan sebaran pendaftar calon mahasiswa baru,

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
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
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
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
 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.
 2 Calon Peserta
3 Peserta
4 Super Admin
5 Helpdesk
6 Dekan, Rektorat
dan BAAK
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
1 Melihat informasi
Penmaba 2015
2 Daftar
3 Login
4 Pilih prodi
5 Cetak tagihan
6 Upload foto
7 Isi biodata
8 Cetak kartu peserta
User yang terdaftar dengan level biodata sebelumnya.
User sebagai pendaftar namun 9 Monitoring panel Merupakan proses yang
belum melakukan proses digunakan oleh admin pada
pembayaran. admin panel untuk memantau
User yang terdaftar dengan level rekapitulasi.
User sebagai pendaftar dan sudah 10 Upload ruang dan Merupakan proses yang
melakukan proses pembayaran. lokasi digunakan oleh admin untuk
User yang terdaftar dengan level menambahkan ruang dan lokasi
User sebagai super admin, yang jika ruang dan lokasi yang ada
mempunyai kewenangan untuk telah habis atau mendekati
menambah User, lokasi, ruang dan habis.
memantau hasil monitoring panel. 11 Tambah User Merupakan proses yang
User yang terdaftar dengan level digunakan oleh admin untuk
User sebagai helpdesk, yang menambahkan User dengan
mempuyai kewenangan untuk level User tertentu.
melihat data lokasi, ruang. Dan 12 Cetak album dan Merupakan proses untuk
memantau hasil monitoring panel cetak daftar kehadiran mencetak album saat pada satu
User yang terdaftar dengan level ruang telah terisi penuh.
User sebagai dekan,rektorat dan
BAAK, yang mempunyai
kewenangan untuk memantau hasil
Dari use case yang dijabarkan, lalu dibuat
monitoring panel diagram use case nya. Diagram use casenya adalah :
Deskripsi
Merupakan proses melihat
informasi seputar Penmaba
2015
Merupakan peserta yang akan
melakukan proses pendaftaran
pertama kali harus
mendaftarkan Username
terlebih dahulu, untuk dapat
melanjutkan proses selanjutnya.
Merupakan proses
memasukkan Username dan
password oleh semua aktor,
kecuali User
Merupakan proses setelah
terdaftar menjadi User, calon
peserta tersebut diwajibkan Gambar 4(a). Diagram Use Case Sistem Penmaba 2015
untuk memilih jenis ujian dan
program studi tujuan untuk
dapat diproses berapa besar Didalam database sistem Penmaba 2015,
biaya yang harus dikeluarkan. terdapat 24 tabel. Berdasarkan source code yang
ada, dari keseluruhan tabel yang ada di dalam
Merupakan proses setelah
memilih jenis ujian dan database sistem Penmaba 2015, terdapat beberapa 8
program studi tujuan, calon tabel yang tidak digunakan, diantaranya :
peserta mencetak tagihan untuk Tabel 4(c). Daftar Database Sistem Penmaba 2016 yang Tidak
kemudian dibayarkan ke pihak Digunakan
Bank. No. Nama Tabel Deskripsi Alasan
Merupakan proses mengupload 1 Baak_daftar Untuk menyimpan Data untuk
foto yang syaratnya disesuaikan data mahasiswa BAAK sudah
dengan syarat dan ketentuan untuk diserahkan didapat dari
yang telah tercantum pada kepada BAAK tabel peserta
website informasi. 2 berita Untuk menyimpan Semua berita
Merupakan proses untuk data berita yang ada di
mengisi biodata peserta yang sistem
akan digunakan untuk Penmaba 2015
mencetak kartu peserta. ditampilkan
Merupakan proses setelah secara statis
proses pengisian biodata 3 slider Untuk menyimpan Slider
selesai, peserta dapat gambar slider ditampilkan
melakukan cetak kartu peserta dalam secara
dan tidak dapat mengganti isian statis
 4 cadangan Untuk menyimpan Data service. Selain itu,
data mahasiswa mahasiswa mengikuti
cadangan atau cadangan perkembangan zaman
jalur kerjasama sudah termasuk yang sekarang ini
dalam tabel banyak menggunakan
peserta web service
5 Tb_pesertafire Untuk menyimpan Data 2. Perubahan Ubah Subjek Awalnya user admin
data mahasiswa mahasiswa Aktor pada berjumlah 5 aktor,
prodi Fire Saftey prodi tersebut sistem Admin, yaitu : Super admin,
Engineering sudah termasuk baik di Portal Helpdesk, BAAK,
Teknik Mesin dalam tabel Penmaba dan Rektorat dan Dekan.
peserta Penmaba Diubah menjadi hanya
6 kabupatensekol Untuk menyimpan Data kabupaten Mandiri 3 aktor yaitu Super
ah data kabupaten diambil dari Admin, Helpdesk dan
sekolah tabel kabupaten Panitia. Hal ini
7 propinsisekolah Untuk menyimpan Data propinsi dikarenakan aktor
data propinsi diambil dari BAAK, Rektorat dan
sekolah tabel propinsi Dekan tidak pernah
8 Tw_menu Untuk menyimpan Data menu mengakses sistem dan
data menu yang ditampilkan hanya meminta
ada di sistem secara statis rekapitulasi berbentuk
cetak kepada super
admin atau helpdesk.
Berdasarkan wawancara dengan narasumber Aktor panitia
dan melihat dari source code sistem Penmaba 2015, merupakan Panitia
terdapat beberapa masalah yang dialami pada saat Penmaba Mandiri
sistem Penmaba 2015 berlangsung, diantaranya : UNJ
Tambah Tambah fitur Adanya kebutuhan
1. Masih terdapatnya beban puncak yaitu saat rekapitulasi untuk mengetahui
setelah pengumuman SBMPTN dan per bidang jumlah peserta
menjelang penutupan. keahlian berdasarkan bidang
2. Adanya kecenderungan pembuatan multiple keahlian, untuk
nantinya berpengaruh
user. pada ruang ujian
3. Banyaknya tabel di database yang tidak 3. Tambah Tambah fitur Adanya kebutuhan
digunakan. rekapitulasi untuk mengetahui sisa
4. Aktor dekan, rektorat dan BAAK tidak sisa ruang dan ruang dan kursi yang
kursi ujian dipakai ujian
pernah menggunakan akunnya, hanya 4. Tambah Tambah fitur Adanya kebutuhan
mengandalkan laporan cetak yang didapat rekapitulasi untuk mengetahui
dari super admin atau helpdesk. uji jumlah pendaftar yang
keterampilan mengikuti uji
keterampilan serta
4.2. Modifikasi Sistem peserta yang sudah
membayar uji
Modifikasi dilakukan dengan menambah, keterampilan
mengubah atau menghilangkan requirement, baik 5. Lihat log Tambah fitur Adanya kebutuhan
transaksi untuk mengetahui
functional requirement maupun non-functional aktifitas yang
requirement untuk meningkatkan kualitas dan dilakukan oleh admin
pemenuhan kebutuhan fungsional. Daftar modifikasi sehingga jika terjadi
sistem sebagai berikut : perubahan data, dapat
Tabel 4(d). Daftar Modifikasi Sistem diketahui siapa yang
No. Nama Fitur Aksi Alasan bertanggung jawab
Pembuatan Penambahan Adanya kebutuhan pada perubahan data
portal sistem untuk menampung tersebut
penmaba mahasiswa yang Lihat grafik Tambah fitur Adanya kebutuhan
diterima dari seluruh untuk melihat grafik
jalur masuk, tidak jumlah pendaftar
hanya yang berasal secara umum
dari Penmaba saja. berdasarkan waktu
Karena mahasiswa 6. Non- Penjelasan 1. Sistem Penmaba
yang diterima melalui functional rinci Mandiri
jalur SNMPTN dan requirement menggunakan
SBMPTN masih bootstrap dan build
menggunakan cara in php,
manual untuk meminimalisasikan
mengumpulkan design dengan
datanya mengacu pada alur
1. Pembuatan Tambah fitur Pembuatan web pendaftaran dengan
Web Service service dilakukan agar memaksimalkan
nantinya semua fungsi JavaScript untuk
yang dibutuhkan oleh mengakses web
sistem Penmaba dapat service agar
diambil dari web meminimalisasi
 pengambilan data RPP021 menyediakan fasilitas button
secara menyeluruh. buat akun untuk user yang
2. Sistem ditampilkan akan membuat akun
dalam bahasa
RPP026 menampilkan fasilitas isi
Indonesia
biodata terkait pembuatan
3. Sistem harus
akun
tersedia 24 jam dan
360 hari dalam RPP027 user umum dapat mengisi BUAT AKUN
setahun untuk biodata untuk pembuatan
kebutuhan akun
pendaftaran RPP028 menampilkan pesan
4. Sistem tidak boleh
peringatan jika data yang
kehilangan data di diisi calon mahasiswa ada
database
yang kurang atau salah
5. Dapat mendukung
1000 aktifitas 4.3.3. Generalisasi
setiap hari tanpa Generalisasi merupakan tahap pengefisiensi
gangguan requirement dalam rangka membagi domain area
6. Proses login hanya
dalam waktu kerja. Angggota tim developer akan mengerjakan
kurang dari 5 detik proyek tersebut berdasarkan pembagian domain area
yang telah diterima. Domain area adalah
4.3. Perancangan Portal Penmaba penggeneralisasian terhadap requirement dan
4.3.1. Penentuan Fitur Utama domain secara keseluruhan.
Tahap pertama dalam pembuatan daftar Tabel 4(f). Generalisasi Functional Requirement Portal
Penmaba
requirement adalah menentukan fitur utama. Fitur KODE NAMA
utama untuk Portal Penmaba adalah : _REQ GENERALISASI
User : RPP037 admin dapat melakukan
1. Menampilkan informasi umum seputar login
penerimaan mahasiswa baru dari semua jalur RPP038 menampilkan pesan
dan Universitas Negeri Jakarta peringatan jika terdapat
kesalahan pada
2. Login pengisian username atau
3. Buat Akun password
4. Lupa Password RPP081 panitia dapat melakukan
5. Isi Biodata login
Admin: RPP082 menampilkan pesan admin,helpdesk
peringatan jika terdapat dan panitia dapat
1. Login kesalahan pada melakukan login
2. Manajemen user pengisian username atau
3. Manajemen berita password
4. Manajemen beasiswa RPP093 helpdesk dapat
5. Manajemen informasi UKT melakukan login
RPP094 menampilkan pesan
6. Manajemen penerimaan peringatan jika terdapat
kesalahan pada
4.3.2. Daftar Functional Requirement dan pengisian username atau
Functional Area password
Langkah selanjutnya adalah membuat daftar RPP039 admin dapat menambah
data user lainnya sesuai
functional requirement. Functional requirement dengan level usernya admin dapat
dikumpulkan berdasarkan tingkatan user (Calon menambah data
RPP040 terdapat pesan
Mahasiswa, Admin, Helpdesk,Panitia) dan user
peringatan perihal
dikelompokkan berdasarkan kesamaan ciri dan penambahan data user
dimensi yang disebut functional area. Setelah itu,
diberikan pengkodean dan pelabelan pada daftar Tabel 4(g). Hasil Generalisasi Functional
functional requirement yang dimulai dari RPP001. Requirement Portal Penmaba
RPP yang berarti “Requirement Portal Penmaba” KODE NAMA GENERALISASI
dan 001 dipilih secara bebas. _REQ_GEN
Tabel 4(e). Daftar Functional Requirement Dan Functional GRPP001 user umum dapat melihat informasi umum
Area Portal Penmaba GRPP002 calon mahasiswa dapat melakukan login
KODE FUNCTIONAL GRPP003 user umum dapat membuat akun
NAMA GRPP004 calon mahasiswa dapat melakukan lupa
_REQ AREA
RPP020 menyediakan fasilitas button password
login bagi user GRPP005 calon mahasiswa dapat mengisi biodata
GRPP006 calon mahasiswa dapat melihat biodata
RPP033 calon mahasiswa dapat
melakukan login GRPP007 calon mahasiswa dapat mengubah biodata
LOGIN
RPP034 menampilkan pesan GRPP008 user umum dapat melihat informasi
peringatan jika username penerimaan
atau password salah
 4.3.4. Pembuatan Feature List ditambahkan rekapitulasi sisa ruang dan kursi,
Setelah membuat tabel hasil generalisasi rekapitulasi bagi yang sudah membayar dan
requirement, kemudian requirement dibuat rekapitulasi uji keterampilan yang sudah membayar,
menjadi kalimat-kalimat feature. Berikut ini sedangkan manajemen pengumuman dihilangkan
adalah tabel sebagian dari perubahan aturan karena tidak terpakainya fitur tersebut di sistem
feature berdasarkan penggeneralisasian Penmaba 2015. fitur utama di Penmaba Mandiri
functional requirement : yaitu :
Tabel 4(h). Penulisan Feature List Portal Penmaba Front-end:
NAMA FEATURE LIST 1. Informasi umum
GENERALISASI
user umum dapat melihat melihat informasi umum 2. Login
informasi umum 3. Buat Akun
calon mahasiswa dapat melakukan login 4. Lupa Password
melakukan login 5. Pilih paket ujian
user umum dapat membuat akun
membuat akun
6. Pilih program studi
calon mahasiswa dapat melakukan lupa password 7. Cetak tagihan
melakukan lupa password 8. Isi biodata
calon mahasiswa dapat mengisi biodata 9. Cetak kartu
mengisi biodata
calon mahasiswa dapat melihat biodata
melihat biodata Back-end:
calon mahasiswa dapat mengubah biodata 1. Login
mengubah biodata 2. Manajemen user
user umum dapat melihat melihat informasi 3. Manajemen peserta
informasi penerimaan penerimaan
4. Manajemen lokasi
5. Manajemen ruang
4.3.5. Pembuatan Feature Set 6. Cetak album dan daftar hadir
Untuk memudahkan penelusuran proses 7. Rekapitulasi
antar feature, maka diberikan pengkodean untuk 8. Grafik pendaftar
masing-masing feature dan dicantumkan pula
subjek atau pelaku aktif yang menggunakan 4.4.2. Daftar functional requirement dan
fungsi tersebut. Tanda checklist menandakan Functional Area
hubungan antara feature dengan subjek. Untuk Langkah selanjutnya adalah membuat daftar
lebih jelasnya, terdapat hasil sebagian dari functional requirement. Requirement pada sistem
feature set berikut : Penmaba 2015 dikembangkan dengan
Tabel 4(i). Daftar Feature Set Portal Penmaba ditambah,diubah atau dihapus requirement-nya
nomor Subjek feature berdasarkan kebijakan yang berlaku saat ini. Lalu,
feature list functional requirement dikumpulkan berdasarkan
Admin Helpdes Paniti
k a
tingkatan user (Pendaftar, Peserta, Admin,
FSPP009 v v v melakukan Helpdesk, Panitia) dan dikelompokkan berdasarkan
login kesamaan ciri dan dimensi yang disebut functional
FSPP010 v menambah area. Setelah itu, diberikan pengkodean dan
data user
pelabelan pada daftar functional requirement yang
FSPP011 v v v melihat
daftar user dimulai dari RPM001. RPM yang berarti
FSPP012 v mengubah “Requirement Penmaba Mandiri” dan 001 dipilih
data user secara bebas.
FSPP013 v menghapu Tabel 4(j).Daftar Functional Requirement Dan Functional
s data user Area Penmaba Mandiri
FSPP014 v menambah KODE NAMA FUNCTIONA
data _REQ L AREA
beasiswa RPM013 semua user dapat melihat BUAT AKUN
FSPP015 v melihat button menuju buat akun
data RPM020 user umum dapat melihat
beasiswa kolom isian yaitu username,
FSPP016 v mengubah nama depan, nama belakang,
data password, ulangi password,
beasiswa email dan nomor telepon
RPM014 semua user dapat melihat LUPA
4.4. Perancangan Penmaba Mandiri button menuju lupa password PASSWORD
4.4.1. Penentuan Fitur Utama
Tahap pertama dalam pembuatan daftar RPM018 pendaftar dan peserta dapat
melihat kolom isian untuk
requirement adalah menentukan fitur utama. Fitur mengisi alamat email user
utama antara Sistem Penmaba 2015 dengan
Penmaba Mandiri tidak begitu banyak mengalami
perubahan, hanya pada fitur Rekapitulasi
 RPM019 pendaftar dan peserta dapat 4.4.4. Pembuatan Feature List
melihat pesan peringatan Setelah membuat tabel hasil generalisasi
terkait pengiriman email
requirement, kemudian requirement dibuat menjadi
RPM015 semua user dapat melihat LOGIN kalimat-kalimat feature. Berikut ini adalah tabel
button menuju login
RPM016 pendaftar dan peserta dapat sebagian dari perubahan aturan feature berdasarkan
melihat kolom isian untuk penggeneralisasian requirement :
mengisi username dan Tabel 4(m). Penulisan Feature List Penmaba Mandiri
password untuk melakukan NAMA GENERALISASI FEATURE LIST
proses login
semua user dapat melihat melihat informasi umum
RPM017 pendaftar dan peserta dapat
informasi umum
melihat pesan peringatan jika
terdapat kesalahan pengisian user umum dapat membuat membuat akun
username atau password akun
pendaftar dan peserta dapat melakukan lupa password
melakukan lupa password
pendaftar dan peserta dapat melakukan login
4.4.3. Generalisasi melakukan login
Generalisasi merupakan tahap pengefisiensi pendaftar dapat memilih memilih paket ujian dan
functional requirement dalam rangka membagi paket ujian dan program studi program studi
domain area kerja. Angggota tim developer akan pendaftar dapat melihat paket melihat paket ujian dan
mengerjakan proyek tersebut berdasarkan ujian dan program studi yang program studi
pembagian domain area yang telah diterima. sudah dipilih
Domain area adalah penggeneralisasian terhadap pendaftar dapat mencetak mencetak tagihan
requirement dan domain secara keseluruhan. tagihan
Tabel 4(k). Generalisasi Functional Requirement Penmaba peserta dapat mengupload mengupload foto dan mengisi
Mandiri foto dan mengisi biodata biodata
KODE NAMA GENERALISASI peserta dapat melihat foto melihat foto dan biodata yang
_REQ dan biodata yang sudah diisi sudah diisi
RPM013 semua user dapat melihat user umum dapat
button menuju buat akun membuat akun peserta dapat mengubah mengubah biodata
RPM020 user umum dapat melihat biodata
kolom isian yaitu peserta dapat mencetak kartu mencetak kartu ujian
username, nama depan,
nama belakang, password, 4.4.5. Pembuatan Feature Set
ulangi password, email dan Untuk memudahkan penelusuran proses antar
nomor telepon
RPM014 semua user dapat melihat pendaftar dan feature, maka diberikan pengkodean untuk masing-
button menuju lupa peserta dapat masing feature dan dicantumkan pula subjek atau
password melakukan lupa pelaku aktif yang menggunakan fungsi tersebut.
password Tanda checklist menandakan hubungan antara
RPM018 pendaftar dan peserta dapat
melihat kolom isian untuk feature dengan subjek. Untuk lebih jelasnya,
mengisi alamat email user terdapat hasil sebagian dari feature set berikut :
RPM019 pendaftar dan peserta dapat Tabel 4(n). Daftar Feature Set Penmaba Mandiri
melihat pesan peringatan nomor Subjek feature list
terkait pengiriman email feature
user pendaftar peserta
umum
Tabel 4(l). Hasil Generalisasi functional Requirement FSPM001 v melihat
Penmaba Mandiri informasi
KODE NAMA GENERALISASI umum
_REQ_GEN FSPM002 v membuat
GRPM001 semua user dapat melihat informasi umum akun
GRPM002 user umum dapat membuat akun FSPM003 v v melakukan
GRPM003 pendaftar dan peserta dapat melakukan lupa lupa
password password
GRPM004 pendaftar dan peserta dapat melakukan login FSPM004 v v melakukan
GRPM005 pendaftar dapat memilih paket ujian dan login
program studi FSPM005 v memilih
GRPM006 pendaftar dapat melihat paket ujian dan paket ujian
program studi yang sudah dipilih dan program
GRPM007 pendaftar dapat mencetak tagihan studi
GRPM008 peserta dapat mengupload foto dan mengisi FSPM006 v melihat paket
biodata ujian dan
GRPM009 peserta dapat melihat foto dan biodata yang program
sudah diisi studi
GRPM010 peserta dapat mengubah biodata FSPM007 v mencetak
GRPM011 peserta dapat mencetak kartu tagihan
FSPM008 v mengupload
foto dan
mengisi
biodata
 FSPM009 v melihat foto Sommerville,Ian. 2009. Software Engineering 9th
dan biodata Edition. Boston : Addison-Wesley.
yang sudah
diisi
FSPM010 v mengubah Tripathy,P & Naik .K. 2014. Software Evolution and
biodata Maintenance: A Practitioner’s
FSPM011 v mencetak Approach.New York : John Wiley
kartu ujian
&Sons,Inc.

Valacich,J.S;George,J.F & Hoffer,J.A. 2012.

5. Kesimpulan dan Saran Essential of Systems Analysis and Design 5th
Berdasarkan hasil pembahasan penelitian pada Edition. New Jersey : Prentice Hall.
skripsi ini, maka dapat diambil kesimpulan bahwa
reuse-oriented dapat diterapkan didalam Zave,P.1997. Classification of Research Efforts in
pengembangan suatu sistem informasi untuk dapat Requirements Engineering. ACM Computing
mempersingkat waktu pengembangan sistem, dan Surveys, 29(4),315-321.
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

View publication stats