Version: |
CS 4500, University of Utah
|
The Project Plan has as its primary audience the customer of the project and the instructor.
The Project Plan has two key goals:
1.1 Project Overview
A brief description of the project objectives, the product to be delivered, the activities, and their resulting work products. This constitutes the formal acceptance of the project.
1.2 Definitions, Acronyms, and Abbreviations
Include key terms; this section helps ensure that the project plan will be understood the same way by everyone. Be sure to alphabetize!
1.3 References
Mention books, articles, web sites, worksheets, project documents, or people who are sources of information about the application domain, etc. Give links to documents as appropriate. Alphabetize by last name of author. For examples of how to list various types of references, see previous CS4500 projects.
1.4 Overview of Document
A short yet informative description of how the rest of the Project Plan is organized and what can be found in the rest of the document. This is not a table of contents!! Briefly describe and motivate the various parts.
2.1 Process Model
Specify the milestones, reviews, work products, and deliverables for this project. You must describe a process model. It is not sufficient to simply copy over the list of milestones for the semester. You might include this information in abbreviated form; you might also include the information in an appendix.
2.2 Organizational Structure and Responsibilities
This section will be an initial exploration of the way your team management will work. Will you have one person as the project leader throughout the semester? Or will such responsibilities rotate among your team members? It is generally a good idea to have shared roles, since this helps prevent problems when one person in a key role is temporarily unable to complete their responsibilities (for example, due to an accident or a serious illness).
Identify the individual(s) who will be responsible for each project function. Job titles depend in part on the organizational structure of the team. It is natural that assignment of roles will shift somewhat as the semester proceeds.
This section should be organized to first clearly define the general principles of the organizational structure and then to outline for the roles you have defined exactly which individuals will serve in that role.
2.3 Organizational Boundaries and Interfaces
Describe the relationships outside of the team. This should include the customer, the instructor and the mentors. For each, include several sentences that describe the nature of the relationship.
2.4 Reviews, walkthroughs, inspections, and audits
This section plans for the reviews, walkthroughs, inspections, and audits the team will hold throughout the project. The section will be expanded in the verification and validation plan, based in part on the activities that are already completed by that time and in part on the activities that remain for the rest of the semester.
2.5.1 Procedures for reviews, walkthroughs, inspections, and audits
2.5.2 Schedule of reviews, walkthroughs, inspections, and audits
3.1 Management Objectives and Prioritories
Describe the philosophy, goals, and priorities for management. This should focus on the team's internal management, rather than the aspects that are imposed externally (e.g. by the instructor).
3.2 Team name
Each team must give itself a name. Report your team's name here. It is strongly requested that you include an explanation of the reasons behind your team's choice of names.
3.3 Possible Meeting Times
Finding compatible meeting times is one of the most challenging tasks that many teams face. It is also important to anticipate days when one or more team members will be unavailable (for example, due to interview trips or the observance of religious holidays). List all of the times outside of class that your team has identified as possibilities for meetings with everyone there. If you are matched with your mentors before this project plan is due, include potential meeting times for the team together with the mentors.
3.4 Team's Range of Skills and Experience
Summarize the skills and experience that your team has collectively. Organize this according to categories (e.g., writing code in various programming languages, project team experience, working with children); include individual names and level of skill or experience in each area. Be imaginative; think of skills that could help your team in your teamwork, in the project work, or in understanding and working with your client's needs. It is strongly recommended that you use one or more tables to present this information. A clear presentation style is to list the skills as row labels, team members as column levels, and then to fill in numeric values in the cells to indicate the strength of experience for that person in that category. Provide a key that guides interpretation of the numeric values; for consistency and ease of reference across teams, we strongly recommend using the scale 1 = very experienced, 3 = some experience, 5 = no experience.
4.1 Overview of Functional Requirements
A short description of the functions to be performed by the software, i.e., what the product should do. This description must be in a form understandable to users, operators, and clients. Do not take up design issues in this document.
4.2 Overview of Data Requirements
Describe data that are input to or output from the product as well as any data that are stored within the system, for example in files or on disk. This section should only cover data requirements from the user's point of view. Once again, this should not be design-oriented.
4.3 General Constraints, Assumptions, Dependencies, Guidelines
This section describes non-functional requirements, those factors that impose constraints on the implementation of the software product. This can include hardware limitations or requirements, the amount of memory available, response times, policies, interfaces to other application software, networks, environmental limitations, compliance with relevant standards. This section can also provide guidance in situations when there may be more than one implementation strategy.
Examples:
"The product will only work with certain operating systems
"The product will only work within a particular network environment."
"The product must be Web-based."
"The product cannot require persistent data."4.4 User View of Product Use
This section should provide a user's-eye-view of using the product. This can include dramatic scenarios that demonstrate the product in operation. Describe the setting, the possible appearance of the screen(s), and give samples of the data that is stored, entered, or output.
Software Project Management Plan framework prescribed in IEEE Standard 1058.1 (1987).
Software Engineering, Theory and Practice by Shari Lawrence Pfleeger, Prentice-Hall 1998, section 3.5.