Download File
Project Planning & Scheduling (Word 2007)
Gant Chart Sample (Microsoft Project)
___________________________________
1 Table of Contents
2 Introduction. 3
2.1 Scope and Purpose: 3
2.2 Overall System Scope. 3
2.3 Project Motivation and Objectives. 3
3 Software Engineering. 4
3.1 Process Model 4
3.2 Project Team Structure. 6
4 Project Scheduling & Task. 7
4.1 Gantt Chart 7
4.2 Work Breakdown Structure (WBS) 8
5 Project Resources and Cost Estimation. 9
5.1 Calculating Function-Oriented Metrics. 9
5.1.1 Calculation of the unadjusted function points (UFP): 9
5.1.2 Calculate Adjusted Function Point 10
5.2 COCOMO EVALUATION.. 11
5.3 FUNCTION POINT BASED APPROXIMATIONS. 12
5.4 LOC BASED APPROXIMATIONS. 12
5.5 Summary. 13
6 Project Management Methods and Monitoring. 14
6.1 Project Monitoring Methods. 14
6.1.1 Weekly Team Meetings. 14
6.1.2 Schedule Tracking. 14
6.1.3 Meet with Customer. 14
6.1.4 Process Reviews. 14
6.2 Project Management Methods. 15
6.2.1 Risk Management 15
6.2.2 Requirements Management 15
6.2.3 Tracking and Oversight 15
6.2.4 Process Management 15
6.2.5 Training. 15
RCBA is business oriented application targeting an organization and provide the solution for their employees and executive to communicate with each other via Unified Communication & Order Management System.
RCBA application will also available on PDA version that communicates with database underlying our web application. This tool allows the sales representative to capture the salient encounter information in real time, upload customer order forms and organize their meetings, contacts, calendar and local email of organization.
The solution is intended to increase the productivity of outside sales forces, whose products are installations and furnishings for homes, hotels, and office buildings. In the past during customer visits, sales representatives had to manually fill in sales orders on paper-based forms. This process was restrictive, time-consuming and source of errors, which need to be update using following object:
· Office Everywhere
· Unified Communication System
· Order Management System
· Conferencing
· Manage Personal Information
During software development the developer apparently has to undergo a certain process named the SDLC (system development life cycle) by using one out of several software process models. This is to establish “the order of the stages involved in software development and evolution and to establish the transition criteria for progressing from one stage to the next.” (Barry W. Boehm, A spiral model of software development and enhancement p.61).
The spiral model allows for a non-linear and more flexible development method. Phases can be revisited at any stage in the process and as many times as need be. The four phases in the spiral model are:
1. Planning
2. Evaluation
3. Risk analysis
4. Engineering
Although the waterfall model “looks very good on paper” better than the spiral method, a product development process is not this simple. It’s said that a waterfall model's success is determined by the “time spent early on” as there is no turning back. However when does one know that enough time has been spent? When is the cut-off period? In fact, it’s said that the closer a “particular plan... [is] followed” the more successful the development, however in the case of such a strict, non iterative model I think that the closer the waterfall model is followed the more chance of failure!
What makes the spiral so robust is the fact that not only does it begin with a hypothesis that if at any time fails then "the spiral is terminated" but also each cycle of the spiral begins with the aims identified, "alternative means of implementing...the product... [and] the constraints imposed". Progression is constantly under scrutiny so there is little chance of mishaps being overlooked. Moreover, the early steps involve a first prototype that is made from the preliminary design; its "strengths, weaknesses, and risks" are evaluated and a second prototype is constructed from this analysis and is tested. This prototype is also evaluated by the customer and the "preceding steps are iterated until the customer is satisfied."
SPIRAL MODEL
To make the team model's "team of peers" concept work, you need to understand and support the roles and dynamics of the team members. Rather than being directly responsible for the day-to-day project direction and tracking, the project manager becomes a facilitator. Depending on the corporate structure, this manager might be the designated Project Manager, Business Manager, or Information Systems Manager.
The following diagram illustrates an overall project structure that includes the suggested project team roles.
The Project Management team includes the Project Manager and the individual leads for each of the team roles. They share the responsibility for planning schedules and resources, assessing risks, and tracking the project. Because each team must deliver on its commitment by completing a set of tasks, each lead should participate in project planning and management. The following items describe examples of this participation.
-
Although the Project Manager might do an initial assessment of how the team model will be applied by considering the characteristics of the project, each team lead should have an opportunity to consider all the factors and determine if the risks are manageable.
-
All team leads participate in negotiating the functional specification. Any proposed changes to the functional specification baseline require agreement from all team leads.
-
Rather than having scheduling and estimating imposed from the top down, each key player should have an opportunity to contribute to the overall schedule and estimates.
-
As the project progresses, each team lead is responsible for assessing risks and participating in tradeoff decisions.
When necessary, the Project Manager may make top-down decisions if the team members cannot reach consensus. Obviously, this can have a tendency to migrate gradually to a more traditional top-down project management style. Only the corporate culture can assure that it will not.
| Work Breakdown Structure (WBS) |
5.1.2 Calculate Adjusted Function Point
To calculate the Complexity adjustment value, several factors have to be considered, such as Backup and recovery, code design for reuse, etc. All the factors and their estimated values in this project are shown in the following table.
The adjusted function point denoted by FP is given by the formula:
FP = total UFP * (0.65 + (0.01 * Total complexity adjustment value)) or
FP = total UFP * (Complexity adjustment factor)
Total complexity adjustment value is counted based on responses to questions called complexity weighting factors in the table below. Each complexity weighting factor is assigned a value (complexity adjustment value) that ranges between 0 (not important) to 5 (absolutely essential).
Table Adjusted Function Points
| Sno. | Complexity Weighting Factor | Value |
| 1 | Backup and recovery | 5 |
| 2 | Data communications | 5 |
| 3 | Distributed processing | 5 |
| 4 | Performance critical | 4 |
| 5 | Existing operating environment | 3 |
| 6 | On-line data entry | 4 |
| 7 | Input transaction over multiple screens | 1 |
| 8 | Master files updated online | 4 |
| 9 | Information domain values complex | 5 |
| 10 | Internal processing complex | 4 |
| 11 | Code designed for reuse | 4 |
| 12 | Conversion/installation in design | 4 |
| 13 | Multiple installations | 4 |
| 14 | Application designed for change | 4 |
|
| Total complexity adjustment value | 56 |
Calculate the Source Lines of Code (SLOC) and the formulas used
· Total Unadjusted Function Points (UFP) = 138
· Product Complexity Adjustment (PC) = 0.65 + (0.01 *56) = 1.21
· Total Adjusted Function Points (FP) = UFP * PC => (138 * 1.21) = 167
COCOMO is one of the most widely used and discussed software cost estimation models. LOC value will be calculated from FP to do the COCOMO calculation. To find LOC and effort we have to choose the programming language also. We will use .NET. LOC/FP for programming languages which we will use in .NET is approximately 46. This value is found from approximating LOC/FP’s for programming languages.
LOC = FP x 46
LOC = 167 x 46 = 7682 LOC ≈ 8 KLOC
According to COCOMO, effort E and duration D are
E = ai * KLOC bi * EAF
D = c E d
Where a, b, c and d are constants depending on your project type. We consider that our project will be embedded. For our project, EAF (Cost Driver) is approximately 1.01(after calculations).
E = 3.6 x (8)1.2 x 1.01
= 44 person-month
D = 2.5 x (44)0.32 = 8.39 months
Average staffing = (44 Person-Months) / (8.39 Months) ≈ 5 people
COMMENTS: In our project, we have 4 people in our team. According to calculations from COCOMO2, we found that we need 5 people to finish the whole project in 8.39 months. We believe that when we work hard, we can finish this project on time.
This part is to use some other estimation techniques on the same FP information and to produce some other comparative approximation.
Albrecht and Gaffney Model: E = -13.39 + 0.0545 * FP
= -4.2885 person-month
Kemerer Model: E = 60.62 x 7.728 x 10-8* FP3
= 21.81 person-months
Matson, Barnet ,Mellichamp Model: E = 585.7 +15.12*FP
= 3110.74 person-month
These results are very far from the effort evaluated in the COCOMO estimation.
5.4 LOC BASED APPROXIMATIONS
We used two LOC based estimation techniques to produce a better approximation.
Walston-Felix Model: E = 5.2 x (KLOC) 0.91
= 34.49 person-months
Boehm Simple Model: E = 3.2 * (KLOC) 1.05
= 28.40 person-month
Doty Model: E = 5.288 * (KLOC) 1.047
= 46.64 person-month
All results are near to COCOMO estimation when compared with FP based estimations. We can use these results for further estimations.
| Inputs |
| Development |
| Delivered Source Instructions (thousands) (KDSI) | 8 |
| Development Mode | Embedded |
| Average Cost Rate (Rs./PM) | 10,000 |
| Maintenance |
| KDSI added (annual) | 0 |
| KDSI modified (annual) | 0 |
| Average Cost Rate (Rs./PM) | 0 |
| |
| |
| Results |
| Effort | 44 | person-months (PM) |
| Schedule | 8 | months |
| Development Cost | 440,000 | Rs. |
| Productivity | 182 | instructions per person-month |
| Average Staffing | 5.5 | full-time-equivalent software personnel |
| Annual Maintenance Effort | 0 | person-months |
| Annual Maintenance Cost | 0 | |
| Phase Distribution |
| Effort (PM) | Schedule (mo.) | Staff (avg.) | Cost |
| Plans and requirements * | 3.5 | 2.2 | 1.6 | 35,000 |
| Product Design | 7.9 | 2.6 | 3 | 79,000 |
| Programming | 25.1 | 3.5 | 7.2 | 251,000 |
| Detailed Design | 11.9 | | | 119,000 |
| Code and unit test | 13.2 | | | 132,000 |
| Integration and test | 11 | 1.9 | 5.8 | 110,000 |
* The plans and requirements phase is calculated in addition to the nominal COCOMO estimate for effort and schedule.
Weekly team meetings will be facilitated by the project supervisor and attended by all team members. Each Team members will be required to submit a progress report for each of their respective teams. At this time problems or potential problems will also be discussed. Suggestions will be made for resolution.
The schedule will be regularly reviewed comparing actual milestones to planned milestones as denoted in the project schedule. In addition, the task start dates will be reviewed to ensure the schedule is not slipping. If there are start date delays or if it looks like milestones may not be achieved on schedule, the appropriate Team Leader will be contacted to discuss and resolve the potential delays.
The critical path will be closely monitored to foresee any upcoming project delays. One method for minimizing these delays is maintaining a somewhat flexible schedule and by staffing the team with members who have both similar and complimentary skill sets.
There will be regular meetings with the customer to review the progress. Current requirements will be also reviewed to ensure that the project requirements have not changed.
Monthly software process reviews will be performed to ensure that the project is headed in the intended direction and in a timely fashion.
As a part of risk management, sources of risk will be identified, addressed, and mitigated before they threaten successful completion of a project. The two primary risk management elements are risk assessment (identifying, analyzing, and prioritizing) and risk control (management planning, resolution, and monitoring).
Initial requirements will be established but these requirements are subject to change and must be monitored and managed. Managing requirements will include capturing, tracking, and controlling requirements, as well as any changes to them. This will establish and maintain a common understanding, between the customer and development team, of the requirements to be addressed by the project. This agreement should be the basis for planning and managing the project.
The project accomplishments will be tracked and reviewed with respect to the project plan. Corrective action will be taken as necessary based on actual accomplishments and results.
In addition to managing the project, the processes involved in managing the project will also be continuously monitored and reviewed. This will include to planning, defining, implementing, monitoring, measuring, and improving processes under project management and producing process documentation and improvement plans.
The engineers working on the project will receive any necessary training to support product development. This will ensure individuals responsible for software engineering activities have the appropriate skills and knowledge relevant to procedures, tools, and domain knowledge.
