Student admission system is a mechanism for selecting a new student in higher education, including at State University of Jakarta. The mechanism of student admission system in State University of Jakarta includes a sequence of processes starting from registration, determination of tuition fees, until students who are accepted to pay the first tuition that has been determined. Student admission system is expected to be able to find out the number and distribution of applicants for new student registrants, which will have an impact on university accreditation and the increase of new students who have good quality . So far, State University of Jakarta has an information about each admission. So that there is an inequality data between one department to another for total number of new student. In addition, there is still little information presented to prospective students who are accepted at State University of Jakarta regarding campus life, study fees, scholarships and so on.
One of the information systems that must be well designed for State University of Jakarta is student admission system. State University of Jakarta has started PENMABA since 2012 but until now it has always undergone changes and improvements from year to year, both due to changes in regulations and changes in system requirements. Based on interviews with head of Student Admission System, Mr. Ifan Iskandar, the obstacles faced by Student Admission System 2015 version are:
• There is still a peak load to access student admissions, at the time after the announcement of the SBMPTN and at the end of the closing of the registration PENMABA, which resulted in the system being difficult to access.
• There is no system that integrates student admissions for the entire entrance.
In addition to technical problems, there are other obstacles including:
• There is a change of policy from year to year regarding the Student Admissions System
• Slow distribution of information from higher level of management to the development team which results in a delay in the system development work schedule
• So far building an information system at State University of Jakarta has not begun with analysis and design, but directly into implementation. So that the requirements often missed and the bug fixes are hampered.
2. Literature Review
Reuse oriented software engineering
Software reuse is the process of implementing or updating a software system using existing software components. The process increased productivity, quality, and reliability, and decreases costs and implementation time. In short, the development of reuse processes and repositories results in a knowledge base that improves quality after reuse, minimizes the amount of development work needed for future projects, and ultimately reduces the risk of new projects based on repository knowledge . In most software projects, there are several software reuses. This often happens when people who work on projects know that a design or code is similar to what is needed. They search, change as needed, and combine them into their systems . The type of Software Reuse are:
• Application System Reuse, recombines all applications by combining one application into another (COTS reuse) or creating an application family such as MS Office.
• Component Reuse, the component (subsystem) of one application is reused into another application.
• Function Reuse, reuse software components that implement a well-defined function.
Feature driven development (FDD)
Feature Driven Development (FDD) is a process that is designed and implemented to present the results of work repeatedly in a certain time and can be measured. FDD is an approach that refers to making systems using methods that are easy to understand and implement, problem solving techniques, and reporting that are easily understood and controlled by stakeholders .
An important element in FDD is the feature. Palmer and Felsing (2002) define features as: " action result object " where object can refer to a person, place or thing. FDD focuses on continuous processes, integration and small releases, which reduce conflicting changes and shorten the feedback cycle by providing fast feedback and improvements.
FDD consists of five series of processes in designing and building a system. The iterative part of the FDD process (Design by Feature and Build by Feature) supports the development of Agile with a fast adaptation process to change requirements and business needs.
The following of FDD processes according to Palmer and Felsing (2002):
• Develop an Overall ModelIn this phase the overall problem domain description is compiled. After gaining an understanding of the functions of business needs, domain expertise, and the overall scope of the project, the Domain Expert starts the entire design model. Documented requirements are governed by appropriate cases and technical specifications.
• Build a Feature ListFeature list is what the client sees for the validity and completeness of the system. The language used is as simple as possible so that the client understands. In the next stage after determining the entire system set, developers must now identify what features can be made in the list of each module produced. The following pattern defines a feature according to Coad (1999): action the result by | for | of | to a (n) object Where an object is a person, place, or something.
• Plan by FeatureThis phase is an initial activity that produces a development (Design and Build) High-Level Plan. This High-Level Plan contains all features, based on their priorities and dependencies.The Project Manager, Development Manager, Chief Programmer and other Actors act together to prepare sequential lists of all the features listed in phase 2, and sort features based on their priorities. Identifying interdependencies between features before implementation is an important part of this phase.
• Design by Feature and Build by FeatureAfter getting the feature set listed with priority, the Class Owner helps form their feature team.Each iteration is generally scheduled for 2 days to 2 weeks. In this phase, the system goes through sequential processes of product development: Designing, Development, Testing, Integration and Testing Systems. After a successful iteration, the finished feature is driven to the main build, while the next design and build iteration starts with a new set of features.
Specification and analysis of old system
Actors in the old system are as follows:
The next step is to find a use case. Use cases can be seen through the old system source code and in the Software Requirement Specification (SRS). The list of old system use cases are:
In the old system database, there are 24 tables. Based on the existing source code, from all tables in the old system database, there are 8 tables that are not used. Based on interviews with interviewees and seeing from old system source code, there were several problems experienced when the old system took place, including:
Modification is done by adding, changing or removing the requirements, both functional requirements and non-functional requirements to improve the quality and fulfillment of functional requirements. List of system modifications as follows:
Designing new system
Determination of main feature
The first stage in making a requirement list is determining the main features. The main features between the old and new system have not changed much, only added recapitulation of the remaining room and seats, recapitulation of those who have already paid and recapitulation of skills tests that have been paid, while announcement management is omitted due to the system being unable to use in old system. The main features at new system of Penmaba Mandiri are:
Functional requirement and functional area list
The next stage is to make a list of functional requirements. Requirements in the old system are developed with added, modified or deleted requirements based on the current policies. Then, functional requirements are collected based on the level of the user (Registrants, Participant, Admin, Helpdesk, Committee) and grouped based on the similarity of features and dimensions called functional area. After that, coding and labeling are given on the functional requirements list starting from RPM001. RPM which means "Requirements Penmaba Mandiri" and 001 is freely chosen.
Generalization is a stage of functional requirement efficiency in order to divide the work area domain. Members of the developer team will work on the project based on the division of the area domain that has been received. Area domains are generalizations of requirements and domain as a whole.
Build a feature list
After creating tables resulting from generalization requirements, then the requirements are made into feature sentences. The following is a partial table of feature rule changes based on generalizing requirements:
Build a feature set
To facilitate tracking the process between features, a coding is given for each feature and also includes the active subject or actor who uses the function. Checklist marks indicate the relationship between features and subject. For more details, there are partial results from the following set features:
After analyzing Penmaba 2015 version system and designing it on 2018 version, can see a differences in total of functional requirement. In the Penmaba 2015 version there are 48 user functional requirements and 77 admin functional requirements. With five actors, namely Admin, helpdesk, vice of rector, BAKHUM, registrants and participants, also added web service features and several features additional in the requirements of 2018 version.
Redesigned the database to tidy up relationship between data, addition of reference tables and addition of tables due to additions feature. After it was designed, it became 24 tables in 2018 version. In 2018 version design there are additional features, namely recapitulation of remaining location, recapitulation for skills test, and transaction log. In addition, there are changes in the actor, in 2015 version there are six actors, there are, participants, admin, helpdesk, vice of rector, and BAKHUM, while in 2018 version becomes only three actors there are participants, admin, and helpdesk. Vice of rector and BAKHUM were removed because in 2015 version, they are never opened the system and only rely on printed recapitulation provided by the admin or helpdesk. In addition, the addition of web services on this system to reduce load on the system itself. So when the system is accessed by many users it does not reduce the performance of the system itself.
Reuse-oriented can be applied in the development of an information system and be able to shorten the time of system development, and the application one of the Agile Methods, Feature Driven Development (FDD) can also be done with the aim of simplifying searching if there is an error in testing the final application and can be used as reference to further project development at State University of Jakarta. In the future, this system will through usability testing to measure the effectiveness of the user interface based on input and complaints from users in 2018
This work was supported by the admission of new student office (Panitia Seleksi PENMABA) and the vice of rector 1 for students affair.
The authors would like to thank Mr. Muchlis R.Luddin as vice of rector 1, Mr. Ifan Iskandar as the head of admission of new student and Mr. Agung Premono as the secretary of admission of new student for their comment and suggest regarding development of new system. We also would like to thank all the member of Technical Implementation Unit of Information and Communication Technology for their support and advice about this research