UNIT - I

Introduction

Disclaimer:
The lecture notes have been prepared by referring to many books and notes prepared by the teachers. This document does not claim
any originality and cannot be used as a substitute for prescribed textbooks.
 Topics
• Introduction to Software Engineering
• Software Project Management – Lifecycle Activities
• Traditional – Waterfall, V Model, Prototype, Spiral, RAD
• Conventional – Agile, XP, Scrum
• Introduction to Requirements Engineering
• Requirements Elicitation
• Software Project Effort and Cost Estimation
• Cocomo 1 and 2
• Risk Management
• Configuration Management
• Project Planning – WBC, Planning, Scope, Risk
2
 Introduction To Software Engineering
• The IEEE definition:
– Software Engineering: The application of a systematic, disciplined,
quantifiable approach to the development, operation and maintenance of
software.
• Some realities:
– To understand the problem before a software solution is developed
– Design becomes a essential activity
– Software should exhibit high quality
– Software should be maintainable
 Layered Technology
• Software engineering is a layered technology.
• The foundation for software engineering is the process layer.
• Process defines a framework that must be established for effective delivery of
software.
• Software engineering methods provide the technical how-to’s for building
software.
• Methods encompass a broad array of tasks that include communication,
requirements analysis, design modeling, program construction, testing, and
support.
• Software engineering tools provide automated or semi automated support for
the process and the methods.

Tools

Methods

Process Model

“Quality” Focus
 Essence of Practice
• Polya suggests:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

• Understand the problem (Communication and Analysis)

- Who are the stakeholders?
- What are the unknowns?
- What data, functions, and features are required to properly solve the
problem?
- Can the problem be compartmentalized?
- Is it possible to represent smaller problems that may be easier to
understand?
- Can the problem be represented graphically?
- Can an analysis model be created?
 Essence of Practice
• Plan the Solution
- Have you seen similar problems before? Are there patterns that are familiar in
a potential solution? Is there existing software that implements the data,
functions, and features that are required?
- Has a similar problem been solved? If so, are elements of the solution
reusable?
- Can sub problems be defined? If so, are solutions readily apparent for the sub
problems?
- Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created? Can an analysis model be
created?

• Carry Out the Plan

- Does the solution conform to the plan? Is source code traceable to the design
model?
- Is each component part of the solution provably correct? Has the design and
code been reviewed, or better?
 Essence of Practice
• Examine the Result
- Is it possible to test each component part of the solution? Has a reasonable
testing strategy been implemented?
- Does the solution produce results that conform to the data, functions, and
features that are required? Has the software been validated against all
stakeholder requirements?

• How it all Starts – Safe Home:

– Every software project is precipitated by some business need:
• The need to correct a defect in an existing application;
• The need to adapt a ‘legacy system’ to a changing business
environment;
• The need to extend the functions and features of an existing application,
or
• The need to create a new product, service, or system
 Software Project Management
Introduction
• Concerned with activities involved in ensuring that software is delivered on time
and on schedule and in accordance with the requirements of the organisations
developing and procuring the software.
• Project management is needed because software development is always subject
to budget and schedule constraints that are set by the organisation developing
the software.

Success Criteria
• Deliver the software to the customer at the agreed time.
• Keep overall costs within budget.
• Deliver software that meets the customer’s expectations.
• Maintain a coherent and well-functioning development team.
 Software Project Management
Software Management Distinctions
• The product is intangible.
– Software cannot be seen or touched.
– Software project managers cannot see progress by simply looking at the
artefact that is being constructed.
• Many software projects are 'one-off' projects.
– Large software projects are usually different in some ways from previous
projects.
– Even managers who have lots of previous experience may find it difficult to
anticipate problems.
• Software processes are variable and organization specific.
– We still cannot reliably predict when a particular software process is likely to
lead to development problems.

Factors Influencing Project Management

• Company size
• Software customers
 Software Project Management
Factors Influencing Project Management
• Software size
• Software type
• Organizational culture
• Software development processes
• These factors mean that project managers in different organizations may work in
quite different ways.

Software Management Lifecycle Activities

• Proposal writing
– The first stage in a software project may involve writing a proposal to win a
contract to carry out an item of work.
– The proposal describes the objectives of the project and how it will be
carried out.

• Project planning
– Project managers are responsible for planning, estimating and scheduling
project development and assigning people to tasks.
 Software Project Management
Software Management Lifecycle Activities
• Risk management
– Project managers assess the risks that may affect a project, monitor these
risks and take action when problems arise.

• People management
– Project managers have to choose people for their team and establish ways
of working that leads to effective team performance.

• Reporting
– Project managers are usually responsible for reporting on the progress of a
project to customers and to the managers of the company developing the
software.
 Traditional Software Process Models
Waterfall
• It is the oldest paradigm for Software Engineering.
• When requirements are well defined and reasonably stable, it leads to a linear
fashion.
• The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development that begins with
customer specification of requirements and progresses through planning,
modeling, construction and deployment, culminating in ongoing support of the
completed software.
• When to select?
• There are times when the requirements for a problem are well understood—
when work flows from communication through deployment in a reasonably
linear fashion.
 Traditional Software Process Models
Waterfall - Problems
• Inflexible partitioning of the project into distinct stages makes it difficult to
respond to changing customer requirements.
– Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.
– Few business systems have stable requirements.
• The waterfall model is mostly used for large system engineering projects where
a system is developed at several sites.
– In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.

Waterfall - Advantages
1. Simple
2. Easy to understand even for non technical customers
3. Oldest, widely used
4. Base for all other models by including feed back loops, iterations etc.
 Traditional Software Process Models
Waterfall - Disadvantages
1. Real projects rarely follow this linear sequence.
2. Difficult for customer to state all requirements at one shot
3. Customer must have patience.

V-Model
• A variation of waterfall model depicts
the relationship of quality assurance
actions to the actions associated with
communication, modeling and early code
construction activities.
• Team first moves down the left side of
the V to refine the problem requirements.
• Once code is generated, the team moves
up the right side of the V, performing
a series of tests that validate each of
the models created as the team moved
down the left side.
 Traditional Software Process Models
Prototyping
• Begins with communication
• A quick plan for prototyping and modeling occur.
• Quick design focuses on the representation of those aspects the software will be
visible to end users. (Interface and output).
• Design leads to the construction of
a prototype which will be deployed
and evaluated. Quick
plan
• Stakeholder’s comments will be Communication

used to refine requirements. Modeling

Quick design

Deployment
delivery &
feedback Construction
of prototype
 Traditional Software Process Models
Prototyping – When to Select
• Customer defines a set of general objectives
• Does not identify detailed requirements
• Developer may be unsure of the efficiency of an algorithm, the form that human
computer interaction should take.
• When your customer has a legitimate need, but is clueless about the details,
develop a prototype as a first step.

Prototyping - Advantages
1. Provides working model.
2. Customer is highly satisfied with such a modeling at initial stages
3. Developer gains business insight, reducing ambiguity
4. Great involvement of users
5. Reduce risks
 Traditional Software Process Models
Prototyping - Disadvantages
1. Customer - not aware that only interface or appearance is concentrated much
and long term quality is at stake.
2. False expectations from customer that end software modelling is finished or will
have the same behavior/pace of the prototype.
3. Inappropriate choices of technology
4. Various iterations to a prototype that is to be discarded is expensive
 Traditional Software Process Models
Spiral
• It couples the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model and is a risk-driven process model generator that
is used to guide multi-stakeholder concurrent engineering of software intensive
systems.
• Two main distinguishing features: one is cyclic approach for incrementally
growing a system’s degree of definition and implementation while decreasing its
degree of risk. The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually satisfactory system solutions.
• A series of evolutionary releases are delivered.
• During the early iterations, the release might be a model or prototype.
• During later iterations, increasingly more complete version of the engineered
system are produced.
• The first circuit in the clockwise direction might result in the product
specification; subsequent passes around the spiral might be used to develop a
prototype and then progressively more sophisticated versions of the software.
• Each pass results in adjustments to the project plan.
• Cost and schedule are adjusted based on feedback.
 Traditional Software Process Models
Spiral
• Also, the number of iterations will be adjusted by project manager.
• Good to develop large-scale system as software evolves as the process
progresses and risk should be understood and properly reacted to.

• Prototyping is used to reduce risk.

• However, it may be difficult to convince customers that it is controllable as it
demands considerable risk assessment expertise.
 Traditional Software Process Models
Spiral - Advantages
1. Applies throughout lifecycle
• Concept Development
• New Product Development
• Product Enhancement
2. Risk is considered at each pass
3. Uses prototyping as risk reduction mechanism
4. Customer and developer understand and better react to risks

Spiral - Disadvantages
1. Difficult to convince customers that it is controllable
2. Demands considerable risk assessment expertise
3. Major risk is not uncovered/managed, problem will occur
 Traditional Software Process Models
Rapid Application Development
• An approach to software development aimed at rapid delivery of the software.
• It often involves the use of database programming and development support
tools such as screen and report generators.
• There are three broad phases to RAD:
– Requirements planning
– RAD design workshop
– Implementation
• Requirements planning
- Users and analysts meet to identify objectives of the application or system
- Oriented toward solving business problems
• RAD Design Workshop
– Design and refine phase
– Use group decision support systems to help users agree on designs
– Programmers and analysts can build and show visual representations of the
designs and workflow to users
 Traditional Software Process Models
Rapid Application Development
• RAD Design Workshop
– Users respond to actual working prototypes
– Analysts refine designed modules based on user responses
• Implementation Phase
- As the systems are built and refined, the new systems or partial systems are
tested and introduced to the organization
- When creating new systems, there is no need to run old systems in parallel

• The Martin approach to RAD includes four phases:

– Requirements planning
– User design
– Construction
– Cutover
 Traditional Software Process Models
Rapid Application Development – When to Select
• The team includes programmers and analysts who are experienced with it
• There are pressing reasons for speeding up application development
• The project involves a novel ecommerce application and needs quick results
• Users are sophisticated and highly engaged with the goals of the company

Rapid Application Development – Advantages

• RAD is very powerful when used within the SDLC
• It can be used as a tool to update, improve or innovate selected portions of the
system

Rapid Application Development – Disadvantages

• May try and hurry the project too much
• Loosely documented
• May not address pressing business problems
• Potentially steep learning curve for programmers inexperienced with RAD tools
 Conventional Software Process Models
Agile
• Agile software development is a group of software development methods in
which requirements and solutions evolve through collaboration between self-
organizing, cross-functional teams.
• It promotes adaptive planning, evolutionary development, early delivery,
continuous improvement, and encourages rapid and flexible response to
change.
• What is Agility?
– Effective (rapid and adaptive) response to change
– Effective communication among all stakeholders
– Drawing the customer onto the team
– Organizing a team so that it is in control of the work performed
– Yielding …Rapid, incremental delivery of software
• Agile Process is driven by customer descriptions of what is required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy emphasis on construction activities
• Delivers multiple ‘software increments’
• Adapts as changes occur
 Conventional Software Process Models
Agile - Principles
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within
a development team is face–to–face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
 Conventional Software Process Models
Agile – Principles
11. The best architectures, requirements, and designs emerge from self–organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

Human Factors
• The process moulds to the needs of the people and team, not the other way
around
• Key traits must exist among the people on an agile team and the team itself:
– Competence
– Common focus
– Collaboration
– Decision-making ability
– Fuzzy problem-solving ability
– Mutual trust and respect
– Self-organization
 Conventional Software Process Models
Agile – Extreme Programming (XP)
• The most widely used agile process, originally proposed by Kent Beck
• XP Planning
– Begins with the creation of “user stories (Listening leads to creation of set of
“stories” (also called user stories) that describe required output, features
and functionality for software to be built).”
– Agile team assesses each story and assigns a cost
– Stories are grouped, for a deliverable increment
– A commitment is made on delivery date
– After the first increment “project velocity” is used to help define subsequent
delivery dates for other increments

• XP Design
– Follows the KIS principle
– Encourage the use of CRC cards
– For difficult design problems, suggests the creation of “spike solutions”—a
design prototype
– Encourages “refactoring”—an iterative refinement of the internal program
design
 Conventional Software Process Models
Agile – Extreme Programming (XP)
 Conventional Software Process Models
Agile – Extreme Programming (XP)
• XP Coding
– Recommends the construction of a unit test for a store before coding
commences
– Encourages “pair programming” (XP recommends that two people work
together at one computer workstation to create code for a story)

• XP Testing
– All unit tests are executed daily
– “Acceptance tests” are defined by the customer and executed to assess
customer visible functionality
 Conventional Software Process Models
Agile – Scrum
• Scrum is an agile software development method that was conceived by Jeff
Sutherland and his development team in the early 1990s.
• In recent years, further development on the scrum methods has been performed
by Schwaber and Beedle.
• Scrum principles are consistent with the agile manifesto and are used to guide
development activities within a process that incorporates the following
framework activities: Requirements, Analysis, Design, Evolution and delivery.
• Within each framework activity, work tasks occur within a process pattern called
a sprint.
• The work conducted within a sprint is adapted to the problem at hand and is
defined and often modified in real time by the Scrum team.
• The overall flow of the Scrum process is illustrated in figure below.
• Scrum emphasizes the use of a set of software process patterns that have proven
effective for projects with tight timelines, changing requirements and business
criticality.
• Each of these process patterns defines a set of development actions:
1. Backlog – a prioritized list of project managements or features that provide
business value for the customer. Items can be added to the backlog at any time.
The product manager assess the backlog and updates priorities as required.
 Conventional Software Process Models
Agile – Scrum
 Conventional Software Process Models
Agile – Scrum
• Each of these process patterns defines a set of development actions:
2. Sprints – consist of work units that are required to achieve a requirement
defined in the backlog that must be fit into a predefined time-box (typically 30
days). Changes (e.g., backlog work items) are not introduced during the sprint.
Hence, the sprint allows team members to work in a short term, but stable
environment.
3. Scrum meetings – are short (typically 15 minutes) meetings held daily by the
Scrum team. Three key questions are asked and answered by all team members:
a. What did you do since the last team meeting?
b. What obstacles are you encountering?
c. What do you plan to accomplish by the next team meeting?
• A team leader, called a Scrum master, leads the meeting and assesses the
responses from each person.
• The Scrum meeting helps the team to uncover potential problems as early as
possible.
• Also, these daily meetings lead to “knowledge socialization” and thereby
promote a self-organizing team structure.
 Conventional Software Process Models
Agile – Scrum
• Demos – deliver the software increment to the customer so that functionality
that has been implemented can be demonstrated and evaluated by the
customer.
• It is important to note that the demo may not contain all planned functionality,
but rather those functions that can be delivered within the time-box that was
established.
• Beedle and his colleagues present a comprehensive discussion of these patterns
in which they state: “Scrum assumes up-front the existence of chaos…”
• The Scrum process patterns enable a software team to work successfully in a
world where the elimination of uncertainty is impossible.
 Introduction to Requirement Engineering
• Inception—ask a set of questions that establish …
– Basic understanding of the problem
– The people who want a solution
– The nature of the solution that is desired, and
– The effectiveness of preliminary communication and collaboration between
the customer and the developer
• Elicitation—elicit requirements from all stakeholders
• Elaboration—create an analysis model that identifies data, function and
behavioral requirements
• Negotiation—agree on a deliverable system that is realistic for developers and
customers
• Specification—can be any one (or more) of the following:
– A written document
– A set of models
– A formal mathematical
– A collection of user scenarios (use-cases)
– A prototype
 Introduction to Requirement Engineering
• Validation—a review mechanism that looks for
– errors in content or interpretation
– areas where clarification may be required
– missing information
– inconsistencies (a major problem when large products or systems are
engineered)
– conflicting or unrealistic (unachievable) requirements.
• Requirements management

Inception
• Identify stakeholders
– “who else do you think I should talk to?”
• Recognize multiple points of view
• Work toward collaboration
• The first questions
– Who is behind the request for this work?
– Who will use the solution?
– What will be the economic benefit of a successful solution?
– Is there another source for the solution that you need?
 Requirements Elicitation
• Meetings are conducted and attended by both software engineers and
customers.

• Rules for preparation and participation are established

• An agenda is suggested

• A "facilitator" (can be a customer, a developer, or an outsider) controls the

meeting.

• A "definition mechanism" (can be work sheets, flip charts, or wall stickers or an

electronic bulletin board, chat room or virtual forum) is used.

• The goal is
– To identify the problem
– Propose elements of the solution
– Negotiate different approaches, and
– Specify a preliminary set of solution requirements
 Requirements Elicitation

Conduc t FAST
m e e t ings

Ma ke lis t s of
func t ions , c la s s e s

Ma ke lis t s of
c ons t ra int s , e t c .

form a l priorit iz a t ion?

Elic it re q u ire m e n t s
ye s no

Us e QFD t o inform a lly de fine a c t ors

priorit iz e priorit iz e
re quire m e nt s re quire m e nt s

dra w us e -c a s e
writ e s c e na rio
dia gra m

Cre a t e Us e -c a s e s
c om ple t e t e m pla t e
 Quality Function Deployment
• Function deployment determines the “value” (as perceived by the customer) of
each function required of the system

• Information deployment identifies data objects and events

• Task deployment examines the behavior of the system

• Value analysis determines the relative priority of requirements

 Elicitation Work Products
• A statement of need and feasibility.

• A bounded statement of scope for the system or product.

• A list of customers, users, and other stakeholders who participated in

requirements elicitation.

• A description of the system’s technical environment.

• A list of requirements (preferably organized by function) and the domain

constraints that apply to each.

• A set of usage scenarios that provide insight into the use of the system or
product under different operating conditions.

• Any prototypes developed to better define requirements.

 Building Analysis Model
• Elements of the analysis model
– Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an “actor” and the
system

– Class-based elements
• Implied by scenarios

– Behavioral elements
• State diagram

– Flow-oriented elements
• Data flow diagram
 Scenario-based Elements - Use Cases
• A collection of user scenarios that describe the thread of usage of a system.
• Each scenario is described from the point-of-view of an “actor”—a person or
device that interacts with the software in some way.
• Each scenario answers the following questions:
– Who is the primary actor, the secondary actor(s)?
– What are the actor’s goals?
– What preconditions should exist before the story begins?
– What main tasks or functions are performed by the actor?
– What extensions might be considered as the story is described?
– What variations in the actor’s interaction are possible?
– What system information will the actor acquire, produce, or change?
– Will the actor have to inform the system about changes in the external
environment?
– What information does the actor desire from the system?
– Does the actor wish to be informed about unexpected changes?
 Use Case Diagram

Arms / dis a rms

s ys t e m

Ac c e s s e s s ys t e m s e ns ors
via Int e rne t

home ow ne r

Re s ponds t o
a la rm e ve nt

Enc ount e rs a n
e rror c ondit ion

s ys t e m Re c onfigure s s e ns ors
a dminis t ra t or a nd re la t e d
s ys t e m fe a t ure s
 Class-based Elements - Class Diagram
• Each usage scenario implies a set of objects
that are manipulated as an actor interacts with From the SafeHome system …
the system.
• These objects are categorized into classes – a
collection of things that have similar attributes
and common behaviors. Sensor
• For example, a UML class diagram can be used
to depict a Sensor class for the SafeHome name/id
security function.
type
• Note that the diagram lists the attributes of
location
sensors (name, type) and the operations (e.g.,
identify, enable) that can be applied to modify area
these attributes. characteristics
• In addition to class diagrams, other analysis
modeling elements depict the manner in which identify()
classes collaborate with one another and the enable()
relationships and interactions between classes. disable()
reconfigure ()
 Behavioral Elements - State Diagram
• The behavior of a computer-based system
can have a profound effect on the design
that is chosen and the implementation
approach that is applied.
• Therefore, the requirements model must
provide modeling elements that depict Reading
behavior. Commands
State
• The state diagram is one method for System status = “ready” name
Display msg = “enter cmd”
representing the behavior of a system by Display status = steady
depicting its states and the events that State
cause the system to change state. variables
Entry/subsystems ready
• A state is any externally observable mode Do: poll user input panel
of behavior. Do: read user input
Do: interpret user input State
• In addition, the state diagram indicates activities
actions (process activation) taken as a
consequence of a particular event.
• To illustrate the use of a state diagram,
consider software embedded within the
SafeHome control panel that is responsible
for reading user input.
• A simplified UML state diagram is shown.
 Flow-Oriented Elements
• Information is transformed as it flows through a computer-based system.
• The system accepts input in a variety of forms, applies functions to transform it
and produces output in a variety of forms.
• Input may be a control signal transmitted by a transducer, a series of numbers
typed by a human operator, a packet of information transmitted on a network
link, or a voluminous data file retrieved from secondary storage.
• The transform(s) may comprise a single logical comparison, a complex
numerical algorithm, or a rule-inference approach of an expert system.
• Output may light a single LED or produce a 200-page report.
• In effect, we can create a flow model for any computer-based system,
regardless of size and complexity.
 Analysis Patterns
Pattern name: A descriptor that captures the essence of the pattern.
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used to
address the problem.
Forces and context: A description of external issues (forces) that can affect
how the pattern is used and also the external issues that will be resolved
when the pattern is applied.
Solution: A description of how the pattern is applied to solve the problem
with an emphasis on structural and behavioral issues.
Consequences: Addresses what happens when the pattern is applied and
what trade-offs exist during its application.
Design: Discusses how the analysis pattern can be achieved through the use
of known design patterns.
Known uses: Examples of uses within actual systems.
Related patterns: One or more analysis patterns that are related to the
named pattern because (1) it is commonly used with the named pattern;
(2) it is structurally similar to the named pattern;
(3) it is a variation of the named pattern.
 Negotiating Requirements
• Identify the key stakeholders
– These are the people who will be involved in the negotiation

• Determine each of the stakeholders “win conditions”

– Win conditions are not always obvious

• Negotiate
– Work toward a set of requirements that lead to “win-win”
 Validating Requirements
• Is each requirement consistent with the overall objective for the
system/product?

• Have all requirements been specified at the proper level of abstraction? That is,
do some requirements provide a level of technical detail that is inappropriate at
this stage?

• Is the requirement really necessary or does it represent an add-on feature that

may not be essential to the objective of the system?

• Is each requirement bounded and unambiguous?

• Does each requirement have attribution? That is, is a source (generally, a

specific individual) noted for each requirement?

• Do any requirements conflict with other requirements?

 Validating Requirements
• Is each requirement achievable in the technical environment that will house the
system or product?

• Is each requirement testable, once implemented?

• Does the requirements model properly reflect the information, function and
behavior of the system to be built.

• Has the requirements model been “partitioned” in a way that exposes

progressively more detailed information about the system.

• Have requirements patterns been used to simplify the requirements model.

• Have all patterns been properly validated? Are all patterns consistent with
customer requirements?
 Software Project Effort and Cost Estimation
• Software projects are inherently effort driven because most of work involves
human effort to build the software product.
• Estimating the effort required to build the software product is difficult as the
result of effort is intangible and difficult to make effort estimation in building
software artifacts.
• There are many techniques like Function point analysis, wide band Delphi,
COCOMO etc. for making effort estimation on software projects.
• Depending on requirement, a suitable effort estimation technique is chosen for
any software project.
• Since effort estimation techniques are not foolproof, effort estimates need to be
revised as the project progresses.
• Once effort estimates are made for the project, cost estimates are calculated
based on the effort estimate and cost parameters like hourly salary of individual
employees.
• Cost estimates are done using techniques like activity based costing or cost
factor analysis.
 Software Project Effort and Cost Estimation
• Estimation of resources, cost, and schedule for a software engineering effort
requires
– Experience
– Access to good historical information (metrics)
– The courage to commit to quantitative predictions when qualitative
information is all that exists
• Estimation carries inherent risk and this risk leads to uncertainty.
• Project scope must be understood
• Elaboration (decomposition) is necessary
• Historical metrics are very helpful
• At least two different techniques should be used
• Uncertainty is inherent in the process
• Estimation Techniques:
– Past (similar) project experience
– Conventional estimation techniques
• Task breakdown and effort estimates
• Size (e.g., FP) estimates
– Empirical models
– Automated tools
 Software Project Effort and Cost Estimation
• Software projects use different kinds of software development life cycle models
like waterfall model, iterative model etc.
• Effort estimation for each type of software development lifecycle model requires
understanding the difference in the way the software product is built.
• In iterative models, software products are built in small incremental cycles.
• On the contrary in the waterfall model, software products are built in one go
and thus all product features are fully built in the same one cycle.
• This fundamental difference necessitates a different approach to effort
estimation for each type of software development lifecycle model projects.
• Software products are made manually by software engineers.
• How many of these people are needed on the project and for how long, is
determined by the effort estimate and project duration.
• Resource estimation also needs to take into consideration the skill set required
on the project.
• Of course, speed with which a software engineer can build a software product
varies and thus this factor can affect resource estimation on the project.
 Software Project Effort and Cost Estimation
Function point count for effort estimate (function point analysis technique)

• Function points are derived using an empirical relationship based on countable

(direct) measures of software’s information domain and qualitative assessments
of software complexity.
• The function point (FP) metric can be used effectively as a means for measuring
the functionality delivered by a system.
• Using historical data, the FP metric can then be used to – a) estimate the cost or
effort required to design, code and test the software, b) predict the number of
errors that will be encountered during testing, c) forecast the number of
components and/or the number of projected source lines in the implemented
 Software Project Effort and Cost Estimation
Function count type for effort estimate (function point analysis technique)

Effort sizing for effort estimate (function point analysis technique)

Software Project Effort and Cost Estimation

Effort estimate for iterative projects

 Software Project Effort and Cost Estimation
Comparison of effort estimate techniques

Effort and cost for

various project tasks
 Software Pricing
• Estimates are made to discover the cost, to the developer, of producing a
software system.
– You take into account, hardware, software, travel, training and effort costs.
• There is not a simple relationship between the development cost and the price
charged to the customer.
• Broader organisational, economic, political and business considerations
influence the price charged.
• Factors affecting Software Pricing
Factor Description
Contractual terms A customer may be willing to allow the developer to retain
ownership of the source code and reuse it in other projects.
The price charged may then be less than if the software
source code is handed over to the customer.
Cost estimate If an organization is unsure of its cost estimate, it may
uncertainty increase its price by a contingency over and above its
normal profit.
Financial health Developers in financial difficulty may lower their price to
gain a contract. It is better to make a smaller than normal
profit or break even than to go out of business. Cash flow is
more important than profit in difficult economic times.
 Software Pricing
• Factors affecting Software Pricing
Factor Description
Market opportunity A development organization may quote a low price
because it wishes to move into a new segment of the
software market. Accepting a low profit on one project may
give the organization the opportunity to make a greater
profit later. The experience gained may also help it
develop new products.
Requirements volatility If the requirements are likely to change, an organization
may lower its price to win a contract. After the contract is
awarded, high prices can be charged for changes to the
requirements.
• Pricing Strategies
• Under pricing
– A company may under price a system in order to gain a contract that allows
them to retain staff for future opportunities
– A company may under price a system to gain access to a new market area
• Increased pricing
– The price may be increased when a buyer wishes a fixed-price contract and
so the seller increases the price to allow for unexpected risks
 Pricing to Win
• The software is priced according to what the software developer believes the
buyer is willing to pay.
• If this is less that the development costs, the software functionality may be
reduced accordingly with a view to extra functionality being added in a later
release.
• Additional costs may be added as the requirements change and these may be
priced at a higher level to make up the shortfall in the original price.
 Software Project Effort and Cost Estimation
Project Planning – Task Set
• Estimate cost and effort
– Decompose the problem
– Develop two or more estimates using size, function points, process tasks or
use-cases
– Reconcile the estimates

• Develop a project schedule

– Establish a meaningful task set
– Define a task network
– Use scheduling tools to develop a timeline chart
– Define schedule tracking mechanisms
 Software Project Effort and Cost Estimation – Software Sizing
• Predicated on …
– The degree to which the planner has properly estimated the size of the
product to be built
– The ability to translate the size estimate into human effort, calendar time,
and dollars (a function of the availability of reliable software metrics from
past projects)
– The degree to which the project plan reflects the abilities of the software
team
– The stability of product requirements and the environment that supports
the software engineering effort.
Software Project Effort and Cost Estimation - Techniques
Functional Decomposition

Statement Functional
of decomposition
Scope
Perform a
Grammatical “parse”

62
 Software Project Effort and Cost Estimation - Techniques
Conventional Methods – LOC/FP Approach
• Compute LOC/FP using estimates of information domain values
• Use historical data to build estimates for the project
• Example – LOC Approach

Average productivity for systems of this type = 620 LOC/pm.

Burdened labor rate =$8000 per month, the cost per line of
code is approximately $13.
Based on the LOC estimate and the historical productivity
data, the total estimated project cost is $431,000 and the
63
estimated effort is 54 person-months.
 Software Project Effort and Cost Estimation - Techniques
Conventional Methods – LOC/FP Approach
Example: FP Approach

The estimated number of FP is derived:

FPestimated = count-total 3 [0.65 + 0.01 3 S (Fi)]
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total estimated
project cost is $461,000 and estimated effort is 58 person-months.
64
Software Project Effort and Cost Estimation - Techniques
Process Based Estimation

Obtained from “process framework”

Framework activities

Application Effort required to

functions accomplish
each framework
activity for each
application function

65
Software Project Effort and Cost Estimation - Techniques
Process Based Estimation - Example
Activity Risk Construction
CC Planning Analysis Engineering Release CE Totals
Task analysis design code test

Function

UICF 0.50 2.50 0.40 5.00 n/a 8.40

2DGA 0.75 4.00 0.60 2.00 n/a 7.35
3DGA 0.50 4.00 1.00 3.00 n/a 8.50
CGDF 0.50 3.00 1.00 1.50 n/a 6.00
DSM 0.50 3.00 0.75 1.50 n/a 5.75
PCF 0.25 2.00 0.50 1.50 n/a 4.25
DAM 0.50 2.00 0.50 2.00 n/a 5.00

Totals 0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

% effort 1% 1% 1% 8% 45% 10% 36%

CC = customer communication CE = customer evaluation

Based on an average burdened labor rate of $8,000 per
month, the total estimated project cost is $368,000 and the
estimated effort is 46 person-months.
66
Software Project Effort and Cost Estimation - Techniques
Tool Based Estimation

Project Characteristics

Calibration Factors

LOC/FP data

67
Software Project Effort and Cost Estimation - Techniques
Estimation with Use Cases

Using 620 LOC/pm as the average productivity for systems of

this type and a burdened labor rate of $8000 per month, the
cost per line of code is approximately $13. Based on the use-
case estimate and the historical productivity data, the total
estimated project cost is $552,000 and the estimated effort is
68 person-months.

68
 Software Project Effort and Cost Estimation - Problems

• Estimated LOC count is 56,100 . Assuming that your organization produces

450 LOC/pm with a burdened labor rate of $7000 per person-month, find the
cost /LOC, total estimated project cost and estimated effort in person months.
To Compute:
• Cost per LOC = Labor rate per month/LOC per pm
• Total Estimated Project Cost = Estimated LOC * Cost per LOC
• Estimated Effort in pm = Total Estimated Project Cost/ Labor rate per month

69
 COCOMO I
• The constructive cost model was developed by Barry W. Boehm in the late
1970s and published in Boehm's 1981 as a model for estimating effort, cost
and schedule for software projects.
• Basic model - It estimates the software in a rough and quick manner.
• Mostly used in small and medium sized projects.
• 3 modes of development:
a) Organic,
b) Semi Detached,
c) Embedded

70
 COCOMO - I
• Equation & Example

71
 COCOMO I
Numerical
• Suppose a project was estimated to be 400 KLOC. Calculate effort and time for
organic mode.
• Organic:
Effort = a (KLOC)b
Effort = 2.4 (400)1.05
Effort = 1295PM
Development Time = c (Effort)d
Development Time = 2.5 (1295)0.38
Development Time = 38 Months, Find Effort Staff Size, Productivity??
• Semi-detached:
Effort = a (KLOC)b
Effort = 3.0 (400)1.12
Person Months = 2462PM, Find Development Time, Effort Staff Size, Productivity??
• Embedded:
Effort = a (KLOC)b
Effort = 3.6 (400)1.20
Person Months = 4772PM , Find Development Time , Effort Staff Size, Productivity??
72
 COCOMO II
• Barry Boehm introduced a hierarchy of software estimation models bearing
the name COCOMO, for Constructive Cost Model.
• The original COCOMO model became one of the most widely used and
discussed software cost estimation models in the industry.
• It has evolved into a more comprehensive estimation model, called COCOMO
II.
• Like its predecessor, COCOMO II is actually a hierarchy of estimation models
that address the following areas:
– Application composition model: Used during the early stages of software engineering, when
prototyping of user interfaces, consideration of software and system interaction, assessment
of performance, and evaluation of technology maturity are paramount.
– Early design stage model: Used once requirements have been stabilized and basic software
architecture has been established.
– Post-architecture-stage model: Used during the construction of the software.
• Like all estimation models for software, the COCOMO II models require sizing
information.
• Three different sizing options are available as part of the model hierarchy:
object points, function points and lines of source code.

73
 COCOMO II
• The COCOMO II application composition model uses object points and is illustrated
below.
• It should be noted that other, more sophisticated estimation models (using FP and
KLOC) are also available as part of COCOMO II.

Complexity weighting for object types

• Like function points, the object point is an indirect software measure that is computed
using counts of the number of (a) screens (at the user interface), (b) reports, and (c)
components likely to be required to build the application.
• Each object instance (e.g., a screen or report) is classified into one of three complexity
levels (i.e., simple, medium, or difficult) using criteria suggested by Boehm.
• In essence, complexity is a function of the number and source of the client and server
data tables that are required to generate the screen or report and the number of views
or sections presented as part of the screen or report.
74
 COCOMO II
• Once complexity is determined, the number of screens, reports and
components are weighted according to the table illustrated in above figure.
• The object point count is then determined by multiplying the original number
of object instances by the weighting factor in the figure and summing to obtain
a total object point count.
• When component-based development or general software reuse is to be
applied, the percent of reuse (%reuse) is estimated and the object point count
is adjusted:
NOP = (object points) * [(100 - % reuse) / 100], where NOP is defined as new
object points
• To derive an estimate of effort based on the computed NOP value, a
“productivity rate” must be derived.

75
 COCOMO II
• The figure above presents the productivity rate,
PROD = NOP / person-month, for different levels of developer experience and
development environment maturity.
• Once the productivity rate has been determined, an estimate of project effort
is computing using,
Estimated effort = NOP / PROD
• In more advanced COCOMO II models (these models use FP and KLOC counts
of the size variable), a variety of scale factors, cost drivers, and adjustment
procedures are required.

76
 COCOMO II - Problems
• Use the COCOMO II model to estimate the effort required to build software for
a simple ATM that produces 12 screens, 10 reports, and will require
approximately 80 software components, Percentage of reuse is 20%, Value of
Prod=9. Use the application composition model with object points.
To Compute:
• Object points = screen + report + components
• NOP = Object Points * [(100 - % reuse)/100]
• Estimated Effort = NOP/PROD

77
 Risk Management
Introduction
• A risk is a potential problem – it might happen or it might not
• Conceptual definition of risk
– Risk concerns future happenings
– Risk involves change in mind, opinion, actions, places, etc.
– Risk involves choice and the uncertainty that choice entails

• Two characteristics of risk

– Uncertainty – the risk may or may not happen, that is, there are no 100% risks.
(those, instead are called constraints)
– Loss – the risk becomes a reality and unwanted consequences or losses occur

78
 Risk Management
Risk Categorization – Approach #1
• Project risks
– They threaten the project plan
– If they become real, it is likely that the project schedule will slip and that costs
will increase
• Technical risks
– They threaten the quality and timeliness of the software to be produced
– If they become real, implementation may become difficult or impossible
• Business risks
– They threaten the viability of the software to be built
– If they become real, they jeopardize the project or the product
• Sub-categories of Business risks
– Market risk – building an excellent product or system that no one really wants
– Strategic risk – building a product that no longer fits into the overall
business strategy for the company
– Sales risk – building a product that the sales force doesn't understand how to sell
– Management risk – losing the support of senior management due to a
change in focus or a change in people
– Budget risk – losing budgetary or personnel commitment
79
 Risk Management
Risk Categorization – Approach #2
• Known risks
– Those risks that can be uncovered after careful evaluation of the project plan, the
business and technical environment in which the project is being developed, and
other reliable information sources (e.g., unrealistic delivery date).
• Predictable risks
– Those risks that are extrapolated from past project experience (e.g., past
turnover).
• Unpredictable risks
– Those risks that can and do occur, but are extremely difficult to identify in
advance.

80
 Risk Strategies
• Reactive risk strategies
– "Don't worry, I'll think of something"
– The majority of software teams and managers rely on this approach
– Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the problem rapidly
• (Fire fighting)
– Crisis management is the choice of management techniques

• Proactive risk strategies

– Steps for risk management are followed (see next slide)
– Primary objective is to avoid risk and to have a contingency plan in place to handle
unavoidable risks in a controlled and effective manner

81
 Steps for Risk Management
• Identify possible risks; recognize what can go wrong.
• Analyze each risk to estimate the probability that it will occur and the impact
(i.e., damage) that it will do if it does occur.
• Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and catastrophic
• Develop a contingency plan to manage those risks having high probability and
high impact.

82
 Risk Identification
Background
• Risk identification is a systematic attempt to specify threats to the project
plan
• By identifying known and predictable risks, the project manager takes a first
step toward avoiding them when possible and controlling them when
necessary
• Generic risks
– Risks that are a potential threat to every software project
• Product-specific risks
– Risks that can be identified only by those a with a clear understanding of the
technology, the people, and the environment that is specific to the software
that is to be built
– This requires examination of the project plan and the statement of scope
– "What special characteristics of this product may threaten our project plan?“

83
 Risk Item Checklist
• Used as one way to identify risks
• Focuses on known and predictable risks in specific subcategories (see next
slide)
• Can be organized in several ways
– A list of characteristics relevant to each risk subcategory
– Questionnaire that leads to an estimate on the impact of each risk
– A list containing a set of risk component and drivers along with their probability of
occurrence

84
 Known & Predictable Risk Categories
• Product size – risks associated with overall size of the software to be built
• Business impact – risks associated with constraints imposed by
management or the marketplace
• Customer characteristics – risks associated with 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
• Development environment – risks associated with availability and quality
of the tools to be used to build the project
• Technology to be built – risks associated with complexity of the system to
be built and the "newness" of the technology in the system
• Staff size and experience – risks associated with overall technical and project
experience of the software engineers who will do the work

85
 Questionnaire on Project Risk
(Questions are ordered by their relative importance to project success)

1) Have top software and customer managers formally committed to support the
project?
2) Are end-users enthusiastically committed to the project and the
system/product to be built?
3) Are requirements fully understood by the software engineering team and its
customers?
4) Have customers been involved fully in the definition of
requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?
7) Does the software engineering team have the right mix of skills?
8) Are project requirements stable?
9) Does the project team have experience with the technology to be
implemented?
10) Is the number of people on the project team adequate to do the job?
11) Do all customer/user constituencies agree on the importance of the project and
on the requirements for the system/product to be built?
86
 Risk Components and Drivers
• The project manager identifies the risk drivers that affect the following 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
• The impact of each risk driver on the risk component is divided into one of
four impact levels
– Negligible, marginal, critical, and catastrophic
• Risk drivers can be assessed as impossible, improbable, probable, and
frequent

87
 Risk Projection (Estimation)
• Risk projection (or estimation) attempts to rate each risk in two ways
– The probability that the risk is real
– The consequence of the problems associated with the risk, should it occur
• The project planner, managers, and technical staff perform four risk projection
steps
• The intent of these steps is to consider risks in a manner that leads to
prioritization
• Be prioritizing risks, the software team can allocate limited resources where
they will have the most impact
• Risk Projection / Estimation Steps
1. Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low,
10-high)
2. Delineate the consequences of the risk
3. Estimate the impact of the risk on the project and product
4. Note the overall accuracy of the risk projection so that there will be no
misunderstandings

88
 Risk Table
• A risk table provides a project manager with a simple technique for risk
projection.
• It consists of five columns
– Risk Summary – short description of the risk
– Risk Category – one of seven risk categories
– Probability – estimation of risk occurrence based on group input
– Impact – (1) catastrophic (2) critical (3) marginal (4) negligible
– RMMM – Pointer to a paragraph in the Risk Mitigation, Monitoring, and
Management Plan

Risk Summary Risk Category Probability Impact (1-4) RMMM

89
 Developing a Risk Table
• List all risks in the first column (by way of the help of the risk item checklists)

• Mark the category of each risk

• Estimate the probability of each risk occurring

• Assess the impact of each risk based on an averaging of the four risk
components to determine an overall impact value

• Sort the rows by probability and impact in descending order

• Draw a horizontal cutoff line in the table that indicates the risks that will be
given further attention

90
 Assessing Risk Impact
• Three factors affect the consequences that are likely if a risk does occur
– Its nature – This indicates the problems that are likely if the risk occurs
– Its scope – This combines the severity of the risk (how serious was it) with its
overall distribution (how much was affected)
– Its timing – This considers when and for how long the impact will be felt
• The overall risk exposure formula is RE = P x C
– P = the probability of occurrence for a risk
– C = the cost to the project should the risk actually occur
• Example
– P = 80% probability that 18 of 60 software components will have to be
developed
– C = Total cost of developing 18 components is $25,000
– RE = .80 x $25,000 = $20,000

91
 Risk Mitigation, Monitoring and Management
• An effective strategy for dealing with risk must consider three issues
• (Note: these are not mutually exclusive)
– Risk mitigation (i.e., avoidance)
– Risk monitoring
– Risk management and contingency planning
• Risk mitigation (avoidance) is the primary strategy and is achieved through a
plan.
- Example: Risk of high staff turnover

92
 Risk Mitigation, Monitoring and Management
• Strategy for Reducing Staff Turnover
 Meet with current staff to determine causes for turnover (e.g., poor
working conditions, low pay, competitive job market)

 Mitigate those causes that are under our control before the project starts

 Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave

 Organize project teams so that information about each development

activity is widely dispersed

 Define documentation standards and establish mechanisms to ensure that

documents are developed in a timely manner

 Conduct peer reviews of all work (so that more than one person is "up to
speed")

 Assign a backup staff member for every critical technologist

93
 Risk Mitigation, Monitoring and Management
• During risk monitoring, the project manager monitors factors that may
provide an indication of whether a risk is becoming more or less likely.
• Risk management and contingency planning assume that mitigation efforts
have failed and that the risk has become a reality.
• RMMM steps incur additional project cost
– Large projects may have identified 30 – 40 risks
• Risk is not limited to the software project itself
– Risks can occur after the software has been delivered to the user
• Software safety and hazard analysis
– These are software quality assurance activities that focus on the identification
and assessment of potential hazards that may affect software negatively and
cause an entire system to fail.
– If hazards can be identified early in the software process, software design
features can be specified that will either eliminate or control potential hazards.

94
 RMMM Plan
• The RMMM plan may be a part of the software development plan or may be a
separate document.
• Once RMMM has been documented and the project has begun, the risk
mitigation, and monitoring steps begin
– Risk mitigation is a problem avoidance activity
– Risk monitoring is a project tracking activity
• Risk monitoring has three objectives
– To assess whether predicted risks do, in fact, occur
– To ensure that risk aversion steps defined for the risk are being properly applied
– To collect information that can be used for future risk analysis
• The findings from risk monitoring may allow the project manager to
ascertain what risks caused which problems throughout the project.

95
 Seven Principles of Risk Management
• Maintain a global perspective
– View software risks within the context of a system and the business problem that is
intended to solve
• Take a forward-looking view
– Think about risks that may arise in the future; establish contingency plans
• Encourage open communication
– Encourage all stakeholders and users to point out risks at any time
• Integrate risk management
– Integrate the consideration of risk into the software process
• Emphasize a continuous process of risk management
– Modify identified risks as more becomes known and add new risks as better
insight is achieved
• Develop a shared product vision
– A shared vision by all stakeholders facilitates better risk identification and
assessment.
• Encourage teamwork when managing risk
– Pool the skills and experience of all stakeholders when conducting risk
management activities

96
 Configuration Management
Introduction
• The First Law: No matter where you are in the system lifecycle, the system will
change and the desire to change it will persist throughout the lifecycle.
• What are these changes?

business requirements

technical requirements

user

requirements

97
 Configuration Management
Software Configuration

98
 Configuration Management
Baselines
• The IEEE(IEEE Std. No. 610.12-1990) defines a baseline as:
– A specification or product that has been formally reviewed and agreed upon, that
thereafter serves as the basis for further development, and that can be changed
only through formal change control procedures.
• A baseline is a milestone in the development of software that is marked by the
delivery of one or more software configuration items and the approval of these
SCIs that is obtained through a formal technical review.

99
 Configuration Management
Baselines

modified

SCIs

Project database

approved
Software Formal
engineering SCIs technical SCIs
tasks reviews

stored

SCIs

extracted
SCM
SCIs
controls

BASELINES:
System Specification
Software Requirements
Design Specification Source
Code
Test Plans/Procedures/Data
Operational System

100
 Configuration Management
Software Configuration Objects

Data model

Design specification

data design architectural

design module design
interface design

Component N

interface description
algorithm description PDL
Test specification

test plan
test procedure
test cases

Source code

101
 Configuration Management
SCM Repository
• The SCM repository is the set of mechanisms and data structures that allow a
software team to manage change in an effective manner.
• The repository performs or precipitates the following functions:
– Data integrity
– Information sharing
– Tool integration
– Data integration
– Methodology enforcement
– Document standardization
• Repository Content

102
 Configuration Management
Repository Content

103
 Configuration Management
Repository Features
• Versioning
– Saves all of these versions to enable effective management of product releases and
to permit developers to go back to previous versions.
• Dependency tracking and change management
– The repository manages a wide variety of relationships among the data elements
stored in it.
• Requirements tracing
– Provides the ability to track all the design and construction components and
deliverables that result from a specific requirement specification
• Configuration management
– Keeps track of a series of configurations representing specific project milestones or
production releases.
– Version management provides the needed versions and link management keeps
track of interdependencies.
• Audit trails
– Establishes additional information about when, why and by whom changes are
made.
104
 Configuration Management
SCM Elements
• Component elements—a set of tools coupled within a file management
system (e.g., a database) that enables access to and management of each
software configuration item.

• Process elements—a collection of procedures and tasks that define an

effective approach to change management (and related activities) for all
constituencies involved in the management, engineering and use of computer
software.

• Construction elements—a set of tools that automate the construction of

software by ensuring that the proper set of validated components (i.e., the
correct version) have been assembled.

• Human elements—to implement effective SCM, the software team uses a set
of tools and process features (encompassing other CM elements).

105
 Configuration Management
SCM Process - Addresses the following questions…
• How does a software team identify the discrete elements of a software
configuration?

• How does an organization manage the many existing versions of a program

(and its documentation) in a manner that will enable change to be
accommodated efficiently?

• How does an organization control changes before and after software is

released to a customer?

• Who has responsibility for approving and ranking changes?

• How can we ensure that changes have been made properly?

• What mechanism is used to appraise others of changes that are made?

106
 Configuration Management
SCM Process

107
 Configuration Management
Version Control
• Version control combines procedures and tools to manage different versions of
configuration objects that are created during the software process.
• A version control system implements or is directly integrated with four major
capabilities:
– A Project database (repository) that stores all relevant configuration objects.
– A Version management capability that stores all versions of a configuration object
(or enables any version to be constructed using differences from past versions);
– A Make facility that enables the software engineer to collect all relevant
configuration objects and construct a specific version of the software.
– An Issues tracking (also called bug tracking) capability that enables the team to
record and track the status of all outstanding issues associated with each
configuration object.

108
 Configuration Management
Change Control
• The reality of change control in a modern software engineering context has
been summed up beautifully by James Bach.
• Change control is vital. But the forces that make it necessary also make it
annoying.
• Bach recognizes that we face a balancing act. Too much change control and we
create problems. Too little, and we create other problems.
• The change control process is illustrated schematically in below figure.

109
 Configuration Management
Change Control Process

110
 Configuration Management
Auditing
•Identification, version control and change control help you to maintain order in what would otherwise be a
chaotic and fluid situation.
•How can a software team ensure that the change has been properly implemented? The answer is twofold:
(1) Technical reviews, (2) Software configuration audit

•The technical review focuses on the technical correctness of the configuration object that has been
modified.
•A software configuration audit complements the technical review by assessing a configuration object for
characteristics that are generally not considered during review. 111
 Configuration Management
Auditing
• The review asks and answers the following questions:
1. Has the change specified in the ECO (Engineering Change Order) been
made? Have any additional modifications been incorporated?
2. Has a technical review been conducted to assess technical correctness?
3. Has the software process been followed and have software engineering
standards been properly applied?
4. Has the change been "highlighted" in the SCI? Have the change date and
change author been specified? Do the attributes of the configuration object
reflect the change?
5. Have SCM procedures for noting the change, recording it and reporting it
been followed?
6. Have all related SCIs been properly updated?

112
 Configuration Management
Status Accounting
• Configuration status reporting (sometimes called status accounting) 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?
• The flow of information for configuration status reporting (CSR) is illustrated in
figure - The Change control process.
• Each time an SCI is assigned new or updated identification, a CSR entry is made.
• Each time a change is approved by the CCA (i.e., an ECO is issued), a CSR entry is
made. (Change Control Authority)
• Each time a configuration audit is conducted, the results are reported as part of
the CSR task.
• Output from CSR may be placed in an online database or website, so that software
developers or support staff can access change information by keyword category.
• In addition, a CSR report is generated on a regular basis and is intended to keep
management and practitioners appraised of important changes. 113
 Configuration Management
Status Accounting

114
 Configuration Management
SCM for Web Engineering
• Content
- A typical WebApp contains a vast array of content—text, graphics, applets, scripts,
audio/video files, forms, active page elements, tables, streaming data, and many
others.
- The challenge is to organize this sea of content into a rational set of configuration
objects and then establish appropriate configuration control mechanisms for
these objects.

• People
- Because a significant percentage of WebApp development continues to be
conducted in an ad hoc manner, any person involved in the WebApp can (and
often does) create content.

• Scalability
- As size and complexity grow, small changes can have far-reaching and unintended
affects that can be problematic.
- Therefore, the rigor of configuration control mechanisms should be directly
proportional to application scale. 115
 Configuration Management
SCM for Web Engineering
• Politics
- Who owns a WebApp?
- Who assumes responsibility for the accuracy of the information on the website?
- Who assures that quality control processes have been followed before
information is published to the site?
- Who is responsible for making changes?
- Who assumes the cost of change?

116
 Configuration Management
Content Management
• The collection subsystem encompasses all actions required to create and/or
acquire content and the technical functions that are necessary to
- Convert content into a form that can be represented by a mark-up
language (e.g., HTML, XML)
- Organize content into packets that can be displayed effectively on the
client-side.
• The management subsystem implements a repository that encompasses the
following elements:
- Content database – the information structure that has been established
to store all content objects.
- Database capabilities—functions that enable the CMS to search for specific
content objects (or categories of objects), store and retrieve objects and manage
the file structure that has been established for the content.
- Configuration management functions—the functional elements and associated
workflow that support content object identification, version control, change
management, change auditing and reporting.

117
 Configuration Management
Content Management

118
 Configuration Management
Content Management
• The publishing subsystem extracts from the repository, converts it to a form
that is amenable to publication and formats it so that it can be transmitted to
client-side browsers.
• The publishing subsystem accomplishes these tasks using a series of templates.
• Each template is a function that builds a publication using one of three
different components
 Static elements—Text, graphics, media and scripts that require
no further processing are transmitted directly to the client-side
 Publication services—Function calls to specific retrieval and formatting
services that personalize content (using predefined rules), perform data
conversion, and build appropriate navigation links.
 External services—Provide access to external corporate information
infrastructure such as enterprise data or “back- room” applications.

119
 Configuration Management
Change Management for WebApps
• The workflow associated with change control for conventional software is
generally too ponderous for WebApp development.
• It is unlikely that the change request, change report, and engineering change
order sequence can be achieved in an agile manner that is acceptable
for most WebApp development projects.
• To implement effective change management within the "code and go"
philosophy that continues to dominate WebApp development, the
conventional change control process must be modified.

120
 Configuration Management
Change Management for WebApp

121
 Configuration Management
Change Management for WebApps
• Each change should be categorized into one of four classes:
1. Class 1 - A content or function change that corrects an error or enhances
local content or functionality
2. Class 2 - A content or function change that has an impact on other content
objects or functional components
3. Class 3 - A content or function change that has a broad impact across a
WebApp (e.g., major extension of functionality, significant enhancement or
reduction in content, major required changes in navigation)
4. Class 4 - A major design change (e.g., a change in interface design or
navigation approach) that will be immediately noticeable to one or more
categories of user.
• Once the requested change has been categorized, it can be processed
according to the algorithm shown in above figure - Managing changes for
WebApps

122
 Project Planning
WBC
• Scheduling of a software project does not differ greatly from scheduling of any
multitask engineering effort.
• Therefore, generalized project scheduling tools and techniques can be applied with
little modification for software projects.
• Program Evaluation and Review Technique (PERT) and the Critical Path Method (CPM)
are two project scheduling methods that can be applied to software development.
• Both techniques are driven by information already developed in earlier project
planning activities: estimates of effort, a decomposition of the product function, the
selection of the appropriate process model and task set and decomposition of the
tasks that are selected.
• Interdependencies among tasks may be defined using a task network. Tasks,
sometimes called the project work breakdown structure (WBS) are defined for the
product as a whole or for individual functions.
• Both PERT and CPM provide quantitative tools that allow you to (1) determine the
critical path - the chain of tasks that determines the duration of the project, (2)
establish "most likely" time estimates for individual tasks by applying statistical
methods, and (3) calculate "boundary times" that define a time "window" for a
particular task.
123
 Project Planning
• An example time-line chart

124
 Project Planning
WBC - Time-Line Charts
• When creating a software project schedule, you begin with a set of tasks (the
work breakdown structure).
• If automated tools are used, the work breakdown is input as a task network or
task outline.
• Effort, duration and start date are then input for each task.
• In addition, tasks may be assigned to specific individuals.
• As a consequence of this input, a time-line chart, also called a Gantt chart, is
generated.
• A time-line chart can be developed for the entire project.
• Alternatively, separate charts can be developed for each project function or for
each individual working on the project.
• Figure - An example time-line chart illustrates the format of a time-line chart.
• It depicts a part of a software project schedule that emphasizes the concept
scoping task for a word-processing (WP) software product.

125
 Project Planning
• An example project table

126
 Project Planning
WBC - Time-Line Charts
• All project tasks (for concept scoping) are listed in the left-hand column.
• The horizontal bars indicate the duration of each task.
• When multiple bars occur at the same time on the calendar, task concurrency
is implied.
• The diamonds indicate milestones.
• Once the information necessary for the generation of a time-line chart has
been input, the majority of software project scheduling tools produce project
tables - a tabular listing of all project tasks, their planned and actual start and
end dates, and a variety of related information (Figure - An example project
table).
• Used in conjunction with the time-line chart, project tables enable you to track
progress.

127
 Project Planning
Why are Projects Late?
• An unrealistic deadline established by someone outside the software
development group.
• Changing customer requirements that are not reflected in schedule changes;
• An honest 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.

128
 Project Planning
Scheduling Principles
• Compartmentalization—Define distinct tasks
• Interdependency—Indicate task interrelationship
• Effort validation—Be sure resources are available
• Defined responsibilities—People must be assigned
• Defined outcomes—Each task must have an output
• Defined milestones—Review for quality

129
 Project Planning
Effort and Delivery Time

Effort
Cost
Ea = m ( t d 4 / t a 4 )

Impossible Ea = effort in person-months

region t d = nominal delivery time for schedule
t o = optimal development time (in terms of cost)
t a = actual delivery time desired
Ed

Eo

td to development time
Tmin = 0.75T d

130
 Project Planning
Effort Allocation

• “Front end” activities

40-50% – Customer communication
– Analysis
– Design
– Review and modification
• Construction activities
– Coding or code generation
15-20%
• Testing and installation
– Unit, integration
– White-box, black box
– Regression

30-40%

131
 Project Planning
• The overall goal of project planning is to establish a pragmatic strategy for
controlling, tracking and monitoring a complex technical project.
• Why? So the end result gets done on time, with quality!

Project Planning Task Set – I

• Establish project scope
• Determine feasibility
• Analyze risks
• Define required resources
– Determine require human resources
– Define reusable software resources
– Identify environmental resources

132
 Project Planning
Project Planning Task Set – II
• Estimate cost and effort
– Decompose the problem
– Develop two or more estimates using size, function points, process tasks or
use-cases
– Reconcile the estimates
• Develop a project schedule
– Scheduling
• Establish a meaningful task set
• Define a task network
• Use scheduling tools to develop a timeline chart
• Define schedule tracking mechanisms

133
 Project Planning
• Defining Task Sets
– Determine type of project
– Assess the degree of rigor required
– Identify adaptation criteria
– Select appropriate software engineering tasks

134
 Project Planning
Task Set Refinement

1.1 Concept scoping determines the overall scope of the project.

Task definition: Task 1.1 Concept Scoping

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 FTR: Review written description of need
FTR indicates that a formal technical review is to be conducted.
1.1.2.2 Derive a list of customer visible outputs/inputs
1.1.2.3 FTR: 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 FTR: Review output and input data objects derived in task 1.1.2;
1.1.3.2 Derive a model of functions/behaviors;
is refined to
1.1.3.3 FTR: 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: Task 1.1 135
 Project Planning
Define a Task Network

I.5a
I.3a
Concept
Tech. Risk
Implement.
Assessment

I.1 I.2 I.3b I.4 I.5b I.6

Proof of Concept Integrate Customer
Concept Concept Tech. Risk
Implement. a, b, c Reaction
scoping planning Assessment Concept

I.3c I.5c
Tech. Risk Concept
Assessment Implement.

Three I.3 tasks are Three I.3 tasks are

applied in parallel to applied in parallel to
3 different concept 3 different concept
functions functions

136
 Estimation
• Estimation of resources, cost, and schedule for a software engineering effort
requires
– Experience
– Access to good historical information (metrics)
– The courage to commit to quantitative predictions when qualitative
information is all that exists
• Estimation carries inherent risk and this risk leads to uncertainty
• Write it Down!

Project Scope Software

Estimates Project
Risks Plan
Schedule
Control strategy

137
 Scope
What is 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.
• To Understand Scope…
- Understand the customers needs
- Understand the business context
- Understand the project boundaries
- Understand the customer’s motivation
- Understand the likely paths for change
- Understand that ...Even when you understand, nothing is guaranteed!
138
 Scope
number software
tools
skills hardware

people
environment network
location resources

project

reusable
software
OTS new
components components

full-experience part.-experience
components components

139
 REFERENCES
• Roger S. Pressman, Software Engineering – A Practitioner Approach, 6th ed.,
McGraw Hill, 2005

• Ian Somerville, Software Engineering, 8th ed., Pearson Education, 2010

• Kendall & Kendall, System Analysis and Design, 9th ed., Pearson Education, 2014

• Education, https://www.slideshare.net/AwaisSiddique8/cocomo-model-1-and-2
THANK YOU