Android Application for Visual Communication Software Project Management Plan (gmirsky@student.utdallas.edu) Tucker Smith (tss063000@utdallas.edu) (jacobalsaleh55@yahoo.com) Tom Langford (etom1002@hotmail.com) (bmw066000@utdallas.edu) Cliff Halasz (miliways@gmail.com) Arlen Aghakians (arlenik@student.utdallas.edu) Project Homepage: http://home-greyhatent.homelinux.org/redmine/projects/req-eng September 27, 2010 Version 1.3 1
Contents 1 Revision History 3 2 INTRODUCTION 4 2.1 Project Overview........................... 4 2.2 Project Deliverables......................... 4 2.3 Evolution of this Document..................... 4 2.4 References............................... 5 2.5 Definitions, Acronyms, and Abbreviations............. 5 3 PROJECT ORGANIZATION 5 3.1 Organizational Structure....................... 5 3.2 Organizational Boundaries and Interfaces............. 5 3.3 Project Responsibilities....................... 6 4 MANAGERIAL PROCESS 6 4.1 Management Objectives and Priorities............... 6 4.2 Assumptions, Dependencies, and Constraints........... 6 4.3 Risk Management.......................... 7 4.4 Monitoring and Control Mechanisms................ 7 5 TECHNICAL PROCESS 8 5.1 Methods, Tools and Techniques................... 8 5.1.1 Tools............................. 8 5.1.2 Methods............................ 8 5.2 Software Documentation....................... 9 6 WORK ELEMENTS, SCHEDULE AND BUDGET 9 2
1 Revision History Ver Date Author Comment 1.3 2010-09-27 tss063000 Added Tom to the cover page. 1.2 2010-09-11 tss063000 Caused automatic system to rebuild document. 1.1 2010-09-11 tss063000 Initial revision 1.1.1.1 2010-09-11 tss063000 Initial Commit. 3
2 INTRODUCTION 2.1 Project Overview This Software Project Management Plan (SPMP) describes the layout and planning of the Android Application for Visual Communication(VCA); the deliverables, schedules, dependencies, constraints, and assumptions involved will be defined, and the management of each will be addressed. This document will also address the organization, roles and responsibilities of all staff involved with the project. This document will primarily be used as guidance for the project leaders. 2.2 Project Deliverables The VCAis divided into several deliverables: Software Project Management Plan Phase I.1 1. Report 2. Presentation Phase I.2 1. Issues 2. Clarification of Definition 3. Mock Prototype and User Manual Phase II.1 1. Report 2. Updated Project Plan Phase II.2 1. Process Specification 2. Issues 3. Product Requirements Models and Specification 4. Working Prototype 5. Justification of Superiority 2.3 Evolution of this Document This document will be often revised as the project progresses. Since the purpose of this document is to serve as an aid to the project leaders during their respective phases, it must be easily accessible, editable, and hard to be confused with an out-dated copy. To that end, this document shall be exclusively stored, edited, and accessed via a Concurrent Versioning System (CVS). Should a leader decide to make changes, the leader and the reason for his change will automatically be inserted into the revision history section of the L A TEX source of this document upon committing it to the CVS. 4
2.4 References [1] A. Rajeevalochana et al. Ambulance Dispatch System Software Project Management Plan, ECS, UT Dallas, TX, May 2007. 2.5 Definitions, Acronyms, and Abbreviations VCA CVS SQA IRC SPMP Android Application for Visual Communication Concurrent Versioning System Software Quality Assurance Internet Relay Chat Software Project Management Plan 3 PROJECT ORGANIZATION 3.1 Organizational Structure All team members will share an equal amount of the workload during each phase. Each member may be assigned to independent sub-modules, or multiple members may be assigned in groups to larger sub-modules. However, a single group member from each sub-module will serve in a reviewer capacity to another sub-module. For example, if there were two sub-modules, and the team was split evenly between them, then one member of Sub-Module A would review Sub-Module B, and one member of Sub-Module B would review Sub-Module A. Likewise, if each team member were assigned individual work, they would each review another s work. Reviews will be chosen ahead of time to ensure that no member has to review more often than any other. Each sub-group will have a member who acts as a liaison, and will be responsible for meeting with the reviewer, and delegating modifications proposed by the reviewer. The liaison will also be responsible for ensuring the integration of his sub-module by coordinating with other liaisons. 3.2 Organizational Boundaries and Interfaces Project Manager : Tucker Smith - Sets milestones, sets standards for documentation, and administrates the collaboration software. Team Lead : (rotating) - Advises the team by answering questions and organizing meetings. Also is responsible for ensuring submission of deliverables. Requirements Engineer : - Describes what the VCA should be doing, answers questions about using the VCA software, and verifies that the specifications are being met. Mentors : Lawrence Chung - Gives advice on the project. 5
3.3 Project Responsibilities Phase Phase I.1 Phase I.2 Phase II.1 Phase II.2 Team Leader Tucker Smith 4 MANAGERIAL PROCESS 4.1 Management Objectives and Priorities Owing to the small size of our team, we espouse a lightweight and tightly collaborative management philosophy. Without needing to manage a large mass of staff, management shall focus on ensuring that each member is functioning at full capacity. Thus it is management s responsibility to keep in close communication with all staff and minimize the time between when a team member encounters a problem that inhibits their ability to function effectively, and when that problem is solved. Management shall also make sure that communication between members is facilitated quickly and effectively. With our small staff, we cannot afford to lose time due to delays in communication and collaboration. 4.2 Assumptions, Dependencies, and Constraints The project assumes that we will have a total staff of at least 4 members, and will have access to all the software and other resources necessary to complete the project. It also assumes that the staff will not grow to a size greater than 6, as our management methodology is dependent on a small group. Management is also dependent on our online collaboration software being up and running smoothly for the duration of the project. 6
4.3 Risk Management No. Risk Likelihood Impact Description 1 Inappropriate Unlikely High The application does not version of work with the platform in the tools and the field components 2 Failure to Possible High Failure to complete a deliverable meet deliverable on schedule deadlines 3 Unavailability Likely High Team members are not of resources available, or are unable commit to a task 4 Requirements Change Likely Medium New requirements are discovered, or old ones are found to be incorrect Possible High Project data is lost due to an accident and cannot be recovered Unlikely Medium A team member shows poor performance, or fails to complete their duties 4.4 Monitoring and Control Mechanisms 5 Accidental loss of information 6 Poor Team Member Performance No. Risk Risk Response 1 Inappropriate Verify that the software being used will work on all version of versions of the target platform. the tools and components 2 Failure to Set multiple milestones during a deliverable s lifetime. meet deliverable If more than 2 are missed, then the project deadlines leader should call a group meeting and try to discern the source of the delays. 3 Unavailability of resources Identify and negotiate team member schedules before a deliverable is started. Identify early when a team member cannot commit, so that another member can 4 Requirements Change start to take on his workload early in the deliverable. Stop all current work, identify how this change in requirements affects the rest of the deliverable, and reassess responsibilities. Maintain backups for every change. The CVS server shall be mirrored to UTD s servers nightly. 5 Accidental loss of information 6 Poor Team Member Performance Set professional standards and follow them. Confront members who are not performing fully, and identify why. 7
5 TECHNICAL PROCESS 5.1 Methods, Tools and Techniques 5.1.1 Tools CVS - All code and documentation will be stored and revised via CVS. L A TEX - All documentation will be written in L A TEX. Redmine -We will be using Redmine to manage the project and collaborate remotely. Redmine provides a forum, wiki, feature tracking, and integration with our CVS server for ease of use. Java - We will use the Java programming language, as that is the language of the Android platform. IRC - A private IRC server is at our disposal, and may be used when the group cannot physically meet. 5.1.2 Methods Team Meetings - Because of our small staff, we can more easily schedule meetings in which all members can be present. As such, all members should be present at team meetings, and these meetings should be made as often as the team leader sees fit. It is his responsibility to schedule, organize, and execute each meeting. At the meeting, the team leader has the authority to assign tasks to team members and request status reports. Online Metrics - The Redmine software we will be using allows the specification of requirements and tasks, the start and end dates of those task, the percent completion of the task, and the capacity to assign the task to individual team members. The software is capable of representing this information in the form of a Gantt Chart. Each task will be a milestone, and members will use this software to log their current status on the project. This way the management can have a clear, graphical report of the current project status, and can easily spot members who are having trouble. Concurrent Versioning System - The CVS is central to our development process. By storing all project data in a central repository (which is, of course, backed up by secondary and tertiary systems) we can ensure only one copy of the data exists at one time, thus eliminating painful and error-prone merging processes near project completion. With automatic versioning, we can also eliminate the possibility of team members forgetting to update the revision history. Additionally, we can trace how requirements entered and evolved in the system. We can also keep track of group participation. Online Collaboration - Another benefit of the Redmine collaboration software is that it provides for us a wiki environment which we can use to define and map out the problem domain. It also provides a forum which provides for an excellent place to publicly solve problems that a group member may have. Additionally, IRC can be a boon when the group needs to meet, but cannot meet in person. 8
5.2 Software Documentation Software documentation will be addressed in Phase I of the project. 6 WORK ELEMENTS, SCHEDULE AND BUD- GET The following schedule will contain individual sub-phases and their completion dates as more information becomes available. Deliverable Sub-Phase Developers Reviewer Start End SPMP Preliminary Proposal Tucker Smith 8/31 9/2 Phase I.1 Tucker Smith Tucker Smith 9/2 9/30 Phase I.2 Tucker Smith 9/30 10/21 Phase II.1 Tucker Smith 10/21 11/11 Phase II.2 Tucker Smith 11/11 11/30 9