Reference no: EM132524943
Project of system development project
Make a complete working system combining different elements so that to make it working on xampp
Complete the whole project
Software Project Management Plan
Part 1 Purpose and Scope
This section provides an executive overview of the project. It explains why the project is being initiated and what can and cannot be expected from project. It may also include any background or contextual information necessary for understanding the project.
The purpose for the project explains the problem or opportunity the project will address. The statement of purpose isn't a statement of what you are doing ("we plan to automate billing"), but rather why you are doing it ("The purpose of this project is to streamline billing in order to save time, money and resources.").
Project scope defines the boundaries of the project-what will and won't be included in the project. Defining project scope helps set expectations regarding what can be expected from the project. The scope definition may also play a role in evaluating requests for changes or new features. Project plans and estimates are based on the scope definition. A request for a change that is outside the current scope of the project can't be accepted without a change in project scope.
Goals and Objectives
Goals and objectives define expected project outcomes. Goals are broad and inspirational. Objectives are narrow and measurable.
Project goals generally related project outcomes to business objectives (reduced cost, increased revenue, improved quality, etc).
A well-worded objective is SMART: Specific, Measurable, Attainable/Achievable, Realistic and Time-bound.
Project objectives:
1. Create a database on homes offered for sale in a local area.
2. Create client software that allows access to the database from mobile devices.
3. Create an interface that home sellers and their agents can use to enter and update home data.
4. Extend mobile access to real estate data in the multiple listing service (MLS).
1 Activities and Tasks
A work breakdown structure is an excellent tool for identifying a complete list of tasks.
Depending on the needs of the project, some or all of the following attributes will be recorded for each task:
• Task name
• Task Description
• Owner
• Effort estimate
• Actual effort
• Planned start and stop dates
• Actual start and stop dates
• Dependencies among other tasks
• Gantt chart (you must draw this)
Release Plan
For day-to-day project management the release and iteration plans (described in the next section) are probably the two most important project management artifacts.
The release plan lists expected completion dates for major milestones and delivery dates of key work products. The project's technical development process to a certain extent will dictate the choice and timing of milestones and deliverables. For example, projects following the Rational Unified Process will have four major milestones: life-cycle objectives, life-cycle architecture, initial operation capability, and product release.
Iteration Plans
An iteration plan is a short-term fine-grained plan that shows the tasks to be completed during an iteration.
3.4 Budget
The project budget is the projected cost of the project as a function of time. At any point in the project you should be able to say how much money has already been spent and estimate of the amount of money needed to complete the project.
Control Plan
4.1 Monitoring and Control
Include in this section plans and procedures for tracking progress and controlling performance. Included here will be the approximate dates of technical as well as managerial reviews. Typically each major milestone or project phase will end in a review.
For projects that don't have a separate communication plan, this section may also include information on the timing and content of status reports and other project review documentation.
Partial Example
Weekly - Team meeting. Project participants report status, progress and potential problems.
3/1/2008 - Critical Design Review. Formal inspection of product architecture.
5/15/2008 - Executive Review. The project manager presents current project status to project sponsor and senior executives.
4.2 Project Measurements
Product and process measures support project management and estimation by analogy. At the beginning of a project, estimates are made for product size, project cost and delivery dates. During a project, progress is tracked with measures of actual effort, integrated lines of code and actual expenditures. Keeping track of estimates and actuals during a project helps to calibrate whatever technique is being used to make estimates. Storing project performance data on completed projects provides a rich source of data for estimating future projects.
5.1 Risk Management Plan
Identify technical and managerial risks. Prioritize risks. Consider the probability of each risk turning into a problem and the likely consequences. For the highest priority risks, what actions will be taken to minimize the probability of the risk turning into a problem and the resulting consequences? What are the contingency plans for selected risks that do become a problem? Identify processes for monitoring risks and updating the risk management plan.
5.2 Configuration Management Plan
Configuration management plans for this document and other baselined work products including review procedures and change management procedures.
Partial Example
1. All work products will be stored in a centralized CVS repository running on a central server.
2. The naming convention for documents will be: NNN-VVV.suffix where NNN is a mnemonic that reflects the function of the document, VVV is a 3 digit version number, and 'suffix' is the standard/normal suffix for the document type. For example, the second version of the requirements document created as a Microsoft Word document might be labeled: REQ-002.doc.
3. All project (work products) items (documents, source code, test cases, program data, test data, etc) will be stored in the CVS repository but not all will be under change control (subject to formal change control procedures.) Only the system requirements, project plan and source code will be baselined and under configuration control.
4. Items that are subject to change control will be considered baselined after a group review at the end of the life cycle phase during which they are created. Baselined here means that the product has undergone a formal review and can only be changed through the prescribed change control procedures.
5. The change control procedure once a product is baselined is: (1) anyone wanting to make a change to a baselined item sends an email to the rest of the group describing the change, reason for the change, expected impact, and timeline for integrating the change. (2) if no one responds to the group within 2 days with a reason for why the change request shouldn't be permitted, it will be considered accepted and the person proposing the change may proceed with the change. If anyone does object to the change, the reason for objecting will be discussed at a meeting where everyone is invited to attend and voice their opinion. At the end of the meeting a democratic vote will be held to decide whether or not the change should be allowed.
6. Including a change history with all documents is encouraged but only required for baselined documents. The change history should be at the front of the work item and include: (1) the name of the person making the change, (2) brief description of what has changed, (3) reason for the change, and (4) the date the change was integrated.
3 Verification and Validation Plan
The verification and validation plan defines what actions are being taken to assure the quality of the development process and resulting software products.
Partial Example
The Verification and Validation plan is specified as a separate documented located in the version control system
Product Acceptance Plan
The product acceptance plan defines what is acceptable in terms of product quality and product functionality. Acceptance criteria should be objective and measurable. Note product success is one aspect of project success. Teams wanting to establish a clear understanding of what will be considered acceptable project performance may want to define a more general plan for project success that includes quantitative goals for delivery date, cost, etc.
Attachment:- Software Project Management Plan Template.zip