Problem:
“Unreasonable” deadlines are a fact of life in the software business. How should you proceed if you’re faced with one?
Answer:
592-24-1P SA Code: 4475
SR Code: 4578
As most developers can attest, unrealistic timelines for software projects are common. But so many estimates wind up, although causes can range from poor decision making by inexperienced project managers to simple miscommunication, If you know what leads to unreasonable estimates, you stand a better chance of preempting problems before the schedule is built. Let some typical reasons why projects wind up with unreasonable estimates.
Based on my experience, I believe that the major causes of unreasonable deadlines are
• Lack of experience
• Business pressure
• Poor communication
• Organizational dysfunction
Document our reservations using quantitative arguments derived from past project metrics. Then suggest an incremental approach that offers to deliver partial functionality in the time allotted with complete functionality following.
Problem:
What is the difference between a macroscopic schedule and a detailed schedule? Is it possible to manage a project if only a macroscopic schedule is developed? Why?
Answer:
592-24-2P SA Code: 4475
SR Code: 4578
Macroscopic Schedule: In order to get a general overview of the entire project the first thing that we did was the macroscopic schedule.Detailed Schedule: Scheduling of software project does not differ greatly from scheduling of any multitask engineering effort. Therefore, generalized project scheduling tools and techniques can be applied with little modification to software projects.
Difference between a macroscopic schedule and a detailed schedule:
Software project scheduling is an activity that distributes estimated efforts across the planned project duration by allocating the effort to specific software engineering tasks. It is important to note, however, that the schedule evolves over time. During early stages of project planning, a macroscopic schedule is developed. This type of schedule identifies all major software engineering activities and the project functions to which they are applied. As the projects get under way, each entry on the macroscopic schedule is refined into detailed schedule. Here, specific software tasks are identified and scheduled.
Scheduling for software engineering projects can be viewed from rather different perspectives. In the first, an end-date for release of a computer-based system has already been established. The software organization is constrained to distribute effort within the prescribed time frame. The second view of software scheduling assumes that rough chronological organization. Effort is distributed to make best use of resources and an end-date is defined after careful analysis of the software. Unfortunately, the first situation is encountered far more frequently than the second.
Thus it is not possible to manage a project if only a macroscopic schedule is developed.
Because, in order to build a complex system, many software-engineering tasks occur in parallel and the result of work performed during one task may have a profound effect on work to conduct in another task. These inter- dependencies are very difficult to understand without a schedule. It’s also virtually impossible to assess progress on a moderate or large software project without a detailed schedule.So, it is impossible to manage a project if only a macroscopic schedule is developed.
Problem:
Is there ever a case where a software project milestone is not tied to a review? If so, provide one or more examples.
Answer:
Not, each task or group tasks must be associated with beginning and a date with end. A task is finished when a review is made on the task in question on account of the quality and when it is approved.
In some cases, milestones are tied to the review of a work product. And some cases, milestones (e.g., integration testing complete) may be tied to successful completion of an integration test plan, rather than a review.
Problem:
“Communication overhead” can occur when multiple people work on a software project. The time spent communicating with others reduces individual productively (LOC/month), and the result can be less productivity for the team. Illustrate (quantitatively) how engineers who are well versed in good software engineering practices and use technical reviews can increase the production rate of a team (when compared to the sum of individual production rates). Hint: You can assume that reviews reduce rework and that rework can account for 20 to 40 percent of a person’s time.
Answer:
When multiple people work on software project, communication overhead can occur. If good reviews reduce rework significantly, it can be argued that the time spent on communication results in time savings (due to less rework) overall.
The time spent communication with others reduces individual productivity.
A formal technical review is a method used to telentify defects in an artifact before progressing to the next stage of development.
For good software engineer practices, use formal technical review and estimate the time needed to communicate others, the results from this experiment should that reviews reduce rework can account 20-40 percent of a person’s time.
Ex:-
The reduction of rework is the key to your argument. This argument is as follows: Typically, it costs more than 10 times as much to find and correct an error during testing as it does to find and correct the same error during, say, design. Therefore, if one hour of communication finds one error during design, it saves 10 hours of work later on.
Problem:
Although adding people to a late software project can make it later, there are circumstances in which this is not true. Describe them.
Answer:
592-24-5P SA Code: 4475
SR Code: 4578
“Adding manpower (or) people to a late software project makes it later”, which has become known as Brooks’ Law.
Generally this is correct but few rules are true without clarification and this is no exception.
The basis of Brooks’ Law is that adding people to a project increases the communication required and, assuming they have no knowledge of the development, will require training, usually by those struggling to finish the development. How long it takes before new team members are productive and how much of the existing team member’s time is taken varies massively from one project to another. Another factor is whether the remaining work can be cleanly split up or “partitionable.
An additional benefit of increasing the size of a team is that the knowledge of that project is spread amongst more people, which, depending on what happens to that project in the future, may be a valuable asset worth sacrificing a period of productivity.
Problem:
The relationship between people and time is highly nonlinear. Using Putnam’s software equation (described in Section 34.2.2), develop a table that relates number of people to project duration for a software project requiring 50,000 LOC and 15 person-years of effort (the productivity parameter is 5000 and B = 0.37). Assume that the software must be delivered in 24 months plus or minus 12 months.
Answer: Problem:
Assume that you have been contracted by a university to develop an online course registration system (OLCRS). First, act as the customer (if you’re a student, that should be easy) and specify the characteristics of a good system. (Alternatively, your instructor will provide you with a set of preliminary requirements for the system.) Using the estimation methods discussed in Chapter 33, develop an effort and duration estimate for OLCRS. Suggest how you would:
a. Define parallel work activities during the OLCRS project.
b. Distribute effort throughout the project.
c. Establish milestones for the project.
Answer:
a)
When one or more persons are involved in a project, the development activities and task will run in parallel.
The following are the concept parallel work activities during the OLCRS project:
• Concept scoping-determines the overall scope of the project.
• Concept planning- ability of an organization to evaluate the project work implied by the project scope.
• Technical risk assignments- calculate the risks involved as a part of project scope.
• Proof of concept- capability of the technologies in terms of software context.
• Concept implementation-implements the concept which is feasible to the customer and is used for marketing purpose.
• Integrate-all the parallel activities are combined into one single activity.
• Customer reaction- feedback on the project used by the customer.
b)
Each and every software project, estimates the work units required to complete the project. The effort distribution across the software process is referred to as the 40-20-40 rule.
Forty percent of effort is assigned to front end and back end analysis and design and twenty percent for coding.
The distribution of effort is given below:
• Project planning-2 to 3 percent of project effort
• Requirements analysis and communication with customer-10 to 25 percent of project effort.
• Software design- 20 to 25 percent of project effort.
• Coding-15 to 20 percent of project effort.
• Testing and debugging-30 to 40 percent of project effort.
The effort distribution is only for guidelines and it may vary from project to project.
c)
Tracking progress of the OLCRS project:
• Technical milestone: OLCRS analysis completion
o Reviewing of classes and class hierarchy
o Reviewing of class attributes and methods
• Technical milestone: OLCRS design completion
o Defining the subsystems
o Allocation of classes to subsystem
o Allocation of task
o Reviewing all the above
• Technical milestone: OLCRS programing completion
o Coding all the classes implemented in the design model
o Defining all the prototype
• Technical milestone: OLCRS testing
o Designing test cases
o Class level tests to be conducted
o System level testing should be performed
o Integration testing should be done
.
Problem:
Select an appropriate task set for the OLCRS project.
Answer:
To develop OLCRS project schedule a task set must be distributed on the project time line. The task set will vary depending upon the project type and the degree of rigor with which the software team decides to do its work.
Conceptual development projects that are initiated to explore some new business concept or application of some new technology.
New application development projects that are undertaken as a consequence of specific customer request.
Application enhancement projects that occur when existing software under goes major modifications to function, performance, or interfaces that are observable by the end user.
Application maintenance projects that correct, adopt, or extend existing software in ways that may not be immediately obvious to the end user.
Even with in a single project type, many factors influence the task set to be elursen.
These include:
Size of the project,
Number of potential users,
criticality,
Application longerity,
Stability of requirements,
Case of customer/developer communication,
Maturity of applicable technology performance constrains embedded and Non embedded characteristics.
Problem:
Define a task network for OLCRS described in Problem 34.7, or alternatively, for another software project that interests you. Be sure to show tasks and milestones and to attach effort and duration estimates to each task. If possible, use an automated scheduling tool to perform this work.
Answer:
4633-27-9P SA: 9420
SR: 6376
Task network for OLCRS (Online course registration system) project:
• Task network is a graphic representation of the task flow for a project.
• If more than one person is involved in a software engineering project then the development activities and tasks will be performed in parallel.
• The task network depicts major engineering tasks.
Task network for a concept of developing OLCRS project:
In this process, each step takes two days of effort, and the total duration of all these tasks takes minimum of 2 weeks.
This is calculated by
Problem:
If an automated scheduling tool is available, determine the critical path for the network defined in problem 34.9.
Answer: Problem:
Using a scheduling tool (if available) or paper and pencil (if necessary), develop a time-line chart for the OLCRS project.
Answer:
Timeline chart for on-line course registration system:-
A timeline chart can be developed for the entire project. In this, time line chart “Left hand column, represents the all project tasks, and the horizontal bars are indicate the duration of each task.
Online course registration system consists of the following outlines
Total course duration
Types of course
Facilities of particular task
Problem:
Assume you are a software project manager and that you’ve been asked to compute earned value statistics for a small software project. The project has 56 planned work tasks that are estimated to require 582 person-days to complete. At the time that you’ve been asked to do the earned value analysis, 12 tasks have been completed. However the project schedule indicates that 15 tasks should have been completed. The following scheduling data (in person-days) are available:
Compute the SPI, schedule variance, percent scheduled for completion, percent complete, CPI, and cost variance for the project.
Answer:
Schedule Performance Index 
Hence, Schedule Performance Index is 0.81.
Schedule Variance SV
Hence, Schedule Variance is -29.0.
Percentage schedule for completion
Hence, Percentage schedule for completion is 80.8%.
Percent Complete
Hence, Percent Complete is 81.47%.
Cost performance index CPI
Hence, Cost performance index is 1.0.
Cost variance CV 
Hence, Cost variance is 1.0.
Solution: Chapter 34: PROJECT SCHEDULING
34.1 Document your reservations using quantitative arguments derived from past project metrics. Then suggest an incremental approach that offers to deliver partial functionality in the time allotted with complete functionality following.
34.2 The macroscopic schedule must be refined to create a detailed project schedule. Refinement begins by taking each major task and decomposing it into a set of subtasks (with related work products and milestones). It would be very difficult to track a project using only macroscopic schedule since it would hard to assess progress since no milestones are defined.
34.3 In most cases, milestones are tied to the review of a work product. However, some milestones (e.g., integration testing complete) may be tied to successful completion of an integration test plan, rather than a review.
34.4 The reduction of rework is the key to your argument. If good reviews reduce rework significantly, it can be argued that the time spent on communication (during reviews) results in time savings (due to less rework) overall. The crux of this argument is as follows: Typically, it costs more than 10 times as much to find and correct an error during testing as it does to find and correct the same error during, say, design. Therefore, if one hour of communication finds one error during design, it saves 10 hours of work later on. Big payoff!
34.5 If a project is compartmentalized and well organized; if good documentation has been done; if interfaces are clearly defined; if parallel tasks are possible; if the people who are added are generally competent; if newcomers can pick up what they need form the configuration, rather than the software engineers currently working on the project, you can add people to a project without negative impact.
34.6 The relationship can be developed by solving for td and varying the number of person months and duration as indicated.
34.7 through 34.11 Be sure that your students first establish the scope of the OLCRS project. Depending on requirements, this can become quite complex. An alternative is for you to provide a requirements handout so that everyone is working from the same scope.
In general, a structured, new application development project should be chosen.
The project team should have at least three people. This will force students to consider parallel activities.
A tool such as Microsoft Project will be extremely useful to illustrate important concepts.
34.12 Use the steps defined in Section 34.6 to compute earned value. First sum all planned effort through task 12. In this case,
BCWS = 126.50
BAC = 156.50
BCWP = 127.50
SPI = BCWP/BCWS = 127.5/126.5 = 1.008
SV = BCWP - BCWS = 127.5 - 126.5 = 1.0 person-day
percent complete = BCWP/BAC = 81%
Other earned-value data are computed in the same way.