Software Project Management Pl Good Eats Inc
Software Project Management Plan
December 14, 2013 CMIS330
Table of Contents
6.0 References 14
Software Project Management Plan
1. Overview
1.1 Project Summary
1.1.1 Purpose, scope and objectives
1.1.1.1 Background
Good Eats Inc. required a system be developed that would be utilized by the local stores, regional warehouses, suppliers and the corporate headquarters of Good Eats Inc. Good Eats ERP provides an inventory control system at each store that is linked to both regional warehouses, and corporate headquarters. This will track the sale of every item in every store and online storefront, as well as all items in the regional warehouses. The system …show more content…
also includes reporting features for corporate use, and automatic resupply order (RO), store order (SO) and delivery order (DO) creation.
1.1.1.2 Scope
The approach of this document is to create a software project management plan (SPMP) that will outline organization and plans for the project. This document includes roles and responsibilities, estimates for the project duration, staffing, a schedule and work breakdown, and resources, dependencies and project specifics.
1.1.2 Assumptions and constraints
The constraints involved in this project are budget and schedule. This project requires a quick turnaround for which we must successfully implement the new ERP system for Good Eats, Inc. We also have a specific budget in place that will not allow us to excessively use funds to purchase new software and equipment for this project. We must reuse some software in order to save money.
4. Project Organization
4.3 Actors and Responsibilities
The major work activities for this project are as follows:
Create ERP system to connect different points of the store
Software engineers are responsible for implementing this ERP system for Good Eats, Inc. The system must relay inventory and ordering information across stores, the distribution center, the warehouse, the regional office, and headquarters. This system must be completely reliable and must be able to be accessed at any time. Because the store will heavily use this system, reliability is essential. Software engineers will need to implement an ERP system that will not fail for the store.
The project manager (PM) will be responsible for ensuring that software engineers are staying on task with the implementation of the ERP system. PM will routinely check the work of the software engineers to ensure that things are headed in the right direction at all times. PM will be responsible for disciplining any software engineers that are failing to complete accurate work.
Testers are responsible for testing the ERP system as it is being developed. The schedule will identify five points within the project in which testers will complete white box and black box testing on the ERP system’s components to ensure that it is being completed correctly and is operating correctly. Testers will not wait until the last minute to test the system just in care errors arise. We want to fix the errors as soon as they are detected.
QA will be responsible for maintaining the quality level of the ERP system. QA must be involved in the entire process of the system implementation to ensure that the product will exceed the expectation of the customer, Good Eats, Inc.
Configuration Management (CM) will ensure that the product is consistent in functionality. They will assess the ERP system’s performance and functionality when the ERP system is complete.
The V&V team, after the ERP system is complete, will assess whether or not the ERP meets standard usability requirements and specifications. They will also ensure that the ERP system fulfills its purpose for the client.
After the project is complete, the client will review the ERP system to make sure it suits up to their standards.
Create an online webpage for online ordering and deliveries
Web developers will be responsible for creating the website. Graphic designers will create the outline and layout for the webpage.
The PM will make sure that all staff are completing their assignments on time and accurately.
Testers will test the website once it is completed and offer suggestions to improve usability.
QA is responsible for ensuring that the website is up to the standards of the client. QA will sit down with the client to ask what improvements they request unless the product completely satisfies the client. This will occur once the website is up and running and available for use.
CM is responsible for ensuring that the website is user friendly and completely functional. CM will assess the physical attributes of the system and ensure that it works consistently.
The V&V team will make sure that the website is usable and has all components required by the client.
The client will review the website to make sure it is up to their standards.
5. Managerial Process Plans
5.1 Project Effort and Duration Estimates
Top-Down Approach:
Because we have budget restrictions, we are using the top-down approach to estimate effort and duration. Our budget restrictions will allow us to complete this project in a maximum of 8 months, preferably less. To estimate duration, we will divide tasks up into 15 persons in order to minimize the duration of this project. The parametric COCOMO model will assist in the estimation process. Ideally, we would want to hire an expert estimator but to stay within budget, we will use project staff to complete this.
5.2 Project Schedule with Work Breakdown
Screenshots from Microsoft Excel spreadsheet:
5.3 Staffing
5.4 Resources, Dependencies, and Project Specifics
5.4.1 People
We will need 15 people to carry out this project:
5.4.1.1 3 software engineers
5.4.1.2 1 project manager
5.4.1.3 2 testers
5.4.1.4 2 QA
5.4.1.5 2 V&V
5.4.1.6 2 Configuration Management Specialists
5.4.1.7 2 web developers
5.4.1.8 1 graphic designer
5.4.2 Equipment
This project will require computers, testing equipment, and software.
5.4.3 Facilities
This project will take place in the Warehouse of the Good Eats Inc. business. This will eliminate the cost of having to pay to lease a space for a certain period of time.
5.4.4 Funding
Funding for this project will come directly from Good Eats, Inc. The company will be responsible for paying the project team members their bi-weekly salary. The company is also responsible for any software or equipment used for the facilitation and completion of the project.
5.5 Risk Assessment
5.5.1 Schedule creation
5.5.1.1 Schedule, resources, and product definition have all been dictated by the customer or upper management and are not in balance
5.5.1.2 Schedule omits necessary tasks
5.5.1.3 Schedule was based on the use of specific team members, but those team members were not available
5.5.1.4 Product is larger than estimated (in lines of code, function points, or percentage of previous project’s size)
5.5.2 Organization and management
5.5.2.1 Project lacks an effective top-management sponsor
5.5.2.2 Project languishes too long in fuzzy front end
5.5.2.3 Management or marketing insists on technical decisions that lengthen the schedule
5.5.2.4 Budget cuts upset project plans
5.5.3 Development environment
5.5.3.1 Facilities are not available on time
5.5.3.2 Facilities are crowded, noisy, or disruptive
5.5.3.3 Development tools are not in place by the desired time
5.5.3.4 Development tools do not work as expected; developers need time to create workarounds or to switch to new tools
5.5.4 End-users
5.5.4.1 End-user insists on new requirements
5.5.4.2 End-user ultimately finds product to be unsatisfactory, requiring redesign and rework
5.5.4.3 End-user does not buy into the project and consequently does not provide needed support
5.5.4.4 End-user input is not solicited, so product ultimately fails to meet user expectations and must be reworked
5.5.5 Customer
5.5.5.1 Customer insists on new requirements
5.5.5.2 Customer review/decision cycles for plans, prototypes, and specifications are slower than expected
5.5.5.3 Customer will not participate in review cycles for plans, prototypes, and specifications or is incapable of doing so—resulting in unstable requirements and time-consuming changes
5.5.5.4 Customer communication time (e.g., time to answer requirements-clarification questions) is slower than
expected
5.5.6 Contractors
5.5.6.1 Contractor does not deliver components when promised
5.5.6.2 Contractor delivers components of unacceptably low quality, and time must be added to improve quality
5.5.6.3 Contractor does not buy into the project and consequently does not provide the level of performance needed
5.5.7 Requirements
5.5.7.1 Requirements have been baselined but continue to change
5.5.7.2 Requirements are poorly defined, and further definition expands the scope of the project
5.5.7.3 Additional requirements are added
5.5.7.4 Vaguely specified areas of the product are more time-consuming than expected
5.5.8 Product
5.5.8.1 Error-prone modules require more testing, design, and implementation work than expected
5.5.8.2 Unacceptably low quality requires more testing, design, and implementation work to correct than expected
5.5.8.3 Development of the wrong software functions requires redesign and implementation
5.5.8.4 Development of the wrong user interface results in redesign and implementation
5.5.9 External environment
5.5.9.1 Product depends on government regulations, which change unexpectedly
5.5.9.2 Product depends on draft technical standards, which change unexpectedly
5.5.10 Personnel
5.5.10.1 Hiring takes longer than expected
5.5.10.2 Task prerequisites (e.g., training, completion of other projects, acquisition of work permit) cannot be completed on time
5.5.10.3 Poor relationships between developers and management slow decision making and follow through
5.5.11 Design and Implementation
5.5.11.1 Overly simple design fails to address major issues and leads to redesign and reimplementation
5.5.11.2 Overly complicated design requires unnecessary and unproductive implementation overhead
5.5.12 Process
5.5.12.1 Amount of paperwork results in slower progress than expected
5.5.12.2 Inaccurate progress tracking results in not knowing the project is behind schedule until late in the project
5.5.12.3 Upstream quality-assurance activities are shortchanged, resulting in time-consuming rework downstream
6. References 6.1.1 IEEE. IEEE Std 820-1998
IEEE Recommended Practice for Software Project Management Plan. IEEE Standards Board, 16 September 1998. 6.1.2 Good Eats - Internal Documentation
Software Requirements Specification V1.1 (Document no. 845). 28 October 2013 class. 6.1.3 Good Eats - Internal Documentation
Software Project Management Plan V1.3 (Document no. 852). 15 December 2013.
December 14, 2013 CMIS330
Table of Contents
6.0 References 14
Software Project Management Plan
1. Overview
1.1 Project Summary
1.1.1 Purpose, scope and objectives
1.1.1.1 Background
Good Eats Inc. required a system be developed that would be utilized by the local stores, regional warehouses, suppliers and the corporate headquarters of Good Eats Inc. Good Eats ERP provides an inventory control system at each store that is linked to both regional warehouses, and corporate headquarters. This will track the sale of every item in every store and online storefront, as well as all items in the regional warehouses. The system …show more content…
also includes reporting features for corporate use, and automatic resupply order (RO), store order (SO) and delivery order (DO) creation.
1.1.1.2 Scope
The approach of this document is to create a software project management plan (SPMP) that will outline organization and plans for the project. This document includes roles and responsibilities, estimates for the project duration, staffing, a schedule and work breakdown, and resources, dependencies and project specifics.
1.1.2 Assumptions and constraints
The constraints involved in this project are budget and schedule. This project requires a quick turnaround for which we must successfully implement the new ERP system for Good Eats, Inc. We also have a specific budget in place that will not allow us to excessively use funds to purchase new software and equipment for this project. We must reuse some software in order to save money.
4. Project Organization
4.3 Actors and Responsibilities
The major work activities for this project are as follows:
Create ERP system to connect different points of the store
Software engineers are responsible for implementing this ERP system for Good Eats, Inc. The system must relay inventory and ordering information across stores, the distribution center, the warehouse, the regional office, and headquarters. This system must be completely reliable and must be able to be accessed at any time. Because the store will heavily use this system, reliability is essential. Software engineers will need to implement an ERP system that will not fail for the store.
The project manager (PM) will be responsible for ensuring that software engineers are staying on task with the implementation of the ERP system. PM will routinely check the work of the software engineers to ensure that things are headed in the right direction at all times. PM will be responsible for disciplining any software engineers that are failing to complete accurate work.
Testers are responsible for testing the ERP system as it is being developed. The schedule will identify five points within the project in which testers will complete white box and black box testing on the ERP system’s components to ensure that it is being completed correctly and is operating correctly. Testers will not wait until the last minute to test the system just in care errors arise. We want to fix the errors as soon as they are detected.
QA will be responsible for maintaining the quality level of the ERP system. QA must be involved in the entire process of the system implementation to ensure that the product will exceed the expectation of the customer, Good Eats, Inc.
Configuration Management (CM) will ensure that the product is consistent in functionality. They will assess the ERP system’s performance and functionality when the ERP system is complete.
The V&V team, after the ERP system is complete, will assess whether or not the ERP meets standard usability requirements and specifications. They will also ensure that the ERP system fulfills its purpose for the client.
After the project is complete, the client will review the ERP system to make sure it suits up to their standards.
Create an online webpage for online ordering and deliveries
Web developers will be responsible for creating the website. Graphic designers will create the outline and layout for the webpage.
The PM will make sure that all staff are completing their assignments on time and accurately.
Testers will test the website once it is completed and offer suggestions to improve usability.
QA is responsible for ensuring that the website is up to the standards of the client. QA will sit down with the client to ask what improvements they request unless the product completely satisfies the client. This will occur once the website is up and running and available for use.
CM is responsible for ensuring that the website is user friendly and completely functional. CM will assess the physical attributes of the system and ensure that it works consistently.
The V&V team will make sure that the website is usable and has all components required by the client.
The client will review the website to make sure it is up to their standards.
5. Managerial Process Plans
5.1 Project Effort and Duration Estimates
Top-Down Approach:
Because we have budget restrictions, we are using the top-down approach to estimate effort and duration. Our budget restrictions will allow us to complete this project in a maximum of 8 months, preferably less. To estimate duration, we will divide tasks up into 15 persons in order to minimize the duration of this project. The parametric COCOMO model will assist in the estimation process. Ideally, we would want to hire an expert estimator but to stay within budget, we will use project staff to complete this.
5.2 Project Schedule with Work Breakdown
Screenshots from Microsoft Excel spreadsheet:
5.3 Staffing
5.4 Resources, Dependencies, and Project Specifics
5.4.1 People
We will need 15 people to carry out this project:
5.4.1.1 3 software engineers
5.4.1.2 1 project manager
5.4.1.3 2 testers
5.4.1.4 2 QA
5.4.1.5 2 V&V
5.4.1.6 2 Configuration Management Specialists
5.4.1.7 2 web developers
5.4.1.8 1 graphic designer
5.4.2 Equipment
This project will require computers, testing equipment, and software.
5.4.3 Facilities
This project will take place in the Warehouse of the Good Eats Inc. business. This will eliminate the cost of having to pay to lease a space for a certain period of time.
5.4.4 Funding
Funding for this project will come directly from Good Eats, Inc. The company will be responsible for paying the project team members their bi-weekly salary. The company is also responsible for any software or equipment used for the facilitation and completion of the project.
5.5 Risk Assessment
5.5.1 Schedule creation
5.5.1.1 Schedule, resources, and product definition have all been dictated by the customer or upper management and are not in balance
5.5.1.2 Schedule omits necessary tasks
5.5.1.3 Schedule was based on the use of specific team members, but those team members were not available
5.5.1.4 Product is larger than estimated (in lines of code, function points, or percentage of previous project’s size)
5.5.2 Organization and management
5.5.2.1 Project lacks an effective top-management sponsor
5.5.2.2 Project languishes too long in fuzzy front end
5.5.2.3 Management or marketing insists on technical decisions that lengthen the schedule
5.5.2.4 Budget cuts upset project plans
5.5.3 Development environment
5.5.3.1 Facilities are not available on time
5.5.3.2 Facilities are crowded, noisy, or disruptive
5.5.3.3 Development tools are not in place by the desired time
5.5.3.4 Development tools do not work as expected; developers need time to create workarounds or to switch to new tools
5.5.4 End-users
5.5.4.1 End-user insists on new requirements
5.5.4.2 End-user ultimately finds product to be unsatisfactory, requiring redesign and rework
5.5.4.3 End-user does not buy into the project and consequently does not provide needed support
5.5.4.4 End-user input is not solicited, so product ultimately fails to meet user expectations and must be reworked
5.5.5 Customer
5.5.5.1 Customer insists on new requirements
5.5.5.2 Customer review/decision cycles for plans, prototypes, and specifications are slower than expected
5.5.5.3 Customer will not participate in review cycles for plans, prototypes, and specifications or is incapable of doing so—resulting in unstable requirements and time-consuming changes
5.5.5.4 Customer communication time (e.g., time to answer requirements-clarification questions) is slower than
expected
5.5.6 Contractors
5.5.6.1 Contractor does not deliver components when promised
5.5.6.2 Contractor delivers components of unacceptably low quality, and time must be added to improve quality
5.5.6.3 Contractor does not buy into the project and consequently does not provide the level of performance needed
5.5.7 Requirements
5.5.7.1 Requirements have been baselined but continue to change
5.5.7.2 Requirements are poorly defined, and further definition expands the scope of the project
5.5.7.3 Additional requirements are added
5.5.7.4 Vaguely specified areas of the product are more time-consuming than expected
5.5.8 Product
5.5.8.1 Error-prone modules require more testing, design, and implementation work than expected
5.5.8.2 Unacceptably low quality requires more testing, design, and implementation work to correct than expected
5.5.8.3 Development of the wrong software functions requires redesign and implementation
5.5.8.4 Development of the wrong user interface results in redesign and implementation
5.5.9 External environment
5.5.9.1 Product depends on government regulations, which change unexpectedly
5.5.9.2 Product depends on draft technical standards, which change unexpectedly
5.5.10 Personnel
5.5.10.1 Hiring takes longer than expected
5.5.10.2 Task prerequisites (e.g., training, completion of other projects, acquisition of work permit) cannot be completed on time
5.5.10.3 Poor relationships between developers and management slow decision making and follow through
5.5.11 Design and Implementation
5.5.11.1 Overly simple design fails to address major issues and leads to redesign and reimplementation
5.5.11.2 Overly complicated design requires unnecessary and unproductive implementation overhead
5.5.12 Process
5.5.12.1 Amount of paperwork results in slower progress than expected
5.5.12.2 Inaccurate progress tracking results in not knowing the project is behind schedule until late in the project
5.5.12.3 Upstream quality-assurance activities are shortchanged, resulting in time-consuming rework downstream
6. References 6.1.1 IEEE. IEEE Std 820-1998
IEEE Recommended Practice for Software Project Management Plan. IEEE Standards Board, 16 September 1998. 6.1.2 Good Eats - Internal Documentation
Software Requirements Specification V1.1 (Document no. 845). 28 October 2013 class. 6.1.3 Good Eats - Internal Documentation
Software Project Management Plan V1.3 (Document no. 852). 15 December 2013.