AAUAv's HelpDesk Noddy's Friends Iteration 2: Initial Design and Project Plan

Transcription

1 AAUAv's HelpDesk Iteration 2: Initial Design and Project Plan David Campos, Hugo Picado, Luis Ribeiro, Pedro Alves 1 Overview This project consists of developing a helpdesk system for AAUAv (Academic Association of University of Aveiro). A helpdesk is a troubleshoot platform which aims to provide information and assistance to its users. AAUAv (founded in June, 28 of 1978) is an association directed by students and exists for the institutional representation of students at University of Aveiro and for the promotion of their interests. AAUAv has been contributing to students education, promoting cultural, physical, sport and political/social activities. They act in three distinct fields (academic, political and social) and represent all the enlisted students at University of Aveiro. AAUAv has several affiliated groups related to courses and/or departments which aim to provide localized assistance to the students, as well as organize activities for their members (e.g. workshops, conferences). Also, every year, University of Aveiro has about twelve thousand students, the main concern of AAUAv. Both students and affiliated groups may require, at any time, help on clarify a given subject related to academic issues (e.g. university regulations, questions related to AAUAv activities). Since the board of AAUAv is also composed of students which may not have compatible schedules to help on clarify those issues, they need some other way to fulfill this responsibility which will minimize this inconvenience. A viable solution is a helpdesk system, which enables the members of AAUAv to deal with any questions on an online platform. The helpdesk system will allow students and members of affiliated groups to post any questions which may be answered at any time of day, instead of being restricted to a fixed schedule. For a first implementation, we are planning to focus on the following features: Login; Logout; Logout By Timeout; Encrypted Login information All tickets and respective comments are saved in a data base Four types of Stakeholders: CEO, Administrator, Assistants, User Tickets are only viewable by the user that created it and the help desk staff An administrator may assign a Ticket to a specific Assistant. No other Assistant may answer that ticket Assistants may propose FAQs, which Administrators later deem acceptable or not. Accounts may be edited, or terminated Iteration 2 Noddy's Friends, 2008 Page 1 of 11

2 The high level requirements required to achieve the above features are: Low performance computers (light web system) Internet connection with speed of 256 Kbps or more Data Base to save all information related to the system: Tickets and comments; Assignments; Web Browser Search Function for Users Search Function for Tickets List Function for Tickets List Function for Users The following actions require the date in which they occurred: Stakeholder creation; Ticket creation, and end; Ticket assignment; Comment added; All tickets must be associated with the assistant that answered them The system must be created with a CEO Only the CEO can add Administrator Only Administrators can create Assistants Only Administrators can assign Tickets to Assistants Only Assistants and Users can create comments to a Ticket Iteration 2 Noddy's Friends, 2008 Page 2 of 11

3 These features are the essential features to create a simple helpdesk as first implementation. Other features will be implemented later in future iterations to improve the performance and quality of service of the system, such as the statistics and FAQ. Some GUI sketches were included in the folder gui/ to provide an idea of how the application will appear to the user. 2 Architecture The following figure represents the deployment diagram which is a specification of how the communication between several components will take place. Users will communicate with application server through HTTP protocol and the application server will communicate with the Hypersonic SQL database to retrieve information or store new/updated information. Figure 1: AAUAv's HelpDesk: Deployment Diagram Iteration 2 Noddy's Friends, 2008 Page 3 of 11

4 3 Use cases The following UC (Use Case) diagram represents the account management package Now we present the UC diagram which represents the management of FAQ (Frequently Asked Questions). This UC will not be considered in a first implementation since it is not essential for a simple functional helpdesk. Iteration 2 Noddy's Friends, 2008 Page 4 of 11

5 The following UC diagram is perhaps the most important of the whole system since it covers the main requirements of a helpdesk system (Tickets management) Iteration 2 Noddy's Friends, 2008 Page 5 of 11

6 Now we present the UC package which represents the management of stakeholders. In other words, this allows for stakeholders to add/remove stakeholders of a lower patent (e.g. administrators can only add/remove assistants or users and CEO can only add/remove administrators with a low level of administration. Both CEO and administrators can search/view other stakeholders. The system must be secure so we need the UC necessary to perform secure login/logout. These UC are present in the following package. Iteration 2 Noddy's Friends, 2008 Page 6 of 11

7 The following UC package represent what the CEO can do to check the performance of the helpdesk. This allows CEO to see for example, if an assistant is better than the other in some issue and then assign similar issues to him/her when needed. The following figure represents the sequence diagram of the Assign Ticket Use case: Iteration 2 Noddy's Friends, 2008 Page 7 of 11

8 4 Class Design Proposal Class Design Proposal in the format of JavaDoc documentation is attached in this deliver in the folder src/doc. 5 Class Diagram Figure 2: AAUAv's HelpDesk: Class Diagram We decide not to introduce methods inside classes because the diagram could become too much complex and reader could loose the general notion of the system. The methods are represented in the JavaDoc documentation included in the folder src/doc. The following points briefly describe the class diagram represented above. X Person Person class is responsible to save stakeholder personal data, like name, username, password, , date of admission and if he/she is active in the system. Iteration 2 Noddy's Friends, 2008 Page 8 of 11

9 p User User class extends person class. It is needed to keep information related to the user, like user s activation code and validation flag. Activation code is a keyword automatically generated by the system when a user submits his/hers registration cheat. The activation code is associated to the user and sent to his/hers e mail. User shall confirm the registration intent by clicking in the link sent by system to his/hers e mail. After this action the validation flag is set to true and the user is validated in the system. Assistant Assistant class extends person class, its intention is just to mask a person into an assistant and there are no extra fields in this class. X Administrator Administrator class extends person class. Has a field named level that is needed to save the administrator access level and to distinguish a common administrator from the CEO: level 0: Chief Executive Administrator (CEO) level 1: common administrator; X FAQ FAQ class is responsible to save the frequently asked questions (FAQ) by the users; to achieve this purpose FAQ class shall keep FAQ s question, answer and admission date, for management purposes, FAQ class shall also keep an accepted flag and an active flag. When an assistant proposes a FAQ accepted flag is set with false value, then the administrator can accept it or refuse it. The active flag is use to activate or deactivate a FAQ. p Ticket Ticket class is responsible to keep all information related to the ticket, like ticket title, ticket question, admission date, resolution date (when the assistant closes the ticket), ticket status (pending, solving, closed) and an active flag for removal purposes. Comment Comment class is responsible to keep all ticket comments, for that purpose comment class shall keep the comment and the admission date. Assignment Assignment class is responsible to keep the information related to the ticket assignment. An administrator can assign a pending ticket to an assistant, after this action ticket is associated to that assistant and he/she is responsible to answer it. Assignment class shall save these associations and the date of the ticket assignment. 6 Resources We will use Google Web Toolkit (GTW) and Hypersonic Structured Query Language (HSQL) Database Engine (DB) for the implementation. GWT is an open source Java software development framework that makes writing AJAX applications. GTW allows for writing a dynamic web application without spending all the time working around subtle incompatibilities Iteration 2 Noddy's Friends, 2008 Page 9 of 11

10 between browsers and platforms. This facilitates the reuse of AJAX components and solves the drawback of JavaScript's lack of modularity. HSQLDB is a relational database engine written in Java, with a JDBC driver, supporting a large subset of ANSI 92 SQL. A small, fast engine with both in memory and disk based tables. This product is the continuation of HypersonicSQL. Active since Project Plan This section briefly describes how the AAUAv's project will be organized. This includes how responsibilities are assigned to team members, which are the recommendations used during the project lifecycle. Project organization Team Member Team leader User interface Modeling Application core David Campos X X X Hugo Picado X X X Luis Ribeiro X X Pedro Alves X X Development process and measurements OpenUP specifications will be used to model and implement the system. OpenUP is a lean Unified Process which is based on iterations and increments within a structured lifecycle. OpenUP is focused on the collaborative nature of software development and aims to provide standards that help project teams to communicate during the project lifecycle. Five project iterations are specified to be required for the success of the project. Every week the team has a meeting to talk about the evolution of the project. Project milestones and objectives Phase Iteratio Primary objectives Scheduled start or n milestone Requirements and Use Cases I1 Find the requirements that the project should meet and an idea of how implementation will grow Until April 2, 2008 Initial design I2 Provide an initial design of the project, architecture modeling and resources to Until April 2, 2008 Iteration 2 Noddy's Friends, 2008 Page 10 of 11

11 use Initial implement and Test I3 Develop of some base code of the application and test units to allow test that code Until April 23, 2008 Ongoing implementation report I4 Have some code features working and some of the most important requirements implemented and tested Until May 24, 2008 Project completion I5 Demonstrate the application and submit the final version of the documentation Until June 9, 2008 Deployment The project will be accessible by the team members through a repository placed in a server at IEETA (Institute of Engineering, Electronics and Telematics of Aveiro). The collaboration is taking place with the help of CVS (Concurrent Versions System) which is a way of a team work in the same project without the need to be always in the same place. Lessons learned Team work was an important element during the development until the current phase. We should invest more time in meetings in order to reinforce team vision about the project and guarantee that that vision is common for all the team members. CVS plays an important role in our project since this is a four-element project and no one of us has too much opportunity to work together in the same place. Iteration 2 Noddy's Friends, 2008 Page 11 of 11