Software Project Management Plan

Transcription

1 Software Project Management Plan Julie Makelberge November 3, 2010 Version Date Author Comment /11/2010 Julie Initial version /11/2010 Kevin Revision 1

2 Contents 1 Overview Project Summary Purpose, scope and objectives Assumptions, dependencies and constraints Project Deliverables References 5 3 Definitions 6 4 Project Organisation Process model Project Organisation External Interfaces Internal Structure Roles and Responsibilities Managerial process plans Start-up plan Staffing plan Project staff training plan Work plan Control Plan Requirements control plan Schedule control plan Reporting plan Risk management plan Technical process plans Process model Methods, tools and techniques Supporting process plans Configuration management plan Verification and validation plan Documentation plan Quality assurance plan

3 1 Overview 1.1 Project Summary Purpose, scope and objectives Introducing the real world to be complement with the virtual universe of games calls for a whole new level of gaming experience. In this project, a game will be developed that uses QR tags, spread in the real world, that the player can use to gather information about the current location, being the particular place where the tag is found. This principle of finding QR tags and gathering information will be used to introduce goals in the game. To create a game session, the player will be given two sets of templates: one for interactive, scenic routes and one for competitive games where players race through way points, marked by the QR tags. If wished for, players can introduce their own rules for custom competitive games. The requirements are based on the official statement. Functional Requirements Finding and selecting a game requesting the existing possible games filtering games based on their name or properties (e.g. Atomium, Empire State Building) Detailed description of a selected game, stating duration time, location, etc social ranking of games Playing Games Starting and ending game with QR tag Possibility of reviewing a played game Possibility to publish your progress Creating Games Templates for scenic routes Templates for competitive gaming Local mini-games for competitive gaming 3

4 Non-Functional Requirements The system must work on Linux and a web container like Tomcat The design must be modular so extensions and replacements of components will be easy The web interface must be simple, attractive and standard (CSS, XHTML) A service interface (using REST or SOAP) is an interesting extension Probable languages are C++, Java, Python, possibly extended with libraries. Only free software can be used as well as for the end product as for the resources. The choice of a certain library or recourse needs to be justified by reliability, being open and simplicity. A free library can only be used for certain (sub)components after authorisation of the client and a comparative study of what is available. The study is a part of the project documents and needs to be a part of the configuration management. It also needs to be available on the website. Frameworks are not allowed for non-technical reasons The system needs to be able to be installed easily on a standard machine The system will be demonstrated on the wilma server Requirements concerning the process All documents (and code) need to be in English Documents need to be available in pdf format All code needs to be documented by the usual resources like javadoc, doxygen, etc A repository needs to be used for configuration management. The repository needs to be available on the website. Eventually a subversion can be used. In that case the repository also needs to be available on the website A test automation tool for the framework needs to be used At least these documents need to be maintained: 1. Software Project Management Plan (SPMP) 2. Software Quality Assurance Plan (SQAP) 3. Software Configuration Management Plan (SCMP) 4. Software Test Plan (STD) 5. Software Requirements Specification (SRS) 6. Minutes of all meetings 4

5 The use of a project management tool is mandatory as well. This tool needs to be able to show for each team member what his/her function is, how much time was planned for a task and how much time was actually spend for a task. The client needs to be able to access this particular tool. All documents need to be publicly available on the website of the group at all times Assumptions, dependencies and constraints No assumptions are made concerning the project. The project is completely dependent on the motivation and work of the team members. Therefore good communication is necessary. There is a constraint on the available work hours since every team member has other courses to attend to and other projects to spend time on. Another constraint is that there is no financial budget, so all used software should be free and/or open-source. The last constraint is that the program needs to run on Linux as well as on the Wilma server Project Deliverables The required documents are: SPMP SCMP SRS SDD SQAP STD Minutes of meetings 2 References - Requirements document - Software engineering course - WE-DINF-6537 Rachnild Van Der Straeten - Eric J. Braude - Software Engineering, An Object-Oriented Perspective 5

6 3 Definitions SPMP Software Project Management Plan SCMP Software Configuration Management Plan SRS Software Requirement Specification SDD Software Design Document SQAP Software Quality Assurance Plan STD Software Test Plan CM Configuration Management VUB Vrije Universiteit Brussel 4 Project Organisation 4.1 Process model The chosen process is the spiral model with four iterations. With this model the most risky problems are identified and handled with in the beginning of the project. This gives the project a very high chance of success. Also it becomes clear early on in the process whether some parts of the project are unrealisable. Unlike the waterfall process, after each iteration, prototypes are made and can be evaluated by the client in order to reduce risks. 4.2 Project Organisation External Interfaces The professor (Ragnild Van Der Straeten) will act like the stakeholder in this project and can be reached through mail. Frequent SCRUM meetings will be held after each iteration Internal Structure The project consists of a group of peers with following roles: Project Manager, Configuration Manager, Quality Assurance Manager, Web-master, Requirements Manager, Design Manager, Implementation Manager and Secretary. 6

7 4.2.3 Roles and Responsibilities Project Manager responsible for the SPMP responsible for the contact with the professor approves timesheets responsible for the agenda approves the documents keeps the SPMP up-to-date approves decisions Configuration Manager responsible for the SCMP Install and maintain used tools Make back-ups of all project documents Manage revision control system Keeps the SPMP up to date Quality Assurance manager Responsible for the SQAP Responsible for the consistency of the documents Responsible for the quality of the deliverables Decides the coding conventions Keeps the SQAP up to date Web-master develops and maintains the project website uploads documents 7

8 Requirements Manager responsible for the SRS verifies if the requirements are correctly implemented looks for extra functional requirements presents final requirements to the customer Design Manager responsible for the SDD verifies if the SDD is correctly followed design and maintenance of the database verifies if the implementation is consistent with the SDD Implementation Manager responsible for the integration of the different parts of the code assigns implementation tasks track errors responsible for the testing of the code responsible for the STD Secretary responsible for the minutes of meetings responsible for mailing the to-do list after the meetings 8

9 5 Managerial process plans 5.1 Start-up plan Staffing plan Each staff member will be needed for the entire duration of the project and will be all responsible for a part of the implementation. Hiring has been done by the professor. This table shows who will be responsible for which role. The secretary role will passed on every meeting. Name Julie Makelberge Jasper Maes Kevin De Valck David Bos David Blinder Jesse Zaman Role Project Manager Configuration manager Quality Assurance Manager Web-master, Requirements Manager Design Manager Implementation Leader Project staff training plan If a member of the team lacks experience or knowledge on a certain subject and can not work on it by himself, peer-to-peer training will be given. The member with the most knowledge concerning the subject will be assigned to train this individual. Such training will be given as follows: presentations, tutorials, workshops, consultations, 5.2 Work plan 9

10 5.3 Control Plan Requirements control plan Requirements shall be described in the projects SRS and will be regularly checked on by the requirements manager Schedule control plan All members of the team will be responsible for checking whether the schedule is maintained and should report to the project manager if this is not the case. This way the schedule can be modified and arrangements can be made. The milestones do not only consist of the implementation but also of unit testing and correct commenting of the code Reporting plan Initial documents will be sent to the quality assurance manger for checking and then to the project manager for a final revision. All documents will be put on the website as soon as the project manager has approved of it. External documents supplied by the course can be found on the course website. Other external documents will be published on the site. Each meeting shall be reported and the minutes will be published at least 24h before the next meeting on the website. 5.4 Risk management plan Localising risks is essential for the completion of the project. That s why it must start at the beginning of the project and be continued during the course of the project. If a team member identifies a risk, it must be notified to the project manager immediately, so the effect and the chance of the risk can be evaluated and can be put in the SPMP. Poor communication Communication is essential in a team project. That is why certain measures have been taken. Bi-weekly meetings have been set up to share ideas, make remarks and discuss risks. A forum has been put up on the website to be able to discuss issues between meetings. All contact information has been exchanged at the first meeting and there is a mailing list for the project. Lack of knowledge on the programming languages If a team member lacks knowledge on a programming language, peer-to-peer training will be used. Misunderstandings about requirements It is possible that the team interprets the requirements differently than the client. 10

11 That is why prototypes will be showed to the client after each iteration so adjustments can be made if necessary. Missed deadlines Missed deadlines will also make the project fail. That is why good arrangements need to be made and the progress of every member needs to be followed up. Sickness or a team member giving up For this reason we have appointed a back-up for each function. Loss of data To avoid this, the configuration manager will back-up weekly. 6 Technical process plans 6.1 Process model The project is organised according to the spiral model consisting of 4 iterations. Each iteration consists of 4 parts. First the system requirements are defined as detailed as possible, then a design is made so all the possibilities are analysed. Once the design is completed, the implementation phase starts. Here a prototype is made for the customer. Finally the implementation gets thoroughly tested. We have chosen for the spiral model because it fits our needs best. The agile process was another possibility because of his flexibility but it requires a very regular work schedule and it is impossible to fit into all of our schedules. 6.2 Methods, tools and techniques Each member can choose how to make his documents. The Quality Assurance manager will receive the documents and put them in the correct lay-out and will provide the necessary formats. PHP will be used as the main programming language. Should it prove to be inadequate, a change to Ruby will be made. 11

12 7 Supporting process plans 7.1 Configuration management plan The configuration management plan is the responsibility of the configuration manager and will be available on the website at all times. 7.2 Verification and validation plan The verification and validation plan (STD) is the responsibility of the implementation leader. It will be available on the website. Verification shall occur by unit testing and full scale testing. 7.3 Documentation plan All documents will be available in LaTeX format and pdf format. The consistency in lay-out is the responsibility of the quality assurance manager. 7.4 Quality assurance plan The quality assurance plan is the responsibility of the quality assurance manager. It will be available on the website. 12