5.

Software Project management Marks: 18

5.1 INTRODUCTION TO SOFTWARE PROJECT MANAG AND ITS NEED

 It is very necessary to perform project management activity, when computer-based systems and products are
built.
 Project management involves the planning, monitoring and control of the people, process, and events that
occurs from preliminary concept to full operational deployment.
 Building the computer software becomes complex if it involves many peoples working together for long
period of time. So software projects needs to be managed.
 The process of software Project management includes thousands of activities which are linked with each
other. Without software project management it is impossible to develop successful and high quality software.
 Software project management ensures that the software is delivered on time and is according with the
requirements.
 Project management is needed because software development is always focuses on budget and schedule
constraints.

5.2. MANAGEMENT SPECTRUM

 Project management involves the planning, monitoring and control of the people, process, and events that
occurs from preliminary concept to deployment.
 Software engineer manages his/her daily activities by planning, monitoring and controlling technical tasks.
But the Project Manager plans, monitors and controls the work of a team of software Engineers.
 The Management Spectrum :The software Project Manager focuses on the FOUR "P's" :
1. People
2. Product
3. Process
4. Project.

1. People:-
 The People factor is important so that the Software Engineering institute (SEI) has developed a People
Management Maturity Model (PM-CMM), to enhance the capacity of organizations to develop complex
applications and helps to motivate the team members.
 People Management Maturity Model (PM-CMM) defines the following key practice areas for Software
people :
1. Recruiting,
2. Selection,
3. Performance management,
4. Training,
5. Compensation,
6. Career development,
7. Organization and Work design, and
8. Team culture development.
 If any organization follows these practices, they will achieve the high level of maturity.
2. Product (Software Application System) :
 Before a Product can be planned :
1. Objectives and Scope should be established.
2. Alternative solutions should be considered.
3. Technical and Management constraints should be identified.
 The Software Developer and Customer must meet to define Product Objectives and Project Scope.
 Objectives identify the Overall Goals for the product, without considering how these Goals will be achieved;
 Scope identifies what Functions, data and behavior the product should have.
  Once, the Product Objectives and Scope are understood, the alternative solutions are identified. So the
Managers and Software Engineers will select the 'Best' solution.
 The technical and management Constraints like Delivery Date, deadlines, budgetary restrictions, Personal
availability, and Technical interfaces are identified.
 Without defining objectives, Scope and Considering Alternative solutions and identifying Constraints, it is
impossible to :
1. Define accurate "Estimates of Costs" and “Risk Assessment".
2. Develop a manageable Schedule that provides a meaningful indication of progress.
3. Process :
 A Software Process provides the Framework from which the plan for software development can be
established.
 The plan consist of :
i) A small number of Framework Activities called Common Process Framework (CPF) which are
applicable to all Software regardless of its size & complexity;
ii) A number of different Task Set which defines :Tasks, Milestones, Work Products (Deliverables)
and Quality Assurance Points.
4. Project:-

 In some cases the success rate for software projects failure rate remains higher than it should be.
 Why software project fail?
1. An unrealistic deadline established.
2. Changing customer Requirements.
3. An underestimate of effort.
4. Predictable and / or unpredictable risks.
5. Technical difficulties.
6. Miscommunications among Project members
7. Failure in project management
 Avoiding project failure:-To avoid project failure, a software manager and software engineers must:-
a. Need a set of common warning signs.
b. Understand the Critical Success Factor (CSF) that lead to good project management.
c. Develop a common sense approach for Planning, Monitoring and controlling a project.

5.2.1 The People:-

 Managers always argue that People are primary resources.

1. People as the Project Players (Stakeholders) :
 The Software Process is populated by Stakeholders who can be categorized into one of the five types
i. Senior Managers: Define Business issues and have important influence on Project.
ii. Project Managers: Who must Plan, Motivate, Organize and Control the Software practitioners
(software developers), who do the work.
iii. Practitioners: Who apply technical skills that are necessary to develop Software Product or
Application.
iv. Customers: Who specify the requirements of Software to be developed and have interest in the
outcome of Project.
v. End-user: Who interact with Software Product when it is released for use.
 In every Software Project, both technical and non-technical peoples are involved.
2. Team Leaders (Project Leader) :
 Project management is a people intensive activity and very difficult task for team leader because they do
not have right mix of People skills.
 3. The Technical Leadership Model (Suggested by Weinberg) : MOI model of Leadership :-
i. Motivation: The ability to encourage (by Push or Pull) technical people to produce their best
ability.
ii. Organization: The ability to develop the process in which initial concept to be translated into
Product.
iii. Ideals of Innovation: The ability to encourage people to create innovations by working within
bounds.
4. Problem Solving Management Style (Suggested by WEINBERG) :-
 A Successful Project Leader apply a Problem Solving Management Style in MOI Model that is :
i. Concentrate on understanding the Problem to be solved.
ii. Taking the ideas from team members and at the same time tells everyone that the quality is important
and that the quality will not be compromised.
5. Characteristics of an Effective Project Manager - The Four Key Traits :
i. Problems Solving :
 An effective Project Manager can diagnose the technical and organizational issues to find out the
solution.
 Motivate other practitioners to develop the solution.
 Apply lessons learned from past projects.
 Remain flexible enough to change direction if initial attempts are failed.
ii. Managerial Identify :
 An effective Project Manager must take charge of the project.
 Have the confidence to assume control when necessary and the assurance to allow good technical
people to follow their instincts.
iii. Achievements :
 To increase the productivity of a Project Team, an effective Manager must "Reward initiative and
Accomplishment”.
 Demonstrate through his own actions that the peoples who are taking risky work will not be
punished.
iv. Influence and Team Building :
 An effective Project Manager must be able to "Read People", be able to understand verbal and non-
verbal signals and react to the needs of the people ending these signals.
 Also effective manager must remain in control in high-stress situations.
6. The Software Project Team :-
 There are many Human Organizational Structure (Team Structure) for team development.
 The best team structure depends on :
1. Management style of the organization.
2. The number of People who will populate the team.
3. Team member‟s skill levels.
4. Overall Problem difficulty.
 The Seven Project Factors when Planning the Structure for Software engineering Team :
1. The difficulty of the problem to be solved.
2. The size of programs in Line Code (LOC) .
3. The time that the team will stay together (Team Lifetime).
4. The degree in which the problem can be modularized.
5. The required quality and reliability of the system to be built.
6. The rigidity of the delivery date.
7. The degree of sociability (Communication) required for project.
 High Performance Team :
 To achieve a high performance team,
a) Team members must trust in one another.
b) The skills should be distributed to solve the problem.
 c) Mavericks (independent peoples) may have to be excluded from the team, to maintain team
cohesiveness.
 A Jelled Team :
 According to Demarco and Lister, a Team is not only any group of people assigned to work together
but these group must have :
1. Common definition of Success and /or
2. Any identifiable Team Spirit.
 Human Traits :
 Some Project Team members are extrovert, some are introvert.
 Some people are comfortable to making decisions based on situation. Others are intrusive, willing to
make decision based on "feel".
 Some Software Practitioners want a detailed schedule by the organization. Others prefer a more
spontaneous environment in which they are openly works.
 Some work hard to get things done well before the milestones date to avoid the stress as the date
approaches while others starts their work at just last minute of deadline.
 Agile Teams :
 The Agile Software Development focuses on Customer satisfaction and Early Incremental
delivery of Software through :
1. Small highly motivated Project teams;
2. Informal methods
3. Minimal software engineering work product.
4. Overall development simplicity.
 The small, highly motivated Project Team also called an "Agile Project Team" adopts many
of the Characteristics of Successful Software Project teams.
 The Agile team emphasizes the following characteristics as the Critical Success Factors (CSF)
for the Team :-
1. Team Member's competence(ability) and
2. Group Collaboration.
 Many Agile Process Models such as Extreme Programming (XP), Adaptive Software
Development (ASD), Dynamic Systems Development Method (DSDM) and SCRUM etc. gives
the freedom to make the Project Management and Technical decision required to get the job
done.
 Coordinating and Communication Issues of Project Team :
 There are many reasons that Software Projects get into trouble :
1. The Scale of many development efforts is large, causing significant difficulties in
coordinating team members.
2. Uncertainty (changes) is common, resulting the confusion among project team members.
3. Interoperability has become a key characteristic of many systems.
 To deal with the above problems, a Software Engineering team must establish Effective
Methods for coordinating the people who do the work.
 To accomplish this, Formal and Informal Communication Mechanism must be established
among the Team Members.
5.2.2 The Product:-

 A Software Project Manager faces the problems at the beginning of software project because:-
1. Quantitative Project Estimates and an Organized Project Plan are required but the information is not
available at beginning.
2. Analysis of the required information takes weeks or months to complete. And a plan is needed
"immediately”!
3. Therefore, we must examine the Software Product to solve at the very beginning of the project. At a
minimum Scope of the Product must be established.
 Software Scope :
 The first activity of Software Manager is to determine the Scope of Software.
 Software Scope is defined in terms of :-
1. Context: How does the software to be built fit into a large system?
2. Information Objective: What customer visible data objectives produced as output from the
software? What data objectives are required for input?
3. Function and Performance: What function does software perform to transform input data into
output?
 Software project scope must be Unambiguous and understandable.
 Also a "Statement of Software Scope" must be bounded. (That is the Constraint and / or Limitations
should be described).
 For example: Cost Restrictions, Memory Size, Number of simultaneous users, maximum allowed
response time etc.
 Problem Decomposition (Problem Partitioning) :
 The decomposition is applied in two major areas :
1. The functionality that must be delivered.
2. The process that will be used to deliver it.
 The "Divide and Conquer strategy" is used when the problem is very complex. A complex problem is
partitioned into smaller pieces so that it can be better managed. And later all these pieces are combined.

5.2.3 The Process:-

1. Selecting Best Process Model :

 The Project Manager must decide which Process Model is most appropriate for:
i. The Customers and the People who will do the work (Users).
ii. The characteristics of the Product itself.
iii. The Project Environment in which the Software works.
 When a Process Model is selected, the Software Team then defines a Preliminary Project Plan based
on the set of "Common Process Framework" (CPF) activities.
 Once, the Preliminary Project Plan is established, Process Decomposition begins.

2. Melding the Product and Process:

 Project Planning begins with the melding (combination) of Product and the Process.
 Each function must pass through the set of Framework Activities which are:-
i) Customer Communication (CC),
ii) Planning (PL),
iii) Risk Analysis (RA),
iv) Engineering (EN),
v) Construction and Release (CR), and
vi) Customer Evaluation (CE).
 The Metrics below represent the Product and Process Melding:
Common Process Framework Activities
CC PL RA EN CR CE ------- -----
(CPF)

Software Engg. Tasks

Product Functions

Text Input

Editing and Format

File Management

Documentation

 Project manager is to Estimate Resource Requirements for each metrics cell with Start and End
Dates for each Task and Work Products to be produced (delivered) for each task.
3. Process Decomposition:-
 A software team member should have flexibility to choosing the best software process model.
 Once the process model has been chosen, the process framework is adapted to it.
 In each and every case, the generic framework is communication, planning, modeling, construction and
deployment.
 A simple project might require the following work tasks.
i. Develop list of clarification issues.
ii. Meet with customer to address clarification issues.
iii. Jointly develop a statement of scope.
iv. Review the statement of scope.
v. Modify the statement of scope as required.
 Above events might occur over a period or less than 48 hours.
5.2.4 The Project:-

 To manage a Successful Software Project, we must understand how the problem can be avoided:-
 The following are the suggestions from John Reel :-
1. Ten Signs that Indicate an Information System is in Jeopardy (failure):
i. Software People do not understand their Customers' needs.
ii. The Product Scope is poorly defined.
iii. Changes are managed poorly.
iv. The chosen technology changes.
v. Business needs changed.
vi. Deadlines are unrealistic.
vii. Users are resistant.
viii. Sponsorship is lost.
ix. The Project Team lacks people with appropriate skills.
x. Managers / Practitioners not applying best practices and lessons learned from past projects.

2. The 90-90 Rule :

 Most Industrial Professional refers to apply the "90 - 90 Rule” for difficult Software Projects.
 The first 90% of a code absorbs 90% of the Allocated Effort and Time.
 The remaining 10% takes the other 90% of the Allocated Effort and Time.
 John Reel also suggests a Five-Part Common Sense Approach to avoid the problem of project in
Jeopardy.
 3. The Five Part-Common Sense Approach to Avoid Project Problems :
i. Start on the right foot
ii. Maintain momentum
iii. Track progress
iv. Make smart decisions
v. Conduct a postmortem analysis
i. Start on the Right Foot.
 This is accomplished by working hard to understand the problem that is to be solved and then
setting the objectives and expectations for everyone who will be involved in the Project.
 This is achieved by building the "Right team" and giving the team freedom, authority and
technology needed to do the job.
ii. Maintain Momentum :
 Many Projects have good starting and then performance degrades slowly as time passes.
 The Manager must keep "Staff turnover" to minimum.
 The Team should emphasize quality in every task it performs.
 Senior Management should do everything possible to "Stay out of team's way".
iii. Track Processes :
 Progress is tracked as work products (i.e. specification, source code, test results etc.) are produced
and approved.
 Additionally, Software Process and Project Measures can be collected and used to Assess Progress.
iv. Make Smart Decision :
 In essence the decision of Project Manager and the Team should be "Keep It Simple".
1. Decide to use, commercial available Off-the-shelf Software or Existing Software components.
2. Decide to avoid Custom Interface when standard approaches are available.
3. Decide to identify and then avoid the risks.
4. Decide to allocate more time than you think is needed to complex or risky tasks.
v. Conduct A Postmortem Analysis :
 Establish a mechanism for extracting lessons learned from each Project by,
1. Evaluate planned and actual schedules,
2. Collect and analyze software project metrics, and
3. Record everything in written form.

5.3 PROJECT SCHEDULING :-

 Project scheduling provides details like start and end date of the project, milestones, and tasks for the
project.
 Project scheduling specifies the resources like people, equipment etc. required to complete the project and
dependencies of tasks of the project on each other.
 An appropriate project schedule can be prepared according to the project plan.
 Scheduling for software development projects can be viewed from two rather different perspectives:
i. An end date for release of a software system has already been established by customer.
ii. Rough dates have been discussed and the end date is set by the software engineering organization.
 Factors affecting the software-project scheduling:
1. People-work relationships,
2. Task definition and parallelism,
3. Effort distribution, and
4. Scheduling methods.
 During early stages of software project schedule is developed. This type of software project schedule
identifies all major process framework activities.
  Need of Project Scheduling:
 Following points describes need of project scheduling:-
1. Error tracking methods can be used for assessing the status of current performance and to
estimate efforts and duration.
2. Use an incremental process model that will deliver critical function imposed by deadline,
but delay other requested functionality.
3. Meet with the customer and explain why the deadline is unrealistic.
 Project Scheduling Process:
 Following fig. shows process of project scheduling:-

Identify activity Identify Activity Dependencies Estimate Resources

Create Project Charts Allocate People to activities

Fig. Project scheduling process

 The phases in project scheduling are as follows:-

1. Identify activity: Identifying the specific activities that must be performed to produce the various
project deliverables.
2. Identify activity dependencies: Identifying and documenting dependencies among modules.
3. Allocate resources: Resources are allocated and estimating the number of work periods which will
be needed to complete individual activities.
4. Create project charts: Project activity charts are created to analyzing activity sequences, activity
durations, and resource requirements to create the project schedule.
5. Allocate people to activities: According to different activities, people are allocated to those
activities.
5.3.1 Concept of Project Scheduling:-
 Software project scheduling is an activity that distributes estimated effort across the planed project
duration by allocating the effort to specific software engineering tasks.
 The goal of a software project schedule is to determine the duration of the software project and the
phases within the project.
 A software project schedule enables you to distribute the estimated effort to be spent in performing
the critical activities.
 Project scheduling helps to establish a roadmap for project managers together with estimation of risk.
 Project scheduling begins with the identification of process models, software tasks and activities,
estimation of effort and work and ends with creation of network of tasks and making sure it gets done
on time.
5.3.2 Factors that Delay Project Schedule :-
 Various factors which delay project schedule are listed below:
1. Unrealistic deadline is established.
2. Changing customer requirements not reflected in schedule changes.
3. Underestimating the resources required to complete the project.
4. Risks that were not considered when project began.
5. Technical difficulties that not have been predicted in advance.
6. Human difficulties that not have been predicted in advance.
7. Miscommunication among project team members resulting the delays.
8. Failure by project management to develop the proper schedule and failure to take corrective
action to solve problems.
 5.3.3 Principles of Project Scheduling :-
 A number of basic principles that guides the software project scheduling are :
1. Principle #1: Compartmentalization: The software project must be compartmentalized into a
number of activities and tasks.
2. Principle #2: Effort Validation: Each and every project has a defined number of people on
the software team. It must ensure that no more than the allocated number of people should get
allocated the schedule.
3. Principle #3: Interdependency: The interdependency of each and every activity or task must
be determined. Some must occur in sequence, while other tasks can occur in parallel. Some
activities cannot commence until the work product produced by another is available.
4. Principle #4: Defined milestones: Every task should be associated with a project milestone. A
milestone is accomplished when one or more work products has been developed and has
approved.
5. Principle #5: Defined outcomes: Each and every task should have a defined outcome. For
software projects, the outcome is a work product. Work products are combined and delivered
to customers.
6. Principle #6: Defined responsibilities: Each and every task that is scheduled should be
assigned to a specific team member.
5.3.4 Project Scheduling Techniques :-
 Project scheduling methods are as follows:-
1. The Program Evaluation and Review Technique (PERT),
2. The Critical Path Method (CPM),
3. Timeline charts.
 All these methods develop a task network description of a project (i.e. a pictorial or tabular representation of
tasks) that must be accomplished from beginning to end of a project.
 The network is defined by developing a list of all tasks, sometimes called the „Work Breakdown Structure'
(WBS).
 Both PERT and CPM provide quantitative tools that allow the planner to :
1. Determine the critical path - the chain of tasks that determines the duration of the project.
2. Establish the time estimates for individual tasks.
3. Calculate 'boundary times' that define a time "window" for a particular task.

[Link] Gantt Chart :-

 This method was introduced in 1917 by Henry L. Gantt.
 It is the oldest and mostly used for planning, scheduling and control.
 Gantt chart is a graphical representation of project and it is used in project scheduling and project
management.
 There are a few initial requirements fulfilled by the project, i.e.
1. The project should have a sufficiently detailed Work Breakdown Structure (WBS).
2. Secondly, the project should have identified its milestones and deliverables.
 A Gantt chart is a horizontal bar chart that graphically displays the time relationship with the steps
in a project. Each step of a project is represented by a line placed on the chart in the time period.
 Gantt chart shows the flow of activities in sequence and those that can be performed in parallel.
 Gantt charts are more useful in projects in which the flow or sequence of steps is simple.
 [Link] Chart

 Advantages:
1. It provides a visual for the tasks that need to be completed.
2. It helps to maintain organization, and it helps in setting realistic frames.
3. Gantt chart is a simple and very inexpensive method.
4. These charts clearly show the decided time and work schedules for job.
5. Monitoring and control are easier and can be done within a minimum time frame and at the
lowest cost.
6. These charts can be changed and updated quickly at a lower cost.

 Disadvantages:
1. For large projects having many tasks, the Gantt chart may be complex and more difficult to read.
2. A Gantt chart also requires frequent updates.
3. They do not show interrelationships and interdependence among tasks.
4. Cost implications cannot be shown in Gantt chart.
5. The shape and form of Gantt charts can differ according to the nature of software requirement.

[Link] PERT and CPM :-

 PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) techniques are useful for
planning, scheduling and control the project.
 PERT is used to schedule, organize and co-ordinate tasks within the project.
 CPM technique determines those activities which have the least scheduling flexibility.
 PERT and CPM provide quantitative tools that allow the project planner to :
 Determine the critical path.
 Establish time estimates for individual tasks, and
 Calculate boundary times that define a time window for a particular task such as :
o earliest start time,
o Latest start time,
o Earliest finish time,
o Latest finish time, and
o Total float i.e. the amount of surplus time.
 Critical path is the longest path through the network.
 For analysis by PERT and CPM, the project essentially should have the following characteristics
 The project consists of well-defined collection of jobs or activities which when completed,
marks the end of the project.
 The jobs may be started and stopped independently of each other, within a given sequence.
 The jobs are ordered, i.e. they must be performed in a sequence.
 To draw PERT and CPM graph, following are broad steps :
1. Definition of job or activities.
2. Estimate time for each activity,
3. Ordering of activities, and
4. Drawing the project graph or diagram.
  Some benefits using PERT and CPM are :
1. Helps to managers for better plan.
2. Shows interrelationship between tasks and helps in identifying the critical path.
3. Helps in allocating resources.
4. Helps in proper scheduling of different activities.
5. Enables the manager to monitor and control a project.
 Following graph shows the relationship of an activity with initial node and with the terminal node
for that activity.
 A node represents an event.

Event Event
Activity

Initial Node Terminal Node

Fig. Event Relationship
 An example of a PERT is given below by taking a simple example of writing and publishing a
book.

Job ID Job Description Immediate Predecessor Time

A Prepare plan NIL 10
B Prepare material A 5
C Talk with publisher A 4
D Finalize material B 6
E Finalize cover C 9
F Print the book D and E 5

 The PERT chart for the above set of activities is given below:-

 PERT Advantages:
1. Large project planning.
2. Visible critical path.
3. It provides the project in graphical form so it is easy and simple to understand.
4. PERT provides information about the expected completion time of the project.
5. PERT describes the dependencies of one or more tasks on each other.
 PERT Disadvantages:
1. It is very complicated task.
2. Prediction inaccuracies.
  CPM Advantages:
1. Make dependencies visible.
2. Organize large and complex project.
3. Increase visibility of impact of schedule revision Enable the project manager to optimize
efficiency.
4. CPM provides a graphical view of the project.
5. CPM provides the critical activities in the project.
6. CPM provides how to speed up the project so that it is completed on schedule.

[Link] Timeline Charts :-

 A timeline chart is invented by Henry Gantt, industrial engineer, in 1917.
 Following fig. Illustrates the format of a timeline chart.
Work tasks Week 1 Week 2 Week 3 Week 4 Week 5
1. Identify need and benefits
Meet with customer
Identify needs and project constraint
Establish product statement
Milestone: product statement defined

2. Define desired output/control/input(OCI)

Scope keyboard function
Scope voice input function
Scope modes of interaction
Scope document diagnosis
Document OCI
FTR review OCI with customer
Revise OCI as required
Milstone: OCI defined
…

…
  For creating a software project schedule, the planner begins with a set of task.
 Duration and start date are then assigned for each task. Tasks may be assigned to individuals.
 A timeline chart can be developed for the entire project. Alternatively charts can be developed for
each project function or for each individual on the project.
 All project tasks are listed in the left-hand column.
 A horizontal bar indicates duration of each task. When multiple bars occur at the same time it
indicates task concurrency.
 The diamonds indicate milestones.

5.4 CONCEPT OF TASK NETWORK:-

 A task set is a collection of software engineering work tasks, milestones and deliverables (outcomes)
that must be accomplished to complete a project.
 A task network is a graphic representation of the task flow for a project.
 It is the mechanism in which task sequence and dependencies are given as input to an automated
project scheduling tool.
 Individual tasks and subtasks have interdependencies based on their sequence.
 A task network, also called an activity network.
 A task network exactly shows how tasks take place and the sequence of them.
 It depicts task length, sequence, concurrency, and dependency.
 Come activities are performed concurrently so the scheduling is required for such project.
 Following Fig. Describes a schematic task network for development of project.

1.3a [Link] 1.5a Concept

Assement Implement

1.1 Concept 1.2 Concept 1.3b [Link] 1.4 proof of 1.5b Concept 1.1 Concept 1.6 Concept
Scoping planning Assement concept Implement Scoping Reaction

1.3c [Link] 1.5c Concept

Assement Implement

Fig. Task network

 Critical Path :
 In designing a task networks there is a certain difficult path called as critical path.
 A single path leading from start to finish in a task network. It contains the sequence of tasks
that must be completed on schedule.
 It also determines the minimum duration of the project.
 Critical path is the longest path through the network.
5.5 WAYS OF PROJECT TRACKING :-

 Project schedule provides a road map for a software project manager.

 The project schedule defines the tasks and milestones that must be tracked and controlled.
 Methods for Tracking the Schedule:
1. Qualitative approaches :
 Conduct the project status meetings in which each team member reports the progress and
problems.
 Evaluate the results of all reviews conducted throughout the software engineering process.
 Determine whether formal project milestones have been accomplished by the scheduled
date
 Compare actual start date to planned start date for each project listed in the timeline chart.
 Meet informally with the team to check progress.
2. Quantitative approach :-
 The progress of project is assessed quantitatively.

5.6 Risk Management :-

 Risk is an unexpected event or condition that produces an adverse effect during software development
process.
 Risk management is a systematic process, which focuses on identification, control and elimination of
risks, which impacts the project.
 Risk analysis and management are a series of steps that help a software team to understand and
manage risks.
 Everyone involved in the software process - managers, software engineers stakeholders should
participate in risk analysis and management.
 The basic objective of risk management is to determine the loss before risks occur and then determine
ways to prevent or avoid the adverse impact of risks on the project.
 Risk management depends on the number and complexity of risks.
 Definitions of Risk:-
 "A possible future event that, if it occurs, will lead to an undesirable outcome". OR
 "Risk is a combination of an abnormal event or failure to a system's operators, users or
environment.
 Principles of Risk Management:

o Principle #1: Take a forward-looking view: Think about the risks that may arise in
the future.
o Principle #2: Integrate: A consideration of risk must be integrator I the software
process.
o Principle #3: Maintain a global perspective: View software risks within the
context of system in which it is intended to solve.
o Principle #4: Encourage open communication: If someone states a potential risk, do not
ignore it.
o Principle #5 : Emphasize a continuous process : The team must be always being
careful throughout the software process.
o Principle #6: Encourage teamwork: The talents, skills and knowledge of all team
members should be pooled when risk management activities conducted.
 Purpose of Risk Management:
1. Anticipate and identify the risks.
2. Minimize the impact/damage/loss caused by risk.
3. Reduce the probability of risk.
4. Monitor risk areas for early detection.
5. Ensure management awareness of risks.
 A risk may have following adverse effects:-
1. Project risks affect schedule or resources.
2. Product risks affect the quality or performance of the software.
3. Business risks affect the organization that developing the software.
 Risk Management Process :
 Following fig. shows risk management process. Which containing following phases:
1. Risk identification: Identify project, product and business risks.
2. Risk analysis: Assess the risks.
3. Risk planning: Draw up plans to avoid or minimize the effects of the risk.
4. Risk monitoring: Monitor the risks throughout the project.

Risk Risk Analysis Risk Risk

identification Planning Monitoring

List of Prioritized risk Risk avoidance Risk

potential risks list & contingency Assessment
plans
5.6.1 What is Software Risk?

 The risk is defined as "the future harm that may arise due to some present actions".
 The risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on
a project's objectives.
 Software risks can be internal or external. The internal risks come from risk factors within the
organization. The external risks come from out of the organization.
 Objectives of Risk Management:
1. To identify and eliminate risk items before they become threats to successful software
operation or major sources of software.
2. Some form of measurement is undertaken to determine and classify the range of risks.
3. To identify areas where significant risks may exists.
 The software risk management concepts are:-
1. Risk Index:
o Generally, risks are categorized into two factors:-Impact of risk events and
probability of occurrence.
o Risk index is the multiplication of impact and probability of occurrence.
o Risk index can be characterized as high, medium, or low.
o Risk index is very important and necessary for prioritization of risk.
2. Risk Analysis:
o There are quite different types of risk analysis that can be used.
o The risk analysis is used to identify the high risk elements of a project in software
engineering.
o The main purpose of risk analysis is to understand risks in better ways and to verify
and correct the risks.
3. Risk Assessment:
o Risk assessment is another important case that integrates risk management and risk
analysis.
o There are many risk assessment methodologies that focus on different types of risks.
o Risk assessment requires correct explanations of the target system and all security
features.
o The performance, cost, schedule must be defined properly for risk assessment.

5.6.2 Reactive and Proactive Risk Strategies:-

 A reactive strategy monitors the project to identify the risks.

 The software team does not thing about risks until something goes wrong. Then team
takes action to correct the problem rapidly.
 For risk management more intelligent scheme is to be proactive. It begins before
technical work is initiated.
 In the proactive strategy, the risks are identified; their probability and impact are
assessed. Then, the software team establishes a plan managing risk.
 The main objective is to avoid risk, but because not all risks can be avoided, the team
works to develop a plan that will helps to avoid risks.
5.6.3 Software Risk:-
 Software risks involve two main tasks:-uncertainty and another is loss.
 In uncertainty, the risks may or may not happen i.e. there are no 100% probable risks.
 In loss task, the risk becomes reality and causes the loss.
1. Project Risk :
o Project risk affects the project plan.
o If project risk becomes real the project schedule will slip and that costs will increase.
o The project risks identify budgetary, schedule, personnel resources problems.
2. Technical Risks:
o Technical risks threaten the quality and timeliness of the software to be produced.
o When technical risk becomes a reality, implementation may become difficult or impossible.
o Technical risks identify design, implementation, interface, verification and maintenance
problems.
o A technical risk generally leads to failure of functionality and performance.
o Causes of technical risks are:
i. Continuous changing requirements.
ii. No advanced technology available.
iii. Product is complex to implement.
iv. Difficult project modules integration.
3. Business Risks :
1. Build an excellent product.
2. Building a product that no longer files into business strategy for the company.
3. Losing the support of senior management due to a change in focus or a change in
people.
4. Losing budgetary or personnel commitment.
4. Schedule Risks:-
o This risk affects on economy, and causes the project failure.
5. Operational Risks:
o Risks of loss due to improper implementation, failed system or some external events risks.
o Causes of Operational risks:
i. Failure to identify priority conflicts.
ii. Failure to resolve the responsibilities.
iii. Insufficient resources.
iv. No proper subject training.
v. No resource planning.
vi. No communication in team.
6. Programmatic Risks:
o These risks are outside the control of the program. These external events can be:
i. Running out of fund.
ii. Market development.
iii. Changing customer product strategy and priority.
iv. Government rule changes.
 Another general categorization of risks has been proposed by Chavette are :-
1. Predictable risk:
o These risks can be predicted from past projects experience such as poor communication
with the customer, staff turnover etc.
2. Unpredictable risk :
o They can do occur but they are extremely difficult to identify in advance.
 3. Known risks:
o These risks are those that can be uncovered after careful evaluation of the project plan, the
technical and business environment in which the software project being developed and
other reliable information sources such as unrealistic delivery date, lack of document
requirement etc.

5.7 RISK CONTROL:-

 Risk control concentrate on the management of risks in order to minimize their effect, so risk control
determines techniques and strategies to minimize the effect of the risks.
5.7.1 Need:-
o following points describe the need of risk control :
1. For risk-management planning: Doing the work to address each risk item.
2. For risk resolution: Producing a situation in which risk items are eliminated or
resolved.
3. For risk monitoring: Tracking the projects progress towards resolving risk items and
taking corrective action where required.
4. For risk mitigation: It is used for minimizes the impact of risks.
5.7.2 Risk Mitigation, Monitoring and Management (RMMM) :-
o An effective strategy consist of three issues :
1. Risk management and Contingency planning.
2. Risk monitoring.
3. Risk avoidance.
o If a software team adopts a proactive approach to risk, avoidance is always the best
strategy. This is achieved by developing a plan for risk mitigation.
o To mitigate this risk, possible steps are given below :
 Organize project teams so that information about each development activity is
widely dispersed.
 Conduct reviews of all work.
 Assign a backup staff member for every critical technologist.
 Define documentation standards and establish mechanisms to ensure that
documents are developed in a timely manner.
 Meet with current staff to determine causes for turnover.
 Once, the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave.
 Mitigate those causes that are under our control before the project starts.

o In the case of high staff turnover, the following factors can be monitored:-
i. General al attitude of team members based on project pressure.
ii. Potential problems with compensation and benefits.
iii. Interpersonal relationships among team members.
iv. The availability of jobs within the company and outside it.
v. The degree to which the team has jelled.

o To monitoring these factors, a project manager should monitor the effectiveness of risk
mitigation steps.
 RMMM Plan:
o A risk management strategy can be included in software project plan can be included into a
separate Risk Mitigation, Monitoring and Management (RMMM).
o This RMMM plan documents all work performed and is used by the project manager as
part of the overall project plan.
o Once, RMMM has been documented the risk monitoring and mitigation steps commence.
o Risk mitigation is a problem avoidance activity while risk monitoring is a project tracking
activity with following objectives :
i. To ensure that risk avoidance steps are defined for the risk.
ii. To collect information that can be used for future risk analysis.
iii. To access whether predicted risks occur or not.

Risk Refinement:
o As the time passes and more is learned about the project and the risk, it may be possible
to refine the risk into a set of more detailed risks which will easier to mitigate, monitor
and manage.
o One way to do this is to represent the risk in condition-transition-consequence format.
That is, the risk is stated in the following form.
o Given that <condition> then there is concern that <consequence>.
o This general condition can be refined in the following manner :
 Subcondition 1: Certain reusable components were developed with no knowledge
of internal design standards.
 Subcondition 2: The design standard for component interfaces may not according
to existing reusable components.
 Subcondition 3: Certain reusable components have been implemented in a language
that is not supported on the target environment.

5.8 SOFTWARE CONFIGURATION MANAGEMENT (SCM) :-

 Changes during all phases of software development arise when user requirements are not understood
properly.
 Some other reasons for changes are :
1. New user requirements may demand modifications of data or functions used in the
software.
2. Cost and time constraints may require the product definition to be redefined.
3. The growth in market or business may change the project priorities.
 SCM is a set of activity that is applied throughout the software engineering process.
 Software Configuration Management (SCM) is a software engineering discipline consisting of
standard processes and techniques used by organizations to manage the changes introduced to its
software products.
 SCM is also known as software control management. SCM aims to control changes introduced to
large complex software systems.
 This management covers the different activities, which are developed to :
1. Identify change,
2. Control change,
3. Ensure that change is being properly implemented and
4. Report change to others, who may have an interest.
 Maintenance is a set of software engineering activities that occur after software has been
delivered to the customer and put into operation, whereas SCM is a set of activities that begin
when software project begins and terminate only when the software is taken out of operation.
 Roger Pressman says that SCM is a "set of activities designed to control change by identifying
the work products that are likely to change, establishing relationships among them, controlling
the changes imposed, and auditing and reporting the changes made."
 The following are few perceptions of several people about SCM in the form of definitions.
1. SCM is the art of identifying, organizing and controlling, modification to the software being
built by programming team. The goal of it is to maximize productivity by minimizing
mistakes.
2. SCM is the process concerned with the development of procedures and standard tor managing
a software system product.
3. SCM is the ability to control and manage change in a software project.
4. SCM is a set of procedure to identify, control the various work products of software project.
5. In the simplest sense, SCM is the process of controlling baseline software document and
code.

5.8.1. Need of SCM :-

 IEEE defines SCM as "the process of identifying and defining components in a system,
controlling the change throughout the life cycle, recording and reporting the status completeness
and correctness of system components".
 Software Configuration Management (SCM) encompasses the disciplines and techniques of
initiating, evaluating the controlling change to software products during and after the software
engineering process.
 Software project managers pay attention to the planning and execution of configuration
management, because it facilitates the ability to communicate status of documents and code as
well as changes that have been made to them.
  High-quality released software has been tested and used, and making it a reusable to save
development costs.
 The problems of Software project are:
1. Multiple people have to work on software that is changing.
2. More than one version of the software has to be supported;
 Released systems.
 Custom configured systems (different functionality).
 Systems under development.
3. Software must run on different machines and operating systems.
4. Need for co-ordination.
 Software configuration management do the following:
1. Manages evolving software systems.
2. Controls the costs involved in making changes to a system.

5.8.2. Benefits of SCM :-

 SCM benefits an organization in four areas control, management, cost saving and quality.
 These four benefits help to an organization to achieve overall goals when the decisions are made
to use SCM tool in-house.

Control

Management
Quality

Cost saving

 Benefits of SCM are:

1. Reduced redundant work.
2. Effective management of simultaneous updates.
3. Avoids configuration-related problems.
4. Facilitates team coordination.
5. It ensures that every defect has been removed.
 SCM Scenario:-
o A typical CM (Change Management) scenario involves a project manager who is in-charge of
a software group, a configuration manager who is in-charge of the SCM procedures and
policies, the software engineers who are responsible for developing and maintaining the
software product and the customer who uses the product.
 1. The goals of the configuration manager are to ensure that procedures and policies for
creating, changing and testing of code are followed. To implement techniques for maintaining
control over code changes, the manager introduces mechanisms for making official requests
for changes, for evaluating them and for authorizing changes.
2. For the software engineers, the goal is to work effectively. This means engineers do not
unnecessarily interfere with each other in the creation and testing of code and in the
production of documents. But, at the same time, they try to communicate and coordinate
efficiently.
3. For the project manager, the goal is to ensure that the product is developed within a certain
time frame.
4. The engineers have their own workspace for creating, changing, testing integrating code.
5. The customer uses the product. Since, the product is under SCM control, the customer
follows formal procedures for requesting changes.

 Elements of a Configuration Management System :

1. Construction elements: A set of tools that automate the construction of software by
ensuring that the proper set of validated components has been assembled.
2. Human elements: To implement effective SCM, the software team uses a set of tools and
process features.
3. Component elements: A set of tools coupled within a file management system that enables
access to and management of each software configuration item.
4. Process elements: A collection of procedures and tasks that define an effective approach to
change management for all elements involved in the management, engineering and use of
computer software.
 Goals of SCM :
1. SCM activities are planned.
2. Selected software work products are identified, controlled and available.
3. Changes to identified software work product are controlled.
4. Affected groups and individuals are informed of the status and software baselines.
 Baselines :
o The IEEE standard defines a baseline as :
o "A specification that has been formally reviewed and agreed after that it serves as
the basis for further development and that can be changed only through formal
change control procedures".
o In the content of software engineering, a baseline is a milestone in the development of
the software that is marked by the delivery of one or more software configuration
items, i.e. "SCI", and the approval of this SCI.
o Software engineering tasks produce one or more SCI‟s. After SCI‟s are reviewed and
approved, they are placed in a project database (also known as Software Repository or
Project library).
o The most common software baselines are as follows:-
o
 System Engg.

Requirement
Analysis
System
specification Design

S/W Coding
Requirement
specificationa Design Testing
nalysis specification
Source code Maintenance

Test
plans/procedures/
data Operational
system

Fig.S/W baselines

 Software configuration Items:-

o Software configuration item is documented information that is created as part of the software
engineering process.
o different documents are :
1. System specification
2. Software project plan
3. Software requirements specification :
i. Graphical analysis models,
ii. Process specifications,
iii. Prototype, and
iv. Mathematical specifications.
4. Preliminary user manual
5. Design specification :
i. Data model description
ii. Schema model description
iii. Modules description
iv. Interface design descriptions
v. Object descriptions (under object-oriented design approach).
6. Source code listing
7. Test specification :
i) Test plan and Procedure
ii) Test cases and Observed results
8. Operation manual and Installation guide.
9. Executable program
10. Database details
11. Maintenance documents
12. Standards and Procedures for software engineering.
5.8.3. SCM Repository :-

 In the early days of software engineering, software configuration items were maintained as paper
documents placed in file folders or stored in metal cabinets.
 This approach was problematic for many reasons:
1. Finding a configuration item from file folders was very difficult.
2. It was very difficult to determining which items were changed, when and by whom.
3. Constructing a new version of an existing program was time consuming and error prone.
4. Describing the relationship between configuration items was impossible.
 Today SCI's are maintained in a project database or repository.
 A repository is defined as "anything or person thought as a center of accumulation of storage
during the early history of Software engineering.
 The repository was indeed a person - the programmer who had to remember the location of all
information relevant to the software project, who had to recall information when required and
reconstruct information that has been lost. Sadly, using a person as a center for accumulation and
storage is not work very well.
 Today, the repository is a database that acts as a center for both repository and storage of SE
(Software Engineering) information. The role of person is to interact with the repository using
tools that are integrated with it.

 Role of Repository:
o The SCM repository is a set of mechanism and data structures that allow software team to
manage change in an effective manner.
o It provides same functions like a DBMS, but in addition, the repository performs the
following functions :
1. Data Integrity: Integrity includes function to validate entries to repository, ensure
consistency among related objects and automatically perform modification when a
change to one object demands changes to objects related to it.
2. Information Sharing: Provides a mechanism for sharing information among multiple
developers and between multiple tools, manages and controls multi user access to data.
3. Tool Integration: Establishes a data model that can be accessed by many SE (Software
Engineering) tools, controls access to data and performs appropriate configuration
management functions.
4. Data Integration: Provides database functions that allow various SCM tasks to be
performed on one or more SCI's.
5. Methodology Enforcement: Define an ER model stored in the repository that implies
a specific process model for SE (Software Engineering) at a minimum. The
relationships and objects define a set of steps that must be conducted to build the
contents of repository.
6. Document Standardization: It is the definition of the objects in the database that leads
directly to a standard approach for creation of a SE (Software Engineering) document.
  General Features and Contents:
o The features and contents of the repository are best understood by looking it at two
perspectives. What is to be stored in the repository and what specific services are provided
by the repository.
o A robust repository provides two different classes of services :
1. The same types of services that might be provided by any DBMS.
2. Services those are specific to the SE (Software Engineering) environment.
o A repository that serves a SE (Software Engineering) team should :
i. Integrate with process management functions.
ii. Support specific rules that govern the SCM functions and the data maintained
within the repository.
iii. Provide an interface to other SE tools.
iv. Accommodate storage of data object.
5.8.4. SCM Features :-
 To support SCM, the repository must have a tool set that provides support for the following
features :
1. Versioning :
o As the project progresses, mini versions of individual work products will be created. The
repository must be able to save all of these versions to enable effective managements of
product releases and to permit developers to go back to previous versions during testing
and debugging.

o The repository must be able to control a wide variety of object types, including text,
graphics, bitmaps, complex documents and unique objects like screens and report
definitions, object files, test data and results.

2. Dependency tracking and Change management:

o The repository manages a wide variety of relationships among the objects stored in it.
These include relationships among the parts of an application design, between design
components and the information architecture, between design elements and other work
products and so on.

o Some of these relationships are associations and some are dependencies or some are
mandatory relationships.

3. Requirements tracing :
o This special function provides the ability to track all the design and construction
components and deliverables that result from a specific requirement specification.

o It provides the ability to identify which requirement should be satisfied by any given work
product.

4. Configuration management:
o This facility keeps track of a series of configurations (changes) representing project
milestones or product releases.
 5. Audit trials :
o It provides additional information about when, why and by whom changes are made.
o Information about the source of changes can be entered as attributes of specific objects in
the repository.
5.8.5. SCM Process :-
o The major objective of SCM is to determine or identify the items that collectively manage
changes in one or more items.

o SCM should also help in developing various versions of software and maintain the quality of
the software.

o To achieve these responsibilities, the SCM process is used.

o This SCM process addresses some critical issues related to the software configuration
management, which are listed below:

1. Identifying discrete elements of software configuration.

2. Controlling changes in the software before and after its release.
3. Ensuring that the changes are according to requirements.
4. Managing the existing versions of software to accommodate changes efficiently.
5. Specify responsibility to approve changes.
o Following fig shows SCM process :-

Configuration status reporting

Configuration auditing

Version control
Change control
Software Vm.n
Configuration Identification

SCI’s

o SCM process includes following five tasks as shown in Fig.

i. Identification,
ii. Version control,
iii. Change control,
iv. Configuration auditing, and
v. Status accounting.
i) Identification:
o To control and manage software configuration items, each must be separately named and
defined. Two types of objects can be identified:
1. Basic objects :
 It is a part of text that has been created by a software engineer during analysis, design,
coding or testing. For example: A part of requirement specification, and a source listing
for a module etc.
2. Aggregate objects :
 It is a collection of basic objects and other aggregate objects. For example: design
specification, (basic objects are data and function module).
ii) Version Control:
o Version control combines procedures and tools to manage different versions of
configuration objects that are created during the software engineering process.
o It is a process of maintaining and tracking versions of the project. This includes
identification and managing configuration items, which change over time.
o Version control is essential because without this, it becomes difficult to maintain a record
of changes, version number, and its link with other configured items.
o Benefits:
a. Helping in creating branches that allow parallel concurrent development.
b. Allowing more than one developer to work on the code.
c. Comparing two versions of a file and highlighting the differences.
d. Maintaining an instant audit trail on each and every file.
e. Providing the ability to roll back to the previous version of a file in case of any
failure occurs in the new version.
o When the changes are made, a new version of configuration items is created. The new version
does not replace the older version of SCI.
o Instead, the record of different versions of SCI is maintained that helps in providing the details
of the latest as well as previous versions.
o A delta (difference between previous and newer version) is created for these configuration
items rather than storing them in the project library.
o Two types of deltas are used to store the versions of the configuration item.

Latest
Version

Deltas

Original
Version

Forward Delta Reverse Delta

 o Types of Deltas:-
1. Forward delta maintains the entire copy of the original file. When a newer version is
developed, the two versions are compared and a delta report is produced. This delta
reports is stored instead of storing the newer version.
2. Reverse delta specifies the most recent version of the file. This newer version is
evaluated, compared with the earlier version and a delta is developed. The older
version of the module is deleted, and the newer version is stored.

iii) Configuration auditing:

o A software configuration audit complements the formal technical review by assessing a
configuration object for characteristics that are generally not considered during technical
review.
o The technical review focuses only on the correctness of the configuration object that has been
modified.
iv) Status accounting (or configuration status reporting) :-
o It is an SCM task that answers the following questions:-
1. What happened?
2. Who did it?
3. When did it happen?
4. What else will be affected?
o Status reporting plays a vital role in the success of a large software development project.

v) Change Control:
o Change control combines human procedures and automated tools to provide a mechanism
for the control of change.
o Although many change requests are submitted during the software maintenance phase,
request for change can occur at any time during the software process.
o Change control ensures that the intermediate product is changed according to the required
changes. Various software configuration tools are used to manage change so that they a
done in a controlled manner.
o The entire change process is shown as follows :-
 Need for change is recognized

Change request from user

Developer evaluates

Change report is generated

Change control authority decides

Request is queued for action Change request is denied

Assign people to SCI

User is informed

Checkout SCI‟s

Make the change

Review audit the change

Establish a baseline for testing

Perform SQA & testing activities

Check in the changed SCI‟s

Promote SCI for inclusion in next release

Rebuild appropriate version

Review /Audit the change

Include all changes in release

Distribute the new version

[Link] Process

----------------------------------------------END of chapter--------------------------------------------------------------