Unit - 3
Software Planning & Scheduling
A software project manager is a person who undertakes the responsibility of executing the software project. Project manager may never get directly involved in producing the end product but he controls and manages the activities involved in production.
The responsibility and activities of project manager is large and varied such as-
- Involves with the senior manager to appoint the team members.
- Build the project team and assign tasks to the members.
- The project manager is responsible for effective project planning and scheduling, project monitoring and control activities.
- He effectively resolves issues between team members
- Modifies the project to deal with the situation
Broadly a project manager has two responsibilities
- Project Planning: Project planning is estimating the several characteristics of the project and then planning the activities according to the estimations made.
- Project Monitoring: The main aim of project monitoring is to ensure that the development is progressing as per the plans being made.
Key takeaway:
- A software project manager is a person who undertakes the responsibility of executing the software project.
- Project manager may never get directly involved in producing the end product.
Project Planning is an organized and integrated management process, which focuses on activities required for successful completion of the project. Planning is undertaken and completed even before any development activity starts.
- Estimating the subsequent attributes of the project
- Project Size: What’s going to be the size of the project?
- Cost: How much is it going to cost to develop the software?
- Duration: How long will it take to develop the complete project?
- Effort: What proportion of effort would be required to develop a project?
The effectiveness of the following relies on the accuracy of those estimations.
- Planning force and alternative resources
- Workers organization and staffing plans
- Risk identification, analysis and designing
- Miscellaneous activities such as configuration, quality assurance plan, management, etc.
Precedence ordering among project planning activities:
The diagram given below shows the order during which vital projects coming up with activities are also undertaken. Size Estimate is the first activity. It is conjointly the foremost activity supported by all the other coming up activities such as effort, cost, resource, etc.
|
Fig 1: Precedence ordering among project planning activities
Key takeaway:
- Project Planning is an organized and integrated management process, which focuses on activities required for successful completion of the project.
- Planning is undertaken and completed even before any development activity starts.
Software project scheduling is an activity that distributes estimated effort 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 product functions to which they are applied. As the project gets under way, each entry on the macroscopic schedule is refined into a detailed schedule. Here, specific software tasks (required to accomplish an activity) are identified and scheduled.
Scheduling for software engineering projects can be viewed from two rather different perspectives. In the first, an end-date for release of a computer-based system has already (and irrevocably) 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 bounds have been discussed but that the end-date is set by the software engineering 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.
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
- Determine the critical path—the chain of tasks that determines the duration of the project;
- Establish “most likely” time estimates for individual tasks by applying statistical models; and
- Calculate “boundary times” that define a time "window" for a particular task.
Boundary time calculations can be very useful in software project scheduling. Slippage in the design of one function, for example, can retard further development of other functions. Riggs describes important boundary times that may be discerned from a PERT or CPM network:
- The earliest time that a task can begin when all preceding tasks are completed in the shortest possible time,
- The latest time for task initiation before the minimum project completion time is delayed,
- The earliest finish—the sum of the earliest start and the task duration,
- The latest finish— the latest start time added to task duration, and
- The total float—the amount of surplus time or leeway allowed in scheduling tasks so that the network critical path is maintained on schedule. Boundary time calculations lead to a determination of critical path and provide the manager with a quantitative method for evaluating progress as tasks are completed.
Both PERT and CPM have been implemented in a wide variety of automated tools that are available for the personal computer. Such tools are easy to use and make the scheduling methods described previously available to every software project manager.
Key takeaway:
- Scheduling for software engineering projects can be viewed from two rather different perspectives.
- It is important to note, however, that the schedule evolves over time.
- Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort.
You may not be able to select the best people to work on a project.
- The project budget could not allow highly-paid personnel to be used;
- There may not be available workers with the required experience;
- An organization on a software project may wish to improve employee skills.
Managers have to function within these constraints, especially when there is a shortage of qualified employees. In this global economy, businesses face many obstacles. In order to stay competitive in this challenging industry, the new cutting-edge innovations are increasingly being introduced in order to enhance services and boost their bottom line. This push for technology has generated a tremendous demand for highly qualified and professional personnel for mission-critical projects to be introduced. These technology programmes and associated ventures involve optimal resourcing / staffing strategies to maximise revenues.
With tight deadlines for deliverables, IT managers face difficult staffing problems. They have inadequate personnel and most of them, without adequate preparation, will not be able to take up production using the latest technologies. This calls for a personnel plan/strategy using outsourced resources to support the flexible demands of the projects over the entire life cycle. The aim of the staffing plan is to ensure that, based on the project schedule, the project has adequate personnel with the right skills for successful completion.
Key takeaway:
- The aim of the staffing plan is to ensure that, based on the project schedule, the project has adequate personnel with the right skills for successful completion.
- An organization on a software project may wish to improve employee skills.
PCMM is a framework of maturity which focuses on continuously improving the management and development of an organization's human assets.
It identifies an evolutionary path to improving the development of expertise, skills and motivation of the workforce from Adhoc, inconsistently performed activities, to a mature, disciplined and continuous improvement that improves strategic business efficiency.
The People Capacity Maturity Model (PCMM) is a system that helps the company solve its critical person problems effectively. The PCMM guides companies in improving their steps to manage and grow their workers, based on the best existing research in fields such as human resources, knowledge management, and organisational growth.
The People CMM describes an evolutionary course of change from Adhoc, inconsistently conducted workforce activities, to a mature practise infrastructure to constantly increase workforce capacity.
The PCMM consists of five stages of maturity that lay successive foundations for the continuous improvement of talent, the creation of efficient strategies, and the effective management of the organization's individual properties. Every level of maturity is a well-defined evolutionary plateau that institutionalises a level of capacity within the organisation to grow talent.
People CMM framework are :
|
Fig 2: People CMM model
Level 1 - Initial
No process areas are included in the Initial Maturity stage. While Maturity Level 1 organisation workforce activities appear to be inconsistent or ritualistic, nearly all of these organisations execute processes that are specified in the areas of the Maturity Level 2 phase.
Level 2 - Managed
Managers begin conducting required people management activities such as recruiting, operating performance, and modifying compensation as a repeatable management discipline in order to reach the Managed Standard, Maturity Level 2.
The company creates a unit-level culture to ensure that the employee can fulfil his or her work obligations. The company gains the capacity to control expertise and efficiency at the unit level after reaching Maturity Level 2. Staffing, Communication and Teamwork, Work Climate, Performance Management, Training and Development, and Compensation are the process areas at maturity level 2.
Level 3 - Defined
The basic aim of the specified level is to help a company gain a competitive advantage from the acquisition of the various skills that must be combined to carry out its business activities in its workforce. Such workforce skills are key pillars that help strategic workforce skills to current and future business goals; enhanced workforce practises for Maturity Level 3 are critical enablers of business strategy.
Level 4 - Predictable
The company manages and exploits the capacity built by its system of workforce competencies at the Predictable Stage. The company is now able to quantitatively manage its ability and efficiency. The company can predict its ability to perform work because it can measure its employees' ability and the competency-based strategies they use in their tasks.
Level 5 - Optimizing
The integrated company at the Maximizing Level is based on quality improvement. Such changes are made to the productivity of individuals and workgroups, to the practise of skill-based procedures, and to the strategies and activities of the workforce.
Key takeaway:
- The People Capacity Maturity Model (PCMM) is a system that helps the company solve its critical person problems effectively.
- PCMM is a framework of maturity which focuses on continuously improving the management and development of an organization's human assets.
Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty. Many problems can plague a software project. A risk is a potential problem—it might happen, it might not.
Steps of Risk Analysis and Management:-
- Recognizing what can go wrong is the first step, called “risk identification.”
- Each risk is analyzed to determine the likelihood that it will occur and the damage that it will do if it does occur.
- Risks are ranked, by probability and impact.
- Finally, a plan is developed to manage those risks with high probability and high impact.
In short, the four steps are:
- Risk identification
- Risk Projection
- Risk assessment
- Risk management
Risk always involves two characteristics a set of risk information sheets is produced.
- Uncertainty—the risk may or may not happen; that is, there are no 100% probable risks.
- Loss—if the risk becomes a reality, unwanted consequences or losses will occur.
Types of risks that are we likely to encounter as the software is built:
- Project risks threaten the project plan. That is, if project risks become real, it is likely that the project schedule will slip and that costs will increase. Project risks identify potential budgetary, schedule, personnel (staffing and organization), resource, customer, and requirements problems and their impact on a software project.
- Technical risks threaten the quality and timeliness of the software to be produced. If a technical risk becomes a reality, implementation may become difficult or impossible.
- Business risks threaten the viability of the software to be built. Business risks often jeopardize the project or the product. Candidates for the top five business risks are:
- Market risk,
- Strategic risk,
- Management risk, and
- Budget risks.
- Known risks are those that can be uncovered after careful evaluation of the project plan.
- Predictable risks are extrapolated from past project experience (e.g., staff turnover, poor communication with the customer, dilution of staff effort as ongoing maintenance requests are serviced).
- Unpredictable risks are the joker in the deck. They can and do occur, but they are extremely difficult to identify in advance.
Reactive risk strategies: -
- Reactive risk strategies follow that the risks have to be tackled at the time of their occurrence.
- No precautions are to be taken as per this strategy.
- They are meant for risks with relatively smaller impact.
Proactive risk strategies: -
- Proactive risk strategies follow that the risks have to be identified before start of the project.
- They have to be analyzed by assessing their probability of occurrence, their impact after occurrence, and steps to be followed for its precaution.
- They are meant for risks with relatively higher impact.
Risk Identification
Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary.
One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic categories:
- Product size—risks associated with the overall size of the software to be built or modified.
- Business impact—risks associated with constraints imposed by management or the marketplace.
- Customer characteristics—risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner.
- Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organization.
- Development environment—risks associated with the availability and quality of the tools to be used to build the product.
- Technology to be built—risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.
- Staff size and experience—risks associated with the overall technical and project experience of the software engineers who will do the work.
Risk Projection
Risk projection also called risk estimation, attempts to rate each risk in two ways—the likelihood or probability that the risk is real and the consequences of the problems associated with the risk, should it occur. The project planner, along with other managers and technical staff, performs four risk projection activities:
- Establish a scale that reflects the perceived likelihood of a risk,
- Delineate the consequences of the risk,
- Estimate the impact of the risk on the project and the product, and
- Note the overall accuracy of the risk projection so that there will be no misunderstandings.
Risk Assessment
At this point in the risk analysis process we have established a set of triplets of the form :
Where ri is risk, li is the likelihood (probability) of the risk, and xi is the impact of the risk. During risk assessment, we further examine the accuracy of the estimates that were made during risk projection, attempt to rank the risks that have been uncovered, and begin thinking about ways to control and/or avert risks that are likely to occur.
Therefore, during risk assessment, we perform the following steps:
- Define the risk referent levels for the project.
- Attempt to develop a relationship between each (ri, li, xi) and each of the referent levels.
- Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty.
- Try to predict how compound combinations of risks will affect a referent level.
Risk Mitigation, Monitoring, and Management
- An effective strategy must consider three issues:
- Risk avoidance
- Risk monitoring
- Risk management and contingency planning
- High staff turnover in any organization will have a critical impact on project cost and schedule.
- To mitigate the risk, project management must develop a strategy for reducing turnover. Among the possible steps to be taken are:
- Meet with current staff to determine causes for turnover. Mitigate those causes that are under our control before the project starts.
- Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave.
- Organize project teams so that information about each development activity is widely dispersed.
- Define documentation standards and establish mechanisms to be sure that documents are developed in a timely manner.
- Conduct peer reviews of all work
- Assign a backup staff member for every critical technologist.
Key takeaway:
- Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty.
- Many problems can plague a software project.
- A risk is a potential problem—it might happen, it might not.
- Project risks threaten the project plan.
References:
- Software Engineering: A precise Approach – Pankaj Jalote (Wiley India)
2. Fundamentals of Software Engineering – Rajib Mall (3rd Edition)( PHI)
3. Software Engineering – Concepts & Practices –Ugrasen Suman (CenageLearning)
