Software Engineering

[ECEg-4204 ]

Chapter One:
Software Engineering Overview
2016 E.C

Compiled by Amanuel Z.
Outline

Frequently asked questions(FAQs) about software engineering

Professional and ethical responsibility

2
 1.1 FAQs about software engineering
 What is software?
 What is software engineering?
 What is the difference between software engineering and computer
science?
 What is the difference between software engineering and system
engineering?
 What is a software process?
 What is a software process model?

3
 Cont’d...
 What are the costs of software engineering?
 What are software engineering methods?
 What is CASE (Computer-Aided Software Engineering)
 What are the attributes of good software?
 What are the key challenges facing software engineering?

4
 What is software?
 Software is a set of items or objects that form a “configuration” that
includes
➔
Programs
➔
Documents
➔
Data

5
 Cont’d...
Or you may want to say:
 Software consists of
➔
Instructions (computer programs)
✔
that when executed provided desired features, function, and
performance,
➔
Data structures
✔
that enable the programs to adequately manipulate information
➔
Documents
✔
that describe the operation and use of the programs.
6
 Cont’d...
 There are two fundamental types of software product:
➔
Generic product
✔
Developed to be sold to a range of different customers
✔
Examples PC software such as databases, word processors, drawing
packages and project management tools.
➔
Customised (or bespoke) products
✔ Developed for a single customer according to their specification.
✔ Examples of this type of software include control systems for
electronic devices and air traffic control systems.
7
 What is software engineering?
 Software engineering is an engineering discipline that is concerned with
all aspects of software production.
 Software engineers should adopt a systematic and organised approach to
their work and use appropriate tools and techniques depending on the
problem to be solved, the development constraints and the resources
available.

8
 What is the difference between software engineering
and computer science?

Computer science is concerned with the theories and methods that
underlie computers and software systems, whereas

Software engineering is concerned with the practical problems of
producing software.

Some knowledge of computer science is essential for software engineers in
the same way that some knowledge of physics is essential for electrical
engineers.

9
 What is the difference between software engineering
and system engineering?
 System engineering is concerned with all aspects of computer-based
systems development including hardware, software and process
engineering.
 Software engineering is part of this process concerned with developing
the software infrastructure, control, applications and databases in the
system.
 System engineers are involved in system specification, architectural
design, integration and deployment.

10
 What is a software process?
 A set of activities whose goal is the development or evolution of software.
 There are four fundamental process activities that are common to all
software processes. These are:
➔
Software specification - where customers and engineers define the software
to be produced and the constraints on its operation.
➔
Development - where the software is designed and programmed.
➔
Validation - where the software is checked to ensure that it is what the
customer requires.
➔
Evolution - where the software is modified to adapt it to changing customer
and market requirements.
11
 What is a software process model?
 A simplified representation of a software process, presented from a specific
perspective.
 Examples of process perspectives are
➔
Workflow perspective - sequence of activities;
➔
Data-flow perspective - information flow;
➔
Role/action perspective - who does what.
 Generic process models
➔
Waterfall;
➔
Iterative development;
➔
Component-based software engineering. 12
 What are the costs of software engineering?
 Roughly 60% of costs are development costs, 40% are testing costs.
➔
For custom software, evolution costs often exceed development costs.
 Costs vary depending on
➔
the type of system being developed and
➔
the requirements of system attributes such as
✔ performance and
✔ system reliability.
 Distribution of costs depends on the development model that is used.

13
 Cont’d...
Activity cost distribution

Figure 1.1 Software engineering activity cost distribution 14

 Cont’d...
Activity cost distribution

Figure 1.1 Software engineering activity cost distribution 15

 Cont’d...
Product development costs

16
 What are software engineering methods?
 Structured approaches to software development.
➔ Aim is to facilitate the production of high-quality software in a cost-
effective way.
 Methods such as Structured Analysis, JSD, and object-oriented (OO)
 These different approaches have now been integrated into a single unified
approach built around the Unified Modeling Language (UML)
 There is no ideal method
 All methods are based on the idea of developing models of a system that
may be represented graphically and using these models as a system
specification or design.
17
 Cont’d...
Methods include a number of different components:
 System model descriptions
➔ Descriptions of the system models which should be developed and the

notation used to define these models.

Example
✔ Object models, data-flow models, state machine models, etc.
 Rules
➔
Constraints which always apply to system models.
Example:
✔
Every entity in a system model must have a unique name.
18
 Cont’d...

Recommendations
➔
Heuristics which characterise good design practice in this method.
Following these recommendations should lead to a well-organised system
model.
Example
✔
No object should have more than seven sub-objects associated with it.

Process guidance
➔
Descriptions of the activities which may be followed to develop the system
models and the organisation of these activities.
Example
✔
Object attributes should be documented before defining the operations
associated with an object.
19
 What is CASE (Computer-Aided Software
Engineering)
 Software systems that are intended to provide automated support for
software process activities.
 CASE systems are often used for method support.
 Upper-CASE
➔
Tools to support the early process activities of requirements and design;
 Lower-CASE
➔
Tools to support later activities such as programming, debugging and
testing.
20
 What are the attributes of good software?
As well as the services that it provides, software products have a number of
other associated attributes that reflect the quality of that software.
 Maintainability
➔
Software must evolve to meet changing needs;
 Dependability
➔
Software must be trustworthy;

21
 Cont’d...
 Efficiency
➔
Software should not make wasteful use of system resources;
 Usability
➔ Software must be usable, without undue effort, by the type of user for
whom it is designed.
➔ This means that it should have an appropriate user interface and
adequate documentation.

22
 What are the key challenges facing software engineering?
Software engineering in the 21st century faces three key challenges:
 Heterogeneity
➔
Developing techniques for building software that can cope with
heterogeneous platforms and execution environments;
 Delivery
➔
Developing techniques that lead to faster delivery of software;
 Trust
➔
Developing techniques that demonstrate that software can be trusted by
its users.

23
 1.2 Professional and ethical responsibility
 Software engineering involves wider responsibilities than simply the
application of technical skills.
 Software engineers must also behave in an ethical and morally
responsible way if they are to be respected as professionals.
 Ethical behaviour is more than simply upholding the law.

24
 Cont’d...
Issues of professional responsibility
 Confidentiality
➔
Engineers should normally respect the confidentiality of their employers
or clients irrespective of whether or not a formal confidentiality
agreement has been signed.
 Competence
➔
Engineers should not misrepresent their level of competence.
➔
They should not knowingly accept work which is outwith their
competence.

25
 Cont’d...
Issues of professional responsibility
 Intellectual property rights
➔
Engineers should be aware of local laws governing the use of intellectual
property such as patents, copyright, etc.
➔
They should be careful to ensure that the intellectual property of employers
and clients is protected.
 Computer misuse
➔
Software engineers should not use their technical skills to misuse other
people’s computers.
➔
Computer misuse ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious (dissemination of viruses).
26
 ACM/IEEE Code of Ethics
 The professional societies in the US have cooperated to produce a code of
ethical practice.
 Members of these organisations sign up to the code of practice when they
join.
 The Code contains eight Principles related to the behaviour of and
decisions made by professional software engineers, including
practitioners, educators, managers, supervisors and policy makers, as well
as trainees and students of the profession.

https://ethics.acm.org/code-of-ethics/software-engineering-code/
27
 Cont’d...

Code of ethics - principles

 Public
➔
Software engineers shall act consistently with the public interest.
 Client and employer
➔
Software engineers shall act in a manner that is in the best interests of
their client and employer consistent with the public interest.
 Product
➔
Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
28
 Cont’d...
Code of ethics - principles
 Judgment
➔
Software engineers shall maintain integrity and independence in their
professional judgment.
 Management
➔ Software engineering managers and leaders shall subscribe to and promote an
ethical approach to the management of software development and
maintenance.
 Profession
➔ Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
29
 Cont’d...
Code of ethics - principles
 Colleagues
➔
Software engineers shall be fair to and supportive of their colleagues.
 Self
➔
Software engineers shall participate in lifelong learning regarding the
practice of their profession and shall promote an ethical approach to the
practice of the profession.

30
Thank You !

31
 Software Engineering
[ECEg-4155 ]

Chapter Two:
Software Project Management
2016 E.C

Compiled by Amanuel Z.
Outline

Introduction to software project management

Management activities

Project planning

Project scheduling

Risk management

2
 2.1 Introduction to Software Project Management

Software project management is an essential part of software
engineering.

Projects need to be managed because professional software engineering is
always subject to organizational budget and schedule constraints.

The project manager’s job is to ensure that the software project meets
and overcomes these constraints as well as delivering high-quality
software.

Good management cannot guarantee project success.

Bad management usually results in project failure:
➔
The software may be delivered late, cost more than originally estimated, or
fail to meet the expectations of customers.
3
 Cont’d...
 The success criteria for project management obviously vary from project to
project, but, for most projects, important goals are:
➔
to deliver the software to the customer at the agreed time;
➔
to keep overall costs within budget;
➔
to deliver software that meets the customer’s expectations;
➔
to maintain a coherent and well-functioning development team.

4
 Cont’d...

Software management distinctions

 The product is intangible.
 Large software projects are often “one-off” projects
 Software processes are variable and organization-specific

5
 Cont’d...
The 4 P’s
 People — the most important element of a successful project
 Product — the software to be built
 Process — the set of framework activities and software engineering tasks
to get the job done
 Project — all work required to make the product a reality

6
 2.1.1 People
2.1.1.1 Stakeholders
 Senior managers who define the business issues that often have significant
influence on the project.
 Project (technical) managers who must plan, motivate, organize, and control
the practitioners who do software work.
 Practitioners who deliver the technical skills that are necessary to engineer a
product or application.
 Customers who specify the requirements for the software to be engineered and
other stakeholders who have a peripheral interest in the outcome.
 End-users who interact with the software once it is released for production use.
7
 Team Leader
 Competent practitioners often make poor team leaders.
➔
They simply don’t have the right mix of people skills.
 The MOI Model of leadership:
➔
Motivation The ability to encourage (by “push or pull”) technical people to produce
to their best ability.
➔
Organization The ability to mold existing processes (or invent new ones) that will
enable the initial concept to be translated into a final product.
➔
Ideas or innovation The ability to encourage people to create and feel creative even
when they must work within bounds established for a particular software product or
application.

8
 Cont’d...
 Successful project leaders apply a problem-solving management style.
 Project manager should concentrate on
➔
understanding the problem to be solved,
➔
managing the flow of ideas, and
➔
at the same time,
✔
letting everyone on the team know (by words and, far more important,
by actions) that quality counts and that it will not be compromised.

9
 Cont’d...
 Another view of the characteristics that define an effective project manager
emphasizes four key traits:
➔
Problem solving
➔
Managerial identity
➔
Achievement
➔
Influence and team building

10
 Cont’d...
Problem solving
 An effective software project manager can diagnose the technical and
organizational issues that are most relevant,
➔
Systematically structure a solution or
✔
properly motivate other practitioners to develop the solution,
➔
Apply lessons learned from past projects to new situations, and
➔
Remain flexible enough to change direction if initial attempts at problem
solution are fruitless.

11
 Cont’d...
Managerial identity
 A good project manager must take charge of the project.
 Manager must have the confidence to assume control when necessary and
the assurance to allow good technical people to follow their instincts.

Achievement
 A competent manager must reward initiative and accomplishment to
optimize the productivity of a project team.
 Manager must demonstrate through his own actions that controlled risk
taking will not be punished.

12
 Cont’d...
Influence and team building
 An effective project manager must be able to “read” people;
➔
he/she must be able to understand verbal and nonverbal signals and react
to the needs of the people sending these signals.
 The manager must remain under control in high-stress situations.

13
 Cont’d...

Software Teams
How to lead?

How to collaborate? How to organize?

How to motivate? How to create good ideas?

Figure 2.1 14
 Cont’d...
The following factors must be considered when selecting a software project
team structure
 Difficulty of the problem to be solved (qualifications)
 Size of the resultant program(s) in lines of code or function points
 Time that the team will stay together (team lifetime)
 Degree to which the problem can be modularized
 Required quality and reliability of the system to be built
 Rigidity of the delivery date
 Degree of sociability (communication) required for the project
15
 Cont’d...
Organizational Paradigms for software engineering teams:
1. Closed paradigm
2. Random paradigm
3. Open paradigm
4. Synchronous paradigm

16
 Cont’d...
Closed paradigm
 Structures a team along a traditional hierarchy of authority.
 Such teams can work well when producing software that is quite similar to
past efforts.
 Less likely to be innovative when working within the closed paradigm.
Random paradigm
 Structures a team loosely and depends on individual initiative of the team
members.
 When innovation or technological breakthrough is required, teams following
the random paradigm will excel.
 It struggles when “orderly performance” is required. 17
 Cont’d...
Open paradigm
 Structure a team in a manner that achieves some of the controls associated with
the closed paradigm but also much of the innovation that occurs when using the
random paradigm.
 Work is performed collaboratively, with heavy communication and consensus-
based decision making the trademarks of open paradigm teams.
 Open paradigm team structures are well suited to the solution of complex
problems but may not perform as efficiently as other teams.
Synchronous paradigm
 Relies on the natural categorization of a problem and organizes team members to
work on pieces of the problem with little active communication among
themselves. 18
 Cont’d...
Avoid Team “Toxicity”

A frenzied work atmosphere,

High frustration that causes friction among team members,

A “fragmented or poorly coordinated” software process,

An unclear definition of roles on the software team, and

Continuous and repeated exposure to failure.

19
 Agile Teams
 Team members must have trust in one another.
 The distribution of skills must be appropriate to the problem.
 Mavericks may have to be excluded from the team, if team cohesiveness is
to be maintained.
 Team is “self-organizing”
➔
An adaptive team structure
➔
Uses elements of Constantine’s random, open, and synchronous
paradigms
➔
Significant autonomy

20
 Team Coordination & Communication Issues
 Characteristics of modern software
➔
scale,
Software projects get into trouble.
➔
uncertainty, and
➔
interoperability
 To deal with them effectively
➔
Must establish effective methods for coordinating the people who do the
work.
➔
Mechanisms for formal and informal communication among team
members and between multiple teams must be established.
21
 Cont’d...
 Formal communication is accomplished through
➔
writing,
➔
structured meetings, and
➔
other relatively non-interactive and impersonal communication
channels.
 Informal communication is more personal.
➔
Members of a software team share ideas on
✔
an ad hoc basis,
✔
ask for help as problems arise, and
✔
interact with one another on a daily basis
22
 2.1.2 The Product
 A software project manager is confronted with a dilemma at the very
beginning of a software project.
 Quantitative estimates and an organized plan are required, but solid
information is unavailable.
➔
A detailed analysis of software requirements would provide necessary
information for estimates
 Must examine the product and the problem it is intended to solve at the
very beginning of the project.
➔
At a minimum, the scope of the product must be established and
bounded.
23
 Software Scope
 The first software project management activity is the determination of
software scope.
 Scope is defined by answering the following questions:
➔
Context
➔
Information objectives
➔
Function and performance.

24
 Cont’d...

Scope is defined by answering the following questions:

Context
 How does the software to be built fit into
➔
a larger system,
➔
product,
➔
or business context, and
 What constraints are imposed as a result of the context?

25
 Cont’d...
Scope is defined by answering the following questions:

Information objectives
 What customer-visible data objects are produced as output from the software?
 What data objects are required for input?

Function and performance.

 What function does the software perform to transform input data into output?
 Are any special performance characteristics to be addressed?

26
 Cont’d...
 Software project scope must be unambiguous and understandable at the
management and technical levels.
 A statement of software scope must be bounded.
➔
That is, quantitative data (e.g., number of simultaneous users, size of
mailing list, maximum allowable response time) are stated explicitly,
➔
Constraints and/or limitations (e.g., product cost restricts memory size)
are noted, and
➔
mitigating factors (e.g., desired algorithms are well understood and
available in Java) are described.

27
 Problem Decomposition
 Sometimes called partitioning or problem elaboration
 Decomposition is applied in two major areas:
1. The functionality and content (information) that must be delivered and
2. The process that will be used to deliver it.
 Both cost and schedule estimates are functionally oriented, some degree of
decomposition is often useful.
 Major content or data objects are decomposed into their constituent parts,
providing a reasonable understanding of the information to be produced by the
software.
 Decomposition process continues until all functions or problem classes have
been defined 28
 2.1.3 The Process
 The framework activities that characterize the software process are
applicable to all software projects.
 The problem is to select the process model that is appropriate for the
software to be engineered by your project team.
 Process model is most appropriate for the customers, people
(programmers), product, and the project environment.
 Then defines a preliminary project plan based on the set of process
framework activities.
 Process decomposition begins.
➔
The work tasks required to populate the framework activities must be
created.
29
 Melding the Product and the Process
 Project planning begins with the melding of the product and the process.
 Each function to be engineered, pass through the set of framework
activities.

Figure 2.2 Melding the product

and the Process 30
 Process Decomposition
 Process decomposition begins when the project manager tries to
determine how to accomplish each activity.
 A small, relatively simple project might require the following work tasks
for the communication activity:
1. Develop list of clarification issues.
2. Meet the customer to address clarification issues.
3. Jointly develop a statement of scope.
4. Review the statement of scope with all concerned.
5. Modify the statement of scope as required.

31
 Cont’d...

A more complex project, which has a broader scope and more
significant business impact.

Such a project might require the following work tasks for the
communication:
1. Review the customer request.
2. Plan and schedule a formal, facilitated meeting with all stakeholders.
3. Conduct research to specify the proposed solution and existing
approaches.
4. Prepare a “working document” and an agenda for the formal meeting.
5. Conduct the meeting.
32
 Cont’d...

6. Jointly develop mini-specs that reflect data, function, and behavioral

features of the software. Alternatively, develop use cases that describe the
software from the user’s point of view.
7. Review each mini-spec or use case for correctness, consistency, and lack
of ambiguity.
8. Assemble the mini-specs into a scoping document.
9. Review the scoping document or collection of use cases with all
concerned.
10.Modify the scoping document or use cases as required.
33
 2.1.4 Project
Projects get into trouble when …
 Software people don’t understand their customer’s needs.
 The product scope is poorly defined.
 Changes are managed poorly. How does a manager act to avoid
the problems just noted?
 The chosen technology changes.
 Business needs change [or are ill-defined].
 Deadlines are unrealistic.
 Users are resistant.
 Sponsorship is lost [or was never properly obtained].
 The project team lacks people with appropriate skills.
 Managers [and practitioners] avoid best practices and lessons learned.
34
 Cont’d...
A five - part common sense approach to software projects:
1. Start on the right foot 4. Make smart decisions
2. Maintain momentum 5. Conduct a postmortem analysis
3. Track progress

Start on the right foot

 This is accomplished by working hard (very hard) to understand the
problem that is to be solved and then setting realistic objectives and
expectations.
 It is reinforced by building the right team and giving the team the
autonomy, authority, and technology needed to do the job.

35
 Cont’d...
Maintain momentum
 Many projects get off to a good start and then slowly disintegrate. To
maintain momentum,
➔ The project manager must provide incentives to keep turnover of
personnel to an absolute minimum,
 The team should emphasize quality in every task it performs, and
 Senior management should do everything possible to stay out of the team’s
way.

36
 Cont’d...
Track progress
 For a software project, progress is
➔
Tracked as work products are produced and
Example models, source code, sets of test cases
➔
Approved as part of a quality assurance activity.
✔
using formal technical reviews

37
 Cont’d...
Make smart decisions
 The decisions of the project manager and the software team should be to
“keep it simple.”
 Whenever possible, decide to
➔
use commercial off-the-shelf software or existing software components
or patterns,
➔
avoid custom interfaces when standard approaches are available,
➔
identify and then avoid obvious risks and
➔
allocate more time than you think is needed to complex or risky tasks
(you’ll need every minute). 38
 Cont’d...
Conduct a postmortem analysis
 Establish a consistent mechanism for extracting lessons learned for each
project.
➔
Evaluate the planned and actual schedules,
➔
Collect and analyze software project metrics,
➔
Get feedback from team members and customers, and
➔
Record findings in written form

39
 2.1.5 The W5HH Principle
To Get to the Essence of a Project
 Why is the system being developed?
 What will be done?
 When will it be accomplished?
 Who is responsible?
 Where are they organizationally located?
 How will the job be done technically and managerially?
 How much of each resource (e.g., people, software, tools, database) will be
needed?
40
 2.1.6 Critical Practices

Formal risk management

Empirical cost and schedule estimation

Metrics-based project management

Earned value tracking

Defect tracking against quality targets

People aware project management

41
 2.2 Management activities
 Project managers in different organizations may work in quite different
ways.
 A number of fundamental project management activities are common to all
organizations:
➔
Proposal writing
➔
Project planning
➔
Risk management
➔
People management
➔
Reporting
42
 2.3 Project planning
 The objective of software project planning is to provide a framework
that enables the manager to make reasonable estimates of resources,
cost, and schedule.
 For estimation of resources, cost, and schedule for a software engineering
effort requires experience, access to good historical information, and the
courage to commit to quantitative predictions when qualitative
information is all that exists.
 Project complexity, project size, and the degree of structural uncertainty all
affect the reliability of estimates.

43
 Cont’d...
Project Planning Process
 Establish project scope
 Determine feasibility
 Analyze risks
 Define required resources
➔
Determine require human resources
➔
Define reusable software resources
➔
Identify environmental resources
 Estimate cost and effort
 Develop a project schedule
44
 Software Scope
 Software scope describes
➔
The functions and features that are to be delivered to end-users
➔
The data that are input and output
➔
The “content” that is presented to users as a consequence of using the software
➔
The performance, constraints, interfaces, and reliability that bound the system.
 Scope is defined using one of two techniques:
➔
A narrative description of software scope is developed after communication
with all stakeholders.
➔
A set of use-cases is developed by end-users.
45
 Feasibility
 Once scope has been identified (with the concurrence of the customer), it is
reasonable to ask:
➔
Can we build software to meet this scope?
➔
Is the project feasible?”
 Once scope is understood, the software team and others must work to
determine if it can be done within the dimensions just noted.

46
 Resources
 The second planning task is estimation of the resources required to
accomplish the software development effort.
 The three major categories of software engineering resources
➔
People,
➔
Reusable software components, and
➔
The development environment.

47
 Cont’d...

Figure 2.3 Project resources 48

 Cont’d...
 Each resource is specified with four characteristics:
➔
description of the resource,
➔
a statement of availability,
➔
time when the resource will be required, and
➔
duration of time that the resource will be applied.
 The last two characteristics can be viewed as a time window.
 Availability of the resource for a specified window must be established at
the earliest practical time.

49
 Cont’d...

Human Resources - People

 Planner begins by evaluating scope and selecting the skills required to
complete development.
 The number of people required for a software project can be determined
only after an estimate of development effort is made.
 Can be measure on skills, specialty (i.e. communication, database admin
etc) or position.

50
 Cont’d...

Reusable software components

 Reusable components, must be cataloged for easy reference, standardized
for easy application, and validated for easy integration.
 Four software resource categories:
1. Off-the-shelf components
2. Full-experience components
3. Partial-experience components
4. New components

51
 Cont’d...

Off-the-shelf components:
 Existing software that can be acquired from a third party or that has been
developed internally for a past project.
 COTS (commercial off-the-shelf) components are purchased from a third
party, are ready for use on the current project, and have been fully
validated.

52
 Cont’d...

Full-experience components
 Existing specifications, designs, code, or test data developed for past
projects that are similar to the software to be built for the current project.
 Members of the current software team have had full experience in the
application area represented by these components.
 Therefore, modifications required for full-experience components will be
relatively low-risk.

53
 Cont’d...

Partial-experience components
 Existing specifications, designs, code, or test data developed for past projects
that are related to the software to be built for the current project but will
require substantial modification.
 Members of the current software team have only limited experience in the
application area represented by these components.
 Therefore, modifications required for partial-experience components have a
fair degree of risk.
New components
 Software components that must be built by the software team specifically for
the needs of the current project.
54
 Cont’d...
What issues should we consider when we plan to reuse existing software
components?
 In off-the-shelf components, cost for acquisition and integration of off-the-
shelf components will almost always be less and risk relatively is low.
 In full-experience components, risks associated with modification and
integration are generally acceptable.
 In partial-experience components, current project must be analyzed.
➔
Integration is difficult and risk is high.
➔
In some cases cost for components is also high compare to development
of new component.
55
 Cont’d...

Environmental Resources
 The environment that supports the software project incorporates hardware and
software often called the software engineering environment (SEE).
 Hardware provides a platform that supports the tools (software) required to
produce the work products.
 A project planner must prescribe the time window required for hardware and
software and verify that these resources will be available.
 For example, a computer-based system (incorporating specialized hardware and
software) is to be engineered, the software team may require access to hardware
elements being developed by other engineering teams (e.g. electronics,
mechanical etc.).
56
 Software project estimation
 Software cost and effort estimation will never be an exact science.
 Too many variables can affect the ultimate cost of software and effort
applied to develop it:
➔
human,
➔
technical,
➔
environmental,
➔
politica
 Software project estimation can be transformed from a black art to a
series of systematic steps that provide estimates with acceptable risk.
57
 Cont’d...

To achieve reliable cost and effort estimates, a number of options arise:

1.Delay estimation until late in the project (obviously, can achieve 100%
accurate estimates after the project is complete!)

2.Base estimates on similar projects that have already been completed.

3.Use relatively simple decomposition techniques to generate project cost

and effort estimates.

4.Use one or more empirical models for software cost and effort estimation

58
 Decomposition Techniques
 Decompose the problem or software, re-characterizing it as a set of
smaller problem or software.
 Estimation uses problem or process or both forms of partitioning.
 Before an estimate can be made,
➔
you must understand the scope of the software to be built and generate
an estimate of its “size.”
 It comprises of
➔
Software size
➔
Problem based estimation
➔
Process based estimation 59
 Software Sizing
 Sizing represents the project planner’s first major challenge.
 The accuracy of a software project estimate is predicated on a number of
things:
1. The degree to which you have properly estimated the size of the product to be
built;
2. The ability to translate the size estimate into human effort, calendar time, and
dollars
3. The degree to which the project plan reflects the abilities of the software
team;
4. The stability of product requirements and the environment that supports the
software engineering effort.
60
 Cont’d...
 Size refers to a quantifiable outcome of the software project.
➔
If a direct approach is taken, size can be measured in LOC.
➔
If an indirect approach is chosen, size is represented as FP.
 Size can be estimated by considering
➔
the type of project and its application domain,
➔
the functionality delivered (i.e., the number of function points),
➔
the number of components to be delivered,
➔
the degree to which a set of existing components must be modified for the new
system.
 To create a “three-point” or “expected value” estimate.
➔
optimistic (low), most likely (medium), and pessimistic (high) values
61
 Problem Based estimation
 Project planner begins from software scope statement to decompose
software into problem functions that can each be estimated individually.
 LOC and FP data are used in two ways during software project estimation:
1. As an estimation variable (i.e. LOC or FP) to "size“ each element of the
software.
2. As baseline metrics collected from past projects and used in combination
with estimation variables to develop cost and effort projections.
 LOC or FP (the estimation variable) is then estimated for each function
(i.e. cost, effort etc.)
62
 Cont’d...

Baseline productivity metrics (e.g., LOC/pm or FP/pm) are then applied to
the appropriate estimation variable, and cost or effort for the function is
derived.

Function estimates are combined to produce an overall estimate for the
entire project.

LOC/pm or FP/pm averages should be computed by project domain.
➔
That is, projects should be grouped by team size, application area,
complexity, and other relevant parameters.

When a new project is estimated, it should first be allocated to a domain, and
then the appropriate domain average for productivity should be used in
generating the estimate.
63
 Cont’d...
 The LOC and FP estimation techniques differ in the level of detail required for
decomposition and the target of the partitioning.
 If LOC is used as the estimation variable, decomposition is absolutely essential
and is often taken to considerable levels of detail.
➔
The greater the degree of partitioning, the more likely reasonably accurate
estimates of LOC can be developed.
 For FP estimates, decomposition works differently.
➔
Rather than focusing on function, each of the information domain
characteristics(inputs, outputs, data files, inquiries, and external interfaces) as
well as the 14 complexity adjustment values are estimated.
➔
FP value that can be tied to past data and used to generate an estimate.
64
 Cont’d...
 Project planner begins by estimating a range of values for each function or
information domain value.(i.e. regardless of the estimation variable)
 Planner estimates an optimistic (low), most likely, and pessimistic (high) size
value for each function or count for each information domain value.
 A three-point or expected value for the estimation variable (size), S, can be
computed as a weighted average of the optimistic (Sopt), most likely (Sm), and
pessimistic (Spess) estimates.
S = (Sopt + 4Sm + Spess)/6
 Once the expected value for the estimation variable has been determined,
historical LOC or FP productivity data are applied.

65
 Example LOC base estimation
 A software package to be developed for a CAD application for mechanical
components.
 A review of the System Specification indicates that the software is to
execute on an engineering workstation and must interface with various
computer graphics peripherals including a mouse, digitizer, high resolution
color display and laser printer.

66
 Cont’d...
 Based on system specification, a preliminary statement of software scope can be
developed:
The mechanical CAD software will accept two- and three-dimensional geometric data
from a designer. The designer will interact and control the CAD system through a user
interface that will exhibit characteristics of good human/machine interface design. All
geometric data and other supporting information will be maintained in a CAD database.
Design analysis modules will be developed to produce the required output, which will be
displayed on a variety of devices. The software will be designed to control and interact
with peripheral devices that include a mouse, scanner, laser printer, and plotter.

 Every sentence of software scope would have to be expanded to provide concrete detail
and quantitative bounding ( i.e. major functions of CAD system).
 Now, Decomposition technique for LOC, an estimation table, shown in Figure 2.4, is
developed. 67
Cont’d...

Figure 2.4 Example LOC base estimation 68

 Cont’d...
 Develop range of LOC estimate for each function.
 For example, range of LOC estimates for the 3D geometric analysis function is
optimistic 4600 LOC, most likely 6900 LOC, and pessimistic 8600 LOC.
 Compute expected value for the 3D geometric analysis function is 6800 LOC.
 By summing estimate LOC, 33200 LOC is established for CAD system
 Now we can review of historical data indicates average productivity for systems of
this type is 620 LOC/pm.
 Labor rate is 8000 birr per month, the cost per line of code is approximately 13 birr
(i.e. 8000/620).
 Based on the LOC estimate and the historical productivity data, the total estimated
project cost is 431,000 birr (i.e. 33200 x 13) and the estimated effort is 54 person-
months (i.e. 431000 / 8000)
69
 Example FP base estimation
 Decomposition for FP-based estimation focuses on information domain
values rather than software functions.
 Project planner estimates inputs, outputs, inquiries, files, and external
interfaces for the CAD software.
 For the purposes of this estimate, the complexity weighting factor is
assumed to be average.

70
Cont’d...

Figure 2.5 Example FP base estimation 71

Cont’d...

Each of these questions is answered

using a scale that ranges from 0 to 5.
0 - not important applicable
5 - absolutely essential

Figure 2.6 72
 Cont’d...
 Finally, the estimated number of FP is derived:
FP estimated = count-total x [0.65 + 0.01 x (Fi)]
FP estimated = 375
 The organizational average productivity for systems of this type is 6.5
FP/pm.
 Based on labor rate of 8000 birr per month, the cost per FP is
approximately 1230 birr (i.e. 8000/6.5).
 Based on the LOC estimate and the historical productivity data, the
total estimated project cost is 461,000 birr (i.e. 375 x 1230) and the
estimated effort is 58 person-months (i.e. 461000/8000).

73
 Process-Based Estimation
 The process is decomposed into a relatively small set of tasks and the
effort required to accomplish each task is estimated.
 Like the problem-based techniques, process-based estimation begins with
project scope.
 Functions and related software process activities may be represented as
part of a table similar to the one presented in Figure 2.7.
 Once problem functions and process activities are melded, the planner
estimates the effort (e.g., person-months) that will be required to
accomplish each software process activity for each software function.

74
 Cont’d...
 The process is decomposed into a relatively small set of tasks and the effort
required to accomplish each task is estimated.
 Average labor rates (i.e., cost/unit effort) are then applied to the effort
estimated for each process activity
 If process and problem based estimation performed independently, it
means we have two or three estimates for cost and effort that may be
compared and reconciled.
 If both sets of estimates show reasonable agreement, there is good reason
to believe that the estimates are reliable.

75
Cont’d...

Figure 2.7 76
 Cont’d...
 The engineering and construction release activities are subdivided into the
major software engineering tasks shown.
 Horizontal and vertical totals provide an indication of estimated effort
required for analysis, design, code, and test.
 Here, 53 percent of all effort is expended on front-end engineering tasks
(requirements analysis and design).
 Based on labor rate of 8,000 birr per month, total estimated project cost is
368,000 birr( i.e. 8000 x 46) and the estimated effort is 46 person-months.
 Total estimated effort for the CAD software range from a low of 46
person-months to a high of 58 person-months. The average estimate is 53
person-months.
77
 2.4 Project scheduling
 Software project scheduling is an activity that distributes estimated effort
across the planned project duration by allocating the effort to specific
software engineering tasks.
 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.

78
 Basic Concept
Why software is delivered late?
 An unrealistic deadline established
 Changing customer requirements that are not reflected in schedule changes.
 Underestimate of the amount of effort and/or the number of resources that will be required to do
the job.
 Predictable and/or unpredictable risks that were not considered when the project commenced.
 Technical difficulties that could not have been foreseen in advance.
 Human difficulties that could not have been foreseen in advance.
 Miscommunication among project staff that results in delays.
 A failure by project management to recognize that the project is falling behind schedule and a
lack of action to correct the problem.
79
 Basic principle
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 refined.
 Interdependency. The interdependency of each compartmentalized activity or
task must be determined. Some tasks must occur in sequence, while others can
occur in parallel.
 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
80
 Cont’d...
 Effort validation: As time allocation occurs, the project manager must
ensure that no more than the allocated number of people have 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 a work product or
deliverable.
 Defined milestones. A milestone is accomplished when one or more work
products has been reviewed for quality and has been approved.
81
 Defining a task set
 A task set is a collection of software engineering work tasks, milestone, and
deliverables that must be accomplished to complete a particular project.
 The task set must provide enough discipline to achieve high software
quality.
➔
But, at the same time, it must not load the project team with unnecessary
work.
 To develop a project schedule, a task set must be distributed on the project
timeline.
➔
Task set will vary depending upon the project type and the degree of
rigor.
82
 Cont’d...
 Task sets are designed to accommodate different types of projects and
different degrees of rigor.
 To define a Task set
➔
Determine project type
➔
Identify adaptation criteria
➔
Assess the degree of rigor required
➔
Select appropriate software engineering tasks.

83
 Determine the project type

Concept development projects that are initiated to explore some new
business concept or application of some new technology.

New application development projects that are undertaken as a
consequence of 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.
84
 Identify adaptation criteria
Even within a single project type, many factors influence the task set to be chosen. These
include

 Each of the adaptation criteria is assigned a grade
Size of project
that ranges between 1 and 5, where

Number of potential users. ➔
1 represents a project in which a small subset of

Mission criticality process tasks are required and

Application longevity ➔
5 represents a project in which a complete set of
 process tasks should be applied
Stability of requirements

Ease of customer/developer communication

Maturity of applicable technology

Performance constraints,

Project staff

Reengineering. 85
 Degree of rigor
 Adaptation criteria are used to determine the recommended degree of rigor with
which the software process should be applied on a project.
 The degree of rigor is a function of many project characteristics.
 As an example, small, non-business-critical projects can generally be addressed with
somewhat less rigor than large, complex business-critical applications.
 Four different degrees of rigor can be defined:
➔
Casual
➔
Structured
➔
Strict
➔
Quick reaction
86
 A task set example
 In order to develop a project schedule, a task set must be distributed on the
project time line.
 Major software engineering tasks are applicable to all process model flows.
 As an example, we consider the software engineering tasks for a concept
development project.

87
 Cont’d...
Major Task Set for concept development project are:

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 feasibility 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 ask for feedback on a new technology concept and
targets specific customer applications.
88
 Cont’d...
 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)
 Implement it in a prototypical manner so that the customer can evaluate it
(concept implementation and customer evaluation).
 Finally, if the concept is viable, a production version (translation) must be
produced.
89
 Refinement of Major Task
 Refinement begins by taking each major task and decomposing it into a
set of subtasks (with related work products and milestones)
 As an example of task decomposition, consider concept scoping for a
development Project
 Task refinement can be accomplished using an outline format a process
design language approach is used to illustrate the flow of the concept
scoping activity

90
Task definition: Action 1.1 Concept Scoping Cont’d...
1.1.1 Identify need, benefits and potential customers;
1.1.2 Define desired output/control and input events that drive the application;
Begin Task 1.1.2
1.1.2.1 TR: Review written description of need
1.1.2.2 Derive a list of customer visible outputs/inputs
1.1.2.3 TR: Review outputs/inputs with customer and revise as required;
Endtask Task 1.1.2
1.1.3 Define the functionality/behavior for each major function;
Begin Task 1.1.3
1.1.3.1 TR: Review output and input data objects derived in task 1.1.2;
1.1.3.2 Derive a model of functions/behaviors;
1.1.3.3 TR: Review functions/behaviors with customer and revise as required;
endtask Task 1.1.3
1.1.4 Isolate those elements of the technology to be implemented in software;
1.1.5 Research availability of existing software;
1.1.6 Define technical feasibility;
1.1.7 Make quick estimate of size;
1.1.8 Create a scope definition;
endtask definition: Action 1.1 91
 Defining a Task Network
 A task network, also called an activity network, is a graphic
representation of the task flow for a project.
 It is sometimes used as the mechanism through which task sequence and
dependencies are input to an automated project scheduling tool.
 Therefore, the task network depicts major software engineering tasks.
 Figure 2.8 shows a schematic task network for a concept development
project.
 The concurrent nature of software engineering activities leads to a number
of important scheduling requirements.

92
Cont’d...

Figure 2.8 A task network for concept development 93

 Scheduling
 Two project scheduling methods
➔ Program evaluation and review technique (PERT)

➔ Critical path method (CPM)

 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.
94
 Cont’d...
 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;
➔ Calculate “Boundary times” that define a time "window" for a particular
task.

 Both PERT and CPM have been implemented in a wide variety of automated
tools that are available for the personal computer
E.g. Primevera software

95
 Timeline Charts
 The planner always 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.
 A timeline chart enables you to determine what tasks will be conducted at a
given point in time.
 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.
96
Cont’d...

Figure 2.9 An example time-line chart 97

Cont’d...

Figure 2.10 An example project table 98

 Tracking the Schedule
 Project schedule defines the tasks and milestones that must be tracked and
controlled as the project proceeds.
 Tracking can be accomplished in a number of different ways:
➔
Conducting periodic project status meetings in which each team member
reports progress and problems.
➔
Evaluating the results of all reviews conducted
➔
Determining whether formal project milestones (i.e. diamonds) have been
accomplished by the scheduled date.
➔
Comparing actual start-date to planned start-date for each project task listed in
the resource table.
➔
Using earned value analysis to evaluate progress quantitatively.

99
 Cont’d...
 Control is employed by a software project manager to administer project
resources, cope with problems, and direct project staff.
 If things are going well (i.e., the project is on schedule and within budget,
reviews indicate that real progress is being made and milestones are being
reached), control is light.
 When problems occur, you must exercise control to reconcile them as quickly
as possible.
➔ After a problem has been diagnosed, additional resources may be focused on
the problem area: staff may be redeployed or the project schedule can be
redefined.

100
 2.4 Risk Management
 Reactive Risk Vs Proactive Risk Management
 Software Risks
 Risk Identification
 Risk Refinement
 Risk Mitigation, Monitoring, and Management

101
 Reactive Vs Proactive Risk Management
Reactive Risk Management
 Project team reacts to risks when they occur.
 More commonly, the software team does nothing about risks until
something goes wrong.
 Then, the team involved into action in an attempt to correct the problem
rapidly. This is often called a fire fighting mode.
 When this fails, “crisis management” takes over and the project is in real
jeopardy.

102
 Cont’d...
Proactive Risk Management
 A proactive strategy begins long before technical work is initiated.
 Potential risks are identified, their probability and impact are assessed,
and they are ranked by importance.
 Then, the software team establishes a plan for managing risk.
 The primary objective is to avoid risk, but because not all risks can be
avoided,
➔ The team works to develop a contingency plan that will enable it to
respond in a controlled and effective manner.

103
 Software Risks
 Risk always involves two characteristics:
➔ 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
 When risks are analyzed, it is important to quantify the level of uncertainty
and the degree of loss associated with each risk.
 To accomplish this, different categories or types of risks are considered.
➔ Project Risks ➔
Known Risks.
➔ Technical Risks ➔
Predictable Risks
➔ Business Risks ➔
Unpredictable Risks 104
 Cont’d...
Project Risk
 Project risks make threats the project plan.
 If project risks become real, it is likely that 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.
 Project complexity, size, and the degree of structural uncertainty were
also defined as project risk factors.

105
 Cont’d...
Technical risks
 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.
 Technical risks identify potential design, implementation, interface,
verification, and maintenance problems.
 In addition, specification ambiguity, technical uncertainty, technical
obsolescence, and "leading-edge" technology are also risk factors.

106
 Cont’d...
Business Risk
 Business risks threaten the feasibility of the software to be built.
 Business risks often jeopardize the project or the product.
 Top five business risks are
➔ Building a excellent product or system that no one really wants (market risk),
➔ Building a product that no longer fits into the overall business strategy for the
company (strategic risk)
➔ Building a product that the sales force doesn't understand how to sell(sales risk)
➔ Losing the support of senior management due to a change in focus or a change in
people (management risk)
➔ Losing budgetary or personnel commitment (budget risks)
107
 Cont’d...
Known Risk, Predictable risks, Unpredictable risks
 Known risks are those that can be uncovered after careful evaluation of the
project plan, the business and technical environment in which the project is
being developed,
➔ Other reliable information sources (e.g., unrealistic delivery date, lack of
documented requirements or software scope, poor development
environment).
 Predictable risks are generalized from past project experience (e.g., staff
turnover, poor communication with the customer, etc).
 Unpredictable risks are the joker in the deck. They can and do occur, but they
are extremely difficult to identify in advance.
108
 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.
 Two distinct types of risks
➔ Generic risks are a potential threat to every software project
➔ Product-specific risks can be identified only by those with a clear understanding of
the technology, the people, and the environment that is specific to the project at
hand.
 To identify product-specific risks, the project Plan and the software statement of
scope are examined.
 One method for identifying risks is to create a risk item checklist.
109
 Cont’d...
The checklist can be used for risk identification and focuses on some subset of known and
predictable risks in the following generic subcategories:
 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.
110
 Cont’d...
Risk Components
PM identify the risk drivers that affect software risk components:
 Performance risk: the degree of uncertainty that the product will meet its
requirements and be fit for its intended use.
 Cost risk: the degree of uncertainty that the project budget will be
maintained.
 Support risk: the degree of uncertainty that the resultant software will be
easy to correct, adapt, and enhance.
 Schedule risk: the degree of uncertainty that the project schedule will be
maintained and that the product will be delivered on time.
111
 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.
➔ The consequences (i.e. effect or result) 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 supposed likelihood of a risk
➔ Describe the consequences of the risk,
➔ Estimate the impact of the risk on the project and the product,
➔ Note the overall accuracy of the risk projection so that there will be no misunderstanding
 The intent of these steps is to consider risks in a manner that leads to prioritization. By
prioritizing risks, the team can allocate resources where they will have the most impact.
112
 Developing a Risk Table
 A risk table provides you with a simple technique for risk projection.
 Listing all risks in first column. This can be accomplished with the help of
the risk item checklists
 Each risk is categorized in the second column
 The probability of occurrence of each risk is entered in the next column of
the table. Which can be estimated by team members.
 Impact of each risk is assessed.
➔ Each risk component is assessed using the characterization and an
impact categories like catastrophic, critical, marginal and negligible are
determined. 113
 Cont’d...
 Once table is completed, manger will give order of prioritization to the
risk. Therefore, the table is sorted by probability and by impact.
 High-probability, high-impact risks get into the top of the table, and low-
probability risks drop to the bottom. (First order prioritization).
 The project manager studies the resultant sorted table and defines a cutoff
line.
 The cutoff line implies that only risks that lie above the line will be given
further attention.
 Risks that fall below the line are considered as second-order prioritization.
114
 Cont’d...
Impact
assessment

Note: (1) The potential consequence of undetected software errors or faults.

Figure 2.12 (2) The potential consequence if the desired outcome is not achieved. 115
 Cont’d...
Impact values:
1—catastrophic
2—critical
3—marginal
4—negligible

Figure 2.13 Sample risk table prior to sorting 116

 Cont’d...
 Risk impact and probability have a distinct influence on management
concern.
 Risk factor that has a high impact but a very low probability of occurrence
then management will give little attention or some time no attention.
 But if risk factor that has high impact and high probability of occurrence
then management will give high attention.
 All risks that lie above the cutoff line must be managed and specify in last
column of the table under RMMM column.

117
 Cont’d...
Risk and management concern

Figure 2.14 118

 Assessing Risk Impact
 Three factors affect the consequences that are likely if a risk does occur:
➔ Nature,

➔ Scope, and

➔ Timing

 The nature of the risk indicates the problems that are likely if it occurs.
For example, a technical risk, development environment change
 The scope of a risk combines the severity with its overall distribution. For
ex. how much of the project will be affected or how many customers are
harmed?
 The timing of a risk considers when and for how long the impact will be
felt.
119
 Cont’d...
To determine the overall consequences of a risk:
 Determine the average probability of occurrence value for each risk
component.
 Determine the impact for each component based on the criteria.
 Complete the risk table and analyze the results as described
Now measure, Risk exposure (RE).
RE = P x C
➔
P is the probability of occurrence for a risk and
➔
C is the cost to the project.
120
 Cont’d...
Example- the software team defines a project risk in the following manner
 Risk Identification - Only 70 percent of the software components scheduled for
reuse and remaining functionality will have to be custom developed.
 Risk probability. 80% (likely).
 Risk Impact – Assume total no. of component is 60. If only 70 percent can be
used, 18 components would have to be developed from scratch.
 Since the average component is 100 LOC and local data indicate that the
software engineering cost for each LOC is $14.00,
 the overall cost (impact) to develop the components would be
18 x 100 x 14 = $25,200.
 Risk exposure. RE = 0.80 x 25,200 ~ $20,200.
121
 Cont’d...
 Once an estimate of the cost of the risk is derived, compute RE for each risk in
risk table.
 The total risk exposure for all risks (above the cutoff in the risk table) can
provide a means for adjusting the final cost estimate for a project.
 The project team should revisit the risk table at regular intervals, re-evaluating
each risk to determine when new circumstances cause its probability and impact
to change.
 As a consequence of this activity, it may be necessary to add new risks to the
table, remove some risks that are no longer relevant, and change the relative
positions of still others.
 Compare RE for all risks to the cost estimate for the project. If RE is greater
than 50 percent of project cost, the feasibility of the project must be evaluated.
122
 Risk Refinement
 During early stages of project planning, a risk may be stated quite generally.
 As 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, each somewhat easier to mitigate,
monitor, and manage.
 One way to do this is to represent the risk in condition-transition-consequence.
That is, the risk is stated in the following form:
 Given that <condition> then there is concern that (possibly) <consequence>.
 Using the CTC format for the reuse risk noted below, you could write:
Given that all reusable software components must conform to specific design standards
and that some do not conform, then there is concern that (possibly) only 70 percent of the
planned reusable modules may actually be integrated into the as-built system, resulting in
the need to custom engineer the remaining 30 percent of components.
123
 Cont’d...
 This general condition can be refined in the following manner:
Subcondition 1. Certain reusable components were developed by a third party
with no knowledge of internal design standards.
Subcondition 2. The design standard for component interfaces has not been
solidified and may not conform to certain existing reusable components.
Subcondition 3. Certain reusable components have been implemented in a
language that is not supported on the target environment.
 The consequences associated with these refined subconditions remain the same
(i.e., 30 percent of software components must be custom engineered), but the
refinement helps to isolate the underlying risks and might lead to easier analysis
and response.
124
 Risk Mitigation, Monitoring, and Management
 Risk analysis goal - to assist the project team in developing a strategy for
dealing with risk. An effective strategy must consider three issues:
➔ Risk avoidance or mitigation.
➔ Risk monitoring
➔ Risk management and contingency planning
 Proactive approach to risk, avoidance is always the best strategy. This is
achieved by developing a plan for risk mitigation.
 For example, assume that high staff turnover (i.e. revenue) is noted as a
project risk.
125
 Cont’d...
To mitigate this 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 (e.g., low pay,
competitive job market).
 Mitigate those causes that are under our control before the project starts.
 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.
126
 Cont’d...
 As the project proceeds, risk monitoring activities commence.
 The project manager monitors factors that may provide an indication of
whether the risk is becoming more or less likely.
 In the case of high staff turnover, the following factors can be monitored:
➔ General attitude of team members based on project pressures.
➔ Potential problems with compensation and benefits.
➔ The availability of jobs within the company and outside it.
 Risk management and contingency planning assumes that mitigation
efforts have failed and that the risk has become a reality.
127
 Cont’d...
 The project is well underway and a number of people announce that they will be
leaving. If the mitigation strategy has been followed, backup is available, information
is documented, and knowledge has been dispersed across the team.
 In addition, the project manager may temporarily refocus resources (and readjust the
project schedule) to those functions that are fully staffed, enabling newcomers who
must be added to the team to “get up to speed.”
 Those individuals who are leaving are asked to stop all work and spend their last
weeks in “knowledge transfer mode.”
 This might include video-based knowledge capture, the development of “commentary
documents,” and/or meeting with other team members who will remain on the project.
 RMMM steps incur additional project cost. For example, spending the time to
"backup" every critical technologist costs money.
128
 THE RMMM PLAN
 The RMMM plan documents all work performed as part of risk analysis and is
used by the project manager as part of the overall project plan.

 Some software teams do not develop a formal RMMM document. Rather, each
risk is documented individually using a risk information sheet (RIS).

 RIS is maintained using a database system, so that creation and information

entry, priority ordering, searches, and other analysis may be accomplished
easily.

 Once RMMM has been documented and the project has begun, risk mitigation
and monitoring steps commence.

129
Cont’d...

Risk
information
sheet

Figure 2.15
130
Thank You !