Sbmptn 2
0 likes299 views
Dokumen ini membahas analisis dan perancangan sistem penerimaan mahasiswa baru di Universitas Negeri Jakarta, termasuk metode pengembangan yang berfokus pada reuse dan fitur. Penelitian ini dilakukan untuk meningkatkan sistem yang ada dengan memperbaiki kendala yang dialami oleh sistem penerimaan mahasiswa baru sebelumnya. Selain itu, penambahan web service dan penerapan Feature Driven Development (FDD) sebagai metode agile diusulkan untuk meningkatkan efisiensi dan efektivitas proses penerimaan mahasiswa baru.
![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](https://image.slidesharecdn.com/sbmptn-2-170512015423/85/Sbmptn-2-11-320.jpg)
Sbmptn 2
- 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