Unit-3 Project Scheduling

Que 1. What do you mean by project scheduling? Explain the basic concept of project scheduling.

Project Scheduling

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 be conducted 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.

Proper project scheduling requires that:

1. All tasks appear in the network,
2. Effort and timing are intelligently allocated to each task,
3. Interdependencies between tasks are properly indicated,
4. Resources are allocated for the work to be done, and
5. Closely spaced milestones are provided so that progress can be tracked.

Scheduling is the culmination of a planning activity that is a primary component of software project management. When combined with estimation methods and risk analysis, scheduling establishes a road map for the project manager. Scheduling begins with process decomposition. The task network is used to compute the critical path, a timeline chart and a variety of project information. Using the schedule as a guide, the project manager can track and control each step in the software process.

A number of basic principles guide software project scheduling:

• Compartmentalization: The project must be compartmentalized into a number of manageable activities and tasks. To accomplish compartmentalization, both the product and the process are decomposed.
• Interdependency: The interdependency of compartmentalized activity or task must be determined. Some tasks must occur in sequence while others can occur in parallel. Some activities cannot commence until the work product produced by another is available. Other activities can occur independently.
• Time Allocation: Each task to be scheduled must be allocated some number of work units (e.g., person-days of effort). In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies and whether work will be conducted on a full-time or part-time basis.
• Effort Validation: Every project has a defined number of staff members. As time allocation occurs, the project manager must ensure that no more than the allocated number of people has been scheduled at any given time.
• Defined Responsibilities: Every task that is scheduled should be assigned to a specific team member.
• Defined Outcomes: Every task that is scheduled should have a defined outcome. For software projects, the outcome is normally work product (e.g., the design of a module) or a part of a work product. Work products are often combined in deliverables.
• Defined Milestones: Every task or group of tasks should be associated with a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved.

Each of these principles is applied as the project schedule evolves.

1. In small software development project a single person can analyze requirements, perform design, generate code, and conduct tests. As the size of a project increases, more people must become involved.
2. There is a common myth that is still believed by many managers who are responsible for software development effort: “If we fall behind schedule, we can always add more programmers and catch up later in the project.”
3. Unfortunately, adding people late in a project often has a disruptive effect on the project, causing schedules to slip even further.
4. The people who are added must learn the system, and the people who teach them are the same people who were doing the work. While teaching , no work is done, and the project falls further behind.
5. In addition to the time it takes to learn the system, more people increase the number of communication paths and the complexity of communication throughout a project.
6. Although communication is absolutely essential to successful software development, every communication path requires additional effort and therefore additional time.
7. But there are some cases in which this comment may not be true. Say for example-
   • Communication, if it is effective, can enhance the quality of the work being performed, thereby reducing the amount of rework and increasing the individual productivity of team members.
   • If project is guided by prototyping model then people who have worked on initial prototypes if added later, experiences so that the project gets completed very fast. they can utilize their previous experiences so that the project gets completed very fast.
   • If Incremental evolutionary model is used as process model then adding people late can increase the speed with which the project can be completed.
   • If late added human resource have experiences of being worked on similar projects of that type, in that case also the above comment prove to be false one as they can guide other by “knowledge transfer mode” activities.
   • If the project work is highly compartmentalized adding people late will be significant.

This are the some circumstances where above comment is not found to be valid.

Que 2. Explain empirical relationship between numbers of lines of code delivered, effort and the development time.

Relationship between People and Effort

1. In small software development project a single person can analyze requirements, perform design, generate code, and conduct tests. As the size of a project increases, more people must become involved.
2. There is a common myth that is still believed by many managers who are responsible for software development effort: “If we fall behind schedule, we can always add more programmers and catch up later in the project.”
3. The relationship between people and time is highly nonlinear. It means it is very tough to predict result when one of them is given and other is to be found out.
4. Using Putnam’s software equation we can demonstrate the highly nonlinear relationship between chronological time to complete a project and human effort applied to the project. The number of delivered lines of code (source statements), L, is related to effort and development time by the equation: L = P x E^1/3 x t^4/3 where, E is development effort in person-months, P is a productivity parameter that reflects’ a variety of factors that lead to high-quality software engineering work (typical values for P range between 2,000 and 12,000), and tis the project duration in calendar months.
5. Rearranging this software equation, we can arrive at an expression for development effort E: E = L^a / (P^3 t^4) where, E is the effort expended (in person-years) over the entire life cycle for software development and maintenance and, t is the development time in years.
6. The equation for development effort can be related to development cost by the inclusion of a burdened labor rate factor ($/person-year).
7. Example: Consider a complex, real-time software project estimated at 33,000 LOC, 12 person-years of effort. If eight people are assigned to the project team, the project can be completed in approximately 1.3 years. If, however, we extend the end-date to 1.75 years, the highly nonlinear nature of the model described in equation above yields: E = L^a / (P^3 t^4)=3.8 person-years. This implies that, by extending the end-date six months, we can reduce the number of people from eight to four. The validity of such results is open to debate, but the implication is clear: Benefit can be gained by using fewer people over a somewhat longer time span to accomplish the same objective.
8. A recommended distribution of effort across the definition and development phases is often referred to as the 40-20-40 rule.

Forty percent of all effort is allocated to front-end analysis and design. A similar percentage is applied to back-end testing. This is also known as Putnam’s relationship.

Also Read – Mojo🔥 Programming Language: Empowering the Revolution in AI Development in 2023

Que 3. Define a task set for the software project.
Explain activity network mechanism for concept development.
Explain how to define a task set for software project. Also define task network in detail.

Defining Task Set and Task Network

Regardless of whether a software team chooses a linear sequential paradigm, an iterative paradigm, an evolutionary paradigm, a concurrent paradigm or some permutation, process model is populated by a set of tasks that enable a software team to define, develop, and ultimately support computer software.

Task Set:

1. No single set of tasks is appropriate for all projects. The set of tasks that would be appropriate for a large, complex system would likely be perceived as overkill for a small, relatively simple software product.
2. Therefore, an effective software process should define collection of task sets, each designed to meet the needs of different types of projects.
3. A task set is a collection of software engineering work tasks, milestones, and deliverables that must be accomplished to complete a particular project.
4. The task set to be chosen must provide enough discipline to achieve high software quality. But, at the same time, it must not burden the project team with unnecessary work.
5. Task sets are designed to accommodate different types of projects and different degrees of rigor. Although it is difficult to develop a comprehensive taxonomy of software project types, most software organization encounter the following projects:
   • Concept development projects that are initiated explore some new business concept or application of some new technology.
   • New application development projects that a undertaken as a consequence of a specific customer request.
   • Application enhancement projects that occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end-user.
   • Application maintenance projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end-user.
   • Reengineering projects that are undertaken with the intent of rebuilding an existing (legacy) system in whole or in part.

Even within a single project type, many factors influence the task set to be chosen. When taken in combination, these factors provide an indication of the degree of rigor with which the software process should be applied.

Selecting Software Engineering Task

1. In order to develop a 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.
2. Each of the project types may be approached using a process model that is linear sequential, iterative (e.g., the prototyping or incremental models), or evolutionary (e.g., the spiral model).
3. In some cases, one project type flows smoothly into the next. For example, concept development projects that succeed often evolve into new application development projects.
4. As a new application development project ends, an application enhancement project sometimes begins. This progression is both natural and predictable and will occur regardless of the process model that is adopted by an organization.
   • As an example, we consider the software engineering tasks for a concept development project. Concept development projects are initiated when the potential for some new technology must be explored. Concept development projects are approached by applying the following major tasks:
   • Concept Scoping determines the overall scope of the project.
   • Preliminary Concept Planning establishes the organization’s ability to undertake the work implied by the project scope.
   • Technology Risk Assessment evaluates the risk associated with the technology to be implemented as part of project scope.
   • Proof of Concept demonstrates the viability of a new technology in the software context.
   • Concept Implementation implements the concept representation in a manner that can be reviewed by a customer and is used for “marketing” purposes when a concept must be sold to other customers or management.
   • Customer Reaction to the Concept solicits feedback on a new technology concept and targets specific customer applications.

The software team must understand what must be done (scoping); then the team (or manager) must determine whether anyone is available to do it (planning), consider the risks associated with the work (risk assessment), prove the technology in some way (proof of concept), and implement it in a prototypical manner so that the customer can evaluate it (concept implementation and evaluation). Finally, if the concept is viable, a production version (translation) must be produced.

Also Read – Short note on Project Scheduling – GeeksforGeeks

Que 4. Why task networking is important in project scheduling? Explain.

Defining a Task Network

Individual tasks and subtasks have interdependencies based on their sequence. In addition, when more than one person is involved in a software engineering project, it is likely that development activities and tasks will be performed in parallel. When this occurs, concurrent tasks must be coordinated so that they will be complete when later tasks require their work product(s).

A task network, also called an activity network, is a graphic representation of the task flow for a project. It sometimes used as the mechanism through which task sequence and dependencies are input to an automated project scheduling tool.

In its simplest form (used when creating a macroscopic schedule), the task network depicts major software engineering tasks. Figure shows a schematic task network for a concept development project.

The concurrent nature of software engineering activities leads to a requirements. number of important scheduling Because parallel tasks occur asynchronously, the planner must determine inter task dependencies to ensure continuous progress toward completion.

In addition, the project manager should be aware of those tasks that lie on the critical path. That is, tasks that must be completed on schedule if the project as a whole is to be completed on schedule.

It is important to note that the task network shown in Figure is macroscopic. In a detailed task network (a precursor to a detailed schedule), each activity shown in Figure would be expanded.

Que 5. Explain Scheduling using timeline chart.
How schedule management process works?

Scheduling

Scheduling of a 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.

Program evaluation and review technique (PERT) and critical path method (CPM) are two project scheduling methods that can be applied to software development.

Both techniques are driven by information already developed in earlier project planning activities:

• Estimates of effort
• A decomposition of the product function
• The selection of the appropriate process model and task set
• Decomposition of tasks.

Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product as a whole or for individual functions. Both PERT and CPM provide quantitative tools that allow the software planner to-

1. Determine the critical path the chain of tasks that determines the duration of the project.
2. Establish “most likely” time estimates for individual tasks by applying statistical models and time.
3. Calculate “boundary times” that define a “window” for a particular task.

Timeline Chart

When creating a software project schedule, the planner begins with a set of tasks (the work breakdown structure). If automated tools are used, the work breakdown is input as a task network or task outline. Effort, duration, and start date are then input for each task. In addition, tasks may be assigned to specific individuals.

As a consequence of this input, a timeline chart, also called a Gantt chart, is generated. A timeline chart can be developed for the entire project. Alternatively, separate charts can be developed for each project function or for each individual working on the project.

Figure illustrates the format of a timeline chart. It depicts a part of a software project schedule that emphasizes the concept scoping task for a new word- processing (WP) software product.

This time line-chart is formed by following these steps

• All project tasks (for concept scoping) are listed in the left-hand column.
• The horizontal bars indicate the duration of each task. When multiple bars occur at the same time on the calendar, task concurrency is implied.
• The diamonds indicate milestones.
• Once the information necessary for the generation of a timeline chart has been input, the majority of software project scheduling tools produce project tables a tabular listing of all project tasks, their planned and actual start and end dates, and a variety of related information.
• Used in conjunction with the timeline chart, project tables enable the project manager to track progress. A timeline chart enables you to determine what tasks will be conducted at a given point in time.

Que 6. Explain earned value analysis.
What is Earned Value Analysis? Explain with suitable example.
Explain EV analysis in detail.

1. The number of qualitative approaches to project Ver tracking provides the project manager with an indication of progress, but an assessment of the information provided is somewhat subjective so it needs to make use of Earned value analysis.
2. It is reasonable to ask whether there is a quantitative technique for assessing progress as the software team progresses through the work tasks allocated to the project schedule.
3. In fact, a technique for performing quantitative analysis of progress does exist. It is called Earned value analysis (EVA). The earned value system provides a common value scale for every software project task, regardless of the type of work being performed.
4. The total hours to do the whole project are estimated, and every task is given an earned value based on its estimated percentage of the total.
5. Stated even more simply, earned value is a measure of progress. It enables us to assess the percent of completeness” of a project using quantitative analysis rather than rely on a gut feeling.

To Determine the Earned Value, the following Steps are performed:

1. The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. Hence, BCWSi is the effort planned for work task i. To determine progress at a given point along the project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule.
2. The BCWS values for all work tasks are summed to derive the budget at completion, BAC. Hence, BAC = (BCWSk) for all tasks k
3. Next, the value for budgeted cost of work performed (BCWP) is computed. The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule.

Noting Down some of the Facts Regarding EVA are as-

• Wilkens notes that the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned to be completed and the latter represents the budget of the activities that actually were completed.
• Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:
  1. SPI is an indication of the efficiency with which the project is utilizing scheduled resources. Schedule performance index, SPI = BCWP/BCWS.
  2. SV is simply an absolute indication of variance from the planned schedule. Schedule variance, SV = BCWP-BCWS.
  3. Percent scheduled for completion provides an indication of the percentage of work that should have been completed by time t. Percent scheduled for completion = BCWS/BAC.

Que 7. Explain Project Plan in detail.

1. Each step in the software engineering process should produce a deliverable that can be reviewed and that can act as a foundation for the steps that follow.
2. The Software Project Plan is produced at the culmination of the planning tasks. It provides baseline cost and scheduling information that will be used throughout the software process.
3. The Software Project Plan is a relatively brief document that is addressed to a diverse audience.
4. It must
   • Communicate scope and resources to software management, technical staff, and the customer.
   • Define risks and suggest risk aversion techniques; Define cost and schedule for management review.
   • Define cost and schedule for management review.
   • Provide an overall approach to software development for all people associated with the project and
   • Outline how quality will be ensured and change will be managed.
5. A presentation of cost and schedule will vary with the audience addressed. If the plan is used only as an internal document, the results of each estimation technique can be presented. When the plan is disseminated outside the organization, a reconciled com breakdown (combining the results of all estimation techniques) is provided.
6. Similarly, the degree of detail contained within the schedule section may vary with the audience and formality of the plan.

It is important to note that the Software Project Plan is not a static document. That is, the project team revisits the plan repeatedly updating risks, estimates, schedules and related information as the project proceeds and more is learned.

Que 8. What are root causes to deliver s/w late?

• Planning and The Optimism Trap: A major reason why projects deliver late is that the original deadline wasn’t realistic. Sometimes, in wanting to please the customer, account executives, project managers, and even technical leads can put on rose-colored glasses about the challenges the project entails. Applications always get more complicated the closer you look at them.
• Time, Resources, or Scope: Every project (software or otherwise) exists on three axes of project management: time, resources, and scope. If you want to build a big project with a lot of features, you’re either going to need a lot of time, a lot of resources, or both. These three axes of project management are inseparably linked. Software projects are often late because requirements change over time and more functionality gets added without changing the delivery date to match the new workload.
• Doing the Unknown: Good project managers build buffers into their delivery timelines because there are always unexpected things that arise. Projects get more complicated the more you work on them. What seems like a simple implementation can often turn into a confusing puzzle once you get into the nitty-gritty of passing and returning values, building APIs, and making various libraries or frameworks work together.
• Waterfall vs. Agile: One way to reduce your exposure and risk to unknowns is to use an iterative approach. If you only plan a small portion of the project at a time, then you have greater control over the factors at play and can quickly assess and test how things are going. That’s one of the key reasons for using an agile methodology when developing software. With every sprint and review, we can immediately see what’s working, what the client likes/dislikes, and modify our next steps to address any issues. Agile projects find problems quickly and course correct immediately. With traditional waterfall-style project planning, the long time between releases makes delays more likely. Problems take longer to discover, and running into a problem is a huge hurdle that could derail the whole project. In an agile environment, a major issue is a signal to the developers to reassess their current plan and tweak the approach. In waterfall, where project. specs are set in stone from the beginning, it is much harder to work around issues.
• No or Slow Feedback from Real Users: Of course, an agile approach relies on feedback from the people who will actually be using the software. All too often that feedback is slow to arrive. Then, the agile team geta blindsided when a feature they released weeks ago, and which they’ve been building atop, receives delayed criticism from stakeholders. This feedback delay often means developers waste effort and have to retrace their steps, slowing down development.
• Delivering On-Time: Being aware of common pitfalis and following the best practices above doesn’t guarantee that every project will always deliver on time. However, these recommendations can go a long way toward setting clear expectations and solving most delays that software companies face. If everything goes exactly to plan, you’ll be pleased to be so far ahead of schedule. If you run into issues, you can rest easy knowing you planned ahead for the challenges and have wiggle room to work out a solution.

Apart from above reason there are some reason which causes to deliver software late those are shown below.

• Unrealistic deadlines forced from the outside
• Changed requirements not reflected in schedule
• Underestimation of effort
• Risks not considered
• Unforeseen technical & human difficulties
• Miscommunication among project staff
• Management fails to see that the project falls behind schedule.