WEB BASED MONITORING AND EVALUATING SYSTEM FOR EXTERNAL QUALITY ASSESSMENTS FOR THE QUALITY ASSURANCE AND ACCREDITATION COUNCIL OF THE UGC

Transcription

1 WEB BASED MONITORING AND EVALUATING SYSTEM FOR EXTERNAL QUALITY ASSESSMENTS FOR THE QUALITY ASSURANCE AND ACCREDITATION COUNCIL OF THE UGC W. P. S. Priyasadini BIT Registration No: R Index No: Name(s) of the Supervisor(s) Mr. N. R. Sembacuttiaratchy Prof. Colin N. Peiris January 2013 BIT This dissertation is submitted in partial fulfillment of the requirement of the Degree of Bachelor of Information Technology (External) of the University of Colombo School of Computing

2 I

3 ABSTRACT The Quality Assurance and Accreditation (QAA) Council is a division of the University Grants Commission which was established in External Quality Assessment (EQA) is one of the main functions of the QAA Council to review the standard and quality of the Higher Education Institutes (HEIs) and its programmes of study and to provide the outcome to all stakeholders to observe their expectations. But there is no organized mechanism to monitor and evaluate the outcome of the EQA conducted in universities. Main modules of the system are University Information, External Review Process, Accreditation Process, Impact of EQAs, Outcome of the EQAs, Monitoring and Evaluation of the EQAs, Cost Analysis for EQAs, Reviewers Database, In-Progress Review of EQAs, Login and Enquiry System. It provides user friendly, accurate and up-to date information System users are in different geographical locations and therefore, a web based approach was selected to develop according to the object oriented principals by using Rational Unified Process (RUP) and Unified Modeling Language (UML) as development methodology and designing language respectively. PHP, CSS, Javascript was used to develop the main system, make user interfaces, client-side validation respectively and MySQL was used to handle all the database development. Finally, the system has been developed helped to overcome the existed problem and this information provide the UGC/Ministry/other Donor Agencies with basis for policy options on higher education and informed decisions for development assistance. II

4 ACKNOWLEDGEMENT First and foremost I would like to express my sincere thank to Prof. Colin N. Peiris, Director of the QAA Council to accept my request to develop this system as well as constant support, guidance and encouragements given throughout the process as a CoSupervisor. Facilitating to arrange relevant meetings with the stakeholders and the university officials for providing additional information, comments/feedback during this process without any hesitation would be appreciated very much. My gratitude goes to Mr. Nishan Sembacuttiaratchy for his guidance and valuable inputs given to me to complete this project on time without having any difficulty. I also must thank the Academic and Project Coordinator and the e-facilitator of the project, BIT-UCSC to provide relevant information and quick response to my clarifications. Special thank goes to the Lecture Panel of the ESOFT Computer Studies (Pvt) Ltd. for giving me the academic knowledge for the BIT Degree Program. I am also grateful to thank all the parties who helped me to achieve this successfully. At last but not least, my heartfelt gratitude goes my parents, family members and friends for your support at all times. III

5 CONTENTS DECLARATION... I ABSTRACT... II ACKNOWLEDGEMENT... III CONTENTS... IV LIST OF FIGURES... VII LIST OF TABLES... IX LIST OF ACRONYMS... XI CHAPTER 1 INTRODUCTION Background of the Client Brief Description of the Project Current System Motivation to this Project Project Objectives and Goals Limitations of the Present System Scope Structure of the Dissertation... 4 CHAPTER 2 ANALYSIS Introduction Feasibility Study Requirement Analysis The Process of Determining Requirements Stages of the Requirement Development Users of the M & E System for EQAs in Universities Fact Finding Techniques Literature Survey of Similar Systems Functional Requirements IV

6 2.8 Non-Functional Requirements Methodology for Proposed System CHAPTER 3 DESIGN Introduction Design Techniques Adopted Alternative Solution Selected Solution Description/Justification Decisions taken during the Design Process Reasons to use PHP as the developing language and MySql as the database development tool 3.5 System Design Process Identification of Use Cases Activity Diagrams Sequence Diagrams Identification of Classes Database Design Normalization Entity Relationship Diagrams Interface Design Design Principles Major Decisions taken during the Interface Design Home page of the system Cost Analysis for EQAs Online Enquiry CHAPTER 4 IMPLEMENTATION Introduction Implementation Environment Module Structure Major Code Segments Database Connection Login Module V

7 4.5. Re-used Codes CHAPTER 5 TESTING AND EVALUATION Introduction Verification and Validation Software Testing Techniques of Testing Types of Testing Test Plan and Test Cases Traceability Matrix User Evaluation Acceptance Testing by Users CHAPTER 6 CONCLUSION Critical Evaluation Additional Features Implemented Enquiry System Modules Partially Implemented Accreditation Module Further Improvements Lessons Learnt, Knowledge & Skills gained REFERENCES APPENDIX A SYSTEM DOCUMENTATION APPENDIX B DESIGN DOCUMENTATION APPENDIX C USER DOCUMENTATION APPENDIX D GENERATED REPORT APPENDIX E TEST RESULTS APPENDIX F CODE LISTING APPENDIX G CLIENT CERTIFICATE GLOSSARY INDEX VI

8 LIST OF FIGURES Figure Identified different levels of system users... 9 Figure 2.2 Similar System Figure 2.3 Similar System Figure Rational Unified Process Model Figure (4+1) view of the UML Figure 3.2 Stages of Modeling and related UML Diagrams Figure Top level USD of the M & E System of the EQAs Figure Activity Diagram for Outcome of the EQAs Use Case Figure Sequence Diagram for Outcome of the EQAs Use Case Figure Package Diagram for the entire M & E system Figure 3.7 Attributes and Methods of the Classes Figure Class Diagram for the entire M & E System of the Figure 3.9 Entity Relationship Diagram for the entire M & E System Figure Home Page of the System Figure 3.11 Interface of the Cost Analysis for the EQA Figure 3.12 Online Enquiry Form Figure 4.1 Network Diagram for the Actual Implementation of the System Figure 4.2 Module Structure of the System Figure A.1 PHP MyAdmin Import Page Figure A.2 FTP Client Software Uploading Files Figure A.3 File Manager folders and folder hierarchy Figure B.1 Activity Diagram for Monitoring and Evaluation Use Case Figure B.2 Activity Diagram for In-Progress of Review of the EQAs Use Case Figure B.3 Sequence Diagram Monitoring and Evaluation Use Case Figure B.4 Sequence Diagram for In-Progress of Review of the EQAs Use Case 77 Figure B.5 Deployment Diagram Figure C.1 Monitoring and Evaluation System Home Page VII

9 Figure C.2 New User Registration Form Figure C.3 Major Disciplines of the Faculty Figure C.4 Generated Output for the selected University Figure C.5 Generated Output for the Research Output Figure C.6 Generated Output for the Strengths of the Faculty Figure C.7 Cost Analysis for IR Figure C.8 Recommendations addressed by the Faculty Figure C.9 Checklist for Curriculum Revision Figure C.10 Contact Details of Reviewers Figure D.1 Cost breakdown for Subject Review Assessment Figure D.2 Cost breakdown for Subject Review Assessment as a pie chart Figure D.3 University Admission by District in 2009/ Figure D.4 Strength of the Staff in the University of Colombo Figure D.5 Status of Implementing Student Feedback Figure D.6 Impact of Curriculum in Major Disciplines Figure E.1 SQL results of registered New User List Figure E.2 Error message for when data are not available in the table Figure E.3 Display appropriate messages for new user of registration Figure E.4 Display error messages of submitting data field without entering values Figure E.5 Error message for entering different passwords in two cages Figure E.6 Error message for login to the system with empty fields Figure E.7 Error message by entering invalid username or password Figure E.8 User Evaluation Form Figure E.9 Stakeholder feedback for the features of the System VIII

10 LIST OF TABLES Table Analysis of Users for the System... 9 Table 3.1 Comparison among famous methods of implementing systems Table 3.2 Main menus and submenus for users in any level Table 3.3 Main menus and submenus for level 2 and 3 users Table 3.4 Main menus and submenus for users in level 3 users Table 4.1 Implementation Environment Table 5.1 Test Plan for the System Table 5.2 Sample format for Traceability Matrix Table 5.3 Test Case for User Login Table 5.4 Test Case for the Information of the University and Faculty Table 5.5 Test Case for the Process of External Quality Assessment Table 5.6 Test Case for In Progress Review of the EQA Table 5.7 Test Case for Outcome of the EQA Table 5.8 Test Case for Accreditation Process Table 5.9 Test Case for Monitoring and Evaluation of the EQAs Table 5.10 Test Case for External Reviewers Database Table 5.11 Test Case for Cost Analysis for the External Quality Assessment Table 5.12 Test Case for the Enquiry Table 5.13 Test Case for Impact of External Quality Assessment Table 5.14 Template of User Evaluation Form Table A.1 Hardware Requirement Table A.2 Software Requirement Table B.1 - Documentation for the Use Case Display University Information...74 Table B.2 - Documentation for the Use Case In progress Review of EQAs...74 Table E.1 User Login Test Results Table E.2 Information of the University and Faculty Test Results Table E.3 Process of External Quality Assessment Test Results Table E.4 In Progress Review of the EQA Test Results Table E.5 Outcome of the EQA Test Results Table E.6 Accreditation Process Test Results Table E.7 Monitoring and Evaluation of the Test Results IX

11 Table E.8 External Reviewers Database Test Results Table E.9 Cost Analysis for the External Quality Assessment Test Results Table E.10 Enquiry Test Results Table E.11 Impact of External Quality Assessment Test Results Table E.12 Results of Traceability Matrix Table E.13 Evaluation results of stakeholders X

12 LIST OF ACRONYMS ADSL - Asymmetric Digital Subscriber Line AJAX - Asynchronous JavaScript and XML CSS - Cascading Style Sheet DBMS - Database Management Systems ERD - Entity Relation Ship Diagram GUI - Graphical User Interface HTML - Hypertext Mark-up Language OO - Object Oriented OOSP - Object Oriented Software Process PHP - Hypertext Pre-processor RAM - Random Access Memory RUP - Rational Unified Process SDLC - System Development Life Cycle SQL - Structured Query Language UML - Unified Modeling Language URL - Uniform Resource Locator WAN - Wide Area Network WWW - World Wide Web WYSIWYG - What You See Is What You Get XML - Extensible Mark-up Language 1NF - 1st Normalization Form 2NF - 2nd Normalization Form 3NF - 3rd Normalization Form 4NF - 4th Normalization Form 5NF - 5th Normalization Form XI

13 Chapter 1 CHAPTER 1 INTRODUCTION This chapter provides the motivation for the assignment and brief description to the project indicating its objectives and scope. 1.1 Background of the Client The Quality Assurance and Accreditation (QAA) Council was established as a division of the University Grants Commission (UGC) in 2005 and funded by the World Bank sponsored Higher Education for Twenty First Century (HETC) Project has given to Sri Lanka which is an excellent start in implementing almost all of the processes in QA Framework in public Universities. The work of the QAA Council has given Sri Lanka a leadership role in the Asia Pacific Region. The QAA Council is carrying out several activities to gather information in quality culture and sharing good practice to promote quality in the programmes conducted by the higher education institutions. One of the main functions of the QAA Council is to review the standard and quality of the Higher Education Institutes (HEIs) and its programmes of study and to publicize the outcome to all stakeholders to achieve expectations. For this purpose the QAA Council conducts External Quality Assessments (EQAs) for Institutions (IRs), Subject/Programmes (SR/PRs) and Libraries (LRs). 1.2 Brief Description of the Project At present, the QAA Council is able to complete all of the IRs, LRs and 98% of the SRs under the EQAs in public universities during the first Review Cycle. Therefore, it is an urgent need to establish a proper mechanism to monitor and evaluate the progress of the EQAs conducted by the QAA Council of the UGC. The Web based Monitoring and Evaluating System for EQAs for the QAA Council of the UGC is very much needed and appropriate as stakeholders of the system are in different locations. By introducing the web based monitoring and evaluation system the deficiencies in programmes can be rectified and a feedback could be given to the UGC and to the respective university. So that it is easy for them to take decisions in relation to QA activities. 1

14 Chapter 1 Stakeholders of the system are Academics of the HEIs, Relevant Authorities of the Ministry of Higher Education (MoHE) and UGC, Undergraduates, Employers,, Donor Agencies, General Public etc. Since the quality of higher education in Sri Lanka is a very important topic, the system will assist them to enhance their knowledge and ongoing activities in higher education sector in relation to QA. The QAA Council can periodically monitor their activities and keep regular communication with them. 1.3 Current System The QAA Council has completed majority of this task in EQAs for the first review cycle therefore, important information is available to share with others. The present process involved with the completion of EQAs according to the guidelines given in the QA handbook and at the end a final report will be produced indicating its strengths, weaknesses, judgements and recommendations. Finally, a composite report will be produced extracting important information in all reviews in a faculty and it will be submitted to the faculty, university, UGC and the Ministry of Higher Education. However, there is no assurance that the monitoring and evaluation process is observed by any of the above. At present, there is no mechanism to monitor and evaluate the progress and impact of EQAs in universities. Some universities are performing this through Internal QA Unit of their respective university but it is not properly functioning up to the required standard. 1.4 Motivation to this Project Though the QAA Council has completed 98% of the EQAs in first review cycle but there is a lack of proper mechanism to monitor and evaluate the progress and impact of EQAs. Currently, developer of the system is working at the QAA Council and has domain knowledge of the process, frequently access the information and able to maintain constant communication with stakeholders of this project. The UGC could periodically monitor and evaluate the performance of each university and their faculties and also be able to maintain constant communication with stakeholders of this project; Internal QA Units in universities can take follow-up actions accordingly. Since the Internet is an efficient and popular medium, web based 2

15 Chapter 1 approach is the most appropriate for this system and stakeholders can access this information 1.5 Project Objectives and Goals Goals The Internet is an efficient and popular medium, web based approach is the most appropriate for this system and stakeholders can access their information. The QAA Council can periodically monitor and evaluate the performance of each university and faculty and can maintain constant communication with stakeholders through the project. Internal QA Units can take follow-up actions accordingly. Objectives To explain the process of EQAs To provide a user friendly access for information on EQAs in universities To maintain an accurate, up-to date and accessible information on performance of higher education institutes to enable stakeholders for decision making To monitor and evaluate the impact of EQAs in universities ensure that quality learning outcomes are responsive to the changing needs and comparable to international standards; Provide the UGC/Ministry/other Donor Agencies with bases for policy options on higher education and informed decisions for development assistance and incentives to HEIs. The scope of the project will be limited to the automation of the monitoring and evaluation system of the external quality assessments process in universities. Since the external quality assessment is one of the components in QA framework, the main website ( provides a link to the system for additional information. This system consists of three main levels. Home page is accessible for the public and other pages can be accessed through the login system to protect valuable and confidential information. 1.6 Limitations of the Present System Stakeholders may need to get numerous information in relation to the QA in higher education in Sri Lanka. Currently, QAA Council website is one source for them to 3

16 Chapter 1 fulfill their requirement. Since some of the information is confidential, the QAA Council website cannot share them. Therefore, through this system, it will be able to access additional information than web according to the permission given for different stakeholders. 1.7 Scope Institutional (IR), Subject (SR), Library (LR), Postgraduate (PG) and External Degree (ED) reviews are included within the EQAs. Due to time constraint, scope is limited to Monitoring and Evaluating the IR, SR and LR. User and System requirements are as follows. User Requirements Obtaining basic information about universities and faculties Understanding the process of EQAs Monitoring of the faculty in relation to EQAs Understanding the outcome or impact of the EQAs System Requirements should be available whenever user need to access it. information should be highly accurate. Prompt response for request by the user. operations should be easily understood and user-friendly. error recoverable system. 1.8 Structure of the Dissertation Structure of the Report is described below which is prepared according to the BIT Project Guidelines Document. CHAPTER 1 Introduction In this chapter a brief description is given about the project such as to what the project is about, problems with current system, project goals and objectives and system requirements. 4

17 Chapter 1 CHAPTER 2 Analysis This Chapter explains expectations of the reader to understand the report, the similar systems available. Overview of user interfaces, how to communicate with the system by the users and quality of user interfaces along with the design tools are provided in this Chapter. CHAPTER 3 - Design Design part contains the design methodology, design diagrams and various design decisions taken in the project.overview of user interfaces, how to communicate with the system by the users and quality of user interfaces along with the design tools are provided in this Chapter. CHAPTER 4 Implementation An overview about the code and module structures, Implementation environment and development tools, are described in this Chapter with respective reasons for choosing the same. CHAPTER 5 Testing and Evaluation The Test Plan which contains various types of test cases, detail test data and test results of the system are provided in this Chapter. A description of project evaluation procedure, success or failure of the project and lessons learnt throughout the whole project are provided in this Chapter. CHAPTER 6 Conclusion The achievements of the project and enhancements to be made in the future are included in this Chapter. 5

18 Chapter 2 CHAPTER 2 - ANALYSIS 2.1 Introduction Systems analysis is a process of collecting factual data, understand the processes involved, identifying problems and recommending feasible suggestions for improving the system functioning [WWW4]. This involves studying the business processes, gathering operational data, understand the information flow, identifying bottlenecks and evolving solutions for overcoming the weaknesses of the system so as to achieve the organizational goals. System Analysis also includes subdividing of complex process involving the entire system, identification of data store and manual processes. 2.2 Feasibility Study Feasibility should be measured throughout the life cycle [Jeffery L.Whitten, Lionel D.Bentley, Kevin C.Dittman, 2001]. First feasibility analysis is conduct during preliminary investigation phase. At this early stage of the project feasibility is reach more than measure of the urgency of the problem and first cut estimate of development cost. Feasibility can t measure until the problem and requirements are better understood. For all systems, the requirements engineering process should start with a feasibility study [Sommerville, 2009]. The input to the feasibility study is a set of preliminary business requirements an outline description of the system and how the system intended to support business processes. The results of the feasibility study should be a report that recommends whether or not it is worth carrying on with the requirements engineering and system development process. A feasibility study is a short, focused study that aims to answer a number of questions. 1. Does the system contribute to the overall objectives of the organization? 2. Can the system be implemented using current technology and within given cost and schedule constraint? 3. Can the system be integrated with other systems which are already in place? 6

19 Chapter 2 The main types of feasibility studies such as Technical, Operational, Schedule, Economical, and Legal were conducted by the analyst of the proposed system to check whether the above requirements are met. Under the Technical Feasibility checks, whether the client organization has technology and relevant skills to carry out the project. The Proposed system technically feasible because web based approach is the most suitable way to cater the wide variety of stakeholders. Under the Economical Feasibility, checks the financial aspect of the system. The client organization maintains their website and they have virtual server at the ISP at no extra or additional payment for maintenance of the proposed system. No development cost for the system, since developer is currently working at the client organization and no need to purchase any equipment and can be used existing resources. Therefore, the proposed system is economically feasible. The Operational Feasibility covers, whether the right information is given to the right people at the right place on the right time. At present there is no mechanism to monitor and evaluate the progress of the EQAs in universities. The proposed web based approach will be the most appropriate solution to meet this requirement. Generally each project has a deadline. According to the Gantt chart, the developer will implement the system by end of July, 2012 and will meet project deadlines and the schedule feasibility. Legal Feasibility measures how well a solution can be implemented within the existing legal framework. Therefore, there is an assurance that the proposed project meets this requirement. 2.3 Requirement Analysis Requirement elicitation and analysis may involve a variety of people in an organization [Sommerville, 2009]. The term stakeholder is used to refer to any person or group who will be affected by the system directly or indirectly. Stakeholders include end-users who interact with the system and everyone else in an organization that may be affected by its installation. 7

20 Chapter 2 Requirements analysis in systems engineering and software engineering encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product. This takes into account the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. It is an early stage in the more general activity of requirements engineering which encompasses all activities concerned with eliciting, analyzing, documenting, validating and managing software or system requirements. Requirements analysis is critical to the success of a systems or software project [WWW1]. The Requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design The Process of Determining Requirements Once management has granted permission to pursue development of a new system (this was done at the end of the project identification and selection phase of the SDLC) and a project is initiated and planned, you begin determining what the new system should do [Jeffry A. Hopper, Joey F. George, Joseph S. Valacich, 2003]. During requirements determination, you and other analyst gather information on what the system should do from as many sources as possible: from users of the current system, fro, observing users, and report, forms and procedures. All of the system requirements are carefully documented and made ready for structuring Stages of Requirement Development We see four different kinds of requirements; (i) business process reengineering (ii) domain requirements (iii) interface requirement and (iv) machine requirements [Dines Bjorner, 2006]. Conventionally the following terms are in circulation. Functional requirements which approximately cover our domain requirements; User requirements which approximately cover air interface requirements. Non-functional requirements which approximately cover some of our machine requirements; and system requirements which approximately cover some other of our machine requirement. 8

21 Chapter Users of the M & E System for EQAs in Universities Different levels and system users are identified shows in the figure 2.1 Figure Identified different levels of system users According to the figure 2.1, three (3) levels of users were identified and their roles are illustrated in the below table 2.1 User Level Level 1 Level 2 Level 3 Group of Users Employers in the Industry, Undergraduates, and Other Stakeholders Frequency of Usage Variable Registered University Academics, Officials of the MoHE, UGC and QAA Council Variable Officials of the QAA Council and System Administrator All the Time External Reviewers During the Review Visit Job Functions Browsing Information and Making Inquiry. Browsing Information, Providing Information on Present Status of the Faculty/University through Web Forms, Generating Reports & Charts, and Making Decisions based on QAA Council Forecasting. Generating Reports & Charts, Monitoring and Evaluation of the Present Status of the Faculty/University and Forecasting Generating Reports and Giving their feedbacks/comments Security Level Table 2.1 Analysis of Users for the System 9

22 Chapter Fact Finding Techniques To study a system the analyst needs to collect all facts and relevant information [WWW3]. These facts when expressed in quantitative form are termed as data. The success of any project is depended upon the accuracy of available data. Accurate information can be collected with help of certain methods/ techniques. These specific methods for finding information of the system are termed as fact finding techniques. Interview, Questionnaire, Record View and Observations are the different fact finding techniques used by the analyst. The analyst may use more than one technique for investigation. Questionnaires It is the technique used to extract information from number of people [WWW3]. This method can be adopted and used only by a skillful analyst. The Questionnaire consists of series of questions framed together in logical manner. The questions are simple, clear and to the point. This is the cheapest source of fact finding techniques. A questionnaire has been prepared for the proposed project and distributed among members of the UGC, university academics (Vice Chancellors, Deans and Heads), and undergraduates from different years, employees, external reviewers and public. Interviews Formal or informal interviews with stakeholders are part of the requirement for engineering processes [Sommerville, 2009]. In these interviews, the requirements engineering team puts questions to stakeholders about the system that they use and the system to be developed. Several Interviews have been conducted with Officials of the Ministry, UGC, QAA Council, Donor Agencies, Vice Chancellors, Deans and External Reviewers to get their views/suggestions for the system. Viewpoints Typically, these viewpoints provide different types of requirements [Sommerville, 2009]. Interactor viewpoints provide detailed system requirements covering the system features and interfaces. Domain viewpoints normally provide domain constraints that apply to the system. 10

23 Chapter 2 Ethnography This is an observational technique that can be used to understand social and organizational requirements [Sommerville, 2009]. An analyst immerses him or herself in the working environment where the system will be used. It observes the day-to-day work notes made of the actual tasks in which participations are involved. The value of ethnography is that it helps analyst to discover implicit system requirements that reflect the actual rather than the formal processes in which people involved. Developer/Analyst has domain knowledge, since the QAA Council (Client of the system) is the current workplace. Ministry of Higher Education, UGC, University community (academics and undergraduates), External Reviewers, Employees, Donor Agencies, QAA Council and General Public will be the stakeholders of the system. Therefore, their feedback will be equally important when designing the proposed system. 2.6 Literature survey of similar systems A survey has been conducted by the analyst to find the similar system for proposed web based system but there is no similar system exists at present. Higher Education for the Twenty First Century (HETC) World Bank funded Project of Ministry of Higher Education, is conducting a manual system on monitoring and evaluation. Components of the projects are periodically monitored and evaluated the progression and finally report the status to the World Bank to take decisions such as funding etc. In this system each component of the project has to be submitted a progress report to the M & E Division and it will be compared with the target which was identified begging for the particular period and given a feedback. Two web based monitoring and evaluation systems were identified through the literature survey by the analyst but these are not directly related to the external quality assessment process. These systems are illustrated in figures 2.2 and

24 Chapter 2 Figure 2.2 Similar System 1- Figure 2.3 Similar System

25 Chapter Functional Requirements Functional requirements are statements of services the system should, how the system should react to particular inputs and behave in particular situations provide [Sommerville, 2009]. After analyzing the gathered information from different stakeholders it will be assigned to main modules and functionalities listed as follows. 1) Login to the system To maintain secure access of confidential information is the main objective of this module. 1.1 System users have different privilege to access the information of the proposed system and consist of three main levels. 1.2 Level 1 will be accessible to the public, Level 2 accessible only to the registered university academics, officers of the UGC, Ministry and QAA Council and Level 3 accessible only to officers of the QAA Council and External Reviewers. 1.3 New users have to register for the system before accessing the system. 1.4 Administrator will verify information on registered users and assign privilege to access the system. 1.5 Through the validation techniques, unauthorized users cannot enter into the system and relevant messages will be displayed during the incorrect logins. 1.6 Based on the assigned user levels by the Administrator, relevant users will be directing to the relevant interfaces accordingly. 2) Basic information of university/faculty Through this module, users of this system are able to get basic information of the university system by just clicking. 2.1 This module provides updated details about Vice Chancellors, Rectors and Deans; 2.2 Details of faculties, departments and degree programmes offered by these faculties and departments; 2.3 Students intake and distribution among districts to the faculty/degree programme can get dynamically; 2.4 Users can get to know the strength of the staff in the faculty (eg. Number of professors, Ph. Ds etc.); 13

26 Chapter 2 3) Process of External Quality Assessments (EQAs) in HE To make general public be aware regarding the EQA process is the main objective of this module. 3.1 It provides objectives of the EQAs, Aspects of Institutional, Subject and Library reviews; 3.2 Users can get information on key features of the review visit; 3.3 Scale of judgements and external review details will be displayed 3.4 Review details will be displayed in this module 4) In-progress Review of the External Quality Assessments Main objective of this module is to reduced paper base instruction given to reviewers and get their service by efficiently and effectively. 4.1 Checklists are available for reviewers in different aspects in order to indicate the status of the faculty during the site visit. Reviewers can complete this checklist online and send it to the QAA Council for future reference/actions. 4.2 Guidelines for writing the review report also available in this module. 4.3 Draft review report can be downloaded via the particular link during the review visit and reviewers can presents this report at the wrap up meeting to the faculty. 5) Outcome of the External Quality Assessments More information will be provided through this module other than available information in QAA COUNCIL main website. It is very useful for relevant parties to take decisions and improve the quality of the faculty; 5.1 Level 2 and 3 users can dynamically get the review judgements for each and every faculty in universities; 5.2 This module provides strengths and weaknesses of the faculty identified during the review visit separately. 5.3 Overall performance of the faculty in EQAs on academic related aspects can be generated using pie charts; 14

27 Chapter 2 6) Accreditation Process Ultimate goal of this module is to rank the university based on the results/outcomes of the accreditation process. 6.1 Criteria for the accreditation process will be displayed. 6.2 This module covers the checklist and manuals for accreditation in different disciplines; 6.3 Accreditation process will be displayed. 6.4 According to the given marks respected faculty/university will be ranked. 7) Monitoring and Evaluation of the Faculty This is the most important module of this system. Through this module will be able to achieve the main objective of this system. Major indicators of the quality assurance will be monitor and evaluated to check the current status of the faculty and the university in relation to the EQAs. User-friendly web forms have been used for this purpose to maintain effectiveness and efficiently get the responses. 7.1 Authorized parties can log in to the system and using the provided web forms (Google forms) they can be stated whether they addressed the recommendations given by the review panel. The QAA Council can periodically monitor and evaluate the provided information by the university officials. 7.2 Impact of the curriculum revision in major discipline can be viewed. 7.3 Conducted workshops to improve the quality in various aspects will be displayed in each and every university. 7.4 Through this module generates progress reports and schedule dates for process review by mathematical equation; 8) Maintenance of Expert Database Currently, client organization has over 300 records of trained reviewers for EQAs. To select them in a proper way need an efficient updated system. Through this module can be achieve this requirement. 8.1 Reviewers profile, responsibilities and some tips for reviewers can be displayed. 8.2 Administrator will be maintained and updated information of expert database by their disciplines, affiliation and contact details and level 2 and 3 users can be viewed these information; 15

28 Chapter Administrator will be ranked external reviewers such as the number of reviews conducted. Reviewers performance can be displayed according to this ranking system. 9) Cost analysis of the entire faculty for a review The World Bank funded IRQUE Project had been sponsored for the first review cycle and in future activities. University has to bear the cost. Hence, it is very useful for university community to take decisions when they prepare budget; 9.1 Cost breakdown such as transport, accommodation, honourarium fee etc. incurred in Institutional and Subject reviews are displayed in tabular form and generate pie charts for cost breakdown in Institutional and Subject Review for better understanding. 10) Enquiry Those who are interested in quality assurance process can make enquires to get more information 10.1 Display the enquiry form The enquiries will be sent to the administrators for him to take necessary actions. 11) Impact of External Quality Assessment There is an ongoing need to ensure, is there any impact of EQAs. Through this module major indicators rely on the impact will be considered Display the percentage of employment comparison with respect to the recent 3-4 years The impact of the EQAs in relation to the improvement of research output as percentage will also be displayed in tabular format The percentage of Annual GPA with compare to previous situation will be displayed in tabular format by dynamically The impact of getting student feedback and peer observation can be displayed in tabular as well as in graphical format for better understanding and decision making for relevant parties. 16

29 Chapter Non-Functional Requirements These constraints on the services or functions offered by the system are given below [Sommerville, 2009]. They include timing constraints, constraints on the development process and standards. Non functional requirements often apply to the system as a whole. They do not usually just apply to individual system features or services. 1. Accessibility is a general term used to describe the degree to which a product, device, service, or environment is available to as many people as possible. 2. Availability is the degree to which a system, subsystem, or equipment is in a specified operable and committable state at the start of a mission, when the mission is called for at an unknown, i.e., a random, time. 3. Reliability Engineering is an engineering field, that deals with the study, evaluation, and life-cycle management of reliability: the ability of a system or component to perform its required functions under stated conditions for a specified period of time. Reliability Engineering is a sub-discipline within Systems Engineering. It is often measured as a probability of failure, frequency of failures or in terms of availability, which are also a probability and a combined result from reliability and maintainability "performance". 4. Usability is the ease of use and learns ability of a human-made object. The object of use can be a software application, website, book, tool, machine, process, or anything a human interacts with. A usability study may be conducted as a primary job function by a usability analyst or as a secondary job function by designers, technical writers, marketing personnel, and others. 5. Accuracy is one of the major aspects of the non-functional requirements. System has to be provided accurate, up-to-date and accessible information on performance of higher education institutions to enable stakeholders for decision making. Since the system provides much confidential information accuracy is a critical functionality. 6. Accessibility/Availability is also important since, the system is a web based and stakeholders are in different location. Users can always access and get information from the system in timely manner. For decisions making purpose also relevant information has to be available then and there when accessing relevant parties. 7. User Friendliness is one of the objectives of this system. Adding and updating information are mainly done through online forms and the system will be accessing 17

30 Chapter 2 various types of stakeholders the instructions have to be simple and understandable. Thus user friendliness is very much needed. 2.9 Methodology for Proposed System Rational Unified Process (RUP) is an object-oriented and Web-enabled program development methodology [WWW6]. According to Rational (Developers of Rational Rose and the Unified Modeling Language), RUP is like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development. RUP and similar products such as Object-Oriented Software Process (OOSP), and the OPEN Process are comprehensive software engineering tools that combine the procedural aspects of development (such as defined stages, techniques, and practices) with other components of development (such as documents, models, manuals, code, etc.) within a unifying framework. The RUP lifecycle comprises four main phases namely: inception, elaboration, construction and transition. Brief description about each phase is follows: Inception Phase - The life-cycle objectives of the project are stated, so that the needs of every stakeholder are considered. Scope and boundary conditions, acceptance criteria and some requirements are established. Elaboration Phase - An analysis is done to determine the risks, stability of vision of what the product is to become, stability of architecture and expenditure of resources. Construction Phase - The Construction phase is a manufacturing process. It emphasizes managing resources and controlling operations to optimize costs, schedules and quality. This phase is broken into several iterations. Transition Phase - The transition phase is the phase where the product is put in the hands of its end users. It involves issues of marketing, packaging, installing, configuring, supporting the user-community, making corrections, etc. Figure 2.4 illustrates the phases of the RUP life cycle. 18

31 Chapter 2 Figure 2.4: Rational Unified Process Model (Source: wikipedia.org/wiki/unified_process) 19

32 Chapter 3 CHAPTER 3 DESIGN 3.1 Introduction System Analysis emphasizes on the business problem whereas System Design emphasizes on the technical or implementation concerns of the system and it produces a design specification for the new system [Sommerville, 2009]. The design inputs, outputs, files, databases and other computer based components are also known as physical design. System Design is a completely problem solving technique that reassembles a system component pieces back into a complete system [Jeffery L.Whitten, Lionel D.Bentley, Kevin C.Dittman, 2001]. This may involve adding, deleting, and changing pieces relative to original system. Architectural design is a creative process where someone tries to establish a system organization that will satisfy the functional and non-functional system requirements. Because it is a creative process, the activities within the process differ radically depending on the type of system being developed, the background and experience of the system architect, and the specific requirements for the system. 3.2 Design Techniques Adopted Object-Oriented (OO) analysis and design methods are becoming the most widely used methods for computer systems design [WWW1]. Unified Modeling Language (UML) has become the standard language in QA Analysis and Design. It is widely used for modeling software systems and is increasingly used for high designing non-software systems and organizations. The OO programming can promote better code re-use to hold down programming costs. Also it is more appropriate for projects where geographically separated groups of programmers have to collaborate to produce integrated system. Object-Oriented (OO) technique was used to design the proposed system based on the above mentioned reasons. The UML was selected as the design language, PHP is used as the development language and MS Visio version 2007 was used to draw wide range of diagrams for the proposed system. 20

33 Chapter 3 Adobe Dreamweaver and Adobe Photoshop were used to design the user interfaces. The business logic was designed using use cases, class, activity and sequence diagrams. MySql is used as the database development tool. UML consists of 5 views as illustrated in figure 3.1 and it covers all the stages of System Development Life Cycle (SDLC), as shown in figure 3.2. Figure 3.1-5(4 + 1) view of the UML Figure 3.2 Stages of Modeling and related UML Diagrams (Source: UML for Database Design, Eric J Naiburg, Robert A. Maksim Chuck 2011) 21

34 Chapter Alternate Solution Selected Solution Description/Justification Main reason of choosing the web based approach is the request has been made by the client. The client official web site is popular internationally and, they want to develop and implement this system as a web-based system in order to share this idea among them since this the first web based monitoring and evaluation system for EQAs according to the literature survey has been done by the developer. Table 3.4 illustrates the reasons to be chosen a web based system and client is requested particularly a web based system. Web-based System Software is accessed from anywhere with a standard browser and an Internet connection. The database is centralized and therefore, maintenance is easy. Stakeholders/users of the system are in different geographical locations. No additional cost since the system will be implemented as a sub link of the home page in the client web site. User interaction is high and response time will be less. System would be platform independent. Easy to monitor and make timely decisions. Single point of maintenance (web server i.e apache, xmapp) Client-server System User must be on the local network to access the software unless company has invested in a remote access application. Issues with upgrades are difficult. Initial cost of the system could be high. Licensing may be required Stand-alone System Most of the standalone systems are platform dependant, Setting up the particular operating environment could be very expensive. The deployment, updating, maintenance processes are time consuming, as every terminal must be maintained individually. The standalone systems are confined to a physical location and hence have usability constraint. Table 3.1 Comparison among famous methods of implementing systems 22

35 Chapter Decisions taken during the Design Process Reasons to use PHP as the developing language and MySql as the database development tool Using PHP scripting and MySQL database enables programmers to create applications that will run on just about any computer, regardless of operating system [WWW12]. PHP has thousands of programming functions to facilitate almost any task. If the computer can run web server software, the PHP/MySQL application is portable across operating systems and environments such as Mac, Linux, Unix, Windows, Internet, Intranet, etc. PHP/MySQL is most often used to create dynamic web sites. On this web site, one script drives about 60 pages of content. Additional scripts are used here to process form data, but that too could be done through the main script using included files. PHP/MySQL projects include forums or communities, organizers, project management tools, calendars, shopping carts, mailing lists, and all sorts of useful applications. Source code for many open source projects is free, while advanced projects often require a registration fee for commercial use. Data can be exported from MySQL for use in spreadsheets or databases on your PC. Similarly, data residing in existing PC spreadsheets and databases can be imported to an online database. The portability of data opens up all sorts of uses, especially for workgroups and for those who need to access data from both home and work. Main reasons for selecting PHP as the developing language and MySql as the database development tool for this system are listed in point form. It is a platform independent language PHP is an open source software therefore, no cost to bear for installing software PHP is a server side language, it can generate dynamic pages PHP can quickly be incorporated into a code generated by WYSIWYG editors No licensing cost thus economically feasible. 23