A Web-Based Rapid Prototyping Workflow Management Information System for Computer Repair and Maintenance

: Problem statement: Response to paper-based requests for computer and peripheral repair and maintenance has become very troublesome and slow due to the large demand and expansion at the University of Jordan. The objectives of this study were to: (i) investigate the current system processes associated with the paper-based workflow system. (ii) design and implement, using a suitable workflow management approach, a totally electronic alterative to improve performance. Approach: The methodology followed in the transform of the business processes from the paper to the electronic-based was using the rapid prototyping workflow management approach. This approach is seen to be especially effective in such cases where there is direct continuous interaction and involvement between the different stakeholders during the lifecycle of the project. Results: The system had been implemented and tested with the result that efficiency, accountability and response time have greatly improved in handling repair and maintenance orders. The transform from paper to electronic resulted in greatly enhanced user satisfaction especially since the developed system provided automatic feedback regarding order status. Conclusion: The design process and results provide a working blueprint for easy and quick various similar university-based business processes to be transformed to electronic. This should highly motivate internal in-house restructuring of business process to utilize technology and IT to enhance performance and accountability.


INTRODUCTION
In today's information technology society, it is no longer acceptable nor is it cost conscious to keep to the old paper-based approaches in managing business processes. Therefore, it is not surprising that from early on, serious efforts were directed at utilizing whatever technologies were available at the time, to automate repetitive tasks using IT [1] .
In the field of equipment management, many efforts were attempted. A multi-user computer system for the management of hospital equipment including repair requests, inventory control, repair costs and service records was described by Whelpton and Cooke [2] . The system uses a relational database together with personal computers. However, data entry transferred from study requests is done by only one user and there is no methodology to follow up requests or monitor activities. A similar system that manages information used for the management of preventive maintenance and equipment repairs at the University of California Berkeley was also described by Mudie and Chang [3] . The system provides technicians and management with a tool for monitoring equipment maintenance events, reviewing equipment history and resolving equipment malfunctions. The system allows equipment users to report faults which are automatically forwarded by email to maintenance staff. A relational database is used to store information regarding events. The system lacks online direct monitoring of events and status. It delegates the management of all events to the maintenance staff which reduces accountability.
Recently, it has been shown that projects developed using traditional software lifecycle models such as the waterfall model typically fail for several reasons, namely: output-driven orientation of design process, application backlog due to the document maintenance workload and user dissatisfaction [4,5] . For small and medium sized systems, a development methodology based on rapid prototyping approach is intended to correct these shortcomings and to bring a software project closer to its user(s). After several iterations of the prototype, the developers have a better understanding of the requirements and the users have a better idea about how the system will eventually look and feel. For large systems, the prototype based methods have difficulty in identifying the global aspects and boundaries of the project and design inconsistencies and shortcomings [5,6] However, despite their difficulties in large system developments, prototype-based methods have been a hot topic in software engineering for more than a decade. Different design models for workflow management systems have been reported in literature, using: Petri Nets [7] , agent technology [8] , knowledge-based [9] , document-based [10] and more recently object-oriented modelling. When compared to other modelling methods, the objectoriented modelling approach offers improved flexibility and adaptability [11] .
In the present study, the architecture, development methodology, design models and implementation of a new web-based workflow management information system for computer repair and maintenance in the Faculty of Engineering and Technology (FET) at the University of Jordan is presented. The choice to transform the paper-based repair system business processes to an electronic form was first evaluated for suitability, based on the following factors: • The processes required people to be notified of events as they occurred (request progress) • Processes were approval-oriented (there is a management and control hierarchy in FET) • The processes cross functional and/or department lines (repair requests are directed from departmental or managerial units to an independent repair and follow-up section) • Processes where workflow will add value to stakeholders (expected reduction in time, effort and supervision and workload distribution) • Automation of processes contributes towards university goals (there is a clear direction towards process automation using modern IT structures in the University of Jordan) • Automation has potential for significant improvements (requests can be remotely monitored and repair workers are directly accountable. The system has the potential to grow and interlink with university IT systems) • Processes are feasible to redesign (since the processes involved already are form-based with a clear flow, then it is totally feasible) Problem background: The FET at the University of Jordan is one of the largest faculties in the university. It consists of eight academic departments and four associated administrative and technical units, of which the centralized computer labs are the subject of this project. The working environment in all these departments/units is completely intra and inter networked. FET is planning to gradually transform all administrative and communicative work to become electronic. Part of the plan focuses on semi automating the workflow processes of maintenance and repair requests in the centralized computer lab to become completely web-based. This goal can be achieved by using an appropriate information system that is capable of dealing with different types of web-based transactions such as new user registration, submission of repair and maintenance orders, distribution of work items (tasks), viewing and reporting various reports.
Such a system will enable all stakeholders to closely follow-up the progress of orders and get timely notification of status. Such a system will also allow monitoring of personnel performance and may help in optimizing the allocated jobs and time distribution.
The existing system involves a conventional paperbased process for order management. This process deals with order submission and workflow control activities as shown in Fig. 1. The main drawbacks for the existing workflow management system can be summarized as follows: • Long lag time between order submission and service operation • Lack of a balanced service staff load distribution facility, which leads to lax accountability and low productivity • Nonexistent reporting of the different system variables which hinders the long term planning and expansion of the system • Reduced reliability and productivity as there have been no procedures to follow-up the order and identify its current status • Low user satisfaction due to all of the above

Proposed system overview:
In addition to reengineering the order management process mentioned above, the proposed system is supported by several newly added processes, namely: User management, report generation, real-time end-user follow-up and a configurable management path. Figure 2 overviews the proposed web-based workflow management system.

System architecture and features: Database
Management Systems (DBMSs) are commonly configured using a three-tiered architecture which is appropriate for Internet applications. This architecture is therefore considered appropriate for the proposed workflow management system [12] . The tiers of the proposed architecture can be seen as having clients at the front end, services at the middle tier and data storage at the back end. Recent advances in Internet technology and the availability of suitable software environments offer the possibility of using different implementation strategies and tools. Figure 3 shows the architecture based on a Java 2 Enterprise Edition (J2EE) platform which is proposed for the Workflow Management Information System (WFMIS) under consideration.
When the web browser is used as the client interface, J2EE specifies the use of Servlets and Java Server Pages (JSP) technology to generate web pages. JavaBeans are used to encapsulate business logic and to connect to the data tier through drivers based on a Java Database Connectivity (JDBC) standard. In the present research, the Relational DBMS (RDBMS) is considered in response to the constraints specified by the client. In addition, the Simple Message Transfer Protocol (SMTP) is used to exchange messages between the application server and system users through an existing SMTP server. Methodology and scenarios: The object-oriented development process adopted in this study is started with an envisioning and requirement analysis phase where the system is divided into several subsystems. The process then proceeds with three iterative phases related to the subsystem's development; design, programming and evaluation. Each subsystem cycle is expected to take one to three weeks, as shown in Fig. 4. Finally, the system development process is completed by integrating the developed subsystems and evaluating the complete system prototype. Process scenarios of the WKFMIS include four processes: user registration and management, order submission and management, e-mail notification and reporting. Of these, the latter two processes are newly added processes to the existing paper-based system. This architecture divides the functionality among objects involved in maintaining and presenting data to minimize the degree of coupling between the objects [13] .
User registration and management: User registration starts by filling in the required information in a registration form. Once completed, the registration form is sent to the corresponding department manager for approval. Upon approval, the system automatically updates the user status, notifies the FET user via e-mail and sends the registration form to the administrator. The administrator then activates the user by updating the user's status in the database. Upon user activation, the system automatically notifies the newly registered user via e-mail. Other users (i.e., the corresponding departmental manager, lab. manager and the FET Dean) can also be notified depending on the configurations of the corresponding contacts profile. Figure 5 shows the MVC architecture of the user registration and management process.
Order Submission and management: Similar to the user registration and management process, the order submission and management process starts by filling in an order form. Once completed, the order form is sent to the corresponding departmental manager for approval. Upon approval, the system automatically updates the order status, notifies the FET user via email and sends the order form to the lab manager. The lab manager then specifies a target completion time (in days) and forwards the order to one of the lab workers. The system also notifies the FET user, departmental manager and the assigned lab worker via e-mail. The lab worker will then perform the required service and update the order status according to the work progress until completion. For each order status update (e.g., started, pending, overdue or completed), the system sends email messages to the corresponding users. Submitted orders can also be cancelled by the users who have ordered them.. The MVC architecture of the order submission and management process is shown in Fig. 6.

E-mail notification:
This process aims at generating automatic e-mail notifications to all system users depending upon certain process events related to each user type. Table 1 summarises the events for which system users receive email notifications. The actor that initiates each event is designated with symbol (*) and the users to whom the messages are sent, are identified by shaded rectangles, as illustrated. The MVC architecture of the e-mail notification (contact) process is shown in Fig. 7. Reporting process: This process aims at preparing and printing various types of reports. The contents of these reports vary depending on the user type. For example, FET users are allowed to prepare and print reports related to their own orders while the FET Dean can prepare reports on all orders and users existing in the system database. The contents of these reports can be filtered by status, department and time period. Table 2 summarises the types of reports which can be prepared by each user type. Unlike other processes, this process only retrieves, views and prints order-related and userrelated information existing in the system database. Figure 8 shows the MVC architecture of the reports process.

UML design models:
The object-oriented design process adopted in this work involves the development of several design models. These models which are essentially the system design represent a bridge between the system requirements and its implementation.  The Unified Modelling Language (UML) provides more than 10 different static and dynamic models that may be produced to document a certain system design [13,14] . For brevity, the models presented are limited to the static model (object-classes and their relationships), dynamic structure (the interactions between system objects, using collaboration diagram) and specification of object interfaces. The Entity Relationship (ER) diagram of the database design is also presented.
Static structure: The object-based design processes involve static models which describe the static structure of the system using classes and their relationships. A class diagram can be defined as a diagram that shows a set of classes, interfaces and their relationships. The purpose of a class is to specify a classification of objects and to specify the features that characterize the structure and behaviour of those objects [15] . The structural feature of the class is its attributes and the behavioural feature of the class is operations [16] . Several types of relationships can exist between classes such as realization, dependency, aggregation, composite aggregation and generalization [15,16] . However, the identified relationships between classes of the WKFMIS are based on the first three types of these relationships, as shown in Fig. 9.
Dynamic structure: The collaboration diagram is used to model the dynamic behaviour of the WKFMIS. Each message defines a particular communication between objects in an interaction. Developing a collaboration diagram for a web based application faces difficulty in modelling a JSP as a single class. This defeats the modeling objective in identifying the architecturally significant pieces within the model in their appropriate context. To overcome this difficulty, the UML extension mechanisms are used to partition each JSPinto two conceptual elements [15; 17] , namely; client page and server page.
The relationship between these pages is also special and is defined as a <<Build>> relationship [17] where the server page builds a client page. When a server page builds a client page, the result is an HTML stream that is sent to the browser through which the request was originated. Database schema: As most processes in the WKMIS are stateful and must survive a restart of the runtime engine, the business process implementation requires a persistent data store so that the process state is kept current in case of engine recovery. The data store is modelled as a normalized relational database schema, referred to in this study as "DFET". DFET design is preceded by a stage of data gathering and analysis. This includes analysis of what kinds of information are expected to be retrieved, by system stakeholders, from the database. DFET is composed of five main tables and three utility tables. The main tables include: Employee, Order, Device, Workflow and Contact as shown in the Entity Relationship (ER) diagram of Fig. 10. The utility tables are only used for mapping titles from English to Arabic language (or vice versa) and for mapping some system attributes to pre-defined codes with the aim of simplifying the coding process of the entire system.

MATERIALS AND METHODS
The system was developed and implemented in the Faculty of Engineering and Technology at the University of Jordan. The Database engine used was Oracle 9 running on a Windows 2003 server. The server also was running the J2EE platform which includes Java Server Pages (JSP), Java Beans/Servlets and the Java Dbase connection. Use was made of the University of Jordan mail server using the Simple Mail Transfer Protocol (SMTP) to send the email notifications.

RESULTS
The system is currently implemented and ready for full deployment. Our results indicate that several immediate improvements have become apparent. Table 3 shows extrapolated estimates for performance compared with the original paper-based system.
More than 25 connected pages (JSPs) are designed and implemented to display various types of information. These pages are categorized into six groups: common pages used by most or all users, FET user pages, department manager pages, lab manager pages, lab worker pages and administrator pages. For brevity, however, only samples of these pages are shown in Table 4.

DISCUSSION
The use of the rapid prototyping approach in such a project proved very successful. Several brain storming sessions and feedback took place with all stakeholders. This helped a lot in fine tuning the design. Among the issues uncovered was the deep concern expressed by faculty users due to lack of timely status notification of their requests. This led to the incorporation of automated email status notification after each phase of the request process. Also, the reporting mechanism incorporated was highly appreciated as it allowed close monitoring of activities of all departments and staff and eased informative timely future planning decisions.
The use of the object oriented methodologies together with UML clearly helped in simplifying and structuring the design process. This led to quick implementation and testing which in turn allowed us to quickly gather feedback from users and relate that back to the design requirements. We discovered that this quick and timely activity on our part had a great impact on the administrative and working staff and their interest and collaboration.

CONCLUSION
A web-based workflow management system is presented for the management, follow-up and status update of user requests for computer repair and maintenance at the University of Jordan. The detailed system architecture, models and realization is shown. The motivation and benefits for the adopted system are explored. It is seen that through the direct and constant interaction between system developers, users and administrators, it is possible to easily and quickly transform paper-based business processes with the help of current modelling and implementation technology such as UML and J2EE. The system is currently implemented with very encouraging results. The system design allows easy expansion; therefore, we aim to expand the system to include more automation options in the future. Some of the ideas being considered are: employing a computational intelligence approach for workload distribution to lab workers thus letting the system automatically assigns jobs as they arrive. Also, we are considering introducing extra processes, also based on computational intelligence approaches, to give end users direct solutions to known problems taken from the system database, thus allowing the end users to solve their issues, if possible, without having to register a repair request. The generation of automated daily work schedules for lab workers is also being considered to streamline the workload process.